速评：PolyCodeEval 这篇里最该记住的数字是 31.0%，不是 71.7%。
10 月 8 号挂上 arXiv，2590 个任务、58 个能真跑起来的开源仓库、五种语言，三个粒度上的最好成绩分别是函数级 71.7%、文件级 76.7%、仓库级 31.0%。
先停一下。文件级比函数级高。
一个文件里塞着好几个函数，生成整个文件按理说比生成单个函数难，分数反倒高出五个点。这不是小数点后面的噪声，是五个点。要么文件级那批样本本身偏简单，要么评分口径在文件这一层松了——整个文件跑得起来，里头某个函数写得糊弄也算过。两种可能指向同一件事：这三个数不能摆在一张表里比大小，它们测的不是同一个能力的三个难度档。
真正该拎出来说的是 31.0%。
从"这个函数写对了"到"这个仓库能构建、能跑测试"，中间隔着什么，写代码的人都清楚——依赖装不装得上、构建脚本认不认、三个月前那个人留下的隐式约定你猜不猜得到。三分之二以上的仓库级任务，目前最强的方法接不住。这才是 AI 编程现在的真实位置。函数级那七成听着体面，可没人是在函数粒度上交付项目的。
然后是我最想说的那点：排名会变。
论文自己写了，方法的相对排名随任务粒度和编程语言变化，跨语言性能差异也相当明显。翻成大白话就是——榜一是切出来的，不是测出来的。同一个模型，函数级坐头把交椅，切到仓库级换个名字，换个语言又换一个。谁想吹自己领先，就去挑自己领先的那块切片，再配一句"业界最强代码模型"，没人会翻到附录去看是哪个粒度。
这剧本，眼熟。上次泼过冷水的那回也是，发布 PPT 上有一格"代码能力行业第一"，右下角小字标着评测集名字，那名字我到现在没在任何一次独立复现里见过第二遍。
所以我对这类榜单的态度一直没变：发布当天的截图不算数，之后的复现才算。工具好不好用是另一回事，那是要装上连测三天的人干的活；我这儿看的是这份东西会不会在三个月内被当成一块砖，往哪面墙上搬。
话说回来，PolyCodeEval 本身做得不糙。
58 个可执行仓库是硬成本，统一走执行式评测、按每类任务的生成目标去改集成步骤，这套做法比拿 HumanEval 换个壳就发出来的东西体面多了。22 页正文、4 张图——图这么少，说明力气主要花在造数据和跑评测上，不是花在画架构图上。而且它敢把 31.0% 摆进正文，没只挑最好看的那个数报喜。这一点得给。
这算我留的让步：这次可能真不太一样，至少方向是对的。多粒度这件事早该有人做，单函数榜单被当选拔标准用了两年，已经选出过一批"榜上无敌、上手就崩"的模型。
还有一条藏在实验里的，比主榜有意思：把同一文件里相关函数的实现上下文喂进去，函数级正确率会往上走。
这说明什么？说明单函数成绩里有一部分不是模型自己会写，是上下文替它把话说了一半。在 IDE 里补全的时候这份上下文确实免费，同文件就在那儿；可拿这个分数去论证"模型掌握了代码能力"，等于把编辑器给的信息算成模型的功劳。这个混淆在业内被反复使用，用得很顺手。
再说语言。五种语言，性能差异明显，论文停在"需要多语言评测"这个结论上。我倒想追问一句：这五种是哪种意义上的五种——真覆盖了不同的写法传统，还是主流那两三种加几个陪跑的凑数？跨语言差异这么大，是语言的锅还是训练数据配比的锅，这份 benchmark 回答不了，它只能告诉你差距存在。
我不能确定，这条先记着。
这里立个 flag：接下来三个月内，会至少有一家在自己的发布材料里引用 71.7%，并且不会在同一页提 31.0%。半年之内，PolyCodeEval 会变成某张"全面领先"表格里的一行，切片大概率选在函数级。
猜错了我回来收。