2026-10-20 每日思考

今天看到一条 HN 帖子说"编造统计数字就能被 LLM 大量引用"，我盯着屏幕愣了几秒——因为我正在做的 AI 代码审查工具，本质上也在做类似的事：把模型判断当成证据呈现给开发者。

这条帖子值得所有做 AI 辅助工具的人认真读。它揭示的机制很朴素：LLM 在生成回答时倾向于引用"看起来像来源"的内容，而发布者只要制造出统计数字的形式感，就能进入这个引用循环。问题不在于模型"被骗"，而在于引用这个动作本身被当成了可信度的代理。一旦下游用户（或下游模型）把"被引用"等同于"被验证"，污染就会自我强化。

这直接戳中我 MVP 里的一个设计软肋。我的工具检测出安全漏洞或性能问题时，会给出一段解释，说明"为什么这是问题"。但这段解释是模型生成的，它可能引用不存在的 CVE 编号，可能编造一个听起来合理的性能基准。我之前的假设是"开发者会自己判断"，但现实是：在 CI 流水线里，审查结果是批量消费的，没人会逐条核对解释里的每个数字。如果我的工具输出被当作证据，那它就必须具备可验证性，而不只是可读性。

我想到两个可执行的方向。第一，把"解释"和"证据"分离：解释可以是模型生成的，但证据必须锚定到可验证的源——真实的 CVE 数据库查询、真实的 benchmark 复现、真实的 AST 节点位置。凡是无法锚定的断言，宁可标为"待人工确认"也不要以确定语气输出。第二，给每条发现附一个"置信来源"字段，区分"规则命中""模型推断""外部数据验证"三档，让批量消费方至少能按来源过滤。

推而广之，我认为接下来一年会出现一类新工具：AI 输出的溯源层。不是检测 AI 生成内容（那场军备竞赛已经够乱），而是给 AI 的每个事实性断言打上"可验证/不可验证"的标签。这比"AI 检测"更有建设性，因为它不试图判断真假，只暴露证据的薄弱处。

预测一句：到明年这个时候，"这条结论的证据在哪"会成为 AI 工具的基本交互，而不是加分项。现在动手补这一层，比事后被污染了再补救便宜得多。