AI 原生 SDLC 实战手册

转载并翻译自 Anthropic 官方文章 The AI-native SDLC playbook，原作者 Louis Claxton，版权归原作者所有。

如何借助 AI，逐阶段改造软件开发生命周期。

作者：Louis Claxton · 原文：https://claude.com/resources/articles/the-ai-native-sdlc-playbook · 2026-08-21

想看 PDF 版本？这份实战手册也可下载——同样涵盖六个阶段、各项打法和完整示例，适合离线阅读或与团队分享。下载 PDF ↓

代码不再是瓶颈

组织已开始用 AI 写代码，速度之快在一年前还难以想象，但围绕代码的流程并没有以同样的速度改变。

许多工程团队仍沿用原来的审批关口、审查、交接和政策，阻碍了 Claude Code 等智能体编程工具带来的生产力提升。

软件开发生命周期（SDLC）是软件从构想到上线所经历的过程。大多数组织的流程都会以某种形式涵盖规划、设计、构建、测试、部署和维护这六个阶段。传统上，每个阶段都是由不同角色负责的独立环节：产品经理撰写需求，技术架构师将需求转为设计，工程师按设计开发，受监管企业的 QA 团队负责验证，发布团队负责上线，运维团队监控运行中的系统。工作通过文档、工单和签核在各阶段之间流转。

传统 SDLC 为确保每一步都有明确的责任和控制，设置了大量流程。然而，它诞生于编写和实现代码最耗时、成本最高的时代，因此着重优化这一环节的效率；如今情况已变。PRD、估算仪式和产品安全审查，都是为了让可能持续数周、数月甚至数个季度的开发工作保持方向一致。

传统 SDLC 的控制措施还假定每一步都由人完成。最能从 AI 获益的组织，已经围绕智能体 AI 如今的能力重建流程，同时确保人始终参与其中。本指南借鉴我们与客户合作的经验，介绍应用 AI 团队在内部将 Claude 融入 SDLC 各阶段、加快开发和流程运转的多项最佳实践。

当代码不再是瓶颈，而构建阶段比传统 SDLC 所允许的速度更快时，会出现三种情况：

• 瓶颈转移到构建阶段的前后环节，主要是规划、审查与测试，以及部署；这些环节仍以人的速度运转。
• 控制措施与现实脱节，变得难以执行。代码由人编写时，逐行人工审查是合理的；当差异中的大部分代码由智能体生成时，这种方式就跟不上了。
• 治理成本上升，因为例外情况仍要经过每周或每月才开一次的会议和委员会。

构建不再是制约因素，制约因素是它前后仍以人的速度运转的环节。构建时间缩短到数小时，这些环节的耗时却没有随之缩短。

以安全审查为例。安全团队的规模按人工产出配置；智能体让代码产出倍增后，审查队列要么越积越长，要么代码在审查不足的情况下上线。受监管组织无法接受任何一种结果，因此安全与政策检查必须跟上智能体的速度。

要更充分且安全地发挥智能体 AI 的生产力，传统 SDLC 需要经历与代码实现阶段同等程度的变革。

什么是 AI 原生 SDLC？

AI 原生 SDLC 是一套重新设计的流程：它保留原有的控制目标，同时采用新的强制执行机制。流程从线性推进变为循环，AI 嵌入每个环节。AI 原生 SDLC 推动自动交接，并自动触发后续打法，以改善传统 SDLC 各阶段之间人工交接繁琐、笨重的问题。

这种转变也被称为智能体 SDLC、AI SDLC，或简单称为智能体软件开发；叫法不同，说的是同一件事。

AI 原生 SDLC 六个阶段的变化

下表展示了传统 SDLC 与 Claude 支持的 AI 原生 SDLC 这一连续谱的两端。大多数组织处于两者之间。

阶段	传统 SDLC	AI 原生 SDLC
规划	由委员会收集需求，经过研讨会和签核提炼，再手工写成文档	Claude 直接从信息来源归纳痛点，记录在既供人阅读、又可供机器执行的 intent.md 中
设计	分析师撰写规格说明，设计师再加以解读	在一次与智能体协作的工作会话中完成需求和设计；由写成 skill 并在 git 中管理版本的标准提供指导
构建	人工编写测试和代码，主要开发工作结束后再写文档	AI 生成测试和代码；组织知识通过可供机器读取、纳入版本管理的 CLAUDE.md 文件和 skill 维护
测试	在阶段边界设置 QA 关口	在实现过程中持续开展 eval
部署	人工逐行审查代码，治理依赖周期性的审查，执行往往不一致	分层开展智能体审查，人工审查聚焦受监管和关键代码；AI 行动时即执行治理，以 hook 作为审批关口
维护	人工监看生产环境中的故障	智能体监控线上部署；一旦突破控制带，就诊断问题，并将结果作为新的 intent.md 写回循环

右侧各阶段的共同主线，是提交到版本控制中的产物。每个阶段结束时都会写入一份产物（包括 intent.md、spec.md、plan.md、代码差异及其测试、附带审查发现的 PR，以及事故记录），下一阶段则从读取它开始。早期阶段主要使用 .md 文件，因为产品负责人和智能体都能阅读同一文件并据此行动。从构建阶段开始，产物则是代码及相关记录。这一串提交同时构成审计轨迹：谁提出了什么要求、智能体产出了什么、谁批准了它。

凡是需要判断的决策，最终仍由人负责。在智能体 SDLC 中，人的注意力会随着需要审查的产物而转移。

每个阶段都会提交一份供下一阶段读取的产物。意图、规格说明、计划、代码差异和审查发现共同构成审计轨迹。

打法

打法（play）是这份实战手册的核心，按规划、设计、构建、测试、部署、维护六个非线性阶段组织，合起来覆盖完整生命周期。

每项打法都涵盖：

• 具体有哪些变化；
• 起步；
• 具体实施步骤；
• 治理考量；以及
• 如何衡量成效。

这些步骤可按模块采用，组织可根据自身需要，优先改造不同阶段。每项打法都会在“前置条件”下列出依赖关系，依赖关系图也会进一步展示。

一个阶段以提交产物结束，而这次提交又启动下一阶段：被接受的 intent.md 触发需求与设计工作；获批的 spec.md 触发 plan mode；合并的 PR 触发流水线；生产环境突破控制带时，则写出下一份 intent.md。循环由此持续。

起初，各步骤由人工逐一提示执行；最终目标是让每份被接受的产物自动触发下一道关口。人的注意力集中在关口上，审查智能体标出的事项，而不必从头启动每个阶段。

图中列出了各项打法所属的阶段；箭头表示采用顺序。两者并不相同。可以从图中任意一个陶土色打法开始——没有箭头指向它，因此无需先采用其他打法。对于其余打法，指向它的箭头表示应先采用哪些打法。

01 · 规划

构想不再等人整理成文档。提出者只需用自己的话记录一次意图，形成纳入版本管理的产物，供下一阶段直接使用。

记录为 intent.md

启动软件开发流程的 intent.md 可以从多种路径产生：有人提出构想、有人提交工单，或告警暴露了某起事故（见第 6 阶段：维护）。

当有人提出构想时，可以与 Claude 集思广益，形成一份 Markdown 格式的初步规格说明。在传统 SDLC 中，同一个人还得说服产品团队成员与自己一起写下这个构想，或请对方代写。

Claude 生成的初步规格说明可供人阅读，纳入版本管理后，下一阶段即可直接使用。这份初步规格说明保存为 intent.md。

无论意图来自事件触发还是智能体，后续步骤都一样：产品负责人在提交智能体撰写的 intent.md 之前，先审查并纠正它。

传统	AI 原生
一个构想必须经过待办事项、用户故事、故事点和需求梳理会议，才有人能着手处理。每次交接都会转移负责人，因此最终到达工程团队的内容，已与提出者的本意隔了好几层。	提出者与 Claude 讨论，并用自己的话把结果写成初步规格说明 intent.md。这份产物记录想要什么、为什么要做，以及有哪些约束。重复性的流程则编码为 skill。

起步

• 前置条件：无。
• 基础设施：让非工程人员也能使用 Claude（claude.ai 或 Cowork）；约定好的 intent.md 模板；以及由产品负责人关注、共享且纳入版本管理的意图存放处。对于单个产品，最简单的做法是在产品代码仓库中创建 intent/ 目录，让产物链与由它产生的代码放在一起。只有当意图横跨多个仓库时，专门建一个意图仓库才值得承担额外开销；在单体仓库中，一个目录即可。第 3 阶段“构建”的补充说明会介绍这里与已保存正式记录的 Jira 或需求工具如何衔接。

搭建这一环境是平台或工程团队的一次性工作。技术团队成员需要建立意图存放处，并决定谁可以写入，因为贡献者可能来自组织各处。

仓库建好后，不熟悉 git 的贡献者也无需直接使用 git。借助与版本控制系统（如 GitHub）连接的工具，他们可以在 claude.ai 或 Cowork 中让 Claude 代为提交 Markdown 文件。

如何执行

1. 提出者用自己的话向 Claude 描述问题。可以说目前做不到什么、这一构想会影响谁、理想结果是什么，或哪些内容不在范围内，无需使用正式术语。
2. 持续讨论，直到构想足够具体。Claude 会提出分析师通常会问的问题：范围、用户、约束，以及成功是什么样子。
3. 让 Claude 按组织模板把讨论结果写为 intent.md。模板可以编码为由技术团队成员设置、负责人签核的 skill，涵盖问题、预期结果、受影响的用户和系统、约束及待解决的问题。
4. 提出者纠正 Claude 理解有误之处。
5. 将 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 历史中。产品负责人负责批准；接受或拒绝意图、决定是否进入第 2 阶段“设计”的结果，会记录为合并操作或关闭审查的记录。

如何衡量

• 先行指标：从首次讨论到提交 intent.md 的时间，可从记录作者和时间戳的意图存放处 git 历史中读取。预期是从长达数周的需求发掘与梳理周期缩短到数小时。
• 滞后指标：存活率，即产品负责人接受并让其进入第 2 阶段“设计”、而非关闭的 intent.md 所占比例。接受或拒绝的决定记录在产物合并或审查关闭的记录中。此外，还要统计同一项变更的 intent.md 在首次提交 spec.md 后又修改了多少次。

02 · 设计

需求与设计在一次会话中完成。政策在撰写规格说明时就得到应用，而非等到数周后审查时才发现需要遵守这些政策。

需求与设计

产品负责人批准 intent.md 后，Claude 会以它为依据，生成需求与设计规格说明。组织关于品牌、安全、合规和 UX 的 skill 会指导这一过程。

产品负责人审查规格说明，但不亲自撰写。目标是生成一份工程团队可以据此规划、并标明了需要关注之处的规格说明。

前端工作最能说明这一点。intent.md 被接受后，产品负责人以 intent.md 为基础，在 Claude Design（测试版）中制作设计原型、反复调整，再导出到 Claude Code 进行构建。

传统	AI 原生
需求和设计是由不同团队负责的独立阶段。分析师将构想正式整理为需求，设计师再据此形成设计。分开处理有助于明确责任，但速度慢，信息也容易流失。	两个阶段在一次提示驱动的会话中完成。Claude 读取 intent.md，在组织 skill 设定的约束下生成需求与设计规格说明，并标出值得关注的问题。

起步

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

如何执行

1. 产品负责人开启一个可使用组织 skill 的会话，并附上 intent.md。
2. 产品负责人的提示应指向 intent.md，明确约束，并要求标出需要关注的问题。开始时手动执行，随后将其固化为组织级斜杠命令。再往后，可以将意图存放处接受 intent.md 作为触发条件：合并时启动非交互式任务，加载组织 skill 执行这一环节，并以 PR 形式提交 spec.md（第 5 阶段“部署”的 CI/CD 打法介绍了具体衔接方式）。此后，产品负责人第一次介入就是审查。
3. 同一位产品负责人对照最初构想审查规格说明：它是否解决了所述问题？intent.md 中的待解决问题是否已得到回答，或明确留待后续处理？
4. 优先处理标出的关注点，因为这些正是分析师原本会升级处理的问题。产品负责人应在工程团队看到规格说明前，与相应政策负责人逐一解决。
5. 将 spec.md 提交到 intent.md 所在的位置。这对文件记录了最初要求和最终决定。
6. 产品负责人决定规格说明和意图是否进入构建阶段；对于组织认定的较高风险事项，应征询技术负责人的意见。这个决定始终由团队成员作出；接受规格说明后，才会启动第 3 阶段“构建”中的 plan mode 打法。

示例（提示词）

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 之间的经过时间（两个 git 时间戳），并与旧的需求加设计周期比较。
• 滞后指标：构建开始后的需求返工。统计同一项变更中，spec.md 在首次提交 plan.md 之后又提交了多少次，可直接从 git 日志中获取。

03 · 构建

计划未获批准前，不开始实现。组织知识成为智能体会读取的文件，护栏则由代码执行，不再只靠习惯。

默认从 Claude Code plan mode 开始

工程师以 plan mode 启动 Claude Code 会话，交给 Claude 第 2 阶段“设计”中获批的 spec.md，让它通过提问逐步完善计划，直到工程师满意为止。

传统	AI 原生
工程师读完设计就开始写代码。具体会改哪些文件、运行哪些测试，以及如何实施变更，通常只留在工程师脑中，最多写在工单评论里，别人无从审查。审查者第一次看到的是最终代码差异，到那时返工已经很慢。	工作从 Claude 在 plan mode 中生成的书面计划开始；此时它可以读取代码库，但不能修改。工程师在写代码前修正计划，并将获批版本提交为 plan.md，供后续阶段核对。

起步

• 前置条件：已有意图产物（intent.md 或 spec.md）时应提供；CLAUDE.md 也有帮助。
• 基础设施：可访问代码仓库的 Claude Code。

如何执行

1. 工程师与 Claude 一起以 plan mode 启动会话。
2. 工程师提供 intent.md 和 spec.md，要求 Claude 制订实现计划，列出要改动的文件、工作顺序和用于证明结果的测试。
3. 追问计划可能破坏什么、哪一步风险最高，以及 Claude 放弃了哪些其他方案。
4. 反复完善，直到一位完全没看过对话的工程师仅凭计划也能实现这项变更。
5. 将获批计划提交为 plan.md。计划由此进入审计轨迹，第 5 阶段“部署”的 PR 审查打法会将最终代码差异与它核对。
6. 接受计划，让 Claude 开始实现。计划扎实时，实现往往一轮即可完成。
7. 如果实现偏离计划，应在同一次提交中更新 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.

治理考量

设计审查发生在生成代码之前，此时调整方向只需修改文档。plan mode 本身会强制这一点，因为工程师接受计划前，Claude 无法编辑文件。计划及其修订、接受计划的人，都会留下记录。常规变更由工程师批准；组织认定的较高风险事项则交给技术负责人或架构师。

如何衡量

• 先行指标：第一轮实现即可合并的变更比例，以及从计划获批到 PR 合并的时间；所需数据可从 PR 元数据中获取。
• 滞后指标：每项变更的返工轮数，同样可从 PR 元数据中获取；以及合并后的代码差异有多频繁仍与已提交的 plan.md 一致。

Claude Code 的 auto mode

Claude Code 也可以在 auto mode 中运行：工程师批准经过反复完善、自己满意的计划后，Claude 无需逐次询问即可应用每项修改。随着后续打法中的护栏日趋成熟——调校好的 CLAUDE.md、编码了政策的 skill、拦截不安全操作的 hook，以及 Claude 能自行运行的测试套件——对于规格明确的 spec.md、影响范围小且已有测试覆盖的常规工作，自动接受将成为默认方式。

工作方式随之改变：用户不再盯着智能体逐项编辑和审查每个动作，而是在更长时间的自主会话结束后审查产物。配合 worktree，自动接受模式还让个人和团队能够进一步并行工作，也是第 6 阶段“维护”所述的 SDLC 自主运行和闭环的基础。

遗留系统与唯一可信来源

补充说明——适用于流程产生的每一份产物。

现有 SDLC 流程很可能已经追踪各类产物，只是它们并非 Markdown 文件。工作项可能在 Jira 中，需求在内置监管可追溯能力的工具中，设计在 Figma 中，变更批准由变更委员会管理。这些系统难以替换，因为审计人员和监管机构已经认可它们，其他团队也依赖它们。因此，AI 原生 SDLC 必须与现有系统衔接。

向 AI 原生 SDLC 过渡时，应为流程产生的每类产物指定一个唯一可信来源，其余系统只保留副本或原件链接。下面几种配置都能做到这一点，不同产物可以作不同选择：

以代码仓库为唯一可信来源。 Markdown 产物是权威记录，遗留系统引用具体提交中的文件。对于工程主导的组织，这可能是最简洁的配置之一：所有记录都在一个工具中，时间戳也由同一来源确定。

以遗留系统为唯一可信来源。 Jira、ServiceNow 或需求工具保存权威记录，Markdown 产物作为工作副本。Claude 在会话开始时读取正式记录，并在生成规格说明或计划的同一次会话中，通过 MCP 连接器把结果写回去。

至少建立双向关联。 所有产物注明正式记录 ID，所有遗留系统记录都包含 Markdown 文件的提交 SHA。在向 AI 原生 SDLC 过渡、暂时存在两个可信来源时，建立关联是一个合适的起点。

只要两套系统之间有链接，或其中一套被指定为唯一可信来源，遗留系统与优先采用 Markdown 的系统就可以共存。

CLAUDE.md

CLAUDE.md 为 Claude 提供新成员入职时所需的背景信息，包括约定、命令、架构以及团队最常遇到的错误。原本散落在人们脑中和 wiki 上的知识，变成智能体每次会话开始时都会读取的文件。整个团队共同维护它，每次发现错误就继续完善。

起步

• 前置条件：无。
• 基础设施：一个代码仓库、已安装的 Claude Code，以及一位熟悉代码库的工程师。

如何执行

1. 在仓库中运行 /init。Claude 会根据仓库内容生成初版 CLAUDE.md。
2. 将生成的文件精简到新成员第一天真正需要的内容：保留构建、测试和 lint 命令，重要约定，以及 Claude 反复犯的错误。
3. 将 CLAUDE.md 放在仓库根目录并提交到 git，供团队共享同一版本，变更也像代码一样接受审查。
4. 一个实用原则：Claude 同一个错误犯了两次，就把纠正方法写进 CLAUDE.md。
5. 控制在一页以内，因为 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 防止的错误。对 CLAUDE.md 的纠正和修改应在 git 历史中追踪。
• 滞后指标：新团队成员从加入到首个 PR 合并所需的时间，从 PR 历史中获取。

将 skill 用作组织知识

skill 让组织知识成为可执行的工作规则。指令是明确的、纳入版本管理的、广泛适用的，并在政策变化时集中更新。经验法则是：需要一致执行的组织知识，应写成 skill；属于 CLAUDE.md 或单次提示词的内容，则不要写成 skill。

起步

• 前置条件：无硬性要求。有 CLAUDE.md 会有帮助，因为它把智能体的工作知识留在仓库里，但 skill 并不依赖它。
• 基础设施：一项有明确负责人和书面权威来源的政策。

如何执行

1. 选择一项目前执行不一致的规范，例如安全标准、API 设计约定或品牌规则。
2. 将它写成 skill：建立包含 SKILL.md 的文件夹，在其 frontmatter 中说明何时触发，在正文中说明该怎么做。工程师依据政策负责人的权威资料编写，并可请 Claude 协助。
3. 将 skill 放在仓库的 .claude/skills/<name>/ 中，使其随代码交付；或通过 plugin 在组织内分发。
4. 测试 skill 是否被触发：用不同方式要求 Claude 执行相关任务，确认每次都会加载 skill。
5. 政策变化时，更新 skill，并请政策负责人签核。
6. 工程师在下次会话中会自动用到新版本。

示例（.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 在编写代码时应用政策的可能性，却不能强制每次会话都遵守。必须始终生效的政策，还需要在 skill 背后设置确定性措施，例如拦截操作的 hook，或在 PR 阶段重新检查政策的审查环节。skill 让违规罕见，hook 则让违规几乎不可能发生。skill 的调用记录在会话轨迹中，政策负责人像审查代码一样审查 skill 变更。

如何衡量

• 先行指标：从政策负责人批准政策变更到更新后的 skill 合并所需的时间，可从 skill 目录的 PR 中获取。
• 滞后指标：引用该政策的 PR 审查发现数；当 skill 在写代码时就应用了政策，这个数字应趋近于零。如果没有下降，可能是 skill 未触发，或其内容已偏离正式政策。

用 hook 设置构建阶段护栏

skill 是指导性的控制措施，而 hook 则是背后的确定性执行层。Claude 在实现阶段的大部分动作是编辑文件和运行 shell 命令，因此 hook 往往在构建阶段触发得最频繁。

构建阶段的 hook 可以：

• 阻止编辑生成的类或冻结的代码包等受保护路径；
• 每次文件编辑后运行格式化工具和 linter，避免偏差累积；
• 防止凭据进入代码差异。

凡是必须毫无例外地遵守的 skill 政策，都应有 hook 支撑。hook 会在每个匹配的动作上运行，因此构建阶段的 hook 应快速执行，且只针对发生变更的文件。完整测试套件等较重的检查，应放在提交或 PR 阶段。

要求人工批准的 hook 应归入第 5 阶段“部署”的关口，因为构建期间弹出审批请求，会让人重新成为所有并行会话的关键路径。

并行会话与 subagent

一位工程师可以同时推进多条工作线。

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

subagent 则在单个会话内运行，是具有独立上下文窗口和工具权限范围的辅助角色，适合在多个任务中重复出现的工作，例如验证应用是否按预期运行。

并行会话增加工程师同时推进的任务数，subagent 则让每个会话专注于自己的任务。工程师的工作转为引导并审查它们的成果。

传统	AI 原生
一位工程师一次处理一项任务，一天或一周中有相当多的时间花在等待构建、测试和审查上。等待期间可以切换任务，但切换上下文太累，很少有人愿意这样做。	一位工程师同时运行多个 Claude 会话，每个会话在自己的 worktree 中处理自己的任务。重复性工作交给拥有独立上下文和工具限制的 subagent。工程师的工作转向编排，最终转向构建和监控循环。

起步

• 前置条件：CLAUDE.md，因为所有会话都会读取它。第 4 阶段“测试”中的反馈循环也有帮助；会话能自行验证工作时，工程师所需的监督就更少。
• 基础设施：一个 git 仓库，因为隔离依靠 worktree 实现；还需调好权限设置，让组织认为安全的命令不会总在等待审批提示。

如何执行

1. 工程师借助第 3 阶段“构建”的 plan mode 打法制订的计划，找出可以独立进行、涉及不同文件的任务。共用文件的任务则放在同一会话中依次执行。
2. 每个并行任务分配一个 worktree，例如在一个终端运行 claude --worktree feature-auth，在另一个终端运行 claude --worktree fix-rate-limit。worktree 是独立分支上的单独检出目录，可防止会话在文件上互相冲突。
3. 从两三个会话开始比较合适。实际能运行多少，取决于一个人能认真审查多少条工作线；只有审查跟得上时才增加会话。
4. 将重复性工作做成 subagent，定义在 .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 历史计算的返工率一起看。

04 · 测试

每个会话都要先检查自己的成果，再交给人看；引导智能体的配置也像它编写的代码一样接受回归测试。

为 Claude 建立反馈循环

始终让 Claude 有办法验证自己的工作，无论是测试、构建，还是截图差异。会话应先自查并修正错误，再交给工程师。

反馈循环不能与验证用的 subagent（第 3 阶段“构建”）混为一谈。反馈循环贯穿整项任务，工作进行多少轮，检查就运行多少轮。而验证 subagent 是打包最终检查的一种方式：当会话认为任务完成时，让一个全新上下文窗口执行检查，避免结论受到生成代码时的假设影响。

传统	AI 原生
代码是否正常工作的信号来得很晚：几分钟后 CI 才反馈，几天后测试人员才发现，几周后生产环境才暴露问题。智能体生成代码时，信号来得晚意味着必须由人检查它的全部产出，而这个人就成了瓶颈。	会话在交给人看之前，已有办法自行检查：运行测试、执行构建、截取屏幕。Claude 反复迭代直到检查通过，因此工程师看到的成果已经过验证。搭建反馈循环是运行会话的工程师的职责，以下步骤也是为他们编写的。

起步

• 前置条件：无。
• 基础设施：可分别用一条命令在本地运行的测试套件和构建流程。对于 UI 工作，让 Claude 看见结果至关重要，可以使用浏览器工具，或通过 MCP 接入截图工具。

如何执行

1. 如果目前检查工作需要一串命令和特定环境知识，就把它封装成一个目标，例如“make test”或“npm test”，失败时返回非零退出码。
2. 在 CLAUDE.md 的 Commands 部分列出每条命令，并给出正常输出的示例。
3. 明确可量化的目标，让 Claude 无需询问就能自查，例如“test_status.py 中的所有测试都通过”、“截图与附带的设计模型一致”，或“接口返回 200 且包含新字段”。
4. 修复 bug 时，先写失败测试。让 Claude 将 bug 复现为测试、运行测试，并确认它因预期原因失败。提交这个测试后，再要求 Claude 在不编辑测试的情况下让它通过，并用本节最后提到的测试文件 hook 强制这一限制。修复前就存在、智能体又无法改写的测试，是 bug 已消除的证据。
5. 对于 UI 工作，用视觉检查完成反馈循环。给 Claude 浏览器或截图工具和设计模型，让它反复实现、截图、比较、调整。通常要两三轮，结果应逐轮改善。
6. 把验证纳入“完成”的定义。指令放在 CLAUDE.md 中：报告任务完成前运行测试，并展示输出。
7. 最后，反馈循环本身也需要保护，因为修复代码的智能体不能同时削弱检查该代码的机制。可以用 hook 阻止修复任务编辑测试文件；另一种做法是在审查时检查代码差异，拒绝任何涉及测试的修改。

示例（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”原始输出、构建日志或截图差异，因此证据直接来自工具链。
• 记录在哪里：会话记录中；OpenTelemetry 导出会把它转发到组织的可观测性系统。PR 的检查运行记录里也会保留，供审查者和之后的审计人员查看。
• 谁来批准：审查 PR 的代码负责人；机械性的证据已经附上，他们可以专注于意图和风险。

如何衡量

• 先行指标：智能体编写的变更首次运行 CI 的成功率，CI 系统本就支持统计这一指标。
• 滞后指标：每个 PR 的审查时间（来自 PR 元数据）；当测试能发现过去由审查者发现的问题时，这一时间应缩短。同时关注事故跟踪系统中的变更失败率。

在 CI 中持续开展 eval

eval 相当于 AI 原生流程中的阶段关口 QA。实际做法是建立一个套件，只要智能体配置发生变化就运行。切换新模型或重写提示词时，eval 套件会判断智能体是否仍能按同样标准完成工作。

eval 应被视为持续更新的套件。随着模型进步，曾经能区分表现的用例可能不再有区分度，必须加入持续监控中发现的新用例。

视使用场景而定，有些团队可能更愿意定期离线运行 eval，而非每次变更都运行。下面的步骤适用于持续评估。

起步

• 前置条件：CLAUDE.md 和第 4 阶段“测试”中的反馈循环。
• 基础设施：能够非交互式运行 Claude Code 的 CI，以及为 eval 运行分配了预算的 API 密钥。

如何执行

1. 平台工程师从近期工作中收集 20 到 50 项真实任务，以及每项任务预期或已接受的结果。
2. 将每项任务写成一个 eval，即提示词加上界定可接受结果的检查条件（测试通过、lint 无问题、行为不变、遵守政策）。
3. 套件在 CI 中定期非交互式运行；CLAUDE.md、skill 或 hook 发生任何变更时也要运行，因为这些配置会引导智能体，理应像代码一样接受回归测试。
4. 用结果为配置变更设置关口。若 skill 变更导致通过率下降，应在合并前审查。
5. 每次生产事故都要由负责该事故的团队写成一个 eval，并永久保留在套件中作为回归测试。

示例（.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

治理考量

eval 为 QA 提供跟得上智能体产出速度的关口。通过率阈值作为合并检查强制执行；每次运行都有记录，便于比较长期结果；配置变更由负责该配置的团队批准。

如何衡量

• 先行指标：每次运行时套件报告的 eval 通过率变化，以及生产事故转化为永久 eval 所需的时间。
• 滞后指标：从事故跟踪系统统计，比较 CI 捕获的回归问题与生产环境发现的回归问题。

05 · 部署

审查双向进行，治理在智能体行动时执行。智能体可以完成生产发布关口之前的一切工作，但不能越过这道关口。

将 AI 纳入 PR 审查循环

Claude 既提供审查，也接受审查。它按组织政策审查新提交的 PR，也处理自己 PR 上的审查评论。这样，工程师在审查 PR 时可以专注于行为，也就是判断意图和风险。

传统	AI 原生
审查能力按人工产出规划。一个 PR 要等审查者读完全部内容；审查质量随审查者的工作量波动；待办队列越积越长，作者只好不断催促。	所有 PR 都经过相同的一组审查环节，并按严重程度排列发现。人的注意力上移，转而判断变更是否实现计划意图、风险是否可以接受。

起步

• 前置条件：第 3 阶段“构建”中更新的 CLAUDE.md；若审查环节要执行书面政策，还需相应 skill；以及已定义的 subagent。
• 基础设施：安装了 Claude 集成的仓库。可以由管理员启用托管的 Code Review 服务，也可以在自己的 CI 中运行 claude-code-action；需要时可通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 调用模型（CI/CD 打法介绍部署选项）。要求代码负责人批准的分支保护政策也很有价值。

如何执行

1. 托管的 Code Review 服务是最快的入门方式：管理员启用并选择仓库。若需要控制流水线，或希望 API 调用走自己的云服务协议，就在自己的 CI 中通过 claude-code-action 运行审查（CI/CD 打法会介绍具体衔接方式）。
2. 技术负责人在仓库根目录编写 REVIEW.md 作为审查政策，按组织关注的环节划分：bug 与逻辑错误；安全与漏洞；是否符合需求打法中的 spec.md、plan mode 打法中的 plan.md，以及设计原则。REVIEW.md 还要定义哪些问题属于 Important、哪些只是 Nit，以及哪些应跳过。
3. 技术负责人设定人工审批门槛。审查发现本身不会批准或拦截 PR；分支保护仍要求代码负责人批准。若平台工程师希望根据发现控制合并，可以读取检查运行发布的、机器可读的各严重程度计数。
4. 审查者或作者在审查评论中提及 @claude 时，Claude 会处理评论并推送修复。PR 讨论串同时记录请求和变更。这个修复循环通过 claude-code-action 运行；在托管服务中，评论 @claude review 则会请求重新审查。对于 Claude 自己创建的 PR，还可以让它持续跟进直到可合并：团队将这一循环封装为自定义斜杠命令，逐一处理 PR 上未解决的审查评论和失败的检查，推送修复，直到 PR 全部通过、只等待代码负责人批准。
5. 将审查发现反馈到 CLAUDE.md。同一错误第二次被审查指出时，就在该次审查中将纠正方法写入 CLAUDE.md。由于审查也会读取 CLAUDE.md，从下一个 PR 起就能发现这类错误。审查还应指出变更是否使 CLAUDE.md 过时。
6. 技术负责人每月通过为审查发现评级来调校设置，以改进审查效果，并在 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 本身就是审计记录。批准由人通过分支保护作出，审查发现为其提供依据。

关于这些控制措施如何在生产规模下组合使用，参见Anthropic 如何保障 AI 原生 SDLC 的安全。

如何衡量

• 先行指标：首次审查等待时间，应缩短到几分钟；以及无需人动分支即可解决的审查评论比例，数据直接保存在 Git 中。
• 滞后指标：对照 PR 历史与事故跟踪系统，比较合并前发现的缺陷和漏洞与流入生产环境的缺陷和漏洞。

用 hook 设置审批关口

构建阶段用 hook 充当护栏，不经人工介入即可允许或拦截操作（第 3 阶段“构建”）。hook 也可以发起询问，让操作暂停，直到指定人员批准；发布关口需要的正是这种能力。

这项打法放在第 5 阶段“部署”，是因为发布关口最容易说明问题，但 hook 并不限于部署：Claude 在哪里行动，hook 就能在哪里运行。例如，第 3 阶段“构建”中，hook 可以在缺少变更工单时阻止编辑迁移文件和基础设施相关文件；第 4 阶段“测试”中，则可以阻止智能体在修复任务中编辑测试文件。

起步

• 前置条件：无。
• 基础设施：一份书面清单，列明变更流程要求的各项批准。

如何执行

1. 工程管理层与变更管理和合规团队共同列出必须保留的人工审批关口，例如变更管理签核、发布授权，以及编辑受保护路径的审批。
2. 平台工程师将每道关口实现为 hook，即 Claude 行动前运行、可以允许、询问或拦截的脚本。
3. 团队级 hook 放在 git 中的 .claude/settings.json；必须强制执行的 hook 放在平台或 IT 管理员管理的托管设置中，让工程师个人无法将其关闭。
4. 拦截原因应说清楚。当 hook 阻止操作时，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、agent、hook 和 MCP 服务器都来自组织批准的 plugin 市场，而非个人主目录。

allowManagedMcpServersOnly 将智能体可用的工具限定为平台团队管理的允许清单。

requiredMinimumVersion 拒绝使用低于批准版本下限的版本启动，从而确保执行控制措施的构建版本确实经过组织评估。

以上配置是供各组织调整的起点，并非建议直接照搬。每项拒绝规则都会以一部分能力为代价，合适的平衡取决于仓库的数据分级。设置参考文档列出了所有配置项，包括仅限托管环境使用的项目：code.claude.com/docs/en/settings

如何衡量（针对 hook 本身）

• 先行指标：每道审批关口的等待时间。每次 hook 决定都会带时间戳及允许或拦截的结果写入 OpenTelemetry 导出数据，因此可分别看到各关口的等待时间。
• 滞后指标：从事故跟踪系统比较部署 hook 前后进入生产环境的关口违规事件。

CI/CD 集成与部署

在 CI/CD 流水线中非交互式运行 Claude Code；将执行过程置于沙箱，让长时间运行的智能体任务安全运行；通过 MCP 集成开放部署能力；并在智能体真正需要回滚之前，就演练好回滚路径。

传统	AI 原生
流水线运行确定性脚本，凡是需要判断的事都等待人处理，例如排查不稳定测试、撰写更新日志，或找出构建失败原因。部署和回滚则按操作手册由人在压力下执行。	Claude 在流水线内的沙箱中，以限定权限的凭据非交互式执行需要判断的步骤。部署工具通过 MCP 暴露给智能体，因此编写并测试变更的工作流也可以在组织为各环境定义的关口内完成上线和回滚。

起步

• 前置条件：将 Claude 纳入 PR 审查循环，并设置 hook 审批关口，因为在自动化加速流程通过关口之前，关口必须已经存在。
• 基础设施：安装了 claude-code-action 的 CI 平台，或任何能调用 claude -p 的运行器；通过 API 获取模型能力，或在流量必须遵循组织云服务协议时使用 Bedrock、Foundry 或 Vertex；面向部署目标的 MCP 服务器；以及不持有长期生产凭据的智能体任务沙箱配置。

如何执行

1. 平台工程师从只读的判断步骤开始。在流水线任务中用 claude -p 排查失败的构建、总结不稳定测试，或起草更新日志。
2. 将有写入操作的任务放在现有关口之后，例如修复 lint 问题、更新生成的文档，或通过提及 @claude 处理审查评论。智能体写入的任何内容都须以 PR 形式提交，并经过分支保护，智能体不能直接推送到 main。
3. 执行环境应置于沙箱中。智能体任务在受网络政策约束的容器里运行，使用短期、限定权限的令牌，默认不持有生产凭据。
4. 通过 MCP 开放部署能力。部署、查看状态和回滚成为按环境限定权限的工具，因此智能体的部署权限是一份允许清单，而不是带凭据的 shell 脚本。
5. 按环境划分自主级别。在开发环境中，智能体可以自由部署；在生产环境中，智能体准备发布，由发布经理授权，并由 hook 强制执行生产关口。预发布环境介于两者之间。
6. 回滚应该是流水线中演练最充分的路径：它是一条智能体可以运行、且在预发布环境中定期演练的命令。第 6 阶段“维护”的闭环打法会在突破控制带时调用这条回滚路径，所以必须提前验证。

示例（流水线步骤）

- 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 流水线日志中获取。
• 滞后指标：DevOps Research and Assessment（DORA）指标，CI 系统和部署工具通常已能提供。

06 · 维护

循环闭合。触发器无需人发起就会调用 Claude，而它发现的事项会以 intent.md 的形式重新进入流水线。

维护与闭环

到目前为止，我们讨论了如何在 SDLC 各阶段加入 Claude，而每个阶段的初始步骤仍需由人启动。这一阶段则把重点转向让 Claude 自主运行，从而闭合循环。

例如，持续运行的监控智能体可以在有人提交 bug 工单后创建 intent.md，再依次经过需求、计划、构建、测试和审查阶段。第 6 阶段“维护”以无界面方式运行，阶段之间设置独立的置信度关口——可以是确定性检查，也可以是对抗性审查智能体——以决定上一阶段的产出继续流转，还是升级给人处理。

传统	AI 原生
维护是被动响应的阶段。所有工单或事故都要等人采取行动并重新启动流程。凌晨 3 点的告警可能被漏掉；工单可能一直躺在待办队列里；如果又发生更紧急的事，事后复盘的行动项甚至可能根本进不了代码库。	突破控制带、工单、频道消息或定时任务等触发器，无需人介入就能调用 Claude。Claude 进行诊断，只通过受关口约束的路径行动，并将发现写成 intent.md，再按前述阶段流转。人负责分流和审查，不再需要亲自启动工作。

闭合循环

确定性脚本监控生产环境，一旦突破控制带就调用 Claude。监测越界是说明自主循环模式的一个实用示例；本阶段末尾的 Claude Tag（公开测试版）部分还会介绍从其他渠道进入的工作。

起步

• 前置条件：提供结构化输出、可用于重新启动循环的 Intent.md；由 Claude 加速的 PR 审查；作为行动边界的 hook；以及供 CI/CD 使用的回滚路径（最高自主级别会调用它）。
• 基础设施：检测脚本能够查询的指标存储系统（Prometheus、CI 系统 API 或类似系统）；代码仓库的读取权限；在 CI 中非交互式运行 Claude Code 的方式，或使用 Agent SDK 构建接收 webhook 的服务。

如何执行

1. 服务负责人或平台工程师选取一个具有稳定滚动基线的指标，例如 CI 测试失败率、部署后 5xx 比率，或 PR 周期时间。
2. 编写检测脚本，通常基于滚动窗口的均值和标准差，配合 Western Electric 等规则，让控制带既能捕捉缓慢漂移，也能捕捉突发峰值。脚本纳入版本管理并接受单元测试；检测过程完全保持确定性，不涉及模型。
3. 在纳入版本管理的配置中定义响应级别（见下文 bands.yaml）：达到 1σ 时，脚本只记录日志；达到 2σ 时，调用 Claude 进行只读诊断；达到 3σ 时，Claude 可以行动，但只能通过向审查关口提交 PR，或触发预先批准的操作手册。
4. 触发层可以是 GitHub 或 GitLab 的定时工作流、现有监控系统的 webhook，或网络内部的 Cron Job。Claude 以无状态方式运行，可以作为 CI 运行器中的非交互式步骤，也可以作为沙箱容器里的 Agent SDK 服务；CI/CD 打法介绍了部署和模型访问选项。由于运行既无状态又不需要交互，一个循环可以在无人启动的情况下自行开始和结束。
5. 智能体按第 1 阶段“规划”的格式，将诊断结果写为 intent.md，说明异常及证据、预期结果、受影响的系统和任何待解决的问题。随后，这项发现像其他工作一样进入流水线。
6. 服务负责人或值班工程师对队列进行分流，将涉及产品的发现交给产品负责人：立即修复、安排稍后处理，或驳回。驳回记录可用于调校控制带，减少噪声。
7. 修复上线后，为该事故添加一个 eval（见持续 eval 打法），确保今后能防范同类问题。

示例（监控 CI 测试失败率的 bands.yaml）

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 审查关口，而智能体可以触发的操作手册都已事先获批。

如何衡量

• 先行指标：从突破控制带到 intent.md 进入分流队列的时间，并与过去从事故发生到形成事后复盘行动项的时间比较。检测脚本日志记录了越界时间戳和事故级别。
• 滞后指标：最终成为已合并修复的发现比例（对照分流队列与实际 PR 历史），以及同类事故重复发生的次数；随着修复不断向 eval 套件加入用例，后者应减少。

示例

• 当 CI 测试失败率突破 3σ 时，智能体隔离不稳定测试，或提交回滚 PR，再由审查关口作出决定。
• 如果部署后 5xx 比率突破 3σ，且统计窗口内发生过部署，智能体就触发现有的回滚流水线。
• 当 PR 周期时间触发漂移规则时，智能体为工程管理层撰写报告，表明这套执行框架既适用于流程指标，也适用于生产指标。

检测始终保持确定性。只有突破控制带时才调用 Claude，响应级别决定它能做什么。

定期扫描代码库

安全扫描只反映特定模型在某一时点对代码库的判断，而代码和模型两方面都会过时：代码每周都在变化，新一代模型也会发现上一代漏掉的漏洞。AI 原生的做法是定期扫描，无需人工发起，并让发现与其他代码变更一样经过相同的关口。

Claude Security 是托管式定期扫描服务。连接 GitHub 仓库后，系统会在 Anthropic 的基础设施上使用 Claude Mythos 5 进行扫描；每项发现都会在报告前得到验证，并附带置信度评级。建议的补丁在网页版 Claude Code 中审查和应用。组织无需直接获得该模型的使用权限，也能取得扫描结果。

传统	AI 原生
安全扫描是一项定点活动，在发布或审计前才启动。报告进入跟踪系统，待办问题靠人工逐项解决，直到下一次扫描。两次扫描之间编写的代码，只能依赖 PR 审查所捕获的问题。	对每个已连接的仓库定期使用当前能力最强的模型扫描，并在任何人阅读前验证发现。每项发现都按突破控制带的方式处理：能用一个 PR 修复的，经审查关口处理；范围更大的，写成 intent.md。覆盖情况以最近一次扫描时间为准，而不是首次扫描时间。

起步

• 前置条件：第 5 阶段“部署”中的 PR 审查关口和 hook 审批关口，确保发现像其他变更一样接受审查；对于一个 PR 无法解决的发现，还需第 1 阶段“规划”的 intent.md 格式。
• 基础设施：Claude Security 面向 Claude Enterprise 组织提供公开测试版。目标仓库（云托管的 github.com）需要安装 Anthropic GitHub App，启用网页版 Claude Code，开启 Extra Usage 并设置支出上限，为运行扫描的人员分配高级席位，再由管理员在 claude.ai/admin-settings/claude-code 启用该功能。扫描按 Mythos 5 的费率根据用量计费，因此支出上限应与仓库的规模和数量匹配。

如何执行

1. 安全负责人连接仓库，并按仓库、服务或团队将它们组织成项目，从一开始就明确发现归谁负责。
2. 首先对最关键的仓库做完整扫描，包括过去由其他工具或早期模型扫描过的仓库。以首次扫描结果作为基线。即使代码此前被视为没有问题，首次扫描也很可能发现问题。
3. 为每个项目设置扫描计划。对于持续开发的服务，每周一次是合理的默认值；仓库很大或包含多种内容时，可限定到某个目录或分支。
4. 结合置信度评级对发现进行分流。驳回时写明理由并留下记录，避免同一问题在下次扫描时再次被当作新发现。
5. 对范围明确的发现，在网页版 Claude Code 中打开建议补丁，审查后像其他变更一样通过 PR 审查关口提交。提出修复的智能体没有批准修复的途径。
6. 对超出单个补丁范围的问题，例如架构缺陷或多个服务中重复出现的模式，按第 1 阶段格式写成 intent.md，从规划阶段开始处理。
7. 修复发布到生产环境后，为该漏洞类别向持续 eval 打法中的套件添加用例，使引导智能体的配置从此针对该类别接受测试。
8. 将发现导出为 CSV 或 Markdown，或通过 webhook 同步，让组织现有的跟踪和审计系统继续充当审计人员熟悉的正式记录系统。

治理考量

扫描受组织的管理员控制：连接哪些仓库、谁拥有扫描席位，以及支出上限，都由中央统一设置。每项发现都有验证结果和置信度评级，每次驳回都有理由，因此扫描历史是一份审计记录，记载了发现、修复和有意识接受的风险。

修复通过 PR 审查关口和分支保护进入生产环境，而不是由扫描直接发布。Claude Security 是对现有静态分析和依赖扫描的补充：确定性检查保留在 CI 中，模型驱动的扫描则覆盖这些检查本来就不擅长发现的、依赖上下文的漏洞。

如何衡量

• 先行指标：已连接仓库中按计划定期扫描的比例，以及从报告发现到补丁进入 PR 审查关口的时间，可从扫描历史和 PR 元数据中获取。
• 滞后指标：从事故跟踪系统比较定期扫描发现的漏洞与生产环境或外部报告发现的漏洞；并观察已完成多轮扫描的仓库每次扫描的发现数变化。随着修复和 eval 用例积累，这个数量应下降。

让 Claude Tag 担任值班响应者

事故也可能通过 Slack 或 Teams 等工作沟通应用进入。例如，晚上 10 点事故频道里一条请求紧急修复的 Slack 消息，如今就可以立即得到处理。Claude Tag（目前在 Slack 提供公开测试版）让 Claude 以自己的身份成为这些频道的成员，使每起新事故都有第一响应者，响应过程也成为闭环的一部分，并留作未来处理事故时可查的记录。

对话和组织知识都留在频道中，任何频道成员都能引导响应并采取行动。团队成员可以实时检验假设、探索新方案并展开调查；频道历史也提高了可审计性。Claude 通过 MCP 访问指标，核实指标已恢复到基线并在讨论串中确认，再把事后复盘写入纳入版本管理的经验文件，供未来调查读取。

Claude Tag 处理的不只有事故。通过 MCP 在工单中被提及，或在频道中被提出要求时，它也会以同样方式分流工作。范围小、边界明确的修复以 PR 形式进入审查关口；范围更大的工作则写成第 1 阶段“规划”的 intent.md，循环由此开始自行运转。参见：Claude Tag 如何在 Anthropic 为 CI/CD 值班。

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

结语

模型和执行框架不断进步，组织如今不仅能改变代码的生产方式，也能改造整个软件开发生命周期。

这种转型始终把人的判断置于流程核心，并考虑大型企业的治理与监管要求。

本指南汇集了应用 AI 团队每天为客户落实的许多真实最佳实践。希望它能成为一份实用、可直接采取行动的参考资料。

循环持续运转。人的判断始终位于其上。

资源与致谢

以下文档是平台团队设置这些控制措施所需的资料，大致按建议落地顺序排列。

• 为组织设置 Claude Code——管理员决策图；从这里开始
• 设置参考及优先级，包括所有仅限托管环境使用的配置项
• 通过 Claude 管理控制台配置服务器托管设置
• 权限
• 沙箱——操作系统层面的文件系统和网络隔离
• Hooks——指南
• Hooks——参考文档
• Skills
• Plugin 和私有市场——如何在组织内分发 skill 与 hook
• 托管 MCP——集中控制智能体可用的工具
• 企业部署概览——Bedrock、Vertex、Foundry
• 企业网络配置
• 监控（OpenTelemetry）
• 分析仪表板
• 合规 API——企业活动流、聊天记录检索与删除
• 安全模型

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献；他们之前的大量工作为本指南提供了启发和基础。