第14课：团队协作中的 Claude Code
阅读时长：约20分钟
难度：★★★☆☆
适合人群：已经个人用好了 Claude Code，想在团队里推广的开发者和技术负责人
学完之后：你能设计一套团队共享的 Claude Code 协作方案，并且知道怎么推广而不引起反感
一个人快不算快
《Claude Code 从入门到精通》试读篇：Claude Code 是什么？你可能从第一步就用错了
《Claude Code 从入门到精通》试读篇：你的第一次 Director Mode 体验（二）
《Claude Code 从入门到精通》试读篇：写好 Prompt 的结构化思维，10组正反对比，看完直接套用（三）
《Claude Code 从入门到精通》试读篇：当 Claude 理解错了怎么办（四）
《Claude Code 从入门到精通》目标优于指令，Director Mode 第一支柱（五）
第06课：让 Claude 自己分配任务——并行 Agent 策略
《Claude Code 从入门到精通》第07课：结果验证——你最不能省的一步
第08课：CLAUDE.md，让 Claude 永远记住你的规矩
第09课：10个高频场景 Prompt 模板库，复制、改几个词、直接用
第10课：Agent 体系，认识你的 AI 团队成员
第11课：Multi-Agent 实战，并行编排的5种模式
第12课：MCP 与 Hooks——给 Claude Code 装上插件和自动化引擎
第13课：日常开发工作流，从晨会到代码提交
你现在一个人用 Director Mode 已经很熟了。效率提升3-5倍，每天多做好几个任务。
但你有没有注意到一个尴尬的情况：你用 Claude 写的代码风格跟同事的越来越不一样。
你的代码严格遵守了 CLAUDE.md 里的规范——命名一致、错误处理统一、测试齐全。但你同事还在用"老方法"写代码，风格各异。
更尴尬的是：你审查同事的 PR 时，Claude 帮你发现了一堆问题，但你每次都要解释"这个要按规范来"——而这些规范只存在于你的 CLAUDE.md 里，同事根本不知道。
一个人用 Claude Code 是线性提升。一个团队用，才是指数提升。
因为团队统一之后：
共享的 CLAUDE.md = 所有人写出来的代码风格一致
共享的 Memory = 决策不需要反复讨论
CI/CD 集成 = 每个 PR 自动获得一致的审查
Prompt 模板共享 = 新人上手速度翻倍
这节课教你怎么把个人的高效扩展到整个团队。
第一步：团队版 CLAUDE.md 的设计
第08课你给自己的项目写了 CLAUDE.md。团队版需要考虑更多东西。
Claude Code 的四层配置体系
Claude Code 支持四层配置，从通用到具体：
┌─────────────────────────────────────────┐ │ 第1层：组织级（IT部门控制） │ │ 位置：/etc/claude-code/settings.json │ │ 用途：安全策略、MCP白名单 │ │ 特点：所有人必须遵守，不可覆盖 │ ├─────────────────────────────────────────┤ │ 第2层：个人全局（每个人自己配） │ │ 位置：~/.claude/CLAUDE.md │ │ 用途：个人偏好、全局工具 │ │ 特点：只影响自己 │ ├─────────────────────────────────────────┤ │ 第3层：项目级（团队共享，提交到Git） │ │ 位置：./CLAUDE.md │ │ 用途：项目标准、团队规范 │ │ 特点：所有团队成员共享 │ ├─────────────────────────────────────────┤ │ 第4层：项目个人级（个人微调，gitignore） │ │ 位置：./CLAUDE.local.md │ │ 用途：个人覆写 │ │ 特点：不提交到Git，只自己用 │ └─────────────────────────────────────────┘ 优先级：个人项目级 > 项目级 > 个人全局 > 组织级团队用的关键是第3层——项目级 CLAUDE.md。这个文件提交到 Git 仓库，所有人共享同一份规范。
团队 CLAUDE.md 跟个人版有什么区别
个人版你可以写得随意——反正只有你自己看。团队版需要：
更明确的权威层次——哪些规则是铁律（不可违反），哪些是建议（可以灵活处理）：
## 不可协商的规则（任何情况下都不能违反） - 所有 PR 必须有测试 - 代码中不能有密钥/凭证 - 涉及认证/支付的变更必须安全审查 ## 项目默认（特殊情况下可覆盖） - 优先使用函数式编程风格 - 使用命名导出而非默认导出 - 公开 API 必须写文档 ## 建议（偏好，不是要求） - 考虑性能影响 - 优先使用组合而非继承更详细的"可以做"和"需要确认"——团队里 Claude 的权限边界要写清楚：
## Claude 可以自主做的（不需要人确认） - 读取项目中的所有文件 - 创建和修改 src/ 和 tests/ 下的文件 - 运行测试和 lint - 创建本地 Git 分支 - 安装开发依赖 ## 需要人确认的 - 修改 .env 或配置文件 - 安装生产依赖 - 推送到远程分支 - 删除文件 - 修改数据库结构模块化的规则目录——大项目规范太多，全塞在一个文件里不好维护。用.claude/rules/目录拆分：
.claude/