代码不再是瓶颈:AI 正在重写软件交付的整条流水线

摘要：AI 把编码速度推高后，需求、审查、安全和部署开始成为新的等待队列。Anthropic 的 AI 原生 SDLC 给出组织级解法：用可提交工件连接六个阶段，让自动验证和治理规则跟着 Agent 运行，把人的注意力留给真正需要判断的关口。

本文根据 Claude 官方博客《The AI-Native SDLC playbook》编译并扩展解读，原文作者为 Louis Claxton。

过去，一个功能要做两周，需求会、技术评审和发布审批各花半天，似乎也能接受。

现在，coding agent（编程 Agent）可能一天就把代码写完。那几场会、几次排队和几份等待签字的文档却没有一起加速。实现阶段越快，周围流程的迟缓就越显眼。

安全团队最先感受到这种落差。过去，他们的审查能力按照人类工程师的代码产量配置。Agent 把代码产出成倍放大后，审查队列要么越积越长，要么为了赶进度而缩短检查。受监管企业很难接受其中任何一种结果。

2026 年 8 月 21 日，Anthropic 发布《The AI-Native SDLC playbook》，讨论的正是这个问题。SDLC 是 Software Development Life Cycle（软件开发生命周期），通常包含规划、设计、构建、测试、部署和维护六个阶段。

这篇文章表面上在列 Claude 可以参与哪些工作，底下其实藏着一个更大的判断：

当代码生成不再占据大部分交付时间，软件团队必须重新设计整条流水线。

一台机器提速，为什么整条流水线没有变快

可以把软件交付想成一条工厂流水线。

过去最慢的机器是「写代码」。产品需求、设计评审和发布流程都围绕它安排：反正实现要几周，多开两次会、多等一天审批，对总工期影响有限。

现在，这台机器突然提速了。上游还在靠会议澄清意图，下游仍要人工逐行审查，发布授权每周集中处理一次。结果很像工厂只升级了中间一台设备：它不断吐出半成品，前后工位很快堆满。

原文把新的阻塞点归纳为三类：

这里需要加一个边界。「代码不再是瓶颈」并非适用于所有团队。遗留系统改造、复杂架构决策和模糊业务问题，仍可能让实现本身非常缓慢。

Anthropic 讨论的是另一种场景：团队已经用 Agent 显著压缩了构建时间，整体交付速度却没有按同样比例提高。 此时继续优化代码生成，只会让等待队列转移得更快。

图 1：构建时间缩短后，瓶颈会迁移到「做对什么、证据够不够、谁来承担风险」。图中长度仅表达相对等待结构。

真正串起六个阶段的，是一条工件链

传统 SDLC 往往靠角色交接推进。产品经理写需求，架构师做设计，工程师实现，测试团队验证，发布团队上线，运维人员监控。信息装在文档、工单和会议纪要里，每次换人都要重新解释一次。

AI 原生 SDLC 换了一种连接方式。每个阶段都留下一个「下一阶段可以直接读取」的版本化工件：

intent.md（想解决什么）  → spec.md（决定怎样解决）  → plan.md（具体怎么实施）  → 代码差异 + 测试证据  → PR + 审查发现  → 部署记录 / 事故记录  → 新的 intent.md

intent.md 可以理解为意图说明书。它保留发起人的问题、目标、受影响对象、约束和开放问题。spec.md 把意图变成可设计的规格，plan.md 再把规格落到修改范围、实施顺序、风险和验证方法。

进入构建阶段后，核心工件不再只是 Markdown 文件，而是 diff（本次代码改了什么）、测试输出、PR 审查和发布记录。生产环境一旦出现异常，诊断结果又会被写成新的 intent.md，重新进入规划阶段。

这条链解决了三个实际问题。

第一，人和 Agent 终于围绕同一份状态工作。 人可以审查其中的判断，Agent 可以继续执行，不必从聊天记录里猜测上一阶段做过什么。

第二，提交动作可以触发下一阶段。被接受的 intent.md 触发规格生成，获批的 spec.md 进入规划，合并后的 PR 启动部署，生产指标越界则生成新的诊断任务。

第三，版本历史自然形成审计线索。谁提出需求、Agent 生成了什么、哪位负责人批准、实施为何偏离计划，都能沿提交和审查记录回看。

Markdown 本身没有魔法。真正有用的是四个属性：可被人读懂、可被机器继续处理、修改有版本记录、每类信息有明确的事实源。

图 2：工件链既是人机共享的状态，也是阶段触发器和审计线索；生产异常会形成新的 intent.md。

如果需求必须留在 Jira，设计必须留在 Figma，变更审批必须留在 ServiceNow，团队完全可以继续使用这些系统。关键是明确哪一边是权威记录，并让另一边保存记录 ID 或提交 SHA（某次 Git 提交的唯一编号）。否则，两份内容都在更新，很快就会出现两套「最终版本」。

六个阶段，可以看成三个闭环

逐项罗列六个阶段，容易把这套方案看成一张功能清单。把相邻阶段合起来，更容易看清它的运行机制。

从想法到规格：压缩信息转述

在规划阶段，需求可以从个人想法、工单或生产告警进入。发起人先用自己的语言说明问题，Claude 协助追问用户、范围、限制和成功标准，再整理成 intent.md。

产品负责人仍要修改和批准这份文件。这个动作很重要，因为语言流畅的需求文档也可能准确地记录了一个误解。

进入设计阶段后，Agent 根据 intent.md 生成 spec.md。品牌、安全、合规和用户体验要求可以整理成 Skills，也就是在相关任务出现时加载的可复用说明。政策因此能在规格形成时参与约束，而不必等代码写完后才集中挑错。

这两个阶段缩短的是「信息经过多人转述」的距离。发起人的原始意图先被保存，再逐步结构化。产品负责人不必从空白页写完整文档，但要对问题定义、取舍和冲突负责。

从规格到证据：让 Agent 自己发现错误

构建阶段先产生 plan.md。工程师让 Agent 读取规格和代码库，写清改哪些文件、按什么顺序做、哪里风险最高、怎样证明完成。计划获批后才进入实现。

这相当于把技术评审提前到代码生成之前。方向不对时，修改一页计划远比推翻一大段代码便宜。

项目知识也要从人的记忆里移出来。CLAUDE.md 保存构建命令、架构约定和 Agent 经常犯的错误；Skills 保存需要重复执行的制度和检查表；Hooks（钩子）则在指定事件发生时自动运行，例如阻止修改受保护目录、在编辑后执行格式化、避免凭证进入代码差异。

到了测试阶段，每次 Agent 工作都必须获得反馈通道：运行测试、执行构建、检查接口返回，或者比较页面截图。它先根据反馈修正自己的错误，再把结果交给工程师。

这里还有一层容易被忽略的测试：Agent 的配置也会回归。CLAUDE.md、Skills、Hooks、模型或 prompt 发生变化，可能让同一任务得到不同结果。因此原文建议维护一组真实任务作为 Evals（评测集），像回归测试代码一样回归测试 Agent 的工作方式。

从审查到维护：让异常重新进入交付链

部署阶段，AI 可以先按统一规则审查每个 PR，区分逻辑错误、安全问题和规格偏离，再处理审查意见。人类审查者不必把注意力平均分配给每一行，而是重点判断：改动是否符合意图，风险是否可以接受，验证证据是否充分。

写代码的 Agent 不能批准自己的 PR。分支保护、代码所有者审批和生产授权仍然存在。Agent 可以一直工作到生产门禁之前，不能自行越过它。

维护阶段则把线性流程变成循环。一个确定性监控脚本观察测试失败率、部署后的服务器错误率或其他稳定指标。指标进入不同控制带后，系统分级响应：轻微波动只记录，明显异常调用 Agent 做只读诊断，更严重的异常允许它通过 PR 提出修复，或者触发事先批准的回滚手册。

这里的顺序不能颠倒。阈值由可测试的监控规则决定，Agent 在越界后负责解释和行动。 模型不能一边观察生产，一边自行决定什么算事故，再给自己扩大权限。

诊断最终写成新的 intent.md。修复重新经过规格、计划、测试、审查和部署；事故还会加入 Eval，成为以后不能再次失败的案例。到了这一步，SDLC 才真正首尾相接。

AI 原生治理，需要五层控制

Agent 参与的环节越多，治理就越不能依赖「大家记得遵守」。Anthropic 的方案可以整理成五层：

图 3：前两层提供上下文与建议，后三层给出不可绕过的边界、可检查的证据和最终责任授权。

Skills 和 Hooks 的差别尤其关键。

Skill 告诉 Agent「遇到外部 API 时应该检查认证、输入验证和日志脱敏」。它能显著降低遗漏，却仍属于模型需要理解和执行的说明。

Hook 可以在动作发生前检查命令和文件路径，条件不满足就直接阻止。Anthropic 的官方文档把它称为 deterministic control（确定性控制）：规则触发时一定执行，不依赖模型是否想起来。

权限和沙箱又补上另一层。工具权限决定某类操作是否需要批准，沙箱则由操作系统限制命令能访问的文件和网络范围。即使一条终端命令试图绕过上层工具，它仍会撞上隔离边界。

测试和 Evals 负责提供证据。测试证明这一版代码在既定场景下能工作，Evals 检查 Agent 的配置变化有没有削弱完成任务的能力。它们都需要持续维护，无法写一次便永久有效。

最后一层仍是人。AI 可以整理证据、标出冲突和执行预案，风险取舍、合规例外和生产责任仍要由有权限的人承担。

这是一张目标架构图，不是现成答案

这份 playbook 很完整，也很容易让人产生一种错觉：只要照着创建几个 Markdown 文件、装上 Hooks 和 Evals，AI 原生 SDLC 就搭好了。

现实会更麻烦。

首先，原文总结的是 Anthropic Applied AI 团队的客户实践，许多环节直接使用 Claude Code、Claude 集成和 Anthropic 的企业控制能力。它提供的是一套目标架构，没有给出跨公司对照实验，也没有证明所有团队都能获得同样收益。

其次，工件越多，漂移风险越高。intent.md、Jira 工单和产品文档如果同时被当作权威记录，Agent 只会更快地放大矛盾。每类信息必须指定一个事实源，其余位置只保存副本或链接。

更难的是人的注意力。自动生成计划、代码、测试和审查意见后，评审者面对的材料会更多。若团队只追求「全部通过」，人工批准很容易退化成盖章。此时新的瓶颈转向了人的判断能力：有没有足够的人理解意图、判断风险并拒绝可疑结果。

因此，落地时不适合一次改造全部六个阶段。更稳妥的做法，是选择一条重复、边界清楚、结果可验证的工作流，例如处理 CI（持续集成）失败：

1. 先规定什么事件触发任务，保存哪些日志和代码差异；
2. 再写清 Agent 可以修改什么，连续失败几次必须停下；
3. 给它一条无法自行削弱的验证路径；
4. 所有修改只通过 PR 进入代码库，由人批准合并；
5. 观察处理时间、首次验证通过率和返工次数，再决定是否提高自治等级。

当 Agent 接过执行，工程师要写清三件事：下一步由什么触发，完成由什么证据证明，哪一步必须停下来等人。

参考资料

1. Louis Claxton：The AI-Native SDLC playbook^[1]，Claude Blog，2026-08-21
2. Anthropic：Extend Claude with skills^[2]，核查于 2026-08-29
3. Anthropic：Automate actions with hooks^[3]，核查于 2026-08-29
4. Anthropic：Configure the sandboxed Bash tool^[4]，核查于 2026-08-29

引用链接