【译文】AI 原生软件开发生命周期(SDLC)实战手册

代码不再是瓶颈

组织如今借助 AI 编写代码的速度，一年前还难以想象；但围绕代码的流程并没有同步演进。

许多工程团队仍沿用原来的审批关卡、评审、交接和政策，因此采用 Claude Code 等智能体编程方案带来的生产力提升，被旧流程抵消了。

软件开发生命周期（SDLC）是把软件从想法带到生产环境的全过程。大多数组织都采用规划、设计、构建、测试、部署和维护六个阶段。传统上，每个阶段由不同角色分别负责：产品经理写需求，技术架构师转化为设计，工程师实现，受监管企业的 QA 团队验证，发布团队上线，运维团队监控。工作通过文档、工单和签字在各阶段之间流转。

传统 SDLC 流程繁重，是为了在每一步保证问责与控制。但它诞生于“编写和实现代码最耗时、成本最高”的年代。PRD、估算仪式和产品安全评审，都是为了让持续数周、数月乃至数季度的开发工作先形成共识。如今，这个前提已不成立。

传统控制还假设每一步都由人完成。获得最大价值的组织，已经围绕智能体 AI 的新能力重构流程，同时让人始终参与关键决策。本指南总结 Anthropic Applied AI 团队在客户实践中形成的经验，说明如何把 Claude 融入 SDLC 各阶段，加速开发与流程运转。

当代码不再是瓶颈、构建阶段快于传统 SDLC 所能承载的速度时，会出现三件事：

瓶颈转移到构建阶段左右两侧，主要是规划、评审/测试和部署，它们仍按人的速度运行。
控制措施与现实脱节，甚至变得无法执行。代码由人编写时逐行评审尚可行；当大部分 diff 由智能体生成时，这种方式无法跟上。
治理成本上升，因为例外仍要进入每周或每月才召开一次的会议和委员会。

构建不再是约束——周围按人类速度运行的步骤才是。构建缩短到数小时，而人工阶段的长度不变。

以安全瓶颈为例：安全团队的规模按人类产出配置。智能体成倍提高代码产量后，要么评审队列越积越长，要么代码在评审不足时上线。受监管组织无法接受任一结果，因此安全与政策检查必须跟上智能体的速度。

要充分释放智能体 AI 的生产力并保证安全，传统 SDLC 必须经历与实现阶段同等程度的变革。

什么是 AI 原生 SDLC？

AI 原生 SDLC 用新的执行方式实现原有的控制目标。流程不再是线性的，而成为一个闭环，AI 嵌入每个节点。阶段之间的交接和后续行动可自动触发，从而消除传统 SDLC 中手工、笨重的移交流程。

关键转变

下表展示了传统 SDLC 与 Claude 支持的 AI 原生 SDLC 两端形态。多数组织会处在两者之间。

阶段	传统 SDLC	AI 原生 SDLC
规划	委员会收集需求，经研讨和签字后人工整理	Claude 直接从源头综合痛点，写入人可读、机器可执行的 `intent.md`
设计	分析师写规格，设计师再解读	需求与设计压缩到一次与智能体协作的会话；标准编码为 skill，并在 git 中版本化
构建	人工编写测试和代码，文档往往事后补写	AI 生成测试与代码，组织知识以机器可读、可版本化的 `CLAUDE.md` 和 skill 维护
测试	在阶段边界设置 QA 关卡	持续评测贯穿实现过程
部署	人工逐行评审，治理以周期性评审执行且常不一致	多层智能体评审，人工专注受监管及关键代码；AI 行动时即执行治理，hook 充当审批关卡
维护	人工监视生产环境中的缺陷	智能体监控线上部署；控制带一旦越界，就诊断问题并以新的 `intent.md` 写回闭环

右栏贯穿始终的是“已提交的产物”。每个阶段都向版本控制写入一个产物——包括 intent.md、spec.md、plan.md、代码 diff 与测试、附评审结果的 PR，以及事故记录——下一阶段再读取它。早期阶段以 .md 为主，因为产品负责人和智能体都能阅读并据此行动；从构建阶段开始，产物则是代码及其记录。提交链同时也是审计轨迹：谁提出了什么，智能体产出了什么，谁进行了批准。

凡需要判断的决定，最终责任仍由人承担。在智能体 SDLC 中，人的注意力会随待审产物一起转移。

每个阶段都会提交一个可供下一阶段读取的产物。意图、规格、计划、diff 与评审发现共同构成审计轨迹。

实战方法

本手册的核心方法分布在规划、设计、构建、测试、部署和维护六个非线性阶段，共同覆盖完整生命周期。

每项方法都会说明：

有什么变化；
如何开始；
具体实施步骤；
治理注意事项；
如何衡量是否有效。

这些方法可以模块化采用。组织可按自身需要，在不同时间优先改造不同阶段。每项方法都会列出“前置条件”，依赖图也会直观展示这些关系。

一个阶段以提交产物结束，这次提交同时触发下一阶段：获准的 intent.md 触发需求与设计，批准的 spec.md 触发计划模式，合并的 PR 触发流水线；生产控制带越界则写入下一份 intent.md，闭环由此继续。

最初可以人工提示每一步；最终形态是每个获准产物自动触发下一道关卡。人的注意力集中在关卡上，评审智能体标记的问题，而不是从头启动每个阶段。

图中列出了方法所属阶段，箭头表示采用顺序，两者并不相同。可从任意黏土色方法开始；没有箭头指向它们，说明不依赖其他方法。采用其余方法前，应先完成指向它的前置方法。

规划

想法不再等待别人代为整理。提出者只需用自己的语言捕获一次意图，形成受版本控制、可供下一阶段直接使用的产物。

将意图记录为 intent.md

启动软件开发流程的 intent.md 可以从不同入口产生：某个人提出想法、有人创建工单，或警报暴露事故（参见“维护”阶段）。

当一个人产生想法时，可以与 Claude 共同头脑风暴，形成 Markdown 原型规格。传统 SDLC 中，此人还要说服产品团队成员与其一起或代其把想法写成正式材料。

Claude 生成的原型规格既能被人阅读，又受版本控制，并可立即交给下一阶段使用。它最终保存为 intent.md。

无论意图来自事件触发还是智能体，步骤都相同：产品负责人在提交前评审并修正智能体编写的 intent.md。

传统方式： 一个想法先后经过待办项、用户故事、故事点和细化会议，之后才有人能够行动。每次交接都转移所有权，到达工程团队时，内容已与提出者原意隔了好几层。

AI 原生方式： 提出者与 Claude 头脑风暴，把结果写入 intent.md，以自己的语言形成原型规格，明确要什么、为什么要以及有哪些约束。重复流程编码为 skill。

开始之前

前置条件：无。
基础设施：为非工程人员提供 Claude（claude.ai 或 Cowork）；约定 intent.md 模板；建立由产品负责人关注、受版本控制的共享意图仓库。单一产品最简单的做法是在产品仓库中建 intent/ 目录，使产物链紧邻由它派生的代码。只有意图跨越多个仓库时，单独建立意图仓库才值得；在 monorepo 中则使用目录。“构建”阶段的边栏会说明它与 Jira 或既有需求系统的关系。

这是平台或工程团队的一次性工作。技术成员要建立意图入口并决定写入权限，因为贡献者会来自整个组织。

仓库建好后，不熟悉 git 的贡献者无需直接操作 git。通过 GitHub 等版本控制连接器，Claude 可从 claude.ai 或 Cowork 代其提交 Markdown 文件。

执行步骤

提出者用自己的语言向 Claude 描述问题：今天做不到什么、谁受影响、理想结果是什么、哪些内容不在范围内；无需正式措辞。
持续讨论，直到想法足够具体。Claude 会像分析师一样追问范围、用户、约束和成功标准。
要求 Claude 按组织模板写成 intent.md。模板可由技术成员编码为 skill，并由负责人批准，覆盖问题、预期结果、相关用户与系统、约束和待解决问题。
提出者修正 Claude 的误解。
把 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：作者、时间戳和完整修订历史都记录在意图仓库的 git 历史中。产品负责人进行批准；把意图送入“设计”阶段的接受或拒绝决定，以合并或关闭评审的形式留痕。

衡量方式： 领先指标是首次对话到提交 intent.md 的时间，可从 git 历史读取，目标是从数周缩短至数小时。滞后指标是存活率，即被产品负责人接受并进入设计阶段、而不是关闭的 intent.md 比例；还应统计同一变更首次提交 spec.md 后，对 intent.md 所做的修改次数。

设计

需求与设计压缩到一次会话中。政策在规格编写时就被应用，而不是数周后的评审才被发现。

需求与设计

产品负责人批准 intent.md 后，Claude 会据此生成需求与设计规格，并受组织在品牌、安全、合规和 UX 方面的 skill 约束。

产品负责人负责评审规格，但不亲自编写。目标是形成一份工程团队可以据此规划、且明确标出关注点的规格。

前端工作最直观：intent.md 获准后，产品负责人可在 Claude Design（beta）中生成并迭代设计稿，再导出到 Claude Code 进行构建。

传统方式： 需求和设计由不同团队分阶段完成。分析师把想法形式化为需求，设计师再把需求解释为设计。这种职责分离便于问责，却缓慢且容易失真。

AI 原生方式： 两个阶段在一次提示会话中完成。Claude 根据 intent.md 生成需求与设计规格，受组织 skill 约束，并标记需要关注的地方。

开始之前

前置条件：已有 intent.md，且品牌、安全、合规和 UX 政策已写成 skill。
基础设施：一名可以使用 Claude 的产品负责人，无需工程技能。

执行步骤

产品负责人开启可使用组织 skill 的会话，并附上 intent.md。
提示词指向 intent.md、说明约束并要求标出风险。初期手工执行，随后固化为组织级斜杠命令；再进一步，可让意图仓库中 intent.md 的合并自动触发非交互任务，加载组织 skill 完成处理，并以 PR 形式提交 spec.md。届时产品负责人第一次介入就是评审。
同一位产品负责人对照原始想法评审规格：它是否解决了问题？intent.md 中的未决问题是否已回答或明确保留？
优先处理标出的关注点，因为这些正是分析师原本会升级的问题；产品负责人需与相应政策负责人逐项解决后再交给工程团队。
将 spec.md 与 intent.md 一并提交，记录“提出了什么”和“最终决定了什么”。
产品负责人决定规格和意图是否进入构建；对组织认定的高风险事项，应咨询技术负责人。该决定始终由人作出，接受规格即会启动“构建”阶段的计划模式。

示例提示词

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.

治理注意事项

实时政策在规格编写时就被读取和应用，不必等到数周后的评审。组织 skill 对规格形成约束；规格、生成它的提示词以及当时生效的 skill 版本都进入版本控制。产品负责人批准规格，并把关注点交给对应政策负责人。

衡量方式： 领先指标是同一变更从提交 intent.md 到提交 spec.md 的时间，与旧的需求加设计周期对比。滞后指标是构建开始后的需求返工，即首次提交 plan.md 后对 spec.md 的提交次数，可直接从 git 日志获取。

构建

没有获准的计划，就不开始实现。组织知识成为智能体会读取的文件，护栏以代码运行，而不再依赖个人习惯。

默认从 Claude Code 计划模式开始

工程师以计划模式启动 Claude Code，把设计阶段批准的 spec.md 交给 Claude，让它通过提问了解情况并反复迭代，直至工程师认可计划。

传统方式： 工程师读完设计便开始写代码。具体改哪些文件、如何测试，往往只存在于脑中，最多留在工单评论里，其他人无法提前评审。评审者第一次看到的是完成后的 diff，此时返工代价已经很高。

AI 原生方式： 工作从书面计划开始。Claude 在只能读取代码库、不能修改的计划模式中生成计划；工程师在写代码前纠正它，并把批准版本提交为 plan.md，供后续阶段核对。

开始之前： 如已有意图产物，则提供 intent.md 或 spec.md；CLAUDE.md 也会有帮助。基础设施是可访问仓库的 Claude Code。

执行步骤

工程师以计划模式启动 Claude。
提供 intent.md 和 spec.md，要求实现计划明确变更文件、工作顺序和验证测试。
追问计划可能破坏什么、哪一步风险最高，以及 Claude 放弃了哪些替代方案。
持续迭代，直到未参与对话的工程师也能仅凭计划完成实现。
将批准的计划提交为 plan.md，纳入审计轨迹；部署阶段的 PR 评审会据此检查最终 diff。
接受计划并让 Claude 实现。计划扎实时，实现通常一次即可完成。
若实现偏离计划，在同一提交中更新 plan.md；可考虑用 hook 强制二者同步。

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.

治理注意事项

设计评审发生在生成任何代码之前，此时改变方向只需编辑文档。计划模式本身会执行这一点，因为工程师接受计划前 Claude 无法编辑文件。计划、修订及批准人都会留痕。常规变更由工程师批准；组织认定的高风险事项交给技术负责人或架构师。

衡量方式： 领先指标包括首次实现即合并的变更比例，以及计划批准到 PR 合并的时间，数据可记录在 PR 元数据中。滞后指标包括每项变更的返工轮次，以及合并后的 diff 与已提交 plan.md 的一致率。

Claude Code 自动模式

Claude Code 也可以自动模式运行：工程师先反复完善并批准计划，随后 Claude 无需逐次编辑确认即可应用变更。随着后续方法中的护栏逐渐成熟——调优的 CLAUDE.md、编码政策的 skill、阻止不安全操作的 hook，以及 Claude 可运行的测试套件——常规工作可以默认自动接受：spec.md 明确、影响范围小、代码已有测试覆盖。

关注点由“盯着智能体逐步编辑并审核每个动作”，转向“较长自主会话结束后评审产物”。结合 worktree，自动接受模式还能提升个人与团队并行度，也是自主运行 SDLC、最终闭合维护环路的基础。

旧系统与唯一事实来源

这一原则适用于流程产生的每种产物。

现有 SDLC 多半已经记录这些产物，只是并非 Markdown：工作项在 Jira，需求在带监管追踪能力的工具中，设计在 Figma，变更由变更委员会批准。这些系统难以替换，因为审计方和监管方已经认可，其他团队也依赖它们；AI 原生 SDLC 必须适配现实。

转型时，应为每种产物指定一个唯一事实来源，其他系统只保存副本或指向原件的链接。不同产物可以采用不同方案：

以仓库为事实来源。 Markdown 产物是权威记录，旧系统引用特定提交中的文件。对工程主导的组织，这是最清晰的方案之一：全部记录集中在一种工具中，并共用一个时间戳权威来源。

以旧系统为事实来源。 Jira、ServiceNow 或需求工具保存权威记录，Markdown 只是工作副本。Claude 在会话开始时读取权威记录，并在生成规格或计划的同一会话中通过 MCP 连接器写回结果。

至少建立双向关联。 每个产物注明记录 ID，每条旧系统记录保存 Markdown 文件的 commit SHA。转型初期可从这里开始，即便暂时存在两个事实来源。

旧系统与 Markdown 优先系统可以共存，前提是二者存在关联，或明确声明其中一个为事实来源。

CLAUDE.md

CLAUDE.md 向 Claude 提供新成员入职时需要的上下文，包括约定、命令、架构和团队最常遇到的错误。原本散落在人脑和 wiki 中的知识，变成智能体每次会话开始都会读取的文件，由全团队维护，并在每次出错后持续迭代。

开始之前： 无前置条件。需要一个仓库、已安装的 Claude Code，以及一名熟悉代码库的工程师。

执行步骤

在仓库中运行 /init，Claude 会根据发现的内容生成初始 CLAUDE.md。
精简到新成员第一天真正需要的信息：构建、测试和 lint 命令，重要约定，以及 Claude 反复犯错的地方。
把文件提交到仓库根目录，让全团队共享一个版本，并像代码一样评审变更。
可采用一条规则：Claude 同一错误出现两次，就把纠正方式写入 CLAUDE.md。
控制在一页以内。Claude 会在每次会话开始读取全文，过时内容只会无益地占用上下文。

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/.

治理注意事项

CLAUDE.md 受版本控制，因此智能体遵循的指令可评审、可审计。团队约定通过文件生效，变更记录在 git 历史中，并由代码负责人在 PR 中批准。

衡量方式： 领先指标是 Claude 重复本应被 CLAUDE.md 阻止的错误次数，相关修订可在 git 历史中追踪；滞后指标是新成员从加入到首个 PR 合并的时间。

用 skill 承载组织知识

Skill 让组织知识真正可执行：指令明确、受版本控制、广泛应用，并能在政策变化时集中更新。经验法则是：必须一致执行的组织知识写成 skill；应属于 CLAUDE.md 或单次提示词的内容不要写成 skill。

开始之前： 不强制要求前置条件；已有 CLAUDE.md 会有帮助，但 skill 不依赖它。基础设施只需一项有明确负责人和书面事实来源的政策。

执行步骤

选择一项目前执行不一致的知识，例如安全标准、API 设计约定或品牌规范。
把它写成 skill：文件夹内包含 SKILL.md，frontmatter 说明何时触发，正文说明如何执行。工程师可借助 Claude，从政策负责人的权威来源编写。
将 skill 放在仓库的 .claude/skills/<name>/，随代码交付；或通过插件在组织内分发。
测试触发：用不同方式要求 Claude 执行相关任务，确认每次都加载 skill。
政策变化时更新 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 是一种建议性控制：它让 Claude 更可能在写代码时执行政策，却不能强制会话合规。必须始终成立的政策还需要确定性控制，例如阻止操作的 hook，或在 PR 中重新检查政策的评审。Skill 让违规变少，hook 让违规接近不可能。Skill 调用记录在会话轨迹中，政策负责人像评审代码一样评审变更。

衡量方式： 领先指标是政策获批到 skill 更新合并的时间；滞后指标是 PR 评审中引用该政策的问题数量。若未趋近于零，说明 skill 没有正确触发，或其内容已偏离正式政策。

用 hook 建立构建护栏

Skill 是建议性控制，hook 则是其背后的确定性执行层。Claude 在实现期间的大多数动作是编辑文件和运行 shell 命令，因此 hook 在构建阶段触发最频繁。

构建阶段的 hook 可以：

阻止修改生成类、冻结包等受保护路径；
编辑后自动运行格式化和 lint，避免偏差累积；
防止凭证进入 diff。

任何不允许例外的 skill 政策，都应有 hook 兜底。Hook 会对每个匹配动作执行，因此构建 hook 应快速且仅作用于变更文件；完整测试套件等重检查应放在提交或 PR 阶段。

需要人工批准的 hook 应归入“部署”阶段的关卡。若构建期间不断弹出审批，会让人重新进入所有并行会话的关键路径。

并行会话与子智能体

一名工程师可以同时推动多条工作流。

并行会话是另一个完整 Claude Code 实例，在独立 git worktree 中处理不同任务。各会话彼此不了解，唯一共同点是负责引导它们的工程师。

子智能体则在单次会话内部运行，是拥有独立上下文窗口和工具限制的专用助手，适合在多个任务中反复出现的工作，例如验证应用是否符合预期。

并行会话增加工程师可同时推进的任务数；子智能体让每个会话专注于自己的任务。工程师的职责转为引导和评审。

传统方式： 一名工程师一次处理一项任务，大量时间耗在构建、测试和等待评审上。等待时切换任务虽可行，但认知成本很高。

AI 原生方式： 一名工程师同时运行多个 Claude 会话，每个会话在独立 worktree 中执行自己的任务。重复工作变成有独立上下文和工具限制的子智能体；工程师转向编排，并最终构建和监控闭环。

开始之前： 需要所有会话都会读取的 CLAUDE.md；若会话能用测试反馈自行验证，工程师监督更少。基础设施是 git 仓库、用于隔离的 worktree，以及经过调整的权限设置，确保组织认定安全的命令不会等待批准。

执行步骤

根据计划模式产出的计划，把工作拆成修改不同文件的独立任务；共享文件的任务应在一个会话中顺序执行。
每个并行任务使用独立 worktree，例如分别运行 claude --worktree feature-auth 和 claude --worktree fix-rate-limit。独立分支与检出可防止会话修改同一文件时冲突。
从两三个会话开始。实际上限取决于一个人能认真评审多少工作流；只有评审跟得上时才增加会话。
把重复工作变成 .claude/agents/ 中定义的子智能体 Markdown，注明名称、适用时机和可用工具。例子包括：主智能体完成后去除无谓复杂度的代码简化器；运行应用并检查行为的验证器；探索代码库并汇报、但不淹没主上下文的研究器。定义应提交到 git，供全团队共享。

.claude/agents/verifier.md 示例

---
name: verifier
description: Runs the app and checks the change works before the session
  reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

治理注意事项

会话越多，产出越多，因此控制必须来自仓库配置。Hook 和权限设置对所有会话生效；会话行为会被记录，并归因到运行它的工程师。

衡量方式： 领先指标是在评审质量不下降时每名工程师的并发会话数（可从 OpenTelemetry 导出统计），以及用于引导而非等待的时间占比；滞后指标是每名工程师每周合并的变更数，同时结合 PR 历史中的返工率观察。

测试

每个会话都在交给人之前检查自己的工作；引导智能体的配置也像它编写的代码一样接受回归测试。

给 Claude 建立反馈闭环

始终给 Claude 一种自行验证工作的方式：测试、构建或截图 diff。会话应先检查并修正自己的错误，再把结果交给工程师。

反馈闭环不同于构建阶段的验证器子智能体。反馈闭环贯穿整个任务，工作迭代多少次，它就运行多少次；验证器子智能体则是在会话认为完成时，用一个全新上下文窗口执行最终检查。这样，结论不会被生成代码时的假设所影响。

传统方式： 代码是否有效的信号来得很晚——几分钟后的 CI、几天后的测试人员，或几周后的生产环境。若代码由智能体生成，延迟信号意味着必须有人检查它的全部产出，这个人便成为瓶颈。

AI 原生方式： 在结果交给人之前，会话已有办法自行检查：运行测试、执行构建、拍摄截图。Claude 迭代到检查通过，因此工程师看到的版本已经验证。搭建这个闭环是运行会话的工程师的责任。

开始之前： 无前置条件。需要能分别用单条命令在本地运行的测试套件与构建。UI 工作尤其需要让 Claude 看见结果，可通过浏览器工具，或经 MCP 接入截图工具。

执行步骤

若当前验证需要一串命令和环境知识，将其封装为 make test 或 npm test 之类的单一目标，失败时返回非零状态码。
在 CLAUDE.md 的 Commands 部分列出每条命令，并给出健康输出示例。
设定可量化目标，让 Claude 无需询问即可检查，例如：“test_status.py 中所有测试通过”“截图与所附设计稿一致”“接口返回 200 且包含新字段”。
修复缺陷时先写失败测试：让 Claude 把缺陷复现为测试，运行并确认它因预期原因失败，随后提交该测试。然后要求 Claude 在不修改测试的前提下使其通过，并用测试文件 hook 强制限制。修复前就存在且智能体无法改写的测试，是缺陷消失的证据。
UI 工作用视觉检查闭环。给 Claude 浏览器或截图工具及设计稿，让它“实现、截图、比较、调整”。两三轮很正常，结果应逐轮改善。
把验证纳入“完成”的定义。指令写在 CLAUDE.md：报告完成前运行测试并展示输出。
最后还要保护闭环本身，因为修代码的智能体不能削弱检查。可用 hook 在修复任务中禁止编辑测试文件；另一方案是在评审中检查 diff，拒绝任何测试变更。

CLAUDE.md 验证区块示例

## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

治理注意事项

强制内容： 任务报告完成前必须验证；修复期间不得编辑测试文件。组织需要绝对保证时，两者都由 hook 实现。
证据： Claude 实际运行并粘贴的 make test 输出、构建日志或截图 diff，因此证据直接来自工具链。
记录位置： 会话转录；OpenTelemetry 可把它转发至组织的可观测平台；PR 的检查运行也会保留记录，供评审者和日后审计查看。
批准人： 评审 PR 的代码负责人。机械性证据已经附上后，其注意力可集中于意图和风险。

衡量方式： 领先指标是智能体编写变更首次通过 CI 的比例。滞后指标包括每个 PR 的评审时间，以及事故追踪器记录的变更失败率。

在 CI 中持续运行评测

评测（eval）是 AI 原生环境中“阶段关卡式 QA”的对应物。只要智能体配置发生变化，就运行一套评测。替换新模型或重写提示词时，评测套件会判断智能体是否仍以同等标准完成工作。

评测应被视为持续演进的套件。模型改进后，曾经有区分度的用例可能失效；持续监控中出现的新问题则应补充进来。

按用例不同，有些团队会按固定周期离线运行，而不是每次变更都执行。以下步骤面向持续评测。

开始之前： 需要 CLAUDE.md、反馈闭环、可非交互运行 Claude Code 的 CI，以及有评测预算的 API key。

执行步骤

平台工程师从近期工作中收集 20～50 个真实任务及其预期或已接受结果。
将每个任务写成评测，即提示词加上可接受标准：测试通过、lint 干净、行为不变、政策得到遵守等。
套件在 CI 中定时非交互运行，并在 CLAUDE.md、skill 或 hook 变化时运行。它们都会引导智能体，理应像代码一样接受回归测试。
用结果阻断配置变更；导致通过率下降的 skill 变更必须在合并前评审。
每次生产事故都由负责团队写成一项评测，并永久保留为回归测试。

.github/workflows/agent-evals.yml 示例

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']
  schedule:
    - cron: '0 2 * * *'
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run eval suite
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          for eval in evals/*.json; do
            claude -p "$(jq -r '.prompt' $eval)" \
              --allowedTools "Read,Edit,Bash(make test)" \
              --output-format json > result.json
            ./evals/check.sh "$eval" result.json
          done

治理注意事项

评测为 QA 提供了能跟上智能体产出的关卡。通过率阈值作为合并检查强制执行；运行结果保留以便长期比较；配置变更由其负责团队批准。

衡量方式： 领先指标是每次运行报告的评测通过率趋势，以及生产事故转化为永久评测所需时间；滞后指标是 CI 捕获的回归与生产环境发现的回归之比。

部署

评审双向运行，治理在智能体行动时就执行。智能体可以完成生产关卡之前的一切，但不能越过关卡。

把 AI 纳入 PR 评审闭环

Claude 既提供评审，也接收评审：它依据组织政策检查传入的 PR，也会自行处理自己 PR 上的评审意见。工程师因此可把 PR 评审集中在行为层面，即判断意图和风险。

传统方式： 评审能力按人类产出规划。PR 排队等待评审者阅读全文；质量随评审者负载波动；作者不断催促，积压持续增长。

AI 原生方式： 所有 PR 都接受相同的一组评审轮次，发现按严重程度排序。人的注意力上移到“变更是否实现计划意图、风险是否可接受”。

开始之前： 需要构建阶段更新过的 CLAUDE.md；若评审需执行书面政策，则还需要 skill 与已定义的子智能体。仓库需安装 Claude 集成：由管理员启用托管 Code Review（research preview），或在自有 CI 中运行 claude-code-action。必要时模型调用可经 AWS Bedrock、Google Vertex 或 Microsoft Foundry。最好同时配置必须由代码负责人批准的分支保护。

执行步骤

托管 Code Review 是最快入口：管理员启用并选择仓库。若需要控制流水线或让 API 调用走自有云协议，则在 CI 中用 claude-code-action。
技术负责人在仓库根目录编写 REVIEW.md，按组织关心的轮次划分：缺陷与逻辑错误；安全与漏洞；对照需求阶段的 spec.md、计划模式的 plan.md 和设计原则进行合规检查。文件还要定义什么算 Important、什么只是 Nit，以及哪些内容跳过。
技术负责人设定人工阈值。智能体发现本身不能批准或阻断 PR，分支保护仍要求代码负责人批准。若平台工程师希望依据发现阻断合并，可读取检查运行发布的机器可读严重度计数。
评审者或作者在评论中标记 @claude 后，Claude 会处理意见并推送修复，PR 线程记录请求和变更。该修复闭环通过 claude-code-action 运行；在托管服务中，评论 @claude review 会请求重新评审。对于 Claude 创建的 PR，可进一步让它持续跟进直至可合并。团队还可封装斜杠命令，反复清理未解决评论和失败检查、推送修复，直到 PR 全绿，只待代码负责人批准。
评审发现要反馈到 CLAUDE.md。同一错误第二次出现时，在评审中把纠正方式加入该文件；之后的 PR 评审会读取它并提前捕获问题。若变更使 CLAUDE.md 过时，评审也应指出。
技术负责人每月调优：为发现评分以改进评审器，在 REVIEW.md 中限制 Nit 数量，并排除生成路径和 CI 已强制检查的内容。

REVIEW.md 示例

# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.

治理注意事项

职责分离仍然成立，因为编写代码的智能体无法批准代码。REVIEW.md 政策适用于所有 PR；发现、修复、评分和批准均记录在 PR 历史中，使 PR 成为审计记录。最终批准由人通过分支保护作出，并参考智能体发现。

衡量方式： 领先指标是首次评审时间（应缩短到几分钟），以及无需人修改分支即可解决的评审意见比例；数据直接保存在 Git。滞后指标是合并前捕获的缺陷与漏洞，相对于逃逸到生产环境的数量。

用 hook 充当审批关卡

构建阶段把 hook 用作无需人工介入、直接允许或阻止动作的护栏。Hook 也可以“询问”，暂停动作直到指定人员批准，这正是发布关卡所需的能力。

这一方法归入部署阶段，因为发布是最清晰的例子；但 hook 并不限于部署。构建阶段可阻止没有变更工单时修改迁移或基础设施，测试阶段可阻止智能体在修复任务中编辑测试文件。

开始之前： 无前置条件；需要一份变更流程所需审批的书面清单。

执行步骤

工程管理层与变更管理、合规团队共同列出必须保留的人工关卡，如变更管理签字、发布授权和修改受保护路径。
平台工程师把每个关卡表达为 hook，即在 Claude 行动前运行并可允许、询问或阻止的脚本。
团队 hook 放入 git 中的 .claude/settings.json；不可妥协的 hook 放入平台或 IT 管理员所有的托管设置，个人工程师无法关闭。
阻止动作时必须解释原因，并在 Claude 输出中给出获得批准的路径。

.claude/settings.json 示例

{
    "hooks": {
      "PreToolUse": [
        {
          "matcher": "Bash",
          "hooks": [
            { "type": "command",
              "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
          ]
        }
      ]
    }
}

关卡脚本 .claude/hooks/production-gate.sh

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2 # exit 2 blocks the action; the message goes to Claude
   fi
fi
exit 0

治理注意事项

Hook 就是审批关卡。关卡条件每次、对每个人都强制执行；允许和阻止决定连同时间戳记录。关卡还定义什么算批准，例如已批准的变更工单或发布经理签字。

实例：受监管企业的托管设置

由平台团队通过 MDM 或管理控制台部署，工程师不能编辑或覆盖。

{ "permissions": { "deny": [ "Read(.env*)", "Read(./secrets/**)", "WebFetch", "Bash(curl *)", "Bash(wget *)" ], "allow": [ "Bash(git *)", "Bash(make build)", "Bash(make test)", "Bash(make lint)" ], "disableBypassPermissionsMode": "disable" }, "allowManagedPermissionRulesOnly": true, "sandbox": { "enabled": true, "failIfUnavailable": true, "allowUnsandboxedCommands": false, "network": { "allowedDomains": ["git.internal.example.com", "registry.npmjs.org"] }, "credentials": { "files": [ { "path": "~/.ssh", "mode": "deny" }, { "path": "~/.aws/credentials", "mode": "deny" } ], "envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ] } }, "allowManagedHooksOnly": true, "disableSideloadFlags": true, "allowManagedMcpServersOnly": true, "strictKnownMarketplaces": [ { "source": "github", "repo": "example-corp/approved-plugins" } ], "requiredMinimumVersion": "2.1.193" }

各项设置带来的控制价值如下：

permissions.deny 防止秘密进入智能体上下文，并阻止工具任意访问网络；permissions.allow 预先批准安全的内部循环，避免拒绝清单造成反复提示。
disableBypassPermissionsMode 与 allowManagedPermissionRulesOnly 保证任何工程师、项目文件或命令行参数都无法放宽规则。
sandbox 弥补权限规则的缺口。工具层禁止 WebFetch 并不能阻止 shell 联网；操作系统层域名白名单会直接阻断外连。
failIfUnavailable 与 allowUnsandboxedCommands 把沙盒变成强制关卡：沙盒无法初始化时 Claude Code 拒绝启动；沙盒内失败的命令不能在沙盒外重试。
credentials 填补拒绝规则留下的漏洞。permissions.deny 管理 Claude 文件工具，但沙盒 shell 默认仍可能读取 ~/.ssh 或 ~/.aws/credentials；这里禁止读取，并从所有沙盒命令环境中移除指定秘密。
allowManagedHooksOnly 表示只运行本方法中的托管审批 hook，本地内容不能添加或替换。
disableSideloadFlags 和 strictKnownMarketplaces 保证工程师机器上的 skill、智能体、hook 与 MCP server 都来自组织批准的插件市场，而非个人目录。
allowManagedMcpServersOnly 把智能体工具面限定为平台团队所有的白名单。
requiredMinimumVersion 会拒绝在低于批准基线的版本上启动，确保控制由组织实际评估过的构建执行。

以上只是按自身情况调整的起点，不应直接照抄。每一项禁止都会牺牲部分能力，正确平衡取决于仓库的数据分类。设置参考文档列出了所有键，包括托管专用项：code.claude.com/docs/en/settings。

衡量 hook： 领先指标是各审批关卡的等待时间。每次 hook 决定都带时间戳和允许/阻止结果写入 OpenTelemetry，因此可按关卡观察。滞后指标是引入 hook 前后到达生产环境的关卡违规数量。

CI/CD 集成与部署

在 CI/CD 流水线中以非交互方式运行 Claude Code；用沙盒保证长时间运行智能体的安全；通过 MCP 集成暴露部署能力；并在智能体真正需要回滚前充分演练路径。

传统方式： 流水线运行确定性脚本，任何需要判断的工作都等待人，例如排查不稳定测试、撰写变更日志或分析构建失败原因。部署与回滚是人在压力下执行的 runbook。

AI 原生方式： Claude 在带范围化凭证的沙盒中，非交互处理流水线的判断环节。部署工具通过 MCP 暴露给智能体，因此写代码并测试的工作流也能在组织按环境定义的关卡内完成发布与回滚。

开始之前： 先把 Claude 纳入 PR 评审闭环，并建立审批 hook；关卡必须先于自动化加速。基础设施包括安装 claude-code-action 的 CI，或任何可调用 claude -p 的 runner；API、Bedrock、Foundry 或 Vertex 模型访问；部署目标的 MCP server；以及没有长期生产凭证的智能体作业沙盒配置。

执行步骤

从只读判断任务开始：在流水线中用 claude -p 排查构建失败、总结不稳定测试或起草变更日志。
在现有关卡之后增加写入任务，如修复 lint、更新生成文档、通过 @claude 处理评审意见。智能体写入的任何内容都通过分支保护成为 PR，无法直接推送 main。
对执行进行沙盒化：智能体作业在受网络策略控制的容器中运行，使用短期、范围受限的 token，默认不持有生产凭证。
通过 MCP 暴露部署，把 deploy、status 和 rollback 变成按环境限定的工具。智能体部署权限由白名单决定，而不是携带凭证的 shell 脚本。
按环境分级自治：开发环境可自由部署；生产环境由智能体准备发布、发布经理授权，hook 强制生产关卡；预发布环境介于二者之间。
回滚应是流水线中演练最充分的路径：单条命令即可执行，并在预发布环境定期演练。维护阶段的闭环会在控制带越界时调用它，因此必须事先证明有效。

流水线步骤示例

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

治理注意事项

核心原则是：智能体可以行动到生产关卡，但不能越过它。

分支保护把智能体写入的一切变成 PR，不存在直达 main 的路径。
生产部署 hook 会阻止发布，直到具名发布经理授权。每次非交互运行使用智能体自己的身份，流水线日志因此能区分智能体的行为与触发它的工程师的行为。
分环境权限层级决定智能体在到达关卡前可以做多少事情。

衡量方式： 领先指标是无需呼叫人工即可完成排查的流水线失败比例，可从 CI/CD 日志获取；滞后指标是 CI 与部署工具已经产生的 DevOps Research and Assessment（DORA）指标。

维护

闭环在这里完成。触发器在调用路径中不经过任何人，直接唤起 Claude；其发现以 intent.md 重新进入流水线。

维护与闭合环路

前文说明了如何把 Claude 加入 SDLC 各阶段，但每个阶段的第一步仍由人启动。维护阶段则把重点转向自主运行 Claude，真正闭合环路。

例如，持续运行的监控智能体可以在缺陷工单创建后生成 intent.md，再依次经过需求、计划、构建、测试和评审。维护阶段以无头方式运行，阶段之间设置独立的置信关卡——确定性检查或对抗式评审智能体——来决定上一阶段产物继续前进，还是升级给人。

传统方式： 维护是被动阶段。所有工单与事故都等人采取行动并重启流程。凌晨三点的警报可能被漏掉；工单可能长期留在待办；如果下一个紧急事件先发生，复盘行动甚至不会进入代码库。

AI 原生方式： 控制带越界、工单、频道消息或定时任务等触发器，无需人在链路中即可调用 Claude。Claude 进行诊断，只通过受控路径行动，并把发现写成 intent.md，再进入上述各阶段。人负责分流与评审，不再负责启动工作。

闭合环路

确定性脚本监控生产环境，控制带越界时调用 Claude。越界监控很好地展示了自主闭环模式；本阶段末尾的 Claude Tag（public beta）还会介绍从其他频道进入的工作。

开始之前： 需要 intent.md 作为重启闭环的结构化输出；还需要 Claude 加速的 PR 评审、作为行动边界的 hook，以及 CI/CD 回滚路径（最高自治等级会调用）。基础设施包括检测脚本可查询的指标存储（Prometheus、CI 系统 API 等）、仓库只读权限、在 CI 中非交互运行 Claude Code 的能力，或用于接收 webhook 服务的 Agent SDK。

执行步骤

服务负责人或平台工程师选择一个滚动基线稳定的指标，如 CI 测试失败率、部署后 5xx 比例或 PR 周期时间。
编写检测脚本，通常计算滚动窗口的均值和标准差，并应用 Western Electric 等规则，使控制带既能捕获突增，也能发现缓慢漂移。脚本受版本控制并有单元测试；检测完全确定性，不使用模型。
在受版本控制的配置（如下方 bands.yaml）中定义响应层级：1σ 只记录；2σ 以只读方式调用 Claude 诊断；3σ 时 Claude 可以行动，但只能向评审关卡创建 PR，或触发预先批准的 runbook。
触发层可以是 GitHub/GitLab 定时工作流、现有监控栈的 webhook，或网络内的 Cron Job。Claude 无状态运行：要么作为 CI runner 上的非交互步骤，要么作为沙盒容器中的 Agent SDK 服务。由于运行无状态、非交互，闭环无需任何人启动即可开始并结束。
智能体按规划阶段格式把诊断写成 intent.md，包括异常及证据、预期结果、受影响系统和待解决问题；随后像其他工作一样进入流水线。
服务负责人或值班工程师分流队列，把面向产品的发现交给产品负责人，并决定立即修复、排期或忽略。被忽略的发现可用于调节控制带、降低噪声。
修复上线后，为该事故增加一项持续评测，避免同类问题再次发生。

bands.yaml 示例：监控 CI 测试失败率

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

治理注意事项

响应层级边界由版本化配置强制执行，权限和托管设置拒绝生产访问。调用、发现和分流决定均带时间戳记录。服务负责人分流并批准发现；最终变更经过正常 PR 评审关卡；智能体可触发的 runbook 均已预先批准。

衡量方式： 领先指标是控制带越界到 intent.md 进入分流队列的时间，并与旧流程中从事故到复盘行动的时间比较；检测日志保存越界时间戳和层级。滞后指标是最终转化为已合并修复的发现比例，以及应随修复进入评测套件而下降的同类重复事故。

示例

CI 测试失败率超过 3σ 时，智能体隔离不稳定测试或创建回滚 PR，由评审关卡决定。
部署后 5xx 比例超过 3σ，且窗口内发生过部署时，智能体触发现有回滚流水线。
PR 周期时间触发漂移规则时，智能体为工程管理层撰写报告，说明该体系也适用于流程指标，而不仅是生产指标。

检测始终保持确定性。只有控制带越界后才调用 Claude，其响应层级决定可执行的动作。

让 Claude Tag 参与值班

事故也可能来自 Slack、Teams 等工作沟通应用。比如晚十点事故频道里出现紧急修复消息，如今可立即得到处理。Claude Tag（目前在 Slack 中 public beta）让 Claude 以独立身份成为频道成员，使每个新事故都有第一响应者；响应本身也成为闭环的一部分，并进入未来事故的记忆。

对话与组织知识留在频道中，任何频道成员都能引导响应并采取行动。团队成员可以实时验证假设、探索方案和调查问题，频道历史增强可审计性。通过 MCP，Claude 可验证指标已回到基线并在线程中确认；它还会把复盘写入受版本控制的经验文件，供以后调查读取。

Claude Tag 处理的不只是事故。无论通过 MCP 在工单中标记，还是在频道中请求，Claude 都以相同方式分流：范围小、边界清晰的修复通过评审关卡形成 PR；更大的工作则写成规划阶段的 intent.md，闭环开始自行供给。

频道就是审计轨迹：请求、诊断、人工授权和修复都留在处理事故的地方。

结语

随着模型和智能体运行框架日益成熟，组织能够改造的不只是代码生产方式，而是整个软件开发生命周期。

这场转型仍把人的判断置于流程核心，同时兼顾大型企业的治理与监管要求。

本指南汇总了 Anthropic Applied AI 团队每天为客户落地的许多真实最佳实践，希望它能成为一份实用、可执行的参考。

闭环持续运行，人的判断始终位于其上。

资源与致谢

以下文档大体按照平台团队建立这些控制措施的顺序排列：

为组织设置 Claude Code：管理员决策图，从这里开始
设置参考与优先级，包括全部托管专用键
从 Claude 管理控制台下发服务端托管设置
权限
沙盒：操作系统级文件系统与网络隔离
Hooks 指南
Hooks 参考
Skills
插件与私有市场：如何在组织范围分发 skill 和 hook
托管 MCP：集中控制智能体工具面
企业部署概览：Bedrock、Vertex、Foundry
企业网络配置
监控（OpenTelemetry）
分析仪表盘
Compliance API：企业活动流、聊天检索与删除
安全模型

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献；本文也借鉴并延续了他们此前的大量工作。

原文链接：The AI-Native SDLC playbook