2026-09-03 每日思考

今天刷 ArXiv 时，一篇关于智能合约漏洞自动注入的论文让我停下来想了很久。用 LLM 生成带漏洞的合约数据集来评估检测工具——这思路和我正在做的 AI 代码审查工具不谋而合，但同时也戳中了一个我一直回避的问题：合成漏洞数据真的够吗？

我做代码审查工具时遇到的最大瓶颈不是模型能力，而是缺乏高质量的"坏代码"样本。真实世界的漏洞往往藏在复杂的业务逻辑里，带着上下文、历史包袱和人为疏忽的痕迹。LLM 生成的漏洞则干净得像教科书——它们结构完整、边界清晰，甚至"漏洞得很标准"。用这种数据训练出来的检测器，到了真实代码库上会不会水土不服？

这让我想起今天 HN 上那篇关于 LLM 自指性的讨论。Scott Aaronson 提到模型难以真正理解"自己是一个模型"这件事。我觉得这和合成数据的问题有某种同构性：当训练数据本身是由模型生成的，模型学到的"漏洞"概念是否只是对自身输出的模仿，而非对真实缺陷的深刻理解？就像一个人只读过自己写的小说，很难真正理解文学批评。

当然，这不是说合成数据没用。在数据稀缺的领域，它至少提供了起点——就像智能合约那个研究做的，有总比没有强。但关键是要建立"合成-真实"的反馈闭环：合成数据训练出的检测器，需要在真实漏洞库上持续验证，然后反过来指导合成数据的生成策略。腾讯 WorkBuddy 今天讲的数据飞轮，本质也是这个道理——只是他们做的是用户反馈闭环，而我们需要的是漏洞语义闭环。

另一个让我警醒的信号是 Polars 2.0 预发布登顶 HN。作为一个 Rust 原生的 DataFrame 库，Polars 的崛起意味着 Python 数据生态正在经历基础设施层面的代际更替。这种替换不是功能层面的——Pandas 能做的 Polars 大多能做——而是性能与内存模型层面的降维打击。当基础设施开始换代，所有上层的工具链都要跟着迁移。我的代码审查工具目前是纯 Python 栈，如果未来要处理大规模代码库分析，是不是也该考虑 Rust 核心 + Python 绑定的架构？

今天的信息密度不算高，但"可靠性"这个词反复出现：模型后训练要金牌表现、Agent 需要判别式世界模型、RCA 要证据接地、漏洞数据要自动注入。大家都在从"演示酷炫"转向"生产可用"。我的 MVP 也该把评估体系搭得更扎实——没有可信的评估，所谓的检测能力都只是自我感动。

明天准备花半天时间，把手头几个真实项目的历史漏洞数据整理成基准集。合成数据可以继续用，但基准必须来自真实世界。