作者: Phodal Huang 2026年4月7日 16:45
过去大半年里，我一直在帮不同规模的团队落地 AI Coding。从最早的一两个人试点，到十几个人的团队尝试让 AI 参与日常交付，再到开始设计下一步的演进路径，我反复碰到同一个现象：试点阶段所有人都很兴奋——代码生成快，骨架搭得漂亮，连测试都能帮忙补上几条。但到了推广阶段，事情就开始走形。有人拿到 AI 生成的代码直接提交，跳过了评审；有人发现 AI 改了不该改的接口，但 PR 已经合进去了；还有人干脆把 AI 的输出当半成品，自己手动重写一遍，等于白跑一趟。
真正的问题不是模型不够强，而是团队还不知道怎么把 AI 放进自己的工程体系里。试点靠个人能力兜底，规模化必须靠系统兜底。大多数团队在试点时只验证了"AI 能不能写代码"，却没有验证"AI 的产出如何被工程体系接纳"。
这也不是我一个人的观察。把 OpenAI 的 Codex 文档和 Claude Code 的 memory 文档放在一起看，会发现两家公司最后都在强化同一类东西——规则文件、持久记忆、结构化状态，以及一套能把 agent 拉回工程边界的外部机制。AI Coding 的瓶颈从来不在生成端，而在接收端。代码生成出来之后，它是不是在边界内生成的？能不能沿着正确范围收敛？是否经过了验证？最后能不能进入评审与放行体系？这些问题不是模型能回答的，而是工程系统必须回答的。([OpenAI Developers][1])
所以，我们要建设的不是一条"让 AI 写更多代码"的路径，而是一条"让 AI 在工程体系里稳定完成交付"的路径。Rule、Spec、Loop、Harness 不是四个并列摆放的能力模块，而是一条前后相依、逐层收紧控制面的建设路线——不要乱来、这次只做什么、如何持续收敛、结果凭什么被接纳进生产。每一层都在给下一层提供约束条件。
很多团队一开始最关心的，都是 AI 能做什么。但真实项目里，最昂贵的错误往往不是代码写得不漂亮，而是越过边界、误改契约、扩散变更面，或者在不该结束的时候宣布任务完成。
这也是为什么 Rule 必须排在第一层。OpenAI 的文档里，AGENTS.md 不是普通说明文件，而是 Codex
启动时就会读取的持久项目指导；它支持从全局到项目再到子目录的分层覆盖，官方还明确建议把它写小，只在发现重复错误之后再追加规则。Anthropic
则把 CLAUDE.md 和 auto memory 定义为每次会话都会加载的上下文，同时提醒你：这些东西本质上是
context，而不是强约束。把两边放在一起看，一个结论其实很清楚：规则文件只是入口，不是护栏；真正的护栏，必须由
test、lint、build、schema check、review policy 这类外部信号接管。([OpenAI Developers][1])
所以，Rule 的设计重点不应该是"给 AI 更多背景"，而应该是先把团队纪律写成默认边界。先写 NEVER 和 DO NOT，再写建议；先约束高代价错误，再讨论更优实现；根目录只放最小入口，具体规则尽量下沉到更近的目录或 skill 里；一旦同一种错误重复出现，就别再靠口头提醒，而是把它回写进规则文件和校验链路里。
换句话说，Rule 解决的不是让 agent 更聪明，而是让它先学会不越界。
仅有 Rule 还不够。因为边界清楚，并不等于目标清楚。很多 AI Coding 失控，不是因为模型没理解需求，而是因为需求本身没有被整理成一个边界明确、范围可控、结果可验证的交付对象。于是 AI 很自然地开始扩写任务：修一个提示，顺手重构流程；补一个状态，顺手改掉契约；写一个 happy path，顺手把整个模块"整理"一遍。
所以，Spec 不是更长的 prompt，而是变更范围纪律。OpenAI 在多小时任务的文档里，甚至把 PLANS.md 写成一种 living
document：要求里程碑、进度、可观察结果、验证命令、自包含上下文都写清楚，再让 agent 沿着这些检查点推进。这个方向非常值得注意，因为它说明真正有用的
Spec，不是"写更多背景"，而是把一次模糊意图压缩成一次可执行、可审查、可验证的变更。([OpenAI Developers][2])
在我看来，一份有效的 Spec 至少要回答五件事：这次要解决什么，这次不解决什么，允许改哪些 surface，哪些 contract 不能动，怎样才算完成。它不需要写成大部头，更不应该演变成新的文档负担。它真正的价值，在于把范围钉住，把完成条件前置，把" 也许顺手改一下"的冲动提前消灭掉。
Rule 解决"别乱来"，Spec 解决"别跑偏"。这就是它们必须前后相接的原因。
有了 Rule 和 Spec，AI 才算拿到了边界和靶心。但即便如此，执行过程依然会出错。真正决定它能不能在工程里持续工作的，不是一次回答质量，而是有没有一个 Loop，把"读取上下文—做最小改动—运行外部验证—记录状态—进入下一轮"变成系统动作。
这一步并不是抽象想象。Vercel 的 ralph-loop-agent 把 continuous AI agent loops 说得很直白：agent
工作，评估器检查结果，如果还没完成，就继续下一轮。OpenAI 近期总结 Codex 的长任务经验时，也把 loop 明确写成 plan、edit code、run
tools、observe results、repair failures、update docs/status、repeat，并强调长任务之所以更可靠，不在于一个更长的 prompt，而在于
harness 提供了结构化上下文和清晰的 "done when" 例程。([GitHub][3])
这背后有三个动作特别关键。第一，每一轮改动都必须足够小，小到能被验证器快速裁决；第二，状态必须外置到文件、日志、Git 历史、计划文档里，而不是寄希望于模型"记得住"；第三，只要检查失败，就要停下来修，而不是带着失败继续往前滚。否则，Loop 很容易从" 持续收敛"退化成"持续漂移"。
所以，Loop 真正优化的不是生成质量，而是收敛效率。没有 Spec，Loop 只是更有耐心的试错；有了 Spec，Loop 才会变成围绕验收条件持续逼近的执行闭环。
当 Rule、Spec、Loop 三层建立起来之后，AI 已经不只是"会写代码"，而是在一个受控环境里推进任务了。但要真正完成落地，还差最后一层：Harness。
Harness 不是某一个具体工具，而是一整套把 AI 产出纳入验证、提交、评审、放行与追责体系的工程外骨骼。Anthropic 在 2026 年甚至直接把
harness design 称为长时自主编码前沿表现的关键变量，并把任务分块、结构化交接、独立 evaluator、明确评分标准放到了体系中心。OpenAI
这边也把 testing、checking、review 串成一个可靠性闭环，甚至建议把 code_review.md 和 AGENTS.md 绑定起来，让 review
规则成为仓库级约束。([Anthropic][4])
这说明一件事：Harness 的任务，从来不是让 AI 更自由，而是让组织更放心。它要解决的，不是"AI 能不能写出代码"，而是" 这些代码为什么值得被信任"。
在工程里，这一层通常会表现为一组组合机制：Contract 负责守住 schema、types、interfaces 这类共享边界；Hooks 把 lint、typecheck、tests、pre-commit 之类的检查前移；Fitness 和 CI 负责仓库级裁决，包括风险分级、人工 review、是否允许放行。前面三层如果没有建立起来，Harness 最多只能在末端捡垃圾；前面三层如果已经成立，Harness 才真正具备组织级治理意义。
换句话说，Harness 回答的不是 AI 多强，而是这次变更为什么足够可信。
这四层最容易被误解成一张能力清单，但它们其实有严格的依赖关系。
没有 Rule，Spec 只是在给一个无边界的 agent 提需求。 没有 Spec，Loop 只是在把错误更高效地放大。 没有 Loop，Harness 只能在 PR 和 CI 末端被动兜底。 只有先把默认行为收住，再把单次变更钉住，再把执行过程闭环起来，最后把结果接入质量与放行体系，AI Coding 才会从"偶尔能用"走向" 稳定交付"。
这也是我更愿意把这条路线理解成"控制面逐层外扩"的原因。Rule 是最内层，解决 agent 的默认行为；Spec 再往外一层，解决单次变更的范围纪律；Loop 把静态约束变成动态执行机制；Harness 则把前面三层汇总进组织治理。它不是四个独立模块，而是一条成熟度路线。
AI Coding 的下一阶段，拼的不会只是模型能力，而是谁更早把工程经验转成机器可参与、组织可裁决的交付系统。
Rule，让 AI 先学会不越界。 Spec，让 AI 明确这次只该做什么。 Loop，让 AI 不能再把"我觉得差不多了"当成完成。 Harness，让 AI 的结果真正进入验证、评审与放行体系。
从 Rule 到 Harness，我们建设的不是一个更聪明的代码助手，而是一套能在工程边界内稳定工作的交付系统。真正拉开差距的，最后也不会只是模型，而会是谁更早把这套交付系统建出来。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
