衡量成效，以及何时回退

成功意味着什么

一次升级算成功，是指该阶段的约束确实移动了，而它的稳定性守住了，两者都以 AI 到来之前测得的基线为参照。达不到这一点的，只是忙碌。前面几章已经展示了定义一旦放松会发生什么。在《当代码变便宜，瓶颈就会转移》描述的那次试点中，拉取请求增加了 13.6%，按质量调整后的产出只增加了 1%，返工却增加到 2.6 倍（Denisov-Blanch，2025 年 9 月演讲幻灯片，T3）。按数量评判，这次试点是胜利；按质量调整后的产出评判，它几乎原地不动，而换来这 1% 的代价是 2.6 倍的返工。

有两类数字永远不能当作成功标准，完整理由见《经济性、风险与度量》。

• 自我评价。在 METR 2025 年的试验（T1）中，经验丰富的开源开发者在自己熟悉的大型成熟代码库上工作，用 AI 时耗时多了 19%，事后却相信 AI 让他们快了 20%。其他试验在不同的任务和工具上测到了提升；这里要说的是感觉与测量之间的差距有多大，而不是效应的正负。调查能告诉你人们喜不喜欢一个工具，却不能告诉你该不该保留一个级别。成熟度模型的证据规则既适用于定级，也适用于判断成效。
• AI 写的代码占比。它统计的是投入；它的定义每次表述都在变；而且无论交付是否更快、故障是否更少，它都会上升（见数量不等于价值）。

连一家出售 AI 度量产品的厂商也这么说。DX 的 AI 度量框架把指标组织为"三个关键维度：使用率、影响和成本"。它警告"代码生成量这类指标尤其容易被操纵"，并且"强烈告诫不要自上而下下达指令，也不要把指标用于个人绩效评估"（厂商框架，截至 2026 年 10 月）。使用率告诉你工具是否在用，只有影响才能为一次升级提供理由。最后那条警告的意义超出了度量本身：一旦某个 AI 指标进入个人绩效评估，人们就会去优化它，这个数字也就不再反映系统的情况。《人：角色、技能与初级工程师培养》讨论应当如何衡量人。

先测基线，因为以后就测不到了。METR 在 2026 年尝试重做其试验时发现，"30% 到 50% 的开发者"选择不提交某些任务，因为他们不愿在没有 AI 的情况下做这些任务。METR 的结论是，"我们新实验的数据，对 AI 工具当前的生产率效应只能给出一个不可靠的信号"（METR，2026 年 2 月，T1）。一旦工具成了人们工作方式的一部分，本该构成对照组的那些人就不复存在了。公司内部也是如此。如果在智能体开始工作之前，你没有记录该任务类型的流动与稳定性数据，你就永远无法知道智能体改变了什么。《90 天试点》把基线窗口写进了试点计划。

一个流动指标，一个稳定性指标

规则很简单。你每升级一个阶段和任务类型，就选一个升级成功时应当改善的指标（流动），再选一个能显示它适得其反的指标（稳定性）。两者一起报告，绝不只报其中一个。

模板来自一项在生产工作上进行、同时测量了两者的随机试验。Google 让一半开发者在十一周内获得针对构建失败的机器学习修复建议，测得"CL 吞吐量提升约 2%"。它也去找了害处，结果是"没有观察到安全风险或缺陷的增加"，回滚率也没有可检测的差异（Google，2024 年 4 月；完整解读见《案例研究》）。

效果很小，而结论之所以可信，是因为稳定性那一半被测量了。吞吐量提升 2% 且回滚没有增加，是一个可以保留的结果；同样的 2% 配上一个没人测的回滚率，只是猜测。

对整个组织而言，DORA 的交付指标仍是通用语言。Thoughtworks 技术雷达（第 34 期，2026 年 4 月）把 DORA 指标（包括返工率）放在"采纳"环，并用一句话概括了本章："如果前置时间没有缩短、部署频率没有提高，更快的代码生成就不会转化为更好的结果。"这是从业者的观点，与证据相符。

第 II 部分的每一章都已经给出了本阶段的指标对。下表把它们汇总在一处，并链回各章的"指标"一节；表中没有任何内容超出那些章节的论证。

注意稳定性一栏有多少次写着"与同类人工变更相比"。这种比较也是 L3 的准入要求，而几乎没有人公布它。在本书的证据中，唯一公开的、把智能体与同一代码库中其余所有变更进行对比的回退数据来自 dotnet/runtime：535 个已合并的智能体拉取请求中有 3 个被回退（0.6%），其他 4,251 个已合并拉取请求中有 33 个（0.8%），作者说这一差异没有统计意义（Microsoft，2026 年 3 月，T2）。即便如此，这也不是干净的智能体与人工对比：那 4,251 个中包括 666 个来自依赖更新工具等机器人的已合并拉取请求，另有 3,585 个来自人。

你得自己建立基线。大部分数据本来就在版本控制和故障跟踪系统里，通常缺的是归属标记：如果智能体的变更没有打标签，你就无法把它们的回退和其他人的区分开。

计分卡

本书的提议是：每个阶段和任务类型各占一行，而不是整个项目只有一个数字。每一行记录级别及其证据、两个指标及其基线、会让这一行降一级的触发条件，以及由谁做这个决定。下面的例子仅作示意，不描述任何真实组织。《模板》附有空白的试点计分卡和回退触发条件表。

SCORECARD (the book's proposal; illustrative values, no real organisation)

PHASE / TASK TYPE           LEVEL  FLOW (baseline -> now)   STABILITY (baseline -> now)    TRIGGER                      OWNER
--------------------------  -----  -----------------------  -----------------------------  ---------------------------  -------------
Maintenance / dep. bumps    L3     landed/wk 12 -> 40       14-day reverts 1.0% -> 0.9%    reverts > human, 2 windows   platform lead
Coding / test cleanup       L2     success rate n/a -> 71%  escaped defects 2 -> 2 (90 d)  any oracle edit merged       team lead
Review / AI first pass      L2     wait P75 9 h -> 7 h      "Not useful" rate 6%           "Not useful" > 10%, 2 wks    review owner
Operations / cache restart  L2     MTTM 34 min -> 22 min    agent-worsened incidents 0     any; or risk score elevated  SRE on call

Every row: baseline window recorded BEFORE the agent started;
trigger written BEFORE the climb.

价值在结构，不在数字。每一行都可以单独变动，所以把一个任务类型降一级，不会牵动项目的其余部分。每一行都写明一个人，所以触发条件被突破时，不必等开会来决定该谁拍板。第一列还让计分卡与《评估你的起点》中的自评表成为同一份文件，让你声称的级别和测得的级别留在同一页上。

回退触发条件

这方面的记录很少。没有任何公司公布过回退 AI 编码工具或降低智能体自主度的标准，为本书所做的检索也一个都没找到（见公开记录中缺少什么）。可用的先例来自编码智能体之外，共有三个。

Google 的 Tricorder：一个数值化的关闭开关。Google 的静态分析平台统计开发者对每个分析器的发现点击"请修复"和"没用"的次数。"如果某个分析器的比例超过 10%，Tricorder 团队就会停用该分析器，直到作者改进它"，而且它"已经（多次）停用过分析器"（Sadowski 等人，CACM 2018）。《代码评审》把它用在 AI 评审者上。在这里，它是每个阶段的模板，因为它具备触发条件所需的全部四个部分：一个作为工作副产品采集的信号，一个持续跟踪的比例，一个事先定死的阈值，以及一个自动、范围受限且可逆的动作。

Google SRE：内置于智能体的降级。在 Google 为运维智能体所做的设计中，"如果智能体请求一次 L3（高度自动化）执行，但检测到风险评分升高或生产状态异常，它会自动把请求降级为 L2（部分自动化），拦截执行并把审批请求转给一名人类 SRE。"此外还有一个覆盖整个集群的"红色按钮"，用来"暂停所有进行中的智能体操作、阻止新操作，或在全局撤销 L3 权限"（Google SRE，页面未注明日期，2026 年 10 月访问，T3）。《运维与故障处理》给出了完整的护栏。对本章而言，要点在于它的形态：触发条件是一个状态，动作是降一级，而且不需要任何人召集会议。

NIST：关停的责任。自愿性的 NIST AI 风险管理框架要求，"已建立并实施相应机制，职责已分配并被理解，以便取代、脱离或停用那些表现或结果与预期用途不符的 AI 系统"（NIST AI 100-1，MANAGE 2.4，2023 年 1 月）。它要求的是机制和明确的责任人，而不是阈值。《监管与许可现状（截至 2026 年 10 月）》跟踪这类责任的现状。

据此，本书提议一条触发条件由六部分组成，六部分都在升级之前写好：

• 信号：取自稳定性一栏的一个指标，自动采集。
• 阈值：事先定死，以你自己的基线为参照，而不是某个厂商的数字。
• 时间窗：长到一个糟糕的星期不会触发它，又短到一个糟糕的季度一定会触发它。
• 动作：限定在一个阶段、一个任务类型，通常是降一级。
• 责任人：指名道姓的那个人，无需再经审批即可执行。
• 重新升级的条件：满足什么才能再升回去，例如根因已修复，并有一个新的干净数据窗口。

下表是本书的提议。阈值只是起点，需要用你自己的基线校准；没有任何组织公布过经结果验证的版本。

表中有两个触发条件并不改变级别。队列溢出时限制的是数量，因为升级本身可能没问题，问题出在评审能力。评审噪声关掉的是一个组件，而不是一个阶段。让动作与失效相匹配，回退才能做到恰如其分。一个只会全部关停的团队，往往什么都不敢关。

自我评价和采用率在表中都没有出现。满意度下降值得调查，但它不是触发条件，道理和满意度上升不算成功一样。本站在急停开关、SLO 与错误预算、质量回归检测和生产反馈信号中介绍了具体机制。

降级是日常运维

公开记录中的回退都不是事先规划的，看起来也不像例行公事。Kiro 事件之后，对 FT 关于原因和持续时间的报道持有异议的 Amazon 表示："额外的保障措施包括对生产环境访问实行强制同行评审"（Amazon，2026 年 2 月 20 日）。成熟度模型的示例把这记为从事实上的 L4 回到 L2，《案例研究》并列了双方的说法。这是一次降级，是事后强加的，没有公布任何触发条件。

Amazon 零售业务提供了第二个有争议的例子。据 FT 报道、经 Fortune 转述（2026 年 3 月），一份关于"事故趋势"且"爆炸半径大"的内部简报，把"生成式 AI 辅助的变更"列为诱因之一；据报道，拟议的护栏包括由资深工程师签核初级和中级工程师的 AI 辅助变更。Amazon 的说法不同：它表示讨论的事故中只有一起与 AI 有关，没有一起涉及 AI 编写的代码，也并不要求这样的签核。

双方的说法都不能确定究竟发生了什么，本书也不把这些事故归咎于"AI"或"人"。这份据报道的计划说明的是：事先什么都没写好时，降级会是什么样子——范围宽泛，按资历而不是按任务类型划线，而且据报道是为了应对一连串事故才拟定的。本章的提议追求的恰恰相反：范围窄、事先约定、由指定的责任人执行。

四个习惯能让降级足够便宜，便宜到数据说该降时就真的会降。

• 预先接好线。每个级别都是一项配置，比如一条路由规则、一组权限或一个自动合并开关，所以降一级就是改一项配置，而不是立一个项目。Google 的降级就运行在智能体自己的请求路径里。
• 演练过。成熟度模型对 L3 的定义本就要求暂停和回退"已经存在且演练过"。从没用过的降级路径，你是靠不住的。
• 限定范围。一个阶段、一个任务类型、一个级别。测试清理出现稳定性倒退的团队，不应因此失去运转良好的依赖升级。
• 记录，但不追责。每次降级都记下触发条件、数据和重新升级的条件。有记录的降级日志，证明触发条件在起作用；一年都是空白的日志，可能意味着它们根本没在看。

本站的缩减智能体部署一文介绍了部分撤退的具体做法。智能体回撤是一次度量失败认为，大多数公开的反转都可以追溯到一开始就选错了成功指标；信任跑在了智能体事故率前面则展示了信心如何比本应支撑它的数据涨得更快。衡量 ROI 把计分卡与商业论证连接起来。当计分卡中的某一行降级时，那是计划在按设计运转。《向更多团队推广》把同样的行推广到整个组织。