「AI 不再只是写代码，AI 在重写整个软件公司」——Anthropic 8-21 发布《AI Native SDLC Playbook》，把 SDLC 从直线改造成循环

北京时间 2026-08-27 13:00 · 智柴 AI 推送 · AI 编程与软件工程栏目

图片来源：Anthropic 官方博客 8-21 Louis Claxton + Founder Park 8-25 编译

一句话警语

2026 年 8 月 21 日，Anthropic 应用 AI 团队的 Louis Claxton 写了一份 8000 字的内部方法论外发件，标题就叫《The AI Native SDLC Playbook》。它的论断只有一句，但能压碎整条行业的旧叙事：

「代码已经不再是瓶颈。」

过去十年里所有工程团队围绕写代码这件事堆出来的流程——PRD、估时会议、code review、合规审查、PR 审批、发布门禁——它们的全部假设都是：写代码是最慢、最贵、最容易出错的环节。现在这个假设被 agent 一次性打穿了。Claude Code 这种工具把代码生成速度压到了「天/小时」量级，传统 SDLC 瞬间变成了沙漏的两头粗、中间细——中间细是 agent 跑的，两头粗是人在扛的、跟不上 agent 速度的 review 和审批。

Anthropic 的解法是把传统 SDLC 拆成六段（Plan/Design/Build/Test/Deploy/Maintain）然后再粘成一个 Loop，每一段提交一份版本控制的产物（intent.md / spec.md / plan.md / 代码 diff / PR / 事故记录），下一段读这份产物再开始。这条 commit 链本身就是审计链：谁提了什么需求，agent 产出了什么，谁批准了它。

把这套方法论放回 2026 H2 的现实地图上读，它就是一份针对 Shopify CEO Tobi Lütke 8-25 公开威胁禁用 Claude Code 事件（详见 8-26 早间 Topic）的官方回应——Anthropic 在告诉所有企业客户：「Code 写完不是终点，从 intent 到 incident 的闭环必须全部交给 AI 跑；你要担心的不是 AI 写得太快，而是 review 和 deploy 这两段是不是同时升级。」

🧭 为什么 SDLC 的中心从「build」位移到了「build 的两侧」

要在脑子里把这件事看清楚，得先回看一下软件行业用过去 40 年堆出来的传统流程。

传统 SDLC 的六个阶段几乎所有 CS 学生都背得出来：Plan / Design / Build / Test / Deploy / Maintain。每个阶段之间靠三件东西串联——文档、工单、签批。流程设计者当年做这个设计的时候有一个心照不宣的共识：build 阶段是耗时大头，一写几周几个月，所以评审、测试、合规这些门禁设得严一点值。

Claude Code 出来之后这个共识垮了。

具体表现在三个症状上：

1. 瓶颈位移——build 阶段从「几个月」被压到「几小时」，但 build 两侧的 Plan、Review、Test、Deploy 还停在「数天-数周」。原本设计来保护 build 的安全审查、PR 队列、发布门禁全部被代码淹了；
2. 治理脱节——当 agent 一次性产出几百行代码，逐行 code review 在物理上就跟不上。要么 review 队列越堆越长，要么代码未经审查就上线；
3. 审计黑洞——传统流程里，治理证据是 JIRA ticket + Confluence 文档 + Git commit + 邮件抄送。agent 跑过之后，谁提了需求、谁批准了什么、agent 自己做了哪些选择，全都散在 IDE 终端里。

Anthropic 在 Playbook 里给了一个很重要的判断：当构建不再是约束时，约束来自构建两侧那些以人类速度运行的环节。这是 SDLC 历史上的第一次约束位移——从 build 移到了 build 的两边。

🪢 Loop 的核心：每个阶段提交一个版本化的产物

AI Native SDLC 最反直觉、也最容易被误读的设计是：循环，而不是直线。

传统 SDLC 是个从 Plan 到 Maintain 的瀑布流；AI Native SDLC 是个闭合的循环，每个阶段结束时往版本控制里写一个产物，下个阶段从读这个产物开始。Anthropic 给这种产物起了一个专门的名字——committed artifact（提交过的产物）。

每一份产物的设计目标可以概括成一句话：让人和 AI 都能读、都能继续写、都能追溯。Plan 阶段的产物是 markdown 文件，因为产品负责人和 agent 都能读；Build 阶段以后的产物是代码和它的元数据，因为只有代码才能执行。

这条 commit 链本身就是审计链——这是整篇 Playbook 里最重要的设计直觉。谁提了 intent、agent 产出了什么 spec、谁批准了 plan、PR 上的 review 结论是什么、事故的处理记录是什么，全部在 git 历史里。审计不需要单独的 JIRA ticket + Confluence 文档 + 邮件抄送——Git 就是审计系统。

🔧 三层规则把 agent 绑在轨道上

Loop 设计漂亮，但光靠 Loop 不够——agent 在每一段都可能被自己的幻觉带跑偏。Anthropic 给出的护栏是一个三层递进的规则体系：

🟦 CLAUDE.md —新人入职第一天的说明书

CLAUDE.md 放在仓库根目录，相当于一份「agent 也要遵守的入职手册」。它包含：

• 项目命令（build / test / lint 怎么跑、分别在什么环境跑）；
• 代码规范（Java 21 + Spring Boot 3、金额永远用 BigDecimal、接口必须配集成测试）；
• 架构约定（api 放 REST、core 放领域、adapters 接外部、Kafka 事件在 schemas/）；
• Claude 容易犯的错——这一节是动态更新的，规则是「Claude 犯同一个错两次，纠正就进 CLAUDE.md」。

控制在一页以内。整份文件的人话翻译是：「把过去存在人脑里和 wiki 上的知识，变成 agent 每次会话开头都读一遍的文件」。

🟨 Skill —可复用、可版本化的组织知识

Skill 是「某类活该怎么干」的可执行规则。例如一条「安全 API 审查」Skill：

name: secure-api-review
description: 应用 API 安全标准。在创建或修改面向外部的接口、审查 API 代码或生成 OpenAPI 规格时使用。

调用时它告诉 Claude：每个接口都需要网关 JWT、/health 之外不允许匿名路由、根据 OpenAPI schema 验证请求体、每个状态变更接口都必须发审计事件……这些规则不是在 review 时被发现，而是在 spec 撰写时就被应用。

Skill 比 CLAUDE.md 更聚焦——CLAUDE.md 是项目全局，Skill 是任务级别的。Skill 写在 .claude/skills/ 目录下，版本化、分发、迭代。

🟥 Hook —绝对不能碰的红线

CLAUDE.md 和 Skill 都是「指导性」规则——它们告诉 agent 应该怎样做，但不能保证每次都做到。Hook 是「确定性控制」机制——agent 修改受保护文件、接触敏感信息、执行发布命令时，Hook 会立即检查，不符合规定直接拦下。

Hook 的意义是：把那些不能靠 prompt 解决的硬约束编码进自动化。例如发布命令需要具名发布负责人授权、修复 bug 时禁止 agent 修改测试文件、PR 触发自动跑全套测试 + lint——这些不是「agent 应该记得」，而是「agent 不能违反」。

🔄 六个阶段的 Play：每段都在解一个具体的卡点

Playbook 的实操部分由六段组成，每一段都给「变化了什么 / 如何开始 / 实施步骤 / 治理考量 / 度量指标」五件套。我们一段一段拆。

📝 第一段 Plan：用 intent.md 捕获意图

传统 SDLC 里的 Plan 阶段是「需求积压 → 用户故事 → 精化会议 → 工单 → 工程团队开始行动」。AI Native SDLC 的 Plan 阶段只有三步：

1. 发起人和 Claude 直接头脑风暴——发起人用自己的话讲问题，Claude 像分析师一样追问范围、用户、约束、成功标准；
2. Claude 按组织模板写成 intent.md——模板本身可以编码成一条 Skill；
3. 发起人修正理解偏差，提交到共享仓库——一个连接到 GitHub 的 connector 可以让不会用 git 的人在 Cowork 或 claude.ai 里直接提交 markdown。

一份 intent.md 长这样：

# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.

## Problem
Customers phone the contact center to ask where their claim is. Handlers spend roughly a third of call time on status-only queries.

## Proposed outcome
Customers see claim status, next step and expected date in the portal.

## Affected users and systems
Claims handlers, portal team, claims-core API.

## Constraints
No new PII in the portal session. Existing authentication only.

## Open questions
Do third-party loss adjusters need access too?

治理记录：作者 + 时间戳 + 完整修订历史都在 intent 仓库的 git 历史里。产品负责人审批，决策以合并或关闭 review 的形式记录。

🎨 第二段 Design：需求和设计压缩成一次会话

传统 SDLC 的 Design 阶段是「分析师把需求正式化 → 设计师再解读」，两个阶段，重复工作。AI Native SDLC 把这两个动作合并成一次 prompt 会话：

1. 产品负责人打开加载了组织 Skills 的会话，附上 intent.md；
2. Claude 在 Brand/Security/Compliance/UX Skills 约束下写出 spec.md；
3. 产品负责人对照原始意图审查 spec，先解决标记的关注点；
4. spec.md 和 intent.md 一起提交到仓库。

这一步的关键不在 Claude 写得多快，而在 「Skills 在 spec 写的时候就被加载并执行」——传统 SDLC 里 Skills 是几周后的 review 才发现冲突，AI Native SDLC 里 Skills 是写在 spec 同一条 commit 里。冲突在源头被消除，而不是在 review 里被发现。

🏗️ 第三段 Build：Plan Mode 让 agent 先写计划再写代码

这是六个阶段里设计最细的一段，也是 Shopify 事件的核心回应。

传统 SDLC 的 Build 阶段是「工程师读完设计文档开始写代码」。AI Native SDLC 的 Build 阶段是Plan Mode——Claude 在 plan 模式下可以读代码库、列出要改的文件、规划工作顺序、写出测试策略，但在被工程师接受之前不能修改任何文件。

Anthropic 给出的实操经验是：Plan Mode 强制执行「设计评审先于代码生成」。方向错了，改的只是 markdown 文件；方向错了再写代码，那是一千个文件的灾难。

计划通过后还有 auto mode——Claude 自动逐个应用变更，不需要每次编辑都让人确认。但 auto mode 的开启是有条件的：

Auto-accept 是结果，不是起点——Playbook 里明确警告「在没有这些护栏之前就用 auto mode，是把自己交给幻觉管理」。

🧪 第四段 Test：让 agent 自己做测试，再让另一个 agent 复核

Test 阶段最容易踩的坑是：agent 写完代码，跑了几个测试，报告「已完成」。但 agent 自己的测试经常是「我跑了我能跑的东西」。

Playbook 给的解法分四层：

最反常识的设计是**「用一个全新的对话来复核」**——同一段对话里的 Claude 自己检查自己，会沿用同一条思路，所以复盘要从外部看。Anthropic 把这一条编码进了 CLAUDE.md 的「完成」指令里，要求 agent 在报告完成前先自己跑完三件套并粘贴输出。

🚀 第五段 Deploy：让 agent 准备上线，但人守最后一关

Deploy 阶段的核心动作是 PR + Hooks 门禁。

REVIEW.md 规定审查顺序：先找逻辑错误 → 再查安全漏洞 → 再对照 spec.md 和 plan.md 看有没有跑偏。PR 获批后，CI/CD 自动接管。

最关键的设计是**「权限分级」**：

Anthropic 在自己内部就是这样干的——How Anthropic secures its AI-native software development lifecycle 那篇配套博客详细记录了内部的具体实现。

🔁 第六段 Maintain：让线上事故回到 intent.md

Maintain 阶段不只是「运维团队盯着生产环境」，而是**「让 agent 自动回到 Plan」**。

监控脚本盯住错误率、延迟、SLO 等指标，一旦越界，agent 做只读诊断（只查不改）；严重时提出修复方案或触发事先批准好的回滚。修复方案被批准后，处理结论被写成一份新的 intent.md，回到第一步。

这一步是 Loop 真正闭合的地方——线上事故不是终点，是下一轮开发的起点。Anthropic 把线上事故加入永久 Evals 库，作为回归测试——这是 SDLC 历史上的第一次「事故即测试」。

🏗️ 落地的依赖图：先补哪一项再补哪一项

Playbook 给了一张非常实用的依赖图——这六段不是必须按顺序落地的。

落地的时候，缺哪一项补哪一项——这是 Anthropic 反复强调的反「全栈改造」原则。没有一家公司需要从第 1 层一路做到第 5 层；如果你的卡点是「AI 总改坏测试文件」，加一个 Hook 就够了；如果你的卡点是「需求总在 build 中变」，先用 intent.md；如果你的卡点是「换模型后效果退步」，加 Evals。

⚖️ 一个被公开挑战的细节：被忽略的「需求工程」

Playbook 几乎被所有 AI 公司当作方法论标杆转发，但有一篇非常犀利的批评值得放进来——Martinelli 的《Code Is No Longer the Bottleneck. Requirements Are.》。

批评者 Simon Martinelli 在自己的 blog 上指出：

「Playbook 说代码不再是瓶颈，所以 build 之前的一切都可以被压缩。我想说正相反。当代码变得便宜时，唯一剩下的杠杆就是需求的质量。一个 agent 用一小时从坏 spec 生成 5000 行代码，就是用一小时生成 5000 行错代码。」

具体批评包括：

1. 只有一个 stakeholder——Playbook 把需求来源描述为「a person with an idea」。真实项目里，参与方往往是多部门、多利益相关方，真正的需求工程是发现并解决这些冲突；
2. 没有分析过程——从「想要什么」到「系统必须做什么」这一步被简化成一个 prompt。完整性、一致性、可测试性这些活动被默认由模型自己完成；
3. 没有结构——spec.md 是散文式文档，没有 use case、没有领域模型、没有业务规则；
4. 非功能需求被隐藏——性能、可用性、数据保护只在 Skills 里出现，没有被作为显式、可度量的需求；
5. 可追溯性被简化为 Git 时间戳——Playbook 度量的是「intent.md 提交快不快」「spec.md 在 build 中改了几次」，衡量的是速度，不是质量。

批评者的替代方案叫 AI Unified Process (AIUP)——以 use case 为核心，每个 use case 有 actors、preconditions、main success scenario、alternative flows、postconditions、business rules，agent 可以从 use case 派生代码和测试。

Anthropic Playbook 不是错了——它写给大企业，那里 PRD 走三道委员会最后没人记得原始需求是什么，相对这种状态「一人一 agent、一天 git 上线」是巨大进步。但Playbook 的基本假设「代码不再是瓶颈所以之前的一切可以压缩」在原理上是危险的——当代码便宜时，需求质量是唯一剩下的杠杆；用坏 spec 加速 agent 只是加速生成错误代码。

🗓️ 这件事的真正背景：Shopify 公开施压的反向回应

把 Playbook 放回 2026 H2 的产业地图上看，它不只是方法论，也是Anthropic 对 Shopify 8-25 公开施压的正式回应。

Shopify CEO Tobi Lütke 8-25 在 X 上公开威胁禁用 Claude Code，理由是 Anthropic 拒绝读 AGENTS.md 这个开放标准（详见 8-26 早间 Topic）。Anthropic 同周关闭了两个相关 feature request。

Shopify 的施压逻辑是：「你的 agent 应该遵守行业标准（AGENTS.md），而不是你的私有规范（CLAUDE.md）。」Anthropic 的回应用了一份 8000 字的 Playbook——「我们不是不读上下文，我们是要把整个行业重写。」 Playbook 里反复出现的「commit chain as audit trail」「Skills as organization knowledge」「Hooks as deterministic guardrail」全部都是 Anthropic 自己在用的私有规范——它不是在投降，是在把私有规范抬升成行业方法论。

这场博弈的关键不在于 AGENTS.md 读不读，而在于 「AI coding 工具的治理边界由谁定」——Shopify 想要的是 agent 读开源协议；Anthropic 想要的是企业把 SDLC 全套流程接入自己的私有规范。Playbook 是 Anthropic 把私有规范包装成「行业最佳实践」的尝试——如果全行业都按 Playbook 改造 SDLC，那 CLAUDE.md 就是新的事实标准。

🔭 落地一周后的真实反应

Playbook 发布一周内，至少四类公司做出了回应：

1. Foundation model 公司：OpenAI、Google DeepMind 在 Playbook 发布后的 48 小时内转发，承认传统 SDLC「确实不再适用」，但未公开自家改造细节；
2. 企业 CI/CD 厂商：GitHub Actions、GitLab CI 都在加「agent-aware」流水线门禁；
3. 开发者工具：Cursor 立刻在自家产品文档里加了 CLAUDE.md 兼容层（兼容 AGENTS.md 的同时支持 Claude 的 Skills）；
4. 创业公司：Ramp、Block、Stripe 等至少五家硅谷独角兽公开承认在用 Playbook 改造内部 SDLC（Ramp 自建的 Inspect agent 详见 The Pragmatic Engineer 8-26 长报道）。

「协议治理元年 = Harness 元年之后」 ——这是 2026 H2 的核心位移之一。8-26 早间 Topic 提到的 Shopify 事件是前哨，8-21 的 Playbook 是主炮。两件事同周发生，叠加 8-27 早间 Topic 的 Harvey Tenet 事件，三件事共振出一个清晰的趋势：

AI coding 的护城河正在从「模型能力」位移到「部署栈」。模型越来越同质化，差异化在 SDLC 改造的深度。

📌 关键洞察备忘

🔗 参考资料

[1] Anthropic 官方《AI Native SDLC Playbook》Louis Claxton 2026-08-21 — https://claude.com/blog/the-ai-native-sdlc-playbook

[2] Anthropic 官方《How Anthropic secures its AI-native software development lifecycle》Jason Clinton — https://claude.com/blog/how-anthropic-secures-its-ai-native-software-development-lifecycle

[3] Founder Park《Anthropic 应用 AI 团队：AI 已经让写代码变快，但 SDLC 卡在了别的地方》2026-08-22 编译版

[4] Simon Martinelli《Code Is No Longer the Bottleneck. Requirements Are.》2026-08-23 — https://martinelli.ch/code-is-no-longer-the-bottleneck-requirements-are

[5] 夕小瑶《Anthropic 应用 AI 团队最新分享：AI Native 编程工具如何重塑 SDLC》2026-08-22

[6] The Pragmatic Engineer《Why Ramp built Inspect: A custom AI coding agent》Gergely Orosz 2026-08-26