一位开发者因模型把 critical 误判为 low，决定搭建一套可复现的准确率测试。他基于 30 条人工核对过的通告记录，让模型提取包名、严重级别和处置动作，并分别统计误报与漏报。测试脚本很短，读取 JSONL 文件，调用仅返回 JSON 的接口，再与期望值比对。
一次本地运行示例显示：critical 召回率 0.90，moderate 召回率 0.62。模型能抓住多数高危通告，但常把 moderate 降级为 low。作者指出，漏报比误报更危险——跳过关键升级的代价远高于一次多余审查。
测试暴露三类反复出现的失败模式：厂商用词不一致（"important" 被映射为 moderate）、包名冲突（libxml2 被识别为 libxml）、长通告截断导致修复版本信息丢失。
作者明确不建议让该输出自动开合并请求，只用于人工复核前的分诊。需要审计级报告、升级工具无人复核或涉及合规系统时，不应采用此方案。建议从十条记录起步，人工标注期望值，先观察错误模式是否稳定再扩大规模。
这套方法的价值在于可复现：用固定测试集而非实时通告，避免厂商页面和模型行为变化影响结果。先度量，再信任。
#开发者 #工具 #安全通告 #AI评测 #Python #DevOps #依赖管理
@DevToolboxHub