最近打开任何一个 AI 社群，满屏都是 Harness。
"缰绳工程"、"马鞍比马重要"、"2026 年比的是谁的缸造得好"——概念已经被讲烂了。
但我读完 Mitchell Hashimoto、OpenAI 和 Anthropic 的原文之后，发现一个问题：
大多数文章在解释 Harness 是什么，很少有人回答一个更实际的问题——读完之后，我到底该做什么？
在 CLAUDE.md 里加一行"不要做XX"就算 Harness Engineering 了？
如果这么简单，OpenAI 为什么要 3 个工程师花 5 个月专门干这件事？
我让 AI 助理把三家公司的原文拆碎了看。看完之后我意识到：Harness 不是一个东西，是一条路。
而这条路有三步，大多数人只走了第一步。
一、第一步：写规则
Terraform 和 Vagrant 的创始人 Mitchell Hashimoto 今年 2 月写了一篇文章，讲自己从 AI 怀疑者变成"缰绳工程师"的过程。
他给 Harness Engineering 下了一个很直白的定义：
"Anytime you find an Agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
每次 AI 犯错，你都花时间建一个机制，让它永远不再犯同类错误。
他说 Harness 有两种形态，
第一种是文字规则：写进 AGENTS.md（或 CLAUDE.md）的行为约束。
他举了自己的开源项目 Ghostty 的例子——那个文件里的每一行，都对应着一次 AI 犯过的错。
这是最简单的起步方式。
AI 编造了一个你没经历过的故事？加一条"禁止编造困境"。
AI 总是在不该改的地方改代码？加一条"只改指定文件"。
我自己的 CLAUDE.md 里就有这样一条规则：
"写作前必须确认事实立场，不确定就问，禁止编造困境。"
这条规则是某次 AI 帮我写文章时编造了一段我没经历过的困境之后加上的。
加完之后，这个问题再也没出现过。
这就是第一步。简单、有效、立竿见影。
但如果你停在这一步，会遇到一个天花板。
二、第二步：造工具
Mitchell 说 Harness 的第二种形态是自动化工具——脚本、linter、测试。
换句话说，不是靠"跟 AI 说一声"来约束它，而是造一个工具让机器自动检查。
OpenAI 的团队把这件事做到了极致。
他们做了一个实验：3 个工程师，5 个月，整个项目不允许任何人手写代码。结果合并了 1500 个 PR，产出约 100 万行代码，做出了一个有真实用户在用的产品。
但最值得关注的不是结果，而是过程。
工程师 Ryan Lopopolo 在文章里写道：
"Early progress was slower than we expected, not because Codex was incapable, but because the environment was underspecified."
早期进展比预期慢，不是因为 AI 不行，而是因为环境缺乏定义——AI 缺少完成任务所需的工具和结构。
他们后来做了什么？
给 AI 造工具。
让 AI 能启动应用、截图、驱动浏览器来验证自己的工作。
让 AI 能查询日志和监控指标来判断性能是否达标。
让 AI 有一整套本地可观测性栈来调试问题。
工程师的工作，从"写代码"变成了"让 AI 能验证自己的代码"。
他们还踩了一个很多人正在踩的坑：一开始把所有规则塞进一个大 AGENTS.md 文件。失败了。
"Give Codex a map, not a 1,000-page instruction manual."
给 AI 一张地图，不是一本说明书。
原因不难理解：上下文窗口是有限的。规则占的空间多了，任务能用的空间就少了。
更糟的是大文件会快速腐烂——规则越来越多，没人维护，有些已经过时了，但 AI 不知道哪条还有效。
他们最后的做法：AGENTS.md 只做目录，大约 100 行。真正的规则住在结构化的文档体系里，AI 按需读取。
这就是从第一步到第二步的跃迁：从"写规则"到"造工具"。
规则是被动的——AI 读到了才生效，读不到就没用。
工具是主动的——不管 AI 读没读到，工具会自动检查、自动报错、自动拦截。
我自己在第二步上也做了一些事。
我的 skills 目录里有几十个 skill 文件——每个 skill 是一套完整的工作流指令，AI 每次执行同类任务时自动加载。
我不需要每次重新教它怎么写文章、怎么做解读、怎么生成卡片。
教一次，永久复用。
我的 hooks 配置，让 AI 在每次对话开始时自动读取必要的上下文。
我的内容系统里有风格定义文件，把"画伞应该怎么写"编码成了结构化的约束。
这些都是工具，不是规则。它们不需要我每次提醒 AI "记得看一下"——它们已经嵌入了环境。
但第二步还有一个盲区。
三、第三步：分离评估
Anthropic 的工程师 Prithvi Rajasekaran 发现了一个底层问题：
让 AI 评估自己的产出，它永远会给自己打高分。
"Tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work."
让一个独立的评估器变得苛刻，远比让生成器自我批评容易得多。
这不是偶尔发生的事，是系统性的偏差。即使在有客观标准的任务上（比如代码能不能跑通），AI 自我评估时依然倾向于给自己开绿灯。
在主观任务上（比如设计好不好看、文章写得好不好），这个问题更严重——AI 会自信地说"写得很好"，即使人类一眼就能看出是平庸之作。
Anthropic 的解法借鉴了 GAN（生成对抗网络）的思路：把生成和评估分开。
一个 AI 负责做事（generator），另一个独立的 AI 负责打分（evaluator）。
- evaluator 用 Playwright 实际操作产品——点击、截图、检查功能——然后给出评分和具体的改进意见。
- generator 根据这些反馈迭代。
结果：同样的任务，加上 evaluator 之后，产出质量有明显提升。
一个 4 分钟生成的网页和一个经过 15 轮评估迭代的网页，差距一目了然。
这就是第三步：不只是给 AI 规则和工具，还要给它一个独立的裁判。
坦白说，我还没做到这一步。我目前让 AI 写完东西后"自己检查一下"，它总是说"写得不错"——现在我知道了，这不是它在敷衍我，是自我评估天然带有正向偏差。
这是读完 Anthropic 文章之后最大的收获：下一步要在工作流中引入独立的评估环节。
你现在在哪一步？
回到开头的问题：读完 Harness 的文章，我们到底该做什么？
如果你还没开始：找出一个 AI 反复犯的错，写一条永久规则。
这是第一步，5 分钟就能做。
如果你已经有一堆规则了：问自己，这些规则是靠 AI "读到"才生效的，还是已经变成了自动运行的工具？
如果是前者，选一条最重要的规则，把它变成一个脚本、一个 skill 文件、或者一个自动化检查。
如果你已经有了规则和工具：试试让一个独立的 AI 来评估另一个 AI 的产出，而不是让同一个 AI 自己检查自己。
Harness 不是一个你某天"建完了"的东西。
它是一条路，每走一步，你和 AI 的协作效率就往上抬一个台阶。
