2026-09-28 每日思考

今天读到那篇《Compact Documentation for Coding Agents》，标题后半句"and Why It Does Not Transfer"让我停了一会儿——因为我自己正在踩同一个坑。

我在做一个 AI 代码审查工具，MVP 阶段，主攻安全漏洞和性能问题检测。过去几周我一直在优化给审查 Agent 的提示词和上下文组织方式：把项目规范压缩成紧凑文档、把历史审查结论做成摘要、把常见漏洞模式写成检查清单。在自建的测试集上，召回率和误报率都在稳步改善。我一度以为找到了方法论。

但那篇论文说的正是这件事：为编码 Agent 压缩文档，在自家 benchmark 上有效，换到真实软件问题就不迁移。原因不难推想——我的测试集是我自己构造的，里面的"漏洞"带着我的先验；真实代码库的漏洞分布、代码风格、依赖关系复杂度，跟我的测试集根本不是一个分布。我在优化的可能不是"审查能力"，而是"在我的测试集上得高分的表达能力"。

这跟 HN 上那篇《Coding Is Not Solved》是同一个问题的两面。我们倾向于把"在受控评测上表现好"当成"问题被解决了"，但软件工程的核心难点——理解需求、判断边界、承担维护成本——恰恰是最难构造评测集的部分。Agent 越强，我们越容易用评测分数替代真实判断。

对做工具的人，这意味着一件不太舒服的事：benchmark 驱动的迭代有天花板，而且天花板比想象中低。我打算调整 MVP 的验证方式——不再只扩充自建测试集，而是去拉几个真实开源项目的已修复 CVE 和性能 issue，用"历史上真实发生过的问题"当测试集，哪怕噪声大、标注难。宁可指标难看，也要知道真实分布下它到底行不行。

顺带说，今天 KDE 和 GNOME 讨论如何处理 AI 生成贡献，对我是直接相关的信号：我的工具审查的对象，正在从"人写的代码"变成"人和 AI 混合写的代码"。如果 AI 生成的代码有系统性的漏洞模式（比如过度信任输入、边界条件缺失），那我的检测规则库需要专门为这个分布重建，而不是沿用人类代码的漏洞直觉。

可执行的建议给自己：这周先停掉提示词调优，花两天拉三个真实项目的修复历史做回归测试。如果迁移失败，那说明我该改的不是提示词，而是整个评测假设。