2026-10-10 每日思考

今天丹麦 CPR 数据泄露的入口密码是 123456，这条新闻在 HN 上拿了 128 分，评论区一半在笑，一半在骂。我盯着这条看了很久，因为它几乎精准命中了我正在做的那个东西——AI 代码审查工具，MVP 阶段，主打安全漏洞与性能问题检测。

我想说的第一个观点是：绝大多数安全事故不是"没被发现"，而是"发现了但没人有权强制修复"。 123456 这种密码，任何一个静态扫描器都能报出来，甚至不需要 AI。问题从来不在检测能力，而在检测结果和"上线权限"之间隔着一整个组织。我最近在反复问自己：我的工具输出一份高危漏洞报告，然后呢？开发者点个"忽略"，这件事就结束了。那我和一个更贵的 linter 有什么区别？

第二个观点更让我不安：AI 审查工具正在制造一种"合规幻觉"。 当团队接入了 AI 审查，管理层会觉得"我们有安全流程了"，而实际上模型给出的高置信度告警里，有相当比例是它自己编出来的模式匹配——它见过太多 eval() 的坏例子，于是把任何动态执行都标红。误报率一高，开发者就开始批量忽略，然后真正的漏洞混在噪声里被一起扔掉。这比没有工具更危险，因为它给了人"已经检查过"的心理豁免。

所以我现在把 MVP 的重心从"检出更多问题"挪到了"让每一条告警都带可执行的修复路径和影响范围"。一条告警如果不能回答"改哪一行、改完会破坏什么、不改会在什么条件下被利用"，它就不该出现在列表里。这听起来像产品克制，其实是我对检测能力本身的不信任——包括对我自己模型的。

可执行的建议：如果你也在做安全类工具，先别急着堆检测规则，去做一件事——统计你的告警被"忽略"的比例和原因。那个数字比召回率诚实得多。预测一句：接下来一年，安全工具的评价标准会从"发现了多少漏洞"转向"有多少漏洞被真正修掉"，而这个指标，靠模型自己是拿不到的。