AI 原生 SDLC 实战手册：Anthropic 如何用 Claude 重塑软件开发生命周期

如何用 AI 逐步改造你的软件开发生命周期——一个阶段一个阶段地。

代码不再是瓶颈

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

许多工程团队仍然沿用同样的审批关卡、评审、交接和策略，拖累了使用 Claude Code 这类智能体编码方案所带来的生产力提升。

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

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

传统的 SDLC 还带有一些控制机制，它们假定每一步都由人类完成。那些创造出最大价值的组织，已经围绕智能体 AI 如今所能做到的事情重建了自己的流程，同时确保人类始终留在环路之中。在本指南中，我们梳理了应用 AI 团队在 SDLC 各个阶段于内部集成 Claude 以加速开发、让流程运转更快的若干最佳实践，这些实践源自我们与客户的合作经验。

当代码不再是瓶颈，且构建阶段的运行速度超出传统 SDLC 所能容许的范围时，有三件事随之成立：

瓶颈转移到了构建阶段左右两侧的步骤。这主要是规划、审查/测试和部署，它们仍以人类的速度运行。
这些控制机制不再与现实匹配，变得难以驾驭。当代码是由人编写时，逐行审查是合理的，但一旦大部分 diff 由智能体编写，这种方式就再也跟不上了。
治理成本上升，因为例外情况仍然要经过每周或每月开会的会议和委员会来流转。

构建不再是瓶颈——围绕它的那些以人类速度进行的步骤才是。以人类速度进行的阶段保持其原有长度，而构建则压缩到数小时。

让我们以一个安全瓶颈为例。安全团队的规模是按人类产出设定的，因此当智能体使代码产出成倍增加时，要么审查队列积压，要么代码在审查不足的情况下发布。受监管的组织无法接受这两种结果中的任何一种，因此其安全和政策检查必须跟上智能体的步伐。

为了更好地实现智能体 AI 带来的生产力提升并保障其安全，传统的 SDLC 生命周期需要经历与实施阶段同等程度的变革。

什么是 AI 原生的 SDLC？

AI 原生的 SDLC 是一种重新构想的流程，它将旧有的控制目标与新的执行方式相结合。该流程不再是线性流转，而是变成一个循环，AI 嵌入其中每一个环节。AI 原生的 SDLC 促进了自动化的交接以及后续 play 的触发，有助于解决传统 SDLC 各阶段之间交接的手动化和笨拙问题。

你还会听到这种转变被称为 agentic SDLC、AI SDLC，或者干脆叫 agentic 软件开发——标签各不相同，但描述的是同一件事。

AI 原生 SDLC 六个阶段的转变

下表突出了传统 SDLC 与 AI 原生 SDLC（由 Claude 支持）之间光谱的两端。大多数组织处于这两列之间的某个位置。

阶段	传统 SDLC	AI 原生 SDLC
规划	需求由委员会收集，通过研讨会和签核提炼，再手工撰写成文	Claude 直接从来源中综合出痛点，并将其捕获到 `intent.md` 中，该内容人类可读且机器可执行
设计	由分析师撰写、由设计师解析的规格说明	需求与设计压缩进与智能体的一次工作会话中，由编码为技能的标准引导，并在 git 中进行版本管理
构建	测试与代码为手写，文档在主要开发完成之后才撰写	测试与代码由 AI 生成，组织知识以版本化的机器可读 `CLAUDE.md` 文件和技能的形式维护
测试	在阶段边界设置 QA 关卡	持续评估贯穿实现过程
部署	人工审查每一行代码，治理发生在审查周期中，且往往不一致	多层智能体审查，人工审查仅保留给受监管和关键代码。治理在 AI 行动时即被强制执行，以钩子作为审批关卡
维护	人工监控生产环境以发现 bug	智能体监控线上部署。任何被突破的控制区间都会被诊断，并作为新的 `intent.md` 写回循环中。

贯穿右栏的主线是已提交的产物。每个阶段结束时都会向版本控制写入一份产物（包括 intent.md、spec.md、plan.md、diff 及其测试、带有评审发现的 PR，以及事故记录），而下一个阶段则从读取它开始。在早期阶段，.md 文件是主要产物，因为产品负责人和智能体都能读取并基于同一份文件采取行动。从 Build 阶段开始，产物是代码及其记录。提交链同时也是审计轨迹：谁提出了什么需求、智能体产出了什么，以及谁批准了它。

人类仍然对每一个需要判断的决策负责。在智能体式 SDLC 的世界里，人类的注意力会随着必须被评审的产物而转移。

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

玩法

这些玩法是 playbook 的核心，被分为六个非线性阶段（Plan、Design、Build、Test、Deploy、Maintain），它们共同覆盖了完整生命周期。

每个玩法涵盖：

有哪些变化；
如何开始；
具体的实施步骤；
治理方面的考量；以及
你如何衡量它是否奏效。

这些步骤是模块化的，组织可以根据自身独特需求，选择在不同时间优先改造不同的阶段。每个 play 都在"Prerequisites"（前提条件）下列出了它的依赖项，依赖关系图对此做了进一步说明。

一个阶段以提交一个产物（artifact）作为结束，而这次提交会启动下一个阶段。一个被接受的 intent.md 会触发需求与设计环节，一个获批的 spec.md 会触发 plan 模式，一个被合并的 PR 会触发流水线，而生产环境中被突破的控制带会写入下一个 intent.md，如此循环往复。

首先，你手动为每一步提供提示词，而最终状态是一个循环：其中每个被接受的产物都会触发下一道关卡。人的注意力集中在关卡处，审查智能体标记出来的内容，而不是从零开始每个阶段。

这些 play 按阶段列出；箭头给出了采用它们的顺序。这两者并不相同。从任何一个 clay play 开始——没有任何箭头指向它，所以它不需要任何前置。对于任何其他 play，指向它的箭头就是需要在它之前采用的 play。

计划

想法不再需要等待有人把它写成文档。意图在源头就以提出者自己的语言被一次性捕获，成为受版本控制的产物，下一阶段可以直接据此行动。

捕获为 intent.md

启动软件开发流程的 intent.md，可以通过不同路径进入。某个人有了一个想法，提交了一张工单，或者通过告警浮现出一起事件（参见第 6 阶段：维护）。

当某个人有了一个想法，他们会与 Claude 一起头脑风暴，并产出一份 markdown 形式的原型规格。在传统的 SDLC 中，同一个人随后必须说服产品团队的一名成员，与他们一起或代替他们把这个想法写成文档。

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

无论意图是源自事件触发还是源自某个智能体，都适用同样的步骤：产品负责人在提交之前，审查并修正由智能体编写的 intent.md。

传统做法：一个想法要经过待办事项条目、用户故事、故事点和细化会议，之后才有人能对其采取行动。每一次交接都会发生归属权的转移，因此到达工程团队手中的内容，已经与提出者的本意相隔了好几步。

AI 原生发起人与 Claude 一起头脑风暴，并将结果写下来，形成 intent.md，即一份用发起人自己的语言表达的原始规格说明。该产物包含想要什么、为什么想要，以及在哪些约束条件下。重复性的流程通过技能来编码。

入门

前提条件

无。

基础设施

为非工程师人员提供 Claude 访问权限（claude.ai 或 Cowork）；一个商定好的 intent.md 模板；一个由产品负责人关注的、共享且受版本控制的意图存放处。对于单个产品而言，最简单的存放处就是产品仓库中的一个 intent/ 文件夹。这种设置让产物链紧邻由其衍生出的代码。只有当意图横跨多个仓库时，专门的意图仓库才值得付出额外开销，而在 monorepo 中它就是一个目录。第 3 阶段：构建侧边栏介绍了这个存放处与已经保存记录的 Jira 或需求工具之间的关系。

搭建这项工作对平台或工程团队来说是一次性任务。需要一名技术团队成员来建立意图存放处，并决定谁可以写入其中，因为许多贡献者将来自整个组织。

一旦仓库建立，没有 git 经验的贡献者就不需要直接使用 git。取而代之的是，一个连接到版本控制系统（例如 GitHub）的连接器，让 Claude 能够代表他们从 claude.ai 或 Cowork 提交 markdown 文件。

如何执行

发起人用自己的话向 Claude 描述问题。发起人可以描述他们目前无法做到的事情、谁会受到这个想法的影响、更好的状态是什么样，或者哪些内容不在范围内。不需要使用正式语言。
持续头脑风暴，直到想法变得具体。Claude 会提出分析师会问的问题：范围、用户、约束条件，以及成功是什么样。
让 Claude 使用组织的模板将结果写成 intent.md，该模板可以编码为由一名技术团队成员设置、并由负责人签核的技能。这可以涵盖问题、拟议成果、受影响的用户和系统、约束条件以及待解决的问题。
发起人纠正 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，其中列出了作者、时间戳和完整的修订历史。它记录在 intent home 的 git 历史中。产品负责人批准，而将 intent 送入 Stage 2：Design 的接受或拒绝决定，则被记录为合并或关闭评审。

如何衡量它

领先指标

从首次对话到提交 intent.md 的时间，从 intent home 上的 git 历史读取，其中记录了作者和时间戳。预期是从长达数周的引导与细化周期缩短到数小时。

滞后指标

存活率，即intent.md产品负责人接受进入第 2 阶段：设计而非关闭的文件所占比例。接受或拒绝的决定记录为产物的合并或已关闭的评审。此外，对intent.md在同一变更的首次spec.md提交之后所做的更改次数。

设计

需求与设计坍缩为同一次会话。策略在规格撰写时即被应用，而不是在数周后的评审中才被发现。

需求与设计

一旦获得产品负责人批准，Claude 就会接收被采纳的 intent.md，并生成需求与设计规格说明。这一过程由组织在品牌、安全、合规和 UX 方面的技能提供指导。

产品负责人会审阅这份规格说明，但并不亲自撰写。这一流程的目标是产出一份工程团队可以据此规划的规格说明，并标注出需要关注的领域。

前端工作是最清晰的例子。一旦 intent.md 被采纳，产品负责人就会在 Claude Design（beta）中根据 intent.md 制作设计稿，对设计稿进行迭代，然后将其导出到 Claude Code 进行构建。

传统上，需求与设计是由不同团队分别运行的独立阶段。分析师将想法形式化为需求，设计师再将其解析回设计。这种分离是为了明确责任归属，但速度慢且存在信息损耗。

AI 原生两个阶段都在单次提示会话中完成。Claude 接收 intent.md，并生成一份需求与设计规格，受组织的技能约束，同时标记出关注领域。

快速上手

前置条件

编写一个 intent.md 文件，将品牌、安全、合规和 UX 政策写成技能。

基础设施

一位拥有 Claude 访问权限的产品负责人。无需任何工程技能。

如何执行

产品负责人开启一个会话，加载组织的技能，并附上 intent.md。
产品负责人的提示词指向 intent.md，列出各项约束，并要求标出关注点。先手动运行，然后将其固化为组织级别的斜杠命令。在此基础上，将意图主页中 intent.md 的验收作为触发器，用一个在合并时触发的非交互式任务，在加载组织技能的情况下运行该检查，并将 spec.md 作为拉取请求提交（第 5 阶段：部署中的 CI/CD 方案涵盖了相关管道搭建）。从那时起，产品负责人的首次参与就是评审。
同一位产品负责人对照想法评审规格说明。规格说明是否解决了所述问题，intent.md 中的未决问题是否已得到解答或延续下来？
先处理标出的关注点，因为这些是分析师会升级处理的问题点。产品负责人在工程团队看到规格说明之前，与各关注点的策略负责人逐一解决。
将 spec.md 与 intent.md 一起提交。这对文件记录了所要求的内容和所决定的内容。
产品负责人决定规格和意图是否进入构建阶段，对于组织归类为较高风险的任何事项，会咨询技术负责人。这一决定始终由人类团队成员做出，而接受规格正是启动第 3 阶段：构建中计划模式流程的起点。

它看起来是什么样（提示词）

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.

治理考量

现行政策不再是在数周后的评审中才被发现，而是在编写规格时就被读取并应用。组织的技能作为约束条件应用于规格之上。规格、生成它的提示词，以及当时生效的技能版本，全部记录在版本控制中。产品负责人签署规格，并将标记出的关切事项转交给指定的政策负责人。

如何衡量它

领先指标

同一变更从 intent.md 提交到 spec.md 提交之间经过的时间（两个 git 时间戳），并与旧的“需求加设计”周期进行对比。

滞后指标

需求在构建开始后返工。计数spec.md提交，其日期晚于同一变更的首次plan.md提交。Git log 会直接给出这一信息。

构建

没有一份被认可的方案，就不会有任何实现。机构知识变成智能体读取的文件，护栏以代码形式运行，而不是靠习惯维持。

将 Claude Code 的 plan mode 作为默认起点

工程师以 plan mode 启动 Claude Code 会话，把第 2 阶段：设计阶段产出的已批准 spec.md 交给 Claude，让它对工程师进行访谈，并不断迭代方案，直到工程师满意为止。

传统做法：工程师阅读设计文档，然后开始写代码。改动将如何进行，具体到哪些文件、哪些测试，都留在工程师的脑子里，或者最多写在工单评论里。其他人都无法审阅。评审者看到的第一样东西就是已完成的 diff，而到那时返工已经很慢了。

AI 原生做法：工作从一份书面方案开始，由 Claude 在 plan mode 中生成，在该模式下它可以读取代码库而不做任何改动。工程师在代码编写之前修正方案，获批的版本会作为 plan.md 提交，供后续阶段对照检查。

入门

前置条件

意图产物（intent.md 或 spec.md）（如果存在的话），以及 CLAUDE.md 文件会有所帮助。

基础设施

Claude Code 并让其访问代码仓库。

如何执行

工程师以计划模式与 Claude 开启会话。
工程师把 intent.md 和 spec.md 交给 Claude，并要求给出一份实现计划，其中要列出会改动的文件、工作顺序，以及用于验证的测试。
对这份计划进行质询，询问这项改动可能破坏什么、哪一步风险最高，以及 Claude 选择不做哪些其他方案。
反复迭代，直到一位从未看过这段对话的工程师仅凭这份计划就能实现该改动。
将获批的计划作为 plan.md 提交。该计划会加入审计追踪，而 PR 审查流程（第 5 阶段：部署）会将最终的 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 元数据。

滞后指标

每次变更的返工轮数，同样来自 PR 元数据，以及合并后的 diff 仍与已提交的 plan.md 相匹配的频率。

自动模式下的 Claude Code

Claude Code 也可以在自动模式下运行，此时工程师批准计划，一旦满意并经过迭代，Claude 就会应用每一项变更，而无需逐次编辑提示。随着后续策略中的护栏逐渐成熟（经过调优的 CLAUDE.md、编码策略的技能、阻止不安全操作的钩子，以及 Claude 可以运行的测试套件），自动接受便成为常规工作的默认方式：紧凑的 spec.md、较小的影响范围，以及测试已经覆盖的代码。

如今，转变的方向已不再是让用户盯着智能体进行编辑并审查其操作，而是转向在更长时间的自主会话结束后对产出物进行审查。自动接受模式在与 worktree 配合使用时，进一步实现了个人与团队层面的并行工作，并且对于自主运行 SDLC 以及如第 6 阶段：维护中所述实现闭环至关重要。

侧边栏

遗留系统与唯一可信来源

适用于流程产出的每一个产出物。

现有的 SDLC 流程很可能已经在追踪产出物了，只不过不是以 markdown 文件的形式。工作项可能在 Jira 中，需求可能在带有内置法规可追溯性的工具中，设计可能在 Figma 中，变更审批则通过变更委员会进行。这些系统很难被取代，因为审计人员和监管机构已经认可它们，其他团队也依赖它们，因此 AI 原生的 SDLC 必须围绕现有系统来适配。

在向 AI 原生 SDLC 过渡时，对于流程产出的每一个产出物，指定一个系统作为唯一可信来源，其他所有地方只保留副本或指向原始内容的链接。以下配置可以设置为只有一个唯一可信来源，具体选择因产出物而异：

以代码仓库作为唯一可信来源。 markdown 产出物是权威记录，遗留系统则引用提交中的文件。对于工程主导型组织来说，这可能是最简洁的配置之一，因为所有记录都存放在一个工具中，拥有统一的时间戳权威。

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

以关联作为最低标准。 所有产物都注明记录 ID，所有遗留记录都包含 markdown 文件的 commit SHA。在向 AI 原生 SDLC 过渡时，关联是一个很好的起点，同时接受存在两个事实来源这一现实。

遗留系统和 markdown 优先的系统可以共存，只要两者之间存在关联，或者声明其中一个是唯一事实来源。

CLAUDE.md

CLAUDE.md 为 Claude 提供了新加入者所需的上下文，涵盖约定、命令、架构以及团队最常见的错误。过去存在于人们头脑和 wiki 中的知识，如今变成了智能体在每次会话开始时都会读取的文件，由整个团队维护，并在每次犯错时不断迭代。

快速上手

前置条件

无。

基础设施

一个代码仓库、安装好的 Claude Code，以及一位熟悉该代码库的工程师。

如何执行

在仓库中运行 /init。Claude 会根据它发现的内容生成一份初始的 CLAUDE.md。
把生成的文件精简到新成员第一天真正需要的程度。保留构建、测试和 lint 命令、重要的约定，以及 Claude 反复出错的地方。
把 CLAUDE.md 提交到仓库根目录的 git 中，让整个团队共享同一个版本，改动像代码一样经过审查。
这里有一条实用的规则：当 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 捕获的错误的频率。对 CLAUDE.md 的修正或更改应在 git 历史中追踪。

滞后指标

从 PR 历史来看，团队新成员首个 PR 被合并所需的时间。

技能作为机构知识

技能是组织将机构知识付诸运作的方式。这些指令是明确的、受版本控制的、被广泛应用的，并在政策变化时集中更新。经验法则：为必须一致应用的机构知识编写技能；不要为属于 CLAUDE.md 或提示词的组件编写技能。

入门

前提条件

无需任何前提条件。拥有 CLAUDE.md 会有帮助，因为它能将智能体的工作知识保存在仓库中，但技能并不依赖于它。

基础设施

一项有明确负责人和书面权威来源的政策。

如何执行

挑选一条目前执行不一致的知识。这可以是一项安全标准、一条 API 设计约定，或一条品牌规则。
把它写成一个技能，即一个包含 SKILL.md 的文件夹，其 frontmatter 说明何时触发，正文说明该做什么。由工程师根据政策负责人的权威来源编写，并借助 Claude 协助。
把该技能放在仓库中的 .claude/skills/<name>/ 下，使其随代码一起发布，或通过 plugin 在全组织范围内分发。
测试该技能能否触发。用不同方式让 Claude 执行相关任务，确认每次都能加载该技能。
当政策发生变化时，修改该技能，并由政策负责人签署批准该变更。
工程师会在下一次会话中自动获取新版本。

它长什么样（.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.

治理考量

技能是一种控制手段，尽管是建议性的。它让 Claude 在编写代码时倾向于应用该策略，但没有任何机制强制某个会话必须遵守它。一项必须始终成立的策略，需要在技能背后有确定性的东西支撑，比如阻止该操作的 hook，或在 PR 阶段重新检查该策略的审查环节。技能让违规变得罕见，而 hook 让违规几乎不可能发生。技能调用会记录在会话追踪中，策略负责人会像审查代码一样审查技能的变更。

如何衡量

领先指标

从策略负责人批准策略变更，到更新后的技能合并所需的时间，取自技能文件夹上的 PR。

滞后指标

PR 审查中引用该策略的发现项，一旦技能在编写代码时应用了该策略，这些发现项应趋近于零。如果发现项没有趋近于零，要么是技能没有被触发，要么是其文本已经偏离了官方策略。

hook 作为构建时的护栏

技能是一种建议性控制，而 hook 是其背后的确定性层。Claude 的大部分操作在实现过程中都是文件编辑和 shell 命令，因此构建阶段正是 hook 触发最频繁的地方。

构建阶段的 hook 可以：

阻止对受保护路径的编辑，例如生成的类或冻结的包；
在文件编辑后运行格式化和 linter，使偏差永远不会累积；
让凭证不出现在 diff 中。

为任何其策略必须无例外地得到遵守的 skill 配备 hook。hook 会在每一个与之匹配的操作上运行，因此构建阶段的 hook 应当快速，并且限定在发生变更的文件范围内。更重的检查，例如完整的测试套件，应放在提交或 PR 阶段。

需要请求人工批准的 hook 应归入第 5 阶段：部署中的 gate，因为构建期间的批准提示会让人重新回到所有并行运行的会话的关键路径上。

并行会话与子智能体

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

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

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

并行会话提高了工程师可以同时推进的任务数量，而子智能体则让每个会话专注于自己的任务。工程师的工作是引导和审查所有这些会话。

传统方式：一名工程师一次只处理一个任务，并将一天或一周中相当大的一部分时间花在构建、测试和审查上。在等待期间切换到其他任务是可行的，但上下文切换足够令人疲惫，以至于很少有人选择这样做。

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

入门

前提条件

CLAUDE.md，因为所有会话都会读取该文件。反馈循环（第 4 阶段：测试）在这里也有帮助，因为当会话能够验证自己的工作成果时，所需的工程师监督就更少。

基础设施

一个 git 仓库，因为隔离来自 worktree，以及经过调整的权限设置，使会话不会因为组织认为安全的命令而等待审批提示。

如何执行

工程师把工作拆分成涉及不同文件的任务，利用规划模式玩法（第 3 阶段：构建）中的计划来判断哪些工作是相互独立的。共享文件的任务在同一个会话中依次运行。
每个并行任务都有自己的 worktree，例如在一个终端中运行 claude --worktree feature-auth，在另一个终端中运行 claude --worktree fix-rate-limit。worktree 是在独立分支上的单独检出，可以防止会话在文件上发生冲突。
两到三个会话是一个合理的起点。实际的上限取决于一个人能妥善审查多少条工作流，因此只有在审查跟得上的情况下才增加会话。
把重复性的工作变成子智能体，即在 .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.

治理方面的考量

更多会话意味着更多产出，因此管控必须来自仓库中的配置。那里的 hooks 和权限设置适用于所有会话，而会话所做的操作会被记录并归属到运行它的工程师名下。

如何衡量它

领先指标

在评审质量保持不变的前提下，每位工程师的并发会话数（从 OpenTelemetry 导出数据中统计），以及一天中用于引导而非等待的时间占比。

滞后指标

每位工程师每周合并的变更数，并结合根据 PR 历史记录确定的返工率一同考量。

测试

每个会话在人类看到其成果之前都会先检查自己的工作，而用于引导智能体的配置也会像它编写的代码一样接受回归测试。

给 Claude 一个反馈回路

始终给 Claude 一种验证自己工作的方式，无论是测试、构建还是截图差异对比。会话会先检查自己的工作并修正自己的错误，然后工程师才会看到。

反馈回路不应与验证器子智能体（阶段 3：构建）混为一谈。反馈回路贯穿整个任务，运行次数与工作量相当。而验证器子智能体则是另一种方式，它在会话认为工作完成后，通过运行一个全新的上下文窗口来打包最终检查。这样一来，判定结果就不会被产生代码时的那些假设所影响。

传统方式：代码可用的信号来得太晚。CI 要几分钟后，测试人员要几天后，生产环境要几周后。当由智能体生成代码时，迟到的信号意味着必须有人检查它的全部输出，而这个人就成了瓶颈。

AI 原生方式：在有人查看之前，先给会话一种检查自身工作的方法。运行测试、运行构建、截取屏幕截图。Claude 会不断迭代，直到检查通过，因此到达工程师手中的成果已经通过了检查。搭建这个循环的工作落在运行该会话的工程师身上，下面的步骤就是为他们写的。

入门

前置条件

无。

基础设施

一套测试套件和一个构建流程，各自只需一条命令即可在本地运行。对于 UI 相关工作，让 Claude 能看到结果至关重要，要么是浏览器工具，要么是通过 MCP 接入的截图工具。

如何执行

如果如今检查工作要执行一连串命令并需要一些环境知识，那就把它包装成单个目标，例如 "make test" 或 "npm test"，在失败时以非零状态退出。
在 CLAUDE.md 的 Commands 部分，列出每条命令，并附上一个健康输出的示例。
说明一个目标，并让它可量化，这样 Claude 就能自行检查工作，而无需询问你，例如：“test_status.py 中的所有测试都通过”、“截图与所附的 mock 一致”，或“该端点返回 200 并带有新字段”。
对于 bug 修复，先编写失败的测试。让 Claude 将该 bug 复现为一个测试，运行它，并确认它因你预期的原因而失败。提交该测试。只有在这之后，才让 Claude 在不编辑该测试的前提下使其通过，并用最后一步中的测试文件 hook 来强制执行这一限制。一个在修复之前就已存在、且智能体无法改写的测试，就是该 bug 已被消除的证明。
对于 UI 工作，用视觉检查来闭环。给 Claude 一个浏览器或截图工具，给它 mock，让它迭代。实现、截图、比较、调整。两到三轮是正常的，而且结果应当每一轮都有所改善。
把验证变成“完成”的一部分。指令位于 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.

治理方面的考量

强制执行的内容

在任务被报告完成之前进行验证，以及在修复期间阻止智能体编辑测试文件，这两项都实现为钩子，由组织决定在何处保证其生效。

证据是什么

"make test" 的字面输出、构建日志，或 Claude 运行并粘贴的截图差异，因此证据来自工具链本身。

记录在哪里

在会话记录中，OpenTelemetry 导出会将其转发到组织的可观测性栈，同时也在 PR 的检查运行中，评审者和任何后续审计者都能看到。

谁来批准

审查 PR 的代码所有者，由于机械性证据已经附上，他们可以专注于意图和风险。

如何衡量它

领先指标

智能体所写变更的首次 CI 成功率，CI 系统已经支持这一指标。

滞后指标

每个 PR 的审查时间（来自 PR 元数据），一旦测试能捕获过去由审查者捕获的问题，这个时间就应当下降；以及来自事故追踪系统的变更失败率。

CI 中的持续评估

评估是 AI 原生的阶段门 QA 等价物。在实践中，这意味着每当智能体的配置发生变化时都会运行一套测试套件。当换入新模型或重写提示词时，评估套件会说明智能体是否仍能按相同标准完成工作。

评估应被视为一套持续运行的实时套件。随着模型改进，曾经具有区分度的用例不再具有区分度，必须根据持续监控中产生的新情况添加新用例。

取决于具体用例，一些团队可能更倾向于按固定节奏离线运行这些评估，而不是在每次变更时运行。以下步骤针对的是持续评估。

入门

前置条件

CLAUDE.md 以及反馈闭环（第 4 阶段：测试）。

基础设施

能够以非交互方式运行 Claude Code 的 CI，以及一个为评估运行预留了预算的 API key。

如何执行

平台工程师从近期工作中收集 20 到 50 个真实任务，并附上其预期/可接受的结果。
将每个任务写成一个 eval，即提示词加上定义何为可接受的检查项（测试通过、lint 干净、行为不变、遵循策略）。
该套件在 CI 中以非交互方式运行，按计划执行，并在 CLAUDE.md、技能或钩子发生任何变更时触发，因为这类配置会引导智能体的行为，理应获得代码所享有的回归测试。
以结果作为配置变更的准入门槛。导致通过率下降的技能变更，在合并前必须经过审查。
每一起生产事故都要生成一个 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

治理考量

Evals 为 QA 提供了一道能跟上智能体产出的准入门槛。通过率阈值作为合并检查强制执行，运行过程会被记录，以便结果可以随时间进行比较，而负责该配置变更的团队则负责批准它。

如何衡量它

领先指标

随时间变化的评估通过率，由测试套件在每次运行时报告，以及一个生产事故需要多长时间才能转化为一个永久性评估。

滞后指标

在 CI 中捕获的回归，与从事故跟踪器中发现的、在生产环境中出现的回归进行对比。

部署

双向审查运行，治理在智能体行动时即被强制执行。智能体完成直到生产门禁之前的一切工作，绝不越过它。

AI 参与 PR 审查闭环

Claude 既给出审查意见，也接收审查意见。它依据组织的策略审查收到的 PR，并处理自己 PR 上的审查评论。这让工程师能在 PR 审查中专注于行为层面，归根结底就是判断意图和风险。

传统审查能力是围绕人类产出规划的。一个 PR 要等审查者把它全部读完，审查质量随审查者的负载而波动，作者在催促，而积压却越来越多。

AI 原生所有 PR 都获得一组完全相同的审查轮次，发现的问题按严重程度排序。人类的注意力上移一个层级，转向变更是否实现了计划所意图的目标，以及风险是否可接受。

入门

前置条件

一份来自第 3 阶段：构建的更新后的 CLAUDE.md 文件；如果审查通过，则技能会强制执行书面策略、已定义的子智能体。

基础设施

一个已安装 Claude 集成的代码仓库，要么是由管理员启用的托管式 Code Review（研究预览）服务，要么是在你自己的 CI 中运行的 claude-code-action，在需要时通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 进行模型调用（CI/CD 实践涵盖了这些部署选项）。要求代码所有者批准的分支保护策略也值得配置。

如何执行

托管式 Code Review 服务是最快的起步方式。管理员启用它并选择代码仓库。当你需要控制流水线，或希望 API 调用通过你自己的云服务协议路由时，可以使用 claude-code-action 在你自己的 CI 中运行审查（CI/CD 实践涵盖了相关的管道搭建）。
技术负责人将审查策略编写为仓库根目录下的 REVIEW.md，按组织关注的审查轮次划分：缺陷与逻辑错误；安全与漏洞；针对规范的合规性（来自需求实践的 spec.md）、实现计划（来自计划模式实践的 plan.md）以及设计原则。REVIEW.md 还定义了什么算作重要问题而非小问题，以及哪些内容应当跳过。
技术负责人设定人工阈值。审查发现本身不会批准或阻止 PR，分支保护仍然要求代码所有者的批准。希望以审查发现作为合并门槛的平台工程师，可以读取该检查运行所发布的、以机器可读计数形式呈现的严重性计数。
当审查者或作者在审查评论中标记 @claude 时，Claude 会处理该评论并推送修复。PR 讨论串会同时记录该请求和所做的更改。这个修复循环通过 claude-code-action 运行。在托管服务中，评论 @claude review 则会请求一次全新的审查。对于 Claude 开启的 PR，可以更进一步，让 Claude 照看该 PR 直至合并。团队将这一循环封装在一个自定义斜杠命令中，该命令会扫描 PR 上未解决的审查评论和失败的检查，逐一处理并推送修复，直到 PR 变绿、只等待代码所有者批准。
审查发现会反馈到 CLAUDE.md 中。当某次审查第二次标记同一个错误时，该更正会作为该次审查的一部分写入 CLAUDE.md，而由于审查会读取 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 本身就是审计记录。批准由人类通过分支保护机制给出，并以审查发现为依据。

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

如何衡量

领先指标

首次审查所需时间，应降至分钟级，以及在无需人工触碰分支的情况下解决的审查评论占比，数据直接存储在 Git 上。

滞后指标

合并前捕获的缺陷和漏洞与逃逸到生产环境的缺陷和漏洞之比，数据来自 PR 历史和事件跟踪系统。

将钩子用作审批门禁

构建阶段将钩子用作护栏，在无人工参与的情况下允许或阻止操作（第 3 阶段：构建）。钩子也可以发起询问，暂停操作直到特定人员批准，这正是发布门禁所需要的。

该实践属于第 5 阶段：部署，因为发布门禁是最清晰的案例，但钩子并非部署专属：只要 Claude 有所动作的地方，它们都会运行。例如，钩子可以在第 3 阶段：构建期间阻止在没有变更工单的情况下对迁移和基础设施的编辑，并在第 4 阶段：测试期间阻止智能体在修复任务中编辑测试文件。

入门

前提条件

无。

基础设施

一份书面清单，列出变更流程所要求的各项审批。

如何执行

工程领导层会同变更管理与合规团队，列出必须保留的人工审批门禁，例如变更管理签核、发布授权，以及对受保护路径的编辑。
平台工程师将每个门禁表达为一个钩子，即一段在 Claude 行动之前运行的脚本，它可以允许、询问或阻止。
团队钩子放在 git 中的 .claude/settings.json，而不可协商的钩子放在由平台或 IT 管理员拥有的托管设置中，单个工程师无法将其关闭。
一个代码块应当能够自我说明，因此当某个 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 意味着工程师机器上的每一个技能、智能体、hook 和 MCP 服务器都来自组织批准的插件市场，绝不来自主目录。

allowManagedMcpServersOnly 让智能体的工具面成为由平台团队拥有的允许列表。

requiredMinimumVersion 会在版本低于批准下限时拒绝启动，因此这些管控措施由组织实际评估过的构建版本来强制执行。

请将上述内容视为可供定制的起点，而非照搬的建议。每一项拒绝都会与能力形成权衡，而正确的平衡取决于代码仓库的数据分级。设置参考文档记录了每一个键，包括仅限托管版的键：code.claude.com/docs/en/settings

如何衡量它（针对 hooks 本身）

领先指标

在每个审批门禁上等待所花费的时间。每一次 hook 决策都会连同时间戳以及允许或阻止的判定结果写入 OpenTelemetry 导出，因此每个门禁的等待时间都清晰可见。

滞后指标

来自事件追踪系统的、在引入 hooks 前后到达生产环境的门禁违规情况。

CI/CD 集成与部署

在 CI/CD 流水线中以非交互方式运行 Claude Code，对执行进行沙箱隔离，使长时间运行的智能体能够安全运行，通过 MCP 集成暴露部署能力，并在智能体真正需要之前就演练好回滚路径。

传统流水线运行的是确定性脚本，任何需要判断的事情都要等待人工处理。例如，对不稳定的测试进行分诊、编写变更日志，或者弄清楚构建为什么失败。部署和回滚是人工在压力下遵循的操作手册。

AI 原生的 Claude 在流水线中以非交互方式运行，负责那些需要判断的步骤，运行在具有限定范围凭证的沙箱中。部署工具通过 MCP 暴露给智能体，因此编写并测试了变更的工作流也能发布它并回滚它，且处于组织为每个环境定义的门禁之内。

快速上手

前置条件

将 Claude 纳入 PR 审查循环，并把 hooks 作为审批门禁，因为在这些门禁存在之前，自动化不能加速任何流程通过它们。

基础设施

一个安装了 claude-code-action 的 CI 平台，或任何能够调用 claude -p 的 runner；通过 API 访问模型，或在流量必须留在组织云协议内的情况下使用 Bedrock、Foundry 或 Vertex；用于部署目标的 MCP 服务器；为智能体任务配置的沙箱配置文件，且不持有长期有效的生产凭证。

如何执行

平台工程师从只读的判断步骤开始。在流水线任务中使用 claude -p 来分诊失败的构建、总结不稳定的测试，或起草变更日志。
在现有门禁之后添加写入步骤，用于修复 lint、更新生成的文档，或通过 @claude 提及来处理审查评论等任务。智能体写入的任何内容都通过分支保护以 PR 形式提交，智能体没有任何途径直接推送到 main。
执行在沙箱中进行。智能体任务在容器中运行，受网络策略约束，使用短期作用域 token，默认不持有任何生产凭证。
通过 MCP 暴露部署能力。部署、状态查询和回滚都成为工具，按环境划分作用域，因此智能体的部署权限是一份允许列表，而不是一个带着凭据的 shell 脚本。
按环境对自主性分级。在开发环境中，智能体可以自由部署。在生产环境中，智能体准备发布，由发布经理授权，并通过一个 hook 强制执行生产环境门禁。预发布环境介于两者之间。
回滚应当是流水线中演练得最充分的路径，一条智能体可以执行的单一命令，并在预发布环境中定期演练。闭环策略（第 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 研究与评估（DORA）指标，CI 系统和部署工具链已经在输出这些指标。

维护

闭环就此形成。触发器调用 Claude，调用路径中没有任何人参与，而它发现的内容会以 intent.md 的形式重新进入流水线。

维护与闭环

到目前为止，我们讨论了如何将 Claude 加入 SDLC 流程的每个阶段，而每个阶段都需要由人来启动初始步骤。然而，这一阶段将重点转向让 Claude 自主运行以形成闭环。

例如，一个持续运行的监控智能体可以在 bug 工单被提出后，创建一个 intent.md，并依次流经需求、规划、构建、测试和审查阶段。第 6 阶段：维护以无头模式运行，各阶段之间设有独立的置信度门控——由确定性检查或对抗性审查智能体来决定上一阶段的输出是继续推进还是升级给人工处理。

传统运维是一种被动响应的阶段。所有工单或事件都在等待有人来处理并重启流程。凌晨 3 点触发的告警可能被忽略，工单可能在待办队列中一直搁置到有人接手，而如果又爆发了新的火情，事后复盘的行动项可能根本到不了代码库。

AI 原生：诸如控制带越界、工单、频道消息或定时计划之类的触发器会在无需人工介入的情况下调用 Claude。Claude 进行诊断，仅通过受门控的路径执行操作，并将其发现写入 intent.md，随后进入上述各个阶段。由人来分诊和审查这些工作，而不再需要由人来启动它。

闭环

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

快速上手

前置条件

Intent.md，它为循环提供了可重启的结构化输出。Claude 加速了 PR 审查，将钩子作为操作边界，并为 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 服务，而 CI/CD 相关章节涵盖了部署和模型访问的选项。由于运行是无状态且非交互的，循环可以在无人启动的情况下自行开始和结束。
智能体将其诊断以 intent.md 的形式写入 Stage 1: Plan 格式中，涵盖异常及其证据、提议的结果、受影响的系统以及任何未决问题。此后，该发现像其他任何内容一样流经整个流水线。
服务负责人或值班工程师对队列进行分诊，将面向产品的发现路由给产品负责人。立即修复、排期或驳回。驳回会调整区间阈值，有助于减少噪声。
当修复上线后，为该事件添加一个 eval（即持续 eval 实践），以确保此类问题今后受到防护。

它看起来是什么样的（例如，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 的时间，对比旧有的从事件到事后复盘行动的时间。检测脚本的日志中包含突破时间戳和事件层级。

滞后指标

发现的问题最终被合并为修复的比例（将分诊队列与实际 PR 历史进行对比），以及同一类问题的重复发生次数——随着修复为 eval 套件不断补充用例，这一数字应当下降。

示例

当 CI 测试失败率突破 3σ 时，智能体会隔离不稳定的测试或提交回滚 PR，由审查门禁做决定。
当部署后 5xx 错误率突破 3σ 且该时间窗口内有部署发生时，智能体会触发现有的回滚流水线。
当 PR 周期时间触发漂移规则时，智能体会为工程管理层撰写报告，这表明该框架不仅适用于生产指标，也适用于流程指标。

检测保持确定性。一旦某个区间被突破，才会调用 Claude，而层级决定了它可以做什么。

定期代码库扫描

安全扫描是针对特定模型下代码库某一时间点的陈述，而这两半都会过时：代码每周都在变化，每一代模型都会发现上一代遗漏的漏洞。AI 原生的答案是按计划运行扫描，调用路径中无需人工介入，并将扫描发现的问题通过与代码库任何其他变更相同的门禁流程。

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

传统安全扫描是一个事件：在发布或审计之前启动一次扫描。报告进入跟踪系统，积压的问题靠人工逐项处理，直到下一次事件。其间编写的代码则由 PR 审查所捕获的内容来覆盖。

AI 原生扫描按计划针对每一个已连接的仓库运行，使用可用的最强模型，并在任何人阅读之前对发现进行验证。每一条发现都按照突破控制带的方式处理：能放进一个 PR 的修复走审查关卡，任何更大的改动则成为一个 intent.md。覆盖范围从上次运行起算，而不是从第一次运行起算

快速开始

前置条件

PR 审查门禁与作为审批门禁的 hooks（阶段 5：部署），使发现的问题像任何其他变更一样经过审查。intent.md格式来自阶段 1：规划，适用于单个 PR 无法容纳的过大的发现。

基础设施

Claude Security 现面向 Claude Enterprise 组织开放公开测试版。它需要在目标代码仓库（云端托管的 github.com）上安装 Anthropic GitHub App，启用 Claude Code on the Web，开启 Extra Usage 并设置支出限额，为执行扫描的人员分配高级席位，并由管理员在 claude.ai/admin-settings/claude-code 处开启该功能。扫描按 Mythos 5 费率按用量计费，因此支出限额应与代码仓库的规模和数量相匹配。

如何执行

安全负责人连接这些代码仓库，并按仓库、服务或团队将其组织为项目，从而从一开始就明确各项发现的归属。
对最关键的代码仓库运行首次完整扫描，包括那些此前已被其他工具或更早的模型扫描过的仓库。将首次扫描视为基线。首次扫描很可能会在曾被认为干净的代码中发现问题。
为每个项目设置计划。对于活跃开发的服务，每周一次是合理的默认值；当仓库规模较大或内容混杂时，将扫描范围限定到某个目录或分支。
在掌握置信度评级的情况下对发现项进行分诊。驳回时附上理由，这样驳回会被记录在案，同一发现项在下次运行时就不会作为新问题再次出现。
对于范围有限的发现项，在 Claude Code on the Web 中打开建议的补丁，进行审查，然后像对待任何其他变更一样，将其送交 PR 审查关卡。提出该修复的智能体无权批准它。
对于任何范围超过单个补丁的问题，例如架构弱点或跨服务重复出现的模式，请按照 Stage 1 格式将其写成 intent.md，并从 Plan 阶段开始。
当修复发布到生产环境后，将针对该漏洞类别的评估添加到持续评估方案中的测试套件里，这样从那时起，用于引导智能体的配置就会针对该类别进行测试。
将发现结果导出为 CSV 或 Markdown，或使用 webhook，以便让组织现有的跟踪和审计系统继续作为记录系统，审计人员已经习惯在那里查看。

治理考量

扫描在组织的管理员控制下运行，这意味着连接哪些代码仓库、谁拥有扫描席位以及支出限额都由中央统一设置。每个发现结果都有验证结果和置信度评级，每次驳回都有原因，因此扫描历史就是一份审计记录，记录了发现了什么、修复了什么以及有意接受了什么。

修复通过 PR 审查门禁和分支保护进入生产环境，而不是由扫描本身直接推送。Claude Security 是对现有静态分析和依赖扫描的增强。确定性检查仍留在 CI 中，而模型驱动的扫描则覆盖那些检查并非为发现而构建的、依赖上下文的漏洞。

如何衡量

领先指标

按计划接入的代码仓库占比，以及从发现被报告到其补丁进入 PR 审查门禁所需的时间，读取自扫描历史和 PR 元数据。

滞后指标

计划扫描发现的漏洞与生产环境中或通过外部报告发现的漏洞之比，读取自事件跟踪系统；以及在已历经多轮运行的仓库中，每次扫描发现数量的趋势——随着修复和评估的积累，这一数字应当下降。

Claude 值班，配合 Claude Tag

事件也可能通过其他途径到来，例如 Slack 或 Teams 这类职场沟通应用。事件可能表现为晚上 10 点发在事件频道里的一条 Slack 消息，要求紧急修复，而现在可以立即采取行动。Claude Tag（目前以公开测试版在 Slack 中提供）让 Claude 以自己的身份成为这些频道的成员，因此每个新事件都有了一位第一响应者，而响应本身也成为循环的一部分，并成为未来事件的记忆。

对话和机构知识都留在频道中，频道内的任何人都能引导并执行响应。任何团队成员都可以测试假设、探索新方案并实时调查，而频道历史则增强了可审计性。通过访问 MCP，Claude 验证指标已回到基线，并在话题中予以确认，将事后复盘写入一个受版本控制的经验教训文件，供未来的调查读取。

事件并非 Claude Tag 唯一承接的工作。无论是在 MCP 上被标记到某个工单，还是在频道中被提问，Claude 都会以同样的方式对工作进行分诊。一个小而边界清晰的修复会以 PR 的形式通过审查关卡送达，而任何规模更大的内容都会被写成 intent.md，进入第 1 阶段：规划，此时这个循环便开始自我供给。参见：Claude Tag 如何在 Anthropic 为 CI/CD 执行值班工作。

频道就是审计追踪：请求、诊断、人工授权和修复全都留在事件被处理的地方。

结语

模型和运行框架已变得更加先进，使各组织不仅能够转变其编写代码的方式，还能转变整个软件开发生命周期。

这一转变让人类判断始终处于流程的核心，并兼顾大型企业组织的治理与监管要求。

本指南汇集了我们应用 AI 团队每天为客户付诸实践的许多真实最佳实践，我们希望你觉得它是一份实用且可操作的资源。

循环持续运转。人类判断始终居于其上。

资源与致谢

下面的文档是平台团队设置这些控制措施所需的内容，大致按照你会逐步推行的顺序排列。

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献，本指南的灵感来源于他们此前的大量工作，并在其基础上构建而成。