AI 原生 SDLC 操作手册（The AI-Native SDLC playbook）AI 原生 SDLC 操作手册（

AI 原生 SDLC 操作手册（The AI-Native SDLC playbook）

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


作者	Louis Claxton
发布日期	2026 年 8 月 21 日
阅读时长	5 分钟
分类	Enterprise AI、Claude Code
原文	claude.com/blog/the-ai…

The AI-Native SDLC playbook

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

各组织已经开始用 AI 写代码，速度之快一年前难以想象，但围绕代码的流程却没能以同样的速度演进。

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

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

传统 SDLC 流程繁重，以确保每一步都有问责与控制。然而，传统 SDLC 的设计初衷是在「编写和实现代码最耗时、最昂贵」的时代实现效率最大化——如今情况已经不同了。PRD、估算仪式、产品安全评审，都是为了在长达数周、数月乃至一个季度的开发周期中强制对齐而存在的。

传统 SDLC 的控制手段还建立在「每一步都由人来执行」的假设之上。创造最多价值的组织已经围绕智能体 AI 当前的能力重建了流程，同时确保人类仍在闭环之中。在本指南中，我们将分享 Applied AI 团队在 SDLC 各阶段内部集成 Claude 的若干最佳实践，这些实践受我们与客户合作的启发，用于加速开发、让流程跑得更快。

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

瓶颈转移到构建阶段的左右两侧——主要是计划、评审/测试和部署，它们仍在以人的速度运行。
控制手段与现实脱节、变得难以为继。逐行人工评审在人写代码时说得通，但当 diff 大部分由智能体编写时就跟不上了。
治理成本上升，因为例外情况仍要经过每周或每月才开一次会的会议和委员会。

构建不再是约束

构建不再是约束——约束变成了它两侧以人的速度运转的环节。以人的速度运行的阶段时长不变，而构建坍缩为几个小时。

以安全瓶颈为例。安全团队的规模是按人的产出配置的，当智能体让代码产出成倍增长时，要么评审队列不断堆积，要么代码在评审不足的情况下就上线了。受监管的组织无法接受任何一种结果，所以它的安全与政策检查必须跟上智能体的节奏。

为了更好地实现智能体 AI 的生产力收益并保障其安全，传统 SDLC 生命周期需要的变革力度，应与实现（implementation）阶段已经经历的相当。

代码不再是瓶颈
打法（Plays）
阶段 1 —— 计划（Plan）
阶段 2 —— 设计（Design）
阶段 3 —— 构建（Build）
阶段 4 —— 测试（Test）
阶段 5 —— 部署（Deploy）
阶段 6 —— 维护（Maintain）
结语

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

AI 原生 SDLC 是一套重新设计的流程，把旧的控制目标与新的执行机制结合起来。流程不再是线性流动，而是一个环，AI 嵌入在每一个节点上。AI 原生 SDLC 推动自动交接并自动触发后续打法，从而解决传统 SDLC 各阶段之间交接的手工与笨重问题。

你也会听到这个转变被称为智能体 SDLC（agentic SDLC）、AI 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 关卡设在阶段边界上	持续评估（evals）贯穿实现全程
部署（Deploy）	人工逐行评审代码，治理在评审周期中进行，且往往不一致	多层智能体评审，人工评审保留给受监管和关键代码。治理在 AI 行动时即被强制执行，hooks 充当审批关卡
维护（Maintain）	人盯生产环境找 bug	智能体监控线上部署。任何被突破的控制带（control band）都会被诊断，并作为新的 `intent.md` 写回闭环

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

对于每一个需要判断的决策，人依然承担责任。在智能体 SDLC 的世界里，人的注意力随着必须评审的制品一起转移。

每个阶段都提交一件可供下一阶段读取的制品。意图（intent）、规格（spec）、计划（plan）、diff 和评审结论合在一起，就是审计轨迹。

打法（Plays）

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

每个打法涵盖：

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

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

一个阶段以提交一件制品结束，提交动作即启动下一个阶段。被接受的 intent.md 触发需求与设计工作，被批准的 spec.md 触发计划模式（plan mode），被合并的 PR 触发流水线，生产环境中被突破的控制带写下新的 intent.md——如此循环往复。

起步时，你需要逐个手工提示每一步；最终状态则是一个闭环：每件被接受的制品自动触发下一个关卡。人的注意力集中在关卡上，评审智能体标记出的问题，而不是每个阶段都从头开始。

打法依赖关系图

打法按阶段列出；箭头给出的是采纳它们的先后顺序。两者并不相同。从任意一个 clay play（译注：原文如此，疑为 Plan play 之笔误）开始——没有任何箭头指向它，所以它不需要任何前置。对任何其他打法来说，指向它的箭头就是需要先采纳的打法。

阶段 1 —— 计划（Stage 1 — Plan）

想法不再等待某人来把它写成文档。意图只被捕获一次，以提出者自己的语言，成为一件受版本控制、可供下一阶段执行的制品。

以 intent.md 捕获（Capture as 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 home），由产品负责人盯守。对单一产品而言，最简单的存放处是产品仓库里的一个 intent/ 文件夹。这种设置让制品链紧挨着由它派生的代码。只有当意图横跨多个仓库时，专门的 intent 仓库才值得那份开销；在 monorepo 里它就是一个目录。阶段 3：构建的侧栏会讨论这个存放处与已有的 Jira 或需求工具（记录的既有载体）之间的关系。

搭建这套东西是平台团队或工程团队的一次性任务。需要一名技术团队成员搭起意图存放处，并决定谁可以向它写入，因为很多贡献者会来自组织各个部门。

仓库建好之后，没有 git 经验的贡献者不需要直接使用 git——通过版本控制系统（如 GitHub）的连接器，Claude 可以在 claude.ai 或 Cowork 里代他们提交 markdown 文件。

如何执行

提出者用自己的语言向 Claude 描述问题。可以说今天做不了什么、这个想法影响谁、更好的样子是什么、什么不在范围内。不要求任何正式语言。
头脑风暴直到想法具体成型。Claude 会问分析师会问的问题：范围、用户、约束，以及成功长什么样。
让 Claude 使用组织的模板把结果写成 intent.md——模板可以由技术团队成员编码为一个 skill，并由负责人签核。内容可涵盖问题、预期产出、受影响的用户与系统、约束，以及待决问题。
提出者修正 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，上面列有作者、时间戳和完整的修订历史，记录在意图存放处的 git 历史中。产品负责人负责批准，而把意图送入阶段 2：设计的接受或拒绝决定，以合并（merge）或关闭评审的形式被记录下来。

如何衡量

先导指标：从第一次对话到 intent.md 被提交的时长，从意图存放处的 git 历史读取，其中记录了作者和时间戳。预期是从数周的需求 elicitation 与梳理周期，下降到数小时。
滞后指标：存活率，即产品负责人接受进入阶段 2：设计（而非关闭）的 intent.md 所占比例。接受或拒绝的决定以制品的合并或评审关闭的形式记录。此外，还有同一变更在第一次 spec.md 提交之后对 intent.md 所做修改的数量。

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

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

需求与设计（Requirements and design）

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

产品负责人评审这份规格，但不亲自撰写。这个流程的目标是产出一份工程团队可以据以规划的规格，并把需要关注的区域标记出来。

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

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

AI 原生：两个阶段在单次提示会话中完成。Claude 接过 intent.md，在组织 skills 的约束下产出需求与设计规格，并标记出需要关注的区域。

如何起步

前置条件：能写出 intent.md 文件，并把品牌、安全、合规和 UX 政策写成 skills。
基础设施：一位能用上 Claude 的产品负责人。不需要工程技能。

如何执行

产品负责人打开一个加载了组织 skills 的会话，并附上 intent.md。
产品负责人的提示词指向 intent.md，点出约束条件，并要求标记出关注点。起初手工运行，之后把它固化为一个组织级 slash command。再往后，让意图存放处中 intent.md 的被接受作为触发器：一个在合并时触发的非交互式作业，加载组织的 skills 运行这一轮，并把 spec.md 作为 pull request 提交（阶段 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.

治理考量

政策不再等到数周后的评审才被发现，而是在写规格的同时被读取并应用。组织的 skills 作为规格的约束被应用。规格、产生它的提示词，以及当时生效的 skill 版本，全部记录在版本控制中。产品负责人签核规格，并把被标记的关注点转给对应的责任人。

如何衡量

先导指标：同一变更从 intent.md 提交到 spec.md 提交之间的流逝时间（两个 git 时间戳），与旧的需求加设计周期做对比。
滞后指标：构建开始后的需求返工。统计同一变更中日期晚于第一次 plan.md 提交的 spec.md 提交。git log 可以直接给出这个数字。

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

没有一份被接受的计划，就不进行任何实现。组织知识变成智能体读取的文件，护栏以代码而非习惯的方式运行。

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

工程师在计划模式（plan mode）下启动 Claude Code 会话，把阶段 2：设计中批准的 spec.md 交给 Claude，让它反过来「访谈」自己，迭代计划直到工程师满意为止。

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

AI 原生：工作从一份书面计划开始，由 Claude 在计划模式下产出——在该模式下它可以只读代码库而不做任何修改。工程师在代码写出之前修正计划，被批准的版本以 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: 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 mode）

Claude Code 也可以运行在自动模式下：工程师批准计划，并在满意和迭代之后，Claude 不再逐次请求确认地应用每一处修改。随着后续打法中的护栏成熟（调校过的 CLAUDE.md、编码政策的 skills、拦截危险操作的 hooks，以及 Claude 可以运行的测试套件），自动接受（auto-accept）成为常规工作的默认方式：紧凑的 spec.md、很小的爆炸半径、测试已覆盖的代码。

现在的转变，是从「用户看着智能体做编辑、逐个评审动作」，转向「更长自主会话之后对制品的评审」。自动接受模式配合 worktrees 还能在个人和团队层面开启并行，是自主运行 SDLC、并如阶段 6：维护所述闭环的基础。

侧栏：遗留系统与事实源（Legacy systems and the source of truth）

适用于流程产出的每一件制品。

现有的 SDLC 流程很可能已经在跟踪制品，只是不在 markdown 文件里。工作项可能在 Jira 里，需求在带监管可追溯性的工具里，设计在 Figma 里，变更审批走变更委员会。这些系统很难被取代，因为审计师和监管者已经接受它们，其他团队也依赖它们——AI 原生 SDLC 必须迁就既有现实。

向 AI 原生 SDLC 过渡时，对流程产出的每一件制品，指名一个系统作为事实源（source of truth），其他一切系统只持有副本或指向原件的链接。以下几种配置都可以做到单一事实源，选择因制品而异：

以仓库为事实源。 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 在每次会话开始时会读完全部内容，任何过时的东西都在白白占用上下文。

# 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 历史中，并由 code owner 在 PR 评审中批准。

如何衡量

先导指标：Claude 重复犯下本应被 CLAUDE.md 拦住的错误的频率。对 CLAUDE.md 的修正和变更应在 git 历史中跟踪。
滞后指标：新成员从入队到第一个 PR 被合并的时长，来自 PR 历史。

Skills 即组织知识（Skills as institutional knowledge）

Skills 是组织把自身知识变得可操作的方式。指令是明确的、受版本控制的、被广泛应用的，政策变化时集中更新。经验法则：必须被一致执行的组织知识写成 skill；属于 CLAUDE.md 或提示词的东西不要写成 skill。

如何起步

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

如何执行

挑一项今天执行得时紧时松的知识。可以是安全标准、API 设计约定，或品牌规范。
把它写成一个 skill：一个包含 SKILL.md 的文件夹，frontmatter 写明何时触发，正文写明要做什么。工程师依据政策负责人的事实源来写，可借助 Claude。
把 skill 放进仓库的 .claude/skills/<name>/，随代码一起交付；或通过 plugin 在全组织范围分发。
测试 skill 是否触发。让 Claude 以不同方式做相关任务，确认每次 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 是一种控制手段，尽管是建议性的。它让 Claude 更可能在写代码的同时应用政策，但没有任何东西强制会话服从它。必须始终成立的政策，需要在 skill 背后有确定性的机制——比如拦截动作的 hook，或在 PR 处重新检查政策的评审环节。skill 让违规变得罕见，hook 让违规几乎不可能发生。skill 的调用记录在会话轨迹中，政策负责人像评审代码一样评审 skill 变更。

如何衡量

先导指标：从政策负责人批准政策变更，到更新后的 skill 被合并的时长，取自 skill 文件夹上的 PR。
滞后指标：引用该政策的 PR 评审发现项——一旦 skill 在写代码的同时应用政策，这类发现应趋近于零。若没有趋近于零，要么是 skill 没有触发，要么是它的文本已经偏离了官方政策。

Hooks 作为构建期护栏（Hooks as build-time guardrails）

skill 是建议性控制，而 hook 是它背后确定性的那一层。Claude 在实现期间的动作大多是文件编辑和 shell 命令，所以构建阶段是 hook 最常触发的阶段。

构建期 hook 可以：

拦截对受保护路径的编辑，比如生成代码的目录或被冻结的包；
在文件编辑后运行格式化工具和 linter，让漂移不再累积；
阻止凭据进入 diff。

为任何「政策必须无一例外成立」的 skill 配上 hook。hook 会在每个匹配它的动作上运行，所以构建期 hook 应当快速、且只作用于被改动的文件。更重的检查（如完整测试套件）应放在提交或 PR 环节。

需要人类批准的 hook 属于阶段 5：部署的关卡——因为构建期间弹出的批准提示，会把人重新放回所有并行会话的关键路径上。

并行会话与子智能体（Parallel sessions and subagents）

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

并行会话是另一个完整的 Claude Code 实例，在自己的 git worktree 里处理独立的任务。各个独立会话彼此一无所知，唯一共享的是驾驭它们的工程师。

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

并行会话提高一名工程师手上同时在飞的任务数，子智能体则让每个会话专注于自己的任务。工程师的工作就是驾驭和评审所有这些。

传统：一名工程师一次做一个任务，一天或一周里有相当一部分时间花在等构建、等测试、等评审上。等待期间切换任务是可能的，但上下文切换太累人，很少有人真的这么做。

AI 原生：一名工程师同时运行多个 Claude 会话，每个在自己的 worktree 里做自己的任务。重复性工作变成有独立上下文和工具限制的子智能体。工程师的工作转向编排，最终转向构建和监控闭环。

如何起步

前置条件：CLAUDE.md，因为所有会话都会读这个文件。反馈回路（阶段 4：测试）在这里也有帮助——当会话能验证自己的工作时，需要工程师盯守的程度就更低。
基础设施：一个 git 仓库（隔离来自 worktrees），以及调校过的权限设置，让会话不会在组织认为安全的命令上等待批准提示。

如何执行

工程师把工作拆成触及不同文件的任务，用计划模式打法（阶段 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 历史确定的返工率对照阅读。

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

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

给 Claude 一个反馈回路（Give Claude a feedback loop）

永远给 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 拦截修 bug 任务中对测试文件的编辑即可。替代方案是在评审中检查 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。
证据是什么：Claude 运行并贴出的 "make test" 原样输出、构建日志或截图对比——证据来自工具链本身。
记录在哪里：会话转录（由 OpenTelemetry 导出转发到组织的可观测性平台），以及 PR 的 check run——评审者和之后的审计者都能看到。
谁批准：评审 PR 的 code owner——机械性证据已经附上，他可以把注意力集中在意图和风险上。

如何衡量

先导指标：智能体所写变更的 CI 首次通过率，CI 系统本身就支持。
滞后指标：每个 PR 的评审时长（来自 PR 元数据）——当测试接住评审者过去接住的问题后，它应当下降；以及来自事件跟踪系统的变更失败率。

CI 中的持续评估（Continuous evals in CI）

evals 是阶段关卡式 QA 的 AI 原生对应物。实践中，它意味着一套在智能体配置发生变化时运行的测试套件。换上新的模型、改写了提示词时，eval 套件会告诉你智能体是否仍能以同样的标准完成工作。

应当把 evals 看作一套活的套件。随着模型进步，曾经能区分好坏的案例会失效，必须从持续监控中补充新案例。

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

如何起步

前置条件：CLAUDE.md 与反馈回路（阶段 4：测试）。
基础设施：能以非交互方式运行 Claude Code 的 CI，以及预算充足的 eval 运行 API key。

如何执行

平台工程师从近期工作中收集 20 到 50 个真实任务及其预期/可接受结果。
把每个任务写成一个 eval：提示词，加上定义"可接受"的检查（测试通过、lint 干净、行为不变、遵循政策）。
套件在 CI 中按计划、并在 CLAUDE.md、skills 或 hooks 有任何变更时以非交互方式运行——这套配置引导着智能体，理应享受代码级的回归测试待遇。
用结果为配置变更把关。一个拉低通过率的 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 一个跟得上智能体产出的关卡。通过率阈值作为合并检查被强制执行，运行被记录以便跨时间比较，配置变更由拥有它的团队批准。

如何衡量

先导指标：eval 通过率随时间的变化（套件每次运行都会报告），以及一个生产事件变成永久 eval 需要多久。
滞后指标：CI 中拦下的回归与生产中发现的回归之比，来自事件跟踪系统。

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

评审双向进行，治理在智能体行动时即被强制执行。智能体做生产关卡之前的所有事，关卡之后一步也不越界。

PR 评审回路中的 AI（AI in the PR review loop）

Claude 既给出评审也接受评审。它按组织政策评审进来的 PR，也处理自己 PR 上的评审意见。这让工程师把 PR 评审的注意力集中在行为上——归结起来就是判断意图与风险。

传统：评审容量是按人的产出规划的。PR 等人来通读，评审质量随评审者负载起伏，作者追着人跑、积压越堆越高。

AI 原生：所有 PR 得到一套完全相同的评审过程，发现项按严重程度排序。人的注意力上移一层——这个改动是否做到了计划想要的，风险是否可接受。

如何起步

前置条件：来自阶段 3：构建的、更新过的 CLAUDE.md；若评审环节执行成文政策则还需要 skills；定义好的子智能体。
基础设施：装好 Claude 集成的仓库——要么由管理员启用托管的 Code Review（research preview）服务，要么在你自己的 CI 里运行 claude-code-action；需要时模型调用走 AWS Bedrock、Google Vertex 或 Microsoft Foundry（CI/CD 打法涵盖部署选项）。要求 code owner 批准的分支保护策略也值得配置。

如何执行

托管 Code Review 服务是最快的起点。管理员启用并选择仓库。当你需要掌控流水线、或想让 API 调用走自己的云协议时，用 claude-code-action 在自己的 CI 里运行评审（CI/CD 打法负责那部分管道铺设）。
技术负责人把评审政策写成仓库根目录的 REVIEW.md，按组织关心的维度划分评审轮次：缺陷与逻辑错误；安全与漏洞；对照规格（需求打法的 spec.md）、实现计划（计划模式打法的 plan.md）和设计原则的合规性。REVIEW.md 还要定义什么算 Important、什么算 Nit，以及跳过什么。
技术负责人设定人工阈值。发现项本身既不批准也不拦截 PR，分支保护仍然要求 code owner 批准。想把合并建立在发现项之上的平台工程师，可以读取 check run 以机器可读形式发布的严重程度计数。
当评审者或作者在评审评论里 @claude，Claude 处理该评论并推送修复。PR 线程记录下请求和改动。这个修复回路通过 claude-code-action 运行；在托管服务中，评论 @claude review 则是请求一次全新评审。对 Claude 自己开的 PR，可以更进一步，让 Claude 把 PR"看护"到合并。团队把这个回路包成自定义 slash command：清扫 PR 上未解决的评审评论和失败的检查，逐项处理并推送修复，直到 PR 变绿、只等 code owner 批准。
评审发现项回流进 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 历史和事件跟踪系统。

Hooks 作为审批关卡（Hooks as approval gates）

构建阶段把 hooks 用作护栏，在无人类参与的情况下放行或拦截动作（阶段 3：构建）。hook 还可以「询问」——暂停动作直到指定的人批准——这正是发布门控所需要的。

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

如何起步

前置条件：无。
基础设施：一份成文的清单，列出变更流程要求的各项人工批准。

如何执行

工程管理层会同变更管理与合规部门，列出必须保留的人工审批关卡，比如变更管理签核、发布授权、对受保护路径的编辑。
平台工程师把每个关卡表达为一个 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
# 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 就是审批关卡。关卡条件对每个人、每一次都被强制执行。放行和拦截的决定带时间戳记录。关卡还定义了什么算作批准——是一张已批准的变更工单，还是发布经理的签核。

实战示例：受监管企业的托管设置（Managed settings for a regulated enterprise）

由平台团队通过 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 服务器都经由组织批准的插件市场而来，绝不来自某个 home 目录。

allowManagedMcpServersOnly 让智能体的工具面成为平台团队拥有的白名单。

requiredMinimumVersion 拒绝在低于批准底线的版本上启动，控制因此由组织实际评估过的构建来强制执行。

请把上面当作一个裁剪起点，而不是照抄的建议。每一项 deny 都在与能力做交易，合适的平衡取决于仓库的数据分级。设置参考文档记录了每个键，包括仅托管可用的那些：code.claude.com/docs/en/set…

如何衡量（针对 hooks 本身）

先导指标：花在每个审批关卡上的等待时长。每个 hook 决定都带时间戳和放行/拦截裁决写入 OpenTelemetry 导出，逐关卡可见。
滞后指标：hooks 上线前后，逃逸到生产的关卡违规次数，来自事件跟踪系统。

CI/CD 集成与部署（CI/CD integration and deployment）

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

传统：流水线跑确定性脚本，一切需要判断的事都等人来。比如分诊不稳定的测试、写变更日志、排查构建为什么挂了。部署和回滚是人顶着压力照着执行的手册。

AI 原生：Claude 在流水线内非交互地承担判断类步骤，运行在带受限凭据的沙箱中。部署工具通过 MCP 暴露给智能体，于是编写并测试了这次变更的工作流，也能在组织按环境定义的关卡内把它发上线并回滚。

如何起步

前置条件：PR 评审回路中的 Claude，以及作为审批关卡的 hooks——关卡必须先存在，自动化才能安全地加速冲过它们。
基础设施：装有 claude-code-action 的 CI 平台，或任何能调用 claude -p 的 runner；通过 API、或必须留在组织云协议内时走 Bedrock、Foundry、Vertex 的模型访问；面向部署目标的 MCP 服务器；一个不持有任何常驻生产凭据的智能体作业沙箱配置。

如何执行

平台工程师从只读的判断类步骤开始。在流水线作业里用 claude -p 分诊失败的构建、总结不稳定的测试、起草变更日志。
在既有关卡之后加入写操作步骤，比如修 lint、更新生成的文档、通过 @claude 提及处理评审意见。智能体写的任何东西都经分支保护以 PR 形式到达，它没有任何直推 main 的路径。
执行沙箱化。智能体作业在容器中、在网络策略之下运行，持有短时效的受限令牌，默认不带任何生产凭据。
通过 MCP 暴露部署。部署、状态、回滚都变成工具，按环境限定范围——智能体的部署权力是一份白名单，而不是一个揣着凭据的 shell 脚本。
按环境分层授权。开发环境里智能体自由部署；生产环境里智能体准备发布、发布经理授权，由 hook 强制生产关卡；staging 居中。
回滚应当是流水线里演练最充分的路径——一条智能体能运行的命令，并在 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

治理考量

指导原则是：智能体可以做生产关卡之前的任何事，不能越过关卡。以下控制手段强制这一原则。

分支保护把智能体写的一切变成 PR，没有直达 main 的路径。
生产部署 hook 拦住发布，直到指定的发布经理授权。每个非交互式运行都以智能体自己的身份行事，流水线日志因此能区分智能体做的事和触发它的工程师做的事。
按环境的权限分层，决定智能体在通往关卡的路上能做多少。

如何衡量

先导指标：无需叫醒人就完成分诊的流水线故障占比，取自 CI/CD 流水线日志。
滞后指标：DevOps Research and Assessment（DORA）度量，CI 系统和部署工具本身就会产出。

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

闭环合拢。一个触发器在没有任何人参与调用的路径上唤起 Claude，它发现的东西作为 intent.md 重新进入流水线。

维护与闭环（Maintenance and closing the loop）

到目前为止，我们讨论的是把 Claude 加入 SDLC 的每个阶段，每个阶段都需要人来启动最初的步骤。而这个阶段把重心转向 Claude 的自主运行，从而闭环。

例如，一个持续运行的监控智能体可以在一张 bug 工单开出的同时，创建 intent.md，并流经需求、计划、构建、测试和评审各阶段。阶段 6：维护以无头（headless）方式运行，阶段之间设有独立的置信关卡——一次确定性检查或一个对抗式评审智能体——决定上一阶段的产出是继续，还是升级给人。

传统：维护是被动环节。所有工单或事件都等一个人来处理、来重启流程。凌晨三点的告警可能被漏掉，工单可能躺在待办里直到有人捡起，复盘行动可能因为另一处火情而根本到不了代码库。

AI 原生：控制带突破、工单、频道消息或日程安排这类触发器，在没有人参与的路径上唤起 Claude。Claude 做诊断，只通过带关卡的路径行动，并把发现写成 intent.md，随后走上述各阶段。人做分诊和评审，但不再需要发起。

闭环（Closing the loop）

一个确定性脚本盯守生产环境，在控制带被突破时唤起 Claude。对突破的监控是闭环自主运行模式的一个好用示例，而本阶段末尾的 Claude Tag（public beta）小节涵盖经由其他渠道到来的工作。

如何起步

前置条件：intent.md，它给闭环一个结构化的输出来重启；Claude 加速过的 PR 评审；作为行动边界的 hooks；以及 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 打法涵盖了部署与模型访问选项。因为运行是无状态且非交互的，一个闭环可以在没有任何人启动的情况下开始和结束。
智能体把诊断写成阶段 1：计划格式的 intent.md，涵盖异常及其证据、预期产出、受影响的系统和待决问题。此后，这项发现像其他任何东西一样走流水线。
服务负责人或值班工程师分诊队列，把面向产品的发现转给产品负责人。立即修、排期、还是驳回。驳回会校准控制带、帮助降低噪声。
修复上线时，为该事件加一个 eval（持续评估打法），确保此类问题从此受到防护。

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 评审关卡，智能体可能触发的 runbook 都是预先批准过的。

如何衡量

先导指标：从控制带突破到 intent.md 进入分诊队列的时长，对照旧的从事故到复盘行动的时长。检测脚本日志里有突破时间戳和事件层级。
滞后指标：发现项变成已合并修复的比例（分诊队列对照实际 PR 历史），以及同类事件的重复发生——随着修复把案例加进 eval 套件，它应当下降。

示例

CI 测试失败率突破 3σ 时，智能体隔离不稳定的测试或开一张 revert PR，由评审关卡决定。
部署后 5xx 率在窗口内有部署的情况下突破 3σ 时，智能体触发既有的回滚流水线。
PR 周期时长触发漂移规则时，智能体为工程管理层写一份报告——这说明这套框架对流程指标和生产指标同样有效。

检测保持确定性。控制带被突破后才唤起 Claude，层级决定它能做什么。

周期性代码库扫描（Recurring codebase scans）

一次安全扫描，是关于「某个特定模型之下的代码库」的一个时点性陈述，而两半都会过期：代码每周都在变，每一代模型都能发现上一代漏掉的漏洞。AI 原生的答案是按计划运行扫描——调用路径上没有人——并把发现送进与其他代码变更相同的关卡。

Claude Security 是计划扫描的托管形态。接入一个 GitHub 仓库，扫描就在 Anthropic 的基础设施上以 Claude Mythos 5 运行，每个发现项在报告之前先经过验证并附置信评级。建议的补丁在网页版 Claude Code 中评审并应用。组织无需接触模型本身就能拿到发现项。

传统：安全扫描是一个事件——在发布或审计之前启动一次。报告进跟踪系统，积压靠人手动消化，直到下一次事件。其间写的代码只靠 PR 评审碰运气覆盖。

AI 原生：扫描按计划对每个接入的仓库运行，用的是当前最强的模型，发现项在任何人读之前先经过验证。每个发现的处理方式与控制带突破一致：一个 PR 装得下的修复走评审关卡，更大的事变成 intent.md。覆盖以最后一次运行起算，而不是第一次

如何起步

前置条件：PR 评审关卡和作为审批关卡的 hooks（阶段 5：部署），让发现项像任何变更一样走评审；来自阶段 1：计划的 intent.md 格式，用于大到装不进单个 PR 的发现。
基础设施：Claude Security 在 public beta 中面向 Claude Enterprise 组织开放。它需要在目标仓库（云端 github.com）上安装 Anthropic GitHub App、启用网页版 Claude Code、开启 Extra Usage 并设置消费上限、为运行扫描的人配备高级席位，并由管理员在 claude.ai/admin-settings/claude-code 打开该功能。扫描按 Mythos 5 费率按量计费，消费上限应与仓库的规模和数量相匹配。

如何执行

安全负责人接入仓库，并按仓库、服务或团队组织成项目，让发现项的所有权从一开始就清晰。
对最关键的仓库跑第一次全量扫描——包括被其他工具或更早模型扫过的。把首次扫描当作基线。第一次扫描很可能在曾被视为干净的代码里翻出发现项。
为每个项目设周期。对活跃开发的服务，每周是合理默认；仓库很大或混杂时，把扫描范围限定到目录或分支。
拿着置信评级分诊发现项。驳回要给理由，驳回被记录下来，同一发现就不会在下一次运行中当作新问题回来。
对有边界的发现项，在网页版 Claude Code 中打开建议的补丁，评审后像任何变更一样送进 PR 评审关卡。提出修复的智能体没有批准它的路径。
对超出单个补丁的范围的问题——比如架构弱点或跨服务重复的模式——按阶段 1 的格式写成 intent.md，从计划阶段起步。
修复发布到生产后，为该漏洞类别在持续评估打法的套件里加一个 eval，引导智能体的配置从此针对该类别接受测试。
把发现项导出为 CSV 或 Markdown，或使用 webhook，让组织既有的跟踪和审计系统继续作为记录系统——审计师本来就预期在那里看到它们。

治理考量

扫描运行在组织的管理控制之下——接入哪些仓库、谁持有扫描席位、消费上限，全部集中设定。每个发现项都有验证结果和置信评级，每次驳回都有理由——扫描历史因此是一份审计记录：发现了什么、修复了什么、以及有意识地接受了什么。

修复经由 PR 评审关卡和分支保护到达生产，而不是从扫描本身直达。Claude Security 是对既有静态分析和依赖扫描的增强。确定性检查留在 CI，模型驱动的扫描覆盖那些检查天生查不到的、依赖上下文的漏洞。

如何衡量

先导指标：已设定扫描周期的接入仓库占比，以及从发现项被报告到其补丁进入 PR 评审关卡的时长——从扫描历史和 PR 元数据读取。
滞后指标：计划扫描发现的漏洞与生产或外部报告发现的漏洞之比，来自事件跟踪系统；以及经过多轮扫描的仓库上每次扫描发现项数量的趋势——随着修复和 eval 累积，它应当下降。

Claude Tag 值班（Claude on call with Claude Tag）

事件也可以经由其他途径到来，比如职场沟通应用——Slack 或 Teams。事件可以长成这样：晚上十点在事件频道里一条要求紧急修复的 Slack 消息，现在可以立即被处理。Claude Tag（public beta，当前在 Slack 中可用）让 Claude 以自己的身份成为这些频道的成员，每个新事件都有了第一响应人，响应本身也成为闭环和未来事件记忆的一部分。

对话和组织知识留在频道里，频道里任何人都能引导和执行响应。任何团队成员都可以实时检验假设、探索新选项、开展调查，频道历史同时增强了可审计性。借助对 MCP 的访问，Claude 验证指标已回到基线并在话题串中确认，把复盘写进一份受版本控制的 lessons 文件供未来的调查读取。

Claude Tag 接手的还不只是事件。在频道里被 @ 或通过 MCP 挂到一张工单上，Claude 以同样的方式分诊工作。小而边界清晰的修复以 PR 形式经评审关卡到达；更大的事被写成 intent.md 进入阶段 1：计划——至此闭环开始自我供养。参见：Claude Tag 如何在 Anthropic 为 CI/CD 值班。

Claude Tag 值班

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

结语（Closing thoughts）

模型和执行框架（harnesses）变得更先进，让组织得以改造的不只是产码的方式，而是整个软件开发生命周期。

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

本指南汇集了 Applied AI 团队每天为客户实际执行的许多最佳实践，希望它对你是一份实用、可上手的资料。

循环持续运转。人类判断凌驾其上。