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

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

个人使用 Trae 很容易提升效率，但团队要稳定收益，通常会卡在三件事：

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

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

11.2 项目规则模板（可直接复制）

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

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

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

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

验收：
- 每次改动必须跑：<tests>、<lint/typecheck>、<build>
- 关键节点先输出 diff，再继续下一步

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

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

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

模板的价值是“降低随机性”：新同学也能稳定产出。

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

门禁建议至少包含：

• tests：证明行为正确
• lint/typecheck：减少风格与类型问题
• build：确保能编译/打包

并要求每次交付都包含：

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

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

建议团队约定：

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

11.6 本章小结

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

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

下一章给出排障清单：当输出跑偏、命令失败、诊断不清零时，如何按层定位与修复。