2026-09-20 每日思考

今天读到那篇把 LLM 比作"通灵师冷读术"的文章，我盯着屏幕想了很久——不是因为它说得对，而是因为它说中了我做 AI 代码审查工具时最不愿承认的那件事。

冷读术的核心不是骗，是让被读的人自己完成剩下的推理。通灵师说"你最近在纠结一个重要的决定"，你立刻想起换工作的事。模型说"这段代码在并发场景下可能有风险"，我作为审查者立刻开始脑补具体场景——然后给它打了个"有洞察力"的标签。

问题在于，我的 MVP 现在检测安全漏洞和性能问题，评测集是我自己标注的。标注的时候，我是不是也在做同样的事？看到模型输出"这里存在注入风险"，我回看代码，确实有个未过滤的参数，于是标记为正确。但模型可能只是识别了"字符串拼接 SQL"这个模式，而没理解数据流。这两者在我的评测集里得分一样，在实际防护效果上差得很远。

这就是冷读术的工程版本：评测指标衡量的是"人类能否把输出解释成正确"，而不是"输出本身是否正确"。前者容易刷分，后者才是产品价值。

更麻烦的是，这个偏差在安全领域代价不对称。一个漏报（false negative）的注入漏洞，可能让用户被拖库；一个误报（false positive）只是让人多看一眼。我现在用的 F1 之类的综合指标，把这两类错误等同对待，这本身就是错的。安全审查工具应该按"漏报零容忍、误报可协商"来设计阈值和评测口径。

所以今天我改了两件事：一是评测集里每条样本必须记录"模型是否给出了数据流路径"，只给结论的不计满分；二是把误报和漏报拆成两个独立指标看，不再合并。改动很小，但它逼我直面一个事实——我之前的"准确率不错"，有一部分是自己在替模型补全。

对做同类工具的人，我的建议是：在写第一行评测代码之前，先问自己"如果模型输出模糊但方向对，我会不会给它高分"。如果答案是会，那你的评测集已经在骗你了。预测一句：未来半年会有一批 AI 编码工具在真实生产环境暴露漏报问题，而它们的评测报告里，F1 都很好看。