代码生成正在从数周压缩到数小时，但多数软件组织周围的流程并没有同步提速。需求仍在等待会议，安全审查仍按固定周期进行，发布仍依赖人工交接；结果是构建阶段突然变快，整个系统的瓶颈却只是向两侧移动。
Anthropic 的判断是：AI 原生软件开发不能只在 Build 阶段增加一个编码助手。规划、设计、测试、部署和维护都要重新组织，而且人类不能退出责任链。真正需要改变的，是工作如何流动、证据如何留下、权限在哪里被截断。
#从流水线改成可追踪的循环
传统 SDLC 常被划分为 Plan、Design、Build、Test、Deploy、Maintain 六个离散阶段，每个阶段由不同角色负责，通过文档、工单和签字把工作移交给下一组人。这套制度产生于“写代码最慢、最贵”的时代，因此大量流程都在为一个持续数周甚至数月的构建阶段服务。
当 Agent 能快速生成大部分 diff，三个问题随之出现：
- 瓶颈移到构建之前和之后，尤其是需求澄清、评审测试与部署；
- 逐行人工审查不再能匹配代码产生速度；
- 例外仍要经过按周或按月召开的委员会，治理成本反而上升。
Anthropic 提出的替代方案不是取消六个阶段，而是把它们连成一个持续运行的循环。每一步都提交一个可被下一步读取的版本化工件：规划阶段产生 intent.md，设计阶段产生 spec.md，构建前产生 plan.md，随后留下代码 diff、测试结果、评审发现和事故记录。
Agent 可以沿着这些工件继续工作，人则在关键关口检查意图、证据和风险。这样做同时解决了速度与审计问题：上下文不再只存在于某次对话里，每次决策也能追溯到当时的输入和批准者。
#Plan：先提交意图，不要急着写规格
规划阶段的目标不是立刻生成一份漂亮 PRD，而是让最了解问题的人先把意图说清楚。
发起者可以与 Claude 一起讨论想法，但最终要用自己的语言确认并提交 intent.md。这份文件至少说明：要解决什么问题、为什么现在解决、影响哪些用户和系统、有哪些约束、哪些问题尚未回答。产品负责人检查并修正后，它才成为后续工作的正式输入。
这一步的价值在于把原始意图变成版本控制中的一等工件。设计或实现偏离方向时，团队不必从聊天记录和会议记忆中猜测最初目的。适合跟踪的指标也不再是开了多少次会，而是意图从提出到提交用了多久、有多少意图被接受，以及规格开始后又发生了多少意图级变更。
#Design：让需求与设计在同一个上下文中完成
进入设计阶段后，Claude 读取已经批准的 intent.md，再结合组织已有的品牌、安全、合规和 UX 规则生成 spec.md。如果约束互相冲突，或设计触碰政策边界，它应明确标注问题，而不是擅自做最终决定。
产品负责人仍然负责审查需求和设计，必要时请对应的政策所有者处理冲突。只有批准并提交的规格才能进入下一阶段。
这里最重要的变化，是减少产品、设计和工程之间反复转述造成的上下文损失。Agent 可以在同一个会话里把意图转成用户流程、界面结构和技术要求，人类则保留对体验、风险和优先级的判断权。
#Build：先批准计划，再开放执行权限
Anthropic 建议把 Claude Code 的 plan mode 设为默认起点。Agent 先只读代码库和规格，给出将修改哪些文件、按什么顺序实施、准备怎样测试、主要风险是什么。工程师可以追问、纠正，确认后再把 plan.md 与规格一起提交。
这道关口让团队在廉价阶段发现方向错误。计划获批后，成熟团队可以逐步启用自动编辑模式，让 Claude 在既定边界内连续修改，不再为每一处编辑等待确认；但如果实现偏离计划，计划本身也必须更新。
仓库还需要为 Agent 提供两类长期上下文：
CLAUDE.md保存新成员第一天就需要知道的命令、约定、架构和常见错误。它应保持短小；同一个错误出现两次，就值得写进去。- Skills 保存较稳定的机构知识，例如安全审查方法、品牌规则或团队工作流。它们适合指导判断，但凡是必须百分之百成立的限制，都应该再用 hooks 或独立评审强制执行。
Hooks 承担确定性护栏：阻止修改受保护路径、在编辑后运行格式化与 lint、拦截凭证泄漏。构建阶段的 hooks 应快速且范围明确；需要人批准的关口则留到部署阶段。
并行能力也要受人类审核带宽约束。独立任务可以在不同 worktree 中运行多个会话，重复性的局部工作可以交给 subagent；会修改同一批文件的任务仍应串行。起步时同时运行两三个会话通常比追求几十个并发更实际，因为真正的上限是团队能可靠评审多少产出。
#Test：把“完成”改成“带证据完成”
Agent 只有看到自己的工作结果，才可能稳定迭代。后端任务需要测试和构建输出，前端任务需要截图或浏览器结果；如果没有可观察反馈，它就只能根据代码形状猜测是否正确。
修复缺陷时，先写一个能够稳定复现问题的失败测试，确认它按预期失败并提交，再限制 Agent 修改这条测试，最后才修实现。这样可以减少“为了让 CI 变绿而改测试”的捷径。UI 工作则应让 Agent 反复比较截图与目标，而不是写完代码就停止。
因此，“完成”的定义应包含验证证据：执行了什么命令、哪些测试通过、构建结果如何、界面截图是否符合预期。持续反馈循环负责帮助实现收敛，最后还可以让一个独立 verifier subagent 检查验收条件，避免编写者同时充当自己的裁判。
Agent 配置本身也需要进入 CI。CLAUDE.md、skills、hooks、模型或 prompt 发生变化，都可能让过去能完成的任务退化。Anthropic 建议先整理 20 到 50 个真实任务及其可接受结果，配置变化时运行回归；生产事故则永久加入评测集。这样团队评估的是系统行为，而不是对某次演示的主观印象。
#Deploy：Agent 可以走到生产门口，但不能自己开门
PR 审查可以让 Claude 执行统一的缺陷、安全和合规检查，也可以让编写代码的 Agent 根据评审意见继续修正。人类评审者因此能把更多注意力放在产品意图、架构权衡和风险上。
不过，写代码的 Agent 不能批准自己的产出。代码所有者、分支保护和人工审批仍是明确的职责分离。团队可以用 REVIEW.md 规定必须执行哪些检查、严重程度如何定义、低价值建议最多多少条，以及哪些内容不应报告，再把反复出现的问题回写到项目指导文件中。
权限边界应使用确定性机制表达成允许、询问和阻止三种结果。生产部署必须要求具名授权；受监管环境还应通过不可由仓库覆盖的托管设置统一限制命令、凭证、hooks、插件和最低客户端版本。关键原则是默认失败关闭、凭证最小化、工具按白名单开放。
CI/CD 中引入 Claude 也应分层推进：先让它只读地分析失败和生成变更日志，再允许它在 PR 保护之下写入；测试环境可以有较高自主性，生产环境只允许它执行到审批门前。回滚必须是整个系统里演练最充分的路径，而不是出事后临时设计。
#Maintain：让生产信号重新变成新的意图
部署不是终点。生产监控应先由确定性规则判断指标是否越界，只在触发后调用模型做诊断。例如轻微偏差只记录，中度偏差要求分析，严重偏差才允许 Agent 提出 PR 或运行手册建议。
诊断结果不应直接变成未经审查的生产修改，而应写成新的 intent.md，重新进入规划、设计、构建、测试和部署循环。人类负责分诊并决定是否继续，事故样本则进入持续评测，防止同类退化再次发生。
定期代码库与安全扫描也遵循同一规则：边界明确且可以验证的问题进入修复 PR；涉及架构模式的发现返回规划阶段；任何修复都补充对应评测。模型可以扩大检查范围，但不能绕过人工批准或获得无限制的生产权限。
#一条更现实的落地顺序
这套 playbook 并不要求团队一次性重写全部流程。更稳妥的顺序是：
- 先建立
intent.md → spec.md → plan.md的工件链，让上下文能够被版本控制； - 给每类任务补上可重复的测试、构建或视觉反馈，把验证证据纳入完成定义；
- 用简短的
CLAUDE.md和小型 skills 固化高频知识； - 用 hooks 强制执行不可违反的边界，并保留人工部署门；
- 只对低风险、可验证任务逐步提高自动化和并行度；
- 把事故和配置退化沉淀为持续评测，让维护结果重新进入循环。
AI 原生 SDLC 的本质不是把现有流程中的人全部替换成 Agent，而是重新分配双方擅长的工作：机器负责快速生成、读取大量上下文和提供确定性证据；人负责定义意图、处理模糊性、批准高风险动作并承担最终责任。
代码越容易生成，这条责任链就越重要。真正成熟的系统，不是让 Agent 无条件走得更远，而是让它在每一步都留下下一位参与者能理解、能验证、能拒绝的工件。