本文为参考文章内容简介，由 AI 整理生成。
Anthropic 在《The AI-Native SDLC Playbook》里讨论的，不是怎样更高效地用 Claude Code 写代码，而是一个更大的变化：当 AI 已经把“写代码”这个环节大幅加速之后，软件研发流程本身是否也应该被重新设计。
这篇 Playbook 的核心判断很直接：传统 SDLC 是围绕“人写代码很慢、很贵”这个事实组织起来的。现在 Build 阶段被 Coding Agent 压缩之后，需求澄清、技术设计、Review、测试、发布和治理这些环节会暴露为新的瓶颈。AI-Native SDLC 要解决的不是让 Agent 多写几行代码，而是让整个研发链路都变成 Agent 可以读取、执行、反馈、审计的闭环。
SDLC 是什么
SDLC 是 Software Development Life Cycle，也就是软件开发生命周期。大多数组织都会有类似的阶段：
1 | Plan -> Design -> Build -> Test -> Deploy -> Maintain |
对应到日常工作里，大概就是需求、方案、编码、测试、上线和维护。
传统 SDLC 的流程通常比较重。产品经理写需求，架构师或资深工程师写设计，工程师实现，QA 或安全团队做验证，发布团队控制上线，运维或 SRE 监控生产环境。每个阶段之间通过 PRD、设计文档、Jira、PR、审批单和发布记录交接。
这些流程并不是无意义的仪式。它们承担的是对齐、问责和风险控制。但它们背后的一个隐含假设是：真正耗时的是写代码。既然一个功能可能要写几周甚至几个月，那么在写之前花时间做需求评审、排期、架构设计和安全审批，是可以接受的。
AI Coding 改变的是这个成本结构。
Build 不再是唯一瓶颈
当 Coding Agent 可以在几小时内完成过去几天的实现，原来围绕 Build 设计的流程就会显得不匹配。
以前的节奏可能是：
1 | 需求 -> 设计 -> 很长的编码周期 -> 测试 -> 上线 |
现在变成：
1 | 需求 -> 设计 -> 很短的编码周期 -> 很长的 Review / Test / Deploy |
瓶颈开始向 Build 左右两侧移动。
左侧的问题是需求和设计。Agent 可以快速实现，但它仍然需要知道“到底要解决什么问题”、“有哪些约束”、“什么结果算成功”。如果这些信息还停留在会议、聊天记录和人的脑子里，Agent 只是更快地把不清晰的需求写成代码。
右侧的问题是 Review、Test 和 Deploy。人工逐行 Review 原本就慢，只是在代码产出速度较低时还能勉强跟上。一旦 Agent 让代码产出成倍增加，安全审查、QA、发布审批都会排队。要么代码堆在队列里，要么为了赶进度带着不足够的验证上线。
所以 AI-Native SDLC 的重点不是取消控制，而是把控制方式从“人在每个阶段手工检查”改成“机器可读的产物、自动化的检查、分层的人类判断”。
从线性流程到产物闭环
Anthropic 给出的关键线索是：每个阶段都应该产生一个能被下一个阶段直接消费的版本化产物。
这个链路可以概括为：
1 | intent.md -> spec.md -> plan.md -> code/tests -> PR/review -> production metrics -> intent.md |
intent.md 记录最初的意图。它不是完整 PRD，而是把问题、目标、约束和成功标准写清楚。例如要解决什么用户痛点，不能破坏哪些兼容性，有哪些安全、性能、合规限制。它既要让人读得懂，也要让 Agent 能继续处理。
spec.md 把意图展开成设计。这里会包括接口变化、数据模型、边界条件、迁移方案、风险点和验收标准。传统流程里 Requirements 和 Design 往往分属不同角色；AI-Native 的做法是让 Agent 基于 intent.md、代码仓库和组织规则生成初稿，再由人 review 和修正。
plan.md 则更接近执行计划。它回答怎么分步改、先改哪里、测试怎么补、哪些地方需要人工确认。这个计划不是为了让人看起来放心，而是为了给后续编码 Agent 一个可执行的路线。
随后才进入 code/tests。实现和测试一起成为可验证的 diff，而不是先写代码、最后补文档。PR 和 review 记录继续保留问题、风险、检查结果和人工判断。上线后，production metrics 又会把真实运行状态反馈回来：如果某个控制指标越界，或者线上暴露新问题，这些信息会重新进入下一轮 intent.md。
这样 SDLC 就不再是一条单向流水线，而是一个持续闭环。每个阶段提交的产物，既是下一阶段的输入，也是未来审计时的证据：当时想解决什么，Agent 生成了什么，人批准了什么，生产环境后来发生了什么。
工程知识要机器可读
Agent 要做好软件工程，光有代码仓库是不够的。真实研发依赖大量组织知识：命名规范、模块边界、发布要求、安全禁区、历史事故、架构取舍、常用命令、测试习惯。这些东西如果只存在于老员工经验里，Agent 就只能靠猜。
Anthropic 在 Playbook 里强调的 CLAUDE.md 和 Skills，本质上是在把工程知识变成机器可读的上下文。
CLAUDE.md 适合记录仓库级、目录级的约定，例如如何构建、如何测试、哪些目录不能随便改、提交前必须跑哪些检查。Skills 则更适合把可复用流程封装起来，例如“如何做安全评审”、“如何生成迁移计划”、“如何处理某类 incident”。它们不只是给人看的文档，而是 Agent 工作时可以加载和执行的操作手册。
这里的关键不是把所有文档都塞进 Prompt。上下文窗口仍然是稀缺资源。更合理的方式是把知识结构化、版本化，并让 Agent 在需要时按需读取。工程组织过去为人建立 Wiki、Runbook 和 Onboarding 文档；AI-Native SDLC 需要为 Agent 建立同样严肃的工程知识体系。
Continuous Evals 替代阶段性大检查
测试阶段也需要变化。传统 QA 往往是阶段边界上的大检查：实现完成后，再统一测试、回归、验收。这个模式在人写代码的速度下可以工作，但面对 Agent 持续生成的大量改动，很容易变成队列瓶颈。
AI-Native SDLC 更强调 Continuous Evals，也就是把评估嵌入实现过程。单元测试、集成测试、静态检查、安全扫描、性能基线、契约测试、业务验收用例，都应该尽量成为 Agent 修改代码时持续收到的反馈。
这和“多写测试”不是一回事。Continuous Evals 的目标是让 Agent 在行动过程中不断知道自己有没有偏离意图，而不是等到最后才由人发现方向错了。好的 eval 应该能回答几个问题：需求里的成功标准是否满足，关键风险是否被覆盖，已有行为是否被破坏，安全和合规约束是否仍然成立。
当 eval 可以稳定运行，Agent 就能基于失败结果继续修复。人的注意力则从“手工检查所有细节”转向“判断 eval 是否覆盖了真正重要的风险”。
Review 要分层
代码产出速度提高后，逐行 Review 每一个 diff 不再现实。更合理的方式是分层 Review。
第一层是 Agent 自查和工具检查。格式、Lint、类型、测试、依赖边界、简单安全规则，都应该由自动化先挡住。
第二层是 Agentic Review。可以让独立的 Agent 从不同角度审查同一个 PR，例如一个看安全，一个看兼容性，一个看测试覆盖，一个看是否符合 spec.md 和 plan.md。这类 Review 不应该取代人，而是负责把大量低层问题和明显遗漏先筛出来。
第三层才是人类 Review。人不应该把主要时间花在拼写、格式、简单重构建议和机械检查上，而应该集中判断：这个需求是否值得做，设计是否解决了真实问题，风险是否被低估，回滚方案是否可信，是否触碰了核心业务和合规边界。
也就是说，AI-Native SDLC 不是让人退出 Review，而是让人的 Review 更靠近判断本身。
Governance as Code
治理是很多组织里最容易被低估的瓶颈。安全、隐私、合规、发布策略、数据访问规则，过去常常依赖会议、审批和委员会节奏运行。Agent 让代码变化更快后，这些治理机制如果仍然以周或月为单位，就会成为系统性阻塞。
Governance as Code 的思路，是把治理要求尽可能编码成可执行规则。哪些目录变更必须触发安全评审，哪些 API 不能返回敏感字段，哪些依赖不允许引入，哪些服务必须满足发布窗口和回滚要求，哪些数据操作需要额外审批，这些都不应该只停留在文档里。
在 Agent 工作流里，治理规则可以通过 CI、Hook、Policy Engine、权限系统和发布门禁执行。规则通过时自动放行，触碰高风险边界时再升级给人。这样治理仍然存在，但它跟上了 Agent 的速度。
这点很重要：AI-Native 不是弱化治理，而是让治理从事后审批变成过程约束。
工程师的角色变化
如果代码不再主要由人逐行写，工程师的价值会向哪里移动？
这篇 Playbook 给出的答案并不是“工程师不重要了”，而是工程师的工作重心会向 SDLC 上游和风险判断移动。
工程师需要更擅长定义 Intent：把一个模糊想法拆成问题、目标、约束和成功标准。Intent 写得不好，Agent 只会更快地产生错误结果。
工程师也需要 review Spec 和 Plan：判断 Agent 生成的设计是否真的理解了系统，是否遗漏了兼容性、迁移、性能、安全和回滚问题。未来很多工程风险不会出现在单行代码里，而会出现在错误的计划和错误的抽象边界里。
最后，工程师仍然要做判断。哪些检查可以自动化，哪些风险必须人工批准；哪些改动可以快速试错，哪些改动必须保守推进；哪些线上指标说明系统正常，哪些异常应该重新进入研发闭环。这些都不是简单的代码生成问题。
所以 AI-Native SDLC 对工程师提出的要求，反而更接近软件工程的本质：定义清楚的问题，设计可验证的系统，建立有效反馈，控制复杂度和风险。
小结
Anthropic 这篇 Playbook 最有价值的地方，是把 AI Coding 从“开发工具效率提升”放回了完整软件工程流程里看。
如果只优化 Build，组织很快会撞上新的瓶颈：需求不清、设计跟不上、Review 排队、测试不足、发布和治理无法扩展。真正的 AI-Native SDLC，需要把每个阶段都沉淀为机器可读、可版本化、可审计的产物，并让 Agent 和人围绕这些产物协作。
intent.md -> spec.md -> plan.md -> code/tests -> PR/review -> production metrics 这条链路的重点，不是具体文件名，而是它代表了一种新的研发接口：人的判断变成结构化输入，Agent 的工作变成可验证输出，生产环境反馈重新回到下一轮意图。
写代码会越来越便宜，但把正确的东西、以可控的方式、持续交付到生产环境，仍然是软件工程。