AI / Programming Languages
AI 原生软件开发生命周期（SDLC）实战手册
一份覆盖规划、设计、构建、测试、部署与维护六个阶段的 AI 原生 SDLC 手册，说明如何以版本化工件、自动化评审、评估、Hooks 与人工审批构成可治理的开发闭环。
代码不再是瓶颈
组织已经开始用 AI 以一年前难以想象的速度编写代码，但围绕代码的流程并没有同步改变。许多工程团队仍沿用原来的审批关卡、评审、交接和政策，因此 Claude Code 等智能体编程方案带来的生产力提升被卡在流程里。
软件开发生命周期（SDLC）是让软件从构想到生产环境的全过程。大多数组织都采用某种六阶段流程：规划、设计、构建、测试、部署和维护。传统上，每一阶段都由不同角色独立负责：产品经理写需求，技术架构师把需求转成设计，工程师实现设计，受监管企业的 QA 团队负责验证，发布团队上线，运维团队监控运行状态。工作通过文档、工单和签字在各阶段之间流转。
传统 SDLC 流程繁重，是为了确保每一步都有责任归属和控制。但它诞生于这样一个时代：最耗时、最昂贵的环节是编写和实现代码。PRD、估算仪式和产品安全评审，都是为了让可能持续数周、数月甚至数季度的开发工作保持一致。
传统 SDLC 的控制机制还假定每一步都由人完成。最能从 AI 中获得价值的组织，已经开始围绕智能体能做的事重构流程，同时确保人仍在环路中。本指南结合 Anthropic Applied AI 团队与客户合作的经验，介绍在 SDLC 各阶段内部整合 Claude 的实践，以加速开发并让流程运转得更快。
当代码不再是瓶颈、构建阶段快到超出传统 SDLC 的承载能力时，会出现三件事：
- 瓶颈转移到构建阶段的左右两侧，主要是规划、评审/测试和部署；这些环节仍以人的速度运行。
- 控制机制不再符合现实，最终变得难以执行。当代码由人逐行写出时，逐行评审尚且合理；一旦大部分 diff 都由智能体生成，这种方式便跟不上了。
- 治理成本上升，因为例外情况仍要进入每周或每月才召开一次的会议和委员会。
以安全评审为例：安全团队的规模是按人类产出来配置的。当智能体让代码产量成倍增长时，要么评审队列不断堆积，要么代码在审查不足的情况下上线。受监管组织无法接受任何一种结果，因此安全和政策检查也必须跟上智能体的速度。
要充分实现智能体 AI 的生产力收益并保障其安全，传统 SDLC 必须经历与实现阶段同等程度的转型。
目录
什么是 AI 原生 SDLC？
AI 原生 SDLC 是一种重新设计的流程：它保留旧有控制目标，但换用新的执行方式。流程不再是一条直线，而是一个循环，AI 嵌入每个节点。它推动自动交接并触发后续动作，从而解决传统阶段之间人工交接笨重的问题。
这种转变也常被称为智能体 SDLC、AI SDLC 或智能体软件开发；名称不同，所指的是同一件事。
六个阶段如何改变
下表展示传统 SDLC 与 Claude 支持的 AI 原生 SDLC 两端形态。大多数组织实际处在两者之间。
| 阶段 | 传统 SDLC | AI 原生 SDLC |
|---|---|---|
| 规划 | 委员会收集需求，经研讨会和签字层层提炼，再由人手工写成文档 | Claude 直接从来源中综合痛点，写入人可读、机器可执行的 intent.md |
| 设计 | 分析师写规格，设计师再解析规格 | 需求和设计压缩进一次与智能体协作的工作会话；由技能中编码的标准约束，并在 Git 中版本化 |
| 构建 | 测试和代码由人手写，文档通常在主要开发完成后补写 | 测试和代码由 AI 生成，组织知识以版本化、机器可读的 CLAUDE.md 与技能维护 |
| 测试 | QA 在阶段边界设置关卡 | 持续评估贯穿实现过程 |
| 部署 | 人逐行评审全部代码，治理依赖评审周期且常不一致 | 多层智能体评审；人工评审留给受监管和关键代码。治理在 AI 行动时执行，以 Hooks 作为审批关卡 |
| 维护 | 人监控生产环境中的缺陷 | 智能体监控在线部署；任何越过控制带的异常都会被诊断并写回新的 intent.md，重新进入循环 |
右栏贯穿始终的主线是“提交后的工件”。每个阶段都以向版本控制写入工件结束——包括 intent.md、spec.md、plan.md、diff 与测试、带评审结论的 PR，以及事故记录；下一阶段则从读取该工件开始。早期阶段主要使用 Markdown 文件，因为产品负责人和智能体都能读懂并据此行动。从构建阶段起，工件则是代码及其记录。
这一连串提交也是审计轨迹：谁提出了什么、智能体生成了什么、谁批准了它。凡是需要判断的决定，仍由人负责。进入智能体 SDLC 后，人的注意力会随着待评审工件一起转移。
每个阶段都提交下一阶段可以读取的工件；意图、规格、计划、diff 与评审结论共同构成审计轨迹。
实战动作
本手册的核心动作被分到六个非线性阶段：规划、设计、构建、测试、部署和维护，合起来覆盖完整生命周期。每个动作都包括：
- 发生了什么变化；
- 如何开始；
- 具体实施步骤；
- 治理考虑；
- 如何衡量是否有效。
这些步骤是模块化的。组织可以根据自身需要，优先改造不同阶段。每个动作都会在“前置条件”中说明依赖，依赖关系图则给出进一步说明。
一个阶段以提交工件结束，这次提交会启动下一阶段：被接受的 intent.md 触发需求与设计流程；获批的 spec.md 触发计划模式；合并后的 PR 触发流水线；生产环境中突破控制带的信号写出下一个 intent.md，循环由此继续。
起初，你可以手动提示每一步；最终形态则是：每个获准工件自动触发下一道关卡。人的注意力集中在关卡上，评审智能体标记的问题，而不是从头启动每个阶段。
01 · 规划
想法不再等待某个人把它写成文档。意图只需捕获一次，以提出者自己的语言形成版本化工件，供下一阶段直接使用。
将想法捕获为 intent.md
启动软件开发流程的 intent.md 可以从不同路径进入：有人提出想法、有人创建工单，或监控告警暴露了一起事故（见第 6 阶段“维护”）。当一个人有了想法时，他可以与 Claude 头脑风暴并产出 Markdown 原型规格；而在传统 SDLC 中，同一个人还必须先说服产品团队成员与其一起、或代其把想法写出来。
Claude 生成的原型规格既可供人阅读、受版本控制，也能立即交给下一阶段使用，并保存为 intent.md。无论意图来自事件触发器还是智能体，步骤都一样：在提交前，产品负责人必须评审并修正智能体写出的 intent.md。
| 传统方式 | AI 原生方式 |
|---|---|
| 一个想法要先经过待办条目、用户故事、故事点和细化会议，之后才有人能够行动。每次交接都转移所有权，最终到达工程团队的信息已与提出者的本意相隔数层。 | 提出者与 Claude 一起头脑风暴，再把结果写成 intent.md：一份用提出者自己的语言写成的原型规格，说明想要什么、为什么需要，以及有哪些约束。重复流程编码为技能。 |
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 无 |
| 基础设施 | 为非工程人员提供 Claude（claude.ai 或 Cowork）；约定 intent.md 模板；建立产品负责人会关注的、共享且受版本控制的意图存放处。单一产品最简单的做法是在产品仓库中使用 intent/ 目录，让工件链与由它生成的代码相邻。只有当意图横跨许多仓库时，独立意图仓库的额外开销才值得；在 monorepo 中，它只是一个目录。第 3 阶段“构建”的侧栏说明了这一位置如何与已经保存正式记录的 Jira 或需求工具配合。 |
这项设置是平台或工程团队的一次性工作。技术团队成员需要建立意图存放处，并决定谁有写入权限，因为贡献者会来自组织各处。仓库建好后，不熟悉 Git 的贡献者不必直接操作 Git；他们可以通过版本控制系统连接器（如 GitHub）让 Claude 从 claude.ai 或 Cowork 代为提交 Markdown 文件。
如何执行
- 提出者用自己的话向 Claude 描述问题：今天做不到什么、谁受影响、改善后的样子，或哪些内容不在范围内；不要求正式术语。
- 持续头脑风暴，直到想法足够具体。Claude 会提出分析师通常会问的问题：范围、用户、约束和成功标准。
- 让 Claude 按组织模板写出
intent.md。模板可由技术团队成员做成技能并由负责人批准，涵盖问题、预期结果、受影响用户与系统、约束和未决问题。 - 提出者修正 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 阶段“设计”的接受或拒绝决定，则记录为合并或关闭评审。
如何衡量
| 指标 | 说明 |
|---|---|
| 领先指标 | 从第一次对话到提交 intent.md 的时间，可由记录作者和时间戳的 Git 历史读取；预期从数周的需求获取与细化周期缩短到数小时。 |
| 滞后指标 | 存活率，即产品负责人接受并送入设计阶段、而不是关闭的 intent.md 占比；决定记录为工件合并或评审关闭。另一个指标是同一变更首次提交 spec.md 之后，对 intent.md 做出的修改次数。 |
02 · 设计
需求和设计被压缩进一次工作会话。政策在规格编写时应用，而不是数周后才在评审中发现。
需求与设计
产品负责人批准 intent.md 后，Claude 根据它生成需求与设计规格。整个过程由组织针对品牌、安全、合规和 UX 编写的技能引导。
产品负责人负责评审规格，但不亲自编写。目标是产生一份工程团队可据以规划的规格，并标记值得关注的领域。前端工作最直观：intent.md 获批后，产品负责人可在 Claude Design（beta）中据此制作设计稿、迭代，然后导出到 Claude Code 实现。
| 传统方式 | AI 原生方式 |
|---|---|
| 需求与设计由不同团队分阶段进行。分析师把想法形式化成需求，设计师再把需求解析回设计。分离是为了问责，却缓慢且容易失真。 | 两个阶段在一次提示会话中完成。Claude 读取 intent.md，在组织技能的约束下生成需求与设计规格，并标记关注点。 |
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 已有 intent.md；品牌、安全、合规和 UX 政策已写成技能。 |
| 基础设施 | 一名可以使用 Claude 的产品负责人；不要求工程技能。 |
如何执行
- 产品负责人打开一个可使用组织技能的会话，并附上
intent.md。 - 提示中指向
intent.md、列出约束，并要求标出关注点。起初手动运行，随后将其固化为组织级斜杠命令；再进一步，可把意图仓库中intent.md的接受作为触发器：在合并时启动非交互作业，加载组织技能运行流程，并以 PR 形式提交spec.md（第 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.治理考虑
实时政策会在规格编写时读取并应用，而不是数周后才在评审中发现。组织技能作为规格的约束。规格、生成规格的提示，以及当时生效的技能版本都记录在版本控制中。产品负责人签署规格，并把标记的问题交给对应政策负责人。
如何衡量
| 指标 | 说明 |
|---|---|
| 领先指标 | 同一变更的 intent.md 提交与 spec.md 提交之间的耗时（两个 Git 时间戳），与旧有的需求加设计周期比较。 |
| 滞后指标 | 构建开始后的需求返工：统计同一变更首次提交 plan.md 后产生的 spec.md 提交，Git 日志可直接给出。 |
03 · 构建
没有被接受的计划，就不实施任何内容。组织知识成为智能体会读取的文件；护栏以代码执行，而不是依赖习惯。
默认从 Claude Code 计划模式开始
工程师以计划模式启动 Claude Code 会话，交给它第 2 阶段已批准的 spec.md，让 Claude 反过来访谈工程师并反复迭代计划，直到工程师满意。
| 传统方式 | AI 原生方式 |
|---|---|
| 工程师读完设计就开始写代码。如何修改、涉及哪些文件和测试，通常只存在于脑中，最多留在工单评论里，无法供他人评审。评审者第一次看到的是完成后的 diff，此时返工代价已经很高。 | 工作从书面计划开始。Claude 在计划模式中读取代码库但不能修改；工程师在写代码前纠正计划，把批准版提交为 plan.md，供后续阶段核对。 |
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 如有意图工件，则提供 intent.md 或 spec.md；CLAUDE.md 也会有帮助。 |
| 基础设施 | 能访问仓库的 Claude Code。 |
如何执行
- 工程师以计划模式开始 Claude 会话。
- 把
intent.md与spec.md交给 Claude，要求它给出实现计划，明确要改的文件、工作顺序，以及证明实现正确的测试。 - 追问计划：可能破坏什么？哪一步风险最高？Claude 放弃了哪些其他方案？
- 持续迭代，直到一个从未看过对话的工程师也能仅凭计划完成实现。
- 把批准后的计划提交为
plan.md。它成为审计轨迹的一部分，第 5 阶段的 PR 评审会把最终 diff 与计划对照。 - 接受计划并让 Claude 实现。计划足够扎实时，实现通常一次即可完成。
- 如果实现偏离计划，在同一次提交中更新
plan.md。可考虑用 Hook 强制两者同步。
plan.md 示例
# Plan: claims status self-service (from intent.md 2026-06-02)
## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py
## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.
## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.
## Proof
test_status.py covers the four claim states; screenshot matches the
approved mock.治理考虑
设计评审发生在生成代码之前，此时改方向仍只是编辑文档。计划模式本身会执行这一点：工程师接受计划前，Claude 不能编辑文件。计划及修订、接受者都被记录。常规变更由工程师批准；组织定义的高风险事项交给技术负责人或架构师。
如何衡量
| 指标 | 说明 |
|---|---|
| 领先指标 | 第一次实现就能合并的变更占比，以及从计划批准到 PR 合并的时间；所需数据位于 PR 元数据中。 |
| 滞后指标 | 每项变更的返工轮次，以及合并后的 diff 与已提交 plan.md 的匹配程度，同样来自 PR 元数据。 |
Claude Code 自动模式
Claude Code 也可以在自动模式下运行：工程师先审批并迭代计划，满意后，Claude 无需为每次编辑单独请求许可即可应用变更。随着后续动作中的护栏逐渐成熟——调优后的 CLAUDE.md、编码政策的技能、阻止不安全操作的 Hooks，以及 Claude 可以自行运行的测试套件——自动接受会成为常规工作的默认方式：紧凑的 spec.md、较小的影响范围，以及已有测试覆盖的代码。
工作方式也会从用户盯着智能体逐项编辑、审批每个动作，转向在更长时间的自主会话后评审工件。配合 worktree，自动接受还能让个人与团队开展并行工作，并且是第 6 阶段所述自主运行 SDLC、闭合循环的基础。
侧栏：遗留系统与事实来源
适用于流程产生的每一种工件。
现有 SDLC 很可能已经在追踪这些工件，只是它们并非 Markdown 文件：工作项在 Jira，需求在具备监管追溯能力的工具中，设计在 Figma，变更审批在变更委员会。审计方、监管方和其他团队已经接受并依赖这些系统，很难替换，因此 AI 原生 SDLC 必须适配现状。
转型时，应为每类工件指定唯一事实来源，其他系统只保存副本或原始记录链接。选择可以因工件而异：
- 以仓库为事实来源。 Markdown 工件是权威记录，遗留系统引用具体提交中的文件。这对工程主导的组织最清晰，因为所有记录共用一套工具和时间戳来源。
- 以遗留系统为事实来源。 Jira、ServiceNow 或需求工具保存权威记录，Markdown 只是工作副本。Claude 在会话开始时读取记录，并在生成规格或计划的同一会话中，通过 MCP 连接器写回结果。
- 至少建立链接。 所有工件写明记录 ID，所有遗留记录写入 Markdown 文件的 commit SHA。这适合转型初期，即使暂时存在两个事实来源。
两类系统可以共存，前提是彼此有链接，或明确声明其中一个为事实来源。
CLAUDE.md
CLAUDE.md 为 Claude 提供新成员入职时需要的上下文，包括约定、命令、架构和团队最常遇到的错误。过去存在于人脑和 Wiki 中的知识，变成智能体每次会话开始都会读取的文件；全团队共同维护，并在每次出现错误后迭代。
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 无 |
| 基础设施 | 一个仓库、已安装的 Claude Code，以及一位熟悉代码库的工程师。 |
如何执行
- 在仓库中运行
/init，Claude 会根据发现的内容生成初始CLAUDE.md。 - 把生成文件精简到新成员第一天所需的内容：构建、测试和 lint 命令，重要约定，以及 Claude 反复犯错的地方。
- 把根目录的
CLAUDE.md纳入 Git，让全团队共享同一版本，变更像代码一样接受评审。 - 建立一条工作规则：Claude 对同一件事错两次，就把纠正方式写进
CLAUDE.md。 - 控制在一页以内。Claude 每次会话开始都会读取全部内容；过期信息只会无谓占用上下文。
CLAUDE.md 示例
# Payments service
## Commands
- Build: make build
- Test: make test (unit), make itest (integration, needs docker)
- Lint: make lint (runs in CI; fix before pushing)
## Conventions
- Java 21, Spring Boot 3. No new Lombok.
- Money is always BigDecimal, never double.
- Every endpoint needs an integration test in src/itest.
## Architecture
- api/ holds REST controllers, core/ holds domain logic,
adapters/ talks to external systems.
- Kafka events are defined in schemas/; never edit generated classes.
## Things Claude gets wrong
- Do not bump dependency versions; the platform team owns them.
- The legacy v1/ package is frozen; changes go in v2/.治理考虑
CLAUDE.md 受版本控制，智能体所遵循的指令因此可评审、可审计。团队约定通过该文件应用，变更记录在 Git 历史中，并由代码所有者在 PR 评审时批准。
| 指标 | 说明 |
|---|---|
| 领先指标 | Claude 重复犯下本应由 CLAUDE.md 避免的错误次数；对文件的纠正和修改应在 Git 历史中追踪。 |
| 滞后指标 | 新成员从加入团队到合并第一个 PR 的时间，可从 PR 历史读取。 |
以技能承载组织知识
技能让组织知识真正进入日常操作：指令明确、受版本控制、广泛应用，并在政策变化时集中更新。经验法则是：必须一致应用的组织知识应写成技能；属于仓库上下文的内容写入 CLAUDE.md，一次性内容留在提示中。
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 无。已有 CLAUDE.md 会有帮助，但技能不依赖它。 |
| 基础设施 | 一项有明确负责人和书面事实来源的政策。 |
如何执行
- 选择一项当前执行不一致的知识，例如安全标准、API 设计约定或品牌规则。
- 将其写成技能：一个包含
SKILL.md的目录，frontmatter 说明何时触发，正文说明如何行动。工程师依据政策负责人的事实来源编写，并可让 Claude 协助。 - 将技能放在仓库的
.claude/skills/<name>/中随代码分发，或通过插件在组织内统一分发。 - 测试技能是否触发。用不同方式让 Claude 执行相关任务，确认每次都会加载。
- 政策变化时更新技能，并由政策负责人批准。
- 工程师下次会话自动获得新版本。
.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.治理考虑
技能是一种控制，但属于建议性控制：它提高 Claude 在编写代码时应用政策的概率，却不能强制会话遵守。必须始终成立的政策，应在技能之后配置确定性机制，例如阻止操作的 Hook，或在 PR 中重新检查政策的评审流程。技能让违规变少，Hook 让违规近乎不可能。技能调用记录在会话追踪中，政策负责人像评审代码一样评审技能变更。
| 指标 | 说明 |
|---|---|
| 领先指标 | 从政策负责人批准变更到更新后的技能合并所需时间，取自技能目录的 PR。 |
| 滞后指标 | 引用该政策的 PR 评审发现数；技能能在写代码时正确应用政策后，该值应趋近于零。若没有下降，说明技能未触发或文本已偏离正式政策。 |
以 Hooks 作为构建期护栏
技能是建议性控制，Hook 则是背后的确定性层。Claude 实现功能时的大多数动作都是文件编辑和 Shell 命令，因此 Hook 最常在构建阶段触发。构建期 Hook 可以：
- 阻止编辑生成类或冻结包等受保护路径；
- 每次编辑后运行格式化和 lint，避免偏差累积；
- 防止凭据进入 diff。
凡政策必须无例外成立，就应在技能背后配置 Hook。Hook 会对每个匹配动作运行，因此构建期 Hook 应快速且只针对变更文件；完整测试套件等重型检查应放在提交或 PR 阶段。
要求人工审批的 Hook 应放在第 5 阶段“部署”的关卡中；如果构建时不断弹出审批，会让人重新回到所有并行会话的关键路径上。
并行会话与子智能体
一名工程师可以同时推动多条工作流。
并行会话是另一个完整的 Claude Code 实例，在独立的 Git worktree 中执行不同任务。各会话彼此一无所知，唯一共享的是负责引导它们的工程师。
子智能体 则在单个会话内部充当范围受限的助手，拥有自己的上下文窗口和工具限制，适合在多个任务中重复出现的工作，例如验证应用是否按预期运行。
并行会话提高一名工程师同时在途的任务数，子智能体则让每个会话专注于自身任务；工程师的职责变为引导并评审它们。
| 传统方式 | AI 原生方式 |
|---|---|
| 一名工程师一次做一个任务，日常大量时间花在等待构建、测试和评审。虽可在等待时切换任务，但上下文切换很累，实际很少有人这么做。 | 一名工程师同时运行多个 Claude 会话，每个会话在自己的 worktree 中处理独立任务；重复工作变成有独立上下文和工具限制的子智能体。工程师的工作转向编排，最终转向构建和监控循环。 |
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 所有会话都会读取的 CLAUDE.md；第 4 阶段的反馈循环也很有帮助，因为能自行验证的会话需要的人工监督更少。 |
| 基础设施 | Git 仓库，以及调优后的权限设置；隔离依赖 worktree，组织认为安全的命令不应反复等待批准。 |
如何执行
- 工程师借助计划模式产出的计划，把工作拆成修改不同文件的任务。共享文件的任务应在同一会话中依次执行。
- 每个并行任务使用独立 worktree，例如在一个终端运行
claude --worktree feature-auth，另一个运行claude --worktree fix-rate-limit。独立检出与分支可避免会话修改同一文件发生冲突。 - 从两到三个会话开始。实际上限取决于一个人能认真评审多少条工作流；只有当评审跟得上时才增加会话。
- 将重复工作改成子智能体，定义在
.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 历史中的返工率一起观察。 |
04 · 测试
每个会话都在交给人之前验证自己的工作；引导智能体的配置，也要像智能体写出的代码一样接受回归测试。
给 Claude 一个反馈循环
始终让 Claude 有办法验证自己的工作，无论是测试、构建，还是截图差异。会话应在工程师看到结果前自行检查并修正错误。
反馈循环不要与第 3 阶段的验证子智能体混淆。反馈循环贯穿整个任务，工作迭代多少次就运行多少次；验证子智能体则是在会话认为完成后，以全新上下文执行最终检查的一种封装方式。这样，判断不会被生成代码时形成的假设影响。
| 传统方式 | AI 原生方式 |
|---|---|
| 代码是否有效的信号来得很晚：CI 在几分钟后、测试人员在几天后、生产环境在几周后。智能体写代码时，晚到的信号迫使人检查全部输出，人就成了瓶颈。 | 会话在交给人之前就具备自检手段：运行测试、运行构建、截取截图。Claude 反复迭代直到检查通过，因此到达工程师手中的结果已经验证。反馈循环由运行会话的工程师建立。 |
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 无 |
| 基础设施 | 测试套件与构建都能各用一条本地命令运行。UI 工作必须让 Claude 看得到结果，可使用浏览器工具或通过 MCP 接入截图工具。 |
如何执行
- 如果当前验证需要一串命令和环境知识，把它封装成
make test或npm test之类的单一目标，失败时以非零状态退出。 - 在
CLAUDE.md的 Commands 一节列出每条命令和健康输出示例。 - 给出可量化目标，让 Claude 无需询问即可判断，例如“
test_status.py的全部测试通过”“截图与附带 mock 一致”或“端点返回 200 且包含新字段”。 - 修复缺陷时，先写失败测试。让 Claude 把缺陷复现成测试，运行并确认它因预期原因失败，然后提交测试。之后让 Claude 在不修改测试的前提下使其通过，并用最后一步的测试文件 Hook 强制执行。修复前已经存在、且智能体不能改写的测试，才是缺陷已消失的证据。
- UI 工作用视觉检查闭环。给 Claude 浏览器或截图工具以及 mock，让它“实现—截图—比较—调整”。两三轮很正常，结果应逐轮改善。
- 把验证纳入“完成”的定义，在
CLAUDE.md中要求报告完成前运行测试并展示输出。 - 最后还要保护反馈循环本身，因为修改代码的智能体不能同时削弱检查。可用 Hook 阻止修复任务编辑测试文件；或者在评审中检查 diff，拒绝任何触及测试的变更。
CLAUDE.md 中的验证块
## Verifying your work
- Build: make build (must finish with "Build succeeded")
- Test: make test (all green; never skip or delete a failing test)
- Lint: make lint (zero warnings)
Run all three before reporting any task complete, and paste the output.
If a test fails, fix the code, not the test.治理考虑
| 项目 | 说明 |
|---|---|
| 强制内容 | 报告任务完成前必须验证；修复任务中禁止智能体编辑测试文件。组织需要保证时，两者都以 Hook 实施。 |
| 证据 | Claude 实际运行并粘贴的 make test 输出、构建日志或截图差异，证据直接来自工具链。 |
| 记录位置 | 会话记录；OpenTelemetry 导出会转发到组织可观测性栈，同时也进入 PR check run，评审者和日后审计者都能查看。 |
| 批准者 | 评审 PR 的代码所有者。机械证据已经附上，因此其注意力可以集中在意图和风险。 |
| 指标 | 说明 |
|---|---|
| 领先指标 | 智能体编写的变更第一次 CI 即成功的比例，CI 系统已有该数据。 |
| 滞后指标 | 每个 PR 的评审时间（来自 PR 元数据），以及事故追踪器中的变更失败率。测试接管评审者过去负责发现的问题后，前者应下降。 |
CI 中的持续评估
评估（evals）是 AI 原生阶段关卡式 QA 的对应物。实践中，它是一套在智能体配置变化时运行的测试：换用新模型或改写提示后，评估套件会判断智能体是否仍能按同一标准完成工作。
评估应视为持续演进的套件。模型提升后，过去能区分好坏的案例可能失去区分度，必须不断加入监控过程中出现的新案例。有些团队会根据场景选择定期离线运行，而不是每次变更都运行；下面步骤针对持续评估。
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | CLAUDE.md 和反馈循环。 |
| 基础设施 | 能以非交互方式运行 Claude Code 的 CI，以及为评估运行设置了预算的 API 密钥。 |
如何执行
- 平台工程师从近期工作中收集 20～50 个真实任务及其预期或已接受结果。
- 把每个任务写成评估：提示，加上定义“可接受”的检查——测试通过、lint 干净、行为不变、政策被遵循。
- 套件按计划在 CI 中非交互运行，并在
CLAUDE.md、技能或 Hooks 发生任何变化时运行；这些配置会引导智能体，理应像代码一样接受回归测试。 - 用结果为配置变更设置关卡。导致通过率下降的技能变更，必须评审后才能合并。
- 每起生产事故都要变成一个评估，由负责该事故的团队编写，并永久留在套件中作为回归测试。
.github/workflows/agent-evals.yml 示例
name: Agent evals
on:
pull_request:
paths: ['CLAUDE.md', '.claude/**']
schedule:
- cron: '0 2 * * *'
jobs:
evals:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install -g @anthropic-ai/claude-code
- name: Run eval suite
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
for eval in evals/*.json; do
claude -p "$(jq -r '.prompt' $eval)" \
--allowedTools "Read,Edit,Bash(make test)" \
--output-format json > result.json
./evals/check.sh "$eval" result.json
done治理考虑
评估为 QA 提供能跟上智能体输出的关卡。通过率阈值作为合并检查强制执行；每次运行都有日志，可随时间比较；由拥有配置变更的团队批准。
| 指标 | 说明 |
|---|---|
| 领先指标 | 套件每次运行报告的评估通过率趋势，以及生产事故变成永久评估所需时间。 |
| 滞后指标 | CI 捕获的回归与生产环境发现的回归之比，数据来自事故追踪器。 |
05 · 部署
评审双向运行，治理在智能体行动时执行。智能体可以完成生产关卡之前的一切，但不能越过关卡。
把 AI 放进 PR 评审循环
Claude 既提供评审，也接受评审：它根据组织政策评审传入的 PR，并自行处理自己 PR 上的评审意见。工程师因此可以把 PR 评审集中到行为层面，即判断意图和风险。
| 传统方式 | AI 原生方式 |
|---|---|
| 评审能力按人类产出来规划。PR 等待评审者逐行阅读；质量随评审者负载变化；作者不断催促，积压持续增长。 | 所有 PR 接受同一组评审流程，发现按严重程度排序。人的注意力上移到变更是否符合计划意图，以及风险是否可接受。 |
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 第 3 阶段更新后的 CLAUDE.md；如果评审流程执行书面政策，则还需技能和已定义的子智能体。 |
| 基础设施 | 已安装 Claude 集成的仓库：可由管理员启用托管的 Code Review（研究预览），或在自有 CI 中运行 claude-code-action；必要时通过 AWS Bedrock、Google Vertex 或 Microsoft Foundry 发起模型调用。还应配置要求代码所有者批准的分支保护。 |
如何执行
- 最快的起点是托管 Code Review：管理员启用并选择仓库。如果需要控制流水线，或让 API 调用经过自有云协议，则在 CI 中使用
claude-code-action。 - 技术负责人把评审政策写在仓库根目录的
REVIEW.md，按组织关心的检查拆分：缺陷与逻辑错误；安全与漏洞；相对于需求规格spec.md、实现计划plan.md和设计原则的合规性。文件还要定义什么是 Important、什么只是 Nit，以及哪些内容跳过。 - 技术负责人设置人工门槛。评审发现本身不能批准或阻止 PR，分支保护仍要求代码所有者批准。若平台工程师希望根据发现阻止合并，可以读取 check run 发布的、机器可读的严重程度计数。
- 评审者或作者在评审评论中提及
@claude时，Claude 会处理评论并推送修复；PR 线程记录请求和修改。该循环通过claude-code-action运行。在托管服务中，评论@claude review可请求重新评审。对于 Claude 自己创建的 PR，还可以让它持续照看直到可合并：团队可用自定义斜杠命令反复扫描未解决评论和失败检查，修复并推送，直到 PR 变绿，只等代码所有者批准。 - 评审发现要反馈进
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 作为无需人工参与的护栏，允许或阻止操作。Hook 也可以选择“询问”，暂停操作，直到特定人员批准；这正是发布关卡需要的能力。
这个动作放在部署阶段，因为发布关卡是最清晰的例子，但 Hooks 并非部署专属：Claude 在哪里行动，它们就在哪里运行。例如，构建阶段可阻止在没有变更工单时编辑迁移或基础设施；测试阶段可阻止智能体在修复任务中修改测试文件。
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 无 |
| 基础设施 | 一份书面清单，列出变更流程要求的全部审批。 |
如何执行
- 工程管理层与变更管理、合规团队共同列出必须保留的人工审批关卡，例如变更管理签字、发布授权和受保护路径编辑。
- 平台工程师把每道关卡表达为 Hook，即在 Claude 行动前运行、可以允许、询问或阻止的脚本。
- 团队 Hooks 放入 Git 中的
.claude/settings.json；不可妥协的 Hooks 放入平台或 IT 管理员持有的托管设置，个人工程师无法关闭。 - 阻止决定应说明原因。Hook 停止操作时，原因和申请批准的路径要显示在 Claude 输出中。
.claude/settings.json 示例
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh" }
]
}
]
}
}关卡脚本 .claude/hooks/production-gate.sh
#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
if [ -z "$RELEASE_APPROVAL" ]; then
echo "Production deploys need a release authorization." >&2
exit 2 # exit 2 blocks the action; the message goes to Claude
fi
fi
exit 0治理考虑
Hooks 就是审批关卡。关卡条件每次对所有人强制执行；允许和阻止决定记录时间戳。关卡也定义什么算批准，例如获批的变更工单或发布经理签字。
示例：受监管企业的托管设置
由平台团队通过 MDM 或管理控制台部署；工程师不能编辑或覆盖。
{ "permissions": { "deny": [ "Read(.env*)", "Read(./secrets/**)", "WebFetch", "Bash(curl *)", "Bash(wget *)" ], "allow": [ "Bash(git *)", "Bash(make build)", "Bash(make test)", "Bash(make lint)" ], "disableBypassPermissionsMode": "disable" }, "allowManagedPermissionRulesOnly": true, "sandbox": { "enabled": true, "failIfUnavailable": true, "allowUnsandboxedCommands": false, "network": { "allowedDomains": ["git.internal.example.com", "registry.npmjs.org"] }, "credentials": { "files": [ { "path": "~/.ssh", "mode": "deny" }, { "path": "~/.aws/credentials", "mode": "deny" } ], "envVars": [ { "name": "GITHUB_TOKEN", "mode": "deny" } ] } }, "allowManagedHooksOnly": true, "disableSideloadFlags": true, "allowManagedMcpServersOnly": true, "strictKnownMarketplaces": [ { "source": "github", "repo": "example-corp/approved-plugins" } ], "requiredMinimumVersion": "2.1.193" }这些设置分别提供如下控制：
permissions.deny防止秘密进入智能体上下文，并阻止工具任意访问网络；permissions.allow预先批准安全的内循环，避免拒绝列表造成提示疲劳。disableBypassPermissionsMode与allowManagedPermissionRulesOnly确保工程师、项目文件或命令行参数都不能扩大权限。sandbox弥补权限无法覆盖的缺口。工具层拒绝 WebFetch 并不能阻止 Shell 命令联网；操作系统层域名白名单可以直接阻断外连。failIfUnavailable与allowUnsandboxedCommands把沙箱变成关卡：沙箱无法初始化时 Claude Code 拒绝启动；命令在沙箱内失败后也不能改到沙箱外重试。credentials补上拒绝规则留下的缺口。permissions.deny约束 Claude 文件工具，但沙箱中的 Shell 命令默认仍可能读取~/.ssh或~/.aws/credentials；该配置禁止这些读取，并从所有沙箱命令环境中移除指定秘密。allowManagedHooksOnly表示只有本动作定义的审批关卡能运行，本地配置不能添加或替换它们。disableSideloadFlags与strictKnownMarketplaces确保工程师机器上的技能、智能体、Hook 和 MCP 服务器全部来自组织批准的插件市场，而不是个人目录。allowManagedMcpServersOnly让智能体工具面成为由平台团队维护的白名单。requiredMinimumVersion拒绝在低于批准版本的构建上启动，确保控制由组织实际评估过的版本执行。
以上只是可按需调整的起点，并非建议直接复制。每项拒绝都会牺牲能力，正确平衡取决于仓库的数据分类。设置参考列出了全部键，包括仅托管环境可用的配置。
如何衡量 Hooks 本身
| 指标 | 说明 |
|---|---|
| 领先指标 | 每道审批关卡的等待时间。每次 Hook 决定都以时间戳和允许/阻止结果写入 OpenTelemetry 导出，可按关卡观察。 |
| 滞后指标 | 引入 Hooks 前后到达生产环境的关卡违规数，来自事故追踪器。 |
CI/CD 集成与部署
在 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，无法直接推送到主分支。 - 将执行沙箱化。智能体作业在受网络政策约束的容器中运行，使用短期、范围受限的令牌，默认不持有生产凭据。
- 通过 MCP 暴露部署。部署、状态和回滚成为按环境限定的工具，因此智能体的部署能力是白名单，而非持有凭据的 Shell 脚本。
- 按环境划分自主等级：开发环境可自由部署；生产环境由智能体准备发布、发布经理授权，Hook 强制执行生产关卡；预发布环境介于两者之间。
- 回滚应是流水线中演练最多的路径：一条智能体可运行、并定期在预发布环境中演练的命令。第 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，不能直接进入主分支。
- 生产部署 Hook 会阻止发布，直到具名发布经理授权。每次非交互运行都使用智能体自己的身份，因此流水线日志能区分智能体与触发它的工程师分别做了什么。
- 各环境的权限等级决定智能体在到达关卡前能做多少。
| 指标 | 说明 |
|---|---|
| 领先指标 | 无需呼叫人工即可完成分析的流水线失败占比，取自 CI/CD 日志。 |
| 滞后指标 | CI 系统和部署工具已经产生的 DevOps Research and Assessment（DORA）指标。 |
06 · 维护
循环在这里闭合。触发器在没有人参与调用路径的情况下启动 Claude，发现结果再以 intent.md 形式进入流水线。
维护与闭环
前面讨论了如何把 Claude 加入 SDLC 各阶段，每一阶段的初始步骤仍由人启动。维护阶段则把重点转向让 Claude 自主运行，以闭合循环。
例如，持续运行的监控智能体可以在缺陷工单出现后创建 intent.md，依次流经需求、计划、构建、测试和评审。第 6 阶段以无头方式运行，各阶段之间有独立置信关卡——确定性检查或对抗式评审智能体——决定上一阶段输出继续前进，还是升级给人。
| 传统方式 | AI 原生方式 |
|---|---|
| 维护是被动阶段。所有工单和事故都要等人行动、重新启动流程。凌晨 3 点的告警可能被漏掉，工单可能长期待在 backlog，复盘行动也可能因下一场火灾而始终进不了代码库。 | 控制带突破、工单、频道消息或定时任务等触发器可在没有人的情况下调用 Claude。Claude 诊断，只沿受关卡保护的路径行动，并把发现写成 intent.md，再进入前述阶段。人负责分流和评审，不再负责启动。 |
闭合循环
确定性脚本监控生产环境，并在控制带被突破时调用 Claude。监控异常是自主循环模式的一个清晰例子；本阶段末尾的 Claude Tag（公开 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，或触发预先批准的运行手册。 - 触发层可以是 GitHub/GitLab 定时工作流、现有监控栈发出的 Webhook，或网络内部 Cron Job。Claude 以无状态方式运行：要么作为 CI runner 的非交互步骤，要么作为沙箱容器里的 Agent SDK 服务。由于运行无状态且非交互，一个循环可以在无人启动的情况下开始和结束。
- 智能体按第 1 阶段格式把诊断写成
intent.md，包含异常及证据、预期结果、受影响系统和未决问题；随后像其他事项一样进入流水线。 - 服务负责人或值班工程师分流队列，把面向产品的发现交给产品负责人：立即修复、排期或忽略。忽略决定用于调整控制带并降低噪声。
- 修复上线后，为该事故增加一个评估，确保同类问题以后受到保护。
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 评审关卡；智能体可以触发的运行手册也已预先批准。
| 指标 | 说明 |
|---|---|
| 领先指标 | 从控制带被突破到分流队列中出现 intent.md 的时间，与过去从事故发生到产生复盘行动的时间比较；检测日志包含突破时间戳与事故等级。 |
| 滞后指标 | 最终成为已合并修复的发现占比（对比分流队列与 PR 历史），以及同类事故的重复次数；修复不断向评估套件添加案例后，后者应下降。 |
示例
- CI 测试失败率突破 3σ 时，智能体隔离不稳定测试或创建回滚 PR，由评审关卡决定。
- 部署后 5xx 率在包含部署的窗口内突破 3σ 时，智能体触发现有回滚流水线。
- PR 周期时间触发漂移规则时，智能体为工程管理层撰写报告，说明同一套机制也适用于流程指标，而不仅是生产指标。
检测始终保持确定性。只有控制带被突破后才调用 Claude，等级决定它能做什么。
定期扫描代码库
一次安全扫描只是特定模型在某一时刻对代码库作出的判断，两部分都会过时：代码每周变化，新一代模型也会发现上一代遗漏的漏洞。AI 原生做法是无需人启动、定期运行扫描，并让发现像其他代码变更一样经过同一组关卡。
Claude Security 是托管式定期扫描。连接 GitHub 仓库后，扫描在 Anthropic 基础设施中使用 Claude Mythos 5 运行；每项发现都会在报告前验证并附置信度。建议补丁在网页版 Claude Code 中评审和应用。组织无需直接访问模型也能获得发现。
| 传统方式 | AI 原生方式 |
|---|---|
| 安全扫描是发布或审计前临时启动的一次事件。报告进入追踪器，积压由人手工处理，直到下次扫描；两次扫描之间的代码只能依赖 PR 评审。 | 对每个已连接仓库按计划使用当时最强模型扫描，发现经验证后才交给人。每项发现像控制带突破一样处理：一个 PR 能修复的进入评审关卡，更大的问题写成 intent.md；覆盖范围以最近一次运行日期为准。 |
如何开始
| 项目 | 要求 |
|---|---|
| 前置条件 | 第 5 阶段的 PR 评审关卡与审批 Hooks，以及第 1 阶段用于较大问题的 intent.md 格式。 |
| 基础设施 | Claude Security 以公开 beta 向 Claude Enterprise 组织提供。需要在目标云托管 GitHub 仓库安装 Anthropic GitHub App，启用 Claude Code on the Web，开启 Extra Usage 并设置支出上限，为运行扫描的人分配 premium seats，并由管理员在 claude.ai/admin-settings/claude-code 开启功能。扫描按 Mythos 5 费率计量收费，支出上限应匹配仓库数量和规模。 |
如何执行
- 安全负责人连接仓库，并按仓库、服务或团队组织成项目，从一开始就明确发现归属。
- 对最关键的仓库运行首次完整扫描，包括之前已经被其他工具或旧模型扫描过的仓库，并把结果当作基线。首次扫描很可能在过去被认为干净的代码中发现问题。
- 为每个项目设置计划。活跃开发的服务可默认每周一次；大型或混合仓库可将扫描范围限定到目录或分支。
- 结合置信度分流发现。忽略时写明原因，使决定被记录，并避免同一发现下次又以新问题出现。
- 对范围明确的问题，在网页版 Claude Code 中打开建议补丁，评审后像普通变更一样送入 PR 关卡。提出修复的智能体无法批准它。
- 对超出一个补丁范围的问题，例如架构弱点或跨服务重复模式，按第 1 阶段格式写成
intent.md，从规划阶段开始。 - 修复发布后，将该漏洞类别加入持续评估套件，使引导智能体的配置从此针对它接受测试。
- 以 CSV、Markdown 或 Webhook 导出发现，让组织现有追踪和审计系统继续作为审计人员期待的事实来源。
治理考虑
扫描遵循组织的管理员控制：连接哪些仓库、谁持有扫描席位、支出上限多少，都集中设定。每项发现都有验证结果和置信度，每次忽略都有理由，扫描历史因此成为“发现、修复、明确接受了什么”的审计记录。
修复通过 PR 评审关卡与分支保护进入生产环境，而不是直接由扫描上线。Claude Security 是现有静态分析和依赖扫描的补充：确定性检查继续留在 CI，模型扫描覆盖这类检查不擅长的、依赖上下文的漏洞。
| 指标 | 说明 |
|---|---|
| 领先指标 | 已连接仓库中纳入定期扫描的占比，以及从发现报告到补丁进入 PR 评审关卡的时间，取自扫描历史与 PR 元数据。 |
| 滞后指标 | 定期扫描发现的漏洞与生产环境或外部报告发现的漏洞之比（来自事故追踪器）；以及多次扫描后每次发现数的趋势，随着修复与评估累积，该值应下降。 |
让 Claude Tag 参与值班
事故也可从 Slack、Teams 等工作沟通应用进入。比如事故频道里晚上 10 点出现一条紧急修复消息，现在可以立即得到处理。Claude Tag（目前在 Slack 中提供公开 beta）让 Claude 以自己的身份成为频道成员，因此每次新事故都会有第一响应者，响应本身也成为循环的一部分，并为未来事故留下记忆。
对话和组织知识留在频道里；频道中的任何人都能引导并执行响应。团队成员可以实时测试假设、探索方案和调查，频道历史增加可审计性。借助 MCP，Claude 验证指标已恢复基线并在线程中确认，再把复盘写进版本控制的经验文件，供未来调查读取。
Claude Tag 处理的不只有事故。通过 MCP 在工单中标记它，或在频道里提出请求，Claude 会用同样方式分流：小而明确的修复通过评审关卡成为 PR，更大的工作写成第 1 阶段的 intent.md，循环开始自我供给。参见 Claude Tag 如何在 Anthropic 为 CI/CD 值班。
结语
模型与智能体运行框架已经变得更先进，组织可以改造的不再只是代码生产方式，而是整个软件开发生命周期。
这场转型仍把人的判断置于流程中心，同时考虑大型企业的治理与监管要求。本指南汇总了 Anthropic Applied AI 团队在客户项目中日常采用的许多真实实践，希望它能成为一份实用、可行动的资源。
循环持续运转，人的判断始终位于循环之上。
资源与致谢
以下文档是平台团队建立上述控制所需的资料，并大致按推荐落地顺序排列：
- 为组织设置 Claude Code：管理员决策图，从这里开始
- 设置参考与优先级，包括全部仅托管环境可用的键
- 通过 Claude 管理控制台配置服务器托管设置
- 权限
- 沙箱：操作系统级文件系统与网络隔离
- Hooks 指南
- Hooks 参考
- 技能
- 插件与私有市场：如何在组织内统一分发技能和 Hooks
- 托管 MCP：集中控制智能体工具面
- 企业部署概览：Bedrock、Vertex、Foundry
- 企业网络配置
- 监控（OpenTelemetry）
- 分析仪表盘
- Compliance API：企业活动流、聊天检索与删除
- 安全模型
感谢 Jim Blackhurst、Will Steuk 和 Jamal Arif 对本指南的贡献；本文受到他们许多既有工作的启发，并建立在这些工作之上。