写代码不再是瓶颈，卡住的是它两侧那几步
Anthropic 的 Applied AI 团队在企业客户现场反复见到同一个画面：agent 把一版改动写完，diff 摆在评审者面前，然后审查队列开始堆积。
传统软件开发生命周期（SDLC）的六个阶段——规划、设计、构建、测试、部署、维护——每个阶段由不同角色拥有，工作靠文档、工单和签核在阶段之间移动。这套流程之所以重，是因为它假设最耗时、最贵的一步是写代码。PRD、估算仪式、产品安全评审，都是开发要花几周、几个月甚至几个季度时用来强行对齐的工具；控制措施还建立在第二个假设上，即每一步都由人执行。
agent 把写代码压到小时级之后，两个假设同时失效。瓶颈转移到构建两侧的阶段——规划、审查与测试、部署——它们仍按人的速度运行；逐行人工审查在人写代码时说得通，在 agent 写出大半 diff 之后就追不上；例外依然要经每周或每月开一次的委员会，治理成本随代码量一起上涨。安全团队的例子最直观：人数按人的产出规模配置，agent 一放大代码产出，要么审查队列堆积，要么代码带着不足的审查上线，受监管组织两种结果都不能接受。
所以转型不是在实现阶段塞一个 AI 工具。控制方式要和产出速度同速——这句话是整套设计的起点。
类比瓶颈转移高速公路拓宽之后，堵点从入口匝道挪到了收费站：车没变多，收费口的处理速度没变。
传统 SDLC 与 AI 原生 SDLC 的两端
| 维度 | 传统 SDLC | AI 原生 SDLC |
|---|---|---|
| 流程形态 | 线性阶段，逐段推进 | 循环，AI 嵌在每个点上 |
| 阶段交接 | 文档、工单、签核 | 提交一件产物，下一阶段读取它 |
| 控制前提 | 假设每一步都由人执行 | 控制点落在产物与门禁上 |
| 人工注意力 | 写代码并逐行审查 | 审 agent 标记出的判断点 |
| 审计载体 | 签核记录 | 提交链：谁提出、agent 产出什么、谁批准 |
把流程从线性改成循环，具体改的是什么？
循环不是修辞：每个阶段以提交一件产物收尾
AI 原生 SDLC 把线性流程改成循环，核心不是模型，是产物：每个阶段以把一件产物写进版本控制收尾，下一阶段以读取它开始。产物序列是 intent.md、spec.md、plan.md、diff 与它的测试、带审查发现的 PR、事故记录。接受一份 intent.md 触发需求与设计，批准 spec.md 触发计划模式，合并 PR 触发流水线；生产环境里某个控制带被击穿，就写下下一份 intent.md，循环接着走。
早期阶段以 .md 文件为主，因为产品负责人和 agent 读的是同一份文件：intent.md 记问题，spec.md 记需求与设计，plan.md 记怎么改。Build 之后为代码及其记录。
这条提交链同时是审计追踪：谁提出了什么、agent 产出了什么、谁批准了。对受监管行业来说，这一点比“写得更快”重要得多，因为它把合规证据从会议室搬进了代码仓库。
人的位置也跟着换。传统流程里人从每个阶段的起点开始干活；循环里人的注意力集中在门禁上，审 agent 标记出来的东西，而不是每段从头做起。流程形态从流水线变成一个环：接受、触发、提交，下一个阶段被上一个阶段的产物叫醒。
类比提交产物驱动下一阶段接力棒不是交给下一个人，而是放进一个只能由下一位读取的格子，交接本身留下了记录。
一份产物叫醒下一阶段
intent.md
写清问题、期望结果、受影响的用户与系统、约束和待决问题，由提出者修正后提交。
spec.md
结合品牌、安全、合规与 UX 技能生成需求与设计规格，产品负责人审阅并把标记出的问题交给政策负责人。
plan.md
写明改哪些文件、顺序和用什么测试证明；实现偏离计划时在同一提交里更新。
diff 与测试
代码改动与证明它的测试一起进入审查，测试在修复任务中不允许被改动。
PR 与审查发现
审查意见、修复与批准记录都留在 PR 里，成为可查的审计记录。
事故记录与下一份 intent.md
生产环境某个控制带被击穿时，agent 按 intent.md 格式写下诊断。
每一阶段结束时提交的产物，就是下一阶段的输入与审计线索。
从一句抱怨到 plan.md：产物链的前三步
第一步值得看清楚，因为它最容易被忽略。想法进入流程有三条路：一个人有想法、有人开工单、告警暴露一起事故。以第一条为例，提出者用自己的话描述问题——今天做不到什么、谁受影响、什么样算更好、什么不在范围内，不需要正式语言。Claude 会追问分析师会问的问题：范围、用户、约束、成功的样子。问清楚后，按组织模板写成 intent.md，提出者改掉被误解的地方，提交到共享仓库。平台或工程团队只需做一次准备：建好这个仓库，定谁能往里写。接上版本控制系统的连接器之后，不熟 git 的人也能从 claude.ai 让 Claude 代为提交。
设计阶段由 Claude 结合组织的品牌、安全、合规和 UX 技能产出需求与设计规格，产品负责人审阅但不执笔。被标出的问题要先找对应政策的负责人解决——政策在写规格时就被读到并应用，而不是几周后在评审里被发现。前端工作是最清楚的例子：产品负责人用 Claude Design（beta）从 intent.md 做设计稿，迭代后导出到 Claude Code 去实现。
构建阶段从计划模式开始。工程师把 intent.md 和 spec.md 交给 Claude，要一份实施计划：改哪些文件、按什么顺序、用什么测试证明。然后追问——这个改动可能弄坏什么、哪一步最险、你放弃了哪些别的方案。判断标准很实在：一个没看过这段对话的工程师，光靠这份计划就能把改动做出来。计划被接受后才允许编辑文件，所以设计评审发生在代码生成之前，那时改方向还只是改文档的事。计划提交为 plan.md，PR 审查拿最终 diff 对照它；实现偏离计划时，同一提交里更新 plan.md。
护栏成熟之后，常规工作会走向自动接受：CLAUDE.md 调好了、skill 把政策编码进去了、hook挡住不安全动作、测试套件 agent 自己能跑，一份紧凑的 spec.md 加一小片影响范围，就足以让逐项确认变成默认。
计划被接受之后，agent 凭什么知道这个团队的规矩？
skill 只是建议，hook 才拦得住人
agent 需要知道这个团队的规矩，而约束力分成几层。
CLAUDE.md 是给 agent 的入职文档：构建、测试、lint 命令，重要的约定，架构分层，以及这个团队最常犯的错。用 /init 生成一版，再削到新人第一天真正需要的量，检入仓库根目录，不超过一页——agent 每次会话开头都会整份读一遍，过时的内容只是在白占上下文。这里有条工作规则：同一个错误出现两次，纠正就写进 CLAUDE.md。
skill 把制度知识变成可执行的文件：一个含 SKILL.md 的文件夹，放在仓库 .claude/skills/<name>/ 下随代码分发，或经 plugin（插件）做组织级分发；frontmatter 说明什么时候触发，正文说明做什么。规则写在 skill 里，就会在代码被写的时候被应用；政策变更时改 skill，由政策负责人签字。但 skill 是咨询性控制（也就是建议性控制）——没有任何机制强制某次会话遵守它。
要让必须始终成立的政策永远成立，背后得有确定性的东西：一个 hook，或者 PR 上再查一遍。hook 在每次匹配的动作上运行，能挡住对生成代码或冻结包的编辑，改完自动跑格式化和 lint，把凭证拦在 diff 之外。构建阶段是 hook 触发最密的地方，因为 agent 的大部分动作就是文件编辑和 shell 命令，所以它必须快、必须限定在改动的文件上；跑整个测试套件这类重活属于提交或 PR 环节。需要人点头的 hook 属于部署门禁，放在构建阶段等于把一个人塞回所有并行会话的关键路径。
两者关系可以说得干脆：skill 是建议性控制，hook 是它背后的确定性层——前者让违规变罕见，后者让违规接近不可能。
四层控制：从上下文到关不掉的门
- 上下文CLAUDE.md
命令、约定、架构、常见错误。每次会话开头被整份读取，建议控制在一页以内。
- 建议性控制skill
含 SKILL.md 的文件夹，写明何时触发、做什么。让违规变罕见，但不强制某次会话遵守。
- 确定性控制hook
在匹配的动作上运行，可允许、询问或阻止；构建阶段触发最密，因此要快、要限定改动范围。
- 不可关闭的门受管设置
由平台或 IT 管理员拥有并下发，团队成员无法自行关闭，用于必须永远成立的策略。
那真正需要人点头的地方，怎么变成一道过不去的门？
人还在，只是站在门禁上
真正需要人点头的地方，做法是把审批写成一道脚本。工程领导层连同变更管理和合规，列出必须保留的人类审批门——变更签字、发布授权、受保护路径的编辑——平台工程师把每个关卡写成一个 hook，可以允许、询问或阻止。团队级 hook 放在仓库里的 .claude/settings.json，不可协商的 hook 放进平台或 IT 管理员拥有的受管设置，工程师自己关不掉。被拦下的动作要说明原因和申请路径，否则门禁只会变成一次干等。
自治按环境分级。开发环境里 agent 自由部署；生产环境里 agent 准备发布，由发布经理授权，hook 强制这道门——它能走到门前，过不去。预发环境的权限介于两者之间，具体档位没有展开。分支保护让 agent 写下的一切都变成 PR，没有直推主干的路径。每次非交互运行以 agent 自己的身份执行，流水线日志因此能区分 agent 做了什么、触发它的工程师做了什么。企业控制面的细节由官方文档补上：服务器托管设置由管理控制台下发，客户端启动时获取、会话中每小时刷新；受管 MCP 配置一旦存在，客户端就只加载它定义的服务器，用户再想用命令行参数加服务器会导致启动退出。
审查端同样在收紧。REVIEW.md 规定跑哪几轮检查（bug 与逻辑错误、安全与漏洞、对照 spec.md 和 plan.md 的合规性），什么算重要、什么算 nit；一次审查最多报五个 nit，其余只报数量。职责分离由此保住：写代码的 agent 无法批准这份代码，批准由人通过分支保护给出，PR 历史就是审计记录。Anthropic 内部还用多个各自聚焦狭窄领域的审查 agent 自动审每个 PR，并与 SAST（静态应用安全测试）工具结合；代码库按风险分级，部分代码库保持严格人工批准，每次批准都记录所用信号与理由，风险加权样本由人工复核。它把硬性代码审查门禁放在测试与 CI（持续集成）阶段，也有客户把安全审查指令与动作前 hook 组合成更硬的门禁。
Eval（评估）是这一代的阶段门：从近期工作里收 20 到 50 个真实任务，连同一个可接受的结果写成用例，在 CI 里非交互地按计划运行，并在 CLAUDE.md、skills 或 hooks 变更时触发；配置变更以结果作为合并门禁，每起生产事故追加一个回归 eval。模型换代或提示重写之后，这套套件回答的问题很朴素：agent 是否还在同一个标准上干活。
并行也要有边界。一个工程师可以同时推几条工作流，每条是独立的 Claude Code 实例、各自的 git worktree，两到三条是合理起点——真正的上限是一个人能认真审多少条，所以只在审查跟得上的时候加会话。
三种环境的自治分级
| 对象 | 开发环境 | 预发环境 | 生产环境 |
|---|---|---|---|
| agent 能做到哪一步 | 自由部署 | 材料只说“介于两者之间”，未展开 | 准备发布，不能自行放行 |
| 谁给出授权 | 无需额外授权 | 未说明 | 发布经理具名授权 |
| 靠什么强制 | 按环境设置的权限档位 | 按环境设置的权限档位 | hook 强制生产门，agent 无法越过 |
状态按材料描述定性标注：越靠近生产，授权要求越硬。
Anthropic 早期用 Claude Opus 做的项目安全审查，后来把低风险批准权下放给团队
Anthropic 早期的安全自动化之一是 Claude Opus 驱动的项目安全审查（PSR）web 应用，读取项目设计文档并对照 MITRE ATT&CK 框架识别潜在漏洞与缓解建议。
- 初始实现
构建 Claude Opus 驱动的 PSR 应用，摄取设计文档并按 MITRE ATT&CK 框架分析潜在漏洞与缓解措施。
It ingested a project design document and analyzed it against the MITRE ATT&CK framework
- 接入组织上下文
把 PSR 连接到内部知识索引，覆盖全组织政策、过往决策与相关系统，用来捕获设计文档本身缺失的信息。
We’ve significantly enhanced the system by connecting it to an internal knowledge index
- 效果声明
官方称该实现节省了 AppSec 团队大部分时间。
This one implementation saved the majority of the AppSec team’s time.
- 授权下放
在确信 Claude 的风险评估足够准确后，允许团队在 Claude 判定上线风险足够低时自行批准项目。
we allowed teams to approve their own project, if Claude deemed the launch low enough risk.
- 后续扩展
用 Claude Code skill 让 Claude 进一步展开并收集散落各处的上下文；同时指出原型可在数小时内产出，使详细架构审查的重要性下降。
Creating a Claude Code skill allowed Claude to further fan out and capture additional context wherever it lived.
结果：官方称该实现节省了大部分 AppSec 时间，并据此把低风险项目的批准权下放给团队；同时认为在原型快速产出的情况下，设计阶段门禁的必要性下降。
不能据此证明：不能证明风险阈值、自批准机制可以被其他组织复制；材料未给出样本量、误报率、人工复核抽样比例和任何时间跨度。
含原文逐字引文
门禁定好之后，闭环靠什么在没人启动的情况下转起来？
没人点开始的那一步：监控分档与频道里的第一响应者
前面每个阶段都要有人启动，最后一段让它自己转。一个持续运行的监控 agent 可以在 bug 工单被提出后自己写下 intent.md，走完需求、计划、构建、测试和审查；阶段之间设一道独立的信心门禁——确定性检查或对抗式审查 agent——判断上一阶段的输出是继续还是升级给人。
监控的做法里最值得抄的是分档思路。先选一个有稳定滚动基线的指标，比如 CI 测试失败率、部署后 5xx 率、PR 周期时间，基线取滚动 30 天；再写一个受版本控制、带单元测试的检测脚本，用均值和标准差配合西部电气（Western Electric）之类的判定规则，让控制带既能抓突变也能抓缓慢漂移。判断“有没有异常”这件事必须完全确定，所以检测全程不含模型。响应分三档，写在受版本控制的配置里：越过 1σ 仅记录；越过 2σ 调用 Claude 以只读工具做诊断；越过 3σ 允许 Claude 行动，但只限于开一个 PR 进入审查门禁，或者触发一个事先批准过的 runbook。agent 把诊断按 intent.md 的格式写成文档，后面的路和其他改动一样，处置结果由服务负责人或值班工程师分诊：立即修、排期、还是驳回；驳回用来调整分档、减少噪音。修好之后，这起事故变成套件里的一个新用例。
安全扫描是同一逻辑的另一个应用。一次扫描只是某个模型下针对某个代码库的时间点陈述，而两半都会过期：代码每周在变，模型换代又会找出上一代漏掉的漏洞。所以按计划、无人启动地跑，发现走和其他改动一样的门禁。Claude Security 是它的托管形式，每个发现报告前先经验证并附置信度评级，建议补丁在 Claude Code on the web 里审核后套用；置信度评级和带理由的驳回一起构成扫描历史。
事故往往不从监控系统来，而是晚上十点出现在团队的即时通讯频道里。Claude Tag（public beta，目前可用在 Slack）让 Claude 以自己的身份成为频道成员，每起事故因此有第一个响应者，对话和机构知识留在频道里，频道里任何人都能引导它、当场验证假设。它可以通过 MCP 确认指标回到基线，再把复盘写进受版本控制的 lessons 文件，供以后的调查读取。
底层还有一层不那么显眼的控制：Anthropic 把编码迁到远程虚拟机，并对 agent 流量做出口白名单，用来限制提示注入的渗出路径。
监控越界之后的三档响应
- 条件指标越过 1σ结果脚本只记录，不调用模型可以怎么做材料给出的处置：留档，供后续调档参考
- 条件指标越过 2σ结果Claude 以只读工具做诊断可以怎么做材料给出的处置：产出诊断，不改动任何东西
- 条件指标越过 3σ结果Claude 可以行动，但只能开 PR 进审查门禁，或触发事先批准过的 runbook可以怎么做材料给出的处置：由服务负责人或值班工程师分诊——立即修、排期或驳回
这些做法听起来完整，效果有没有被独立验证过？
效果数字全部来自厂商自己
方法讲完之后，该看数字了。它们主要来自 Anthropic 另一篇官方文章：Claude 撰写其代码库约 80% 的合并代码；软件工程师人均每季度交付的代码量是 2021 到 2025 年水平的 8 倍；获得实质审查评论的 PR 占比从 16% 升到 54%；超过一半的代码由其内部版 Claude Tag 合并，人类工程师转向设定意图与最终批准。还有一句反事实估算：过去 claude.ai 事故背后约三分之一的 bug，会被现在已实现的自动化流程捕获。文章里另有两组转述——Intercom 自动批准 19% 的 PR、部署量翻倍、破坏性代码变更造成的停机下降 35%；CircleCI 的 Chunk 让 agent 任务转化为已完成 PR 的比率翻倍。
问题不在数字大小，在口径。80% 是按行数、PR 数还是文件数算的，8 倍的“代码量”是什么单位、覆盖多少工程师、起点如何定义，这些都没有说明；“实质审查评论”由谁判定，其中有多少增量来自“要求 agent 提供证据”这条规则本身，也没有答案。三分之一是反事实推断，缺事故样本量、时间区间和判定方法。内部版 Claude Tag 与公开 beta 版本的关系同样未交代。Intercom 和 CircleCI 的数字是二手转述，原始材料不在这批来源里。这些缺口不是吹毛求疵：它们决定了数字能不能被另一个组织拿来当参照。
Anthropic 自己的贡献度统计反倒说明了口径有多要紧。Claude Code 的分析文档写明这套指标“刻意保守”、是对实际影响的低估：只统计对 Claude Code 参与有高置信度的行与 PR；归因窗口是 PR 合并日前 21 天到后 2 天；被开发者重写超过 20% 的代码不算；超过 1000 字符的行和自动生成文件排除；计入的有效行指归一化后超过 3 个字符的行，空行和只有括号标点的行不计。一家公司要对外公布自己的 AI 贡献度，通常得建一套可能低估自己的口径——而这个口径是它自己定的。这套指标还处于 public beta，只覆盖 claude.ai 组织内的用户，需要 GitHub 应用和管理员开关。
所以 80% 和你在自己团队里看到的数字之间，隔着统计口径、样本和组织结构三道坎。把它们当作厂商声明，而不是可移植的基准。
人审查速度成为上限之后，Anthropic 用多 agent 窄聚焦审查加人工抽样应对
Anthropic 称在多数开发者使用 agentic coding 工具并同时运行多个 agent 之后，团队速度受限于人类能够审查代码的速度。
- 瓶颈出现
官方称测试或 CI 阶段很快成为 AI 原生转型中最痛的瓶颈，因为人类审查速度成为上限。
it quickly became obvious the team could only move as quickly as humans could review code.
- 组合式审查
把自动化 agent 审查与确定性审查结合，人工审查保留给受监管或真正关键的代码，人的问责仍然居中。
combining automated agentic and deterministic reviews, while reserving human review for regulated or truly critical code
- 多 agent 分工
每个审查 agent 聚焦狭窄领域，并用检索增强获取过往事件上下文与记忆；理由是偏见不共享、一个出错可被其他 agent 捕获、精力不被摊薄。
Each review agent is designed and scoped to a specific, narrow focus and leverages RAG for additional context and memory surrounding past incidents.
- 人工问责与分级
代码库按风险分级，部分代码库保持严格人工批准；每次批准记录所用信号与理由，风险加权样本由人工复核。
Every approval is logged with the signals and reasoning behind it, and a risk-weighted sample is reviewed by humans.
- 结果数值
官方称获得实质审查评论的 PR 占比从 16% 升至 54%，并估算过去 claude.ai 事故背后约三分之一的 bug 会被现行自动化流程捕获。
approximately a third of the bugs behind past claude.ai incidents would have been caught by the automated processes we have now implemented.
结果：官方给出审查评论覆盖率从 16% 升至 54%、约三分之一历史事故 bug 可被捕获等自报数字，并称通过多 agent 加确定性与人工抽样维持问责。
不能据此证明：数字全部为发布方自报，没有对照实验、样本量与判定口径；Intercom 与 CircleCI 的数字为转述第三方，原始材料未抓取，不能作为独立验证。
含原文逐字引文
换掉的是流程，不是人的带宽
写代码不再是瓶颈之后，卡住的是判断的带宽——审查、授权、例外处理这些必须由人做的动作。整套设计服务的正是这件事：把人从每个阶段的起点挪到门禁上，让注意力只落在被标记出来的判断上。
有个细节很能说明问题。Anthropic 承认，并行会话的实际上限取决于一个人能认真审查多少条工作流，两到三条只是起点。agent 没有取消人的带宽上限，它换掉了上限的单位：从“能写多少”变成“能审多少、能做多少判断”。分档响应、hook 门禁、评测套件、提交链，都是在把这个新上限变得可测量、可排班。
因此判断这套方法适不适用于你，不看 agent 写代码有多快，看三件事：哪些控制必须永远成立——它们需要确定性层，光靠提示和 skill 不够；例外处理是否还走每周或每月开一次的委员会——那会让治理成本随代码量一起上涨；人工审查能不能被定义成一道可度量的门禁，而不是一句“我们会看”。这三条都能回答，流程改造才有落点。
改变判断的条件也很清楚。如果出现独立于 Anthropic 的实测，显示这套控制组合在非自家代码库上带来同等收益、且没有把风险推到门禁之外，它的普适性才算被支撑。在那之前，它是一份来自供应商、内部自洽的实践指南：机制描述具体到可以照着做，效果数字全部来自发布方自述或二手转述，没有独立复现。
最值得记住的可能不是那六个阶段，而是那条提交链。一份被接受、被提交、被读取的产物，比一场评审会更容易被审计。
类比带宽单位改变工厂自动化之后，车间里最忙的人从装配工变成了质检员——产量上去了，能检查的数量成了新天花板。
