AI 原生 SDLC 实战手册

代码不再是瓶颈Code is no longer the bottleneck

各组织已经开始以一年前无法想象的速度用 AI 编写代码，然而围绕代码的流程却没有以同样的速度发生变化。

许多工程团队仍然保留着同样的审批关卡、评审、交接和策略，拖累了使用 Claude Code 等代理式编码解决方案所带来的生产力提升。

软件开发生命周期（SDLC）是让软件从想法走向生产的过程。大多数组织都在运行同一套六个阶段的某种版本，涵盖软件的规划、设计、构建、测试、部署和维护。传统上，每个阶段都是一个由不同角色负责的独立阶段。产品经理撰写需求，技术架构师将其转化为设计，工程师构建设计，受监管企业的 QA 团队负责验证，发布团队负责交付，运营团队监控正在运行的系统。工作通过文档、工单和签字在各个阶段之间流转。

传统 SDLC 流程繁重，是为了确保每一步都有问责和控制。然而，传统 SDLC 的设计初衷是在“编写和实现代码是最耗时、最昂贵的阶段”这一时代实现效率最大化，而如今情况已不再如此。PRD、估算仪式和产品安全评审之所以存在，都是为了在可能长达数周、数月或数季度的开发工作中强制对齐。

传统 SDLC 的控制机制还假定每一步都由人来执行。产生最大价值的组织已经围绕代理式 AI 现在能做什么重建了流程，同时确保人类始终在回路中。在本指南中，我们将介绍应用 AI 团队在 SDLC 各个阶段内部署 Claude 的最佳实践，以加速开发、让流程跑得更快——这些实践源于我们与客户的合作经验。

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

• 瓶颈转移到构建阶段左侧和右侧的环节。主要是规划、评审/测试和部署，这些环节仍以人的速度运行。
• 控制机制开始与现实脱节，变得难以处理。当代码是人所写时，逐行人工评审是合理的；一旦代理写出大部分 diff，人工评审就跟不上了。
• 治理成本上升，因为例外情况仍然要流向每周或每月开会的评审会和委员会。

以安全瓶颈为例。安全团队是按人工产出规模配置的，所以当代理使代码产出倍增时，要么评审队列堆积，要么代码在评审不足的情况下上线。受监管的组织两种结果都无法接受，因此其安全和策略检查必须跟上代理的速度。

为了更好地实现生产力收益并保障代理式 AI 的安全，传统 SDLC 生命周期需要经历与实现阶段同样程度的转型。

什么是 AI 原生 SDLC？What is an AI-native SDLC?

AI 原生 SDLC 是一种重新构想的流程，它把旧的控制目标与新的执行机制结合起来。流程不再是线性流动，而是变成一个循环，AI 被嵌入到每个节点。AI 原生 SDLC 推动自动交接和后续打法的自动触发，有助于解决传统 SDLC 各阶段之间手动交接的笨拙问题。

你也会听到这种转变被称为“代理式 SDLC”、“AI SDLC”，或简称为“代理式软件开发”——标签不同，但描述的是同一件事。

六个阶段的转变

下表突出展示了传统 SDLC 与由 Claude 支持的 AI 原生 SDLC 之间的频谱两端。大多数组织介于两列之间。

贯穿右栏的主线是“已提交的产物”。每个阶段都以将某个产物写入版本控制结束（包括 intent.md、spec.md、plan.md、diff 及其测试、带着评审意见的 PR，以及事故记录），下一阶段从读取它开始。在早期阶段，.md 文件是主要的产物，因为产品负责人和代理都能阅读并对同一文件采取行动。从构建阶段开始，产物变成了代码及其记录。提交链也是审计轨迹：谁要求了什么，代理生成了什么，谁批准了什么。

人类仍然对每一个需要判断力的决策负责。在代理式 SDLC 的世界里，人类的注意力随着需要评审的产物一起转移。

打法（Plays）Plays

打法（plays）是本手册的核心，按六个非线性阶段（规划、设计、构建、测试、部署、维护）分组，共同覆盖完整生命周期。

每个打法涵盖：

• 什么发生了变化；
• 如何开始；
• 具体的实施步骤；
• 治理考量；以及
• 如何衡量它是否奏效。

这些步骤是模块化的，组织可以根据自身独特需求选择在不同时间优先改造不同阶段。每个打法都在“前提条件”中写明其依赖项，依赖关系图对此作了进一步说明。

一个阶段以提交产物结束，提交将启动下一个阶段。被接受的 intent.md 触发需求和设计环节，被批准的 spec.md 触发规划模式，合并的 PR 触发流水线，生产环境被突破的控制带写出下一个 intent.md，循环就这样继续。

最初，你手工为每个步骤编写提示词，最终状态是一个循环：每个被接受的产物触发下一道关卡。人类的注意力集中在关卡上，评审代理标记的内容，而不是从头开始每个阶段。

阶段 1：规划（Plan）Stage 1 — Plan

以 intent.md 捕获意图

启动软件开发流程的 intent.md 可以通过不同途径进入。一个人有一个想法，一个工单被提交，或者通过警报发现一个事故（见阶段 6：维护）。

当一个人有想法时，他们与 Claude 进行头脑风暴，产出一个 markdown 原型规格。在传统 SDLC 中，同一个人必须说服产品团队的成员与之一起撰写或代其撰写想法。

Claude 生成的原型规格是人类可读、版本受控的，并且下一阶段可以立即使用。原型规格保存为 intent.md。

无论意图来自事件触发还是代理，都适用相同的步骤：产品负责人在提交 intent.md 之前评审并修正代理撰写的 intent.md。

设置这一机制是平台或工程团队的一次性任务。需要一名技术人员建立 intent 主仓库，并决定谁可以写入它，因为许多贡献者将来自整个组织的不同部门。

仓库建立后，没有 git 经验的贡献者不需要直接使用 git。相反，一个到版本控制系统（如 GitHub）的连接器可以让 Claude 从 claude.ai 或 Cowork 代表他们提交 markdown 文件。

如何执行

• 发起人用自己的话向 Claude 描述问题。发起人可以描述他们今天无法做到什么、谁受这个想法影响、更好的样子是什么样，或者哪些内容不在范围内。不要求正式语言。
• 头脑风暴，直到想法具体化。Claude 会提出分析师会问的问题：范围、用户、约束，以及成功是什么样子。
• 请 Claude 使用组织的模板将结果写成 intent.md，该模板可以编码为由技术人员建立、负责人签字认可的一套技能。它可以涵盖问题、预期成果、受影响的用户和系统、约束以及未决问题。
• 发起人纠正 Claude 误解的任何内容。
• 将 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 历史中。产品负责人批准，将意图送入阶段 2：设计的接受或拒绝决定，记录为合并或关闭评审。

阶段 2：设计（Design）Stage 2 — Design

需求与设计

一旦产品负责人批准，Claude 会获取被接受的 intent.md，产出一份需求和设计规格。这由组织在品牌、安全、合规和 UX 方面的技能指导。

产品负责人评审该规格，但不撰写它。此流程的目标是产出一份工程团队可以据此规划的规格，并标出需要关注的领域。

前端工作是最清晰的例子。一旦 intent.md 被接受，产品负责人根据 intent.md 在 Claude Design（测试版）中做出设计稿，迭代 mock，然后导出到 Claude Code 进行构建。

如何执行

• 产品负责人打开一个带有组织技能的会话，并附上 intent.md。
• 产品负责人的提示词指向 intent.md，点名约束，并要求标出关注点。起初手工运行，然后将其固化为组织级的斜杠命令。之后，让 intent home 中 intent.md 的接受成为触发条件，用一个在合并时触发的非交互式任务，在加载组织技能的情况下运行该环节，并将 spec.md 作为拉取请求（PR）提交（阶段 5：部署中的 CI/CD 打法涵盖管道细节）。从那时起，产品负责人的第一次介入就是评审。
• 同一位产品负责人对照想法评审规格。该规格是否解决了所述问题？intent.md 中的未决问题是否得到回答或被延续？
• 首先处理标记出的关注点，因为它们是分析师会升级的点。产品负责人在工程团队看到规格之前，与每个策略负责人解决每个关注点。
• 将 spec.md 与 intent.md 一起提交。这对文件记录了要求了什么、决定了什么。
• 产品负责人决定规格和意图是否进入构建阶段，对于组织归类为较高风险的任何内容，咨询技术负责人。这个决定始终由人类队友做出，而接受规格正是启动阶段 3：构建中规划模式打法的动作。

实际效果（提示词）

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

治理考量

策略不再是数周后才在评审中被发现，而是在规格撰写的同时被读取和应用。组织的技能作为约束应用于规格。规格、产生规格的提示词以及生效中的技能版本都记录在版本控制中。产品负责人签署规格，并将标记出的关注点转给指定的策略负责人。

阶段 3：构建（Build）Stage 3 — Build

以 Claude Code 规划模式作为默认起点

工程师以规划模式启动 Claude Code 会话，将阶段 2：设计中批准的 spec.md 交给 Claude，让它对工程师进行访谈，迭代计划，直到工程师满意为止。

如何执行

• 工程师以规划模式与 Claude 开始会话。
• 工程师把 intent.md 和 spec.md 交给 Claude，要求它产出一份实施计划，列出会改变的文件、工作的顺序以及证明其有效的测试。
• 通过提问来拷问计划：这个改动可能破坏什么？哪一步风险最高？Claude 选择不做的其他选项是什么？
• 迭代，直到一个从未见过这段对话的工程师也能仅凭计划实施该改动。
• 将批准的计划提交为 plan.md。计划加入审计轨迹，PR 评审打法（阶段 5：部署）将最终的 diff 与它对照检查。
• 接受计划，让 Claude 实施。有了扎实的计划，实施通常一次就完成。
• 当实施偏离计划时，在同一提交中更新 plan.md。考虑使用钩子来强制两者同步。

实际效果（plan.md）

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 无法编辑文件。计划及其修订版本与接受者一起记录。常规变更由工程师批准，组织归类为较高风险的任何内容则交由技术负责人或架构师。

Claude Code 自动模式

Claude Code 也可以在自动模式下运行，工程师批准计划，在满意并迭代之后，Claude 应用每项改动而无需每次编辑都提示。随着后续打法的护栏成熟（调优的 CLAUDE.md、编码策略的技能、阻止不安全操作的钩子，以及 Claude 可以运行的测试套件），自动接受成为常规工作的默认：紧凑的 spec.md、较小的爆炸半径，以及测试已经覆盖的代码。

这种转变现在是离开“用户盯着代理做编辑并评审动作”，转向在更长的自主会话之后评审产物。与 worktrees 一起使用时，自动接受模式还进一步支持个人和团队的并行，并且是自主运行 SDLC 并在阶段 6：维护中所描述的那样闭环的基础。

遗留系统与事实来源

CLAUDE.md

CLAUDE.md 给 Claude 提供一个新加入者需要的情境，涵盖约定、命令、架构，以及团队最常犯的错误。过去存在于人脑中、wiki 上的知识，变成了代理在每次会话开始时都会读取的文件，由整个团队维护，并在每次犯错时迭代。

如何执行

• 在仓库中运行 /init。Claude 根据它所发现的内容生成一个起点 CLAUDE.md。
• 把生成的文件删减到新加入者第一天需要的内容。保留构建、测试和 lint 命令、重要的约定，以及 Claude 不断搞错的事情。
• 将 CLAUDE.md 提交到仓库根目录的 git 中，使整个团队共享一个版本，变更像代码一样被评审。
• 一个有效的规则在这里有帮助：当 Claude 犯同样的错误两次时，纠正内容进入 CLAUDE.md。
• 保持在一页以内，因为 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/.

治理考量

CLAUDE.md 是版本受控的，因此代理所遵循的指令是可评审、可审计的。团队约定通过该文件应用，对它的更改记录在 git 历史中，代码所有者通过 PR 评审批准这些更改。

技能作为组织知识

技能是组织让其组织知识变得可操作的方式。指令是明确的、版本受控的、广泛应用的，并在策略变化时集中更新。经验法则：为必须一致应用的组织知识编写技能；不要为属于 CLAUDE.md 或提示词的组件编写技能。

如何执行

• 选择一条今天执行不一致的知识。可以是安全标准、API 设计约定或品牌规则。
• 把它写成技能：一个包含 SKILL.md 的文件夹，其 frontmatter 说明何时触发，正文说明做什么。由工程师根据策略负责人的事实来源撰写，借助 Claude 的帮助。
• 把技能放在仓库的 .claude/skills/<name>/ 下，让它随代码一起交付，或通过插件在组织内分发。
• 测试技能是否触发。用不同方式请 Claude 执行相关任务，确认技能每次都加载。
• 当策略变化时，修改技能，并让策略负责人签字认可变更。
• 工程师在下次会话中自动获取新版本。

实际效果（.claude/skills/secure-api-review/SKILL.md）

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.

治理考量

技能是一种控制，尽管是咨询性的。它让 Claude 在编写代码时更可能应用策略，但不强制任何会话遵守。必须始终成立的策略需要在技能背后有一些确定性的东西，例如阻止该动作的钩子，或在 PR 时重新检查策略的评审环节。技能让违规变得罕见，钩子让违规几乎不可能。技能调用记录在会话轨迹中，策略负责人像评审代码一样评审技能变更。

钩子作为构建期护栏

技能是咨询性控制，钩子则是其背后的确定性层。Claude 的大多数动作在实施期间是文件编辑和 shell 命令，因此构建阶段是钩子最可能频繁触发的地方。

构建期钩子可以：

• 阻止编辑受保护路径，如生成的类或冻结的包；
• 在文件编辑后运行格式化器和 linter，使漂移永不累积；
• 让凭据不进 diff。

为任何必须毫无例外成立的策略的钩子做备份。钩子在每个匹配它的动作上运行，因此构建期钩子应该快速，并且限定在已变更的文件上。更重的检查（如完整的测试套件）属于提交或 PR 环节。

要求人类批准的钩子属于阶段 5：部署中的关卡，因为构建期间的一次批准提示会让一个人重新回到所有并行运行会话的关键路径上。

并行会话与子代理

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

并行会话是另一个完整的 Claude Code 实例，在自己的 git worktree 中处理独立任务。每个独立会话对其他会话一无所知，引导它们的工程师是它们唯一的共享点。

子代理在单个会话内作为有作用域限制的助手运行，拥有自己的上下文窗口和工具限制，适合在多个任务中重复出现的工作，例如验证应用是否按预期运行。

并行会话提高了工程师可以同时在途的任务数量，而子代理让每个会话专注于自己的任务。工程师的工作是引导并评审所有这些。

如何执行

• 工程师把工作拆分成触及不同文件的任务，使用规划模式打法（阶段 3：构建）中的计划来看工作在哪里是独立的。共享文件的任务在单个会话中一个接一个地运行。
• 每个并行任务获得自己的 worktree，例如在一个终端中运行 claude --worktree feature-auth，在另一个终端中运行 claude --worktree fix-rate-limit。worktree 是在自己分支上的独立检出，防止会话在文件上冲突。
• 两到三个会话是合理的起点。实际上限是一个人能妥善评审多少条流，所以只有在评审跟得上时才增加会话。
• 把重复的工作变成子代理，定义在 .claude/agents/ 中的 markdown 文件里，每个都有名称、何时使用的描述以及它可以触及的工具。例子包括：代码简化器，在主代理完成后剥离多余的复杂性；验证器，运行应用并检查行为；研究员，探索代码库并回报而不淹没主上下文。把定义提交到 git，让整个团队共享。

实际效果（.claude/agents/verifier.md）

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.

治理考量

更多的会话意味着更多的产出，因此控制必须来自仓库中的配置。那里的钩子和权限设置适用于所有会话，会话做了什么会被记录并归属于运行它的工程师。

阶段 4：测试（Test）Stage 4 — Test

给 Claude 一个反馈回路

始终给 Claude 一种验证自己工作的方式，无论是测试、构建还是截图对比。会话在工程师看到之前检查自己的工作并修复自己的错误。

反馈回路不应与验证器子代理（阶段 3：构建）混淆。反馈回路在整项任务中反复运行，与工作的次数一样多。验证器子代理则是另一种方式：一旦会话认为工作已完成，就通过运行一个全新的上下文窗口来打包最终检查。这样结论就不会被产生代码的假设所染色。

如何执行

• 如果今天检查工作需要一系列命令和一些环境知识，把它包装成单一目标，如 “make test” 或 “npm test”，失败时以非零退出。
• 在 CLAUDE.md 的 Commands 部分，列出每个命令及健康输出的示例。
• 陈述一个目标并使其可量化，让 Claude 无需询问即可检查工作，例如：“test_status.py 中的所有测试通过”、“截图与附带的 mock 一致”、或“端点返回 200 并带有新字段”。
• 对于 bug 修复，先编写失败的测试。请 Claude 将 bug 复现为测试，运行它，并确认它因你期望的原因失败。提交该测试。然后才请 Claude 在不编辑测试的情况下让它通过，由最后一步中的测试文件钩子强制执行该限制。修复之前就存在、代理无法重写的测试，就是 bug 已消除的证明。
• 对于 UI 工作，用视觉检查闭合回路。给 Claude 一个浏览器或截图工具，给它 mock，让它迭代。实现、截图、比较、调整。两到三轮是正常的，结果应该每轮都改善。
• 让验证成为“完成”的一部分。指令写在 CLAUDE.md 中。在报告任务完成之前运行测试，并展示输出。
• 最后，回路本身需要保护，因为修复代码的代理绝不能削弱对该代码的检查。在修复任务期间阻止编辑测试文件的钩子可以做到这一点。替代方案是在评审中检查 diff，拒绝任何触及测试的变更。

实际效果（CLAUDE.md 验证块）

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.

CI 中的持续评估

评估（evals）是阶段关卡式 QA 的 AI 原生等价物。实际上，这意味着一个在代理配置发生变化时运行的套件。当换入新模型或重写提示词时，评估套件会说明代理是否仍以同样的标准完成工作。

评估应被视为一个活套件。随着模型改进，曾经有区分度的用例不再有区分度，必须添加来自持续监控产生的新用例。

根据用例不同，一些团队可能更喜欢按固定节奏离线运行这些评估，而不是每次变更都运行。以下步骤针对持续评估。

如何执行

• 平台工程师从近期工作中收集 20 到 50 个真实任务及其预期/被接受的成果。
• 把每个任务写成评估，即提示词加上定义“可接受”的检查（测试通过、lint 干净、行为不变、策略被遵循）。
• 套件在 CI 中按计划非交互式运行，并在 CLAUDE.md、技能或钩子发生任何变更时运行，因为该配置引导着代理，值得得到代码所得到的回归测试。
• 用结果作为配置变更的关卡。降低通过率的技能变更在合并前会被评审。
• 每个生产事故都会得到一个评估，由拥有该事故的团队编写，并作为回归测试留在套件中。

实际效果（.github/workflows/agent-evals.yml）

agent-evals.ymlname: 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 一个跟得上代理产出的关卡。通过率阈值作为合并检查强制执行，运行被记录以便结果可以跨时间比较，拥有配置变更的团队批准它。

阶段 5：部署（Deploy）Stage 5 — Deploy

PR 评审回路中的 AI

Claude 既给予评审也接受评审。它根据组织策略评审进来的 PR，并处理自己 PR 上的评审意见。这让工程师在 PR 评审中专注于行为，归结为判断意图和风险。

如何执行

• 托管式 Code Review 服务是最快的起点。管理员启用它并选择仓库。当你需要控制流水线，或想让 API 调用通过自己的云协议路由时，在自有 CI 中用 claude-code-action 运行评审（CI/CD 打法涵盖该管道）。
• 技术负责人把评审策略写成仓库根目录的 REVIEW.md，分为组织关心的几个环节：bug 与逻辑错误；安全与漏洞；对照规格（来自需求打法的 spec.md）、实施计划（来自规划模式打法的 plan.md）和设计原则的合规性。REVIEW.md 还定义了什么算“重要”（Important）而不是“小问题”（Nit），以及要跳过什么。
• 技术负责人设定人工阈值。发现结果本身不会批准或阻止 PR，分支保护仍然要求代码所有者批准。想用发现结果作为合并关卡门槛的平台工程师，可以读取检查运行发布的严重性计数（机器可读的统计）。
• 当评审者或作者在评审意见上 @claude 时，Claude 处理该意见并推送修复。PR 线程记录请求和变更。这个修复回路通过 claude-code-action 运行。在托管服务中，评论 @claude 会请求一次全新的评审。对于 Claude 打开的 PR，更进一步，让 Claude 照看 PR 直到合并。团队把回路包装成自定义斜杠命令，清扫 PR 上未解决的评审意见和失败的检查，处理它们并推送修复，直到 PR 变绿，只等代码所有者批准。
• 评审发现回馈到 CLAUDE.md。当评审第二次标记一个错误时，纠正内容作为该评审的一部分进入 CLAUDE.md，由于评审会读取 CLAUDE.md，这个错误从下一个 PR 起就被捕获。评审还会标记某个变更何时让 CLAUDE.md 过时。
• 每月一次，技术负责人通过给发现结果评级来调优设置，让评审者改进，并在 REVIEW.md 中限制 Nit 的数量。生成的路径和 CI 已经强制的内容被排除。

实际效果（REVIEW.md）

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 的安全”。

钩子作为审批门禁

构建阶段用钩子作为护栏，允许或阻止动作而无需人类介入（阶段 3：构建）。钩子也可以询问，暂停动作直到特定的人批准，这正是发布关卡所需要的。

这个打法放在阶段 5：部署，因为发布关卡是最清晰的用例，但钩子并非部署专属：它们在 Claude 行动的任何地方运行。例如，钩子可以在阶段 3：构建期间阻止在没有变更工单的情况下编辑迁移和基础设施，并在阶段 4：测试的修复任务期间阻止代理编辑测试文件。

如何执行

• 工程领导层与变更管理和合规部门一起，列出必须保留的人工审批关卡，如变更管理签字、发布授权，以及编辑受保护路径。
• 平台工程师把每个关卡表达为一个钩子：一个在 Claude 行动之前运行的脚本，可以允许、询问或阻止。
• 团队钩子放在 git 中的 .claude/settings.json 里，不可协商的钩子放在平台或 IT 管理员拥有的托管设置中，个人工程师无法关闭它们。
• 阻止应该解释自己，所以当钩子阻止一个动作时，原因和审批途径会出现在 Claude 的输出中。

实际效果（.claude/settings.json）

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

以及关卡本身（.claude/hooks/production-gate.sh）

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

治理考量

钩子就是审批门禁。关卡条件每次都强制执行，对每个人都如此。允许和阻止的决定带时间戳记录。关卡还定义了什么算批准，无论是已批准的变更工单还是发布经理的签字。

受监管企业的托管设置

CI/CD 集成与部署

在 CI/CD 流水线中非交互式运行 Claude Code，沙箱化执行，让长时间运行的代理安全运行，通过 MCP 集成暴露部署能力，并在代理需要之前排练回滚路径。

如何执行

• 平台工程师从只读的判断步骤开始。在流水线任务中使用 claude -p 来分流失败的构建、总结不稳定（flaky）的测试，或起草变更日志。
• 在现有关卡之后添加写步骤，用于诸如修复 lint、更新生成的文档，或通过 @claude 提及处理评审意见等任务。代理写的任何东西都以 PR 形式通过分支保护到达，代理没有推送到 main 的途径。
• 执行被沙箱化。代理任务在容器中运行，受网络策略约束，使用短期的、限定作用域的令牌，默认不持有生产凭据。
• 通过 MCP 暴露部署。部署、状态和回滚成为按环境限定作用域的工具，因此代理的部署能力是一个白名单，而不是一个带凭据的 shell 脚本。
• 按环境划分自主层级。在开发环境中，代理自由部署。在生产环境中，代理准备发布，发布经理授权它，钩子强制执行生产关卡。预发布（staging）环境介于两者之间。
• 回滚应该是流水线中排练最多的路径，一条代理可以运行、并定期在预发布环境演练的命令。闭环打法（阶段 6：维护）在控制带被突破时调用这个回滚，所以它必须提前得到验证。

实际效果（流水线步骤）

pipeline step- 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 的直接路径。
• 生产部署钩子阻止发布，直到指定的发布经理授权。每次非交互式运行都以代理自己的身份行动，因此流水线日志区分了代理做了什么和触发它的工程师做了什么。
• 按环境的权限层级设定代理在通往关卡的路径上可以做多少。

阶段 6：维护（Maintain）Stage 6 — Maintain

维护与闭环

到目前为止，我们讨论了如何在 SDLC 的每个阶段加入 Claude，每个阶段都需要人类启动最初的步骤。而这一阶段将焦点转向自主运行 Claude 以闭合循环。

例如，一个持续运行的监控代理可以在 bug 工单被提出的背景下创建 intent.md，并流经需求、规划、构建、测试和评审阶段。阶段 6：维护无人值守运行，在阶段之间有独立的置信关卡——一个确定性检查或对抗性评审代理——决定前一阶段的产出是继续还是升级给人类。

闭环

一个确定性脚本监控生产环境，在控制带被突破时调用 Claude。对突破的监控是循环自主运行模式的一个有用例子，而本阶段末尾的 Claude Tag（公开测试版）部分涵盖通过不同渠道到达的工作。

如何执行

• 服务所有者或平台工程师选择一个具有稳定滚动基线的指标，如 CI 测试失败率、部署后 5xx 率或 PR 周期时间。
• 他们编写检测脚本，通常是滚动窗口上的均值和标准差，并配以规则（Western Electric 或类似），使控制带既能捕获缓慢漂移，也能捕获尖峰。脚本是版本受控并有单元测试的，检测保持完全确定性，不涉及模型。
• 响应层级定义在版本受控的配置中（下面的 bands.yaml）。在 1σ 时脚本只记录日志，在 2σ 时它以只读方式调用 Claude 进行诊断，在 3σ 时 Claude 可以行动，但只能通过打开 PR 进入评审关卡或触发预先批准的 runbook。
• 触发层可以是 GitHub 或 GitLab 中的定时工作流、现有监控栈的 webhook，或网络内的 Cron Job。Claude 无状态运行，既可以作为 CI runner 上的非交互式步骤，也可以作为沙箱容器中的 Agent SDK 服务，CI/CD 打法涵盖部署和模型访问选项。由于运行是无状态且非交互的，循环可以在没有人启动的情况下开始和结束。
• 代理按照阶段 1：规划格式把诊断写成 intent.md，涵盖异常及其证据、预期成果、受影响的系统和任何未决问题。从那里，发现与其他内容一样流经流水线。
• 服务所有者或值班工程师分流队列，把面向产品的发现转给产品负责人。修复、排期或忽略。忽略会调优控制带并帮助减少噪音。
• 当修复上线时，为事故添加一个评估（持续评估打法），确保此类问题在未来得到保护。

实际效果（例如，监控 CI 测试失败率的 bands.yaml）

bands.yamlmetric: 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 事先已获批准。

示例

• 当 CI 测试失败率突破 3σ 时，代理隔离 flaky 测试或打开回滚 PR，评审关卡做决定。
• 当部署后 5xx 率在窗口内有部署的情况下突破 3σ 时，代理触发现有的回滚流水线。
• 当 PR 周期时间触发漂移规则时，代理为工程领导层撰写报告，表明这套装置对流程指标和生产指标同样有效。

定期代码库扫描

安全扫描是关于特定模型下代码库的时点陈述，而两半都会过时：代码每周都在变化，每一代模型都会发现上一代遗漏的漏洞。AI 原生的答案是按计划运行扫描，调用路径中不出现人类，并把发现的内容像代码库的任何其他变更一样送入相同的关卡。

Claude Security 是定时扫描的托管形式。连接 GitHub 仓库，扫描在 Anthropic 基础设施上的 Claude Mythos 5 上运行，每个发现都在报告前经过验证并附有置信度评级。建议的补丁在 Web 版 Claude Code 中评审和应用。组织无需访问模型本身即可获得发现。

如何执行

• 安全负责人连接仓库，并按仓库、服务或团队把它们组织成项目，让发现的所有权从一开始就清晰。
• 对最关键仓库运行第一次完整扫描，包括那些曾被其他工具或早期模型扫描过的。把第一次扫描当作基线。第一次扫描很可能会在被认为干净的代码中发现内容。
• 为每个项目设定计划。对于积极开发的服务，每周是合理的默认值；在仓库庞大或混合的情况下，将扫描限定到目录或分支。
• 带着置信度评级分拣发现。带理由忽略，这样忽略会被记录，同一发现不会在下次运行时作为新发现再次出现。
• 对于有边界的发现，在 Web 版 Claude Code 中打开建议的补丁，评审它，并像任何其他变更一样送它通过 PR 评审关卡。提出修复建议的代理没有批准它的途径。
• 对于比单个补丁更广的任何内容，如架构弱点或跨服务重复的模式，按阶段 1 格式写成 intent.md，并从规划阶段开始。
• 当修复发布到生产时，为漏洞类别向持续评估打法的套件添加一个评估，这样引导代理的配置从那时起就针对该类别进行测试。
• 将发现导出为 CSV 或 Markdown，或使用 webhook，让组织现有的跟踪器和审计系统保持为记录系统，即审计人员期望它们所在的地方。

治理考量

扫描在组织的管理控制下运行，意味着连接哪些仓库、谁拥有扫描席位、支出上限都由中央设定。每个发现都有验证结果和置信度评级，每次忽略都有理由，因此扫描历史是对发现、修复和有意接受内容的审计记录。

修复通过 PR 评审关卡和分支保护到达生产，而不是直接从扫描本身。Claude Security 增强了现有的静态分析和依赖扫描。确定性检查留在 CI 中，模型驱动的扫描覆盖这些检查并非为发现而构建的、依赖上下文的漏洞。

Claude Tag 值班

事故也可以通过其他方式到达，如 Slack 或 Teams 等工作场所通信应用。事故可以表现为事故频道上晚上 10 点的一条紧急修复 Slack 消息，现在可以立即处理。Claude Tag（目前 Slack 中公开测试版）让 Claude 以自己的身份成为这些频道的成员，因此每个新事故都有第一个响应者，响应本身成为未来事故的循环和记忆的一部分。

对话和组织知识留在频道中，频道中的任何人都能引导并执行响应。任何团队成员都可以实时测试假设、探索新选项和调查，频道历史增加了可审计性。通过 MCP 访问，Claude 验证指标已回到基线并在线程中确认，把事后复盘（post-mortem）写入版本受控的经验教训文件，供未来的调查阅读。

事故不是 Claude Tag 接手的唯一工作。在工单上通过 MCP 标记它，或在频道中询问，Claude 以同样的方式分流工作。一个小的、边界清晰的修复以 PR 形式通过评审关卡到达，任何更大的内容都写成阶段 1：规划的 intent.md，此时循环开始自我供给。参见：Claude Tag 如何在 Anthropic 为 CI/CD 值班。

结语Closing thoughts

模型和装置已经变得更加先进，让组织不仅可以转变生产代码的方式，还可以转变整个软件开发生命周期。

这种转变让人类判断保持在流程的核心，并考虑大型企业组织的治理和监管要求。

本指南汇集了我们的应用 AI 团队每天为客户执行的大量真实最佳实践，希望你能发现它是一份实用、可操作的资源。

参考资料与致谢

下面的文档是平台团队建立这些控制所需的内容，大致按你推出的顺序排列。

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献，本指南受他们此前大量工作的启发并建立在其基础上。