Anthropic 官方指南：AI 原生 SDLC 开发手册

本文编译自 Anthropic 官方博客《The AI-Native SDLC Playbook》，2026 年 8 月 21 日发布，作者 Louis Claxton。全文约八千字，保留了原文全部代码示例和配置样板，对部分章节做了适合中文读者的表述调整

这里的 SDLC 指的是「软件开发生命周期」全称：Software Development Life Cycle，说的是软件从一个想法变成线上产品的完整过程，通常拆成规划、设计、构建、测试、部署、运维六个阶段

在看文章之前，先看一下这个数据：App Store 销售额十年来首次下降

换言之：香草时代，结束了

SDLC（Software Development Life Cycle，软件开发生命周期）说的是软件从一个想法变成线上产品的完整过程，通常拆成规划、设计、构建、测试、部署、运维六个阶段

01 代码不再是瓶颈

很多团队已经在用 AI 写代码了，速度快到一年前根本想不到。但代码周围的流程没跟上

大部分工程团队还是老一套审批门禁、代码审查、人工交接、合规策略，把 Claude Code 这类 agentic coding 工具带来的效率提升活活卡住

传统做法里，SDLC 的每个阶段是一个独立环节，各有各的负责人。产品经理写需求，技术架构师把需求变成设计，工程师按设计写代码，QA（Quality Assurance，质量保证）团队做验证，发布团队负责上线，运维团队盯线上。工作在这些环节之间流转，靠的是文档、工单和签批

这套流程很重，是为了确保每一步都有人负责、有人管控。但它的设计前提是：写代码和实现代码是最耗时、最费钱的阶段。现在这个前提不成立了。PRD（Product Requirements Document，产品需求文档）、估时会议、产品安全审查，这些东西存在的意义是在可能长达数周、数月甚至数个季度的开发周期里强制对齐认知

传统 SDLC 还有一个假设：每一步都是人在做。产出最大的那些组织已经围绕 agentic AI 的能力重建了流程，同时确保人始终在回路中。这份指南里，我们会逐阶段走一遍 Anthropic Applied AI 团队在内部集成 Claude 的最佳实践，加速开发、让流程跑得更快

当代码不再是瓶颈、构建阶段跑得比传统 SDLC 允许的速度还快时，三件事变成了现实：

→瓶颈转移到了构建阶段的左右两侧。主要是规划、审查/测试和部署，这些环节还在以人的速度运行

→管控手段和现实脱节了。代码是人写的时候，逐行审查是合理的。但当 agent 产出了大部分 diff，逐行审查跟不上了

→治理成本上升了，因为例外情况还是要走会议和委员会，而这些会每周或每月才开一次

构建不再是约束，约束来自构建两侧那些人速运行的环节

拿安全审查做个例子。安全团队的人力配置是按人类产出量来的，agent 把代码产出量翻了好几倍之后，要么审查队列越积越长，要么代码没审就上线了。受监管的组织两种结果都接受不了，安全和合规检查必须跟上 agent 的速度

要真正兑现 agentic AI 的效率收益并确保安全，传统 SDLC 需要经历和代码实现阶段同等程度的改造

什么是 AI 原生 SDLC

AI 原生 SDLC 是一套重新设计的流程，把旧的管控目标和新的执行方式结合起来。流程从线性变成了循环，AI 嵌入到每个节点。AI 原生 SDLC 推动自动化的交接和后续步骤的触发，解决的是传统 SDLC 各阶段之间手动、笨重的衔接问题

AI 原生 SDLC 循环

关键转变

贯穿 AI 原生 SDLC 的核心概念是提交的产物（committed artifact）。每个阶段结束时往版本控制里写一个产物（intent.md、spec.md、plan.md、代码 diff 及其测试、带审查结论的 PR、事故记录），下一个阶段从读取这个产物开始

早期阶段的主要产物是 .md 文件，因为产品负责人和 agent 都能读、都能用。从构建阶段往后，产物就是代码和它的记录了。这条 commit 链本身就是审计链：谁提了什么需求，agent 产出了什么，谁批准了它

人对每一个需要判断力的决策负责。在 agentic SDLC 的世界里，人的注意力随着需要审查的产物一起转移

02 各阶段 Play

Play 是这份手册的核心，按六个非线性阶段分组（规划、设计、构建、测试、部署、运维），覆盖完整生命周期。每个 play 包含：变化了什么、如何开始、具体实施步骤、治理考量、如何衡量效果

这些步骤是模块化的，组织可以根据自身需要优先改造不同阶段。一个阶段在提交产物时结束，这次提交同时启动下一个阶段。一个通过审核的 intent.md 触发需求和设计环节，一个通过审核的 spec.md 触发 plan mode，一个合并的 PR 触发流水线，线上的监控指标突破控制带时写出下一个 intent.md，循环继续

一开始你手动触发每一步，最终状态是每个通过审核的产物自动触发下一个门禁。人的注意力集中在门禁上，审查的是 agent 标记出来的内容，不用从头开始每个阶段

Play 依赖图：箭头给出采纳顺序，从任何没有箭头指入的 play 开始

03 用 intent.md 捕获意图

intent.md 是软件开发流程的起点，可以从不同入口进来。一个人有了想法，一个工单被提交，或者一个告警触发了事故

当一个人有了想法，他和 Claude 一起头脑风暴，产出一份 Markdown 格式的 proto-spec。传统 SDLC 里，这个人接下来得说服产品团队的人帮他写或替他写。Claude 生成的 proto-spec 是人类可读的、版本控制的，下一个阶段可以直接消费

这是一次性的搭建工作，由平台或工程团队完成。仓库建好之后，没有 git 经验的人不需要直接用 git。一个连接到 GitHub 的 connector 可以让 Claude 在 claude.ai 或 Cowork 里代替他们提交 Markdown 文件

具体怎么做

第一步，发起人用自己的话向 Claude 描述问题。不需要正式语言

第二步，反复头脑风暴直到想法具体化。Claude 会问分析师该问的问题：范围、用户、约束、怎样算成功

第三步，让 Claude 按组织模板把结果写成 intent.md。模板可以编码为一个 skill

第四步，发起人修正 Claude 理解错的地方

第五步，把 intent.md 提交到共享仓库。作者和时间戳加入记录

一个 intent.md 长这样：

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.md，列有作者、时间戳和完整修订历史，记录在 intent 仓库的 git 历史里。产品负责人审批，接受或拒绝的决定记录为合并或关闭审查

04 需求与设计

产品负责人批准后，Claude 拿着通过审核的 intent.md 生成需求和设计规格说明。这个过程受组织的 skills 指引，涵盖品牌、安全、合规和 UX

产品负责人审查这份规格说明，但不写它。这个流程的目标是产出一份工程团队可以据此规划的 spec，同时标记出需要关注的地方

前端工作是最直观的例子。intent.md 通过审核后，产品负责人在 Claude Design 里基于它做出 mock，反复迭代，然后导出到 Claude Code 来构建

具体怎么做

产品负责人打开一个加载了组织 skills 的会话，附上 intent.md。Prompt 指向 intent.md，列出约束条件，要求标记关注点。一开始手动跑，然后编码成组织级别的 slash command。再往后，让 intent.md 在 intent 仓库中被接受这个动作成为触发器

同一个产品负责人对照 idea 审查 spec。先处理标记出来的关注点，产品负责人在工程团队看到 spec 之前，和对应的策略负责人一起解决每一个。最后把 spec.md 和 intent.md 一起提交

产品负责人决定 spec 和 intent 是否进入构建阶段，涉及组织认定的高风险内容时咨询技术负责人。这个决定始终由人来做

Prompt 长什么样

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.

治理考量

组织的 skills 作为约束条件应用在 spec 上。不是等几周后在审查里才发现冲突，而是在 spec 编写时就读取并应用了现行策略。Spec、产生它的 prompt、以及生效的 skill 版本，全部记录在版本控制里

05 构建阶段

Claude Code Plan Mode 作为默认起点

工程师在 plan mode 下启动 Claude Code 会话，给 Claude 第二阶段产出的 spec.md，让它提问、讨论，反复迭代计划，直到工程师满意

工程师把 intent.md 和 spec.md 给 Claude，要求一份实施计划：列出要改的文件、工作顺序、证明它 work 的测试。质询计划：问这个改动可能破坏什么，哪一步风险最大，Claude 为什么没选其他方案。反复迭代，直到一个从没看过这段对话的工程师也能只凭这份计划完成改动

把通过审核的计划提交为 plan.md。接受计划，让 Claude 实施。有一份扎实的计划，实施通常一遍就完成了

plan.md 示例

Plan: claims status self-service (from intent.md 2026-06-02)

Files that change portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py, claims-api/tests/test_status.py

Order of work 1. Add the status endpoint behind existing auth. 2. Panel against the endpoint. 3. Wire into the portal nav.

Risks The claims-core API rate-limits at 50 rps; the panel must cache.

Proof test_status.py covers the four claim states; screenshot matches the approved mock.

治理考量：设计审查发生在任何代码生成之前，改方向还只是改文档的事。Plan mode 本身就强制执行了这一点，因为工程师接受计划之前 Claude 不能编辑文件

Claude Code Auto Mode

Claude Code 也可以在 auto mode 下运行。工程师审批计划，满意之后 Claude 自动逐个应用变更，不需要每次编辑都确认。随着后续 play 的护栏成熟（调好的 CLAUDE.md、编码了策略的 skills、拦截不安全操作的 hooks、Claude 能自己跑的测试套件），auto-accept 成为常规工作的默认模式

注意力的重心从「看着 agent 做每一次编辑」转向「在更长的自主会话之后审查产物」

CLAUDE.md

CLAUDE.md 给 Claude 提供一个新人入职第一天需要知道的东西：代码规范、命令、架构、团队最常见的错误。过去存在人脑里和 wiki 上的知识，变成了 agent 每次会话开头都会读的文件，由整个团队维护，每犯一次错就迭代一次

在仓库里跑 /init，Claude 从它发现的东西里生成一个初始版本。把它精简到新人第一天需要的内容。一条实用规则：Claude 犯同一个错两次，纠正就进 CLAUDE.md。控制在一页以内

CLAUDE.md 示例

Payments service

Commands – Build: make build – Test: make test (unit), make itest (integration, needs docker) – Lint: make lint (runs in CI; fix before pushing)

Conventions – Java 21, Spring Boot 3. No new Lombok. – Money is always BigDecimal, never double. – Every endpoint needs an integration test in src/itest.

Architecture – api/ holds REST controllers, core/ holds domain logic,

adapters/ talks to external systems. – Kafka events are defined in schemas/;

never edit generated classes.

Things Claude gets wrong – Do not bump dependency versions;

the platform team owns them. – The legacy v1/ package is frozen; changes go in v2/.

Skills：机构知识的可执行化

Skills 是组织让机构知识真正发挥作用的方式。指令是显式的、版本控制的、广泛适用的，策略变化时集中更新。经验法则：需要一致性执行的机构知识写成 skill

找一条今天执行不一致的知识，写成 skill，放在仓库的 .claude/skills/ 目录里让它随代码一起分发。策略变化时改 skill，工程师在下一次会话自动获取新版本

.claude/skills/secure-api-review/SKILL.md 示例

— name: secure-api-review description: Apply the API security standard. Use whenever

creating or modifying an external-facing endpoint,

reviewing API code, or generating an OpenAPI spec. — # Secure API review

When you create or change an API endpoint: 1. Authentication: every endpoint requires the gateway JWT;

no anonymous routes outside /health. 2. Input validation: validate request bodies against the

OpenAPI schema and reject unknown fields. 3. Audit: every state-changing endpoint emits an audit event

with actor, action, entity and timestamp. 4. Data classification: fields tagged pii in the schema must

never appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

治理考量：Skill 是一种管控手段，但是建议性的。必须无条件执行的策略需要在 skill 背后加一层确定性的东西，比如 hook。Skill 让违规变得少见，hook 让违规几乎不可能

Hooks：构建阶段的护栏

Skill 是建议性管控，hook 是背后的确定性层。Claude 在实施阶段的大部分操作是文件编辑和 shell 命令，所以构建阶段是 hook 触发最频繁的地方

构建阶段的 hook 可以做这些事情：阻止对受保护路径的编辑（比如生成的类或冻结的包），在文件编辑后跑 formatter 和 linter，把凭证挡在 diff 之外

Hook 在每个匹配的操作上运行，所以构建阶段的 hook 要快、范围要限定在改动的文件上。更重的检查（比如跑完整测试套件）应该放在 commit 或 PR 阶段

并行会话和子 Agent

一个工程师可以同时推进多条工作流