用 AI 做漏洞扫描器如果一开始就追求高召回率，大概率会走弯路

很多做安全工具的人习惯于追求指标好看，但我最近折腾的一个 AI 漏洞扫描器，在跑 OWASP Benchmark（Java 安全扫描的标准考卷）时，给出的结果简直惨不忍睹：召回率（Recall）只有 0.07。简单来说，面对 777 个真实的漏洞，它只抓到了 7%，漏掉了 93%。

但奇怪的是，我当时觉得这个结果是对的。

先看具体的实测数据：

$ python scripts/score_benchmark.py --findings out/java.findings.json \
 --truth benchmark-java/expectedresults-1.2.csv

OVERALL precision 0.60 recall 0.07 F1 0.13

这里的逻辑是这样的：我的设计方案是用确定性的静态分析规则去搜寻，然后交给 LLM 来判定这个发现到底是真 Bug 还是误报。在这次测试中，精准率（Precision）有 0.60，这意味着虽然它找得少，但只要它报警，大概率是真的。

为什么说 0.07 的召回率反而是个好信号？

因为这只是一个用来验证链路的 Spike 版本。我故意只写了一个 getParameter 的 source 模式，去对接几个 sink。我的目的不是为了刷分，而是为了确认这套“静态分析 + LLM 判定”的流水线能不能跑通。

如果这次结果是精准率 0.10、召回率 0.80，那我就得担心底层引擎是不是在瞎猜，可能得推翻重构。而现在的结果清晰地告诉我：引擎没问题，只是我的“词汇量”太小了。这就好比我在一栋有几十扇门的房子里只守了一扇门，漏掉其他房间的贼是很正常的。

这种从零开始部署 AI 工具的实操经验告诉我，先验证链路的正确性，比盲目追求一个完美的 F1 分数要重要得多。只要精准率在，增加 source 列表就能快速提升召回率，这比修补一个逻辑混乱的引擎要简单得多。