AI 辅助研发流程门禁标准

一、为什么研发流程需要重新设门禁

传统研发门禁是为人设计的：人写代码，人在评审时质疑，人在测试里兜底。AI 进入研发流程后，这个前提变了——产出速度提高了，但产出的概率性也进入了主干。

于是出现两类典型问题：

• 放行过宽：AI 生成的代码直接合入，风格与既有架构不一致、边界条件缺失，问题在生产环境才暴露
• 一刀切禁用：因为不信任而全面禁止，结果是 AI 在研发流程之外被偷偷使用，风险更不可控

两种做法都错在把 AI 当成”人”或”工具”二选一。正确的做法是：任务先分流，方法才分明——确定性任务走规则求解，概率性任务走模型生成再收敛，两条路径共同汇入同一个门禁体系。

---

二、分流：哪些环节允许 AI 参与

研发环节	任务性质	AI 角色	收敛方式
需求澄清	概率性	生成问题清单、识别歧义	人工确认需求基线
方案设计	概率性	生成候选方案与权衡	规则校验架构约束 + 人工决策
编码实现	混合	生成实现与测试骨架	静态检查 + 测试 + 人工评审
代码评审	确定性为主	生成评审提示	规则自动校验风格与安全
测试与校验	确定性	辅助生成用例	覆盖率与断言由规则判定
发布与回滚	确定性	不参与决策	流水线门禁 + 人工签字

原则：AI 可以参与生成，但不能参与定责。 只要一个环节需要承担责任，最终签字的人必须是人。

---

三、六道门禁与判据

门禁一：需求门禁

• 判据：需求描述无未消解歧义；验收条件可判定（非”体验更好”）；影响范围已标注
• 拦截：歧义项未关闭则不允许进入设计
• AI 参与：AI 输出歧义清单，人工逐条确认

门禁二：设计门禁

• 判据：方案符合架构约束（依赖方向、分层边界、数据模型）；已说明失败路径与降级策略
• 拦截：架构约束自动校验不通过则不允许进入编码
• AI 参与：AI 输出候选方案，规则系统校验约束，人做选择

门禁三：编码门禁

• 判据：静态检查通过；单元测试通过且覆盖关键分支；新增代码有明确归属与责任人
• 拦截：任一不通过则不允许提交评审
• AI 参与：AI 生成实现与测试骨架，测试与静态检查由确定性规则判定

门禁四：评审门禁

• 判据：风格与安全规则自动校验通过；AI 生成部分已被人工逐段确认（不得整块放行）
• 拦截：未逐段确认的 AI 生成代码不允许合入
• 铁律：没有”AI 写的一整块代码无人读过”这种情况

门禁五：测试门禁

• 判据：回归集全通过；关键路径覆盖率达标；性能与资源指标不退化
• 拦截：任一不通过则不允许进入发布
• AI 参与：AI 可辅助生成用例，但覆盖率与断言由规则判定

门禁六：发布门禁

• 判据：变更可回滚；灰度策略已配置；监控与告警已就绪；责任人已签字
• 拦截：不可回滚的变更不发布
• AI 参与：不参与发布决策

---

四、责任分工

角色	在门禁中的职责
开发者	对 AI 生成内容逐段确认，对提交内容负责
评审者	审核逻辑与边界，而非审核语法
规则系统	承担可枚举的确定性校验（风格、安全、覆盖率、约束）
AI	承担规模化生成与提示，不承担结论
责任人	在发布门禁签字，承担最终责任

责任永远在人，不在模型。 门禁的作用是把这句话变成流程里可检查的事实，而不是一句口号。

---

五、拦截记录必须回流

门禁不是一次性过滤器，而是闭环的数据源。每一次拦截都要留下结构化记录：

• 哪道门禁拦的、拦截时的输入特征
• 拦截原因归类（风格 / 安全 / 逻辑 / 覆盖 / 架构约束）
• 人工是否修改、改了什么
• 同类拦截是否重复出现

这些记录驱动四件事：更新规则集（可枚举的交给规则）、调整 Prompt 与工作流基线（减少同类错误）、补充测试用例、以及判断哪些环节可以放宽、哪些必须收紧。

判断标准：人工干预率是否随轮次下降。 如果不降，说明门禁只是在拦，没有在收敛。

---

六、豁免与灰度

• 豁免必须留痕：谁批准、理由、影响范围、失效时间，且必须有失效时间
• 新门禁先灰度：先在一条链路生效，观测拦截率与误拦率，再推广
• 误拦率过高即门禁设计失败：拦得多不等于拦得对，误拦会逼迫团队绕过流程

---

七、落地步骤

1. 分流盘点：把研发流程中的任务按确定性与概率性分类，确定 AI 可参与的环节
2. 先上两道门禁：从编码门禁（静态检查 + 测试）与评审门禁（逐段确认）起步
3. 补规则集：把可枚举的校验写成规则，交给确定性路径
4. 接拦截回流：建立拦截记录的结构化存储与周度复盘
5. 扩到全流程：需求、设计、发布三道门禁在规则集成熟后接入
6. 看人工干预率：以干预率下降作为收敛信号，逐步放宽已稳定的环节