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

编者摘要：传统 SDLC 以编码为最大瓶颈，流程线性流转，各阶段由人工驱动。AI 编码工具大幅加快代码产出后，瓶颈转移到规划、评审、部署等人速环节，原有人工逐行审核模式失效，治理成本抬升，因此需要重构为 AI 原生 SDLC。

AI 原生 SDLC 将线性流程改造为闭环，AI 嵌入规划、设计、构建、测试、部署、维护全链路，人保留决策权与最终责任。各阶段产出可版本管理的标准化 Markdown 制品：intent.md（业务意图）、spec.md（设计）、plan.md（开发方案），制品自动触发下一阶段，提交记录即审计链路。

核心实践：规划阶段捕获原始业务意图；设计阶段把需求与设计合并；构建优先使用方案规划模式，通过CLAUDE.md、Skills 能力集、Hooks 钩子沉淀组织知识与强制管控；测试建立 AI 自我反馈闭环与 CI 持续评估；部署实现 AI 辅助 PR 评审、分层审批钩子、沙箱 CI/CD；维护实现闭环自动化，监控异常自动生成intent.md回流流程。

并非完全取代人，人类聚焦风险、意图审批；AI 负责生成、自检、重复工作。企业可模块化分步落地，兼顾现有 Jira、Figma 等系统，明确事实源，在提效同时满足合规监管。

10 个关键问题问答

Q1：什么是 AI 原生 SDLC？

A：将传统线性 SDLC 重构为闭环，AI 深度嵌入规划到运维全流程，以标准化可版本化制品驱动流转；AI 承担生成、重复执行，人类保留判断、审批与最终问责，兼顾研发效率与企业合规治理。

Q2：为什么传统 SDLC 在 AI 编码时代失效？

A：传统流程假设编码是最慢环节、全部操作由人完成。AI 大幅提速代码生成后，规划、评审、安全审核等人工作业变成新瓶颈；人工逐行审查跟不上 AI 代码产出，治理与合规流程阻塞研发。

Q3：intent.md/spec.md/plan.md 分别作用是什么？

A：intent.md记录原始业务诉求；spec.md是需求与设计文档；plan.md是开发实施方案。三者版本归档，自动驱动下一阶段，同时构成完整审计链条。

Q4：CLAUDE.md 和 Skills 能力集有什么区别？

A：CLAUDE.md属于仓库级，记录本仓库架构、命令、编码规范；Skills 能力集是组织级策略（安全、品牌规范），可多仓库复用。

Q5：Skills 与 Hooks 钩子管控差异？

A：Skills 属于建议性约束，提示 AI 主动遵守策略；Hooks 是确定性强制防护，拦截危险操作、实现审批关卡，强合规需求两者搭配使用。

Q6：AI 原生 SDLC 中，人的角色发生什么变化？

A：不再从零编写大量代码，工作重心转移：业务意图确认、风险评审、高风险变更审批、校验 AI 输出结果，对最终业务结果承担全部责任。

Q7：企业已有 Jira、Figma，需要全部替换吗？

A：不需要。可以设置唯一事实源，要么以仓库 Markdown 制品为权威，旧系统做引用；要么旧系统为事实源，Markdown 作为工作副本，互相记录关联 ID。

Q8：什么是构建阶段 Plan 模式，为什么要优先使用？

A：Plan 模式让 AI 先输出书面开发方案 plan.md，不改动代码。工程师评审修正方案后再允许 AI 编码，把方案评审前置，大幅降低后期返工成本。

Q9：如何保证 AI 生成代码质量？

A：六层防护：

①plan 模式前置方案评审；

②CLAUDE.md+Skills 规范约束；

③本地反馈闭环 AI 自测；

④CI 持续评估；

⑤AI 辅助 PR 评审；

⑥Hooks 拦截违规变更。

Q10：维护阶段 “闭环” 具体如何实现？

A：监控系统确定性检测指标越界，触发 Claude 做诊断，自动生成intent.md回流至规划阶段，重新走完完整 SDLC；重大故障走人工复核，修复后新增评估用例防止同类问题复现。

附录 AI 原生软件开发生命周期实战手册

借助 AI 分阶段重塑软件开发生命周期

• 分类：企业级 AI
• 相关产品：Claude 企业版、Claude Code、Claude Tag
• 成文日期：2026 年 8 月 21 日
• 阅读时长：43 分钟
• 作者：Louis Claxton

1 代码不再是开发瓶颈

众多企业已开始借助 AI 生成代码，开发效率达到一年前难以想象的水平，但配套的开发流程并未同步迭代升级。

不少工程团队仍沿用旧有的审批关卡、评审机制、工作交接模式与管理制度，这直接抵消了 Claude Code 这类智能编码工具带来的生产力提升。

软件开发生命周期（SDLC）覆盖从创意构思到产品上线运维的全流程。绝大多数企业的 SDLC 包含六大核心阶段：规划、设计、构建、测试、部署与维护。传统模式下，每个阶段相互独立，由不同角色负责：产品经理输出需求，技术架构师完成方案设计，工程师开展开发实现，受监管企业的 QA 团队负责验证，发布团队完成上线交付，运维人员监控线上运行状态。各阶段依靠文档、工单与审批签字完成工作流转。

传统软件开发生命周期流程繁杂，目的是保障每一步的责任可追溯与风险可控。但这套体系诞生的时代背景是：编码实现是整个流程中最耗时、成本最高的环节，而如今现状已然改变。产品需求文档（PRD）、工作量评估、产品安全评审等机制，原本是为了在长达数周、数月乃至季度的开发周期中对齐各方认知。

同时，传统 SDLC 的管控逻辑全部基于 “所有操作由人类执行” 这一前提。现如今，能够充分挖掘 AI 价值的企业，都已围绕智能 AI 代理重构流程，同时保留人类的决策监督权。本手册整理了 Anthropic 应用 AI 团队的大量实操经验，结合服务客户的实践案例，讲解如何在 SDLC 全流程落地 Claude，实现开发提速与流程优化。

当代码编写不再是瓶颈，构建阶段的执行速度远超传统 SDLC 的承载能力时，会出现三大现实变化：

1. 瓶颈向构建阶段的前后两端转移
   主要集中在规划、评审测试、部署环节，这些步骤依旧受人类处理速度制约。
2. 管控规则与实际业务脱节，落地难度陡增
   人工逐行审查代码在人类编码时代具备可行性，但当绝大部分代码由 AI 代理生成后，这套模式便难以为继。
3. 治理成本持续攀升
   流程中的例外事项依旧需要通过周会、月会等会议模式审议处理。
   

说明：引入 AI 智能体前，全流程均受人类处理速度约束；引入 AI 代理后，构建阶段由 AI 高速完成，规划、评审、发布等依赖人工的环节时长不变，大量周期被释放出来。

以安全管控的瓶颈为例：安全团队的人员配置是按照人类编码输出量设定的。当 AI 代理成倍产出代码时，要么评审队列大量积压，要么代码在未充分审核的状态下上线。对于强监管企业而言，两种结果均不可接受，因此安全与策略校验流程必须跟上 AI 代理的产出速度。

想要真正释放智能 AI 智能体的生产力，同时保障业务安全，传统 SDLC 需要完成与开发实现环节同等深度的变革。

目录

1. 代码不再是开发瓶颈
2. 实操方案总览
3. 阶段一：规划
4. 阶段二：设计
5. 阶段三：构建
6. 阶段四：测试
7. 阶段五：部署
8. 阶段六：维护
9. 总结思考

2 何为 AI 原生 SDLC

AI 原生 SDLC 是一套经过重新设计的开发流程，在保留原有管控目标的前提下，采用全新的落地执行方式。流程不再是单向线性流转，而是形成闭环，AI 能力深度嵌入每一个环节。AI 原生 SDLC 支持工作自动流转、自动触发后续任务，解决传统 SDLC 中各阶段之间手动交接、流程笨重的痛点。

该模式也被称作智能代理 SDLC、AI‑SDLC 或是智能代理软件开发，不同叫法指向同一套理念。

下表对比了传统 SDLC 与 Claude 赋能下的 AI 原生 SDLC 的核心差异。大部分企业都处于两种模式的过渡区间。

AI 原生 SDLC 的核心逻辑是产出可归档的标准化产物。每个阶段完成后，都要将产物提交至版本控制系统，包含intent.md、spec.md、plan.md、代码变更及其测试用例、附带评审意见的 PR、故障记录；下一阶段基于上一阶段的产物启动。

前期阶段主要产出 Markdown 文档，产品负责人与 AI 智能体均可读取使用；从构建阶段开始，核心产物转变为代码及相关记录。整套提交记录同时构成审计链路：完整记录需求提出内容、AI 代理生成结果、审批人员信息。

所有需要主观判断的决策，最终责任仍归属于人类。在智能代理 SDLC 模式下，人类的工作重心发生转移，聚焦于关键产物的审核工作。

每一个阶段都输出可供下一阶段读取的归档产物。意图文档、设计规范、实施方案、代码变更、评审记录共同构成完整审计依据。

3 实操方案总览

本手册的实操方案是核心内容，覆盖规划、设计、构建、测试、部署、维护六大非线性阶段，贯穿完整软件生命周期。

每一项实操方案包含以下内容：

• 流程产生的变化
• 落地起步方式
• 具体实施步骤
• 治理相关考量
• 效果衡量指标

所有步骤均支持模块化落地，企业可结合自身业务优先级，分阶段完成流程改造。每项实操方案会在 “前置条件” 中标明依赖项，依赖关系图可直观展示整体依赖链路。

一个阶段完成的标志是提交归档产物，产物会自动触发下一阶段流程：审核通过的intent.md触发需求与设计工作；审批完成的spec.md触发方案规划；合并 PR 触发流水线；线上指标异常触发生成新的intent.md，由此循环往复。

落地初期需要人工触发每一步，最终目标形成自动化闭环：每一份审核完成的产物自动开启下一关卡。人类只需要聚焦关卡节点，重点复核 AI 代理标记的风险点，无需从零启动每个阶段。

实操方案按开发阶段分类，但落地顺序和阶段顺序并不完全一致。可以从无依赖的方案起步；其他方案需要先完成箭头指向的前置实操。

4 阶段一：规划

业务创意无需等待专人整理输出。原始需求只需要录入一次，由提出者完成表述，产出一份纳入版本管控的产物，供后续环节直接使用。

实操 1：生成 intent.md 捕获业务意图

启动软件开发流程的intent.md拥有多种来源：人员提出的创意、系统工单、监控告警触发的故障事件（详见第六阶段维护）。

在人员提出创意的场景下，提出者和 Claude 共同头脑风暴，产出一份原型规范文档。而传统 SDLC 中，提出创意的人还需要说服产品团队协同整理需求，或是交由产品团队代为编写。

Claude 生成的原型规范文档人类可读、纳入版本管控，可直接供给下一阶段使用，这份文档就是intent.md。

无论需求来自事件触发还是 AI 智能体输出，流程保持统一：产品负责人审核并修正 AI 生成的intent.md，确认无误后完成提交。

落地起步

• 前置条件：无
• 基础设施：面向非工程人员开放 Claude 访问权限（claude.ai 或 Cowork）；统一的intent.md文档模板；设置共享的版本管控存储空间，由产品负责人跟进维护。单一产品场景下，最简单的方式是在代码仓库内新建intent/文件夹，将需求产物和对应的代码放在同一处；当需求跨多个代码库时，才考虑单独搭建需求仓库；单体仓库场景直接新建目录即可。第三阶段构建部分会讲解该存储空间如何对接 Jira 或其他现有需求管理工具。

平台或工程团队一次性完成环境搭建，技术人员配置存储空间并设置写入权限，支持企业内不同角色人员提交需求。

仓库搭建完成后，不熟悉 Git 的人员无需直接操作 Git，借助 GitHub 等版本控制系统的连接器，即可通过 claude.ai、Cowork 让 Claude 代为提交 Markdown 文件。

实施步骤

1. 需求提出者用通俗语言向 Claude 描述业务问题：当前遇到的阻碍、受影响对象、预期效果、不在范围内的内容，无需遵循正式书面格式。
2. 开展头脑风暴，把创意打磨清晰。Claude 会模拟分析师提出问题，确认业务范围、目标用户、约束条件与成功衡量标准。
3. 调用企业定制模板，让 Claude 输出intent.md。模板可封装为能力集，由技术团队搭建、负责人审批通过，内容包含业务问题、预期效果、受影响用户与系统、约束条件、待确认问题。
4. 需求提出者修正 Claude 理解有误的内容。
5. 将intent.md提交至共享存储空间，记录提交人与时间戳，产品负责人接手开展后续工作。

intent.md示例：理赔状态自助查询作者：J. Ortiz（理赔运营）｜状态：草稿

业务问题

客户致电客服中心查询理赔进度，客服人员约三分之一通话时长消耗在状态查询类咨询上。

预期成果

用户可在门户页面查看理赔状态、下一步操作以及预计完成时间。

受影响用户与系统

理赔客服人员、门户开发团队、理赔核心 API。

约束条件

门户会话禁止新增个人敏感信息，仅复用现有鉴权体系。

待确认问题

第三方理赔定损人员是否也需要访问该功能？

治理考量归档的intent.md即为审计依据，记录作者、时间戳与完整修订历史，保存在存储空间的 Git 记录中。产品负责人完成审批，合并或评审关闭操作记录下通过 / 驳回的结果，通过的需求进入第二阶段设计环节。

效果衡量

• 先导指标：从首次沟通到提交intent.md的耗时，从 Git 历史提取作者与时间；目标将原本数周的需求梳理迭代周期压缩至数小时。
• 滞后指标：留存率，即产品负责人审批通过进入设计阶段的intent.md占比，合并 / 评审关闭记录审批结果；同时统计同一份需求生成第一版spec.md之后，intent.md的修改次数。

5 阶段二：设计

需求梳理与方案设计合并为一次会话。策略规范在编写设计文档的过程中就落地执行，避免数周后的评审环节才发现合规问题。

实操 2：需求与设计一体化

产品负责人审批通过intent.md后，Claude 读取文档，结合企业品牌、安全、合规、用户体验相关能力集，输出需求与设计规范文档。

产品负责人负责审核这份文档，不需要手动撰写。输出的文档需要给到工程团队用于方案规划，同时标记出潜在风险点。

前端开发是典型场景：intent.md审核通过后，产品负责人可以在测试版 Claude Design 中基于文档生成设计原型，迭代调整后直接导出给 Claude Code 开展开发。

落地起步

• 前置条件：已产出intent.md；品牌、安全、合规、UX 策略封装为能力集。
• 基础设施：产品负责人拥有 Claude 使用权限，无需工程技术能力。

实施步骤

1. 产品负责人加载企业能力集，会话中上传intent.md。
2. 初始阶段人工执行，提示词指向intent.md，明确约束条件，要求标记风险项；后续封装为企业级斜杠命令；进一步配置为自动触发：当intent.md完成合并，后台启动非交互式任务，加载企业能力集生成spec.md并以 PR 形式提交；后续产品负责人只需要开展评审工作。第五阶段部署的 CI/CD 实操会讲解底层配置。
3. 产品负责人对照原始业务需求审核文档：确认文档能够解决业务问题，intent.md中待确认事项是否得到解答或是持续留存。
4. 优先处理标记的风险点，也就是传统模式下分析师需要向上同步的问题；产品负责人协同对应策略负责人解决全部风险，再交付给工程团队。
5. 将spec.md和intent.md归档保存，两份文档完整记录原始诉求与落地决策。
6. 产品负责人判定文档是否进入开发；高风险内容同步咨询技术负责人。该决策必须由人类完成，spec.md审批通过后，启动第三阶段构建的方案规划流程。

参考提示词 读取附件intent.md，结合现有代码库输出需求和设计规范文档。调用已有的能力集，保证方案符合企业品牌指南、安全策略、UX 标准。完整输出spec.md交付工程团队。清晰标注风险点，尤其当存在策略冲突无法同时满足的场景。

治理考量策略规范不再延后到评审阶段校验，而是在编写文档时直接读取并落地。企业能力集作为设计文档的约束条件；设计文档、生成文档所用提示词、生效的能力集版本全部纳入版本管控。产品负责人完成签字确认，标记的风险点同步给到对应策略负责人。

效果衡量

• 先导指标：同一份需求，从提交intent.md到提交spec.md的时间间隔，对比传统模式下需求加设计的周期。
• 滞后指标：开发启动之后的需求返工量；统计同一份需求生成第一份plan.md之后的spec.md提交次数，直接从 Git 日志获取。

6 阶段三：构建

任何开发实现都必须基于审批完成的方案。企业内部沉淀的知识转化为 AI 代理可读取的文件，管控规则通过代码落地，而非依靠团队习惯。

实操 3：默认启用 Claude Code 方案规划模式

工程师在 Claude Code 会话中开启方案规划模式，输入第二阶段输出的审批完成的spec.md，和 AI 交互迭代实施方案，直至工程师确认方案可行。

落地起步

• 前置条件：intent.md或spec.md；配置CLAUDE.md会起到辅助作用。
• 基础设施：Claude Code 拥有仓库访问权限。

实施步骤

1. 工程师开启 Claude 的方案规划会话。
2. 向 Claude 传入intent.md与spec.md，要求输出实施方案，明确需要修改的文件、工作顺序、验证用的测试用例。
3. 向 AI 追问方案风险：本次改动可能破坏哪些逻辑、风险最高的步骤、舍弃的其他实现思路。
4. 迭代优化方案，做到完全不了解会话背景的工程师，仅依靠这份文档就可以完成开发。
5. 将审核完成的方案提交为plan.md，纳入审计链路；第五阶段部署的 PR 评审实操，会拿最终代码变更和这份方案做比对。
6. 确认方案后，交由 Claude 执行开发；完善的方案通常可以一次性完成实现。
7. 如果开发实现和方案存在出入，需要在同一次提交中更新plan.md，可以配置钩子强制保证两者同步。

plan.md示例：理赔状态自助查询（源自2026‑06‑02的intent.md）

修改文件

portal/src/claims/StatusPanel.tsx（新增）、claims‑api/routes/status.py、claims‑api/tests/test_status.py

工作顺序

1. 在现有鉴权体系下新增状态查询接口
2. 开发对接接口的前端面板
3. 将面板接入门户导航栏

风险

理赔核心 API 限流阈值为每秒 50 次请求，前端面板必须增加缓存逻辑。

验证标准

test_status.py 覆盖四类理赔状态；页面截图和审批完成的原型保持一致。

治理考量代码生成前就完成方案评审，此时修改方案仅需要编辑文档，成本很低。规划模式本身就限制 AI 修改文件，必须等待工程师确认方案。方案及修订记录、审批人全部留痕。常规改动由工程师审批；企业定义的高风险改动提交给技术负责人或架构师审核。

效果衡量

• 先导指标：一次开发即可完成合并的变更占比；从方案审批通过到 PR 合并完成的耗时，从 PR 元数据获取。
• 滞后指标：单份变更的返工次数；合并后的代码变更和归档的plan.md的匹配度，读取 PR 元数据分析。

实操 4：Claude Code 自动执行模式

工程师确认并迭代完成方案后，可以开启自动执行模式。无需每一步编辑都人工确认，Claude 自动落地每一处改动。当后续实操中的管控机制完善（调优后的CLAUDE.md、策略能力集、拦截危险操作的钩子、完备测试套件），自动确认将成为常规工作的默认模式：适用于spec.md定义清晰、影响范围小、已有测试覆盖的业务。

工作模式发生转变：不再盯着 AI 代理执行编辑操作，而是在 AI 完成较长周期的自主工作之后，对产物开展评审。搭配 Git 工作树，自动执行模式支持个人与团队并行处理多项任务，也是第六阶段维护实现 SDLC 自主闭环的基础。

补充说明：遗留系统与事实源 该规则适用于流程产出的全部产物。 传统 SDLC 工具也会记录各类产物，只是载体并非 Markdown：工作项存放在 Jira，需求保存在具备合规追溯能力的系统，设计存于 Figma，变更审批由变更管控委员会处理。这些系统很难直接替换，审计人员、监管机构、其他团队均依赖其运行。因此 AI 原生 SDLC 需要和现有体系兼容共存。 向 AI 原生 SDLC 过渡时，每一类产物都指定一套事实源，其余系统只保存副本或是跳转链接。可选配置如下：

1. 仓库作为事实源
   Markdown 文档作为权威记录，传统系统引用提交记录内的文件。对于工程主导的组织是较优方案，全部记录统一存储，时间戳权威可信。
2. 传统系统作为事实源
   Jira、ServiceNow、需求管理工具保存权威记录；Markdown 仅作为工作副本。会话启动时 Claude 读取系统记录，完成设计、方案输出后，通过 MCP 连接器回写结果。
3. 最低限度：建立关联关系
   所有产物标注外部系统记录 ID，传统系统记录标注 Markdown 文件的提交 SHA。适合过渡阶段，接受双事实源并存。

传统系统与 Markdown 体系可以共存，核心要求是建立相互关联，或是明确唯一事实源。

实操 5：CLAUDE.md 文档

CLAUDE.md为 Claude 提供新入职员工需要掌握的全部上下文，包含代码规范、执行命令、架构说明、团队高频踩坑点。原本沉淀在人脑、Wiki 中的团队知识，变为 AI 代理每次会话都会读取的文件，由全员共同维护，出现错误就迭代更新。

落地起步

• 前置条件：无
• 基础设施：代码仓库，安装 Claude Code，熟悉代码库的工程师参与维护。

实施步骤

1. 在仓库执行/init命令，Claude 基于仓库内容生成初始CLAUDE.md。
2. 精简文档，保留新人入职第一天必须掌握的信息：构建、测试、代码检查命令，关键规范，AI 高频出错点。
3. 将文件提交至仓库根目录，团队共用同一份，修改流程和普通代码一样需要评审。
4. 执行维护规则：同一错误 AI 重复出现两次，就把修正规则写入CLAUDE.md。
5. 控制文档篇幅，尽量精简为一页，AI 会话启动时读取全部内容，过时内容会无谓消耗上下文窗口。

CLAUDE.md示例：支付服务

执行命令

• 构建：make build
• 单元测试：make test；集成测试：make itest（依赖 Docker）
• 代码检查：make lint（CI 流水线执行，提交前必须修复）

编码规范

• Java21，Spring Boot3；禁止新增 Lombok 依赖。
• 金额统一使用 BigDecimal，禁止使用 double。
• 所有接口必须编写 src/itest 目录下的集成测试。

架构说明

• api 目录存放 REST 控制器；core 存放领域逻辑；adapters 对接外部系统。
• Kafka 事件定义在 schemas 目录，禁止手动修改自动生成类。

AI 高频出错点

• 不要升级依赖版本，由平台团队统一管控。
• 遗留 v1 包冻结，改动全部在 v2 中实现。

治理考量CLAUDE.md纳入版本管控，AI 代理遵循的指令全部可评审、可审计。团队规范通过文件落地，修改记录保存在 Git，变更需要代码负责人 PR 评审。

效果衡量

• 先导指标：本应被CLAUDE.md规避的错误重复出现频次；Git 历史统计文档修改次数。
• 滞后指标：从 PR 记录统计，团队新成员完成首个合并 PR 的耗时。

实操 6：能力集，企业制度知识的载体

能力集让企业内部制度知识可被工具执行。指令明确、版本可控、全局生效，策略更新时统一迭代。经验规则：需要一致性落地的企业制度编写为能力集；属于仓库级的公共知识放入CLAUDE.md，简单规则直接写在提示词中。

落地起步

• 前置条件：无，CLAUDE.md可提供辅助，非强制依赖。
• 基础设施：每一项能力都要有明确负责人与权威原始文档。

实施步骤

1. 选取一项落地效果参差不齐的制度，例如安全标准、API 设计规范、品牌规则。
2. 将制度编写为能力集：文件夹内包含SKILL.md，头部元数据写明触发条件，正文写明执行规则。工程师基于负责人提供的权威文档编写，可借助 Claude 辅助。
3. 存放路径：仓库内.claude/skills/<能力名称>/随代码一同分发；或是企业全局插件统一分发。
4. 验证触发逻辑：用不同的指令让 Claude 执行对应任务，确认能力集正常加载。
5. 制度更新时同步修改能力集，变更由策略负责人审批。
6. 工程师开启下一次会话自动加载最新版本。

SKILL.md示例：.claude/skills/secure‑api‑review/SKILL.md

---name: secure‑api‑reviewdescription: 执行API安全标准。创建/修改对外接口、评审API代码、生成OpenAPI文档时启用---# API安全评审规则修改或新增接口时执行以下规则：1. 鉴权：所有接口必须校验网关JWT，除健康检查接口外禁止匿名访问。2. 参数校验：请求体对照OpenAPI Schema校验，拒绝未知字段。3. 审计：所有修改状态的接口输出审计事件，记录操作人、动作、实体、时间戳。4. 数据分级：Schema标记为个人敏感信息的字段，禁止输出至日志与报错信息。执行脚本scripts/check‑endpoints.sh，并把输出写入总结。

治理考量能力集属于建议性管控，提升 AI 编码过程中遵循策略的概率，但无法强制会话必须遵守。对于强制落地的制度，需要搭配确定性的钩子机制，或是 PR 阶段二次校验。能力集降低违规概率，钩子机制几乎杜绝违规。能力集调用记录留存于会话日志，修改需要策略负责人按代码流程评审。

效果衡量

• 先导指标：策略负责人审批策略变更，到更新后的能力集完成合并的耗时，读取能力集目录的 PR 记录。
• 滞后指标：PR 评审中提出的相关策略问题数量；代码生成阶段能力集生效后，该类问题数量应趋向于零；若没有下降，说明能力集未正常触发，或是内容和官方策略出现偏差。

实操 7：钩子，构建阶段的确定性防护

能力集是建议性约束，钩子提供确定性强制能力。Claude 在构建阶段大多执行文件编辑、Shell 命令，因此钩子在构建阶段高频触发。

构建阶段钩子可实现能力：

• 拦截对受保护路径的修改，例如自动生成代码、冻结的包；
• 文件编辑后自动运行格式化、代码检查，避免偏差累积；
• 阻止密钥写入代码变更。

任何强制落地的策略，都要为对应的能力集配套钩子。钩子在匹配动作发生时执行，构建阶段钩子需要执行速度快，限定仅校验变更文件；完整测试套件这类重型校验放在提交或是 PR 环节。

如果钩子需要人工审批，应当放到第五阶段部署的关卡机制；构建阶段弹出人工确认，会把人员重新加入所有并行会话的关键路径，造成阻塞。

实操 8：并行会话与子代理

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

• 并行会话
  独立完整的 Claude Code 实例，依托 Git 工作树，分别处理不同任务；会话之间互相隔离，仅受工程师统一调度。
• 子智能体
  运行在同一个会话内部，作用域受限的辅助智能体，拥有独立上下文与工具权限；适合多个任务中重复执行的工作，例如验证应用运行状态。

并行会话提升工程师可同时处理的任务总量；子代理让单一会话聚焦核心目标。工程师的工作转变为调度与审核全部代理。

落地起步

• 前置条件：配置CLAUDE.md；第四阶段测试的反馈闭环可以降低工程师监督成本。
• 基础设施：Git 仓库，依托工作树实现隔离；权限配置完成，安全命令无需人工确认。

实施步骤

1. 工程师基于方案规划模式输出的文档，拆分任务：修改文件互不重叠的任务可以并行；修改同一文件的任务放在同一个会话中串行执行。
2. 每一项并行任务分配独立工作树，例如claude --worktree feature‑auth、claude --worktree fix‑rate‑limit。工作树为独立分支检出，避免会话之间文件冲突。
3. 起步建议同时运行 2‑3 个会话；上限取决于工程师可以高质量完成评审的数量，评审能力跟不上就不要新增会话。
4. 将重复工作封装为子智能体，定义文件放在.claude/agents/，写明名称、触发时机、可用工具。例如代码精简器、运行验证器、代码调研器。定义纳入 Git，团队共用。

子智能体示例 .claude/agents/verifier.md

---name: verifierdescription: 会话结束上报完成前，启动应用校验改动效果tools: Bash, Read---通过make run启动应用，执行改动相关逻辑以及相邻的两处业务流程。记录执行内容、运行结果，输出和plan.md不符的行为。仅输出报告，不修复问题。

治理考量会话变多会带来更大输出量，管控逻辑依托仓库配置落地。钩子、权限规则对全部会话生效；会话所有操作留痕，归属启动会话的工程师。

效果衡量

• 先导指标：在评审质量稳定前提下，每位工程师的并发会话数量，从 OpenTelemetry 导出数据统计；工程师用于调度而非等待的时间占比。
• 滞后指标：每位工程师每周合并变更数量，结合 PR 历史统计的返工率综合评估。

7 阶段四：测试

AI 代理在交付给人工审核之前，先完成自我校验；驱动 AI 代理的配置文件，也和业务代码一样开展回归测试。

实操 9：为 Claude 搭建反馈闭环

为 Claude 提供自我校验手段，无论是测试套件、构建脚本还是截图比对。会话在给到工程师查看之前，先完成自检并修复缺陷。

注意区分反馈闭环和验证子智能体：反馈闭环贯穿任务完整执行，循环多次；验证子代理是会话完成全部工作后，开启全新上下文做最终校验，不受前期逻辑假设干扰。

落地起步

• 前置条件：无
• 基础设施：测试套件、构建脚本支持本地一键执行；UI 类工作需要浏览器工具或是 MCP 对接的截图工具，供 Claude 查看运行效果。

实施步骤

1. 如果校验工作需要多条命令与大量环境知识，封装为单一目标，例如make test、npm test，失败时返回非零退出码。
2. 在CLAUDE.md的命令章节填写全部命令，附带正常输出样例。
3. 设置可量化目标，让 Claude 无需询问人类即可校验：“test_status.md 全部用例通过”、“截图和原型保持一致”、“接口返回 200 与新增字段”。
4. 缺陷修复场景：优先编写复现缺陷的失败测试用例，确认报错符合预期，提交测试用例；之后让 Claude 修复代码，禁止修改测试文件，配置钩子保障该约束。一份代理不能修改的前置测试用例，是缺陷真正被修复的证据。
5. UI 开发场景，通过可视化校验完成闭环。为 Claude 提供浏览器 / 截图工具，传入原型，循环迭代：开发、截图、比对、调整，通常需要 2‑3 轮迭代，效果逐轮提升。
6. 将校验作为 “任务完成” 的硬性要求，写入CLAUDE.md。任务上报完成前必须执行全部测试，输出执行日志。
7. 保护闭环本身：代理修复代码的过程中，不允许削弱校验逻辑。配置钩子，修复缺陷任务下禁止编辑测试文件；评审环节也可以拒绝改动测试文件的变更。

CLAUDE.md校验模块示例

工作校验规则

• 构建：make build，输出必须为 Build succeeded
• 测试：make test，全部用例通过，禁止跳过、删除失败用例
• 代码检查：make lint，零警告

任务上报完成前必须全部执行，粘贴输出结果。测试失败时修复业务代码，不改动测试。

治理考量

• 强制落地内容：任务完成前必须校验；修复缺陷任务禁止代理修改测试文件，企业可以配置钩子实现强制约束。
• 审计证据：make test输出、构建日志、截图比对结果，来自工具链的原始输出。
• 日志留存：保存在会话记录，通过 OpenTelemetry 输出至企业可观测平台，同时保存在 PR 检查记录，供评审、审计查阅。
• 审批人：PR 的代码负责人，机械层面的校验已经完成，评审可以聚焦业务意图与风险。

效果衡量

• 先导指标：AI 生成变更的首次 CI 流水线成功率，CI 系统直接统计。
• 滞后指标：单份 PR 评审耗时（读取 PR 元数据）；故障跟踪系统统计的变更失败率。

实操 10：CI 流水线内持续评估

持续评估是 AI 原生模式下的关卡式 QA。当 AI 代理的配置发生改动时，自动执行整套评估套件。更换模型、改写提示词后，评估套件会验证代理输出质量是否维持原有标准。

评估套件需要持续维护迭代：随着模型升级，原有区分效果的用例失效，需要基于监控新增测试案例。团队也可以选择离线周期性运行，而非每次改动都触发。以下为持续评估落地步骤。

落地起步

• 前置条件：配置CLAUDE.md；搭建反馈闭环。
• 基础设施：CI 支持非交互式运行 Claude Code；具备预算的 API 密钥用于执行评估。

实施步骤

1. 平台工程师选取 20‑50 条历史真实任务，附带预期合格结果。
2. 每一条任务编写评估用例，包含提示词、合格校验规则：测试全部通过、代码检查无异常、业务行为不变、符合策略。
3. CI 中定时执行评估套件；当CLAUDE.md、能力集、钩子发生修改时自动触发，这类配置和代码一样需要回归测试。
4. 配置门禁，评估通过率不达标，配置变更不能合并。
5. 每一次线上故障，由对应责任团队新增一条评估用例，永久加入套件作为回归防护。

GitHub 工作流配置示例 .github/workflows/agent‑evals.yml

name: Agent evalson:  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 提供可以跟上 AI 代理产出速度的门禁。通过率阈值作为合并条件；执行记录留存，可对比多轮结果；配置变更由对应负责团队审批。

效果衡量

• 先导指标：每一轮执行输出的评估通过率；线上故障转化为评估用例的耗时。
• 滞后指标：CI 拦截的回归缺陷对比线上暴露的缺陷，读取故障跟踪系统。

8 阶段五：部署

评审双向执行，AI 代理执行动作的同时落地治理；AI 代理可以完成生产前全部操作，但无法直接触达生产环境。

实操 11：PR 评审流程引入 AI

Claude 既接收评审，也执行评审：对照企业策略评审 PR，也可以自行修复 PR 下的评审意见。工程师评审 PR 时可以聚焦业务行为，也就是判断业务意图与风险等级。

落地起步

• 前置条件：第三阶段构建产出调优后的CLAUDE.md；用于评审校验的能力集、定义完成的子代理。
• 基础设施：仓库安装 Claude 集成；可以选用管理员开启的 Code Review 预览服务，或是 CI 中运行 claude‑code‑action；需要时可对接 AWS Bedrock、Google Vertex、Microsoft Foundry 路由模型调用；建议开启分支保护，要求代码负责人审批。

实施步骤

1. 快速上手：管理员开启托管的 Code Review 服务，选定生效仓库。想要自主管控流水线，或是流量需要走企业云协议，则在自有 CI 中运行 claude‑code‑action。CI/CD 实操会讲解底层配置。
2. 技术负责人在仓库根目录编写REVIEW.md评审规则，定义多套评审维度：逻辑缺陷、安全漏洞、对照spec.md/plan.md与设计原则的合规校验。同时定义严重问题、次要提示的区分标准，配置忽略项。
3. 设置人工介入阈值：AI 输出的评审结果不会直接批准或阻断 PR，分支保护依旧强制代码负责人审批。平台工程师可以读取检查运行输出的严重等级统计，配置合并门禁。
4. 在评审评论中 @claude，Claude 会解析评论并推送修复，PR 对话完整记录请求和改动，该修复循环由 claude‑code‑action 实现。托管服务中输入@claude review即可触发新一轮评审。对于 Claude 创建的 PR，可以让 AI 自动跟进直至待人工审批状态：自定义斜杠命令批量处理未解决评审意见、修复检查报错，直到 PR 全部通过，等待代码负责人审批。
5. 将评审发现沉淀至CLAUDE.md：同一错误第二次被评审标记，就在本次评审中将规则写入CLAUDE.md；评审也可以检测出CLAUDE.md过时的场景。
6. 技术负责人按月调优配置：对评审结果评级，优化 AI 评审质量，在REVIEW.md限制次要提示的数量；自动生成文件、CI 已经校验的内容不再重复输出。

REVIEW.md示例

# 评审指引## 评审维度执行三类评审，每一条问题标注所属维度- 缺陷：逻辑错误、边界场景失效、隐性回归问题- 安全：注入风险、鉴权漏洞、日志泄露个人敏感信息- 合规：变更匹配spec.md、plan.md与设计原则## 严重等级定义严重问题：会造成业务故障、数据泄露、违反制度；格式、命名类归为次要提示。## 次要提示上限单次评审最多输出5条次要提示，其余仅统计数量汇总。## 忽略范围src/gen/下自动生成文件、CI已经校验完成的内容不再输出问题。

治理考量职责分离得到保障：编写代码的 AI 代理没有权限审批代码。REVIEW.md的评审规则对全部 PR 生效；评审发现、修复动作、评级、审批全部留存 PR 记录，PR 本身构成审计记录。人类通过分支保护完成审批决策，AI 结果作为参考。如需了解大规模落地管控，可参考 Anthropic 的 AI 原生 SDLC 安全实践。

效果衡量

• 先导指标：获取首轮评审的耗时；无需人工修改分支就被解决的评审评论占比，读取 Git 数据。
• 滞后指标：合并前拦截的缺陷、漏洞，对比上线后暴露的问题；读取 PR 历史与故障跟踪系统。

实操 12：钩子作为审批关卡

构建阶段钩子用于无人工介入的防护，允许 / 拦截动作。钩子同样可以暂停流程，等待指定人员审批，这正是发布门禁的核心场景。

钩子不局限部署阶段使用，Claude 执行操作的场景都可以配置。例如构建阶段拦截未经变更工单的数据库迁移、基础设施修改；测试阶段修复缺陷任务禁止修改测试文件。

落地起步

• 前置条件：无
• 基础设施：梳理变更流程中必须保留的人工审批清单。

实施步骤

1. 工程负责人协同变更管理、合规团队，梳理必须保留的审批关卡，例如变更管控签字、发布授权、保护路径修改。
2. 平台工程师将每一条关卡编写为钩子脚本，在 Claude 执行动作前运行，实现允许、询问、拦截三类逻辑。
3. 团队级钩子放在 Git 内的.claude/settings.json；不可绕过的强制钩子由平台、IT 管理员托管配置，工程师无法关闭。
4. 拦截动作需要附带说明：钩子阻断操作时，输出拦截原因与审批路径，反馈给 Claude 会话。

.claude/settings.json配置片段

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

发布门禁脚本 .claude/hooks/production‑gate.sh

#!/bin/bash# 生产环境部署需要正式发布授权cmd=$(jq -r '.tool_input.command' < /dev/stdin)if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then   if [ -z "$RELEASE_APPROVAL" ]; then     echo "生产环境部署需要发布授权。" >&2     exit 2 # exit 2阻断动作，消息回传给Claude   fifiexit 0

企业强监管场景托管配置示例

{  "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"}

配置说明：

1. permissions.deny
   避免密钥进入 AI 上下文，拦截任意出站网络请求；permissions.allow预批准安全的内部操作，避免频繁弹窗确认。
2. disableBypassPermissionsMode
   + allowManagedPermissionRulesOnly：工程师、项目文件、命令行参数都不能放宽权限规则。
3. sandbox 沙箱弥补工具层权限的不足：工具禁止 WebFetch，但 Shell 脚本依旧可以访问网络；操作系统层面域名白名单彻底限制出站。
4. failIfUnavailable
   与allowUnsandboxedCommands：沙箱初始化失败，Claude Code 直接拒绝启动；沙箱内执行失败的命令，禁止在沙箱外重试。
5. credentials 配置：工具权限可以限制文件读取，但沙箱 Shell 进程默认依旧可以读取~/.ssh、~/.aws/credentials；该配置拒绝这类读取，从环境变量剥离指定密钥。
6. allowManagedHooksOnly
   ：只运行管理员托管的钩子，本地无法新增、替换。
7. disableSideloadFlags
   、strictKnownMarketplaces：工程师本地无法加载自定义能力集、代理、钩子、MCP 服务，全部来自企业审批的插件市场。
8. allowManagedMcpServersOnly
   ：代理可用工具集由平台团队统一管控。
9. requiredMinimumVersion
   ：低于审批基线版本拒绝启动，保证管控能力基于企业评估过的版本。

以上仅作为定制起点，不建议直接复制。每一条禁止项都会牺牲部分能力，需要结合仓库数据分级找到平衡点。完整字段查阅官方文档 code.claude.com/docs/en/settings。

效果衡量（钩子）

• 先导指标：每一道审批关卡的等待耗时；OpenTelemetry 导出记录钩子决策时间戳、允许 / 拦截结果，统计每类关卡等待时长。
• 滞后指标：故障跟踪系统统计，钩子落地前后绕过关卡流入生产的违规事件数量。

实操 13：CI/CD 集成与部署

在 CI/CD 流水线中以非交互模式运行 Claude Code；执行环境沙箱隔离，长时间运行的代理安全可控；通过 MCP 集成暴露部署能力；代理真正需要回滚之前，提前演练回滚流程。

落地起步

• 前置条件：完成 AI 参与 PR 评审；搭建钩子审批关卡。必须先建立关卡，自动化才能安全提速。
• 基础设施：CI 平台安装 claude‑code‑action，或是支持调用claude -p的执行器；API 访问能力，需要时对接 Bedrock、Foundry、Vertex 满足企业云协议；部署目标对应的 MCP 服务；代理任务使用沙箱配置，默认不持有生产凭据。

实施步骤

1. 平台工程师从只读类智能任务起步：流水线任务中执行claude -p，分析构建失败、总结偶现测试问题、生成变更日志草稿。
2. 在现有关卡之后新增写操作任务：修复代码检查报错、更新自动生成文档、处理 @claude 评审评论。代理所有写操作产出 PR，受分支保护约束，没有直接提交主分支的权限。
3. 执行环境沙箱隔离：代理任务运行在容器，配置网络策略，使用短期受限令牌，默认不持有生产凭据。
4. 通过 MCP 暴露部署能力：部署、状态查询、回滚作为工具，按环境做权限范围限定；代理的发布能力依靠白名单工具，而非带有凭据的 Shell 脚本。
5. 按环境划分自主等级：开发环境代理可以自由部署；生产环境代理仅准备发布包，等待发布管理员授权，钩子强制生产门禁；预发环境介于两者之间。
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，禁止直接推送主分支。
• 生产部署钩子：必须有发布管理员授权才放行；非交互式运行记录代理身份，流水线日志区分代理行为与触发任务的工程师。
• 分环境权限分级，管控代理到达门禁前可执行的操作。

效果衡量

• 先导指标：无需人工介入即可完成定位处理的流水线失败占比，读取 CI 日志。
• 滞后指标：CI 与部署工具输出的 DORA 研发效能指标。

9 阶段六：维护

闭环完成。触发事件直接调用 Claude，无需人工发起；分析结果输出intent.md，重新进入开发流水线。

实操 14：维护与闭环能力

前面所有阶段都需要人工启动 Claude；本阶段实现 Claude 自主运行，完成闭环。

例如持续运行的监控代理，检测到工单生成，自动创建intent.md，完整走完需求、方案、构建、测试、评审流程。维护阶段为无头运行模式，阶段之间配置独立的置信度关卡：确定性检查或是对抗评审代理，判断输出是否继续流转，或是升级交给人工处理。

实操 15：闭环落地实现

确定性脚本监控生产环境，指标超出可控阈值时调用 Claude。以监控指标越界为闭环自主运行示例；阶段末尾 Claude Tag 章节会讲解其他事件来源。

落地起步

• 前置条件：intent.md作为闭环结构化输出载体；AI 加速的 PR 评审；作为行为边界的钩子；CI/CD 具备回滚路径（高自主等级会调用回滚）。
• 基础设施：可供检测脚本查询的指标存储（Prometheus、CI 系统 API 等）；仓库读权限；CI 中非交互式运行 Claude Code，或是 Agent SDK 服务接收 Webhook，运行在沙箱容器。

实施步骤

1. 服务负责人或平台工程师选取拥有稳定滚动基线的指标，例如 CI 测试失败率、发布后 5xx 错误率、PR 周期耗时。
2. 编写版本管控、单元测试过的检测脚本；基于滚动窗口计算均值、标准差，采用 Western Electric 规则，同时捕获突增与缓慢漂移。检测逻辑完全确定性，不调用大模型。
3. 在版本管控配置bands.yaml定义响应等级：1σ 仅记录日志；2σ 调用 Claude 只读模式诊断；3σ 允许 Claude 执行操作，但仅能提交 PR 或是触发预审批的操作手册。
4. 触发层可以是 GitHub/GitLab 定时工作流、现有监控系统 Webhook、集群定时任务。Claude 无状态运行，作为 CI 步骤或是沙箱容器内 Agent SDK 服务。无需人员操作，闭环即可完整启动结束。
5. 代理输出诊断报告，按照第一阶段格式编写intent.md，写明异常现象、证据、预期效果、受影响系统、待确认问题；这份产物和其他需求一样进入流水线。
6. 服务负责人或是值班工程师处理待办队列：修复、排期或是驳回。驳回的同时调整阈值配置，减少误报。
7. 修复上线后，为该故障新增评估用例加入持续评估套件，规避同类问题再次发生。

bands.yaml示例：监控CI测试失败率

metric: ci_test_failure_ratebaseline: rolling_30drules: western_electrictiers:  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 历史；同类故障复现次数，新增评估用例后该数值应当下降。

场景举例

1. CI 测试失败率达到 3σ 阈值：代理隔离不稳定用例，或是提交回滚 PR，交由评审关卡决策。
2. 发布后 5xx 错误率达到 3σ，且发布窗口内有版本变更：代理调用已有的回滚流水线。
3. PR 周期耗时触发漂移告警：代理生成报告给到工程管理层，说明闭环也可以处理流程类指标，不限于线上业务指标。

关键点：检测逻辑保持完全确定性；阈值越界之后才调用 Claude，等级配置限定代理可执行的动作。

实操 16：周期性代码库扫描

安全扫描只能反映特定时间点、特定模型视角下的代码库状态。代码持续迭代，新模型可以发现旧模型遗漏的漏洞。AI 原生方案是无人为触发、按周期执行扫描；发现的问题和其他变更一样经过统一关卡处理。Claude Security 是托管式周期扫描服务。接入 GitHub 仓库，基于 Mythos5 模型周期性扫描，结果经过校验附带置信等级；修复建议可以在网页端 Claude Code 中评审应用。企业获取扫描结果，无需自行调用模型。

落地起步

• 前置条件：PR 评审关卡、钩子审批关卡；超出单 PR 修复范围的问题使用第一阶段的intent.md格式。
• 基础设施：Claude Enterprise 企业版可使用公测 Claude Security；安装 Anthropic GitHub App 到目标仓库；网页端开启 Claude Code；开启超额用量并设置消费上限；扫描人员配置高级席位；管理员在 claude.ai/admin‑settings/claude‑code 开启功能。扫描按 Mythos5 消耗量计费，消费上限匹配仓库数量与规模。

实施步骤

1. 安全负责人接入仓库，按仓库、服务、团队划分项目，明确每一条问题的归属。
2. 关键仓库执行首次完整扫描，包括其他工具、旧模型扫描过的代码，将首次结果作为基线。首次扫描往往会在原本认为安全的代码中发现问题。
3. 按项目配置扫描周期：活跃开发的服务默认每周；仓库体量巨大时限定扫描目录、分支。
4. 结合置信等级处理结果；驳回问题必须填写理由，避免下一轮扫描重复输出同一告警。
5. 范围可控的问题，在网页端 Claude Code 打开修复建议，评审后进入 PR 评审；生成修复的代理没有审批权限。
6. 架构缺陷、跨服务共性模式这类超出单次 PR 的问题，整理为intent.md进入规划阶段。
7. 修复上线后，为该漏洞类型新增评估用例，加入持续评估套件，后续代理配置自动针对该漏洞类型回归校验。
8. 结果导出 CSV/Markdown，Webhook 推送，对接企业现有工单审计系统，满足审计人员习惯。

治理考量扫描受企业管理员管控：仓库接入、扫描席位、消费上限统一配置。每条结果带有校验状态与置信等级，驳回记录附带理由；扫描历史完整留存审计记录。修复必须经过 PR 评审与分支保护，扫描本身不能直接上线改动。Claude Security 作为静态扫描、依赖扫描的补充。确定性检查保留在 CI，模型驱动扫描用来捕获传统工具无法识别的上下文相关漏洞。

效果衡量

• 先导指标：开启周期扫描的仓库占比；问题上报到修复建议进入 PR 评审的耗时，读取扫描历史与 PR 元数据。
• 滞后指标：周期扫描发现漏洞对比线上暴露、外部上报漏洞数量；多次扫描的仓库告警数量变化趋势，随着修复、评估用例增加，告警应当逐步下降。

实操 17：Claude Tag 实现 AI 值班

故障也会来自企业沟通工具，例如 Slack、Teams。晚上 10 点故障频道收到消息需要紧急修复，Claude Tag（公测，支持 Slack）让 Claude 成为频道内成员。每一次故障都获得第一时间响应，响应记录成为后续故障处理的历史记忆。

对话与企业知识完整保存在频道，所有团队成员可以参与引导执行。借助 MCP，Claude 校验指标恢复基线，在频道内确认结果；复盘文档写入版本管控的经验文档，供后续排查参考。

故障不是 Claude Tag 唯一的输入来源：MCP 接入工单 @提及、频道提问，Claude 统一处理。小范围、边界清晰的修复走 PR 评审；复杂问题输出intent.md进入规划阶段，实现自我驱动的闭环。可参考 Anthropic 内部 Claude Tag 处理 CI/CD 值班故障的实践案例。

频道本身就是审计链路：需求、诊断、人工授权、修复全部保留在故障处理发生的位置。

10 总结思考

模型与配套工具日趋成熟，企业不仅可以改变代码的生产方式，更可以重塑整套软件开发生命周期。

这套转型将人的主观判断放在流程核心，充分考虑大型企业的治理与合规要求。

本手册汇总了 Anthropic 应用 AI 团队服务客户的真实落地经验，希望为你提供可落地的实践指引。

闭环持续运转，人类的判断凌驾于闭环之上。

参考资源与致谢

以下文档供平台团队配置管控，按落地大致顺序排列：

1. 企业部署 Claude Code — 管理员决策指南：code.claude.com/docs/en/admin‑setup
2. 设置参考与优先级，包含全部托管专属配置：code.claude.com/docs/en/settings
3. 管理员控制台服务端托管配置：code.claude.com/docs/en/server‑managed‑settings
4. 权限文档：code.claude.com/docs/en/permissions
5. 沙箱：操作系统级文件与网络隔离：code.claude.com/docs/en/sandboxing
6. 钩子指南：code.claude.com/docs/en/hooks‑guide
7. 钩子参考文档：code.claude.com/docs/en/hooks‑reference
8. 能力集：code.claude.com/docs/en/skills
9. 插件与私有市场，能力集、钩子企业分发：code.claude.com/docs/en/plugin‑marketplaces
10. 托管 MCP，代理工具集集中管控：code.claude.com/docs/en/managed‑mcp
11. 企业部署总览（Bedrock、Vertex、Foundry）：code.claude.com/docs/en/third‑party‑integrations
12. 企业网络配置：code.claude.com/docs/en/network‑config
13. 监控（OpenTelemetry）：code.claude.com/docs/en/monitoring‑usage
14. 分析仪表盘：code.claude.com/docs/en/analytics
15. 合规 API — 企业活动日志、会话查询与删除：platform.claude.com/docs/en/manage‑claude/compliance‑api
16. 安全模型：code.claude.com/docs/en/security

感谢 Jim Blackhurst、Will Steuk、Jamal Arif 为本手册提供贡献，本手册基于他们过往的工作成果衍生而来。