AI 原生 SDLC 实战手册

原文：The AI-Native SDLC playbook · Anthropic

代码不再是瓶颈

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

许多工程团队依然保留着同样的审批关卡、评审、交接和政策，这拖住了 Claude Code 这类智能体编码方案本可以带来的生产力提升。

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

传统 SDLC 流程繁重，目的是确保每一步都有问责和管控。然而，传统 SDLC 的设计前提是：最耗时、最昂贵的阶段是编写和实现代码——而这个前提如今已不成立。PRD、估点仪式、产品安全评审，这些都是为了在可能长达数周、数月甚至数个季度的开发工作中强制对齐而存在的。

传统 SDLC 还包含大量假定「每一步都由人执行」的管控措施。而那些创造出最大价值的组织，已经围绕智能体 AI 如今的能力重建了自己的流程，同时确保人始终在环。在这份指南里，我们将梳理 Anthropic 应用 AI 团队在 SDLC 各阶段内部集成 Claude 的若干最佳实践——这些实践源自我们与客户的合作，目标是加速开发、让流程跑得更快。

当代码不再是瓶颈、构建阶段跑得比传统 SDLC 所能容纳的更快时，有三件事会成立：

• 瓶颈转移到构建阶段左右两侧的环节。主要是规划、评审/测试和部署，它们仍以人的速度运行。
• 管控措施开始与现实脱节，变得难以为继。当代码是人写的，逐行手工评审是合理的；但一旦大部分 diff 由智能体产出，这种做法就跟不上了。
• 治理成本上升，因为例外情况仍然要走每周或每月才开一次的会议和委员会流程。

构建不再是约束——约束是它周围那些以人的速度运行的环节。当构建坍缩到以小时计时，人速阶段的时长却纹丝不动。

我们拿安全瓶颈举个例子。安全团队的人员编制是按人类产出规模设定的，所以当智能体把代码产出翻倍时，要么评审队列越积越长，要么代码在评审不足的情况下上线。受监管的组织两种结果都无法接受，因此它的安全与政策检查必须跟上智能体的节奏。

要更好地兑现智能体 AI 的生产力红利、并让它安全可控，传统 SDLC 生命周期需要经历与实现阶段同等程度的改造。

什么是 AI 原生 SDLC？

AI 原生 SDLC 是一个重新构想的流程：它保留旧有的控制目标，但换上新的执行方式。流程不再是线性的，而是变成一个循环，AI 嵌入在每一个节点上。AI 原生 SDLC 推动自动化的交接和后续打法（play）的自动触发，从而化解传统 SDLC 各阶段之间那种手工且笨重的交接方式。你也会听到有人把这个转变叫作 agentic SDLC、AI SDLC，或者干脆就叫智能体软件开发——叫法不同，说的是同一件事。

AI 原生 SDLC 六个阶段的转变。

转变

下表列出了传统 SDLC 与 Claude 支撑下的 AI 原生 SDLC 这一光谱的两端。大多数组织处在两列之间的某个位置。

阶段	传统 SDLC	AI 原生 SDLC
规划（Plan）	需求由委员会收集，经工作坊和签字层层提炼，再手工撰写	Claude 直接从源头综合出痛点，并写入 intent.md——它既能被人读懂，也能被机器执行
设计（Design）	规格由分析师撰写，再由设计师解析	需求与设计被压缩进与智能体的一次工作会话，由编码为 skills 的标准引导，并在 git 中版本化
构建（Build）	测试和代码手写，文档在主要开发完成之后才补	测试和代码由 AI 生成，组织知识以版本化、机器可读的 CLAUDE.md 文件和 skills 形式维护
测试（Test）	QA 关卡设在阶段边界上	持续评估贯穿整个实现过程
部署（Deploy）	人工评审每一行代码，治理发生在评审周期中，且往往不一致	多层智能体评审，人工评审只保留给受监管和关键代码。治理在 AI 行动的同时被执行，以 hooks 作为审批关卡
维护（Maintain）	人盯着生产环境找 bug	智能体监控线上部署。任何被突破的控制带（control band）都会被诊断，并作为新的 intent.md 写回循环

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

凡是需要判断力的决策，责任依然由人承担。在智能体化的 SDLC 世界里，人的注意力随着「必须被评审的产物」一起转移。

每个阶段都提交一份下一阶段可读取的产物。意图、规格、计划、diff 与评审发现合在一起，就是审计轨迹。

打法（Plays）

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

每个打法涵盖：

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

这些步骤是模块化的，组织可以根据自身独特需求，在不同时间优先改造不同阶段。每个打法都在「前置条件」下列出了自己的依赖，依赖关系图对此有进一步说明。

一个阶段以提交一份产物作为结束，而这次提交会启动下一阶段。一份被接受的 intent.md 触发需求与设计环节，一份获批的 spec.md 触发计划模式，一个被合并的 PR 触发流水线，而生产环境中一条被突破的控制带则写出下一份 intent.md——循环由此继续。

起初，你需要手工提示每一步；终态则是一个循环，其中每份被接受的产物都会触发下一道关卡。人的注意力集中在关卡上，评审智能体标记出来的东西，而不是每个阶段都从零开始。

图中打法按阶段列出；箭头给出的是采用顺序。两者并不相同。可以从任何一个「起点打法」开始——没有箭头指向它，所以它不需要任何前置条件。对于其他任何打法，指向它的箭头就是需要先行采用的打法。

规划（Plan）

想法不再等着别人来把它写下来。意图被一次性捕获，用发起人自己的话表达，成为下一阶段可以直接据以行动的、受版本控制的产物。

用 intent.md 捕获意图

启动软件开发流程的 intent.md 可以通过不同途径产生。可能是某人有了一个想法、有人提了一张工单，或者告警暴露出一起事故（见第 6 阶段：维护）。

当一个人有了想法，他与 Claude 头脑风暴，产出一份 markdown 原型规格（proto-spec）。而在传统 SDLC 里，同一个人接下来必须说服产品团队的某位成员，和他一起、或者代他把这个想法写下来。

Claude 生成的原型规格既可读，又受版本控制，还能被下一阶段立即消费。这份原型规格被保存为 intent.md。

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

传统方式：一个想法要经过待办条目、用户故事、故事点和细化会议，才有人能据此行动。每次交接所有权都在转移，所以最终到达工程团队的东西，已经和发起人的本意隔了好几层。

AI 原生方式：发起人与 Claude 头脑风暴，把结果写成 intent.md——一份用发起人自己的语言表达的原型规格。这份产物记录了想要什么、为什么要、以及在什么约束之下。重复性流程通过 skills 编码固化。

如何起步

前置条件

无。

基础设施

让非工程人员也能访问 Claude（claude.ai 或 Cowork）；一份约定好的 intent.md 模板；一个受版本控制、由产品负责人关注的共享存放位置。对单个产品来说，最简单的位置就是产品仓库里的一个 intent/ 目录。这样布置能让产物链条紧挨着由它派生出的代码。只有当意图跨越多个仓库时，专设一个 intent 仓库才值得那份额外开销；在 monorepo 里它就是一个目录。第 3 阶段「构建」的边栏会讲这个位置如何与已经承载记录的 Jira 或需求管理工具相处。

这项配置对平台团队或工程团队来说是一次性任务。需要一位技术成员把 intent 存放位置搭起来，并决定谁有写入权限，因为贡献者会来自组织的各个角落。

仓库一旦存在，没有 git 经验的贡献者不必直接使用 git。取而代之的是，一个连接到版本控制系统（例如 GitHub）的连接器，可以让 Claude 从 claude.ai 或 Cowork 代他们提交 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，其中列出了作者、时间戳和完整的修订历史，并记录在 intent 存放位置的 git 历史里。由产品负责人批准，而那个把意图送进第 2 阶段「设计」的接受或拒绝决定，会以合并记录或结案评审的形式被留存下来。

如何衡量

先行指标

从第一次对话到 intent.md 被提交所花的时间，可从 intent 存放位置的 git 历史中读出（其中记录了作者和时间戳）。预期是从数周的需求引出与细化周期，下降到数小时。

滞后指标

存活率，即被产品负责人接受进入第 2 阶段「设计」（而非直接关闭）的 intent.md 占比。接受或拒绝的决定以产物的合并或评审关闭的形式记录。此外还要看：在同一变更的第一份 spec.md 提交之后，intent.md 又被改动了多少次。

设计（Design）

需求与设计坍缩进同一次会话。政策在规格被撰写的当下就被应用，而不是几周后在评审中才被发现。

需求与设计

一旦产品负责人批准，Claude 就拿走这份被接受的 intent.md，产出一份需求与设计规格。整个过程由组织在品牌、安全、合规和 UX 方面的 skills 引导。

产品负责人评审这份规格，但不撰写它。这个流程的目标，是产出一份工程团队可以据以做计划的规格，其中标注出需要关注的地方。

前端工作是最清晰的例子。intent.md 一经接受，产品负责人就基于它在 Claude Design（beta）中做出设计稿，在稿子上迭代，然后导出到 Claude Code 去构建。

传统方式：需求和设计是由不同团队负责的两个独立阶段。分析师把想法形式化为需求，设计师再把需求解析回设计。这种分离的存在是为了问责，但它既慢又有损耗。

AI 原生方式：两个阶段在一次被提示驱动的会话里同时完成。Claude 拿走 intent.md，在组织 skills 的约束下产出需求与设计规格，并标注出需要关注的地方。

如何起步

前置条件

写好一份 intent.md 文件，并把品牌、安全、合规和 UX 政策写成 skills。

基础设施

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

具体怎么做

1. 产品负责人开启一次会话，让组织的 skills 处于可用状态，并附上 intent.md。
2. 产品负责人的提示词指向那份 intent.md，点名各项约束，并要求标注出需要关注的地方。一开始手工执行，之后把它固化为组织级的斜杠命令。再往后，把 intent 存放位置中「intent.md 被接受」这件事设为触发器：由一个在合并时触发的非交互式任务，在加载组织 skills 的情况下跑完这一遍，并以 pull request 的形式提交 spec.md（第 5 阶段「部署」中的 CI/CD 打法会讲这套管道）。从那一刻起，产品负责人第一次介入就是评审。
3. 同一位产品负责人对照最初的想法评审规格。这份规格是否解决了陈述的问题？intent.md 里的待解问题是被回答了，还是被延续下来了？
4. 优先处理被标注出的关注点，因为它们正是分析师本会向上升级的那些点。产品负责人在工程团队看到规格之前，就与各政策负责人逐一解决它们。
5. 把 spec.md 与 intent.md 并排提交。这一对文件记录了「要求的是什么」和「决定的是什么」。
6. 产品负责人决定规格与意图是否进入构建阶段；凡是组织判定为较高风险的内容，都要咨询技术负责人。这个判断始终由人类同事作出，而接受规格正是启动第 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.

治理考量

政策不再是几周后在评审中才被发现，而是在规格被撰写的当下就被读取和应用。组织的 skills 作为约束施加在规格之上。规格本身、产生它的提示词、以及当时生效的 skill 版本，全都记录在版本控制里。产品负责人对规格签字确认，并把被标注的关注点路由给指定的政策负责人。

如何衡量

先行指标

同一变更的 intent.md 提交与 spec.md 提交之间的时间间隔（两个 git 时间戳），与旧的「需求 + 设计」周期作对比。

滞后指标

构建开始之后的需求返工量。统计同一变更中日期晚于第一次 plan.md 提交的 spec.md 提交次数。git log 可以直接给出这个数字。

构建（Build）

没有被接受的计划，就不实现任何东西。组织知识变成智能体可读的文件，护栏以代码的方式运行，而不是靠习惯维系。

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

工程师在计划模式下开启 Claude Code 会话，把第 2 阶段「设计」产出的、已获批的 spec.md 交给 Claude，让它反过来对自己提问，并不断迭代这份计划，直到工程师满意为止。

传统方式：工程师读完设计就开始写代码。这次改动具体怎么做、涉及哪些文件、要写哪些测试，全都留在工程师脑子里，顶多写在工单评论里。别人无从评审。评审者看到的第一样东西就是成品 diff，而到那时返工已经很慢了。

AI 原生方式：工作从一份书面计划开始，由 Claude 在计划模式下产出——在该模式下它可以读取代码库但不做任何修改。工程师在代码被写出之前先修正计划，获批的版本作为 plan.md 提交，供后续阶段据以核对。

如何起步

前置条件

如果已经有意图产物（intent.md 或 spec.md）就用上，另外有 CLAUDE.md 文件会很有帮助。

基础设施

拥有仓库访问权限的 Claude Code。

具体怎么做

1. 工程师以计划模式与 Claude 开启会话。
2. 工程师把 intent.md 和 spec.md 交给 Claude，要求它给出一份实现计划，点名哪些文件会变、工作顺序是什么、以及用哪些测试来证明它成立。
3. 拷问这份计划：这次改动可能弄坏什么？哪一步风险最大？Claude 考虑过但选择放弃的其他方案有哪些？
4. 反复迭代，直到一位从未看过这段对话的工程师，仅凭这份计划就能实现该改动。
5. 把获批的计划作为 plan.md 提交。计划加入审计轨迹，而 PR 评审打法（第 5 阶段「部署」）会拿最终 diff 与它核对。
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.

治理考量

设计评审发生在任何代码被生成之前——那时改变方向还只是编辑一份文档的事。计划模式本身就强制了这一点，因为在工程师接受计划之前，Claude 无法编辑文件。计划及其修订记录会连同「谁接受了它」一起被留存。常规改动由工程师批准；凡是组织判定为较高风险的内容，则交由技术负责人或架构师。

如何衡量

先行指标

第一遍实现就成功合并的改动占比；以及从计划获批到 PR 合并的时长——所需数据都在 PR 元数据里。

滞后指标

每次改动的返工轮数（同样取自 PR 元数据），以及被合并的 diff 有多大比例仍与提交的 plan.md 保持一致。

Claude Code 的 auto 模式

Claude Code 也可以运行在 auto 模式下：工程师批准计划，在满意并迭代完成之后，Claude 逐条应用改动，而不再逐次编辑都来征求确认。随着后续打法中的护栏日趋成熟（调校好的 CLAUDE.md、把政策编码进去的 skills、拦截不安全操作的 hooks、以及 Claude 可以自己跑的测试套件），自动接受会成为常规工作的默认模式：一份严密的 spec.md、一个小的影响半径、以及测试已经覆盖到的代码。

重心由此发生转移——从用户盯着智能体做编辑、逐个动作地审查，转向在更长的自主会话结束后评审产物。自动接受模式配合 worktrees 使用时，还能进一步实现个人层面和团队层面的并行；它也是自主运行 SDLC、并按第 6 阶段「维护」所述闭合循环的基础。

边栏

遗留系统与事实来源

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

现有的 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 被合并所需的时间。

用 skills 承载组织知识

Skills 是组织把自身的组织知识变得可执行的方式。指令是明确的、受版本控制的、被广泛应用的，并在政策变更时集中更新。经验法则是：为那些必须被一致执行的组织知识写 skill；不要为本该放进 CLAUDE.md 或直接写在提示词里的内容写 skill。

如何起步

前置条件

无硬性要求。有 CLAUDE.md 会有帮助，因为它把智能体的工作知识留在仓库里，但 skill 并不依赖它。

基础设施

一条有明确负责人、且有书面事实来源的政策。

具体怎么做

1. 挑一条今天执行得不一致的知识。可以是一项安全标准、一条 API 设计约定，或一条品牌规则。
2. 把它写成一个 skill：一个包含 SKILL.md 的目录，其 frontmatter 说明何时触发，正文说明该做什么。由工程师依据政策负责人的事实来源撰写，可以让 Claude 协助。
3. 把 skill 放在仓库的 .claude/skills/<name>/ 下，让它随代码一起分发；或者通过插件在组织范围内分发。
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 没有被触发，要么是它的文本已经和正式政策产生了偏移。

用 hooks 做构建期护栏

skill 是建议性的控制手段，而 hook 是它背后那层确定性的保障。Claude 在实现过程中的大多数动作都是文件编辑和 shell 命令，所以构建阶段往往是 hooks 触发最频繁的地方。

构建阶段的 hooks 可以：

• 拦截对受保护路径的编辑，比如生成的类文件或已冻结的包；
• 在文件编辑后运行格式化工具和 linter，让偏移永远不会累积；
• 把凭据挡在 diff 之外。

凡是政策必须无例外成立的 skill，都要用 hook 兜底。hook 会在每一个与之匹配的动作上运行，所以构建阶段的 hooks 应当快速、且只作用于发生变化的那个文件。更重的检查（比如跑完整测试套件）属于提交或 PR 阶段。

需要人工审批的 hook 应当归入第 5 阶段「部署」中的关卡部分，因为构建过程中弹出审批提示，会把人重新放回所有并行会话的关键路径上。

并行会话与子智能体

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

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

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

并行会话提升了一位工程师可以同时在手的任务数量，而子智能体让每个会话专注于自己的任务。工程师的工作是掌舵并评审它们全部。

传统方式：一位工程师一次只做一个任务，一天或一周中相当大的比例花在构建、测试和等待评审者上。等待期间切到别的任务当然可行，但上下文切换足够累人，以至于很少有人真的这么做。

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

如何起步

前置条件

CLAUDE.md，因为所有会话都会读这个文件。反馈回路（第 4 阶段「测试」）在这里也有帮助，因为当一个会话能自行验证工作成果时，工程师需要的监督就更少。

基础设施

一个 git 仓库（隔离来自 worktrees），以及调校好的权限设置——让会话不必为组织认定安全的命令去等待审批提示。

具体怎么做

1. 工程师把工作拆分成触及不同文件的任务，用计划模式打法（第 3 阶段「构建」）产出的计划来判断哪些工作是彼此独立的。共享文件的任务放在同一个会话里依次执行。
2. 每个并行任务分配自己的 worktree，比如在一个终端里 claude --worktree feature-auth，在另一个终端里 claude --worktree fix-rate-limit。worktree 是一份位于独立分支上的单独检出，能防止会话在文件上互相冲突。
3. 两三个会话是合理的起点。实际上限取决于一个人能认真评审多少条流，所以只有在评审跟得上的前提下才增加会话数。
4. 把重复性工作变成子智能体：定义在 .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 历史中确定的返工率对照阅读。

测试（Test）

每个会话在人看到之前先自查工作成果，而引导智能体的那套配置，也要像它写出的代码一样接受回归测试。

给 Claude 一个反馈回路

永远要给 Claude 一条验证自身工作的途径，无论是测试、构建，还是截图比对。会话在工程师看到之前，就自查工作、自行修正错误。

不要把反馈回路和验证器子智能体（第 3 阶段「构建」）混为一谈。反馈回路贯穿整个任务，工作需要跑多少次就跑多少次。而验证器子智能体是打包最终检查的一种方式：在会话认为工作完成之后，用一个全新的上下文窗口跑一次。这样得出的结论就不会被那些产生了代码的假设所污染。

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

AI 原生方式：会话被赋予一条在人看到之前自查工作的途径。跑测试、跑构建、截图。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 就能做到这一点。另一种办法是在评审时检查 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.

治理考量

强制执行什么

任务被报告完成之前必须验证，以及在修复任务期间禁止智能体编辑测试文件——两者在组织希望获得确定性保证时，都以 hooks 的形式实现。

证据是什么

make test 的原始输出、构建日志、或 Claude 跑出并粘贴上来的截图比对结果——也就是说，证据来自工具链本身。

记录在哪里

记录在会话轨迹中（由 OpenTelemetry 导出转发到组织的可观测性栈），以及 PR 的 check run 中——评审者和日后的审计人员都能看到。

谁来批准

评审该 PR 的代码属主。由于机械性的证据已经附在上面，他们可以把注意力集中在意图和风险上。

如何衡量

先行指标

智能体所写改动的 CI 一次通过率，CI 系统本身就已支持统计。

滞后指标

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

CI 中的持续评估

评估（evals）是阶段关卡式 QA 在 AI 原生世界里的对应物。落到实处，就是一套在智能体配置发生变化时就会运行的测试集。当换上新模型或改写了提示词，评估套件会告诉你这个智能体是否仍以同样的标准完成工作。

评估应当被视作一套活的测试集。随着模型进步，曾经具有区分度的用例会失去区分度，而新的用例必须从持续监控中产生并被补充进来。

视用例而定，有些团队可能更愿意按固定节奏离线运行这些评估，而不是每次变更都跑。下面的步骤针对的是持续评估。

如何起步

前置条件

CLAUDE.md 和反馈回路（第 4 阶段「测试」）。

基础设施

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

具体怎么做

1. 平台工程师从近期工作中收集 20 到 50 个真实任务，连同它们的预期/可接受结果。
2. 把每个任务写成一条评估，也就是提示词加上定义「可接受」的那些检查项（测试通过、lint 干净、行为未变、政策被遵守）。
3. 该套件在 CI 中以非交互方式运行：按计划定时跑，以及在 CLAUDE.md、skills 或 hooks 发生任何变更时跑——因为这些配置在引导智能体，理应享有代码所享有的回归测试。
4. 用结果为配置变更把关。一次导致通过率下降的 skill 改动，必须在合并前接受评审。
5. 每一起生产事故都对应写一条评估，由负责该事故的团队撰写，并作为回归测试长期留在套件中。

长什么样（.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 中被拦下的回归数量，与从事故追踪系统中得出的、在生产环境才被发现的回归数量作对比。

部署（Deploy）

评审是双向运行的，治理在智能体行动的当下就被执行。智能体做完通往生产关卡之前的一切，但绝不越过那道关卡。

让 AI 进入 PR 评审回路

Claude 既做评审，也接受评审。它按组织的政策评审进来的 PR，也处理别人对它自己 PR 的评审意见。这让工程师在 PR 评审中得以专注于行为本身——归根结底就是判断意图和风险。

传统方式：评审产能是按人类产出规模规划的。一个 PR 要等评审者把它通读一遍，评审质量随评审者的负荷波动，作者一边催一边看积压越堆越多。

AI 原生方式：所有 PR 都经过同一套评审环节，问题按严重程度排序。人的注意力上移一个层次：这次改动是否做到了计划的本意？风险是否可接受？

如何起步

前置条件

第 3 阶段「构建」中更新好的 CLAUDE.md 文件；如果评审环节要执行成文的政策，还需要 skills，以及定义好的子智能体。

基础设施

一个安装了 Claude 集成的仓库——要么由管理员启用托管的 Code Review（研究预览版）服务，要么在自己的 CI 中运行 claude-code-action，必要时让模型调用走 AWS Bedrock、Google Vertex 或 Microsoft Foundry（CI/CD 打法会讲这些部署选项）。要求代码属主批准的分支保护策略也很值得配上。

具体怎么做

1. 托管的 Code Review 服务是最快的起步方式。管理员启用它并选择仓库即可。当你需要掌控流水线、或希望 API 调用走自己的云合约时，就用 claude-code-action 在自己的 CI 里跑评审（CI/CD 打法会讲这套管道）。
2. 技术负责人把评审政策写成仓库根目录下的 REVIEW.md，按组织关心的环节划分：缺陷与逻辑错误；安全与漏洞；对规格（需求打法产出的 spec.md）、实现计划（计划模式打法产出的 plan.md）和设计原则的符合性。REVIEW.md 还要定义什么算「重要（Important）」、什么只算「吹毛求疵（Nit）」，以及哪些内容跳过不报。
3. 技术负责人设定人工介入的阈值。评审发现本身既不批准也不阻断 PR，分支保护仍要求代码属主批准。如果平台工程师想用发现数量为合并把关，可以读取 check run 以机器可读形式发布的严重程度计数。
4. 当评审者或作者在某条评审意见上 @claude 时，Claude 会处理这条意见并推送修复。PR 讨论串同时记录了请求和改动。这条修复回路通过 claude-code-action 运行。在托管服务中，评论 @claude review 则是请求一次全新的评审。对于 Claude 自己开的 PR，还可以更进一步，让 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 本身就是审计记录。批准由人通过分支保护给出，并以评审发现作为参考依据。

如何衡量

先行指标

首次评审的响应时间，应当降到几分钟；以及无需人工触碰分支就被解决的评审意见占比，数据直接存在 Git 里。

滞后指标

合并前被捕获的缺陷与漏洞数量，与漏到生产环境的数量作对比，数据来自 PR 历史和事故追踪系统。

用 hooks 做审批关卡

构建阶段把 hooks 用作护栏，在无人介入的情况下放行或拦截动作（第 3 阶段「构建」）。hook 也可以「询问」——暂停动作，直到某位特定的人批准，而这正是发布把关所需要的。

这个打法放在第 5 阶段「部署」里，是因为发布关卡是最清晰的例子；但 hooks 并非部署专属：Claude 在哪里行动，它们就在哪里运行。举例来说，hooks 可以在第 3 阶段「构建」中拦截没有变更工单就修改迁移脚本和基础设施的行为，也可以在第 4 阶段「测试」中阻止智能体在修复任务期间编辑测试文件。

如何起步

前置条件

无。

基础设施

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

具体怎么做

1. 工程管理层会同变更管理和合规部门，列出必须保留的人工审批关卡，比如变更管理签字、发布授权、以及对受保护路径的编辑。
2. 平台工程师把每道关卡表达为一个 hook——一段在 Claude 行动之前运行的脚本，可以放行、询问或拦截。
3. 团队级 hooks 放进 git 中的 .claude/settings.json，而不可协商的 hooks 放进由平台或 IT 管理员掌管的托管设置（managed settings）中，让单个工程师无法关掉它们。
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

治理考量

hooks 就是审批关卡。关卡条件每一次都被执行，对每个人都一样。放行与拦截的决定连同时间戳一起被记录。关卡还定义了什么才算「批准」——是一张获批的变更工单，还是发布经理的签字。

实例演示

受监管企业的托管设置

由平台团队通过 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 意味着本打法中的审批关卡是唯一会运行的 hooks；本地的任何东西都无法追加或替换它们。

disableSideloadFlags 和 strictKnownMarketplaces 意味着工程师机器上的每一个 skill、agent、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 的执行器；通过 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 流水线日志。

滞后指标

DORA（DevOps 研究与评估）指标——CI 系统和部署工具本身就已经在产出这些数据。

维护（Maintain）

回路就此闭合。一个触发器在没有人处于调用路径上的情况下唤起 Claude，而它发现的东西以 intent.md 的形式重新进入流水线。

维护与闭合回路

到目前为止，我们讨论的是如何把 Claude 加入 SDLC 的每一个阶段，而每个阶段的最初几步都需要人来启动。而这个阶段，重心转向让 Claude 自主运行、把回路闭合起来。

举例来说，一个持续运行的监控智能体可以在一张 bug 工单被提出之后，创建一份 intent.md，然后一路流经需求、计划、构建、测试和评审各阶段。第 6 阶段「维护」以无人值守（headless）方式运行，各阶段之间设有独立的置信度关卡——可以是确定性检查，也可以是一个对抗性的评审智能体——由它判定上一阶段的产出是继续往下走，还是升级给人类处理。

传统方式：维护是一个被动响应的阶段。所有工单或事故都要等人来处理并重启流程。凌晨三点的告警可能被漏掉，一张工单可能在待办里躺到有人捡起为止，而如果下一场火先烧起来，事后复盘的行动项可能根本进不了代码库。

AI 原生方式：一个触发器——控制带被突破、一张工单、一条频道消息或一个定时计划——在没有人处于调用路径上的情况下唤起 Claude。Claude 做诊断，只通过设有关卡的路径行动，并把发现写成 intent.md，随后走完上文描述的各个阶段。人负责分诊和评审这些工作，而不再需要去启动它。

闭合回路

一个确定性的脚本盯着生产环境，在控制带被突破时唤起 Claude。监控突破是理解「回路自主运行」这一模式的好例子，而本阶段末尾的 Claude Tag（公开测试版）一节，则讲述工作从其他渠道流入的情形。

如何起步

前置条件

intent.md——它给了回路一个结构化的输出用来重启流程。此外还需要：Claude 加速的 PR 评审、作为动作边界的 hooks，以及一条 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. 修复上线后，为这起事故补一条评估（见持续评估打法），确保此类问题今后都在防护之内。

长什么样（例如一份监控 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 历史），以及同类事故的重复发生次数——随着修复不断为评估套件添加用例，这个数字应当下降。

例子

• 当 CI 测试失败率突破 3σ 时，智能体隔离那个不稳定的测试，或者开一个回退 PR，由评审关卡决定。
• 当部署后 5xx 率突破 3σ 且窗口内有一次部署时，智能体触发既有的回滚流水线。
• 当 PR 周期时长触发漂移规则时，智能体为工程管理层写一份报告——这说明这套运行框架不仅适用于生产指标，也适用于流程指标。

检测环节始终保持确定性。Claude 只在控制带被突破后才被唤起，而层级决定了它可以做什么。

用 Claude Tag 让 Claude 值班

事故也可能通过其他途径抵达，比如 Slack 或 Teams 这类办公沟通应用。事故可能表现为晚上 10 点在事故频道里发来的一条紧急修复请求——而现在它可以被立即处理。Claude Tag（公开测试版，目前在 Slack 中可用）让 Claude 以自己的身份成为这些频道的成员，于是每一起新事故都有了一线响应者，而响应本身也成为回路的一部分，并沉淀为面向未来事故的记忆。

对话和组织知识都留在频道里，频道中的任何人都可以引导和推动响应过程。任何团队成员都能实时验证假设、探索新方案、开展调查，而频道历史进一步增强了可审计性。通过 MCP 的访问能力，Claude 会验证指标是否已回到基线并在讨论串中确认，还会把复盘写进一个受版本控制的经验教训文件，供未来的调查读取。

Claude Tag 承接的工作不止于事故。通过 MCP 在一张工单上被标记，或者在频道里被直接询问，Claude 都会以同样的方式对工作做分诊。一个小而边界清晰的修复，会以 PR 的形式经过评审关卡抵达；任何更大的事情则被写成 intent.md 交给第 1 阶段「规划」——至此，回路开始自我喂养。延伸阅读：Claude Tag 在 Anthropic 如何为 CI/CD 值班。

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

结语

模型和运行框架（harness）都变得更先进了，这让组织不仅能改造代码的生产方式，更能改造整个软件开发生命周期。

这场改造把人的判断力保持在流程的核心位置，并充分考虑了大型企业组织的治理与监管要求。

这份指南汇总了我们应用 AI 团队每天为客户实际执行的诸多最佳实践，希望你觉得它是一份实用且可落地的资源。

回路持续运转。人的判断力凌驾其上。