没有哪种"审得好"是完美的,只有权衡。而权衡之前,得先有两个词:误报、漏报。
开场:烟雾报警器的两难
你家装了个烟雾报警器,它只有两种错误:
- 误报:没着火它也响,吓你一跳,半夜把你吵醒;
- 漏报:真着火了它不响,火都烧起来了你还不知道。
这是个经典的"两难":想让它不漏报,就把灵敏度调高——结果连炒菜冒点烟都响,天天误报;想让它少误报,就调低灵敏度——结果真着火可能也不响。
没有任何报警器能做到既不误报也不漏报。 你能选的,只是在哪一边多担一点风险。
AI 代码审查,就是一台代码报警器。它的两种"错误",正是那两个词。
二、把四个词一次讲透(TP / FP / FN / P / R)
我们用"AI 说有问题、代码’实际’有没有问题"来对照,四种情况:
| AI 说有 bug | AI 说没 bug | |
|---|---|---|
| 实际真有 bug | ✅ 抓对了 = TP(抓对了) | ❌ 漏了 = FN(漏报) |
| 实际没 bug | ❌ 错怪了 = FP(误报) | ✅ 放对了(正常的) |
记号解释(不用背,理解即可):
- TP(True Positive)= AI 抓到的真问题
- FP(False Positive)= 误报——AI 说是问题,其实不是
- FN(False Negative)= 漏报——AI 没说是问题,其实是
从这三个数推出两个最重要的指标:
精确率 P = TP / (TP + FP) → AI 报告的100个"问题"里,真的对的有几个?
只看"报出来的准不准"
召回率 R = TP / (TP + FN) → 100个真问题里,AI 抓到了几个?
只看"该抓的漏没漏"
用报警器的话说:
- P(精确率)= 它响的 100 次里,真着火了几次(误报少=高)
- R(召回率)= 真的着火 100 次,它响了几次(漏报少=高)
P 低 = 乱报;R 低 = 漏检。这两个,就是衡量一台"审查报警器"好坏的核心。
三、为什么"没有唯一最好的配置":误报漏报的代价不对称
回到产品设计:AI 审查到底该"多报"还是"少报"?没有标准答案,取决于代价。
看两种场景:
场景 A:AI 给资深工程师当"助手指" AI 把疑似问题都标出来,高手拿着清单去人工确认。这时候,多一些误报也无妨——反正最后有高手把关,误报顶多多看两眼。这里可以让 AI 大胆一点、多报,重点减少漏报(别让真问题溜走)。
场景 B:AI 自动把关、决定"能不能上线" 如果 AI 说"OK"就直接放行,那误报和漏报的代价都很大:漏报=放行事故(要命),误报=拦住正常上线(耽误进度)。这时候政策要权衡,通常宁可谨慎一点。
结论:产品不能拍脑袋定"多报还是少报",要先想清楚"AI 在你的流程里扮演什么角色、每种错误各要付多大代价"。
四、回到那个更扎心的问题:我们怎么知道 AI “实际"有没有问题
你看上面的表,要算 P 和 R,得知道"实际到底有没有 bug”——这个"实际"从哪来? 这就是下一章"标准答案/考卷"的起点:
- 你得有一批已经被确认真假的代码问题,才能拿 AI 的结果去对;
- 这批"标准答案"决定了你能不能算得出 P/R,也决定了你的产品能测得多准。
先记住这句话:没有可靠的"标准答案",你连"它审得好不好"都无从谈起。 下一篇就讲怎么造这份答案。
深入一点(可跳读)
- 为什么不能只看一个指标? 只看 R(召回)会鼓励乱报——抓得多、哪怕全是误报也算"抓得多";只看 P(精确)会鼓励少报——报得少自然准,但漏一堆。所以要两个一起看,并观察"漏掉的问题里有没有要命的"。
- f1 分数:一个把 P/R 合成单数的常用做法(二者调和平均)。适合快速比较,但产品决策时还是要分开看,因为误报漏报的代价不同。
- “严重度”:进一步,真问题还分"要命"和"小瑕疵"。产品里常把 P/R 按严重度分层算——安全漏洞的漏报和风格问题的漏报,不是一个重量级。
这一篇的收获
「审得好」没有一个绝对答案,只有权衡:在误报和漏报之间,选一个更符合你场景的姿势。而衡量它的两把尺子,叫精确率(P)和召回率(R)——一个管"报得准不准",一个管"该抓的漏没漏"。
要想真算得出这两个数,你得先有一份"正确答案"。下一篇讲:「标准答案」从哪来,以及为什么它是产品的天花板。