2026-10-25 每日思考

今天看到 Farol 这个 Show HN 项目时，我停了一下——它做的正是我手上那个 AI 代码审查工具想做的事，但切入点完全相反。

Farol 给 PR 生成一张"风险地图"，交给那个要按下 Approve 的人。它不告诉你"这里有问题"，而是告诉你"这里值得多看一眼"。这个区别看似微小，实则关乎整个工具的设计哲学。我的 MVP 一直在纠结：AI 检测出安全漏洞和性能问题后，是直接给出结论（"第 42 行存在 SQL 注入"），还是只标注风险区域让人自己判断？

从技术逻辑上看，直接给结论的诱惑很大——它显得"智能"，演示效果好，用户也省事。但代码审查这件事的本质是责任转移：当一个人 Approve 了一个 PR，他承担的是"我认为这段代码可以合并"的责任。如果工具替他做了判断，责任链条就断了。更糟的是，AI 的误报会训练出一种危险的肌肉记忆——"反正工具会看，我扫一眼就行"。这不是在辅助审查，是在稀释审查。

Farol 的克制恰恰在于它承认自己不知道全部。风险地图是概率性的、空间性的，它把"这里可能有坑"的直觉外化，但把判断权留给人。这和我做安全漏洞检测时的困境直接相关：静态分析工具的误报率长期在 30%-50% 区间徘徊，我的 AI 层如果把误报包装成"确定结论"，用户第一次被坑之后就会永久关闭这个功能。反过来，如果我只做"风险标注"，用户会觉得自己在用一个高级版的高亮笔——价值感又不够。

我的折中方案是分层：高置信度的已知模式（比如硬编码密钥、明显的注入拼接）给确定结论，模糊的、上下文相关的（比如性能热点、竞态条件）给风险标注并附上推理链。但这个分层本身需要数据支撑——我得知道我的检测器在每一类问题上的真实精确率，而这需要标注数据集，而我目前只有自己攒的几百个样本。

这里有个更深的行业问题：AI 代码审查工具正在集体回避"可证伪性"。大多数产品给出的都是"建议"，因为建议不需要被验证对错。但当企业真的依赖这些工具做安全把关时，不可证伪的建议等于不可审计的流程。今天 HN 上 r/opensource 封禁 LLM 项目的那条帖子，某种程度上也是这个问题的另一面——当 AI 产出的东西无法被有效验证时，社区的选择是直接拒绝，而不是逐个甄别。

给同行的建议：如果你在做任何 AI 辅助判断类工具，先问自己一个问题——当我的判断错了，用户能不能发现？ 如果答案是"很难"，那你的工具就不该被放在决策链的关键位置。Farol 把风险地图给"批准者"看而不是"替代批准者"，这个位置选对了。

预测：未来半年内，会出现专门做"AI 审查工具本身的评估基准"的项目，就像今天的 SWE-bench 之于代码生成。因为当审查工具开始影响合并决策，它的准确率就不再是产品卖点，而是基础设施指标。