团队怎么制定 Claude Code 使用规范

团队 Claude Code 使用规范教程：制定允许场景、禁止事项、权限模式、审查要求、验收标准和敏感信息边界。

团队使用 Claude Code，不能只靠“大家小心点”。

规范的目的不是限制效率，而是让团队知道：哪些能交给 CC，哪些不能交给 CC，交给 CC 以后怎么验收。

一份规范至少包含什么

建议包含 7 部分：

允许使用场景。
禁止使用场景。
权限模式建议。
敏感信息规则。
代码审查要求。
验收和提交要求。
CLAUDE.md 和模板维护规则。

规范不要只写“原则”，还要写“动作”。比如不要只写“注意安全”，而是写清楚哪些信息不能发、哪些任务必须只读、哪些改动必须人工评审。

允许使用场景

可以写：

团队允许在以下场景使用 Claude Code：
1. 只读分析项目结构、模块和调用链。
2. 辅助生成文档、README、交接说明。
3. 辅助 Bug 排查和日志分析。
4. 辅助生成测试策略和验收清单。
5. 辅助小范围代码修改。
6. 辅助提交前 diff 审查和 Code Review。

这些是相对低风险、高收益的场景。

团队刚开始推广时，可以先只开放这些场景。等成员熟悉 diff 审查、权限模式和验收流程后，再逐步开放中风险任务。

禁止使用场景

必须写清楚：

禁止在以下场景直接使用 Claude Code 自动修改：
1. 生产数据库修复或删除数据。
2. 支付、资金、订单核心链路。
3. 权限、认证、安全策略核心逻辑。
4. 生产配置、密钥、Token、证书。
5. 未脱敏的用户隐私数据。
6. 未经评审的大范围重构。
7. 未确认影响范围的依赖大版本升级。

注意不是说这些场景永远不能用 CC，而是不能直接让它自动改。最多先做只读分析和风险评估。

禁止场景要写得明确，不要留“看情况”的口子。否则团队成员会把高风险任务理解成“我觉得能让 CC 试试”。

权限模式建议

可以按风险分级：

任务类型	建议模式
文档、README、说明整理	低风险，可小步执行
只读分析、架构梳理、日志分类	只读，不修改
普通 Bug、小功能、小样式	Plan Mode 后逐步执行
接口、权限、配置、依赖升级	严格审批，必须验收
数据库、生产、支付、安全	默认只读，必须人工评审

团队规范里要避免一句“都可以用 auto”。

敏感信息规则

写得越明确越好：

不得向 Claude Code 或外部模型提供：
1. API Key、Token、账号密码。
2. 生产数据库连接串。
3. 用户手机号、身份证、地址、支付信息。
4. 未脱敏日志。
5. 公司未授权的私有代码片段。
6. 客户合同、内部商业数据。

如果要分析日志，必须先脱敏。

Code Review 要求

团队可以规定：

凡是 Claude Code 参与生成或修改的代码，提交前必须：
1. 查看完整 diff。
2. 说明 CC 参与了哪些环节。
3. 说明人工确认了哪些点。
4. 跑必要检查。
5. 标注剩余风险。
6. 进入正常 Code Review 流程。

这能防止“AI 说完成了”就直接合并。

验收要求

团队规范里还要写验收标准：

Claude Code 参与的任务，完成后必须说明：
1. 实际修改了哪些文件。
2. 是否符合原任务范围。
3. 运行了哪些检查。
4. 哪些路径已经人工验证。
5. 哪些风险仍未确认。
6. 是否需要 Reviewer 重点看某些文件。

没有验收说明，就不进入合并流程。

任务大小限制

团队初期可以规定：

任务规模	建议处理方式
1-3 个文件的小改动	可以让 CC 辅助执行
4-10 个文件的中等改动	必须 Plan Mode 和分步验收
超过 10 个文件	拆任务，不允许一次性完成
涉及配置、权限、数据库	默认高风险，先评审

这不是绝对规则，但能防止 CC 一次性铺太大。

团队规范模板

# Claude Code 团队使用规范

## 使用目标
提升项目理解、开发效率、审查质量和文档沉淀，不替代工程判断。

## 允许场景
【列允许场景】

## 禁止场景
【列禁止场景】

## 权限策略
【按任务风险选择模式】

## 敏感信息
【密钥、隐私、生产数据边界】

## 提交流程
【diff 审查、验证、Code Review】

## CLAUDE.md 维护
【长期规则谁维护、怎么更新】

推行流程

建议按 4 步推行：

1. 先发布 5 条红线。
2. 选 2-3 个低风险场景试点。
3. 收集一次真实 PR，复盘 CC 做了什么、人工确认了什么。
4. 再补充权限、验收、CLAUDE.md 维护细则。

不要一上来写很重的制度，没人执行就等于没有规范。

团队成员需要统一的说法

为了减少沟通成本，可以统一几句话：

场景	推荐说法
只分析不改	“本次只允许 CC 只读分析，不修改文件。”
需要先计划	“先输出计划和风险，确认后再执行。”
提交前审查	“请说明 CC 参与范围、人工确认点和验收结果。”
高风险任务	“只做方案审查，不自动执行。”

统一话术以后，团队使用 CC 会更稳定。

推行建议

团队不要一次写 30 条没人看的规范。

先从 5 条红线开始：

不发密钥。
不发生产隐私数据。
高风险任务只读分析。
AI 代码必须审查。
CLAUDE.md 只写长期规则。

等团队习惯稳定后，再逐步补细节。

规范是否有效怎么判断

一个团队规范是否有效，看这几件事：

成员知道哪些信息不能发给 CC。
高风险任务不会直接进入自动修改。
PR 里能看出 AI 参与范围。
Reviewer 知道重点审查哪里。
CLAUDE.md 不会被临时任务污染。
出问题时能追溯谁确认、怎么验收。

如果这些做不到，规范就还停留在口号阶段。