编辑偏差：RepoProbe 给模型照出的那条底裤

先说结论：ASE 2026 那篇 RepoProbe，别当基准看，当照妖镜看。它最值钱的不是刷分指标，是造了一个词——「编辑偏差」。

这词儿准得让人后脊发凉。

模型没看懂代码就敢上手改。你让它改个接口签名，它顺着调用链生成一大片，看着整整齐齐，其实连那个接口为什么存在都没搞明白。改完还觉得自己特对。

这病谁没见过？

RepoProbe 给这病起了个名：「编辑偏差」。官方 benchmark 不敢拆穿的事，它拆穿了——现在各家刷仓库级代码理解，喂一堆 GitHub Issue，bug 复现、补丁生成，跑得飞起。但模型真懂架构了吗？还是对着 issue 标题里的异常栈，从模式库里拼一个长得像答案的东西出来？这活儿要的不是架构理解，是检索技巧。

所以 RepoProbe 换了个玩法。不用 Issue，改用 GitHub Discussions 里的开放式架构问题。没有错误日志当拐杖，没有现成 bug 上下文，就丢给你一句「这个模块想扩展某个能力，应该动哪里」。答得出来是真懂架构，答不出来就是答不出来。这一刀，直接把模型从「模式匹配舒适区」里拽了出来。

论文里那张对照图我盯了半天。模型回答的流畅度和它引用的证据之间，落差清晰得吓人。话越漂亮，支持那句话的代码证据越虚。这就是编辑偏差的量化定义——把「不懂装懂」从感觉变成了可测量的量。

流畅度：9/10
对应的证据支撑：3/10

这组数字放在一起，比论文里任何结论都扎眼。

当然，泼盆冷水。编辑偏差这个概念好归好，论文给的量化数据更多是证实了「偏差普遍存在」，还没到「拿这指标当尺子量所有模型」的分上。样本量、任务难度分布、模型版本覆盖率，这些细节我还想扒一扒。这条我还没完全看完，先别信我这半句。

RepoProbe 批的不是某个模型拉胯，是整条「用缺陷报告刷仓库理解」的路径依赖。Issue 驱动的东西本来就是 bug 修复导向，拿它当架构理解基准，南辕北辙。

锐评评分卡就仨字：不冤。

这话我平时说得少，这次是真心的。等它把样本量铺开、把验证规模做大了再捧不迟——但「编辑偏差」这四个字，往后评模型可以直接拿来用。对方要是一脸茫然，那就该测测他自己的理解偏差了。