别被「Harness」唬住——它就是软件工程的旧地图，套在了 AI 的新大陆上
一个新词引发的既视感
最近 AI 编程圈冒出一个高频词：Harness。
大意是说，AI Coding Agent 太野了，得给它套个缰绳——用规则约束、用流程管控、用自动化校验，不让它乱来。
第一次看到这个词的时候，我有一种强烈的既视感。想了三秒钟，反应过来了——这不就是我们做了几十年的那些事吗？
Design review。Code review。CI/CD。自动化测试。Lint 检查。Coding standards。
你把"AI Agent"四个字换成"新来的初级工程师"，上面这段话完全不违和。
换句话说：Harness 不是什么新发明。它是软件工程几十年攒下来的老规矩，换了一个新对象。
但问题没这么简单。如果只是"对象换了"，那确实没啥好聊的。真用起来你会发现——这些老规矩套在 AI 身上，有些地方出奇地好用，有些地方又出奇地不好用。
这篇文章把两件事一起聊清楚：它为什么就是旧地图（正面），以及这张旧地图在新大陆上哪里好用、哪里不够用（反面）。
旧地图：我们怎么管人的
在 AI 写代码之前，软件工程的核心矛盾一直是：怎么让一群人写出不乱套的代码？
答案是一层一层往上摞的保障机制：
还没写代码呢——Design review。 架构师或者 Tech Lead 过一遍你的设计文档，看思路对不对、边界清不清晰。这一步卡住了大量"方向就错了"的问题。
写完了，没合入——Code review。 同事看你的 PR，挑逻辑问题、命名问题、架构问题。这一层在 Google 被证明是消灭 bug 最有效的手段之一。
合入了，没上线——CI/CD。 自动跑构建、跑测试、跑 lint、跑安全扫描。任何一项挂了，合入按钮就是灰的。这一层把"低级错误逃逸到线上"的概率压到极低。
上线了——监控 & 告警。 最后一层，出了问题能发现、能回滚。
这四层，本质上都在干同一件事：在产出物进入下一阶段之前，加一道校验。 校验的对象是人——人的设计、人的代码、人的配置。
新大陆：同一个套路，换了对象
现在 AI 开始写代码了。你打开 pi 或者 Cursor，说一句话，它哗哗哗生成几百行。
然后你盯着屏幕想：这就合入了？不审一下吗？
审，当然要审。但审法不一样了。以前的 code review 是 peer review——两个水平差不多的工程师互相看代码。现在的 AI review 更像是 supervisor review——一个人类盯着一个干活飞快、但偶尔犯浑的下属。
但好在，那四层保障机制，一层都没有过时。只是每层的实现方式变了：
| 保障层 | 对人的时候 | 对 AI 的时候 |
|---|---|---|
| Design review | 设计文档评审 | Prompt / 任务描述的审阅（比如写好 AGENTS.md） |
| Code review | 同事审 PR | 人类审 AI 生成的 diff |
| CI/CD | 自动构建 + 测试 + lint | 完全一样，同一套流水线 |
| 自动化测试 | 人写测试 | AI 写测试，或测试验证 AI 的输出 |
| Coding standards | 团队约定 + ESLint | System prompt 里的约束规则 |
CI 管线不知道管道那头是谁。它只管 push 上来的代码能不能过 build、能不能过 test、能不能过 lint。是不是 AI 写的，它根本不关心。
好的工程实践是抽象层级的，对生产者和生产方式不敏感——这是旧地图在新大陆上仍然好用的根本原因。
但这张旧地图，有三个地方需要更新
如果只是"对象变了"，那到这里就写完了。但有三件事，在 AI 时代确实不一样了。
第一：约束必须显式编码了。 管人的时候，大量约束靠"软机制"——不好意思写烂代码、团队文化熏陶、默契。AI 不吃这一套。你跟它讲默契，它给你讲概率分布。对 AI 的约束必须写死在 system prompt 里、写在项目规则文件里。某种程度上，AI 在逼我们做更好的工程师。
第二：速度不对称出现了。 人写代码和审代码的速度大概是匹配的，你写一天，同事审半小时。AI 几秒钟几百行，审代码的还是人。瓶颈从"生产"转移到了"审阅"，人类成了流程里最慢的环节。
第三：隐喻变了。 以前叫 guardrails（护栏）——被动的，你偏了它接你一把。现在叫 harness（缰绳）——主动的，你一直在拉、一直在校正方向。我们从"让它跑、出事了我兜着"，变成了"我拽着它一起跑"。
好了，以上是"它就是旧地图"的部分。下面聊更实际的问题——这张旧地图套在 AI 身上，哪里特别好用，哪里不够用？
换句话说：你每天打开终端、让 AI 写代码的时候，是该信那份 AGENTS.md 规则文件，还是该老老实实自己再看一遍？
我的回答是：各赢一半。
正面：AGENTS.md 规则约束赢在哪
1. 即时性：在生成时就拦截，不是事后验尸
传统流程：写代码 → 提 PR → 等 review → 改 → 合入。问题在第一步就产生了，第三步才发现。
规则约束在生成时就介入。我的 AGENTS.md 里写了"脚本必须打进度日志、支持断点续跑、提供 --dry-run"，AI 在生成脚本的时候就已经带着这些约束了。它不会先生成一个没日志的版本、等 code review 被打回来再改——它一步到位。
这是质的区别。 传统保障是"事后检查"，规则约束是"事前塑形"。
2. 绝对一致性：不会因为周五下午就放水
人类 reviewer：周二上午能看出十个问题，周五下午可能只看出三个。规则不会累，不会心情不好，每一次都以完全相同的标准执行。我 AGENTS.md 里写的"不得静默 || true 吞错"——AI 永远不会在某一次调用里忘了这条。说实话，我自己 review 代码都不一定每次都能注意到。
3. 零边际成本：一份规则管一万次调用
一个 senior engineer 一天能 review 几百行。AGENTS.md 写一次，以后每一次调用都受它约束，增量成本是零。这意味着你可以把规则写得极其详细、覆盖极其多的场景——在传统工程里你敢跟每个同事说"请注意第 47 条：日志文件名必须包含 ISO8601 时间戳"吗？在 AGENTS.md 里，你可以。
规则约束把"工程规范的颗粒度"推到了人力不可能达到的精细程度。
4. 永不丢失：知识不会跟着人走
老工程师脑子里存着大量隐性知识——边界条件、踩过的坑、某个库的奇怪行为。人离职那天，知识也跟着走了。AGENTS.md 不会离职。
5. 强制执行"说不清楚就别写"
传统工程里大量约束靠默契。"这个函数不要太长"——多长？"代码要清晰"——什么叫清晰？AGENTS.md 逼你把所有约束显式化。你不能写"脚本要写好"，你必须写"每个关键步骤开始与结束都打一行日志，带 ISO8601 时间戳、步骤名、关键输入"。
AGENTS.md 是一面镜子——你写不清楚的地方，就是你其实也没想清楚的地方。
反面：AGENTS.md 规则约束输在哪
1. 只能覆盖"已知的已知"
这是最根本的局限。规则只能约束你已经想到的事情——基于过去的经验、踩过的坑、见过的烂代码。
但最危险的问题往往是没预料到的。那个奇怪的并发条件、那个隐蔽的安全漏洞——规则里没有对应条目，因为你在写规则时根本不知道它们存在。
传统 code review 的价值，很大程度上就在于发现这些"规则覆盖不到的问题"。一个有经验的 reviewer 扫一眼代码，脑子里自动浮现"这个地方不对劲"——不是因为对照了某条规则，而是因为他见过类似的场景。
人类判断力对机械化规则的根本优势：人能发现"未知的未知"。
2. 没有"味道"判断
代码有 smell——"味道不对"。这玩意儿没法写成规则。
"这个抽象层级不对"——怎么写进 AGENTS.md？"这个模块知道的太多了"——怎么量化？"这个设计之后一定会出问题"——基于什么指标？
AI 可以检查"这个函数超过 50 行了"，但它无法判断"这个函数虽然短但做了三件不相关的事"。规则擅长机械性检查，人类擅长结构性判断。两者的交集很小。
3. 可以被"字面合规"绕过
规则写得很死，聪明的执行者会找到"技术上没犯规、精神上完全背离"的做法。你写"所有脚本必须打印 SUMMARY 行"，AI 打了 SUMMARY: ok=all fail=0——合规，毫无信息量。
人类 reviewer 看到会皱眉。自动化检查只会看——嗯，有 SUMMARY 行，通过。
规则缺乏"意图理解"能力。它看到的是形式，看不到精神。
4. 没有社交压力机制
传统 code review 有隐藏功能——社交约束。你知道同事会看你的代码，提交前自己先查一遍。不是因为有规则，是因为不好意思。
AI 没有羞耻心。它不会因为"上一段代码被 reviewer 说了"而更小心。被约束的对象从人变成 AI 之后，那条隐藏的"自检防线"消失了。
5. 不能自我进化
传统工程会自我改进：这次 review 发现了常见问题 → 下次 team 开会 → 所有人都注意了。这是一个持续学习的循环。
AGENTS.md 不会自己进化。它只有在人类发现新问题、手动更新规则之后才会变好。但问题是——规则的进化依赖人类发现新问题，而人类如果过度依赖规则、放松了判断力，就发现不了新问题。
这就形成了一个死循环：规则越好，人越懒；人越懒，规则越难进化。 这条是我觉得最需要警惕的。
一张表总结
| 维度 | AGENTS.md / 规则约束 | 传统工程保障（review / CI / 测试） |
|---|---|---|
| 执行时机 | 生成时（事前塑形） | 提交后（事后检查） |
| 一致性 | ⭐⭐⭐ 完美一致 | ⭐ 因人因时而异 |
| 边际成本 | ⭐⭐⭐ 几乎为零 | ⭐ 随代码量线性增长 |
| 覆盖范围 | ⭐ 只有"已知的已知" | ⭐⭐⭐ 能发现未知问题 |
| 结构性判断 | ⭐ 只能机械检查 | ⭐⭐⭐ 能识别设计问题 |
| 灵活应变 | ⭐ 刚性，不会变通 | ⭐⭐⭐ 能按上下文取舍 |
| 社交约束 | ⭐ 完全不存在 | ⭐⭐⭐ 强大的自检动力 |
| 自我进化 | ⭐ 需要人工更新 | ⭐⭐⭐ 团队持续学习 |
| 知识留存 | ⭐⭐⭐ 永不丢失 | ⭐ 人走知识走 |
结论：不是替代，是分层
这张表看完，规律很清楚——AGENTS.md 强的地方，恰好是传统保障弱的地方。反过来也一样。
它们不是竞争关系，是互补关系。一个合理的工程保障体系应该分三层：
-
底层：机械化规则（AGENTS.md / lint / CI 检查）——管那些不需要判断、只需要"记住"的事。日志格式、命名规范、禁止的 API、必须的 flag。这些活不该占用人的脑子，让规则去管。
-
中层：自动化验证（测试 / 构建 / 安全扫描）——管那些能形式化验证的事。功能对不对、性能合不合格。这些活不该靠肉眼，让机器去跑。
-
顶层：人类判断（code review / design review）——管那些需要经验、直觉、业务理解的事。设计合不合理、抽象对不对、有没有埋下未来的坑。这些活不该交给规则，让人去做。
规则不是来取代人的。规则是来解放人的——把机械检查的负担从人身上卸下来，让人把精力集中在只有人能做好的判断上。
如果你的 AGENTS.md 写完之后，你觉得自己可以少看代码了——那你就用错了。你应该觉得自己的 review 质量更高了，因为你不再需要分心去检查"日志格式对不对""有没有用全局 pip install""错误处理有没有吞错"这些破事了。
好的规则让你把注意力放到更重要的东西上，而不是让你把注意力收回来。
那些在 AI 时代显得游刃有余的工程师，不是因为学了什么"AI 工具使用技巧"，而是因为他们本来就有扎实的工程素养。他们知道一个靠谱的软件交付流程长什么样，然后把 AI 嵌入进去。AI 对他们来说只是一个新的"生产者"，不是一个新的"范式"。
所以，如果你看到满屏的 Harness、Guardrails、AI Engineering 觉得有点慌——不用慌。你掌握的工程基本功，在新大陆上照样好用。你只需要把那张旧地图拿出来，对着新的地形，重新标几个点。
地图没变。地变了。
如果觉得有用，点个在看，转发给你的 team——尤其是那个在纠结"有了 AI 还要不要 code review"的同事。
有什么想法欢迎在评论区聊聊：你最近看到哪些"新瓶装旧酒"的 AI 概念？你的团队在用什么规则文件？你觉得哪些东西适合写进规则，哪些绝对不能交给规则？