Anthropic 软件开发生命周期实战手册

本文作者：泊舟（@bozhou_ai）。版权归作者所有，未经授权禁止转载。

代码不再是瓶颈

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

许多工程团队依然保留着原有的审批关卡（approval gates）、评审（reviews）、交接（handoffs）和流程规范，这使得引入类似 Claude Code 这样的 Agentic 编程方案所带来的生产力提升被严重阻滞。

软件开发生命周期（SDLC）是将软件从构想推向生产环境的完整过程。大多数组织都在运行包含 6 个阶段的某种流程版本，涵盖规划（Plan）、设计（Design）、构建（Build）、测试（Test）、部署（Deploy）和维护（Maintain）。传统上，每个阶段都是由不同角色负责的离散环节：产品经理编写需求（PRD），技术架构师将其转化为设计方案，工程师根据设计进行编码实现，受监管企业的 QA 团队进行验证，发布团队负责上线，运维团队负责监控运行状态。工作通过文档、工单（tickets）和审批签字（sign-offs）在各个阶段之间流转。

传统的软件开发生命周期（SDLC）流程非常繁重，以确保每一步的权责明确与严格受控。然而，传统 SDLC 的设计初衷是为了在那个“编写和实现代码是最耗时且最昂贵的阶段”的时代最大化效率——而如今情况已截然不同。PRD、工作量估算仪式（estimation rituals）以及产品安全评审，它们的存在都是为了在长达数周、数月甚至数个季度的开发工作中强行拉齐认知与对齐目标。

传统的 SDLC 控制机制还默认每一步均由人类执行。而那些正在创造最大价值的组织，已经围绕 Agentic AI 当前的能力重构了流程，同时确保人类始终处于监督环路中（Human-in-the-loop）。在本指南中，我们将结合 Anthropic Applied AI 团队在内部以及与客户合作中总结的最佳实践，详细拆解如何在 SDLC 各阶段深度集成 Claude，以加速开发并让流程运转得更快。

当代码不再是瓶颈、构建阶段的速度远超传统 SDLC 的承载能力时，会出现三个显著现实：

瓶颈转移到了构建阶段的左右两侧：主要体现在规划（Plan）、评审/测试（Review/Test）和部署（Deploy），这些环节依然按照人类的速度在运行。
控制机制脱离实际并变得难以维系：当代码全由人手写时，人工逐行 Review 是合理的；但当大部分 Diff 都是由 Agent 编写时，人工逐行审查根本无法跟上节奏。
治理成本上升：因为各种例外情况仍然需要通过每周或每月的会议和委员会来流转审批。

构建已不再是瓶颈——围绕它的“人类速度”步骤才是。人类速度的阶段依然耗时漫长，而构建阶段已被压缩至几小时

以安全瓶颈为例。安全团队的人员规模通常是针对人类产出量来配置的，因此当 Agent 将代码产出成倍放大时，要么导致 Review 队列严重堆积，要么导致未经充分评审的代码直接上线。对于受合规监管的组织来说，这两种结果都无法接受，因此其安全和合规检查必须跟上 Agent 的产出节奏。

为了更好地释放 Agentic AI 的生产力红利并确保安全性，传统 SDLC 流程必须经历与实现阶段同等级别的深度重塑。

什么是 AI 原生 SDLC？

AI 原生 SDLC 是一套重新构想的流程，它将原有的控制目标与全新的执行方式相结合。它不再是线性的单向流水线，而是演变为一个闭环（loop），且 AI 被嵌入到每一个环节之中。AI 原生 SDLC 倡导自动化交接以及对后续打法（plays）的自动触发，从而解决了传统 SDLC 各阶段之间手动且笨重的交接痛点。

上图中的打法（plays）按阶段列出；箭头表示落地实施的推荐顺序。两者并非完全一致。可以从任意浅色（clay）打法开始——没有箭头指向它，说明它不需要前置条件。对于其他打法，指向它的箭头表示在采用它之前需要先落地的依赖打法。

核心范式转变

下表对比了传统 SDLC 与由 Claude 支持的 AI 原生 SDLC 之间的两极光谱。大多数组织目前处于两列之间的某个过渡位置。

贯穿右侧列的核心线索是已提交的工件（committed artifact）。每个阶段的结束都以向版本控制系统提交一个工件为标志（包括 intent.md、spec.md、plan.md、Diff 及其测试用例、包含 Review 发现的 PR 以及故障事故记录），而下一阶段则从读取该工件开始

在早期阶段，.md Markdown 文件是主要的工件形式，因为 Product Owner 和 Agent 都可以读取并基于同一个文件开展工作。从构建（Build）阶段开始，工件转变为代码及其运行记录。这一条 Commit 链条同时也是完整的审计追踪链（audit trail）：谁提出了什么需求、Agent 生成了什么、谁批准了它。

对于每一个需要人类判断力的决策，人类始终承担最终责任。在 Agentic SDLC 的世界里，人类的精力随着需要被评审的工件而发生转移。

每个阶段都会提交下一个阶段可读取的工件。Intent（意图）、Spec（规格）、Plan（方案）、Diff（代码变动）以及 Review Findings（评审意见）共同构成了不可篡改的审计追踪链。

具体实战打法 (Plays)

这些打法（Plays）是本 Playbook 的核心，按 6 个非线性阶段划分（Plan、Design、Build、Test、Deploy、Maintain），共同覆盖了软件的完整生命周期。

每个打法均涵盖：

核心改变（What changes）；
起步准备（Getting started）；
落地实施的具体步骤（Concrete steps for implementation）；
治理与合规考量（Governance considerations）；以及
效果衡量指标（How you measure whether it worked）。

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

一个阶段的结束通过提交工件来实现，而该 Commit 会自动触发下一阶段。一份被接受的 intent.md 触发需求与设计环节；一份获批的 spec.md 触发 Plan 模式；合并的 PR 触发流水线；而生产环境中被突破的控制区间则自动写出下一个 intent.md，如此循环往复。

起初，你可以手动 Prompt 每个步骤；最终状态是一个全自动化闭环——每个被接受的工件都会自动触发下一道门禁。人类的注意力集中在门禁关卡上，重点评审 Agent 标记出的问题，而不是从零开始推敲每个阶段。

图中打法按阶段列出；箭头表示落地实施的推荐顺序。两者并非完全一致。可以从任意浅色打法开始——没有箭头指向它，说明它不需要前置条件。对于其他打法，指向它的箭头表示在采用它之前需要先落地的打法。

规划 (Plan)

构想不再苦苦等待专人去撰写成文。意图（Intent）直接以发起人自己的语言被单次捕获，并作为下一阶段可直接处理的、受版本控制的工件记录下来。

捕获为 intent.md

intent.md 是启动软件开发流程的源头，可以通过不同路径产生：某人产生了一个想法、提交了一个工单（ticket）、或者通过监控告警暴露了一起事故（参见阶段 6：维护）。

当有人产生想法时，他们可以直接与 Claude 进行头脑风暴，生成一份 Markdown 格式的初始原型规格（proto-spec）。在传统 SDLC 中，这个人必须先说服产品团队的成员来协助他们或代表他们把想法写成文档。

Claude 生成的原型规格具有人类可读性、受版本控制，且能立即被下一阶段消费使用。这份原型规格被保存为 intent.md。

无论意图是源自事件触发还是来自 Agent，核心流程一致：Product Owner 在提交入库之前，对 Agent 编写的 intent.md 进行评审和修正。

传统模式：一个想法在能够被落地之前，必须经历 Backlog 条目、User Stories、Story Points 估算以及各种需求梳理会（Refinement）。每次交接所有权都会发生转移，因此最终到达工程团队手中的内容，往往已经与发起人的原意相去甚远。
AI 原生：发起人直接与 Claude 头脑风暴，并将结果记录为 intent.md——一份用发起人自己的术语写成的 proto-spec。该工件包含了想要什么、为什么想要以及在什么约束条件下。重复的流程则通过 Skills 固化。

起步准备

前置条件 (Prerequisites) 无。

基础设施 (Infrastructure) 非工程师团队成员的 Claude 访问权限（claude.ai 或 Cowork）；一套约定好的 intent.md 模板；一个由 Product Owner 关注的、受版本控制的共享 Intent 存放目录/仓库。对于单一产品，最简单的方式是在产品代码仓库中建立一个 intent/ 目录。这种结构能让工件链紧挨着由其派生出的代码。只有当 Intent 跨越多个仓库时，设立专门的 Intent 仓库才有意义；在 Monorepo 中它就是一个子目录。阶段 3：构建（Build）的侧边栏详细介绍了该存放位置如何与已存储记录的 Jira 或需求工具协同。

设置这一基础设施是平台或工程团队的一次性任务。技术团队成员需要搭建 Intent 的存放目录并决定谁拥有写入权限，因为许多贡献者来自全公司的各个部门。

仓库建好后，没有 Git 经验的贡献者无需直接使用 Git。相反，通过版本控制系统（例如 GitHub）的 Connector，Claude 可以直接从 claude.ai 或 Cowork 代表他们提交 Markdown 文件。

如何执行

发起人用自己的语言向 Claude 描述问题。可以描述当前做不到什么、该想法会影响到谁、理想状态是怎样的、或者哪些内容属于范围之外（Out of scope）。不需要使用任何正式的工程术语。
持续头脑风暴，直到想法具体成型。Claude 会像业务分析师一样提问：涉及范围、目标用户、约束条件以及衡量成功的标准。
让 Claude 使用组织的模板将结果输出为 intent.md。该模板可以封装为由技术团队设置并由 Tech Lead 批准的 Skill。内容可涵盖问题定义、预期成果、受影响的用户与系统、约束条件以及待澄清问题（Open questions）。
发起人修正 Claude 理解有偏差的地方。
将 intent.md 提交（Commit）到共享目录中。作者信息和时间戳随之入库，Product Owner 从此接手该想法。

# 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 历史中。Product Owner 进行审批，决定将 Intent 流转到阶段 2：设计（Design）的接受或拒绝决策，会作为 Merge 或 Closed Review 记录在案。

效果衡量

领先指标 (Leading indicator) 从首次对话到提交 intent.md 的耗时（可直接从 Git 历史中的作者和时间戳读取）。预期是从传统数周的需求引出与梳理周期缩短至几小时。

滞后指标 (Lagging indicator) 存活率（Survival rate），即 Product Owner 接受进入阶段 2（设计）而非直接关闭的 intent.md 占比。接受或拒绝决策体现为工件的 Merge 或关闭评审。此外，还包括在同一变更的第一个 spec.md 提交后，对 intent.md 产生的后续修改次数。

设计 (Design)

需求与设计被压缩在单次会话中完成。合规与制度策略在编写 Spec（规格文档）的同时即被注入并生效，而不是在数周后的评审中才被动发现。

需求与设计

一旦获得 Product Owner 批准，Claude 就会基于已接受的 intent.md 生成一份需求与设计规格说明书（Spec）。这由组织在品牌、安全、合规与 UX 方面的 skills 来指导规范。

Product Owner 负责评审该 Spec，但无需亲自撰写。该流程的目标是生成一份工程团队可以直接据此规划的 Spec，并明确标出存在顾虑的区域（Flagged areas of concern）。

前端工作是最直观的例子。一旦 intent.md 获批，Product Owner 即可基于 intent.md 在 Claude Design（Beta）中快速生成原型设计 Mockup，在 Mockup 上反复迭代，然后导出至 Claude Code 进行构建。

传统模式：需求与设计是由不同团队执行的独立阶段。分析师将想法形式化为需求文档，设计师再将其拆解转化为设计方案。这种隔离是为了明确权责，但过程缓慢且信息损耗严重。
AI 原生：两个阶段在单次 Prompt 会话中完成。Claude 接收 intent.md，并在组织 Skills 的约束下生成需求与设计 Spec，同时标出需要重点关注的疑虑点。

起步准备

前置条件 (Prerequisites) 编写好的 intent.md 文件，以及以 Skills 形式沉淀的品牌、安全、合规和 UX 策略。

基础设施 (Infrastructure) 具备 Claude 访问权限的 Product Owner。无需工程编码技能。

如何执行

Product Owner 开启一个会话，加载组织现有的 Skills，并附上 intent.md。
Product Owner 的 Prompt 指向 intent.md，指明约束条件，并要求明确标出存在疑虑或冲突的地方。初期可手动执行，后续可固化为组织级的 Slash Command。进阶做法是将 Intent 目录中 intent.md 的 Merge 设为自动触发器，通过非交互式任务加载组织 Skills 执行这一阶段，并将 spec.md 作为 Pull Request 提交（阶段 5：部署中的 CI/CD 打法涵盖了这一流水线机制）。此时 Product Owner 首次介入便直接进入评审环节。
Product Owner 对照原始想法评审 Spec：Spec 是否解决了陈述的问题？intent.md 中的待澄清问题（Open questions）是已得到解答还是被保留顺延？
优先处理被标记出疑虑的点（Flagged concerns），因为这些正是过去分析师需要向上升级（Escalate）的问题。Product Owner 在工程团队看到 Spec 之前，与对应的策略负责人共同解决这些问题。
将 spec.md 与 intent.md 一并提交。这对文件完整记录了“诉求是什么”以及“决策是什么”。
Product Owner 决定 Spec 和 Intent 是否进入构建阶段；对于组织划分为高风险的内容，需咨询 Tech Lead。人类团队成员始终拥有最终决定权，接受 Spec 即触发阶段 3：构建中的 Plan Mode 打法。

Prompt 示例

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。应用可用的 Skills，确保方案符合我们的品牌指南、安全策略与 UX 标准。将 Spec 完整记录为 spec.md，以便直接交付给工程团队。清晰描述所有存在疑虑的区域，特别是无法同时满足互相冲突的策略之处。）

治理与合规考量

不再是在数周后的评审中才发现合规问题，而是在编写 Spec 的过程中直接读取并应用最新策略。组织的 Skills 被作为硬性约束施加在 Spec 上。Spec、生成它的 Prompt 以及生效的 Skill 版本全部记录在版本控制系统中。Product Owner 签署批准 Spec，并将标记出的问题分发给指定的策略负责人。

效果衡量

领先指标 (Leading indicator) 同一变更从 intent.md 提交到 spec.md 提交的间隔时间（Git 两个时间戳对比），与过去“需求+设计”传统周期的耗时对比。

滞后指标 (Lagging indicator) 进入构建阶段后的需求返工量。统计在同一变更的第一个 plan.md 提交之后打上时间戳的 spec.md 提交次数（直接通过 Git Log 统计）。

构建 (Build)

未经批准的方案绝不付诸实现。组织机构的隐性知识沉淀为 Agent 可读取的文件，防护栏（Guardrails）作为代码运行，而非依赖个人习惯。

将 Claude Code 的 Plan 模式作为默认起点

工程师在 plan mode（计划模式）下启动 Claude Code 会话，向 Claude 提供阶段 2（设计）中获批的 spec.md，让 Claude 对工程师进行提问式访谈，不断迭代推敲方案，直到工程师对方案完全满意。

传统模式：工程师阅读设计文档后便开始写代码。具体如何实现（具体改哪些文件、写哪些测试）全在工程师大脑中，或者最多体现在工单的一条评论里。其他人无法提前 Review。评审人员看到的第一件产物就是最终完成的 Diff，到了那时返工成本极其高昂。
AI 原生：工作始于 Claude 在 Plan Mode 下生成的书面方案。在此模式下，Claude 可以读取代码库但不能修改任何文件。工程师在编写代码前对方案进行纠偏，获批的版本提交为 plan.md，供后续阶段对照检查。

起步准备

前置条件 (Prerequisites) Intent 工件（若有 intent.md 或 spec.md），若有 CLAUDE.md 文件则更好。

基础设施 (Infrastructure) 具备仓库访问权限的 Claude Code。

如何执行

工程师与 Claude 在 Plan Mode 下启动会话。
工程师向 Claude 提供 intent.md 和 spec.md，要求生成一份实现计划（Implementation Plan），明确指出需要修改的文件、工作顺序以及证明实现正确的测试用例。
深入质询方案：询问该变更可能会破坏什么、哪个步骤风险最高、Claude 权衡后放弃了哪些备选方案。
持续迭代，直到从未参与过对话的另一位工程师仅凭该方案就能独立实现该变更为止。
将批准的方案提交为 plan.md。该方案进入审计追踪链，PR Review 打法（阶段 5：部署）将对照此方案检查最终的 Diff。
接受方案并让 Claude 开始实现。有了扎实的方案，实现过程通常可以一气呵成（Single pass）。
当实际实现偏离了方案时，在同一个 Commit 中同步更新 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 无法编辑任何文件。方案及其修订历史、谁批准的均被完整记录。常规变更由工程师审批，组织界定为高风险的变更则由 Tech Lead 或架构师审批。

效果衡量

领先指标 (Leading indicator) 首次实现即可直接 Merge 的变更占比，以及从方案批准到 PR 合并的耗时（通过 PR 元数据获取）。

滞后指标 (Lagging indicator) 每次变更的返工迭代轮数（同样源自 PR 元数据），以及合并后的 Diff 与已提交的 plan.md 保持一致的频率。

Claude Code 的 Auto 模式

Claude Code 还可以在 Auto 模式下运行。在此模式下，工程师批准方案后，一旦满意且完成迭代，Claude 会自动应用每处修改，而无需每次编辑都弹出提示确认。随着后续打法中防护栏的成熟（调优后的 CLAUDE.md、编码了策略的 Skills、拦截不安全操作的 Hooks，以及 Claude 可自行运行的测试套件），对于常规任务（明确严谨的 spec.md、影响半径小、且测试已覆盖的代码），Auto-accept（自动接受）将成为默认模式。

这种转变使得用户不再需要盯着 Agent 一步步编辑并逐个确认操作，而是转向在更长时间的自主会话结束后直接评审交付的工件。Auto-accept 模式结合 Git Worktrees 进一步释放了个人与团队的并行能力，并且是实现 SDLC 自主运行并在阶段 6（维护）中形成闭环的基础。

侧边栏：遗留系统与单一事实源

适用于流程产生的所有工件。

现有的 SDLC 流程可能已经在跟踪各种工件，只是没有以 Markdown 文件的形式呈现。工作项可能在 Jira 中，需求在内置监管可追溯性的专用工具中，设计在 Figma 中，变更审批在变更委员会中。这些系统很难被完全替换，因为审计人员和监管机构已经认可它们，其他团队也依赖它们，因此 AI 原生 SDLC 必须与现有系统良好契合。

在向 AI 原生 SDLC 转型时，针对流程产生的每一个工件，指定一个系统作为单一事实源（Source of Truth），其他系统只保留副本或指向原始记录的链接。可采用以下几种事实源配置方式（不同工件可采用不同选择）：

以代码仓库为单一事实源 (The repo as the source of truth)：Markdown 工件是权威记录，遗留系统引用 Commit 中的文件。对于以研发为主导的组织，这是最清晰清爽的配置之一，因为所有记录都存在于同一个工具中，具备统一的时间戳权威。
以遗留系统为单一事实源 (The legacy system as the source of truth)：Jira、ServiceNow 或需求工具保存权威记录，Markdown 工件作为工作副本。Claude 在会话开始时读取记录，并在产出 Spec 或 Plan 的同一个会话中通过 MCP Connector 将结果写回遗留系统。
以双向链接作为最低标准 (Linkage as the minimum bar)：所有工件均注明遗留系统记录 ID，所有遗留记录均包含 Markdown 文件的 Commit SHA。在向 AI 原生 SDLC 过渡初期，承认存在两个事实源的前提下，双向链接是一个很好的切入点。

只要两者之间建立了链接，或者明确声明了其中一个是单一事实源，遗留系统与以 Markdown 为核心的系统完全可以和谐共存。

CLAUDE.md (项目知识文件)

CLAUDE.md 为 Claude 提供新入职员工所需了解的上下文，涵盖代码规范、常用命令、架构设计以及团队最常遇到的踩坑点。过去散落在员工脑中和内部 Wiki 中的知识，变成了 Agent 在每次会话开始时都会读取的文件，由全团队共同维护，并在每次犯错时持续迭代。

起步准备

前置条件 (Prerequisites) 无。

基础设施 (Infrastructure) 一个代码仓库、安装好的 Claude Code，以及一名熟悉代码库的工程师。

如何执行

在仓库根目录运行 /init。Claude 会根据扫描到的内容生成初始的 CLAUDE.md。
将生成的文件精简压缩为新员工入职第一天必须知道的内容：保留构建、测试和 Lint 命令、核心约定规范以及 Claude 经常搞错的事项。
将 CLAUDE.md 提交到 Git 仓库根目录，以便全团队共享统一版本，其变更也能像代码一样进行 Review。
建立一条实用规则：当 Claude 犯了两次同样的错误时，纠错规则必须写入 CLAUDE.md。
篇幅保持在一页以内，因为 Claude 在每次会话开始时都会完整读取该文件，陈旧过时的内容只会白白消耗 Context 窗口而没有任何好处。

配置示例 (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 纳入版本控制，因此 Agent 遵循的指令是可评审且可审计的。团队约定通过该文件落地，历史变更记录在 Git 中，Code Owner 在 PR Review 时对其变更进行审批。

效果衡量

领先指标 (Leading indicator) Claude 重复犯下本应被 CLAUDE.md 拦截的错误的频率（通过 Git 历史追踪对 CLAUDE.md 的修改与纠偏记录）。

滞后指标 (Lagging indicator) 新团队成员从入职到合并首个 PR 的平均时间（源自 PR 历史）。

将 Skills 作为组织机构知识

Skills（技能）是组织将机构知识转化为可操作执行力的方式。其指令明确、受版本控制、广泛应用，并在制度策略发生变化时能够集中统一更新。经验法则：对于必须被一致执行的机构知识，编写 Skill；对于属于 CLAUDE.md 或单次 Prompt 的内容，不要写成 Skill。

起步准备

前置条件 (Prerequisites) 无强依赖。配置有 CLAUDE.md 会有帮助，但 Skill 不依赖它。

基础设施 (Infrastructure) 具备明确负责人（Owner）和书面单一事实源的一套制度规范。

如何执行

挑出一项当前执行不够一致的知识规范，例如安全标准、API 设计规范或品牌规范。
将其编写为一个 Skill——包含 SKILL.md 的文件夹，其 Frontmatter 声明何时触发，正文描述具体如何操作。由工程师在 Claude 协助下根据策略负责人的事实源进行编写。
将 Skill 放入仓库中的 .claude/skills/<name>/ 目录下随代码一同发布，或者通过 Plugin 在全组织范围内分发。
测试 Skill 的触发效果：让 Claude 用不同方式执行相关任务，确认每次都能正确加载该 Skill。
当策略更新时，修改 Skill 并由策略负责人签署确认。
工程师在下次会话中将自动加载最新版本。

Skill 示例 (.claude/skills/secure-api-review/SKILL.md)
---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

When you create or change an API endpoint:
1. Authentication: every endpoint requires the gateway JWT;
   no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI
   schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with
   actor, action, entity and timestamp.
4. Data classification: fields tagged pii in the schema must never
   appear in logs or error messages.

Run scripts/check-endpoints.sh and include its output in your summary.

治理与合规考量

Skill 属于建议性控制机制（Advisory control）。它让 Claude 在编写代码时极大概率遵循该策略，但并不能在底层强制每次会话都必须合规。对于必须 100% 严格执行的策略，需要在 Skill 背后配备确定性机制（Deterministic layer），例如拦截操作的 Hook 或在 PR 阶段重新校验策略的 Review 流程。Skill 能够大幅降低违规发生率，而 Hook 则让违规几乎不可能发生。Skill 的调用会记录在会话 Trace 中，策略负责人像审查代码一样审查 Skill 的变更。

效果衡量

领先指标 (Leading indicator) 从策略负责人批准策略变更到更新后的 Skill 完成 Merge 的耗时（从 Skill 文件夹的 PR 获取）。

滞后指标 (Lagging indicator) PR Review 中引用该策略的缺陷发现数量。一旦 Skill 能够在编码过程中即时应用策略，该数值应趋近于零；若未下降，说明 Skill 没有被正确触发，或者其描述已与官方策略产生偏差。

作为构建时防护栏的 Hooks

Skill 是建议性控制，而 Hook 是其背后的确定性执行层。在实现过程中，Claude 的大部分操作都是文件编辑和 Shell 命令，因此构建阶段是 Hooks 触发最频繁的地方。

构建阶段的 Hooks 可以：

拦截对受保护路径的编辑（如自动生成的类或已冻结的 Legacy 包）；
在文件编辑后自动运行 Formatter 和 Linter，防止代码风格漂移累积；
防止密钥凭据被提交进 Diff 中。

为任何必须无条件执行的策略配备 Hook。Hook 会在每次匹配的操作上触发，因此构建阶段的 Hooks 必须轻量快速，且限定在发生变更的文件范围内。更重的检查（如全量测试套件）应放在 Commit 或 PR 阶段。

需要人类批准的 Hook 属于阶段 5：部署中的门禁，因为在构建过程中弹出人工审批提示会让工程师重新成为所有并行会话的关键路径瓶颈。

并行会话与 Subagents

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

并行会话（Parallel session）是另一个独立的 Claude Code 完整实例，在各自的 git worktree 中处理单独的任务。每个独立会话彼此完全隔离，唯一共享的只有把控全局的工程师。

Subagent（子 Agent）运行在单个会话内部，作为具备独立上下文窗口和工具限制的作用域辅助工具，适合在多个任务中反复出现的重复性工作，例如验证应用是否按预期运行。

并行会话提升了一名工程师可同时处理的任务数量，而 Subagents 则保证了每个会话专注于自身的任务。工程师的核心职责是统筹把控与评审所有这些会话。

传统模式：一名工程师一次只能处理一项任务，并把一天或一周中相当大的一部分时间花在等待构建、跑测试和等评审上。虽然可以在等待时切换任务，但 Context 切换成本极高，以至于很少有人愿意这么做。
AI 原生：一名工程师可以同时运行多个 Claude 会话，每个会话在各自的 Worktree 中执行单独的任务。重复性工作沉淀为具备独立 Context 和工具限制的 Subagents。工程师的角色转变为任务编排，并最终演变为构建和监控自主闭环。

起步准备

前置条件 (Prerequisites) CLAUDE.md（所有会话都会读取该文件）。阶段 4（测试）中的反馈闭环也很有帮助，因为当会话能够自行验证工作时，所需的工程师监督就会大幅减少。

基础设施 (Infrastructure) Git 仓库（隔离依赖 Worktrees 实现），以及经过调优的权限配置，避免会话在执行组织认可的安全命令时频繁等待审批提示。

如何执行

工程师将工作拆分为涉及不同文件的独立任务，参考 Plan Mode 产出的方案判断哪些工作相互独立。涉及相同文件的任务在单个会话中按顺序串行执行。
每个并行任务分配一个独立的 Worktree，例如在一个终端中运行 claude --worktree feature-auth，在另一个终端中运行 claude --worktree fix-rate-limit。Worktree 是独立分支上的独立检出目录，能防止多个会话在文件上发生冲突。
建议以 2 到 3 个并行会话作为合理的起步点。实际的上限取决于一个人能够保质保量评审多少条工作流，因此仅在评审能力跟得上的前提下增加会话。
将重复性工作沉淀为 Subagents（定义在 .claude/agents/ 的 Markdown 文件中），每个 Agent 包含名称、使用场景描述以及允许使用的工具。例如：在主 Agent 完成后剔除冗余复杂度的代码精简 Agent（code simplifier）、运行应用并检查行为的验证 Agent（verifier）、探索代码库并汇报总结而不污染主 Context 的研究 Agent（researcher）。将这些定义提交到 Git 中供全团队共享。

Subagent 示例 (.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 和权限设置对所有会话生效，会话的每项操作均有日志记录，并归属到运行该会话的工程师名下。

效果衡量

领先指标 (Leading indicator) 在保证评审质量的前提下，单工程师并发运行的会话数（通过 OpenTelemetry 导出数据统计），以及一天中用于把控指导而非苦等的时间占比。

滞后指标 (Lagging indicator) 根据 PR 历史统计的单工程师每周合并变更数，并结合返工率综合评估。

测试 (Test)

在人类介入查看之前，每个会话都会先自行检验工作成果；指导 Agent 的配置也会像它编写的代码一样接受回归测试。

为 Claude 提供反馈闭环

务必始终为 Claude 提供验证自身工作的方式——无论是自动化测试、构建指令还是截图 Diff。让会话在工程师看到结果之前，自行检查工作并修正自身错误。

反馈闭环（Feedback loop）不应与 Verifier Subagent（阶段 3：构建）混淆。反馈闭环贯穿整个任务过程，随工作执行多次反复运行；而 Verifier Subagent 则是封装最终验收的一种方式——在会话认为工作已完成时，启动一个全新的干净上下文窗口进行独立验证，这样验收结论就不会受到当初生成代码时的假设偏见所干扰。

传统模式：验证代码是否正常工作的信号往往来得很迟：CI 反馈需要数分钟，测试人员反馈需要数天，生产环境暴露需要数周。当由 Agent 产出代码时，迟缓的反馈信号意味着人类必须亲自检查所有输出，人类随之沦为瓶颈。
AI 原生：在人类查看之前，会话就已经具备了自检自纠的能力：运行测试、执行构建、截取屏幕快照。Claude 会持续迭代直至检查全部通过，因此最终呈现在工程师面前的内容早已通过了这些验证。搭建该闭环是运行会话的工程师的职责，以下步骤即为此而设计。

起步准备

前置条件 (Prerequisites) 无。

基础设施 (Infrastructure) 能够通过单条命令在本地运行的测试套件与构建脚本。对于 UI 工作，为 Claude 提供查看渲染结果的途径至关重要（通过浏览器工具或经由 MCP 接入的截图工具）。

如何执行

如果当前验证工作需要一连串命令和特定的环境知识，将其封装为单一目标（如 make test 或 npm test），失败时返回非零退出码（non-zero exit code）。
在 CLAUDE.md 的 Commands 章节中列出每个命令，并附上健康运行输出的示例。
明确设定量化目标，以便 Claude 无需向你询问即可自行检验，例如：“test_status.py 中的所有测试全部通过”、“截图与附带的 UI Mockup 一致”、或“该端点携带新字段返回 200”。
对于 Bug 修复任务，先写出能够复现该 Bug 的失败测试（Failing test）。要求 Claude 以测试的形式复现 Bug，运行并确认其失败原因符合预期。提交该测试。只有在这之后，才要求 Claude 在不修改该测试文件的前提下修复代码使其通过，并通过最后一步的测试文件保护 Hook 强制执行此限制。一个在修复前就已存在、且 Agent 无法篡改的测试用例，才是证明 Bug 彻底被修复的铁证。
对于 UI 工作，通过视觉检查闭环。为 Claude 配备浏览器或截图工具，提供设计 Mockup，让其反复迭代：实现 → 截图 → 对比 → 微调。通常 2 到 3 轮是正常的，且每一轮结果都会明显改善。
将验证纳入“Done（完成）”的定义。在 CLAUDE.md 中写明指令：在报告任务完成之前必须运行测试并展示输出。
最后，闭环本身需要保护：正在修复代码的 Agent 绝不能被允许削弱对该代码的校验标准。通过 Hook 在 Bug 修复任务期间拦截对测试文件的编辑即可做到这一点；另一种备选方案是在 PR Review 时检查 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.

治理与合规考量

强制执行机制 (What is enforced)：在任务报告完成前必须进行验证，并在修复期间禁止 Agent 编辑测试文件；当组织需要确保持续生效时，均通过 Hooks 强制执行。
证据形式 (What the evidence is)：make test 的真实终端输出、构建日志或 Claude 运行并贴出的截图 Diff，证据直接源自工具链。
记录位置 (Where it is logged)：记录在会话 Transcript 中（通过 OpenTelemetry 导出转发至组织的可观测性系统），并体现在 PR 的 Check run 中，供评审人员和后续审计人员查验。
审批责任人 (Who approves)：负责 Review PR 的 Code Owner。由于机械性的验证证据已自动附上，评审人员可以专注于评估意图与风险。

效果衡量

领先指标 (Leading indicator) Agent 编写变更的首次 CI 通过率（First-pass CI success rate），CI 系统原生支持此指标。

滞后指标 (Lagging indicator) 单 PR 评审耗时（源自 PR 元数据，当测试替评审人员拦截了大部分基础问题后，该指标应显著下降），以及事故追踪器中记录的变更失败率（Change failure rate）。

CI 中的持续评测 (Continuous evals)

评测（Evals）是阶段门禁式 QA（Stage-gate QA）在 AI 原生时代的对等物。在实践中，它指的是一套每当 Agent 配置发生变动时就会自动触发运行的评测套件。当更换新模型或重写 Prompt 时，Eval 套件能够明确指出 Agent 是否仍能按照相同的标准完成工作。

Evals 应被视为一套动态演进的活套件。随着模型能力提升，曾经具有辨别力的测试用例会逐渐失去区分度，必须不断补充来自日常持续监控中发现的新用例。

根据不同场景，部分团队可能更倾向于按固定周期离线运行这些 Evals，而非在每次变更时都触发。以下步骤针对的是持续评测（Continuous evaluations）流程。

起步准备

前置条件 (Prerequisites) CLAUDE.md 与反馈闭环（阶段 4：测试）。

基础设施 (Infrastructure) 能够以非交互方式运行 Claude Code 的 CI 环境，以及具备 Eval 运行额度的 API Key。

如何执行

平台工程师从近期的实际工作中收集 20 到 50 个真实任务及其预期/接受的成果。
将每个任务编写为一个 Eval，即 Prompt 加上定义“可接受”的校验规则（测试通过、Lint 无告警、行为未变、策略已遵循）。
该套件在 CI 中定期定时运行，并且在 CLAUDE.md、Skills 或 Hooks 发生任何变动时自动触发，因为这些配置直接指导 Agent，理应像代码一样接受回归测试。
将评测结果设为配置变更的合并门禁：导致通过率下降的 Skill 变更在合并前必须经过严格审查。
每一个生产事故都应由负责该事故的团队编写对应的 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 提供了能够跟上 Agent 产出节奏的自动化门禁。通过率阈值作为合并检查（Merge check）强制执行，运行记录被完整保存以便跨周期比对，拥有配置变更所有权的团队负责最终审批。

效果衡量

领先指标 (Leading indicator) 随着时间推移的 Eval 通过率趋势（每次运行自动汇报），以及生产事故转化为永久 Eval 用例所需的平均时长。

滞后指标 (Lagging indicator) 在 CI 中拦截的回归缺陷数量与生产环境中暴露的回归缺陷数量对比（通过事故追踪器获取）。

部署 (Deploy)

评审双向进行，治理在 Agent 执行动作时即时生效。Agent 负责完成直至生产门禁之前的所有工作，但绝不越雷池一步。

PR 评审闭环中的 AI

Claude 既能给出评审，也能接受评审。它根据组织策略对提交的 PR 进行审查，并能够自动响应并修复针对其自身 PR 提出的 Review 意见。这使得工程师在 PR Review 时可以把注意力完全聚焦在业务行为上——即判断真实意图与潜在风险。

传统模式：评审吞吐量过去完全围绕人类产出进行规划。一个 PR 需要等待评审人员完整读完，评审质量随评审人的工作负荷大幅波动，作者在不断催促中眼看着 Backlog 越堆越高。
AI 原生：所有 PR 都会经过一套完全一致的 Review Pass，审查发现按严重级别排序。人类的注意力上升到了更高维度：该变更是否符合方案预期？风险是否在可接受范围内？

起步准备

前置条件 (Prerequisites) 阶段 3（构建）中更新后的 CLAUDE.md 文件；若评审流程需要强制执行书面制度，则需准备好对应的 Skills 和定义好的 Subagents。

基础设施 (Infrastructure) 安装了 Claude 集成的仓库：可以是由管理员启用的托管版 Code Review（Research preview）服务，也可以是在自有 CI 中运行的 claude-code-action（必要时模型调用可通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 进行，详见 CI/CD 部署选项）。同时建议配置要求 Code Owner 批准的分支保护策略。

如何执行

托管的 Code Review 服务是启动最快的方式，管理员启用并选择仓库即可。当需要完全掌控流水线或希望 API 调用走自有云服务商协议时，可在自己的 CI 中通过 claude-code-action 运行 Review（CI/CD 打法涵盖了相关配置）。
Tech Lead 在仓库根目录编写 REVIEW.md 作为评审策略，划分为组织关心的几个 Pass 维度：Bug 与逻辑错误；安全与漏洞；针对需求规格（spec.md）、实现方案（plan.md）和设计原则的合规性。REVIEW.md 还需明确定义什么属于 Important（重要），什么属于 Nit（小挑刺），以及应该跳过哪些内容。
Tech Lead 设定人类审批阈值。审查发现本身不会直接通过或拦截 PR，分支保护（Branch protection）仍然要求 Code Owner 的人工批准。如果平台工程师希望根据审查发现自动拦截合并，可以读取 Check run 输出的机器可读严重级别计数。
当评审人员或作者在 Review 评论中 @claude 时，Claude 会处理该评论并推送修复代码。PR 讨论流完整记录了诉求与修改。该修复闭环通过 claude-code-action 运行；在托管服务中，评论 @claude review 则会触发一次全新 Review。对于由 Claude 提起的 PR，还可以进一步让 Claude 全程照料 PR 直至合并——团队将其封装为自定义 Slash Command，自动清理 PR 上未解决的 Review 评论和失败的 Check runs，逐一处理并推送修复，直到 PR 全部变绿、仅等待 Code Owner 最终批准。
Review 发现反哺 CLAUDE.md。当 Review 第二次指出某个错误时，纠正规则直接作为该次 Review 的一部分写入 CLAUDE.md；由于后续 Review 会读取 CLAUDE.md，该错误将在以后的 PR 中被提前规避。Review 还会标记出代码变更导致 CLAUDE.md 内容过时的情况。
Tech Lead 每月对审查发现进行打分调优，使 Reviewer 持续进化，并在 REVIEW.md 中对 Nit 数量设置上限。排除 src/gen/ 等生成路径以及 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.

治理与合规考量

职责分离原则（Separation of duties）得到严格保留，因为编写代码的 Agent 没有任何途径批准自己的代码。REVIEW.md 中的评审策略应用于所有 PR，所有的发现、修复、评分与审批均完整记录在 PR 历史中，因此 PR 本身就是审计记录。最终批准来自人类通过分支保护进行的授权，且这一决策基于充分的审查发现支撑。

效果衡量

领先指标 (Leading indicator) 获得首次 Review 的响应时间（预期降至几分钟），以及在无需人类直接修改分支的情况下解决 Review 评论的比例（数据直接沉淀在 Git 中）。

滞后指标 (Lagging indicator) 合并前拦截的缺陷和漏洞数量与逃逸到生产环境中的缺陷漏洞数量对比（通过 PR 历史与事故追踪器获取）。

作为审批门禁的 Hooks

构建阶段使用 Hooks 作为防护栏，在无需人类介入的情况下放行或拦截操作（阶段 3：构建）。Hook 同样可以发起询问（Ask），暂停当前操作直到指定人员批准——这正是发布门禁（Release gating）所需要的。

该打法放在阶段 5（部署）是因为发布门禁是最典型的场景，但 Hooks 绝不仅限于部署：它们可以在 Claude 执行操作的任何地方运行。例如，Hooks 可以在阶段 3（构建）中拦截在没有变更工单的情况下对数据库迁移脚本和基础设施代码的编辑；在阶段 4（测试）的 Bug 修复任务中阻止 Agent 编辑测试文件。

起步准备

前置条件 (Prerequisites) 无。

基础设施 (Infrastructure) 一份梳理清晰的变更流程所需审批项清单。

如何执行

工程领导层与变更管理和合规团队共同梳理出必须保留的人工审批门禁（如变更管理签字、发布授权、对受保护路径的编辑等）。
平台工程师将每个门禁编写为一个 Hook——在 Claude 执行操作前运行的脚本，可返回 allow（允许）、ask（询问）或 block（拦截）。
团队级 Hooks 存放在 Git 仓库的 .claude/settings.json 中；不可协商的强制性 Hooks 存放在平台或 IT 管理员拥有的受管配置（Managed settings）中，单个工程师无法将其关闭。
拦截应当具备自解释性：当 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
# 生产环境部署需要指定人员的发布授权
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 # 退出码 2 会拦截操作；提示信息将返回给 Claude
   fi
fi
exit 0

治理与合规考量

Hooks 即为审批门禁。门禁条件对所有人每次操作都无差别强制执行。放行与拦截决策均带有时间戳日志。门禁同时定义了何种凭据构成有效批准——无论是获批的变更工单，还是发布经理（Release Manager）的明确签字。

实战案例：受监管企业的托管配置

由平台团队通过 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：防止密钥凭据进入 Agent 上下文，并阻止通过工具发起的任意网络外联；permissions.allow：预先批准安全的内部循环命令，避免频繁的权限弹窗导致工程师产生确认疲劳（Prompt fatigue）。
disableBypassPermissionsMode 配合 allowManagedPermissionRulesOnly：确保任何工程师、项目文件或命令行参数都无法擅自放宽规则。
sandbox：弥补权限层无法覆盖的安全缝隙。工具层对 WebFetch 的拒绝并不能阻止 Shell 命令访问网络；而操作系统级的域名白名单能够从底层彻底阻断未经授权的网络外联。
failIfUnavailable 与 allowUnsandboxedCommands：将沙箱本身变成一道刚性门禁：当沙箱初始化失败时 Claude Code 拒绝启动，且在沙箱内执行失败的命令绝不允许在沙箱外重试。
credentials：封堵 Deny 规则遗留的缺口。permissions.deny 管控 Claude 的文件工具，但默认情况下沙箱内的 Shell 命令仍可能读取 ~/.ssh 或 ~/.aws/credentials；该配置块彻底拒绝这些读取，并从每个沙箱命令的环境变量中剥离指定的敏感密钥。
allowManagedHooksOnly：确保本打法中定义的审批门禁是唯一运行的 Hooks；本地配置无法追加或替换它们。
disableSideloadFlags 与 strictKnownMarketplaces：确保工程师机器上的每个 Skill、Agent、Hook 和 MCP Server 均来自组织官方批准的插件市场，绝不能从个人 Home 目录随意侧载。
allowManagedMcpServersOnly：将 Agent 的工具暴露面收敛为平台团队统一把控的白名单。
requiredMinimumVersion：禁止在低于批准底线版本的客户端上启动，确保所有安全控制均由经过组织实际评估过的构建版本来执行。

以上配置应作为量身定制的参考起点，而非生搬硬套的模版。每一项 Deny 规则都是在能力与限制之间做权衡，恰当的平衡点取决于代码仓库的数据敏感级别。更多设置项详见官方参考文档：code.claude.com/docs/en/settings

效果衡量 (针对 Hooks 本身)

领先指标 (Leading indicator) 在各个审批门禁上的等待耗时。每个 Hook 决策都会写入 OpenTelemetry 导出日志中（附带时间戳以及 Allow 或 Block 判定），因此可以清晰观测每个门禁的等待时长。

滞后指标 (Lagging indicator) 引入 Hooks 前后突破门禁逃逸至生产环境的违规事件数量对比（源自事故追踪器）。

CI/CD 集成与部署

在 CI/CD 流水线中以非交互方式运行 Claude Code，对执行环境进行沙箱隔离以确保长时间运行的 Agent 安全可靠，通过 MCP 集成暴露部署能力，并在 Agent 实际使用之前充分演练回滚路径。

传统模式：流水线只运行确定性的脚本，任何需要主观判断的步骤都必须等待人工介入。例如：排查不稳定的 Flaky 测试、编写发布更新日志（Changelog）、或分析构建失败的原因。部署与回滚全凭运维人员在高压下对照操作手册（Runbook）手动执行。
AI 原生：Claude 以非交互方式嵌入流水线中处理各类判断型步骤，运行在配备受限凭据的隔离沙箱中。部署工具通过 MCP 暴露给 Agent，使得编写和测试代码的工作流能够直接完成上线与回滚，且完全限定在组织为各环境设定的门禁规则之内。

起步准备

前置条件 (Prerequisites) 在 PR Review 闭环中引入 Claude，并将 Hooks 作为审批门禁；因为在自动化加速推进之前，门禁机制必须先行确立。

基础设施 (Infrastructure) 安装了 claude-code-action 的 CI 平台，或任何能够调用 claude -p 的 Runner；通过 API 访问模型，或在流量必须留在自有云协议内时通过 Bedrock、Foundry 或 Vertex 接入；针对部署目标的 MCP Servers；针对 Agent 任务的沙箱 Profile，默认不持有常驻生产凭据。

如何执行

平台工程师从只读的判断类步骤切入。在流水线任务中使用 claude -p 来诊断失败的构建、总结偶发不稳定的测试（Flaky test）或起草 Release Changelog。
在现有门禁后增加写入步骤，用于自动修复 Lint、更新生成的文档、或通过 @claude 提及处理 Review 评论。Agent 写入的所有内容都必须通过分支保护以 PR 形式提交，Agent 没有任何直接 Push 到 main 分支的途径。
沙箱化执行。Agent 任务在具有网络策略限制的容器中运行，配备短期作用域 Token，默认不持有生产环境凭据。
通过 MCP 暴露部署能力。部署、状态查询和回滚均封装为工具，按环境划分作用域，使 Agent 的部署权限成为白名单机制，而非直接持有凭据的 Shell 脚本。
按环境划分自主权等级。在 Dev 环境中，Agent 可自由部署；在 Production 环境中，Agent 准备发布包，由 Release Manager 授权，并通过 Hook 强制执行生产门禁；Staging 环境介于两者之间。
回滚（Rollback）应当是流水线中演练最充分的路径——一条 Agent 可以直接执行的单条命令，并在 Staging 环境中定期演练。阶段 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

治理与合规考量

核心治理原则是：Agent 可以执行直至生产门禁之前的所有动作，但绝不能越过该门禁。以下控制措施用于捍卫该原则：

分支保护将 Agent 编写的所有内容强制转换为 PR，杜绝直接向 main 分支推送的途径。
生产部署 Hook 会拦截发布操作，直至指定的 Release Manager 正式授权。每次非交互式运行均以 Agent 自身身份执行，流水线日志能够清晰区分哪些是 Agent 做的、哪些是触发它的工程师做的。
基于环境的权限分级机制严格限定了 Agent 在抵达门禁前允许执行的操作范围。

效果衡量

领先指标 (Leading indicator) 无需呼叫人工（Paging a human）即可完成排查的流水线故障比例（从 CI/CD 流水线日志中提取）。

滞后指标 (Lagging indicator) DevOps 研发效能与评估（DORA）指标，CI 系统与部署工具已原生输出该数据。

维护 (Maintain)

闭环正式合拢。触发器直接唤醒 Claude，调用路径中无需人类介入；Claude 的诊断发现作为 intent.md 重新进入研发流水线。

维护与形成闭环

到目前为止，我们探讨了如何在 SDLC 的各个阶段引入 Claude，每个阶段仍需要人类来启动初始步骤。然而，本阶段将焦点转移到了 Claude 的自主运行上，以彻底闭合整个循环。

例如，一个持续运行的监控 Agent 可以在创建 Bug 工单时自动生成 intent.md，并自主流转过需求、方案、构建、测试和评审各阶段。阶段 6：维护以无头模式（Headless）运行，阶段之间设有独立的置信度门禁（Confidence gate）——确定性检查或对抗性评审 Agent——决定前一阶段的产出是继续向下流转还是升级上报给人类。

传统模式：维护属于被动响应阶段。所有的工单或事故都必须苦等人员介入来重启流程。凌晨 3 点触发的告警可能会被遗漏；工单可能会一直躺在 Backlog 里直到有人认领；如果有更紧急的问题出现，事故复盘（Post-mortem）的跟进动作甚至根本无法落地到代码库中。
AI 原生：诸如控制区间被突破、新工单创建、协作频道消息或定时调度等触发器，可以直接唤醒 Claude 而无需人工介入。Claude 负责诊断，仅通过受门禁管控的途径采取行动，并将分析结果记录为 intent.md，随后进入上述各阶段流转。人类负责对该工作进行分诊（Triage）和审查，而不再需要从头手动发起。

闭合循环 (Closing the loop)

确定性脚本实时监控生产环境，并在突破控制区间（Control band）时唤醒 Claude。监控异常突破是自主闭环运行模式的一个典型示例，而本阶段末尾的 Claude Tag（Public beta）部分则涵盖了通过不同协作渠道流入的工作。

起步准备

前置条件 (Prerequisites) intent.md（为闭环重启提供结构化输出载体）；Claude 加速的 PR Reviews；作为行动边界的 Hooks；以及 CI/CD 中的回滚路径（最高自主权等级会调用该路径）。

基础设施 (Infrastructure) 检测脚本可查询的指标存储库（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 服务）。由于运行是无状态且非交互式的，闭环可以在没有任何人手动触发的情况下自主启动并结束。
Agent 将诊断结果按照阶段 1（规划）的格式输出为 intent.md，涵盖异常现象及其证据、建议的处理目标、受影响系统及待明确问题。随后该发现便像普通需求一样进入流水线流转。
服务负责人或值班工程师对队列进行分诊（Triage），将面向产品的发现路由给 Product Owner：立即修复、排期处理或直接忽略。忽略操作有助于微调控制区间并降低噪音。
当修复上线后，为该事故补充一条 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 Review 门禁，且 Agent 允许触发的 Runbooks 必须是提前获得审批的。

效果衡量

领先指标 (Leading indicator) 从控制区间被突破到 intent.md 进入分诊队列的耗时（与过去从事故发生到采取复盘行动的耗时进行对比）。检测脚本的日志完整记录了突破时间戳和事故等级。

滞后指标 (Lagging indicator) 转化为已合并修复的发现占比（分诊队列对比实际 PR 历史），以及同类事故的重复发生率（随着修复将新用例沉淀进 Eval 套件，该指标应当持续走低）。

案例示例

当 CI 测试失败率突破 3σ 时，Agent 自动隔离该 Flaky 测试或提起 Revert PR，由 Review 门禁做出最终决定。
当发布后 5xx 错误率在发布窗口期内突破 3σ 时，Agent 自动触发既有的回滚流水线。
当 PR 交付周期触发漂移规则时，Agent 自动为工程管理层生成分析报告，证明该自动化脚手架既适用于生产指标，也同样适用于流程研发效能指标。

检测过程保持绝对确定性。一旦控制区间被突破即唤醒 Claude，而响应等级严格限定了其允许采取的行动范围。

基于 Claude Tag 实现 Claude 值班

事故也可能通过其他渠道流入，例如 Slack 或 Teams 等工作区即时沟通工具。比如晚上 10 点在事故频道中发出的紧急修复求助，现在可以被立即响应处理。Claude Tag（目前在 Slack 开启公开测试）让 Claude 以独立身份成为这些频道的成员，使每个新事故都能获得第一响应人（First responder），且响应过程本身会成为闭环的一部分以及未来事故排查的记忆库。

对话与机构知识留存在频道中，频道内的任何人都可以指导和跟进响应。团队成员可以实时验证假设、探索方案并展开调查，频道的完整历史增强了可审计性。通过 MCP 访问，Claude 可以验证指标是否恢复到基线并在讨论串中确认，将事后复盘（Post-mortem）写入受版本控制的经验教训文件中，供未来的调查读取。

事故并非 Claude Tag 唯一接管的工作。在工单中通过 MCP 被 Tag 或在频道中被直接提问时，Claude 会以相同的方式进行分诊。小型且边界清晰的修复将作为 PR 提交至评审门禁；任何更大规模的需求则编写为 intent.md 交付给阶段 1：规划，此时整个 SDLC 闭环便开始自给自足地持续运转。