Agent X-Ray

AI 原生 SDLC 实战手册

约 45 分钟 · 更新于 2026-09-01 · 原文

AI 原生 SDLC 实战手册

要点速览

代码不再是瓶颈：写码提速后，瓶颈左移右移到仍以人类速度运行的规划、评审、部署环节，传统管控手段（逐行人工评审、周会审批）在智能体产出面前直接失效。

AI 原生 SDLC 把六个阶段串成闭环，每个阶段以一份提交进版本库的产物收尾（intent.md / spec.md / plan.md / 代码差异及其测试 / 带评审结论的 PR / 事件记录），下一阶段读它开工，commit 链本身就是审计轨迹。

机构知识要落成文件：CLAUDE.md 装团队约定与常犯错误，技能 (skills) 装必须一致执行的政策，钩子 (hooks) 做确定性兜底——技能让违规变少，钩子让违规几乎不可能。

测试阶段给智能体自验证的反馈回路（跑测试、跑构建、截图比对），并把 CLAUDE.md、技能、钩子这些「操控智能体的配置」纳入持续评估 (evals) 做回归，配置变更掉分就卡住合并。

部署阶段的原则是"智能体可以做到生产闸门之前的一切，但跨不过闸门"；维护阶段由确定性脚本盯控制带，越界后无人介入地拉起 Claude 诊断并写出新的 intent.md，回路自己转起来。

原文链接 原文：The AI-Native SDLC playbook，Anthropic Applied AI 团队，发布于 2026 年 8 月 21 日。英文存档：Original

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

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

各类组织已经开始用 AI 写代码，速度在一年前还难以想象；但围绕代码的那些流程，并没有以同样的速度改变。

许多工程团队仍然保留着原有的审批闸门、评审、交接和政策流程，把 Claude Code 这类智能体编码方案带来的生产力增益又拖了回去。

软件开发生命周期 (SDLC) 是把软件从想法送到生产环境的那套流程。大多数组织跑的都是同一套六个阶段的变体，覆盖规划、设计、构建、测试、部署和维护。传统做法里，每个阶段都是一个独立环节，由不同角色负责：产品经理写需求，技术架构师把需求转成设计，工程师实现设计，受监管企业里的 QA 团队做验证，发布团队负责上线，运维团队盯着线上运行状况。工作在各环节之间的流转，靠的是文档、工单和签字。

传统 SDLC 流程厚重，为的是在每一步都保证问责和管控。但传统 SDLC 是为另一个时代设计的：在那个时代里，最耗时也最昂贵的阶段是写代码和做实现——今天已经不是了。PRD、估点仪式、产品安全评审之所以存在，是为了在长达数周、数月甚至数个季度的开发过程中强行对齐认知。

传统 SDLC 的另一个特征是：它的所有管控都默认每一步由人来完成。而那些创造出最大价值的组织，已经围绕"智能体 AI 现在能做什么"重建了自己的流程，同时确保人始终在回路中。在这份指南里，我们会走一遍 Applied AI 团队在内部把 Claude 接入 SDLC 各个阶段的若干最佳实践——它们脱胎于我们与客户的协作经验，目的是加速开发、让流程跑得更快。

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

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

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

拿安全评审的瓶颈举个例子。安全团队的人力是按人类产出规模配置的，所以当智能体把代码产出翻了好几倍，要么评审队列越积越长，要么代码在评审不充分的状态下就上线了。受监管的组织两种结果都不能接受，因此它的安全与政策检查必须跟上智能体的节奏。

要真正兑现智能体 AI 的生产力增益、同时保证它是安全的，传统 SDLC 生命周期需要经历一场和实现阶段同等量级的改造。

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

AI 原生 SDLC 是一套重新构想过的流程：它保留了原有的管控目标，但换上了新的执行方式。流程不再是线性的，而是变成一个回路，并在每个节点嵌入 AI。AI 原生 SDLC 推动自动化的交接与后续打法的自动触发，从而解决传统 SDLC 各阶段之间交接手工、笨重的问题。

你也会听到这场转变被称作智能体 SDLC、AI SDLC，或者干脆叫智能体软件开发——叫法不同，说的是同一件事。

图中打法按所属阶段列出，箭头给出的则是采纳它们的顺序。两者并不相同。可以从任意一个 clay 色的打法起步——没有任何箭头指向它，所以它不依赖别的东西。对其余任何一个打法来说，指向它的那些箭头就是需要先行采纳的打法。

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

下表列出的是传统 SDLC 与由 Claude 支撑的 AI 原生 SDLC 这两端的极端形态。大多数组织处在两列之间的某个位置。

阶段	传统 SDLC	AI 原生 SDLC
规划	需求靠委员会收集，经工作坊和层层签字提炼，再手工写成文档	Claude 直接从源头提炼痛点，并写进 intent.md——一份人可读、机器可执行的产物
设计	分析师写规格说明，设计师再解析一遍	需求与设计压缩进与智能体的一次工作会话，由编码成技能的标准约束，在 git 中做版本管理
构建	测试和代码全手写，文档在主体开发完成之后才补	测试和代码由 AI 生成，机构知识以版本化、机器可读的 CLAUDE.md 文件和技能的形式维护
测试	QA 闸门卡在阶段边界上	持续评估贯穿整个实现过程
部署	人逐行评审代码，治理靠评审周期完成，且往往不一致	多层智能体评审，人工评审只留给受监管代码和关键代码。治理在 AI 行动的当下被强制执行，钩子充当审批闸门
维护	人盯着生产环境找 bug	智能体监控线上部署。任何被突破的控制带都会被诊断，并作为新的 intent.md 写回回路

贯穿右侧这一列的主线，是那份被提交的产物。每个阶段都以向版本控制系统写入一份产物收尾（包括 intent.md、spec.md、plan.md、代码差异及其测试、带评审结论的 PR，以及事件记录），下一个阶段则从读取它开始。在早期几个阶段，.md 文件是主要产物形式，因为产品负责人和智能体可以读同一份文件、也都能据此行动。从构建阶段往后，产物就是代码及其相关记录。这条 commit 链同时也是审计轨迹：谁提出了什么、智能体产出了什么、谁批准的。

凡是需要判断力的决策，人依然对其负责。在智能体 SDLC 的世界里，人的注意力随着"必须被评审的产物"一起转移。

每个阶段都提交一份下一阶段能读的产物。意图、规格、计划、代码差异和评审结论合在一起，就是审计轨迹。

打法（Plays）

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

每个打法包含：

有什么改变；
如何起步；
落地的具体步骤；
治理方面的考量；以及
如何衡量它是否奏效。

这些步骤是模块化的，组织可以根据自身情况，在不同时间优先改造不同的阶段。每个打法都在"前置条件"一节中点明它的依赖，依赖关系图对此有更进一步的说明。

一个阶段以提交一份产物收尾，而这次提交就启动了下一个阶段。被接受的 intent.md 触发需求与设计环节，被批准的 spec.md 触发计划模式 (plan mode)，被合并的 PR 触发流水线，生产环境中被突破的控制带则写出下一份 intent.md——回路就这样转下去。

一开始，你手工逐步提示每一步；而终态是一个回路：每一份被接受的产物都会触发下一道闸门。人的注意力集中在这些闸门上，评审智能体标记出来的问题，而不是每个阶段都从零开始。

规划（Plan）

想法不必再等着谁来把它写成文档。意图只被捕捉一次，用提出者自己的话，形成一份纳入版本控制、下一阶段可以直接据此行动的产物。

用 intent.md 捕捉意图

启动软件开发流程的 intent.md，可以从不同的路径进入。可能是某个人有了想法，可能是提了一张工单，也可能是告警暴露出一起线上事件（见阶段 6：维护）。

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

Claude 生成的原型规格是人可读的、纳入版本控制的，并且下一阶段可以立即消费。这份原型规格被保存为 intent.md。

无论意图来自事件触发还是来自智能体，步骤都一样：产品负责人在 intent.md 提交之前，先评审并修正智能体写出的内容。

这套东西搭起来对平台团队或工程团队来说是一次性工作。需要一位技术成员建起意图存放地（intent home），并决定谁有写入权限——因为贡献者会来自组织的各个角落。

仓库一旦存在，没有 git 经验的贡献者也不需要直接使用 git。通过一个连接版本控制系统（例如 GitHub）的连接器，Claude 可以在 claude.ai 或 Cowork 中代他们提交 markdown 文件。

如何执行

提出者用自己的话向 Claude 描述问题。他可以描述今天做不到什么、这个想法会影响谁、更好的状态长什么样，或者什么不在范围内。不要求使用任何正式措辞。
头脑风暴，直到想法变得具体。Claude 会问出分析师会问的那些问题：范围、用户、约束条件，以及成功的标准是什么。
让 Claude 按组织的模板把结果写成 intent.md——这个模板可以由技术团队成员编码成一个技能，并由负责人签字确认。模板可以涵盖问题、期望结果、受影响的用户和系统、约束条件，以及待解决的问题。
提出者纠正 Claude 理解偏差的地方。
把 intent.md 提交到共享的存放地。作者和时间戳一并进入记录，产品负责人从这里接手这个想法。

markdown

# 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（设计）的接受或拒绝动作，则以合并记录或关闭时的评审意见的形式留存下来。

如何衡量

先行指标

从第一次对话到 intent.md 被提交所花的时间，可以直接从意图存放地的 git 历史中读出（其中记录了作者与时间戳）。预期是从原本长达数周的需求获取与打磨周期，缩短到以小时计。

设计（Design）

需求与设计合并为一次会话。策略在规格书写就的当下就已生效，而不是等几周后的评审才被发现。

需求与设计

产品负责人批准之后，Claude 接过已受理的 intent.md，产出一份需求与设计规格书。整个过程由组织自己的技能 (skills) 引导，覆盖品牌、安全、合规与用户体验 (UX)。

产品负责人评审这份规格书，但不亲自撰写。这一流程的目标是产出一份工程团队可以据此排期的规格书，并标注出需要关注的风险点。

前端工作是最清晰的例子。intent.md 被受理后，产品负责人依据 intent.md 在 Claude Design（beta）中做出设计稿，反复迭代，然后导出到 Claude Code 去实现。

传统做法需求与设计是两个独立阶段，由两支不同团队负责。分析师把想法形式化为需求，设计师再把需求解读回设计。这种分工是为了责任清晰，但既慢又有损耗。

AI 原生做法两个阶段在一次带提示词的会话里完成。Claude 拿到 intent.md，在组织技能的约束下产出需求与设计规格书，并标注出需要关注的风险点。

上手准备

前置条件

写好一份 intent.md 文件，并把品牌、安全、合规与 UX 策略写成技能。

基础设施

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

具体怎么做

产品负责人开启一个会话，让组织的技能可用，并附上 intent.md。
产品负责人的提示词指向 intent.md，点明各项约束，并要求标注风险点。一开始手工跑，之后把它固化成组织级的斜杠命令 (slash command)。再往后，把 intent 存放库中 intent.md 的受理动作作为触发器：合并时启动一个非交互式任务，加载组织技能跑完这一轮，并以 pull request 的形式提交 spec.md（这套管道见第 5 阶段：部署中的 CI/CD play）。从这一步开始，产品负责人第一次介入就是评审。
同一位产品负责人对照原始想法评审规格书。规格书是否解决了所陈述的问题？intent.md 里的开放问题是被回答了，还是被顺延了？
优先处理被标注的风险点——它们正是分析师原本会升级上报的地方。产品负责人在工程团队看到规格书之前，逐条与对应的策略负责人达成结论。
把 spec.md 与 intent.md 一起提交。这一对文件记录了「要的是什么」和「定的是什么」。
产品负责人决定规格书与 intent 是否进入构建阶段；组织认定为高风险的内容要咨询技术负责人。这个决定始终由人类同事来下，而受理规格书正是第 3 阶段：构建中 plan mode play 的启动信号。

长什么样（提示词）

markdown

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 时间戳），与旧的「需求 + 设计」周期作对比。

滞后指标

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

构建（Build）

没有经过批准的计划，就不动手实现。组织的既有知识变成智能体可读的文件，护栏以代码形式运行，而不再靠习惯维系。

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

工程师以 plan mode 启动 Claude Code 会话，把第 2 阶段：设计中批准的 spec.md 交给 Claude，让它反过来向自己提问，反复迭代计划，直到工程师满意为止。

传统做法工程师读完设计就开始写代码。这次变更具体怎么做、动哪些文件、写哪些测试，全都留在工程师脑子里，顶多是工单里的一条评论。别人无从评审。评审者第一眼看到的就是完成后的 diff，到那时再返工已经很慢了。

AI 原生做法工作从一份书面计划开始，由 Claude 在 plan mode 下产出——这个模式下它可以读代码库但不做任何改动。工程师在代码写出来之前先修正计划，批准后的版本以 plan.md 提交，供后续阶段对照检查。

上手准备

前置条件

如果有 intent 类产物（intent.md 或 spec.md）就带上，另外有 CLAUDE.md 文件会更好。

基础设施

一个能访问代码仓库的 Claude Code。

具体怎么做

工程师用 plan mode 与 Claude 开启会话。
工程师把 intent.md 和 spec.md 交给 Claude，要求一份实现计划，写明哪些文件会变、工作顺序如何、用哪些测试来证明它成立。
追问这份计划：这次变更可能弄坏什么？哪一步风险最大？Claude 考虑过但没有选择的其他方案是什么？
反复迭代，直到一个从没参与过这段对话的工程师，仅凭这份计划就能完成这次变更。
把批准后的计划提交为 plan.md。计划进入审计轨迹，PR 评审 play（第 5 阶段：部署）会拿最终的 diff 与它对照。
接受计划，让 Claude 去实现。计划扎实的话，实现往往一遍过。
当实现偏离了计划，就在同一次提交里更新 plan.md。可以考虑用一个钩子 (hook) 来强制二者保持同步。

长什么样（plan.md）

markdown

# 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 无法编辑文件。计划及其修订版本会被记录下来，连同是谁接受了它。常规变更由工程师批准，组织认定为高风险的内容则交给技术负责人或架构师。

Claude Code 的 auto mode

Claude Code 也可以运行在 auto mode 下：工程师批准计划，在满意并迭代完成之后，Claude 逐项应用变更，不再每改一处都来征询一次。随着后续几个 play 的护栏逐渐成熟（调优过的 CLAUDE.md、把策略编码进去的技能、能拦截危险动作的钩子，以及一套 Claude 可以自己跑的测试），自动接受就成了常规工作的默认模式：一份严谨的 spec.md、一个不大的影响半径、以及测试已经覆盖到的代码。

重心至此从「用户盯着智能体逐条改、逐个动作地审」，转向「在更长的自主会话结束后审查产物」。自动接受模式配合 worktree 使用，还能进一步支撑个人与团队层面的并行度，是自主运行整个 SDLC、并按第 6 阶段：维护所述闭合回路的基础。

现有的 SDLC 流程多半已经在追踪各类产物了，只不过不是以 markdown 文件的形式。工作项可能在 Jira 里，需求在某个内建法规可追溯性的工具里，设计在 Figma 里，变更审批在变更委员会那儿。这些系统很难被取代，因为审计师和监管方已经认可它们、其他团队也依赖它们，所以 AI 原生 SDLC 必须绕着既有格局来适配。

向 AI 原生 SDLC 过渡时，流程产出的每一类产物都要指定唯一一个系统作为事实来源 (source of truth)，其他地方只保存副本或指向原件的链接。下面几种配置都可以做到「单一事实来源」，具体选哪个则因产物而异：

以代码仓库为事实来源。 markdown 产物就是权威记录，遗留系统引用提交中的文件。对工程主导的组织来说，这往往是最干净的一种配置，因为所有记录都在同一个工具里，时间戳权威也只有一个。

以遗留系统为事实来源。 Jira、ServiceNow 或需求管理工具持有权威记录，markdown 产物是工作副本。Claude 在会话开始时读取记录，并在产出规格书或计划的同一次会话里，通过 MCP 连接器把结果写回去。

以关联作为底线。 所有产物都注明记录 ID，所有遗留记录都包含对应 markdown 文件的提交 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）

javascript

# 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 历史中取得。

把技能作为组织既有知识的载体

技能是组织把自身既有知识变成可操作形态的方式。这些指令是显式的、纳入版本控制的、可以大范围应用的，并且在策略变更时集中更新。经验法则是：必须被一致执行的组织既有知识，写成技能；本该属于 CLAUDE.md 或某条提示词的内容，不要写成技能。

上手准备

前置条件

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

基础设施

一条有具名负责人、有书面事实来源的策略。

具体怎么做

挑一条当下执行得最不一致的知识。可以是某项安全标准、某条 API 设计约定，或者某条品牌规则。
把它写成一个技能：一个包含 SKILL.md 的文件夹，frontmatter 说明何时触发，正文说明要做什么。由工程师依据策略负责人的事实来源来写，可以借助 Claude。
把技能放在仓库的 .claude/skills/<name>/ 下，让它随代码一起分发；或者通过插件 (plugin) 在全组织范围内分发。
测试技能是否会被触发。用不同的说法让 Claude 去做相关任务，确认技能每次都被加载。
策略变更时，改技能，并请策略负责人为这次改动签字。
工程师在下一次会话里自动获得新版本。

长什么样（.claude/skills/secure-api-review/SKILL.md）

markdown

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or
  modifying an external-facing endpoint, reviewing API code, or
  generating an OpenAPI spec.
---
# Secure API review

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

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

治理考量

技能是一种控制手段，但只是建议性的。它让 Claude 在写代码的过程中很可能应用该策略，却没有任何东西强制某一次会话必须遵守。一条必须永远成立的策略，需要在技能背后加一层确定性的东西，比如一个能拦截该动作的钩子，或者一轮在 PR 阶段重新核查该策略的评审。技能让违规变得罕见，钩子让违规几乎不可能发生。技能的调用记录在会话轨迹里，策略负责人像评审代码一样评审技能的变更。

如何度量

先行指标

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

滞后指标

PR 评审中引用该策略的问题数量。一旦技能能在写代码的过程中就把策略应用上，这个数字应当趋近于零。如果它没有下降，要么是技能没有被触发，要么是它的文本已经和官方策略脱节了。

把钩子作为构建期的护栏

技能是建议性的控制手段，而钩子 (hook) 是它背后那层确定性的机制。Claude 的动作大多是实现过程中的文件编辑和 shell 命令，所以构建阶段往往是钩子触发最频繁的地方。

构建期的钩子可以：

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

任何必须无例外成立的策略，其技能都应当有钩子在背后兜底。钩子会在每个匹配的动作上运行，所以构建期的钩子应当足够快，并且只针对发生变化的那个文件。像跑整套测试这类更重的检查，应该放在提交或 PR 阶段。

需要人工批准的钩子应当归入第 5 阶段：部署中的各类闸门，因为构建过程中弹出的审批提示，会把人重新塞回所有并行会话的关键路径上。

并行会话与子智能体

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

一个并行会话就是另一个完整的 Claude Code 实例，在它自己的 git worktree 里处理一项独立任务。每个独立会话彼此毫不知情，它们唯一共享的就是那位在背后掌舵的工程师。

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

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

传统做法一位工程师一次只做一项任务，一天或一周里有相当大一部分时间花在等构建、等测试、等评审者上。等待时切换到别的任务当然可行，但上下文切换足够累人，很少有人真愿意这么干。

AI 原生做法一位工程师同时跑好几个 Claude 会话，每个都在自己的 worktree 里做自己的任务。重复出现的活儿被固化成子智能体，各有自己的上下文和工具权限。工程师的角色转向编排，并最终转向构建和监控各种回路。

上手准备

前置条件

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

基础设施

一个 git 仓库，因为隔离性来自 worktree；另外要把权限设置调好，让会话不会卡在等待批准上——那些命令组织本来就认为是安全的。

具体怎么做

工程师把工作拆分成触及不同文件的任务，借助 plan mode play（第 3 阶段：构建）产出的计划来判断哪些工作是相互独立的。共享文件的任务放在同一个会话里，一个接一个做。
每个并行任务都有自己的 worktree，比如一个终端里跑 claude --worktree feature-auth，另一个终端里跑 claude --worktree fix-rate-limit。worktree 是一份独立分支上的独立检出，可以避免多个会话在文件上撞车。
两到三个会话是个合理的起点。实际上限取决于一个人能认真评审多少条工作流，所以只在评审还跟得上的前提下继续加会话。
把重复出现的活儿变成子智能体，定义为 .claude/agents/ 下的 markdown 文件，每个都有名字、何时使用的描述、以及它可以调用的工具。例子包括：一个在主智能体收工后剥离多余复杂度的代码精简器、一个跑起应用并检查行为的验证器、一个探索代码库并回报结论、不把主上下文塞满的调研员。把这些定义提交进 git，让全团队共享。

长什么样（.claude/agents/verifier.md）

javascript

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

治理考量

会话越多产出越多，因此各项控制必须来自仓库里的配置。仓库中的钩子和权限设置对所有会话生效，而每个会话做了什么都会被记录下来，并归属到运行它的那位工程师名下。

测试（Test）

每一次会话在人看到结果之前都会先自查，而那些引导智能体（agent）行为的配置，也要像它写出的代码一样接受回归测试。

为 Claude 提供反馈闭环

一定要给 Claude 一条验证自己工作成果的途径，可以是测试、构建，也可以是截图比对。会话会自查工作、自行修正错误，然后才交到工程师手里。

反馈闭环不要与验证子智能体（verifier subagent，见「阶段 3：构建」）混为一谈。反馈闭环贯穿整个任务，工作跑多少轮它就跑多少轮；而验证子智能体是把最终检查封装起来的一种方式——当会话认为工作已完成时，用一个全新的上下文窗口跑一遍，这样得出的结论就不会被写出这段代码时的那些假设所污染。

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

AI 原生做法 会话被赋予了在人看到之前自查工作的能力：跑测试、跑构建、截图。Claude 反复迭代直到检查通过，因此送到工程师面前的东西已经过检验。搭建这个闭环由运行会话的工程师负责，下面的步骤也是写给他们看的。

开始动手

前置条件

无。

基础设施

一套测试用例和一套构建，各自都能用一条命令在本地跑起来。对于用户界面（UI）相关工作，让 Claude 能「看见」结果至关重要——要么给它浏览器工具，要么通过 MCP 接入截图工具。

如何执行

如果今天验证工作需要敲一连串命令、还得懂点环境知识，那就把它封装成单个目标，比如 "make test" 或 "npm test"，失败时返回非零退出码。
在 CLAUDE.md 的 Commands 一节里逐条列出命令，并附上一份正常输出的示例。
给出一个可量化的目标，让 Claude 不必问你就能自查，例如：「test_status.py 中的所有测试通过」「截图与附带的设计稿一致」或「接口返回 200 且带上了新字段」。
修复缺陷时，先写会失败的测试。让 Claude 把这个 bug 复现成一个测试、跑一遍，确认它确实因为你预期的原因而失败，然后提交这个测试。到这一步才让 Claude 在不修改测试的前提下让它通过——用最后一步提到的测试文件钩子（hook）来强制这条限制。一个在修复之前就存在、且智能体无法改写的测试，才是 bug 已被消除的证据。
UI 工作要用视觉检查来闭环。给 Claude 一个浏览器或截图工具，把设计稿给它，让它自行迭代：实现、截图、比对、调整。跑两三轮很正常，而且每一轮的结果都应该更好。
把「验证」纳入「完成」的定义。这条指令写在 CLAUDE.md 里：报告任务完成前先跑测试，并把输出贴出来。
最后，闭环本身也需要保护，因为一个正在修代码的智能体绝不能有能力削弱针对这段代码的检查。用一个在修复任务期间阻止编辑测试文件的钩子就能做到。另一种办法是在评审时检查差异（diff），凡是动了测试的改动一律驳回。

它长什么样（CLAUDE.md 中的验证段落）

javascript

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

治理考量

强制的是什么

任务报告完成前必须先验证，以及在修复任务期间禁止智能体编辑测试文件——当组织希望这两条是有保障的，就把它们实现成钩子。

证据是什么

Claude 实际跑出来并贴出的 "make test" 原始输出、构建日志或截图比对结果——证据来自工具链本身。

记录在哪里

记录在会话记录（session transcript）里，由 OpenTelemetry 导出转发到组织的可观测性平台；同时也记录在合并请求（PR）的检查运行结果中，评审者和日后的审计人员都能看到。

谁来批准

评审这个 PR 的代码所有者（code owner）。因为机械性的证据已经附在上面，他可以专注于意图和风险。

如何度量

先行指标

智能体所写改动的 CI 首次通过率——CI 系统本身就已支持这项统计。

滞后指标

单个 PR 的评审耗时（取自 PR 元数据）。一旦测试能抓住过去靠评审者发现的问题，这个数字就应该下降；另外还有取自事故追踪系统的变更失败率。

CI 中的持续评估

评估 (eval) 是阶段门式质量保证（QA）在 AI 原生世界中的对应物。落到实处，就是一套只要智能体的配置发生变化就会运行的用例。当换用新模型或重写提示词（prompt）时，评估套件会告诉你智能体是否仍以同样的标准完成工作。

评估应当被视为一套活的用例集。随着模型能力提升，曾经具备区分度的用例会逐渐失效，必须补充在持续监控中新发现的用例。

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

开始动手

前置条件

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

基础设施

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

如何执行

平台工程师从近期工作中收集 20 到 50 个真实任务，并附上各自的预期／可接受结果。
把每个任务写成一个评估，也就是提示词加上定义「可接受」的检查项（测试通过、lint 干净、行为未变、策略被遵守）。
这套用例在 CI 中以非交互方式按计划运行，同时在 CLAUDE.md、技能（skills）或钩子发生任何变更时触发——因为正是这些配置在引导智能体，它们理应享有和代码同等的回归测试待遇。
用结果给配置变更把关。一个让通过率下降的技能改动，在合并前必须经过评审。
每一次生产事故都要产出一个评估，由负责该事故的团队编写，并作为回归测试长期留在用例集中。

它长什么样（.github/workflows/agent-evals.yml）

yaml

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 文件；如果评审流程要执行成文的策略，还需要技能，以及定义好的子智能体。

基础设施

一个装好 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 还要定义什么算「重要（Important）」、什么只是「小毛病（Nit）」，以及哪些可以跳过。
技术负责人设定人工介入的门槛。评审发现本身不批准也不阻塞 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 中给小毛病的数量设上限。生成代码路径以及 CI 已经强制执行的内容都排除在外。

它长什么样（REVIEW.md）

markdown

# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.

治理考量

职责分离得以保留，因为写代码的那个智能体没有任何途径批准自己的代码。REVIEW.md 中的评审策略适用于所有 PR，而评审发现、修复、评分与审批全都记录在 PR 历史里，因此 PR 本身就是审计记录。审批由人通过分支保护给出，并以评审发现作为参考。

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

钩子作为审批关卡

构建阶段把钩子当作护栏，在无人参与的情况下放行或拦截操作（阶段 3：构建）。钩子也可以「询问」——暂停操作，直到指定的人批准，这正是发布把关所需要的。

这一节放在「阶段 5：部署」，是因为发布关卡是最典型的场景，但钩子并不专属于部署：Claude 在哪里行动，钩子就在哪里生效。例如，钩子可以在阶段 3：构建中阻止在没有变更工单的情况下修改数据库迁移和基础设施，也可以在阶段 4：测试中阻止智能体在修复任务期间编辑测试文件。

开始动手

前置条件

无。

基础设施

一份写下来的清单，列明变更流程所要求的各项审批。

如何执行

工程管理层会同变更管理与合规部门，列出必须保留的人工审批关卡，例如变更管理签核、发布授权，以及对受保护路径的修改。
平台工程师把每一道关卡表达成一个钩子——一个在 Claude 行动之前运行、可以放行（allow）、询问（ask）或拦截（block）的脚本。
团队级钩子放进 git 中的 .claude/settings.json；不可协商的钩子放进由平台或 IT 管理员掌管的托管设置（managed settings），个别工程师无法关闭它们。
拦截要能自我解释：当钩子挡住某个操作时，原因和申请审批的途径都要出现在 Claude 的输出里。

它长什么样（.claude/settings.json）

json

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

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

bash

#!/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

治理考量

钩子就是审批关卡。关卡条件每一次、对每个人都强制生效。放行与拦截的决定都带时间戳记录在案。关卡同时也定义了什么算作「已批准」——是一张通过审批的变更工单，还是发布经理的签核。

实战示例

面向受监管企业的托管设置

由平台团队通过移动设备管理（MDM）或管理控制台下发；工程师无法编辑或覆盖其中任何一条。

从控制的角度看，每一行都买到了什么

permissions.deny 让密钥进不了智能体的上下文，并阻断经由工具发起的任意网络外联；permissions.allow 则预先批准安全的内环操作，免得拒绝清单变成无休止的授权疲劳。

disableBypassPermissionsMode 加上 allowManagedPermissionRulesOnly，意味着任何工程师、项目文件或命令行参数都无法放宽这些规则。

sandbox 补上了权限管不到的缺口。工具层面禁用 WebFetch 并不能阻止一条 shell 命令访问网络；而操作系统层面的域名白名单会直接切断外联。

credentials 补上了拒绝规则留下的另一个缺口。permissions.deny 管的是 Claude 的文件工具，但沙箱里的 shell 命令默认仍可能读到 ~/.ssh 或 ~/.aws/credentials；这一段配置会拒绝这些读取，并从每一条沙箱命令的环境变量中剥掉指定的密钥。

allowManagedHooksOnly 意味着本节所述的审批关卡是唯一会运行的钩子；本地的任何东西都无法追加或替换它们。

disableSideloadFlags 和 strictKnownMarketplaces 意味着工程师机器上的每一个技能、智能体、钩子和 MCP 服务器，都来自组织批准的插件市场，而不是某个用户主目录。

allowManagedMcpServersOnly 让智能体的工具面变成一份由平台团队掌控的白名单。

requiredMinimumVersion 会拒绝在低于批准下限的版本上启动，从而保证这些控制措施跑在组织真正评估过的构建版本上。

以上内容请当作一个待裁剪的起点，而不是照抄的推荐配置。每一条拒绝规则都要拿能力去换，合适的平衡点取决于该仓库的数据分级。设置参考文档收录了每一个配置项，包括那些仅限托管使用的：code.claude.com/docs/en/settings

如何度量（针对钩子本身）

先行指标

在每一道审批关卡上等待的时间。每一次钩子决策都会带着时间戳以及放行／拦截的判定写入 OpenTelemetry 导出，因此每道关卡的等待时长都是可见的。

滞后指标

引入钩子前后，突破关卡进入生产环境的违规数量，取自事故追踪系统。

CI/CD 集成与部署

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

传统做法 流水线跑的是确定性脚本，任何需要判断力的事情都要等人来做，比如甄别不稳定的测试（flaky test）、写变更日志、搞清楚构建为什么挂了。部署和回滚则是人在压力之下照着操作手册（runbook）执行。

AI 原生做法 Claude 以非交互方式在流水线内部承担那些需要判断的步骤，运行在带有受限凭据的沙箱中。部署工具通过 MCP 暴露给智能体，于是那条写出并测试了这次改动的工作流，也能在组织为每种环境定义的关卡之内把它发布出去、并把它回滚回来。

开始动手

前置条件

Claude 已进入 PR 评审闭环，且钩子已作为审批关卡就位——因为在自动化把东西加速推过这些关卡之前，关卡必须先存在。

基础设施

一个装了 claude-code-action 的 CI 平台，或任何能调用 claude -p 的运行器；通过 API 获得模型访问权限，或者在流量必须留在组织云合同内时走 Bedrock、Foundry 或 Vertex；面向各部署目标的 MCP 服务器；一份供智能体作业使用、默认不持有生产凭据的沙箱配置。

如何执行

平台工程师先从只读的判断类步骤入手。在流水线作业里用 claude -p 来甄别失败的构建、总结不稳定的测试，或起草变更日志。
在既有关卡之后加入写操作步骤，比如修 lint、更新生成的文档，或通过 @claude 提及来处理评审意见。智能体写的任何东西都以 PR 的形式经过分支保护进来，它没有任何途径直接推送到 main。
执行过程要沙箱化。智能体作业运行在受网络策略约束的容器中，使用短时有效的受限令牌，默认不持有任何生产凭据。
通过 MCP 暴露部署能力。部署、状态查询和回滚都变成按环境划分作用域的工具，于是智能体的部署权限是一份白名单，而不是一个带着凭据的 shell 脚本。
按环境分级自主权。在开发环境，智能体可以自由部署；在生产环境，智能体准备好发布、由发布经理授权，并有钩子强制执行生产关卡；预发布环境介于两者之间。
回滚应当是整条流水线中演练得最充分的路径——一条智能体可以执行、并在预发布环境中定期演练的单一命令。「闭合循环」那一节（阶段 6：维护）在控制带被突破时会调用这个回滚，所以它必须事先被验证过。

它长什么样（流水线步骤）

markdown

- 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 的路径。
生产部署钩子会拦住发布，直到某位具名的发布经理授权为止。每一次非交互运行都以智能体自己的身份进行，因此流水线日志能区分开哪些是智能体做的、哪些是触发它的工程师做的。
按环境划分的权限分级，决定了智能体在抵达关卡之前能做多少事。

维护（Maintain）

循环闭合。触发器在没有人参与调用路径的情况下唤起 Claude，而它发现的问题会以 intent.md 的形式重新进入流水线。

维护与闭合循环

到目前为止，我们讨论的是如何把 Claude 加进 SDLC 的每一个阶段，而每个阶段的起始步骤都需要人来发起。这一阶段则把重心转向让 Claude 自主运行，从而闭合整个循环。

举例来说，一个持续运行的监控智能体可以在缺陷工单被提出之后，创建一份 intent.md，并让它流经需求、计划、构建、测试与评审各阶段。阶段 6：维护以无界面（headless）方式运行，阶段之间设有独立的置信度关卡——可以是确定性检查，也可以是一个对抗性的评审智能体——由它决定上一阶段的产出是继续推进还是升级给人处理。

传统做法 维护是一个被动的阶段。所有工单或事故都要等人来处理并重新启动流程。告警在凌晨 3 点响起，可能被漏掉；工单可能一直躺在待办里直到有人认领；而事后复盘（post-mortem）产生的行动项，如果另一场火灾先烧起来，可能根本进不了代码库。

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

闭合循环

一个确定性脚本盯着生产环境，在控制带被突破时唤起 Claude。监控突破是这种自主循环模式的一个好例子，而本阶段末尾的 Claude Tag（公开测试版）部分则涵盖了工作从其他渠道抵达的情况。

开始动手

前置条件

Intent.md，它为循环提供了一个可用于重新启动流程的结构化输出。以及由 Claude 加速的 PR 评审、作为行动边界的钩子，还有 CI/CD 的回滚路径（最高自主级别会调用它）。

基础设施

一个检测脚本可以查询的指标存储（Prometheus、CI 系统的 API 或同类系统）、仓库的读取权限、一种在 CI 中非交互运行 Claude Code 的方式，或者用 Agent SDK 搭一个接收 webhook 的服务。

如何执行

服务负责人或平台工程师挑选一个滚动基线稳定的指标，比如 CI 测试失败率、部署后 5xx 比例，或 PR 周转时间。
他们编写检测脚本，通常是在滚动窗口上计算均值和标准差，再配上判定规则（Western Electric 或类似规则），使控制带既能捕捉尖峰也能捕捉缓慢漂移。脚本纳入版本控制并有单元测试，检测过程保持完全确定性，不涉及任何模型。
响应分级定义在纳入版本控制的配置里（下面的 bands.yaml）。1σ 时脚本只记录日志；2σ 时以只读方式唤起 Claude 做诊断；3σ 时 Claude 可以行动，但只能通过开 PR 进入评审关卡，或者触发一份预先批准的操作手册。
触发层可以是 GitHub 或 GitLab 中的定时工作流、来自现有监控系统的 webhook，或者内网里的一个 Cron Job。Claude 无状态运行，既可以作为 CI 运行器上的一个非交互步骤，也可以作为沙箱容器中的 Agent SDK 服务，部署与模型访问的各种选项在 CI/CD 那一节已有说明。正因为运行是无状态且非交互的，一个循环可以在无人启动的情况下开始并结束。
智能体把诊断结果按阶段 1：计划的格式写成 intent.md，涵盖异常本身及其证据、建议达成的结果、受影响的系统以及任何待解决的问题。从这里开始，这条发现就像其他任何需求一样走完整条流水线。
服务负责人或值班工程师对队列做分诊，把面向产品的发现路由给产品负责人：立即修、排期，或者关闭。关闭动作会反过来调优控制带，有助于降噪。
修复上线后，为该事故补一个评估（见持续评估那一节），确保此类问题今后都有防护。

它长什么样（例如一份监控 CI 测试失败率的 bands.yaml）

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 评审关卡，而智能体可以触发的操作手册都是事先批准过的。

示例

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

检测保持确定性。控制带一旦被突破就唤起 Claude，而分级决定了它能做什么。

定期代码库扫描

一次安全扫描，是在某个特定模型之下对某个代码库做出的时间点陈述，而这两半都会过时：代码每周都在变，而每一代模型都能找出上一代漏掉的漏洞。AI 原生的答案是让扫描按计划运行、调用路径中不需要人，并把它发现的问题送进和其他代码库改动一样的关卡。

Claude Security 是这种定期扫描的托管形态。接入一个 GitHub 仓库，扫描便在 Anthropic 的基础设施上以 Claude Mythos 5 运行，每一条发现在上报之前都会经过验证，并附带一个置信度评级。建议的补丁在 Claude Code on the web 中评审并应用。组织无需自己拥有模型访问权限就能拿到这些发现。

传统做法 安全扫描是一个事件——在发布或审计之前发起一次扫描，报告进入追踪系统，团队手工消化积压，直到下一次事件。中间这段时间写的代码，就靠 PR 评审顺手抓到多少算多少。

AI 原生做法 扫描按计划在每一个接入的仓库上运行，使用当前最强的模型，发现在任何人阅读之前就已通过验证。每一条发现的处理方式与被突破的控制带相同：能装进一个 PR 的修复走评审关卡，更大的问题则写成 intent.md。覆盖度是从最近一次运行算起的，而不是从第一次算起。

开始动手

前置条件

PR 评审关卡和作为审批关卡的钩子（阶段 5：部署），这样发现才能像其他改动一样走评审。以及来自阶段 1：计划的 intent.md 格式，用于那些一个 PR 装不下的发现。

基础设施

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

如何执行

安全负责人接入各个仓库，并按仓库、服务或团队把它们组织成项目，这样从一开始就能明确发现的归属。
对最关键的几个仓库先跑一次全量扫描，包括那些以前被其他工具或更早的模型扫过的仓库。把首次扫描当作基线。首次扫描很可能会在被认为「干净」的代码里翻出问题。
为每个项目设定扫描周期。对于活跃开发的服务，每周一次是个合理的默认值；如果仓库很大或内容混杂，就把扫描范围收窄到某个目录或分支。
结合置信度评级来分诊发现。关闭时要写明理由，这样关闭动作有据可查，同一条发现也不会在下一次运行时以「新发现」的身份卷土重来。
对于范围明确的发现，在 Claude Code on the Web 中打开建议的补丁，评审它，然后像其他任何改动一样送进 PR 评审关卡。提出修复的那个智能体没有任何途径批准它。
对于超出单个补丁范围的问题，比如架构层面的弱点或跨服务重复出现的模式，按阶段 1 的格式写成 intent.md，从「计划」阶段重新开始。
当一个修复发布到生产环境后，为该漏洞类别向持续评估那一节的用例集中补一个评估，从此以后引导智能体的配置都会针对这一类问题接受测试。
把发现导出为 CSV 或 Markdown，或者使用 webhook，让组织既有的追踪与审计系统继续作为记录系统留在审计人员熟悉的位置上。

治理考量

扫描在组织的管理控制之下运行，也就是说接入了哪些仓库、谁持有扫描席位、支出上限是多少，全都由中心统一设定。每一条发现都有验证结果和置信度评级，每一次关闭都有理由，因此扫描历史本身就是一份审计记录，记录了发现了什么、修了什么、以及有意识地接受了什么。

修复通过 PR 评审关卡和分支保护抵达生产环境，而不是由扫描本身直接推上去。Claude Security 是对既有静态分析和依赖扫描的补充：确定性检查继续留在 CI 里，模型驱动的扫描则覆盖那些依赖上下文、确定性检查天生找不出来的漏洞。

用 Claude Tag 让 Claude 值班

事故也可能通过其他途径抵达，比如 Slack 或 Teams 这样的办公沟通软件。事故可能表现为晚上 10 点在事故频道里发的一条 Slack 消息，要求紧急修复——现在这类消息可以被立刻响应。Claude Tag（公开测试版，目前在 Slack 上可用）让 Claude 以自己的身份成为这些频道的成员，于是每一起新事故都有了第一响应人，而响应过程本身也成为循环的一部分、成为未来事故可参考的记忆。

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

事故并不是 Claude Tag 唯一承接的工作。无论是通过 MCP 在工单上被 @，还是直接在频道里被问到，Claude 都以同样的方式分诊这些工作：小而边界清晰的修复以 PR 形式经过评审关卡，更大的事情则写成 intent.md 交给阶段 1：计划——到这一步，循环就开始自我供给了。参见：Claude Tag 如何在 Anthropic 为 CI/CD 值班。

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

结语

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

这场转型让人的判断力始终处于流程的核心位置，同时兼顾了大型企业组织在治理与监管方面的要求。

本指南汇总了我们应用 AI 团队每天为客户实践的诸多真实最佳实践，希望它对你而言是一份实用且可落地的参考。

循环持续运转，而人的判断力始终居于其上。

资源与致谢

下面这些文档，是平台团队搭建上述控制措施所需要的，大致按照落地推行的顺序排列。

感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献，本指南的灵感与大量内容都建立在他们此前的工作之上。

English Original
AI 技术博客索引

本章目录

代码不再是瓶颈（Code is no longer the bottleneck）什么是 AI 原生 SDLC（What is an AI-native SDLC?）打法（Plays）规划（Plan）设计（Design）构建（Build）测试（Test）部署（Deploy）维护（Maintain）结语 Related Documents