Deploy：分层评审、门禁与 CI/CD

当代理可以快速产生差异，评审不能继续依赖某位工程师从第一行读到最后一行。更稳妥的结构是让所有 PR 经过一致的分层检查：行为缺陷、安全、合规与计划一致性分别审视，发现按严重度排序；人类代码所有者集中判断变更是否符合意图、风险是否可接受。流水线则让代理处理需要推理但可被约束的步骤，直到生产门前停止。

学习目标

• 能设计职责分离的多层 PR 评审流程。
• 能区分 Hook、分支保护、权限和沙箱各自控制的边界。
• 能按环境分级代理在 CI/CD 中的自主权，并保留可演练回滚。

核心概念

官方手册描述了双向评审：Claude 可以评审进入的 PR，也可以处理自己 PR 上的评论。但写代码的代理不能批准自己的变更；统一的评审策略、分支保护和人类代码所有者构成职责分离。重复发现会反馈到 CLAUDE.md，让下一次构建更早避免同类错误。

Hook 可在工具动作发生时允许、询问或阻止，适合把批准要求变成可执行门。项目 Hook 可随代码评审，不能由个人绕过的要求应由管理员托管。权限控制工具和资源访问；沙箱对 Bash 子进程施加操作系统级文件与网络边界。它们互补，不能用一层假装覆盖全部威胁。

CI/CD 中先从只读判断任务开始，例如解释失败构建或起草变更日志；写操作必须形成 PR，不能直推主干。开发、预发布和生产应使用不同权限层级：生产默认无常驻凭据，发布由指定人员授权。回滚要成为最常演练的路径，而不是事故时第一次执行的脚本。

实践步骤

1. 写一份短评审策略，分别定义行为、安全、策略一致性检查与严重度；排除生成文件和 CI 已确定性覆盖的格式问题。
2. 让独立评审者运行各层检查，限制低价值样式意见数量，把高风险发现放在最前。
3. 启用分支保护，要求代码所有者批准；确保实现代理没有批准或直推主干的凭据。
4. 把生产发布、迁移和受保护路径写成 Hook/托管策略；阻断消息必须说明原因和授权路径。
5. 让非交互代理先承担流水线只读任务，再把可逆写任务放到既有门禁之后。
6. 为开发、预发布、生产建立权限矩阵，并在预发布环境定期演练单命令回滚。

以下评审矩阵为 AIKnow 原创示意，不是 Anthropic 官方评审标准。

团队可以把它改造成符合自身风险分类与职责分工的版本：

层	主要问题	证据	批准者
确定性 CI	能否构建、测试、扫描通过	检查运行日志	自动门禁
代理行为评审	边界条件、回归、计划偏离	分级 PR 发现	代码所有者参考
安全/合规	权限、数据、策略冲突	策略检查与负责人意见	对应策略负责人
发布	风险、时机、回滚就绪度	变更记录与演练结果	发布经理

常见误区

• 让作者代理自批。 它可以修复评论，但独立批准仍必须存在。
• 所有检查都调用模型。 格式、测试、依赖和已编码政策应优先用确定性工具，降低成本和波动。
• Hook 只写“禁止”不写恢复路径。 团队会绕开不可操作的门；阻断应指明所需记录或审批人。
• 给流水线长期生产密钥。 短期、最小范围、按环境隔离的身份才符合最小权限。
• 自动化发布却不演练回滚。 加速单向路径会扩大事故半径。

动手练习

选一个现有仓库，列出合并与生产发布之间的所有门。将每个门标为“确定性检查、代理判断或人类授权”，并寻找重复与空白。然后设计三档环境权限：开发可做什么、预发布多哪一层门、生产必须由谁授权。最后在不接触生产的情况下写一次预发布回滚演练记录。

要点回顾

分层评审让每个 PR 接受一致检查，人类把注意力留给意图与风险。Hook、权限、沙箱、分支保护和独立身份共同把治理变成执行边界。代理可以走到生产门口、准备完整证据并处理反馈，但不应自行跨过生产授权门。

参考来源

• Anthropic / Claude 官方文章：The AI-Native SDLC playbook，重点参见 “Stage 5 — Deploy”、PR review、approval gates 与 CI/CD integration，核验日期：2026-08-26。
• Claude 官方文档：Automate workflows with hooks，用于核验 Hook 事件和确定性执行方式，核验日期：2026-08-26。
• Claude 官方文档：Configure permissions 与 Sandboxing，用于核验权限与 OS 级隔离的互补关系，核验日期：2026-08-26。
• Claude 官方文档：Claude Code GitHub Actions，用于核验 CI 中的官方集成方式，核验日期：2026-08-26。