微光札记

测试 WorkBuddy 后，我开始给 AI 助手写一套 Harness ……

工具可以替换，项目可以失败，但协作经验可以被抽出来。

公众号原文
五一节前，我已经把 OpenClaw 卸载了。
这句话要先说清楚。因为后面这件事听起来有点反常：这几天，我又在 Codex 里花了 6300 多万 token，重新整理 OpenClaw 留下来的设定文件，还给 Agent 写了 6 份协作规则。
不是为了复活 OpenClaw。这个工具之前维护成本太高，我已经放弃了（详见《折腾 OpenClaw 三个月后，我把它卸载了》）。
真正的原因是，我最近在测试国产的 WorkBuddy，看看它能不能替代 OpenClaw。
WorkBuddy 开箱即用，比 OpenClaw 省心不少。但用着用着，我发现它离我想要的长期助手还差一点。
差的不是功能，而是它能不能接住我已经沉淀出来的协作方式。
所以这次整理，表面上是改一堆 md 文件，实际是在把“某个工具里的设定”，拆成以后任何 AI 工具都能接住的底层协议。
开始时，我给 Codex 的提示词是这样的：
当前我在OpenClaw里的设定还不够完善，需要你协助我一起完成更详细的操作，主要是针对workspace中的文档进行更新。
我需要你不断对我进行提问，直到你觉得有足够信息可以补充一份完整的立体人格画像、长期协作协议、未来90天的作战框架才可以。
流程是：
1. 读取已有资料
2. 根据前面我的提问要求，结合前面的md文件梳理并准备至少20+提问
这些问题可以是：
- 我是谁
- 我的工作、内容是什么
- 我喜欢什么（三观是怎样的）
- 我厌恶什么
- 我可能擅长什么
- 我可能擅长什么
- 我内心深处真相想要什么
- 我想成为怎样的人
- 我到底是怎么样的
不要拽专业名词，用大白话提问（要更具体，而不是直接用我发给你的这种，我发给你的这种不具体我也不知道怎么回答，用很小的事、物进行提问）。
3. 一个个提问，每个提问针对一个具体问题；如果我的回答有可挖掘的地方，就针对这个内容进行挖掘式提问同时调整后续的提问，直到这个问题有足够深度、广度的了解，清楚问题的边界、限定、禁忌；同样生成一份完整的分析文档（包括我的行为习惯、表达风格、个人观点、思考方式等等，你继续补充可以分析的，用md文件格式）在下载文件夹存放
4. 根据前面生成的两个文件，结合现在workspace下文件的内容，给出各个文件的修改建议，由用户确认调整
现在回头看，这段提示词暴露了我当时的一个误判：我以为问得足够细，AI 就会更懂我。
一开始它确实按要求做了。它问我的 90 天计划、AI 工具要求、项目经验，也问我希望 AI 怎么说话、哪些事必须先确认。
问题出在中段。
问到一个追热点的小项目时，它开始继续追问第一屏应该长什么样、MVP 阶段优先哪些一手来源。
这些问题本身没错。错在当前任务不是做这个项目，而是整理我和 AI 的协作模式。它把每个可展开的点，都当成了应该继续完成的路线。
我提醒它：“是不是有点跑偏了？”
这句话后来变成了一条很重要的规则：支线点到为止。拿到足够影响当前判断的信息，就收口；支线有价值，可以记入待办，不能在当前任务里一直追。
一个好用的 AI，不是永远替你把所有东西展开，它还得知道什么时候停。
后面 AI 又问我：折腾长期助手，最想解决的底层问题是什么。
我当时回答：“让 AI 更懂我算是核心的，就是想打造一个专属自己的 AI 助手这样。陪伴感是附带的，主线这个就算了，有时候 AI 跑偏了还要我来纠正。”
这话是真的，但太虚。
继续追问后，这个“更懂我”才被拆成更硬的东西：
  • 该读文件的时候读文件
  • 该确认的时候先确认
  • 不要把我的原话改坏
  • 不要把临时状态写成长期设定
  • 不要把所有的信息都塞进同一个文件
到这里，我才意识到，自己做的不是提示词工程（ Prompt Engineering），也不只是 上下文工程（Context Engineering）。
提示词工程解决的是：这一次，我怎么把话说清楚。
上下文工程解决的是：这一次之前，AI 应该知道哪些背景。
但长期协作里还有一层东西更要命：当 AI 开始读文件、改文件、总结原话、沉淀规则、推进项目时，它必须知道什么能做、什么要停、什么必须先问、什么不能改坏。
这一层，现在大家叫 Harness Engineering（大家都这么叫，没有中文名哈哈哈）。
Harness 不负责让 AI 表演“懂你”。它更像一套上工位前的安全带和夹具，让 AI 的能力被用在合适的位置上。
这也是我为什么宁愿折腾设定文件，也不满足于开箱即用。
WorkBuddy 省掉了很多维护成本，这点很有吸引力。但如果它只能完成当下对话，不能读取、尊重、执行我已经确认过的协作规则，那它再顺手，也只是临时工具。
真正能进入我工作流的 Agent，至少要过四道门槛：
  1. 能不能按已有规则工作，而不是每次重新调教。
  2. 能不能在高影响动作前停下来确认，而不是替我自作主张（OpenClaw爆出了太多安全案例了）。
  3. 能不能区分原始记录、阶段状态和长期设定，而不是把所有东西混成一团。
  4. 能不能在跑偏后接受纠偏，并把纠偏沉淀成下一次可用的规则（记忆和自我进化系统）。
这次最后的结果，是新建或调整了 6 份工具和规则文件，还把当前状态和 90 天框架放进 context/，不再让它们占用每次都要加载的永久设定。
所以，6300 多万 token 看起来很夸张，但它真正换来的不是一套 OpenClaw 配置。
OpenClaw 已经卸载了。以后我也可能继续换工具，继续测试 WorkBuddy，继续遇到新的 Agent 平台。
但我确认过的协作边界、写作禁区、日记规则、项目记录方式、支线收束原则，可以留下来。
工具可以替换，项目可以失败，但协作经验可以被抽出来。
以后我再测试一个新 AI 工具，不会只看它会不会聊天、会不会调用工具、会不会写代码。
我会先看它能不能接住我的 Harness。
如果接不住，它只是一个聪明工具。
如果接得住，它才有资格进入我的长期工作流。
这大概就是这轮设定整理最后给我的结论：
我不是在给 OpenClaw 补设定，是在给未来所有可能接入我工作流的 Agent，做一套属于自己的 Harness Engineering。