AI 原生研发：产物链、门禁与度量

去年我们把 AI 编程工具装进了研发团队。三个月后做交付盘点，结论不好看：工具用得不少，交付没有变快。原因不是模型不行，是我们把它当成了"更快的打字机"，而流程本身一寸没动。

后来做了一次工单实况抽样，才找到真正的病灶。在那批新建工单里，真正的新功能开发只占 16%：说不清要什么占 38%，缺陷修复 25%，配置调整 12%，数据操作 10%。同时 46% 的工单描述是空的，故事点填写率 0%。

这组数字把话说死了：瓶颈不在"AI 会不会写代码"，在于八成以上的工作根本不经过新功能开发。用 AI 提速，先得让这些工作变成可交接、可验证的输入，否则你只是让"说不清的需求"更快地变成了"看不懂的代码"。

下面这套东西，是我们把 Anthropic 的 AI-native SDLC playbook 拆开、对着自己的存量系统重写之后的结论。它不是最佳实践清单，是踩过之后留下的形状。

先把三件事想明白

一、AI 原生不是给旧流程加一个代码生成器。

传统 SDLC 是直线：计划 → 设计 → 构建 → 测试 → 部署 → 维护，每一段做完往前交。AI 原生保留这六个阶段，但把它改成可回流的循环，并且让 AI 进入每个阶段。

控制目标一个都没少——责任、审批、隔离、审计、回滚都还在。变的是控制不再只依赖会议和习惯，而是尽量落到版本化文件、权限、Hooks、CI 检查这些确定性的东西上。

二、下一阶段读的是上一阶段的产物文件，不是「上一场聊天」。

会话有保质期，产物才是资产。任何"这个上次聊过了"的东西，只要没落在文件里，对下一个环节就等于不存在。

三、控制必须从「资深同事看一眼」迁到机器上。

变更是人工做的时候，“看一眼"是有效的——量小、上下文在人脑子里。变更是 AI 放大之后，“看一眼"既是瓶颈，又会稳定地漏。你不能用一个线性的人工环节去守一个非线性的产出。

范式内核：基线、沙箱、守门员

三句话能说清：

1. 共识固化为可执行基线——ADR + 不变量（JSON Schema / OpenAPI / JSON Logic），只读、版本化、唯一事实源。
2. 探索隔离在私有沙箱——从指定基线版本派生；沙箱产出只是候选，不自动进基线；漂移超过阈值即超限。
3. 幻觉由独立守门员拦截——Gatekeeper 与 Builder 物理隔离，只吃「基线全集 + 本次变更集」，不读沙箱聊天记录。

第三条最容易被做错。同一个会话里让模型"再检查一遍自己刚才写的”，等于没检查：它看到的是自己的推理，不是事实。守门员必须是独立会话，输入只有两样东西，多一样都不行。

配套的红线（评审可以直接打回）：禁止多人共用一个会话当协同空间；禁止绕过守门员直接提交基线变更；禁止守门员读沙箱聊天记录和需求故事；禁止普通开发直接改 invariants/、contracts/，只能走变更提案合并；禁止沙箱长期漂移超限。任何豁免都要单独一份 ADR，写明原因、有效期、责任人，永久留痕。

六阶段产物链，和三个真实缺口

intent.md → spec.md → plan.md → diff + tests → PR + review → incident → 新的 intent.md

缺口一：plan.md

传统开发里，实现方案常留在工程师脑子里或工单评论里。评审者第一次看到完整方案时，往往已经面对一个巨大的 diff，改方向的成本高到没人愿意提。

AI 让"先写出来再说"变得极其廉价，于是大 diff 评审从偶发变成常态，几个资深工程师根本看不过来。解药是计划模式：Agent 只读仓库、不修改文件，先产出计划，人批准后才进入实现。

一份 plan 要具体到"陌生工程师仅凭它也能实施”：改哪些文件（包括明确"保持不动"的文件）、顺序与依赖、最危险的步骤和破坏面、怎么证明完成、被放弃的替代方案及理由、偏离时怎么回写。其中"最危险的步骤"和"被放弃的方案"最常被跳过，恰恰也是评审时信息量最大的两栏。

缺口二：intent.md 里的「未决问题」

AI 最擅长一本正经地编造不存在的共识。把猜测显式列出来，是把幻觉逼到明面上最便宜的手段。一份 intent 至少五段：问题、期望结果、影响范围、约束与排除项、未决问题。最后一段的杠杆最大。

缺口三：约束和假设必须分开写

传统 spec 把要求写成一坨，AI 分不清哪些是钉死的、哪些是它可以自己定的。判断标准只有一条：能否用一个测试用例判定通过/失败？

• 能 → 约束：进不变量基线，自动检查，改动要走变更提案，架构组批。
• 不能 → 假设：实现者可以自行调整，但必须在偏差记录里说明。

我们的不变量体系早就解决了"约束"这一半，但没给"假设"留位置。后果是 AI 遇到 spec 空白只有两条路：停下来问（打断流程），或者自己编（幻觉逃逸）。给假设一个显式位置，等于告诉它"这些你可以定，但要留痕"——速度保住了，痕迹也没丢。

配套一条硬规矩：允许偏离，不允许不记录。plan.md 的偏差记录段空着也要写"无偏离"，PR 描述必须带偏差摘要。季度统计"diff 偏离 plan 且未记录"的比例，超过 20% 就说明 plan 本身写得太粗。

四层知识载体：别把「建议」当「保证」

组织知识要按控制强度分层，不能混着用：

一句话原则：凡能写成脚本的规则，不许写成提示词。

守门员的提示词再好，本质还是第二层——它提高遵守政策的概率，不保证执行。真正兜底的是第三、第四层。所以守门员每抓到一条系统性规则，都要追问一句：这条能不能变成 CI 检查？能，就别留在提示词里。

CLAUDE.md 用四段结构：Commands、Conventions、Architecture、Known mistakes。维护规则比内容更重要：保持简短（每次会话都要读）、从初始化结果往下删而不是从空白往上堆、同一种错误出现两次就把纠正规则写进去、每季度清一次。

最后一条最常被忽略：一个三个月没更新的 CLAUDE.md，会从"帮忙"变成"稳定地制造错误"——过期说明消耗上下文，并且每次都指向错的方向。

门禁：三值判定，失败关闭

大多数团队的守门员只有两个判定：通过、打回。漏掉了最危险的一种情况——证据不足。

UNKNOWN 的原则是失败关闭：高风险动作不能因为"验证系统暂时不可用"就被放行。同时 block 必须返回可操作的修正路径，不是单纯拒绝；ask 要指定到具体的人，而不是指定到角色——指定角色等于没人负责。

还有三条容易被忽略的：

• 执行者与审计者必须分离。不能把同一个模型实例既当执行者又当最终审计者。
• 门禁要双向验证。每个 Hook 上线前两个用例：一个真危险的动作必须被拦，一个正常动作必须放行。能拦住所有动作的 Hook 不是安全，是不可用。
• 凭据只给占位值。出站请求由可信代理按"域名 + 路径 + 方法"注入真实认证头，凭据不进快照。把真 token 写进环境变量是最常见也最危险的捷径——Agent 可以 env、读 /proc、打日志。

自主权按环境分级：开发环境可以高自主（自动改、自动跑测试），预发布保留部分批准，生产环境 Agent 只准备发布，人授权。

度量：三层不可拆，主键链必须闭

三层合起来才是完整证据链。L2 里最该盯的是逃逸缺陷数（合并后或生产才发现的），以及门禁应拦未拦的生产事件——那是门禁有效性的终极检验，比通过率有意义得多。

再往下是归因主键链：

Session → Commit → Change → Workitem

每一次 AI 会话要能追到它产生了哪个 commit，每个 commit 属于哪次变更，每次变更对应哪个工单。这条链一断，你永远说不清"这次提速是不是 AI 带来的"，也追不回"这个缺陷是哪次会话引入的"。

落地全靠 CI 强制：PR 必须填 workitem ID，commit message 尾部自动追加 session ID（CLI 追加，不靠人记），PR 填基线版本号。靠自觉的字段，三个月后填写率会掉到三成以下。

四种必然出现的翻车姿势

一、流程空转。 沙箱建了、提案提了、守门员跑了，但大家心里都明白这是走形式，真正的决策还是在会下口头定。根因不是人不配合，是守门员校验的是已经写出来的不变量，而大部分真实约束根本没进基线——所以校验什么都过。识别信号很明确：守门员不通过率长期低于 5%。这时候问题不在守门员，在基线太薄。先补基线，再谈流程。

二、守门员自己幻觉。 它言之凿凿列出"冲突清单"，人一看是瞎编的。对策：冲突清单必须可追溯到具体不变量 ID，无 ID 一律视为无效输出；结构性冲突（Schema 不兼容、字段缺失）交给确定性脚本，别给 LLM 判；重要提案跑两遍，结论不一致就人工介入。

三、不确定性闸门无限堆积。 一堆需求卡在"等规则确认"，开发干等，最后绕过流程直接写。每条闸门必须有责任人和死线（比如 5 个工作日），超期自动升级，月度公开"堆积榜"。没有拍板人的闸门，最后一定会被绕过。

四、沙箱变成长期分支。 开了两个月不合并，本地规则和基线差了十万八千里，最后合并是一场灾难。漂移分用脚本算，超阈值强制提示，长期无更新强制归档。别靠自觉。

还有一个不算技术问题的动作：试点启动前，公开书面承诺"允许慢 20%"，并同步给业务方。等进度落后了再说这句话，没人信，流程当天就会崩。

落地顺序：按依赖，不按时间

1. 诊断真实瓶颈——先测一条链路的处理时间和等待时间，别猜。
2. 建立最小产物链——每步人触发、产物可读、每道门有负责人。先跑通 intent → spec → plan 三张纸。
3. 给实现加入反馈——统一 build / test / lint 入口，健康输出明确。
4. 版本化组织知识——四层载体就位。
5. 先自动只读，再允许 PR 写入——只读自动化稳定了，才允许自动修 lint 和文档。
6. 最后接维护闭环——身份、沙箱、短期凭据、分支保护、生产门、回滚都演练过，再让确定性触发器自动调诊断。

两个前置条件，缺一个就别往下走：

• 没有可靠反馈前，不扩大并行和自动接受。 并行会话数超过人的评审能力，输出更快，决策质量更低。
• 存量系统必须先反向提取基线。 老系统没有不变量，AI 进去只会加速制造混乱。提取时的坑是把历史妥协当规则固化——低置信度的"规则"不进基线，单独进 ADR 的风险章节，否则 Bug 就被合法化了。

最后

这套东西不便宜。它会让你多写三份文件、多养一个独立会话、多跑几条 CI 校验，还要在试点期主动认下 20% 的减速。

换来的是一句可审计的事实：每个变更为什么做、按什么假设做的、谁批的、偏离了哪里、出事怎么回滚。

装上工具是第一天的事。把交接、控制、反馈这三件事落成产物、门禁和度量，才是转型。