🔧 AI 知识库
⚡ 编程工程方法论2026-06-30

从 Rule、Spec 到 Harness：AI Coding 的渐进式建设路径

原文链接

从 Rule、Spec 到 Harness：AI Coding 的渐进式建设路径

原文链接：https://mp.weixin.qq.com/s/UCh2bPzMZjNBMBCCJysuNw 作者：Phodal 发布时间：2026年4月7日

摘要

Phodal 基于帮多个团队落地 AI Coding 的经验，提出四层递进的建设路线——Rule（别乱来）→ Spec（这次只做什么）→ Loop（如何持续收敛）→ Harness（凭什么被接纳进生产）。核心观点：AI Coding 的瓶颈不在生成端，在接收端。真正拉开差距的不是模型能力，而是谁更早把工程经验转成机器可参与、组织可裁决的交付系统。

问题：试点和规模化的鸿沟

试点靠个人能力兜底，规模化必须靠系统兜底。大多数团队只验证了"AI 能不能写代码"，没验证"AI 的产出如何被工程体系接纳"。

典型事故：

  • AI 生成的代码跳过评审直接提交
  • AI 改了不该改的接口但 PR 已经合入
  • 把 AI 输出当半成品手动重写，等于白跑

OpenAI 和 Anthropic 最后都强化同一类东西——规则文件、持久记忆、结构化状态、把 agent 拉回工程边界的外部机制。

第一层：Rule — 先把"不要乱来"写成机器边界

核心原则

  • 先写 NEVER 和 DO NOT，再写建议
  • 先约束高代价错误，再讨论更优实现
  • 根目录只放最小入口，具体规则下沉到子目录或 skill 里
  • 同一种错误重复出现 → 回写进规则文件和校验链路

关键认识

规则文件只是入口，不是护栏。真正的护栏必须由 test、lint、build、schema check、review policy 这类外部信号接管。

Rule 解决的不是让 agent 更聪明，而是让它先学会不越界。

第二层：Spec — 把"想做什么"收敛成一次可执行的变更

为什么需要 Spec

很多 AI Coding 失控不是因为模型没理解需求，而是需求本身没有被整理成边界明确、范围可控、结果可验证的交付对象。AI 会自然地扩写任务——修一个提示顺手重构流程、补一个状态顺手改掉契约。

一份有效的 Spec 回答五件事

  1. 这次要解决什么
  2. 这次不解决什么
  3. 允许改哪些 surface
  4. 哪些 contract 不能动
  5. 怎样才算完成

关键认识

Spec 不是更长的 prompt，而是变更范围纪律。 不需要写成大部头，真正的价值在于把范围钉住、把完成条件前置、把"顺手改一下"的冲动提前消灭。

OpenAI 甚至把 PLANS.md 写成 living document，要求里程碑、可观察结果、验证命令、自包含上下文都写清楚。

Rule 解决"别乱来"，Spec 解决"别跑偏"。

第三层：Loop — 把一次性生成改造成可收敛的执行闭环

核心流程

"读取上下文 → 做最小改动 → 运行外部验证 → 记录状态 → 进入下一轮"

Vercel 的 ralph-loop-agent：agent 工作 → 评估器检查 → 没完成继续下一轮。OpenAI 总结的 Codex 长任务经验：plan → edit code → run tools → observe results → repair failures → update docs/status → repeat。

三个关键动作

  1. 每一轮改动必须足够小，小到能被验证器快速裁决
  2. 状态必须外置（文件、日志、Git 历史、计划文档），别指望模型"记得住"
  3. 检查失败就停下来修，别带着失败继续滚

关键认识

Loop 真正优化的不是生成质量，而是收敛效率。没有 Spec，Loop 只是更有耐心的试错；有了 Spec，Loop 才变成围绕验收条件持续逼近的执行闭环。

第四层：Harness — 把 AI 放回工程治理，而不是直接推向生产

定义

不是某一个具体工具，而是一整套把 AI 产出纳入验证、提交、评审、放行与追责体系的工程外骨骼。

Anthropic 把 harness design 称为"长时自主编码前沿表现的关键变量"。OpenAI 把 testing、checking、review 串成一个可靠性闭环。

核心能力

  • Contract：守住 schema、types、interfaces 等共享边界
  • Hooks：lint、typecheck、tests、pre-commit 等检查前移
  • Fitness + CI：仓库级裁决（风险分级、人工 review、是否放行）

关键认识

前面三层没建起来，Harness 只能在末端捡垃圾；前面三层成立，Harness 才具备组织级治理意义。

Harness 回答的不是 AI 多强，而是这次变更为什么足够可信。

为什么必须是递进关系（不是并列）

Rule（内层） → Spec → Loop → Harness（外层）
控制面逐层外扩
  • 没有 Rule，Spec 只是在给无边界的 agent 提需求
  • 没有 Spec，Loop 只是在把错误更高效地放大
  • 没有 Loop，Harness 只能在 PR 和 CI 末端被动兜底

只有先把默认行为收住 → 再把单次变更钉住 → 再把执行过程闭环 → 最后把结果接入质量与放行体系，AI Coding 才会从"偶尔能用"走向"稳定交付"。

结语

AI Coding 的下一阶段拼的不是模型能力，而是谁更早把工程经验转成机器可参与、组织可裁决的交付系统。

四层递进一句话：

  • Rule — 让 AI 先学会不越界
  • Spec — 明确这次只该做什么
  • Loop — 不能把"我觉得差不多了"当成完成
  • Harness — 结果真正进入验证、评审与放行体系

真正拉开差距的，不会是模型，会是谁更早把这套交付系统建出来。