评测环境里分数再高,和真实团队直接用,还差最后一座桥——怎么安全地把产品放出去。
开场:考驾照和上真路是两回事
你在驾校考场里,倒车入库、侧方停车全都满分。但考官不会因为你满分,就让马路上所有人给你让路。考场上的满分,和真实道路上的安全,是两回事。
AI 审查也一样:评测环境里 P/R 再漂亮,也不等于"可以直接放到真实代码仓库上给整个团队用"。从"测得好"到"敢上线",要过几道产品的关。
二、产品在真实流程里扮演什么角色(先想清楚)
上线前,最该想清楚的是:AI 审查在团队的真实流程里,站着什么位置? 这决定了它该多"强势"。
常见的两种定位:
| 定位 | AI 的角色 | 该多强势 |
|---|---|---|
| 辅助 | 给人工审查当"助手指",标出疑似点 | 可以大胆些,人最后把关 |
| 把关/门禁 | 当一道检查关卡,过了它才能合并上线 | 必须谨慎,管理好误报漏报 |
同样的 AI,在"辅助"和"门禁"两种定位下,配置、风险和上线策略完全不同。 产品上线前,先想清楚是哪种——绝大多数团队应该先从"辅助"开始,别一上来就让它"把关"。
三、门禁(gate)怎么设计,才算"不瞎放行"
如果 AI 审查要做一道"关卡",它要满足几个硬要求(这正好呼应第 2 篇的 fail-closed):
① 机器人挂了 ≠ 审查通过 这是第一条底线。如果 AI 服务崩了,系统绝不能默认"没问题,放行"——否则等于把关的门神被打晕了,大家还以为是过了关。正确做法:标记为"审查未完成",让流程停下来等人工处理。
② 每批改动只审一次,不重复骚扰(幂等) 同一个 MR(合并请求)不该被同一位 AI 重复评论、重复打扰。要有"已审过"的标记——确保它不重复干活,也不制造噪音。
③ 只读、可回滚 AI 审查永远只能"看",不能动手改代码。审查产品的定位是"给意见",不是"替团队写代码"。而且任何时候出问题,都能退回"没有 AI 把关"的旧流程,不会卡死团队。
④ 结论可追溯、可申诉 每个"通过/警告"的结论,都链条到"哪次审查、用什么配置、看到什么"。团队觉得判断错了,能查、能申诉,而不是对着一个"黑色盒子"干瞪眼。
四、怎么"安全地"上线:用灰度一步步来
就算上面都满足,也不该"一键全量上线"。稳妥的做法是灰度(gradual rollout)——像试水温一样,先小范围、后全量。
一个合理的灰度路径:
第 1 步:影子(只跑不打扰) AI 在后台默默审查,但结果不发给任何人。先收集一批"它到底说了啥、准不准"的真实数据。这时候零风险——没人被打扰。
第 2 步:只给"内部/少量试点团队"看 选一个愿意当"小白鼠"的团队,让 AI 以"辅助"身份在旁边给建议。观察真实的误报漏报、团队的真实反应。
第 3 步:按风险分场景放开 先在"低风险改动"上用(比如文档、测试),别一上来就让它守"高危重构";再逐步扩大到更核心的代码。
第 4 步:数据说话,再考虑"把关" 到了真的考虑"让 AI 把关"这步,必须是累积了足够多真实表现数据、证明它可靠之后的事,而不是"感觉它挺好"就让它把关。
五、灰度的本质:把"衡量和信任"合二为一
你可能会发现,灰度的每一步,都在做同一件事:
- 先降风险(影子模式,不打扰);
- 后收集数据(真实表现);
- 再给权限(逐步放开);
- 最后才给信任(让人听它的)。
这正是本系列反复强调的主线:AI 审查这种信任产品,权限和信任不是"一上来就给",而是"被证据一点点换来的"。 评测(前面的所有篇)负责在受控环境拿到证据,灰度(这一篇)负责在真实环境攒回证据——两者接力,产品才敢真正放出去。
深入一点(可跳读)
- 门禁的"状态机"要设计对:一个 MR 至少要有"未审查 / 审查中 / 审查完成(通过或有警告 / 审查失败)“等状态,并且审查失败 ≠ 通过。
- 灰度的每一步,都要有"退出开关”:发现可以随时回滚到"无 AI 把关"的旧模式,不能让产品把团队锁死。
- “按风险分场景"需要落地成规则:比如按"是否改到核心模块"“改动行数多少"“是否动到数据库/安全相关"来分级,不同级别给 AI 不同的把关力度。
这一篇的收获
评测里的高分,不等于能直接上线。从"测得好"到"敢上线”,要过几道关:想清楚定位(辅助还是门禁)、门禁满足四条底线(挂了≠通过、只审一次、只读可回滚、可追溯可申诉)、并按灰度逐步放开——用真实数据一点点换回团队的信任,而不是相信"感觉它挺好”。
上线之后,产品要长期活着,靠的是持续正确的迭代。下一篇讲:怎么用数据做产品迭代——什么时候加能力,什么时候该收手。