协作与工程治理

人与 AI 的责任划分

环节	AI 可以辅助	人必须负责
需求	整理、找冲突、生成问题清单	决定目标、范围和优先级
设计	比较方案、生成草图和风险清单	选择架构并承担后果
开发	读代码、实现、测试、写文档	审核关键逻辑和授权操作
上线	准备清单、执行已授权自动化	批准生产变更和回滚决策
运营	汇总指标、发现异常	解释业务影响和采取行动

团队规则的最小集合

• 代码、文档、配置和设计的真源分别在哪里。
• 每个目录由谁维护，跨边界如何交接。
• 分支、提交、评审和发布采用什么流程。
• 哪些命令或外部动作允许自动执行，哪些必须确认。
• 测试、质量、安全和文案有哪些交付门禁。
• 失败、阻断和范围变化如何报告。

规则应短而明确，并能被工具读取。只写在聊天里的决定容易丢失，也无法稳定约束后续任务。

多人并行

并行任务必须尽量减少重叠写入。按模块、目录或独立验收目标切分；共享接口先锁定契约；每个任务说明输入、输出、依赖和完成状态。若两人需要修改同一核心文件，应明确合并顺序，不能靠最后覆盖解决冲突。

代码评审关注点

1. 变更是否真的对应需求和验收条件。
2. 是否保留了现有行为，或明确说明破坏性变化。
3. 安全、权限、数据和失败路径是否被考虑。
4. 测试是否证明行为，而不是只覆盖行数。
5. 是否引入了不必要复杂度、依赖或供应商锁定。
6. 文档和运行方式是否与代码一致。

把经验沉淀成资产

一次性提示词只解决当前任务。重复出现的规则应沉淀为项目说明，稳定步骤沉淀为脚本，跨项目方法沉淀为模板或 Skill，常见故障沉淀为运行手册，关键决策沉淀为决策记录。

沉淀时保留适用条件和失效条件。没有边界的“最佳实践”容易在新场景中变成错误约束。

交付状态要诚实

区分“已写方案”“已完成本地实现”“已通过测试”“已部署测试环境”“已上线生产”“已通过业务验收”。任何中间状态都不能自动等同于最终完成。