EP02. "AI-Native SDLC 实战手册：测试、部署到维护的自动化闭环（Test / Deploy / Maintain 三阶段）"

• 接着 EP01（Plan/Design/Build 三阶段），这篇讲后半段：怎么用持续 evaluation 取代传统 QA 关卡（Test）、Claude 怎么参与 PR 审查 + 用 hooks 当审批关卡 + 怎么把 Claude 接进 CI/CD 做部署判断（Deploy）、生产环境出问题怎么让 Claude headless 自主诊断（Maintain），最后一节整理官方给的落地资源清单
• 官方反复强调一条治理主线：agent 可以一路做到部署关卡前，但过不了关卡——分支保护、生产部署 hook、按环境分层的权限，三层机制确保「写代码的 agent 没有办法自己批准自己」
• 前置知识：看过 EP01，理解 intent.md/spec.md/plan.md 这几份产物、CLAUDE.md/Skills/Hooks 的分工

重点内容

Stage 4 · Test：Continuous Evals 是 AI-native 版本的 QA 关卡

核心定义：Evals 是传统 stage-gate QA 的 AI-native 对应版本——每次 agent 配置改动（换模型、改 prompt）都自动跑一次回归测试，确认 agent 的表现水准没有退步。

执行步骤：

1. 平台工程师从最近的实际工作里收集 20-50 个真实任务，每个都要有明确写下的预期结果
2. 每条 eval = 一个 prompt + 验收标准（测试要过、lint 要干净、功能不能变、政策要合规）
3. 整套 eval 在 CI 里非交互式执行，触发时机是排程跑一次，或者配置文件（CLAUDE.md/skills/hooks）有改动
4. 配置改动如果让通过率下降就直接挡住，要求先审查才能合并
5. 生产环境出的事故会变成新的、永久保留的 eval，防止同样的问题再犯一次

治理：通过率门槛当成 merge check 强制执行；结果都记录下来方便做时间序列比对；配置的所有权需要团队批准。

衡量指标：Leading——通过率的走势、事故转成 eval 的耗时；Lagging——CI 阶段就抓到的回归 vs 生产环境才被发现的问题数量对比。

Stage 5 · Deploy：三个打法把审查和部署都嵌进流程里

打法一：让 Claude 参与 PR 审查

转变：传统审查能力取决于人力空不空、审查质量因人而异、backlog 会一直堆；AI-native 做法是「所有 PR 都跑一模一样的一套审查，发现的问题按严重程度排序」，人力审查者专注在验证意图对不对、评估风险能不能接受。

前置条件：更新过的 CLAUDE.md；放在仓库根目录的 REVIEW.md 政策文件；装好 Claude 整合（官方托管的 Code Review 服务，或 CI 里跑 claude-code-action）；要求 code owner 批准的分支保护政策。

执行步骤：

1. 用 Anthropic 托管的 Code Review 服务或自建 CI/CD pipeline 打开审查功能
2. 在 REVIEW.md 里按审查类别定义政策：bug/逻辑错误、安全漏洞、跟 spec 对不对得上
3. 设定哪些发现需要人力处理的门槛
4. 让 @claude 能在评论里被提及，agent 可以直接处理反馈、推修复
5. 反馈循环整合：同一条政策违规被抓到两次，就该写进 CLAUDE.md
6. 每个月根据发现的评价和琐碎意见（nit）数量做调优

审查类别：Important（影响行为/数据安全/政策合规的问题）、Nits（风格和命名，一次审查最多列五条）、Exclusions（生成的文件、CI 已经强制检查过的项目不重复审）。

衡量指标：Leading——第一次收到审查的时间（目标是几分钟内）、不需要人力碰分支就能解决的评论比例；Lagging——合并前抓到的缺陷/漏洞 vs 逃进生产环境的数量。

打法二：Hooks 当审批关卡

核心概念：Hooks 能「允许、询问或挡下」一个动作——跟 build 阶段那种不用人介入的硬性护栏不同，审批关卡是真的暂停下来，等指定的人明确授权才继续。

不只用在部署阶段，横跨多个阶段：Stage 3 Build（挡下没有 change ticket 的基础设施/migration 改动）、Stage 4 Test（防止未授权修改测试文件）、Stage 5 Deploy（强制要求发布授权）。

执行步骤：

1. 工程领导、变更管理、合规团队一起定义哪些动作需要审批
2. 把这些关卡写成会在 Claude 动手之前先执行的 hook 脚本
3. 存放位置分两层——团队级 hook 放进版本控管的 .claude/settings.json；不可协商的硬性 hook 放进由平台/IT 管理员控制的 managed settings
4. 卡关时要给出清楚的讯息，说明原因和怎么申请批准

范例：生产部署关卡要求环境变量层级的授权，用一段 bash 脚本检查指令输入，没有正确的批准凭证就挡下部署。

治理：所有人都必须走这道关卡；允许/挡下的决定都要有时间戳记录；批准标准要写清楚；managed settings 防止工程师绕过去。

企业级管控范例涵盖：权限的允许/拒绝清单（保护密钥、控制网络）、OS 层级的沙盒隔离（网域白名单）、凭证文件/环境变量限制、只有平台团队能批准的 hook-only 政策、限定可用的 marketplace（防止装未经授权的 plugin）、强制要求的最低版本。

衡量指标：Leading——每个关卡的等待时间（透过 OpenTelemetry 可见）；Lagging——因为关卡被违反导致的生产事故，上线前后对比。

打法三：CI/CD 整合与部署

传统 pipeline：靠确定性脚本自动化，遇到测试分诊、写 changelog、排查 build 失败这类需要判断的工作还是要人来做；部署和回滚靠人在压力下照着手册操作。

AI-native pipeline：Claude 在 pipeline 内、用沙盒化的环境 + 范围受限的凭证，非交互式地完成这些需要判断的任务；部署工具透过 MCP 开放给 agent 用，让「写代码 + 测试代码」的同一套流程，在组织定义好的环境关卡内，也能负责部署和回滚。

前置条件：已经有 AI 驱动的 PR 审查和审批关卡 hook 在运作；CI 平台装了 claude-code-action 或 runner 支持 claude -p 指令；能调用 Claude 模型的 API（或 Bedrock/Microsoft Foundry/Vertex AI 这类云端替代方案）；给部署目标用的 MCP server；给 agent job 用的范围受限、短期有效的凭证沙盒 profile。

六步实施路径：

1. 只读的判断类步骤先上——在 pipeline job 里用 claude -p 分诊 build 失败原因、分析 flaky test、生成 changelog 摘要
2. 写入类的步骤放在关卡后面——比如 lint 修复、文档更新，agent 的产出要走分支保护，不能直接 commit 进 main
3. 沙盒化执行——容器化的 agent job 在网络政策限制下跑，用短期 token，默认不给生产环境凭证
4. 用 MCP 开放部署工具——部署/查状态/回滚变成白名单化的工具，而不是带凭证的 shell 脚本，而且按环境分开授权范围
5. 按环境分层给自主权——开发环境可以自由部署；staging 给中等程度的控制；生产环境一定要走部署 hook，经 release manager 授权
6. 回滚流程要反复演练——回滚要变成 pipeline 里被演练得最熟的一条路径，平时就在 staging 反复跑单一可执行指令，确保生产环境真的需要时靠得住

范例：

- 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

治理三层机制（核心原则：agent 可以一路做到部署关卡前，但过不了关卡）：

• 分支保护把 agent 生成的代码转成 PR，没有直接碰 main 的权限
• 生产部署 hook 挡住发布，要 release manager 授权，pipeline log 把动作都归到这个 agent 的身份底下
• 按环境分层的权限逐级限制 agent 的能力，一路收紧到关卡

衡量指标：Leading——不需要升级给人处理、自动分诊掉的 pipeline 失败比例（从 CI/CD log 抓）；Lagging——CI 系统本来就会吐出来的 DORA 指标（速度、稳定性、前置时间的影响）。

Stage 6 · Maintain：把维护变成自主诊断的闭环

这个阶段把软件开发从「被动响应」变成「自主运作」——不用等人发起，Claude 在后台（headless）自己诊断问题、提出解法。

传统做法：事故和工单都要等人来发起响应。AI-native 做法：Claude 能透过控制带（control-band）被突破、工单、或排程监控自主触发，不需要人先开口，同时靠置信度关卡维持治理。

前置条件：intent.md 当作结构化的输出格式；Claude 加速过的 PR 审查；CI/CD hooks 当作行动边界；回滚能力。

基础设施需求：指标存储（Prometheus 或 CI 系统 API）；仓库读取权限；能非交互式执行的 Claude；能接收 webhook 的 Agent SDK 服务。

执行步骤：

1. 挑一个有稳定 rolling baseline 的指标（测试失败率、部署后错误率、或周期时间）
2. 用统计方法（比如 Western Electric 规则）写确定性的侦测脚本
3. 在版本控管的配置里定义响应分级
4. 设好触发机制（GitHub workflow、webhook 或 cron job）
5. agent 照 Stage 1 的格式生成诊断用的 intent.md
6. on-call 工程师分诊这些发现
7. 为已经上线的修复补上对应的 eval

响应分级范例（用 sigma 门槛）：

治理：分级的边界/权限/设置都要版本控管；所有调用、发现、决策都要带时间戳记录；改动一样要走标准 PR 审查关卡。

衡量指标：Leading——从突破侦测门槛到进入分诊队列的时间；Lagging——有多少发现最终转成合并的修复、重复事故有没有减少。

收尾：官方给的落地资源清单

课程最后一节强调：AI 模型和开发工具已经成熟到不只能改变「写代码」这件事，而是能重塑整条软件开发生命周期，而且全程把人的监督放在核心位置，同时兼顾企业治理和合规需求。这套打法来自 Anthropic Applied AI 团队每天跟客户一起落地的实际方法，不是纸上谈兵。官方按平台团队建置治理机制的大致顺序，整理了以下资源清单：

学完你会

• ✅ 讲得清 Continuous Evals 怎么在 AI-native 流程里取代传统的 QA stage-gate
• ✅ 知道 REVIEW.md、Code Review 服务、@claude 评论这套机制怎么让 Claude 参与 PR 审查，同时保住「写的人不能批准自己」这条职责分离
• ✅ 分得清 build 阶段的硬性护栏 hook 跟部署阶段的审批关卡 hook 有什么不同，各自该放在哪一层 settings
• ✅ 讲得出 CI/CD 六步实施路径，从只读判断任务开始、一路到生产环境部署都要经过 release manager 授权
• ✅ 理解 Maintain 阶段怎么用置信度分级（sigma 门槛）让 Claude 自主诊断，同时不会绕过治理
• ✅ 知道官方资源清单大致的落地顺序，方便自己团队按图索骥

常见错误

• ❌ 把「AI 能参与 PR 审查」理解成「AI 批准 PR」——治理红线是写代码的 agent 没有权限批准自己的代码，人工批准透过分支保护始终是强制的
• ❌ build 阶段的硬性护栏 hook 和部署阶段的审批关卡 hook 混在一起配置——前者不需要人介入、要求执行快、范围限定在单一文件；后者是真的要停下来等人明确授权，放错阶段会卡住不该被卡住的并行 session
• ❌ 生产部署凭证在 CI/CD pipeline 里长期有效、范围过大——沙盒化执行应该用短期 token、按环境分层授权，默认不给生产凭证
• ❌ 回滚流程只写在文档里，从来没真的跑过——回滚应该是 pipeline 里被演练得最熟的一条路径，平时就该在 staging 反复跑，不要等真正出事才第一次执行
• ❌ Maintain 阶段的自主诊断没有设分级门槛，一有风吹草动就直接自动执行修复——响应分级（比如 1σ 只记录、2σ 只读诊断、3σ 才提出行动）是必要的治理机制，不能让 agent 在没有置信度分级的情况下直接对生产环境动手
• 💡 想知道从哪里开始落地，官方给的资源清单本身就是按「平台团队建置顺序」排的——核心设置 → 开发管控 → 分发与整合 → 运营与合规，照顺序看比东抓一点西抓一点有效率

Sources

官方文档：

1. The AI-Native SDLC Playbook（课程总览）— https://academy.claude.com/courses/ai-native-sdlc-playbook
2. Continuous evals in CI — https://academy.claude.com/courses/ai-native-sdlc-playbook/continuous-evals-in-ci
3. AI in the PR review loop — https://academy.claude.com/courses/ai-native-sdlc-playbook/ai-in-the-pr-review-loop
4. Hooks as approval gates — https://academy.claude.com/courses/ai-native-sdlc-playbook/hooks-as-approval-gates
5. CI/CD integration and deployment — https://academy.claude.com/courses/ai-native-sdlc-playbook/ci-cd-integration-and-deployment
6. Closing the loop on metrics — https://academy.claude.com/courses/ai-native-sdlc-playbook/closing-the-loop-on-metrics
7. Closing thoughts and resources — https://academy.claude.com/courses/ai-native-sdlc-playbook/closing-thoughts-and-resources