团队采用 Claude Code 的 Playbook：从个人工具到团队基础设施

Claude Code 个人用很爽，但在团队里推广会遇到新的问题：标准不统一、能力差异大、成本难以控制。以下是一个可行的采用路径。

第一阶段：建立共识（第 1-2 周）

不要强制推广，先做内部演示： - 选一个真实的工程师痛点（比如：手动写测试） - 用 Claude Code 现场解决 - 让团队看到效果，而不是听你描述

同时建立基础认知：

# 团队 onboarding 问题
claude "解释 Claude Code 的基本限制：
1. 它能做什么
2. 它不能替代什么
3. 常见的误用方式
输出为一份 3 分钟能读完的内部文档。"

第二阶段：基础设施（第 2-4 周）

建立团队共享的 CLAUDE.md：

# Team CLAUDE.md

## 技术栈约定
[项目的具体技术选型]

## 代码规范
[最重要的几条规范]

## 禁止事项
- 不修改 _test.go 文件除非明确要求
- 不引入未讨论的新依赖
- 不改变 API 接口签名

## 常用命令模板
[团队常用的 prompt 模板]

建立共享的 .claude/commands/： - /review：PR 前的标准检查清单 - /ship：提交前的确认流程 - /explain：为特定代码生成注释

第三阶段：建立规范（第 4-8 周）

什么需要 Claude Code 辅助，什么不需要：

# 推荐使用 Claude Code 的场景
- 写新功能的测试
- 理解陌生代码库
- PR 的初步审查
- 文档生成

# 需要谨慎使用的场景
- 关键业务逻辑（需要人工 review）
- 生产环境操作（必须人工确认）
- 安全相关代码（需要专业审查）

管理成本：

# 团队用量追踪（用 API key 区分成员）
# 建议按项目申请 API key，而不是每人一个
# 在 CLAUDE.md 里加约束避免浪费：
"不使用 extended thinking，除非明确标注任务需要"

衡量效果：

不要用"节省了多少小时"这种主观指标。更可靠的： - PR 的 review 轮次减少 - 测试覆盖率提升 - 新人 onboarding 时间缩短（能更快理解代码库）

常见阻力和应对：

工具推广最大的错误是假设"工具够好大家自然会用"。需要主动设计采用路径。