先讲个翻车现场。

前阵子让 AI 规划一个小任务。DESIGN 里我明明只写了 3 条验收标准，它生成的 PLAN 里却堂而皇之地写着「4 条验收标准全部满足」——更离谱的是，我这个人类，居然也签字点过了。

模型没报错、没崩、没道歉，就是把「3」悄悄变成了「4」，然后一路绿灯。事后复盘才看清，这是多 Agent 开发里最阴的一种问题：工件之间悄悄漂移，谁都没发现，最后人肉验收也没拦住。

问题不在某个模型，在迭代规律

折腾挺久，踩的坑翻来覆去就几个：

• AI 写完代码说「我检查过了，没问题」——自己审自己，等于没审。
• 一个会话聊几十轮，越聊越偏，还舍不得丢上下文。
• 审查打回 → 改 → 又打回 → 再改，无限补丁，没人停下来问「是不是方案本身就错了」。
• 三家模型都说「没问题」，代码跑起来就是不对——共识代替了证据。

根子就一句：我们老想着给 AI 定角色（谁设计、谁写、谁审），却没把迭代的规律写清楚。 角色是死的，循环才是活的。

所以有了 dev-loop：一份「宪法 + Playbook」的 Skill。核心一句话——

规范化开发循环，而不是规范化某个 AI。模型只是插槽，循环才是主体。

核心机制（挑重点说）

状态机很简单：DESIGN → PLAN → IMPLEMENT → VERIFY → TRIAL → DONE，异常就两个 BLOCKED（等人）和 RETHINK（回根因）。

失败路由是我觉得最值钱的部分——错在哪就回到哪，不搞「无脑再改一次」：

失败类型	判定	回到
实现错	代码没按方案做	IMPLEMENT
计划错	方案漏了东西	PLAN
设计错	架构假设错了	DESIGN
需求错	目标本身有问题	人

再加一条硬规矩：同类失败连续两次，强制 RETHINK，停手回根因，不许继续打补丁。

工件契约：Agent 之间交接的是工件（DESIGN / PLAN / RESULT / EXPERT_PACKET），不是聊天记录。每个专家进来都是 fresh context + 一份有界工件，从根上治「上下文越滚越偏」。

人只守 4 道门：方向变了、高风险执行、要烧稀缺额度、最终体验——这 4 个问一下，其余（改哪个文件、跑什么命令、怎么降级）一律不烦人。

两道从事故里长出来的硬防线：

1. 验收标准必须带稳定编号（AC1/AC2/...），规划器不得增删改。开头那个「3 变 4」的事故，现在被做成脚本里一道确定性校验——DESIGN 的 AC 集合和 PLAN 对不上，直接 exit 2。
2. 规划器只读，由 runtime 强制，不是靠 prompt 嘱咐。Codex 用 --sandbox read-only，Claude 用 --bare --tools=，写不了就是写不了。

为什么可信

因为规则不是「我觉得该这样」，是从真实翻车里长出来的。那个 3 AC → 4 AC 的事故原件，原样躺在仓库的 cases/acceptance-drift/ 里当回归样本。

仓库和参与

https://github.com/1263-ux/real-ai-engineering

刚起步，里面就两个东西（dev-loop 和 clean）。如果你也在被这些问题折腾，拿去用；发现问题开 Issue，有想法直接 PR。尤其「在你环境下会出问题」这类反馈，比夸我有用。