第十一章：团队落地：规则固化、模板复用、质量门禁

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

个人用 Cursor 很容易提升效率，但团队要稳定收益，必须解决：

• 提示词质量不稳定（每个人写法不同）
• 改动边界不一致（有人动了不该动的目录）
• 验收不一致（有人没跑测试就合入）

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

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

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

项目规则（Cursor 必须遵守）：

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

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

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

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

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

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

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

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

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

门禁建议至少包含：

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

同时要求 Cursor 每次变更都产出：

• 变更摘要
• diff
• 验证命令与结果
• 回滚方式

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

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

• 大改动必须拆分（每次都可验证）
• 任何“格式化全仓库”必须单独 PR
• PR 描述必须包含风险点与验证命令

11.6 本章小结

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

• 规则固化：范围/依赖/安全/验收写清楚
• 模板复用：提示词稳定化
• 门禁统一：tests/lint/build 成为默认路径
• 审阅优先：diff 清晰，改动可控

下一章给出排障清单：当输出跑偏、索引异常、命令失败时，如何快速定位与修复。