第十一章：团队落地：项目规则、提示词模板、质量门禁

11.1 团队落地的关键：把“口头约定”变成“默认行为”

个人用 Claude Code 很容易起飞，但团队要稳定收益，必须解决三个问题：

• 新同学不知道项目约定，提示词质量不稳定
• 有人让 Claude 改了不该改的目录，风险外溢
• 没有一致的验收门禁，导致“看起来能用”但上线出问题

解决方式不是“多提醒”，而是“固化成规则与模板”。

11.2 项目规则模板（建议每个仓库都放一份）

你可以把下面这段直接作为团队规则的基础模板（根据项目调整）：

项目规则（Claude Code 必须遵守）：

范围：
- 允许修改：src/、tests/
- 禁止修改：.github/、infra/、deployment/、terraform/、docs/

依赖：
- 禁止新增依赖（除非明确要求）

安全：
- 绝不输出/提交密钥与敏感数据
- 不读取/修改 .env、证书、私钥
- 禁止运行破坏性命令（删除/清库/批量改写）

验收：
- 每次改动必须跑：<测试命令>、<lint 命令>、<构建命令>
- 关键节点先 /diff，再继续

11.3 提示词模板库：把最佳实践复用起来

建议团队至少沉淀三类模板：

• 修 bug 模板（复现→定位→修复→验证）
• 加功能模板（边界条件→兼容性→测试）
• 重构模板（行为不变→小步提交→全量验证）

你可以直接复用第 5 章的模板，并把项目的命令与目录边界填进去。

11.4 质量门禁：把“验收”变成默认路径

团队门禁建议至少包含：

• Lint/Format：保证风格一致，减少无意义 diff
• 单元测试：覆盖边界条件（空数据、异常输入）
• 构建：确保能编译与打包

你的目标是让 Claude 也遵循同一套门禁：

任何改动都必须跑完：<测试命令>、<lint 命令>、<构建命令>，并给出结果摘要。

11.5 评审规范：把“可审阅”作为第一优先级

团队协作中，Claude 的解释再好也不如一个清晰的 diff。建议你在团队中约定：

• PR 必须包含改动摘要、风险点、验证命令
• 大改动必须拆成多次 PR（每次可验证）
• 任何“格式化全仓库”的改动必须单独 PR

11.6 本章小结

你已经具备团队落地的最小闭环：

• 项目规则：范围/依赖/安全/验收写清楚
• 模板复用：提示词稳定化
• 质量门禁：测试/lint/构建成为默认路径
• 审阅优先：diff 清晰，改动可控

下一章给出排障清单：遇到安装、网络、权限、卡死等问题时，怎么快速定位与解决。