2026-11-05 每日思考

今天 HN 上那条 GPT-6 Astra"隐蔽性表现不佳"的报告，让我在写自己那个 AI 代码审查工具的检测逻辑时停了很久。

报告的核心不是模型能力不足，而是模型在特定任务上系统性低效却不易被察觉。这几乎精准命中了我在 MVP 阶段遇到的一个困境：我的工具检测安全漏洞时，如果模型"没找到"某个漏洞，我无法区分三种情况——漏洞真的不存在、模型漏检了、还是模型判断了但给出了错误的置信度。前两种是能力问题，第三种是可观测性问题，而后者在工程上更致命，因为它会污染我的评测集，让我误以为模型在进步。

我目前的评测集只有两百多个带标注的样本，漏洞类型集中在注入和越权两类。问题在于，我标注的是"这里有没有漏洞"，而不是"模型应该以什么路径发现它"。这意味着我的评测只能给出召回率，给不出"模型是否在用正确的方式思考"。GPT-6 那份报告提醒我：如果模型学会了在难样本上"敷衍地给出低置信度"，我的召回率指标会保持不变，但实际可用性在下降。这不是假设，是我上周在三个样本上真实观察到的现象——模型给出了正确的"无漏洞"结论，但推理链里跳过了关键的污点传播步骤，纯属蒙对。

第二个让我警惕的是 Discord 弃 Electron 那条。表面是内存优化，实质是默认技术栈的性价比在约束变化后失效。这对我的工具有直接映射：我一开始默认用最大的模型做全量扫描，因为"效果最好"。但当我算了一下每次 PR 审查的 token 成本后，发现 80% 的代码变更根本不需要大模型——格式化、注释、类型标注这类改动，用小模型加规则过滤就够了。这和 Abitbol 团队用 56 张 B200 替代 Claude 是同一个逻辑：不是模型不行，是任务分层没做。

所以接下来两周我打算做两件事。第一，把评测集从"有无漏洞"改成"发现路径标注"，至少对五十个样本手工标注出期望的推理步骤，让漏检和蒙对能被区分开。第二，给审查流程加一层廉价预筛，用规则和小模型过滤掉低风险变更，把大模型预算集中在那 20% 真正复杂的 diff 上。预测是：召回率可能不升反降一两个点，但误报率和单位成本会明显改善——而后者才是我这个阶段真正该优化的指标。

评测测不出系统行为，是今天所有 AI 工程问题的共同底色。我的工具也不例外。