写一份简短、可执行的项目规则
把团队已经认可的做法告诉 AI，而不是堆积泛泛的口号。
- 记录架构边界、常用命令、关键模块、禁改区域和数据处理要求，注明维护人。
- 保留适用于多数任务的规则；专题知识用链接或按需材料，避免每次加载过长背景。
- 规则先经团队审阅，再合入仓库；使用适合当前工具的项目指令文件，不覆盖既有约定。
留下什么
项目协作规则、维护人、修订记录。
试着做一次用一次真实返工检验规则：能防止同类问题吗？不能就修改具体步骤，不追加“必须高质量”这种空话。
COLLABORATE / 从个人方法到共同标准
团队协作规范
面向小团队和技术负责人。明确任务、审阅与交付责任，保留证据，再用真实结果迭代方法。
免费方法与模板 · 不包含自动代码审查或托管团队管理服务
给变更分级，而非每一步都审批
低风险工作直接推进，高风险变更留给有职责的人确认。
- 低风险：文案、样式、小范围可逆修复，按相关检查与常规审阅处理。
- 一般风险：接口行为、跨模块逻辑、新依赖，列出影响范围、验证与兼容性，由模块负责人审阅。
- 高风险：身份权限、支付、数据迁移和生产配置，指定责任人、专项验证、发布窗口与回退计划；先授权再执行不可逆操作。
留下什么
风险分级表与每类变更的负责人。
试着做一次把“改按钮文案”和“改订单幂等逻辑”分别归类，写出不同的验收要求；不把高风险过程套到所有任务上。
为 AI 参与的 PR 设共同标准
大家按相同证据审阅，减少“我这里没问题”的来回。
- PR 写明目标、行为变化、影响范围、实际验证、未覆盖项和回退办法；AI 参与了什么只作背景，不作质量担保。
- 作者先自检，审阅者核对关键行为；发现阻断问题先修复，必要的偏离必须说明并由责任人接受。
- 小改动避免无关整理。合并后继续验证集成与实际发布结果，不把CI通过当成全部验收。
留下什么
统一 PR 模板、审阅结论和阻断问题处理记录。
试着做一次使用模板审阅一项接口字段变更，检查旧客户端和错误路径；提出能直接修复的意见。
明确谁来决定可以交付
工具负责执行，工程责任仍然要落到人。
- 任务负责人确认目标与范围；实现者提交变更及证据；审阅者核查关键行为。小团队可兼任，但仍要完成对应步骤。
- 发布负责人确认上线条件、观察项与回退触发条件。数据库和外部操作单独制定恢复方案，不能只还原代码。
- 用户数据、源码和凭据的使用遵守项目要求。推广案例需取得授权，不能把真实客户资料直接拿来演示。
留下什么
角色责任表、发布与观察清单。
试着做一次给一个订单修复写发布前检查、上线后观察和回退条件，并说明谁有权作出决定。
用试点数据改进协作
先观察一个小团队的真实任务，不急着发布“效率翻倍”。
- 建议先选一类维护任务试行两周；记录复杂度、工具、任务数及失败样本，再与相近任务比较。两周是试点建议，不是统计保证。
- 记录交付周期、人工审阅与返工时间、首次验收通过、调用费用及固定观察期的回归缺陷。不要用代码行数当产出。
- 每周找出一个主要返工原因，更新对应规则；公布结果时附样本量、基线和观察限制，避免把所有变化归因于AI。
留下什么
试点记录表、每周复盘与下一项改进。
试着做一次如果生成更快但审阅与返工增加，重新计算总耗时；不要只挑生成环节宣布提效。