AI 原生 SDLC 实践手册 | Claude by Anthropic

来源:https://claude.com/blog/the-ai-native-sdlc-playbook

代码不再是瓶颈

组织已经开始用 AI 写代码,速度之快在一年前难以想象,但代码周边的流程却没能跟上同样的节奏。

许多工程团队仍沿用同样的审批关卡、评审、交接和政策,拖慢了使用 Claude Code 这类智能体编码方案取得的效率收益。

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

传统 SDLC 流程繁重,是为了在每个步骤确保责任和管控。但传统 SDLC 的设计初衷,是在"写代码、实现代码"这一环节最耗时最费钱的年代最大化效率------如今情况已经变了。PRD、估时仪式、产品安全评审,所有这些存在的目的,是在可能长达数周、数月甚至数季度的开发工作中强制各方对齐。

传统 SDLC 的管控机制还假设每一步都由人完成。而从智能体 AI 中获得最大价值的组织,已经围绕 AI 目前能够完成的工作重新设计流程,同时确保人在关键决策中始终参与。本指南介绍了 Applied AI 团队在 SDLC 各阶段集成 Claude 的多项内部最佳实践;这些做法也吸收了我们与客户合作的经验,旨在加快开发并提升流程效率。

当代码不再是瓶颈、构建阶段跑得比传统 SDLC 允许的速度更快时,三件事变成现实:

瓶颈转移到构建阶段左右两侧的步骤:主要是规划、评审/测试和部署,这些仍在以人的速度运行。
原有管控方式开始脱离现实,并变得难以维系。当代码由人编写时,逐行评审还说得通;一旦大部分 diff 由智能体生成,人工评审就无法跟上。
治理成本上升,因为例外情况仍然要路由到每周或每月才开一次会的评审委员会。

构建不再是约束------围绕它的人速步骤才是。人速阶段维持原有周期,而构建塌缩到几小时内完成。

以安全瓶颈为例。安全团队的规模是按人的产出配置的,当智能体把代码产出放大数倍时,要么评审队列越积越长,要么代码在评审不足的情况下上线。受监管组织两种结果都不能接受,所以安全和策略检查必须跟上智能体的速度。

要充分释放智能体 AI 的生产力,同时确保其安全可控,传统 SDLC 必须经历与代码实现阶段同等程度的转型。

什么是 AI 原生 SDLC?

AI 原生 SDLC 是对软件开发流程的重新设计:保留原有的管控目标,但采用新的强制执行机制。流程不再线性流转,而是形成闭环,AI 嵌入每个节点。AI 原生 SDLC 支持自动交接并触发后续 play,从而改善传统 SDLC 阶段之间依赖人工、效率低下的交接方式。

你也会听到这种转变被叫作 agentic SDLC、AI SDLC,或干脆叫 agentic 软件开发------叫法不同,说的是同一件事。

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 breach)都被诊断并作为新的 `intent.md` 写回循环

贯穿右列的主线是"提交的产物"(committed artifact)。每个阶段结束时,向版本控制写入一份产物(包括 intent.md、spec.md、plan.md、diff 及其测试、带评审结论的 PR、事件记录),下一阶段从读它开始。早期阶段,.md 文件是主要产物,因为产品负责人和智能体能读同一份文件并据此行动。从构建阶段起,产物是代码及其记录。提交链本身也是审计轨迹:谁要求了什么、智能体产出了什么、谁批准了。

每个需要判断力的决策,最终责任人仍是人。在 agentic SDLC 世界里,人的注意力随待评审的产物一起移动。

每个阶段提交一份产物,下一阶段可读。intent、spec、plan、diff 和评审结论合在一起,就是审计轨迹。

Plays(实战打法)

plays 是本手册的核心,按六个非线性阶段(规划、设计、构建、测试、部署、维护)分组,合起来覆盖完整生命周期。

每个 play 涵盖:

改变了什么;
如何开始;
具体实施步骤;
治理考量;以及
如何衡量是否见效。

步骤是模块化的,组织可根据自身需要,在不同时间优先改造不同阶段。每个 play 在"Prerequisites"(前置条件)下列出依赖项,依赖图对此有进一步展示。

一个阶段以提交产物结束,该提交即触发下一阶段。被接受的 intent.md 触发需求和设计环节,被批准的 spec.md 触发 plan 模式,合并的 PR 触发流水线,生产环境的控制带越界则写下下一个 intent.md------循环就此持续。

最初,每个步骤由你手动提示;最终形态是一个循环:每份被接受的产物触发下一道关卡。人的注意力集中在关卡处,评审智能体标记出来的内容,而不是从头开始每个阶段。

play 按阶段列出;箭头给出采纳顺序。两者不是一回事。可以从任何"粘土色"play 开始------没有箭头指向它,说明它不依赖任何前置。对其他 play,指向它的箭头就是它之前应采纳的 play。

规划 Plan

想法不再等着有人把它写下来。意图(intent)只被捕获一次,用提出者自己的话,作为版本化产物交给下一阶段执行。

以 intent.md 捕获

启动软件开发流程的 intent.md 可以通过不同途径进入:一个人有了想法、提交了一张工单,或者一个告警暴露了事件(见阶段 6:维护)。

当一个人有想法时,他和 Claude 头脑风暴,产出一份 markdown 原型规格(proto-spec)。在传统 SDLC 中,这个人必须再去说服产品团队中的某个人,跟他一起或替他写下来。

Claude 生成的原型规格人类可读、有版本控制,下一阶段可直接消费。原型规格保存为 intent.md。

无论 intent 来自事件触发还是智能体,步骤都一样:产品负责人评审并修正智能体写的 intent.md,然后才提交。

传统想法要经过积压条目、用户故事、故事点、细化会议,才能有人动手。每次交接所有权就转移一次,到工程手里的东西,和提出者本意已经隔了好几层。

AI 原生提出者和 Claude 头脑风暴,把结果写成 intent.md------一份用提出者自己的话表达的原型规格。产物包含想要什么、为什么、在什么约束下。重复性流程编码为 skills。

开始上手

前置条件

无。

基础设施

为非工程师提供 Claude 访问(claude.ai 或 Cowork);一份约定的 intent.md 模板;一个共享的、有版本控制的 intent 存放处,由产品负责人盯守。对单一产品,最简单的存放处是产品仓库里的 intent/ 文件夹。这个设置让产物链紧挨着从它衍生出的代码。只有当 intent 横跨多个仓库时,独立的 intent 仓库才值得那点开销;在 monorepo 里,它就是一个目录。阶段 3:构建的侧栏会讲这个存放处和已有的 Jira 或需求工具如何相处。

这项设置是平台或工程团队的一次性任务。需要一位技术团队成员搭起 intent 存放处,决定谁有写入权------因为贡献者会来自组织各处。

仓库建好后,没有 git 经验的贡献者不需要直接用 git。通过一个版本控制系统的连接器(如 GitHub),Claude 可以代替他们从 claude.ai 或 Cowork 提交 markdown 文件。

如何执行

提出者用自己的话向 Claude 描述问题。可以说现在做不到什么、这个想法影响谁、更好的状态长什么样、哪些不在范围内。不需要正式语言。
头脑风暴直到想法具体化。Claude 会问分析师会问的问题:范围、用户、约束、成功长什么样。
让 Claude 用组织模板把结果写成 intent.md。模板可编码为一组 skill,由技术成员搭建、负责人签字认可。模板可覆盖:问题、预期结果、受影响的用户和系统、约束、待决问题。
提出者纠正 Claude 理解错的地方。
把 intent.md 提交到共享存放处。作者和时间戳进入记录,产品负责人从这里接手想法。

prism 复制代码

# 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 历史中。产品负责人批准;把 intent 送入阶段 2:设计的接受/拒绝决定,以合并(merge)或关闭评审(closed review)的形式记录。

如何衡量

先行指标

从第一次对话到 intent.md 提交的时间,可从 intent 存放处记录作者和时间戳的 git 历史中读取。预期可从数周的需求获取与细化周期缩短至几小时。

滞后指标

存活率:产品负责人接受进入阶段 2:设计、而非关闭的 intent.md 占比。接受/拒绝决定记录为产物的合并或关闭评审。另外还有:同一变更的首个 spec.md 提交之后,intent.md 又被修改了多少次。

设计 Design

需求与设计合并进一个会话。策略在写规格时就被应用,而不是几周后的评审里才发现。

需求与设计

产品负责人批准后,Claude 拿着被接受的 intent.md,产出一份需求和设计规格。整个过程由组织的skills(品牌、安全、合规、UX)引导。

产品负责人评审这份规格,但不写它。此流程的目标,是产出一份工程团队可以据此规划、并带有关注点标记的规格。

前端工作是最清晰的例子。intent.md 被接受后,产品负责人用 Claude Design(beta)根据 intent.md 做出设计稿,迭代草稿,然后导出到 Claude Code 去构建。

传统需求与设计是不同团队跑的两个独立阶段。分析师把想法形式化为需求,设计师再把需求解析回设计。这种分离为的是责任清晰,但既慢又有损耗。

AI 原生两个阶段发生在一个被提示的会话里。Claude 拿 intent.md 产出需求和设计规格,受组织 skills 约束,并标记关注点。

开始上手

前置条件

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

基础设施

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

如何执行

产品负责人打开一个可用组织 skills 的会话,附上 intent.md。
产品负责人的提示指向 intent.md,点明约束,要求标记关注点。先手动跑,然后固化为组织级斜杠命令。再往后,把 intent 存放处中 intent.md 被接受作为触发条件:一个非交互式任务在合并时触发,加载组织 skills 跑这一环节,以拉取请求的形式提交 spec.md(阶段 5:部署的 CI/CD play 覆盖管道细节)。从那时起,产品负责人的第一次介入就是评审。
仍由这位产品负责人对照原始想法评审规格:规格是否解决了所述问题?intent.md 中的待决问题是已经得到回答,还是被明确带入下一环节?
先处理标记的关注点------这些正是分析师会升级的点。产品负责人和每个关注点的策略负责人逐一对齐,之后才让工程看到规格。
把 spec.md 和 intent.md 一起提交。这一对文件记录了"要了什么"和"决定了什么"。
产品负责人决定规格和 intent 是否进入构建,对组织归类为较高风险的事项咨询技术负责人。这个决定永远由人类队友做出;接受规格就是启动阶段 3:构建中 plan 模式 play 的动作。

长什么样(提示词)

prism 复制代码

Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.

治理考量

现行策略在写规格时就被读取和应用,而不是几周后的评审里才发现。组织的 skills 作为约束施加于规格。规格、产出它的提示词、生效中的 skill 版本,全部记录在版本控制中。产品负责人签核规格,把标记的关注点路由给指定的策略负责人。

如何衡量

先行指标

同一变更的 intent.md 提交与 spec.md 提交之间的耗时(两个 git 时间戳),与旧的"需求+设计"周期对比。

滞后指标

构建开始后的需求返工。统计同一变更在首个 plan.md 提交之后的 spec.md 提交数。git log 直接给出。

构建 Build

没有经过批准的计划,就不进入实现。组织知识被沉淀为智能体可读取的文件,护栏则以代码形式执行,而不再依赖个人习惯。

Claude Code plan 模式作为默认起点

工程师以 plan 模式启动 Claude Code 会话,把阶段 2:设计批准的 spec.md 交给 Claude,让 Claude 通过提问向工程师澄清需求,并反复完善计划,直到工程师满意。

传统工程师读设计,然后开始写代码。改动怎么做------具体到改哪些文件、哪些测试------留在工程师脑子里,最多写在工单评论里。没有人能评审它。评审者看到的第一样东西是成品 diff,到那时返工已经很慢了。

AI 原生工作始于一份书面计划:Claude 在 plan 模式下产出它,此时它只能读代码库,不能改任何东西。工程师在写代码之前修正计划,批准版作为 plan.md 提交,供后续阶段对照检查。

开始上手

前置条件

如有 intent 产物(intent.md 或 spec.md),以及 CLAUDE.md 文件(有帮助)。

基础设施

能访问仓库的 Claude Code。

如何执行

工程师以 plan 模式和 Claude 开启会话。
工程师给 Claude intent.md 和 spec.md,要一份实施计划:点明要改的文件、工作顺序、证明成功的测试。
深入审视计划:追问这项改动可能破坏什么、哪一步风险最高,以及 Claude 排除了哪些备选方案。
迭代,直到一个从没看过这段对话的工程师也能仅凭计划实施改动。
把批准的计划提交为 plan.md。计划加入审计轨迹,PR 评审 play(阶段 5:部署)会拿最终 diff 对照它。
接受计划并让 Claude 实施。计划足够扎实时,实现往往可以一次完成。
实施偏离计划时,在同一提交里更新 plan.md。考虑用 hook 强制两者同步。

长什么样(plan.md)

prism 复制代码

# 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 模式本身强制执行这一点:Claude 在工程师接受计划前无法编辑文件。计划及其修订、以及谁接受了它,都记录在案。常规改动由工程师批准;组织归类为较高风险的事项交给技术负责人或架构师。

如何衡量

先行指标

首次实施一遍通过并合并的改动占比,以及从计划批准到 PR 合并的时间(所需数据在 PR 元数据里)。

滞后指标

每个改动的返工轮次(同样来自 PR 元数据),以及合并后的 diff 仍与已提交的 plan.md 相符的频率。

自动模式下的 Claude Code

Claude Code 也可以运行在 auto 模式下:工程师反复完善并批准计划后,Claude 应用每项改动时不再逐一请求确认。随着后续 play 中的护栏逐渐成熟(调优后的 CLAUDE.md、编码了策略的 skills、阻止危险动作的 hooks,以及 Claude 能运行的测试套件),自动接受会成为常规工作的默认选择,适用于范围明确的 spec.md、影响面较小且已有测试覆盖的代码。

重心从"盯着智能体做编辑、评审动作"转向"在更长的自主会话之后评审产物"。自动接受模式配合 worktrees,还能在个人和团队层面放大并行度;它是自主运行 SDLC、按阶段 6:维护所述闭合循环的基础。

侧栏

遗留系统与真相来源

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

现有 SDLC 流程很可能已经在追踪产物了,只是不在 markdown 文件里。工作项可能在 Jira,需求在内置监管可追溯性的工具里,设计在 Figma,变更审批挂在变更委员会。这些系统很难被取代------审计和监管机构已经接受它们,其他团队依赖它们------所以 AI 原生 SDLC 必须迁就现状。

向 AI 原生 SDLC 过渡时,对流程产出的每一份产物,指定一个系统为真相来源,其他系统只持有副本或指向原件的链接。以下配置可做到单一真相来源,选择因产物而异:

仓库作为真相来源。 markdown 产物是权威记录,遗留系统引用提交内的文件。对工程主导的组织,这是最干净的配置之一:所有记录在一个工具里,只有一个时间戳权威。

遗留系统作为真相来源。 Jira、ServiceNow 或需求工具持有权威记录,markdown 产物是工作副本。Claude 在会话开始时读取记录,通过 MCP 连接器,在产出 spec 或 plan 的同一会话里把结果写回。

链接是最低标准。 所有产物标注记录 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)

prism 复制代码

# 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 owners 在 PR 评审中批准这些改动。

如何衡量

先行指标

Claude 重复犯下本应被 CLAUDE.md 拦住错误的频率。对 CLAUDE.md 的修正或改动应在 git 历史中跟踪。

滞后指标

新成员从 PR 历史看,到首个合并 PR 的时间。

Skills 作为组织知识

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)

prism 复制代码

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

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

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

治理考量

skill 是一种控制,但只是建议性的。它让 Claude 在写代码时大概率应用策略,但没有任何机制强制会话遵守。必须始终成立的策略,需要在 skill 背后放确定性的东西,比如阻止该动作的 hook,或在 PR 处复检策略的评审环节。skill 让违规变罕见,hook 让违规几乎不可能。skill 调用记录在会话轨迹中,策略负责人像评审代码一样评审 skill 改动。

如何衡量

先行指标

从策略负责人批准策略改动,到更新后的 skill 合并的时间------从 skill 文件夹的 PR 上取。

滞后指标

PR 评审中引用该策略的发现数量,一旦 skill 在写代码时施加策略,这个数字应趋近于零。若没有趋近于零,要么 skill 没触发,要么它的文本已偏离官方策略。

Hooks 作为构建期护栏

skill 属于建议性控制,而 hook 是其背后的确定性执行层。Claude 的大部分动作,是实现过程中的文件编辑和 shell 命令,因此 hooks 在构建阶段触发得最频繁。

构建期 hooks 可以:

阻止对受保护路径的编辑,如生成类或冻结的包;
编辑文件后跑格式化和 lint,防止漂移累积;
防止凭据进入 diff。

凡是策略必须无条件成立的 skill,都在背后配 hook。hook 在每个匹配的动作上运行,所以构建期 hooks 要快,且限定在变更的文件上。更重的检查(如完整测试套件)属于提交或 PR 阶段。

需要人类批准的 hook 属于阶段 5:部署的关卡------构建期间的审批弹窗会把一个人重新放回所有并行会话的关键路径上。

并行会话与子智能体

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

并行会话是另一个完整的 Claude Code 实例,在独立的 git worktree 中处理另一项任务。各独立会话彼此并不知情,唯一的共同点是由同一名工程师统筹。

子智能体在单个会话内运行,是有自己上下文窗口和工具限额的受限助手,适合在多个任务中反复出现的活,比如验证应用按预期运行。

并行会话增加了一名工程师可同时推进的任务数量,子智能体则让每个会话专注于自己的任务。工程师负责统筹并评审这些工作。

传统一个工程师一次干一个任务,一天或一周里有相当大比例花在构建、测试和评审上。等待时切换任务不是不行,但上下文切换累人,没几个人愿意。

AI 原生一个工程师同时跑几个 Claude 会话,每个在各自的 worktree 里干各自的活。重复的活变成有自己上下文和工具限额的子智能体。工程师的职责转向编排,最终转向构建和监控循环。

开始上手

前置条件

CLAUDE.md------所有会话都要读它。反馈循环(阶段 4:测试)也有帮助:会话能自查工作时,对工程师监督的需求就少了。

基础设施

一个 git 仓库(隔离来自 worktrees),以及调好的权限设置,让会话不会因为组织认为安全的命令卡在审批弹窗上。

如何执行

工程师用 plan 模式 play(阶段 3:构建)的计划把工作拆成触碰不同文件的任务------计划能看出哪些工作彼此独立。共享文件的任务在单个会话里串行跑。
每个并行任务有自己的 worktree,例如一个终端跑 claude --worktree feature-auth,另一个跑 claude --worktree fix-rate-limit。worktree 是独立分支上的独立检出,防止会话在文件上互相碰撞。
两到三个会话是合理的起点。实际天花板是一个人能认真评审多少条流,所以只在评审跟得上的时候加会话。
把重复的活变成子智能体,定义在 .claude/agents/ 的 markdown 文件里,每个有名、有何时使用的描述、有可触碰的工具。例子:代码简化器(主智能体完成后剥离多余复杂度)、验证器(跑应用、检查行为)、研究员(探索代码库、回报结果,不淹没主上下文)。把定义提交进 git,全团队共享。

长什么样(.claude/agents/verifier.md)

prism 复制代码

---
name: verifier
description: Runs the app and checks the change works before the session
  reports done
tools: Bash, Read
---
Start the app with make run. Exercise the changed behavior and the two
nearest neighboring flows. Report what you ran, what you saw, and any
behavior that does not match plan.md. Do not fix anything; report only.

治理考量

会话越多,产出越多,所以控制必须来自仓库里的配置。那里的 hooks 和权限设置适用于所有会话,会话做了什么都被记录,并归属到运行它的工程师。

如何衡量

先行指标

在评审质量不下降的前提下,每名工程师的并发会话数(从 OpenTelemetry 导出中统计),以及一天中用于统筹会话而非等待的时间占比。

滞后指标

每个工程师每周合并的改动数,配合 PR 历史得出的返工率一起读。

测试 Test

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

给 Claude 一个反馈循环

永远给 Claude 一条自查工作的路:测试、构建,或截图对比。会话自查自纠,在工程师看到之前修掉自己的错误。

不要把反馈循环与验证器子智能体(阶段 3:构建)混为一谈。反馈循环贯穿整个任务,并根据工作需要反复运行;验证器子智能体则是一种封装最终检查的方式:当主会话认为任务完成后,再在全新的上下文窗口中运行一次。这样可以避免验证结论受到生成代码时那些先入假设的影响。

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

AI 原生会话在有人看到之前就有自查的路。跑测试、跑构建、截图。Claude 迭代直到检查通过,所以到工程师手里的东西已经通过检查了。搭这个循环是跑会话的工程师的活,下面的步骤就是写给他们看的。

开始上手

前置条件

无。

基础设施

一个测试套件和一个构建,各自一条命令本地可跑。UI 工作还需要让 Claude 看到结果的手段:浏览器工具,或经 MCP 接进来的截图工具。

如何执行

如果今天检查工作需要一串命令加一些环境知识,把它包进单一目标,如 "make test" 或 "npm test",失败时以非零码退出。
在 CLAUDE.md 的 Commands 部分列出每条命令,附健康输出示例。
给出目标并让它可量化,Claude 才能不问你就能自查。例如:"test_status.py 里所有测试通过"、"截图与附件 mock 一致"、"端点带新字段返回 200"。
修 bug 时先写失败测试。让 Claude 把 bug 复现成测试,跑它,确认它按你预期的方式失败。提交这个测试。然后才让 Claude 在不编辑测试的前提下让它通过------最后一步的测试文件 hook 强制这条限制。一个在修复前就存在、智能体无法改写的测试,就是 bug 已除的证据。
UI 工作用视觉检查闭合循环。给 Claude 浏览器或截图工具,给它 mock,让它迭代:实现、截图、对比、调整。两三轮是正常的,每轮都应更好。
把验证变成"完成"的一部分。指令写在 CLAUDE.md 里:报告任务完成前先跑测试,并贴出输出。
最后,循环本身需要保护------修代码的智能体不能削弱对它代码的检查。修复任务期间阻止编辑测试文件的 hook 能做到。替代方案是在评审中检查 diff,拒绝任何动了测试的改动。

长什么样(CLAUDE.md 验证块)

prism 复制代码

## Verifying your work

- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)

Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.

治理考量

强制了什么

任务报告完成前的验证,以及修复期间禁止智能体编辑测试文件------组织想确保的地方,两者都用 hooks 实现。

证据是什么

"make test" 的字面输出、构建日志,或 Claude 跑过并贴出的截图对比------证据来自工具链。

记录在哪里

会话转录中,由 OpenTelemetry 导出转发到组织的可观测性栈;以及 PR 的 check run 里,评审者和之后的审计者都能看到。

谁批准

评审 PR 的 code owner。机械证据已附上,他可以专注意图和风险。

如何衡量

先行指标

智能体写改动的首次 CI 通过率------CI 系统已支持。

滞后指标

每个 PR 的评审时间(来自 PR 元数据),一旦测试接住了评审者过去抓的问题,这个数字应下降;以及事件跟踪器里的变更失败率。

CI 中的持续评测(evals)

Evals 相当于 AI 原生 SDLC 中的阶段关卡式 QA。实际落地时,它是一套在智能体配置发生变化时运行的评测集。更换模型或重写提示词后,评测集需要回答一个问题:智能体还能否按照同样的标准完成工作?

evals 应被视为一套持续演进的评测集。随着模型进步,原本具有区分度的用例可能不再有效,此时需要把持续监控中新发现的用例补充进来。

根据用例不同,有些团队可能更愿意按固定节奏离线跑这些 evals,而不是每次变更都跑。以下步骤针对持续评测。

开始上手

前置条件

CLAUDE.md 和反馈循环(阶段 4:测试)。

基础设施

能非交互式跑 Claude Code 的 CI,以及有预算跑评测的 API key。

如何执行

平台工程师从近期工作中收集 20 到 50 个真实任务,连同其预期/被接受的结果。
把每个任务写成一条 eval:提示词加定义"可接受"的检查(测试通过、lint 干净、行为不变、策略被遵守)。
套件在 CI 中按计划非交互式运行,并在 CLAUDE.md、skills 或 hooks 有任何变更时运行------这些配置引导智能体,理应获得代码同等的回归测试。
用结果给配置变更把关。让通过率下降的 skill 改动,合并前先被评审。
每个生产事件都产出一条 eval,由事件归属团队撰写,作为回归测试留在套件里。

长什么样(.github/workflows/agent-evals.yml)

prism 复制代码

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 要多久。

滞后指标

CI 抓到的回归,与生产环境发现的回归(来自事件跟踪器)对比。

部署 Deploy

评审是双向的,治理则在智能体采取行动时同步执行。智能体可以完成生产关卡之前的所有工作,但不能越过该关卡。

PR 评审循环中的 AI

Claude 既评审他人提交的 PR,也处理自己所提 PR 收到的评审意见。它依据组织策略审查传入的 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 play 覆盖部署选项)。要求 code owner 批准的分支保护策略也值得配置。

如何执行

托管的 Code Review 服务是最快的起步方式。管理员启用服务并选择仓库。当需要掌控流水线,或希望 API 调用通过组织自己的云服务协议时,可使用 claude-code-action 在自有 CI 中运行评审(CI/CD play 会说明相关管道配置)。
技术负责人把评审策略写成仓库根目录的 REVIEW.md,按组织在意的环节划分:bug 和逻辑错误;安全与漏洞;对照 spec(需求 play 的 spec.md)、实施计划(plan 模式 play 的 plan.md)和设计原则的合规。REVIEW.md 还定义什么算 Important、什么算 Nit,以及跳过什么。
技术负责人设人类阈值。评审发现本身不批准也不阻止 PR,分支保护仍要求 code owner 批准。想用发现卡合并的平台工程师,可以读 check run 发布的严重度计数(机器可读的统计)。
评审者或作者在评审评论上 @claude 时,Claude 处理评论并推送修复。PR 线程同时记录请求和改动。这个修复循环走 claude-code-action。托管服务里,评论 @claude review 请求一次新评审。对 Claude 自己开的 PR,更进一步,让 Claude 看护 PR 直到合并。团队把循环包进自定义斜杠命令:清扫 PR 上未解决的评审评论和失败检查,处理并推送修复,直到 PR 变绿、只等 code owner 批准。
评审发现反馈回 CLAUDE.md。评审第二次标记同一错误时,修正作为该评审的一部分写进 CLAUDE.md;因为评审读 CLAUDE.md,从下一个 PR 起这个错就被抓住了。评审还会标记改动何时让 CLAUDE.md 过时了。
每月一次,技术负责人给发现评级来调优评审器,并在 REVIEW.md 里限制 Nit 数量。生成路径和 CI 已强制的内容排除在外。

长什么样(REVIEW.md)

prism 复制代码

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

如何衡量

先行指标

从 PR 创建到首次收到评审的时间,应缩短到几分钟;以及在无需人工修改分支的情况下得到解决的评审评论占比(相关数据直接记录在 git 中)。

滞后指标

合并前抓到的缺陷和漏洞,对比泄漏到生产的数量------来自 PR 历史和事件跟踪器。

Hooks 作为审批关卡

构建阶段用 hooks 当护栏,允许或阻止动作,没有人类参与(阶段 3:构建)。hook 也可以"询问":暂停动作直到特定的人批准------这正是发布把关需要的。

这个 play 放在阶段 5:部署,因为发布关卡是最清晰的用例;但 hooks 不限于部署:Claude 在哪儿行动,它们就在哪儿运行。例如,hooks 可以在阶段 3:构建阻止无变更工单就编辑迁移和基础设施,在阶段 4:测试阻止修复任务中编辑测试文件。

开始上手

前置条件

无。

基础设施

一份书面清单,列出变更流程所需的所有批准。

如何执行

工程领导层,连同变更管理和合规,列出必须保留的人类审批关卡:如变更管理签核、发布授权、受保护路径的编辑。
平台工程师把每个关卡表达成一个 hook:一个在 Claude 行动前运行的脚本,可以 allow(允许)、ask(询问)或 block(阻止)。
团队 hooks 放在 git 里的 .claude/settings.json;不可协商的 hooks 放在平台或 IT 管理员拥有的托管设置(managed settings)里,单个工程师关不掉。
阻止应该自我解释:当 hook 拦住一个动作,原因和审批路径要出现在 Claude 的输出里。

长什么样(.claude/settings.json)

prism 复制代码

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

关卡本身(.claude/hooks/production-gate.sh)

prism 复制代码

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
   if [ -z "$RELEASE_APPROVAL" ]; then
     echo "Production deploys need a release authorization." >&2
     exit 2 # exit 2 blocks the action; the message goes to Claude
   fi
fi
exit 0

治理考量

Hooks 就是审批关卡。关卡条件每次、对每个人都强制执行。允许和阻止决定带时间戳记录。关卡还定义什么算批准:已批准的变更工单,或发布经理的签核。

实操示例

受监管企业的托管设置

由平台团队经 MDM 或管理控制台部署;工程师无法编辑或覆盖其中任何一项。

prism 复制代码

{ "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 预先批准安全的内部开发循环,避免 deny 列表造成频繁的授权提示。

disableBypassPermissionsMode 加 allowManagedPermissionRulesOnly:没有工程师、项目文件或命令行参数能扩大规则。

sandbox 堵上权限堵不住的口子。工具层的 WebFetch deny 拦不住 shell 命令触网;OS 级域名白名单直接封死出站。

failIfUnavailable 和 allowUnsandboxedCommands 让沙箱成为闸门:sandbox 初始化失败时 Claude Code 拒绝启动;在沙箱内失败的命令不能在沙箱外重试。

credentials 堵上 deny 规则留下的口子。permissions.deny 管的是 Claude 的文件工具,但沙箱内的 shell 命令默认仍可能读 ~/.ssh 或 ~/.aws/credentials;这一块拒绝这些读取,并从每个沙箱命令的环境里剥掉指定的秘密。

allowManagedHooksOnly:本 play 的审批关卡是唯一会运行的 hooks;本地任何东西都不能添加或替换它们。

disableSideloadFlags 和 strictKnownMarketplaces:工程师机器上的每个 skill、智能体、hook 和 MCP server 都来自组织批准的插件市场,绝不来自家目录。

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

requiredMinimumVersion:低于批准下限的版本拒绝启动,控制由组织实际评估过的构建版本强制执行。

应把以上配置视为定制方案的起点,而不是可直接照抄的建议。每条 deny 规则都在安全性与开发效率之间做取舍,合适的平衡取决于仓库的数据分级。设置文档解释了每个配置项,包括托管环境专用项:code.claude.com/docs/en/settings

如何衡量(对 hooks 本身)

先行指标

在每个审批关卡上等待的时间。每个 hook 决定都带时间戳和 allow/block 判定写入 OpenTelemetry 导出,所以等待时间可按关卡查看。

滞后指标

引入 hooks 前后,绕过关卡进入生产环境的违规数量------数据来自事件跟踪器。

CI/CD 集成与部署

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

传统流水线跑确定性脚本,任何需要判断的活都等人类。例如:给 flaky 测试分诊、写 changelog、搞清构建为什么挂。部署和回滚是人扛着压力照 runbook 执行的。

AI 原生 Claude 在流水线内为非交互式的判断步骤运行,处在带限定凭据的沙箱里。部署工具通过 MCP 暴露给智能体,所以写代码、测代码的那个工作流,也能在组织按环境定义的关卡内上线它、回滚它。

开始上手

前置条件

PR 评审循环里的 Claude,和作为审批关卡的 hooks------自动化加速任何东西过闸之前,闸门必须存在。

基础设施

安装了 claude-code-action 的 CI 平台,或任何能够调用 claude -p 的 runner;模型可通过 API 访问,若流量必须保留在组织签订的云服务协议内,则可使用 Bedrock、Foundry 或 Vertex;还需要面向部署目标的 MCP servers,以及一套不含长期生产凭据、供智能体任务使用的沙箱配置。

如何执行

平台工程师从只读判断步骤开始。在流水线任务里用 claude -p 给失败的构建分诊、总结 flaky 测试、起草 changelog。
在现有关卡之后加写步骤,处理诸如修 lint、更新生成的文档、通过 @claude 提及回复评审意见等活。智能体写的任何东西都以 PR 形式通过分支保护进来,智能体没有任何路径直接推 main。
执行被沙箱化。智能体任务在容器里跑,受网络策略约束,使用短时限定 token,默认不持有生产凭据。
通过 MCP 暴露部署。Deploy、status、rollback 变成工具,按环境限定范围,智能体的部署能力是一个白名单,而不是一份带凭据的 shell 脚本。
按环境分层自主度。开发环境,智能体自由部署。生产环境,智能体准备发布,发布经理授权,一个 hook 强制生产关卡。staging 介于两者之间。
回滚应该是流水线里演练最多的路径:一条智能体能跑的命令,定期在 staging 演练。闭合循环 play(阶段 6:维护)在控制带越界时会调用这个回滚,所以它必须预先被验证。

长什么样(流水线步骤)

prism 复制代码

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log at out/build.log. Identify the most
    likely cause, say whether the failure looks flaky or real, and write a
    three-line summary for the PR thread." >> triage.md

治理考量

治理原则:智能体可以行动到生产关卡为止,不能越过它。以下控制强制执行这一原则。

分支保护把智能体写的任何东西变成 PR,没有直通 main 的路径。
生产部署 hook 阻止发布,直到指定的发布经理授权。每次非交互运行以智能体自己的身份行动,流水线日志把智能体做的和触发它的工程师做的区分开。
按环境的权限层级决定智能体在通往关卡的途中能做什么。

如何衡量

先行指标

无需呼叫人类就完成分诊的流水线失败占比------来自 CI/CD 流水线日志。

滞后指标

DORA 指标,CI 系统和部署工具已在产出。

维护 Maintain

循环闭合。一个触发器调用 Claude,调用路径上没有人类;它的发现以 intent.md 的形式重新进入流水线。

维护与闭合循环

到目前为止,我们讨论的是如何把 Claude 加进 SDLC 的每个阶段,每个阶段都需要人类启动最初的步骤。而这一阶段,重点转向让 Claude 自主运行,闭合循环。

例如,一个持续运行的监控智能体可以在 bug 工单创建后生成 intent.md,并依次流经需求、计划、构建、测试和评审阶段。阶段 6:维护以无头方式运行(headless),各阶段之间设置独立的置信度关卡------由确定性检查或对抗性评审智能体决定上一阶段的产出是继续流转,还是升级给人工处理。

传统维护是被动阶段。所有工单或事件都等人动手、重启流程。凌晨 3 点的告警可能被错过,工单可能躺在积压里直到有人拾起,复盘行动可能根本到不了代码库------如果又有火情插队的话。

AI 原生一个触发器------控制带越界、工单、频道消息或定时任务------在无人在路径上的情况下调用 Claude。Claude 诊断,只通过带关卡的路由行动,把发现写成 intent.md,然后按前述各阶段流转。人们分诊和评审这些工作,不再需要启动它。

闭合循环

一个确定性脚本盯着生产环境,控制带越界时调用 Claude。监控越界是循环自主运行模式的一个有用示例;本阶段末尾的 Claude Tag(公开 beta)部分则覆盖从其他渠道到达的工作。

开始上手

前置条件

intent.md 格式------它给循环一个结构化的重启输出。Claude 加速的 PR 评审、作为行动边界的 hooks,以及 CI/CD 的回滚路径(最高自主层级会调用它)。

基础设施

检测脚本可查询的指标存储(Prometheus、CI 系统的 API 或同类)、仓库的读访问、非交互式运行 Claude Code 的方式(在 CI 中),或接收 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 play 覆盖部署和模型访问选项。因为运行是无状态、非交互的,循环可以无人启动地开始和结束。
智能体把诊断写成阶段 1:规划格式的 intent.md,覆盖异常及其证据、预期结果、受影响的系统、待决问题。此后发现和任何其他东西一样走流水线。
服务负责人或值班工程师对队列进行分诊,并把产品层面的发现转交给产品负责人。处理决定可以是立即修复、排期处理或关闭;若决定关闭,则据此调整控制带以减少噪声。
修复上线后,给事件加一条 eval(持续评测 play),确保这类问题今后受到保护。

长什么样(例如 bands.yaml 监控 CI 测试失败率)

prism 复制代码

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 历史);以及同类事件的重复率------修复给评测套件加用例后,这个数字应下降。

示例

CI 测试失败率越 3σ 时,智能体隔离 flaky 测试或开回滚 PR,评审关卡做决定。
部署后 5xx 率在窗口内有部署的情况下越 3σ 时,智能体触发现有回滚流水线。
PR 周期时间触发漂移规则时,智能体给工程领导层写报告------说明这套框架对流程指标和生产指标同样有效。

检测保持确定性。控制带一旦越界就调用 Claude,层级决定它能做什么。

周期性代码库扫描

安全扫描只是特定模型在某一时点对代码库给出的判断,而其中两个变量都会过时:代码每周都在变化,新一代模型也可能发现上一代遗漏的漏洞。AI 原生的做法是按计划定期运行扫描,调用路径中无需人工介入;扫描发现则与其他代码库变更一样,经过同一套关卡。

Claude Security 是计划扫描的托管形态。连接 GitHub 仓库,扫描在 Anthropic 基础设施上用 Claude Mythos 5 运行,每条发现报告前先验证,并附置信度评级。建议的补丁在 web 版 Claude Code 中评审和应用。组织拿到发现,无需自己访问模型。

传统安全扫描是一个事件:发布或审计前启动一次扫描。报告进跟踪器,积压靠手工消化直到下一个事件。期间写出的代码,靠 PR 评审碰巧抓住什么算什么。

AI 原生扫描按计划对每个已连接仓库运行,用可用的最强模型,发现先验证再给人读。每条发现按控制带越界的处理方式:一个 PR 装得下的修复走评审关卡,更大的写成 intent.md。覆盖度从最近一次运行算起,而不是从第一次。

开始上手

前置条件

PR 评审关卡和作为审批关卡的 hooks([阶段 5:部署](#阶段 5:部署)),让发现像任何其他改动一样走评审。单个 PR 装不下的发现,用[阶段 1:规划](#阶段 1:规划)的 intent.md 格式。

基础设施

Claude Security 对 Claude Enterprise 组织开放公开 beta。它需要:在目标仓库上安装 Anthropic GitHub App(云托管 github.com)、启用 web 版 Claude Code、开启 Extra Usage 并设消费上限、给跑扫描的人 premium 席位、管理员在 claude.ai/admin-settings/claude-code 打开该功能。扫描按 Mythos 5 费率按量计费,消费上限应与仓库的大小和数量匹配。

如何执行

安全负责人连接仓库,按仓库、服务或团队组织成项目,让发现的归属从第一天就清楚。
对最关键的仓库跑第一轮全量扫描,包括之前被其他工具或更早模型扫过的。把第一轮当基线。第一轮很可能会在被认为干净的代码里浮出发现。
按项目设定计划。对活跃开发的服务,每周是合理的默认值;仓库大或混合时,把扫描限定到目录或分支。
拿着置信度评级分诊发现。带理由关闭,关闭被记录,同一条发现不会在下一轮作为新发现回来。
对有限的发现,在 web 版 Claude Code 打开建议补丁,评审它,像任何其他改动一样送进 PR 评审关卡。提议修复的智能体没有批准路径。
对超出单个补丁的发现------架构弱点、跨服务重复的模式------按阶段 1 格式写成 intent.md,从规划开始。
修复发布到生产后,给漏洞类别往持续评测 play 的套件里加一条 eval,从此引导智能体的配置就针对该类别被测试。
导出发现为 CSV 或 Markdown,或用 webhooks,让组织现有跟踪器和审计系统在审计者期待的地方继续做系统记录(system of record)。

治理考量

扫描在组织管理控制下运行:连接哪些仓库、谁持有扫描席位、消费上限多少,都集中设定。每条发现有验证结果和置信度评级,每次关闭有理由,所以扫描历史就是一份"发现了什么、修了什么、有意识地接受了什么"的审计记录。

修复通过 PR 评审关卡和分支保护到达生产,而非直接来自扫描。Claude Security 增强现有静态分析和依赖扫描。确定性检查留在 CI,模型驱动的扫描覆盖那些检查本就不为发现而建的、依赖上下文的漏洞。

如何衡量

先行指标

按计划运行的已连接仓库占比;从发现被报告到补丁进入 PR 评审关卡的时间------从扫描历史和 PR 元数据读取。

滞后指标

计划扫描发现的漏洞,对比生产或外部报告发现的------来自事件跟踪器;以及跑过多轮的仓库上每次扫描的发现趋势------修复和 evals 累积后应下降。

Claude Tag 在线值守

事件也可能从其他渠道到达,例如 Slack、Teams 等工作通信应用。它可能是一条晚上 10 点发在故障处理频道里的 Slack 消息,要求紧急修复;现在这类请求可以立即得到处理。Claude Tag(公开 beta,目前支持 Slack)让 Claude 以独立身份加入这些频道,使每个新事件都有第一响应者,并让响应过程成为后续事件闭环与记忆的一部分。

对话和组织知识保留在频道中,频道里的任何人都可以引导并处理响应过程。团队成员可以实时验证假设、探索新的可能性并展开调查,频道历史也增强了可审计性。借助 MCP 访问能力,Claude 可以验证指标是否回到基线、在线程中确认结果,并把复盘结论写入受版本控制的 lessons 文件,供后续调查使用。

事件不是 Claude Tag 接手的唯一工作。通过 MCP 被 @ 在工单上,或在频道里被问到时,Claude 用同样的方式分诊工作。一个小的、边界清楚的修复以 PR 形式通过评审关卡到达;更大的写成 intent.md 送进阶段 1:规划,至此循环开始自我喂养。参见:Claude Tag 如何在 Anthropic 为 CI/CD 在线值守。

频道就是审计轨迹:请求、诊断、人类授权和修复,都留在事件处理的地方。

结语

模型和框架已经变得更先进,让组织不仅能转型代码的生产方式,而是整个软件开发生命周期。

这场转型把人的判断保持为流程的核心,并顾及大型企业组织的治理与监管要求。

本指南汇集了 Applied AI 团队在日常客户合作中实践的多项真实最佳做法,希望它能成为一份实用且可直接采取行动的参考资料。

循环持续运转,人的判断始终负责把关。