Claude Code：集成、review 与治理
一个工具一旦被组织当成主入口，就必须回答三个问题：它怎么接入工作系统、证据回流到哪里、出了问题由谁负责。只有把这三件事说清，工具选型才算进入工程层。
工作系统接入
- 终端、git、worktree、MCP。
- 可与 GitHub review、Spec Kit、Superpowers 等方法层叠加。
- 适合做本地 owner，再把结果回流到 PR 系统。
证据链
- 命令执行记录、root cause / plan 说明和最终 diff 是主要证据。
- 如果只剩一段对话，没有命令和验证结果，说明流程没有落地。
治理矩阵
| 治理面 | 最低要求 | 不满足时的风险 |
|---|---|---|
| 工作系统接入 | 终端、git、worktree、MCP。 | 入口成功提示会替代真正的任务状态。 |
| 证据链 | 命令执行记录、root cause / plan 说明和最终 diff 是主要证据。 | 团队无法解释“这次到底跑了什么、改了什么”。 |
| Owner 与规则 | terminal-first 最大价值来自边界控制，不是自动化本身。 | 团队不愿维护规则文件，也不愿看 diff 和命令输出。 |
| 扩张节奏 | 先从低风险、高频任务试点，再扩大到复杂任务。 | 高频任务都转到平台或 IDE，终端入口只剩边缘用途。 |
Owner、审批与 rollout 清单
- 先定义谁拥有入口规则、谁拥有 repo 合同、谁拥有最终 merge 责任。
- 把“哪些任务能直接放行、哪些任务必须人工接管”写成可复用清单。
- 默认先从低风险、高频任务试点，再扩大到长任务或跨模块任务。
- terminal-first 最大价值来自边界控制，不是自动化本身。
- 计划、执行、验证和审批必须有清晰顺序，不能混在同一次输出里。
团队落地顺序
- 先确认 Claude Code 在系统里负责哪一段，而不是一开始就给它全部权限。
- 再把 review 证据固定成 diff、命令结果、说明和 handoff 记录。
- 最后才扩大适用范围，否则你只是在放大现有治理缺口。
下一步怎么读
- Superpowers：如果你想把 brainstorming、plan、worktree、TDD 和 review ritual 固定下来。
- Spec Kit：复杂 feature 先用 spec 固定边界，再回到 Claude Code 执行。
- GitHub Copilot：本地终端执行与 GitHub PR 收口形成分工。
- OpenAI Codex：如果你更需要更强执行栈和云端任务。
- Gemini CLI：如果你更倾向轻量终端入口和 GitHub 结合。
- VS Code Agents：如果你更依赖 editor 控制面与 background agents。