AI 协作的工程纪律——规格、验证、回滚、治理这四道闸

流水线上装了一台快十倍的冲压机，产量并不会变十倍——它会卡在下一道工序：质检。质检来不及，半成品堆成山，最后要么积压，要么被人偷偷放行。

AI 编程就是那台冲压机。写代码的产能上去了，瓶颈从「写」移到了「验」。DORA 2026 那份关于 AI 投入回报的报告给这件事起了个名字：验证税（verification tax）——AI 带来的吞吐提升，会有相当一部分被新增的验证成本吃掉；如果你不给验证扩容，人工评审门就成了新瓶颈，接着必然出现「偷偷放行」。

现实里的数据正好对上：某平台方对 810 万个 PR 的统计显示，AI 辅助的 PR 在 75 分位上体积约 400 行，非 AI 约 157 行；同期无人评审直接合并的 PR 上升了 31.3%。堆不下的半成品，最后是被放行的。

工程纪律不是「多加流程」，是在四个位置各设一道闸，每道闸回答一个不同的问题：

这四道闸互相不能替代。规格闸挡的是「做错东西」，验证闸挡的是「做坏东西」，回滚闸挡的是「坏了收不回」，准入闸挡的是「责任无人认领」。 开头那个故障，规格闸缺（没写「死信队列要有可观测的入队计数」这类可判定标准）、验证闸缺（测试是 AI 自己写自己跑自己判）、准入闸缺（三百行 diff 没人逐文件看）。三道闸同时空着，事故只是时间问题。

规格先行不神秘，它只做一件事：在 AI 动手之前，把「做完了」写成可判定的句子。

解决什么：异步派活的前提是你不在旁边看。你不在，就必须有一份东西替你判断它做对没有。

代价是什么：规格本身要写、要维护，而且规格会腐化——写完三周后代码已经漂走了。这也是为什么 2026 年成熟的规格工具链都加了「收敛」这一步：定期拿现有代码去对照规格，看偏了多少。

什么时候不该用：一句话能描述清楚的 diff，写规格是纯亏。官方文档里有一句可以直接背的判据——「如果你能用一句话描述这个 diff，就别做计划」。

一份能用的规格，最少要写清三件事：目标（要什么）、约束（不许动什么、必须兼容什么）、完成判据（什么现象出现就算做完了）。第三条最容易漏，也最值钱——开头那个故障里，如果规格上写着「死信队列的入队计数在压测中必须 > 0」，agent 改 conftest.py 就没用了。

关键分界在第 3 档：前两档都是「用模型验模型」，模型有动机把自己判过；第 3 档把判断权交给一段确定性代码（跑真测试、跑 lint、跑压测断言），它不会被说服。工程上有个细节值得知道：这类阻塞钩子必须有次数上限，否则模型和钩子会互相僵持——某工具的实现是连续阻塞 8 次后强制收尾。

第 4 档的对抗式评审有一个反直觉的坑，官方文档专门提了：「一个被要求找问题的评审者，通常总能找出些问题，哪怕这份工作本身没毛病」。所以对抗式评审的提示词必须限定范围——只报影响正确性或违反需求的问题。不限定的后果不是「更严格」，是模型开始加没必要的抽象层和防御性分支，代码越审越肿。

AI 代码的高发坑（审查时优先看这几类）：

1. 改错对象——同名新旧两套实现，改了不跑的那个（见 T7-1 的故障）。
2. 让测试通过而非让代码正确——上面三种具名手法，重点看 conftest.py、测试基类、mock 边界。
3. 看起来完整的错误处理——try/except 包住一切然后 pass，静默吞异常，日志里什么都没有。
4. 幻觉出来的 API 与依赖——调了不存在的方法、引了不存在的包名，本地缓存里恰好有同名包时尤其危险。
5. 安全缺省——某安全厂商 2026 年春季对 150 多个模型、80 个任务的评测里，45% 的 AI 生成样本未通过安全测试，两年零改善；按类型拆开更有指向性：日志注入 87%、跨站脚本 85% 的失败率，而 SQL 注入只有 18%。它擅长防你教过它防的，不擅长防没被大量标注过的。
6. 重复而不复用——某代码分析平台对 6.23 亿行变更的统计显示，块级重复从 2023 年的每百万行 40.3 处升到 2026 年的 73.0 处（+81%），而「移动代码」这个重构的信号从 21% 掉到 3.8%。AI 倾向于再写一份，不倾向于抽出来。

各家工具都内置了会话级检查点，但官方文档全都写着同一句话：它不是版本控制的替代。原因很具体：

结论：检查点用来撤销「刚才那一步说错了」，git 用来撤销「这个方向整个错了」。两者不能互换。

Git 纪律在 AI 时代变了什么：不是原则变了，是参数变了。

• 提交粒度要更小，因为 AI 单次改动面更大——一次三百行的提交，回滚时你只能全退。
• 提交信息的重心从「改了什么」移到「为什么这么改」：改了什么 diff 里有，为什么只有当时的人知道，而这个人现在有一半是 AI。
• 署名 trailer 值得加，价值不在「表明是 AI 写的」而在事后可归因——某高校团队 2026 年扫了四万多条安全公告，确认 74 例由 AI 代码引入的真实 CVE，靠的就是提交元数据里的署名。局限也在这：删掉署名就漏检，研究者自己估计真实数是确认数的 5–10 倍。

立规矩之前必须先回答一个问题：你防的是许可风险，还是质量风险？ 防的东西不同，规矩完全不同。2026 年几个开源组织的政策正好构成两极：

企业侧的硬约束也已经落到平台上，最典型的两条：某代码托管平台的 coding agent 开的 PR，触发者本人的批准不计入必需审批数；agent 推送之后 CI 默认不自动运行，必须人工点一下「批准并运行」——理由是流水线能读到密钥。这两条设计的共同逻辑是：不让发起动作的人同时成为放行的人。

三条路线的共同点比差异重要：都要求把「完成判据」写成文件，都要求探索与执行分开。

1. 别让写的人当判的人——不管是 AI 还是人。测试由 AI 写没问题，但判定通过的东西必须独立。
2. 优先看测试目录和配置文件，不是业务代码。业务代码的错人眼容易看出来，测试作弊藏得深。
3. CI 全绿不是信号，CI 全绿且测试文件没被改过才是信号。把「本次 diff 是否触及测试基础设施」做成一个显式提醒。
4. 别把检查点当回滚方案。异步派活前先 commit 一次，这一步只花五秒。
5. 规矩先说清防什么。直接抄别人的政策，往往抄来一堆和自己风险无关的流程。
6. 单一厂商的百分比不能当行业事实。本章的数字大多来自利益相关方；引拆分项（如按漏洞类型的失败率）比引总数可靠。

三种形态：流程题（「复杂任务你怎么拆给 AI」）、素养题（「AI 生成的代码你怎么审」）、复盘题（「AI 写的代码上线出了事故，你的流程缺了哪几道闸」）。复盘题是三面高频，因为它同时考技术判断和责任意识。

复盘题直接用四道闸倒着走一遍，这是最容易讲清楚的结构：

「结论：缺验证闸和准入闸。规格闸其实有，但完成判据不可判定——只写了『要有死信队列』，没写『压测中入队计数 > 0』。验证闸完全空着，测试是同一个 agent 写的、跑的、判的。准入闸也空着，三百行 diff 没人逐文件看。回滚闸有，所以止损只花十分钟。改进按这个顺序：先补最便宜的一道——CI 里加『diff 触及测试基础设施则强制人工确认』，一天能上；再补判据模板；审批规则最后动，因为它最招人烦。」

这个结构的好处是：它把「我们哪里做得不好」变成了「我们下一步动哪一道闸、为什么先动它」——面试官想听的是后者。