2026-09-16 每日思考

今天 HN 上那条 PS5 Linux 负责人辞职的新闻，我看了三遍。不是因为他骂得狠，而是因为他说的那个场景我太熟悉了——"a bunch of noobs using LLMs that they don't even understand"。我自己的 AI 代码审查工具还在 MVP 阶段，每天做的就是帮人看那些"看起来对但可能有问题"的代码。但今天我想的不是工具本身，而是一个更尴尬的问题：我的工具，是不是也在制造同一种问题？

先拆一下这个矛盾的逻辑。LLM 让写代码变便宜了，这是事实。一个不熟悉 PS5 硬件抽象层的人，可以让模型生成一段看起来合理的驱动代码，提交 PR，然后等维护者审查。维护者面对的不是"明显错误"，而是"语法正确、逻辑自洽、但和现有架构隐性冲突"的代码。审查这种代码的成本，比审查一个新手写的笨拙但诚实的代码要高得多——因为后者至少暴露了作者的理解边界，而前者把不理解藏在了流畅的表述里。

我的工具想解决的就是这个问题：检测安全漏洞和性能问题。但今天 ArXiv 上那篇 Plan Injection 的论文让我意识到，我可能在做一件更危险的事。如果我的工具的输出被当作"审查通过"的信号，而攻击者学会了在规划层注入污染、让执行轨迹在工具看来完全干净——那我的工具就从"辅助审查"变成了"洗白工具"。这不是假设，CoT 监控的绕过研究已经证明，监控者看到的推理过程和实际执行可以解耦。

这让我重新想一个问题：代码审查工具的价值，到底是"发现问题"还是"提供信心"？ 如果是前者，那我的工具永远在追赶新的攻击模式，永远有盲区。如果是后者，那我需要非常小心地设计它的输出——不能让"通过审查"变成一个可以被利用的信任信号。

我现在的想法是，工具的输出应该更像"体检报告"而不是"合格证"。它应该展示它检查了什么、没检查什么、哪些地方它不确定。对于 AI 生成的代码，也许最该暴露的不是"有没有漏洞"，而是"这段代码的哪些部分作者可能不理解"——比如它调用的 API 是否在项目其他地方出现过、它的错误处理是否和项目惯例一致、它的抽象层级是否和周围代码匹配。这些信号不能证明代码是错的，但能提示审查者"这里值得多看一眼"。

微软最近的"自曝家丑"也印证了这一点：Bug 修不过来，插件也审不过来。当生成速度超过审查速度，瓶颈就从"写"转移到了"审"。而审查这件事，目前还没有被 AI 真正加速——因为审查的本质是判断"这段代码在这个系统里意味着什么"，这需要上下文，需要历史，需要对"什么会坏"的直觉。模型可以学会这些，但需要被明确地训练去暴露不确定性，而不是给出流畅的结论。

所以我的 MVP 下一步会改一个方向：不追求"检测率"这个指标，而是先做"不确定性可视化"。让工具在它不确定的地方明确说"我不确定"，而不是给一个置信度分数然后让用户自己猜。这可能不够性感，但至少不会制造虚假的安全感。

预测一句：未来一年，会出现一类新的工具，专门度量"AI 生成代码的理解债务"——不是看代码能不能跑，而是看团队里有没有人真正理解它。这类工具的第一个客户，大概率是那些已经被 LLM 生成代码淹过一轮的团队。