Code Review 的本质是"信任"。而信任这东西,建立难,崩塌快。
开场:和医生问诊一个道理
你去看病,如果第一次问诊,医生就给你开了个完全不对的药,你还会信他第二次吗?
大概率不会。哪怕他过去"治好了很多人",只要一次离谱,你就再也不敢听他的了。
AI 代码审查就是这样一款信任产品——它的价值完全建立在"团队敢不敢听它的"上面。
一、为什么 AI 审查是"信任产品"
很多工具是"效率型":哪怕偶尔出错,用完不记仇(比如搜索,几个结果不准,换一个就是)。
但 AI 审查不是。它介入的是**“要不要放行这段代码上线”这种高风险决策。它说"有问题"或"没问题",团队会当真去做。所以它出错的代价不对称**:
- 乱报(误报):AI 说"这里有个 bug",其实没有。团队去查、去改、去争论——浪费时间、消耗耐心。一次、两次,大家就开始"AI 又在瞎说"。
- 漏报:AI 说"没问题",结果上线出事故。这是致命伤——团队从此彻底不再信任它,直接把它关掉。
一句话:别的工具错一次赔一次小钱,AI 审查错一次,赔的是整个团队的信任。
二、由此引出最重要的设计原则:fail-closed(宁可闭嘴,不可误导)
“信任会崩塌"这个事实,逼出一个反直觉的设计原则:
报不准的时候,宁可不说(或明说"我不确定”),也不要硬报一个错误的结论。
这叫 fail-closed(失败时关闭)。它是安全系统的标准思想——就像电梯的安全闸:出问题时,电梯宁可停着,也不要"冒一点险继续跑"。
放到 AI 审查上:
| 做法 | 结果 |
|---|---|
| 不确定也硬报"有个 bug" | 误报,消耗信任 |
| 不确定就闭嘴 / 标"存疑,请人工确认" | 不误导,信任保住了 |
| 真出问题(模型挂了)时假装"一切正常,通过" | 死罪,绝不答应 |
最要命的一种情况,连新手都能想到:AI 服务崩了,如果系统"默默当作没问题、直接放行",那等于把最重要的把关人给端掉了,团队还以为有人看着。“机器人挂了 ≠ 审查通过”——这是这类产品必须写死的一条红线。
三、从"信任"反推产品的三条设计原则
原则 1:宁可少报,不可乱报(控制误报) 吹嘘"我们召回率高、抓到很多问题"很爽,但如果里面有大量误报,团队会变成"狼来了"——没人当回事。宁可 AI 只说有把握的,让每个结论都值得被当真。
原则 2:报不准就明说自己不确定 给结论带置信度,或者干脆用"疑似/建议人工确认"这种语气。人不怕 AI 说"我不确定",怕的是 AI 自信地胡说。
原则 3:系统故障必须"显形",绝不静默放行(fail-closed) 这是底层保障,不是产品文案,是要写进代码、写进部署的硬性红线。
四、这对"怎么测这个产品"意味着什么
既然信任这么重要,那么测一个 AI 审查,就不能只看"它抓到了多少问题",还要特别关注它"错报了多少"和"错了还不自知"。
这直接决定了我们要做的质量评测要盯两类指标:
- 它报告的问题里,有多少是真问题?(别让团队白忙)
- 它漏掉的真问题,有多少?(别让事故溜走)
这两个指标,就是下一篇的"误报与漏报"。
深入一点(可跳读)
“fail-closed"在工程上的落地长什么样?举几个具体样子:
- 模型调用失败 → 这个 MR 的状态标记为"审查未完成”,而不是"通过";
- AI 输出的内容不符合约定格式(比如没给出"问题在哪个文件哪一行")→ 判定这次审查无效,计入"交卷失败",而不是当"没问题";
- 所有"通过"的结论,必须建立在"AI 真的完成了审查"这个前提上,而不是"AI 没来得及看就说通过"。
这些听上去像是"严谨的工程细节",但本质都是在守护同一件事:这个产品的每个"放行"信号,都必须是真的。
这一篇的收获
AI 审查是一台"信任机器":它的输出会被当真的执行。所以产品设计的第一原则不是"强",而是"可信"——宁可少报不可乱报,报不准要明说,系统坏了绝不能静默放行。
奠定了"信任"这个基调,下一章我们开始回答一个具体问题:「审得好」到底怎么算? 这就是误差报与漏报的报警器比喻。