代码不再是瓶颈

AI 让实现速度大幅提升后，团队最容易犯的判断错误，是继续把“写代码更快”当成全部收益。真正决定交付速度的，往往已经变成需求澄清、风险评审、测试证据和发布授权。Anthropic 的官方手册把这个变化称为对整个软件开发生命周期的重构：保留原有控制目标，但让控制方式跟得上代理式开发的产出节奏。

学习目标

• 能用约束理论解释为什么构建阶段提速不等于端到端交付提速。
• 能画出团队当前从想法到生产的等待时间分布。
• 能区分“必须保留的控制目标”和“可以重做的人工流程”。

核心概念

传统流程围绕“实现昂贵、周期长”设计。为避免做错，组织把大量对齐、签字和检查放在编码前后。当代理能够在较短时间内生成大规模改动时，计划、测试、评审和部署仍以原速度运行，队列就会向两侧堆积。此时继续优化代码生成，只会更快地制造待评审工作。

瓶颈迁移还会带来控制失配。例如，逐行人工审查在小规模人工差异上有效，但面对高频、大体量的代理差异，安全团队要么形成长队，要么被迫降低覆盖。正确动作不是取消安全目标，而是把可机械判断的规则前移成测试、静态检查或 Hook，把需要判断的异常交给人。

可以把每次变更拆成三类时间：工作时间是实际分析或执行；等待时间是在队列里等人、等会议或等环境；返工时间是因为意图或约束晚发现而重做。AI 通常先压缩工作时间，因此观察端到端周期而不是代码产量，才能看到新的瓶颈。

实践步骤

1. 抽取最近 20 个已上线变更，记录首次提出、意图确认、设计确认、首个提交、首个评审、合并和上线时间。
2. 计算每段的中位等待时间，不要把周末或审批等待隐藏在“开发中”。
3. 标出最长的两段，并写下其控制目标。例如安全评审的目标可能是“防止未授权数据暴露”，而不是“必须参加周四会议”。
4. 为每个控制目标选择更快的证据：自动化测试结果、策略检查、风险标签、负责人签字或可回滚演练记录。
5. 只选择一个瓶颈做两周试验，同时观察缺陷逃逸率，避免以速度换失控。

常见误区

• 把代码行数当产能。 代码越多，评审和维护负担可能越高；应看可验证结果和端到端周期。
• 把 AI 原生理解为取消审批。 手册强调人类仍对需要判断的决定负责，变化的是人把注意力放在哪里。
• 先扩大并行会话数量。 如果评审已经是瓶颈，并行只会扩大队列。
• 自动化原有表单。 如果表单本身不能产生下一阶段需要的证据，自动填写只是在加速浪费。

动手练习

选一个最近上线的小功能，画一条包含七个时间点的时间线。用红色标等待、蓝色标工作、橙色标返工。然后回答：如果编码瞬间完成，交付周期最多能缩短多少？哪个控制仍必须存在？把这个控制改写成“输入—规则—证据—审批人”的四列表。

要点回顾

AI 原生 SDLC 的起点不是工具采购，而是承认瓶颈已经迁移。保留安全、合规和责任目标，重写产生证据与触发审批的方式。先测端到端流动，再决定自动化位置；否则局部提速会变成更大的下游队列。

参考来源

• Anthropic / Claude 官方文章：The AI-Native SDLC playbook，重点参见 “Code is no longer the bottleneck”，核验日期：2026-08-26。