Mythos 报了一大批内核漏洞。整理下来，够得上错误修复的，大概十个。
剩下的条目里，二十四个没有细节，只写着"发生了崩溃"。十四个，判断下来根本不是漏洞。三个，是编造的数据。
多数人的第一反应：又一个被吹过头的 LLM 安全工具。
这个反应没错。但它什么也没解释。它解释不了这类工具为什么还在卖。
值得想的不是它准不准。
先看维护者那一端。讨论里有人说，自动提交到他维护的开源项目里的安全报告，大多冗长且没意义，得由懂行的人花几个小时读懂、判断、最后一并丢掉。
重点不是报告很烂。是那几个小时落在谁头上。
买家付钱给工具厂商，拿到一份报告，报告说扫过了。卖家拿到合同。真正坐下来消化那堆东西的人，既不是买家，也不是卖家。
一个很干净的成本转移。
你可能会说，市场迟早会惩罚它，不准的东西没人一直买。
停一下。
讨论里有人提到 Coverity 当年的误报率大概两成，比现在这些工具好得多，最后还是没推开。¹ 这个对比要紧。它说明误报率不是决定采购的那个变量。两成不行，五成也行，那"准不准"就不是关键。
那关键是什么。
同一批讨论里有一条：企业采购更愿意选那种能向管理层交代"安全审查做了、问题处理了"的工具，而不是会质疑假设、顺带暴露管理层认知不足的那种。
这条把整件事翻了个面。
工具卖的不是发现漏洞的能力，是"我们做过安全审查"这个能出示的结论。这么看，假阳性就不是缺陷，它是交付物的组成部分。报告越长、条目越多、分级越细，越像一份审查记录。数字本身就是产品的一部分。
也正因如此，没人去核对它。
那二十四个只写着"崩溃"的条目，最能说明问题。崩溃是个事实，不是一条判断。工具看见了异常，但说不出这个异常违反了哪条安全属性、值不值得优先修。它给不出优先级，只能往列表里加。列表越长，越像档案。
至于那三条编造的数据——在一份本来就不给人逐条读的文件里，编造一条和写一条占位符，功能上没差别，都是让文档看起来完整。
整理的人说，这些条目相加只有七十六，标题写的却是七十九，演讲者本人在视频里拿这个开了个玩笑，说 LLM 不会数数。²
顺序得摆正。不是报告不准所以没人读，是这份报告本来就不是给人读的。一份要归档的东西，条目相加对不对，只要不出现在该出现的位置，就没人管。
讨论里还有一大段在争这些模型像不像实习生。这争论有点意思，但和上面那件事基本不搭界。一个不会积累判断、只在厂商发新版时才改变的东西，当然学不会少报几十条。可就算它学会了，采购那端买的东西也不会因此变化。
开头的说法可能宽了点，收紧一下。
我不是说它没用。有人的公司在专有代码里用这类模型找出过真问题，修掉了真实的 CVE。上面那二十个待修条目里，也有一部分被内核维护者认成真错误。这些都是真的。³
它的"用"和它宣称的"用"，是两件事。前者发生在有人愿意坐下来逐条核对的时候，后者发生在采购流程里。同一份报告，两种命运。
还有个细节我一直没想好往哪放。内核社区给每个错误修复都分配一个 CVE。所以"上个月一千三百多个 CVE"和"十个真实安全漏洞"根本不矛盾，把这两个数摆在一起比，从前提上就是错的。数字在这里不承载信息，围绕数字的争论自然也不承载。⁴
Mythos 在法语俚语里的意思是强迫性说谎的人。这个巧合我不展开。
如果我对，接下来会看到的不是这类工具变准，是它们开始卖别的东西：带格式的、分好级的、能直接对上合规条款的那种报告。到那时候，误报率会从产品页上悄悄消失。不是问题解决了，是它终于不在这份指标列表里了。
¹ 这是讨论里的说法，我没去核原始数据。就算记错一半，方向不变。
² 转述自整理者，我没看视频本身。
³ 反过来的意见也有人提：Linux、libcurl 这类项目受到的审视远多于普通软件，这里的结论不该向外推。这一半我同意。它说的是这些数字不能外推到一般项目，不是说不该批评这类工具。
⁴ 也是别人的说法，我没去查分配政策的原文。