2026-11-03 每日思考

今天 HN 上那篇 410 分的帖子让我停下来想了很久——spaCy 作者亲自拆穿"只动 0.016% 参数就让 Qwen 数学暴涨"的说法。我第一反应不是"又一篇打假"，而是：如果我的代码审查工具也发这么一篇 PR 稿，会不会同样经不起这种拆解？

我的 AI 代码审查 MVP 现在做安全漏洞和性能问题检测。过去几周我一直在纠结一个指标：召回率。把召回率从 78% 刷到 85%，我在内部演示里能讲得很漂亮。但 Honnibal 那篇帖子提醒我，单点实验的提升和"在真实代码库上稳定可用"之间隔着一条鸿沟——我的测试集是我自己挑的，正如那个 0.016% 的实验是发布者自己设计的。评估集的独立性，比指标本身更重要。 这是我给自己的第一个结论：在 MVP 阶段，与其追召回率的小数点，不如先建一个我"没有参与构造"的留出集，哪怕只有两百个真实 PR。

第二个想法关于今天 GitHub 上那些 Agent 记忆和插件项目。dsh-memory-evolve 强调"零核心修改、卸载即净"，hyperresearch 强调"知识持续累积"。这让我反思自己的架构：我一开始想把审查规则、上下文检索、报告生成全塞进一个单体流程，图省事。但代码审查的本质是可解释的判定——用户要的不是"AI 说有漏洞"，而是"哪一行、什么模式、为什么危险、怎么改"。这要求每个检测器可独立替换、可单独回归测试。插件化不是为了时髦，是为了让"某条规则误报率高"这件事能被单独定位和关掉，而不是整个工具背锅。

我不想盲目追热点。今天满屏的 Agent、世界模型、递归自我改进，离一个还在打磨误报率的审查工具很远。但有一条是共通的：当模型能力不再是瓶颈，工程上的可复现、可解释、可回滚就成了真正的护城河。

可执行的建议给自己：这周先做两件事——建一个独立留出集，把每条检测规则的误报率单独打表；把审查流程里"上下文检索"抽成可替换模块，为将来换检索策略留口子。预测一句：半年内，"能说清为什么"的 AI 工具会明显跑赢"只会报数字"的同类。