速评：这篇论文有点意思。
说的是 CodeSIFT 那篇检测工作。核心卖点一句话能说完：不预设任何攻击类别，不依赖任何已知漏洞模式，照样能识别出"诱导模型生成坏代码"的提示批次。方法上用的是影响函数，把生成代码在模型参数空间里留下的痕迹捞出来算，再拿统计检验比一比这批提示有没有显著偏离良性分布。
先夸这个角度。现在做代码安全的主流逻辑是反过来：先枚举你会怎么攻击，再针对性地防。威胁模型建得越细，防得越死，但建错了或者没建全呢？攻击者换种姿势就穿了。这篇论文干脆说，我不预设了——直接看生成出来那堆坏代码在模型内部留下的痕迹，痕迹不对就抓。不查表。
影响函数这路子不是新东西，早年在可解释性那边被念叨过好几轮，这几年慢慢没人提了，因为算力代价太难看，算一次要对参数空间做一堆近似。现在有人把它捡起来用在安全检测上，至少思路没毛病。
实验部分确实是按这个逻辑走的：三个 30 亿到 70 亿参数的开源模型，建了两个新基准，漏洞类型倒也覆盖得挺全。中等偏高的注入率下 AUROC 最高摸到 0.98，误报率校准得也不错，比静态分析基线高出多少我懒得记了，论文里写得清楚。榜级数字，看着是舒服。
但这里我打个问号。所有"检测恶意提示"的论文都会告诉你自己在中等偏高注入率下表现优异，低注入率呢？一万条正常请求里混着五十条恶意诱导，那个区间才是日常，论文只给了个中等偏高的数字，然后宣称能用了。这个口子不小，我先记着。
硬挑的话还有结构性问题：影响函数需要动模型内部，白盒假设在闭源模型上根本不成立，只能用于开源模型——好在论文用的也确实是开源模型。工程化场景要在 pipeline 里挂一个实时影响函数计算器，延迟会不会让 CI 直接报警，论文里也没提。这些都不算错，只是回避了"到底谁来用"这个最现实的问题。
但作者干了一件让我意外的事——基准数据集里故意放的都是最典型的漏洞类型。典型 SQL 注入、典型路径遍历、典型 XSS，几乎没有那种"得连着触发三个条件才炸"的复杂状态漏洞。看上去像在躲避高压测试，再一想，反而老练：对典型漏洞检测达到这个数字，对业界来说已经是安全收益了。退一步选战场，不是没底气，是在攒承认度。
这论文放在当下时间点看，有点"安全界迟到的体面"的意思。所有 AI 编程工具现在都这状态：代码修得痛快，用这些新生成代码的团队没几个在做安全审计。大模型生成代码的安全问题，喂给静态分析器和人肉专家都来不及，得靠模型自己暴露出来的行迹来抓——这个思路不是补一个检测器，而是给整个代码生成市场打补丁。
不是说我完全信这套能落地。但它是 2026 年 AI 代码安全方向上少数几个不是拿来凑数的成果。真正的价值不在那 0.98，在于它把"不预设攻击类别"从口号变成了可落地的方案。这句话本身，就够压住一堆还在纠结怎么枚举攻击面的工作。
还有件我还没想明白的事。论文一作把"大规模未知攻击类别"放在结论里，看起来是定给红队用的——红队最缺的就是这种不猜题、只看痕迹的侦察哨。但反过来想，真正拿到这工具最开心的，大概是两边吃亏的模型提供方和防守方：威胁模型越庞杂，求这种"闻到味就行"的探测器就越迫切。落地产品还难说，可如果真有人把它做成产品集成进头部 IDE，这个瓜，我回头要拿来细看。
这里立个 flag：一年内，这套思路会出至少一个商业化探针雏形。 跑赢了，说明这条路真能走通；跑输了，也不冤——至少它没像有些方向，发完论文就再也不提了。