摘要： AI 把写代码变快之后，交付瓶颈会转移到 CI、测试和维护。Anthropic 的测试选择服务连续三次修补，分别只维持了 70 天、29 天和不到 1 天，随后用 1 名工程师、3 周时间完成重新设计。本文把这组案例转化为一套可执行的重写判断协议，同时保留单一公司自报数据的证据边界。
阅读时间： 约 8 分钟 · 约 3400 字
TL;DR
- 补丁半衰期指一次修补上线后，同一个容量或可靠性边界再次被击穿所经历的时间。
- 连续补丁的有效寿命不断缩短，比代码行数、系统年龄和架构洁癖更能说明问题。
- 寿命缩短只触发重新设计评估。正式重写还要通过成本、瓶颈消除、等价验证和回退四道门。
- 关键系统优先渐进替换，避免把全部风险集中到一次大切换。
- AI 降低的是实现成本。行为发现、生产验证和双轨迁移的成本仍然存在。
Anthropic 的三次补丁，买到的时间越来越少
Anthropic 在 2026 年 9 月公布了一次 CI 架构复盘。公司工程师每季度提交的代码量达到 2021 至 2025 年平均水平的 8 倍，测试数量增长 10 倍，CI 任务量在 6 个月内增长 25 倍。代码生成和 PR 审查提速后，测试选择服务开始限制整个交付系统的吞吐量（Anthropic CI 工程复盘）。
旧服务由两个部分组成：listener 收集每次 CI 的测试结果，selector 根据历史记录决定某个 PR 应运行哪些测试。listener 是有状态单进程。任务量上升后，它开始追不上输入队列。官方给出的例子是，20 分钟延迟可能意味着数万条测试更新尚未进入 selector。Anthropic 同时明确说明，这不代表 PR 没有运行 CI，也不代表未经测试的代码进入生产；直接影响是 selector 使用了陈旧数据。
团队先后尝试了三次快速修补：
- 把机器核心数翻倍，维持了 70 天。
- 按代码包拆分状态和 worker，维持了 29 天。
- 每天重启进程，连 1 天都没有买到，还让积压继续扩大。
最终方案改变了约束本身：把状态移入内存数据存储，listener worker 无状态化，结果先进入 journal，再由独立 consumer 汇总。官方称，1 名工程师用 3 周完成改造；切换和调优后，未处理事件的积压曲线趋平，发布时系统仍保持稳定。
这些数字来自 Anthropic 内部测量，不能直接外推到其他团队。它们能够支持一个更窄的判断：当上游代码产出快速增加，原本勉强可用的串行状态设计会成为新瓶颈；继续优化非瓶颈环节，只会制造更多等待中的工作。
Anthropic 在另一份关于 AI 研发加速的材料中也用 Amdahl 定律解释组织瓶颈迁移：一个环节提速之后，总速度由其余没有提速的环节决定。此前的零成本编程文章讨论过同一个问题：个人代码产出增加，组织交付速度仍可能保持不变。
下一步需要回答的是：什么时候继续修补已经失去经济意义？
先定义补丁半衰期
补丁半衰期是本文提出的运维指标。Anthropic 原文没有使用这个词。只有积累足够多数据并拟合衰减分布时，它才是严格的统计学半衰期；日常工程中更准确的名称是补丁有效寿命。
定义如下：
第 i 次补丁寿命 Sᵢ = 同一服务目标再次被击穿的时间 − 补丁上线时间
关键是同一服务目标。内存溢出补丁上线后，系统因为第三方 API 限流故障，这次事件不能算作该补丁到期。只有同一个受限资源或故障机制再次越过预先声明的边界，才形成可比较数据。
适合用作边界的指标包括：
- listener 积压超过 50000 个任务；
- CI 队列 p95 等待时间超过服务目标；
- 内存饱和迫使服务紧急重启；
- 测试选择数据的新鲜度超过上限；
- 同类故障每周触发的 on-call 次数超过预算。
再计算相邻两次补丁的寿命比：
Dᵢ = Sᵢ / Sᵢ₋₁
Anthropic 案例中的第二次寿命比约为 0.41，第三次低于 0.035。三个数据点无法证明普遍规律，却足以说明同类修补正在迅速贬值。
数据较多时，应按组件和故障类型计算滚动中位数与 P25，并用部署次数、流量或 CI 任务量做归一化。否则，发布量增加会让复发间隔自然缩短，监控能力提高也会让问题看起来更频繁。故障分类也要冻结：安全补丁、依赖升级、容量故障和产品行为缺陷不能混在同一条曲线里。
代码很老、架构很乱、维护起来不舒服，表达的是感受。补丁寿命回答的是另一个问题：本次修补是否仍在改善系统的限制条件。
重写前要过五道门
补丁寿命下降是预警信号，不能自动授权重写。关键系统至少要通过五道门。
1. 同类约束门
先确认连续事件来自同一个瓶颈。分类依据应是被击穿的服务目标和因果机制，而不是告警名称。
内存增长、外部 API 配额和网络抖动可能都表现为 CI 超时。把它们混进同一条寿命序列，会制造一个看似精确、实际无意义的下降趋势。
2. 寿命门
每次重要修补都进入统一台账：
| 字段 | 记录内容 |
|---|---|
| 触发边界 | 哪个 SLO 或容量阈值触发本次修补 |
| 修补动作 | 为恢复容量余量采取的最小改动 |
| 上线与到期 | 上线时间，以及同类边界再次被击穿的时间 |
| 容量余量 | 修补后的余量和余量消耗速度 |
| 人力成本 | 工程天数、排障时间和 on-call 中断 |
| 风险成本 | 数据陈旧、任务遗漏、回滚暴露和用户影响 |
连续两次寿命下降，进入架构复盘。围绕同一瓶颈完成三次紧急修补，启动正式的修补与重写成本比较。这两个数量是评审触发器，不是适用于所有系统的硬阈值。
评审范围服从证据范围。某个 worker 或 selector 的补丁寿命下降，只能支持组件级重写候选，不能自动扩展成整个仓库、平台或产品的全量重写。
3. 经济交叉门
先冻结一个决策周期，例如未来两个季度，然后分别估算两条路径：
修补路径 = 预计补丁 + 故障处置 + 交付等待 + 累积迁移债
重写路径 = 实现 + 行为发现 + 双轨运行 + 迁移 + 回退储备
AI 会显著降低实现成本，也可能加快测试生成和迁移工具开发。它无法自动消除旧系统行为发现、生产结果核对和双轨运行成本。
只有在保守估计下，修补路径成本仍高于替换路径，重写才通过经济门。如果删除一条乐观假设就会反转结论，当前证据还不足以拍板。
工期也要单独比较。如果下一次补丁的保守寿命估计，已经短于重写交付周期加回滚缓冲期，这次补丁只能作为迁移窗口，不能再按长期方案管理。继续把它当成终局，会人为制造一段没有受保护路径的时间。
这个结构与卡内基梅隆 SEI 的成本收益分析方法一致：架构策略要同时比较成本、收益、工期和风险，单一技术指标只负责触发评审。
4. 瓶颈消除门
新设计必须改变被测瓶颈的性质，而不是用新框架重写一遍旧约束。
Anthropic 的有效改动是把状态移出单进程，让 listener 可以无状态横向扩展，并用 journal 解耦接收与汇总。假如只是换一种语言重新实现同一个有状态 singleton，代码会更整洁，容量上限仍然存在。
这也是 Harness Engineering 的核心：值得保留的资产是约束模型、故障知识和验收接口，替换代码只是实现手段。
5. 可恢复门
关键服务没有验证与回退能力，就没有进入重写切换阶段的条件。最低配置包括：
- 冻结一套代表性输入与预期决策；
- 为外部可见行为建立合同测试；
- 权限切换前先做影子处理或双读；
- 持续核对新旧输出差异；
- 用 canary 限制故障半径；
- 实际演练回滚，而不是只写一份回滚文档。
Google 的 canary 发布指南进一步给出了运行合同：让 release candidate 与同期 control 对照，提前声明判断指标，出现显著偏离时暂停或回滚。
Strangler Fig 渐进替换模式的价值就在于分散切换风险。AWS 的实践指南也建议优先替换测试覆盖较好，或者扩展压力最突出的组件（AWS Prescriptive Guidance）。
一张可直接使用的决策表
| 当前状态 | 建议动作 |
|---|---|
| 补丁寿命稳定或变长，故障原因不同 | 继续修补，同时补强观测 |
| 寿命缩短，但当前瓶颈尚未确认 | 暂停架构改造，先提高因果测量质量 |
| 同一约束复发，寿命连续缩短两次 | 资助一个限时重新设计 PoC |
| 修补成本已经超过重写，但行为无法核对 | 先建设验证 Harness，再替换生产系统 |
| 新设计已证明能移除瓶颈，回退路径也已演练 | 用影子、canary 和渐进切换完成迁移 |
这张表把经常混在一起的三个问题拆开：
- 修补是否正在失去经济价值？
- 新设计是否真的移除了当前瓶颈？
- 迁移过程能否验证并撤销？
只有第一个问题为是，仍然不足以启动生产重写。
同时观察吞吐量与不稳定性
新系统可以让队列变短，也可能让发布风险增加。验收指标必须同时覆盖吞吐量和不稳定性。
DORA 软件交付指标把变更前置时间、部署频率，与变更失败率、失败部署恢复时间和部署返工率放在一起。针对 CI 或测试选择服务，还应补充：
- 输入任务数与持久记录结果数是否一致；
- 事件积压深度与最老事件年龄；
- selector 使用数据的陈旧度；
- 错误跳过测试和无效追加测试的比例；
- 周期性全量测试发现的逃逸故障；
- 影子对照期间新旧选择集的差异率；
- p95 决策延迟；
- 紧急人工干预频率；
- 回滚与新旧结果核对耗时。
Google SRE 将监控视为比较变更、分析趋势和理性决策的基础，同时要求寻呼逻辑保持简单、稳定、低噪声（Monitoring Distributed Systems）。当 Agent 依靠指标持续调优系统时，这条要求更重要。观测错误会让 Agent 优化一个代理指标，而真实积压仍在后台增长。
这组案例不能证明什么
Anthropic 的案例不能证明所有团队都该为 25 倍负载设计，也不能证明第三次补丁后必须重写，更不能证明 AI 已经让全量重写变得安全。
它支持的结论更克制：当实现成本快速下降，修补与重写的成本交叉点可能提前出现；团队需要用时间序列衡量修补耐久性，再用验证门控制替换风险。
优化单位应该是完整交付系统。代码便宜而验证仍然稀缺时，继续提高代码产出属于非瓶颈优化，只会给最慢的环节增加库存。
FAQ
重构和重写有什么区别？
重构是在同一个持续演化的系统中改变内部结构并保持外部行为。重写会建立替代实现，再把生产权限迁过去。现实项目通常还有第三条路：旧系统继续运行，团队按边界逐步替换组件。
三次补丁就是重写规则吗？
不是。三次同类修补可以形成一条短时间序列，适合作为正式评审触发器。最终决定还取决于寿命、故障成本、目标架构、测试能力和回退风险。
小系统也能使用补丁半衰期吗？
可以。定时任务反复错过完成窗口、数据库 worker 反复耗尽内存、构建服务队列反复越过 SLO，都能形成可比较的补丁寿命序列。
AI 会让重写更安全吗？
AI 可以降低实现、测试生成和迁移工具的成本。安全来自行为捕获、独立核对、分阶段转移权限和可演练回退。AI 改变成本账，不改变这套控制结构。
下一步：从下一次补丁开始记账
下一次重复发生容量故障时，记录被击穿的边界、补丁上线时间、恢复后的容量余量、余量消耗速度，以及同类问题复发时间。完成两次可比修补后，计算寿命比，并在固定周期内分别估算继续修补和重新设计的成本。
架构直觉可以发起讨论。补丁耐久性的可复算记录，才负责决定修补还能买到多少时间。