LibEvoBench不是单一题型，而是三道关卡一起上。论文把它设计成一个多任务基准，分别测模型在真实代码场景、文档理解场景和纯记忆场景下，对版本化 API 的掌握程度。这样做的好处是：模型到底是“不会找”“不会认”还是“记错签名”，一眼就能拆开看。图1：三项评测任务总览，以及 API-C 的四档提示设计。API-C 看真实代码补全，API-I 看“描述找 API”，SR 看“背签名”。先说第一关API Calling（API-C），也就是 API 调用。给模型一段不完整代码，让它把缺失的 API 调出来。这个任务最像真实开发：代码上下文里有 import、别名、函数调用痕迹，模型得把“这句到底该补哪个调用”猜对。为了把“猜对”拆得更细，论文给 API-C 设计了四档提示。L0 只有原始代码，考最原始的上下文补全；L1 加上被遮住名字的文档说明，测试模型能不能把描述和 API 对上；L2 再补一个版本约束，看看模型会不会因为“知道版本”就突然开窍；L3 干脆给出 API 名字和版本，只让模型回忆参数签名，重点就落到细粒度参数上了。第二关是API Identification（API-I）。给模块路径和一段被删减的函数描述，让模型判断正确 API 名字。这个任务更像“看说明书认门牌号”，不需要完整代码推理，但要求模型知道描述对应哪个公开接口。第三关是Signature Recall（SR），签名召回。题目只给完整限定名和目标版本，别的啥都没有，模型必须把函数参数、默认值、顺序都背出来。这个任务最狠，因为它把“记忆里有个大概”这种含糊其辞直接按在地上摩擦。图2：API-C 的“降噪阶梯”。加文档，准确率明显涨；再加版本号，几乎没再变好；说明模型看懂了提示，但没真正学会版本切换。这三关的评分也各不相同。API-C 和 API-I 主要看完全匹配，SR 则更关注参数级别的准确性，用 F1 去衡量。别小看这个差异，它决定了模型是“名字认对了但参数乱了”，还是“连名字都认错了”。表1：数据集规模与覆盖情况。三套任务覆盖了 PyTorch、NumPy、SciPy 的多个版本，总体样本量和 API 覆盖都不小，足够把“版本感知”这件事测得比较扎实。
越新的API，大模型越容易“两眼一抹黑”?
论文最扎心的发现之一是：模型对稳定 API 和演化 API 的表现差得不是一星半点。稳定 API 指的是跨多个版本都没怎么变的接口；演化 API 则是那些新增、删除或改签名的接口。说白了，一个是“老熟人”，一个是“今天刚改名的同事”。结果很一致：模型在稳定 API 上通常还算稳，可一碰演化 API，准确率就开始往下滑，而且越接近新版本，滑得越明显。也就是说，模型不是单纯“不会这门库”，而是对时间轴上的知识分层不敏感。它知道有这个库，但不知道这个库在不同年份长什么样。图2：稳定 API 的曲线基本平，演化 API 的曲线随着版本推进持续下滑。这个趋势在多个模型家族、多个库、多个任务上都能看到。更有意思的是，论文还专门看了 Qwen3.5 不同规模的模型。结果显示，模型越大，整体水平确实更高，但那条“遇到新版本就掉头向下”的曲线几乎没变。这个现象很关键：它说明问题不只是“模型小所以不行”，而更像是训练语料把不同版本代码和文档混在一起后，模型学到的是一个混合时间切片，而不是版本分层知识。图7：从 GitHub 依赖文件统计得到的版本使用分布。现实里，很多项目确实会固定在某个版本上很久，这也解释了为什么“版本感知”不是可有可无的小题目。还有一个很实用的观察：在 API-C 中，只给代码上下文时，模型表现一般；加上文档描述后，准确率能稳定提升 10 到 20 个点。说明模型不是完全没救，它确实会利用提示里的信息。可一旦再加上“这个版本号是多少”，提升却几乎没有。这就很像让人做题时告诉他“这题来自六年级数学”，结果他还是把二次方程写出来了——知道背景，不等于知道答案。
时代错误幻觉：模型如何混淆不同版本的调用？
论文把这种现象叫做时代错误幻觉，英文是 anachronistic prediction，意思是模型给出的答案在别的版本里确实存在，但在当前版本下就是错的。这个词很传神：不是凭空捏造，而是“把别的年代的东西搬到了现在”。为了把错误拆干净，论文还引入了一个很聪明的分类框架。正确 就是答对；Unknown 指的是模型编了一个历史上从没出现过的符号，是真·幻觉；Invalid 则是模型没乱编，只是从这个库里拿了个“存在但不对”的 API；而Anachronistic 则是它拿了“历史上存在、当前版本不存在”的 API。这个分类的价值在于，它把“不会”与“记错年代”区分开了。图5：以 GPT-5.1 为例，展示不同版本下 API 级别和参数级别的错误构成。能看到，随着版本推进，错误类型的分布会发生变化。表4：API 名称级别与参数级别的完整幻觉分类。这个表是整篇论文的“错误字典”，把模型到底错在哪儿讲得很清楚。在 API 名称级别上，模型最常见的不是“凭空造一个不存在的东西”，而是拿错了一个真实存在的 API。这说明它并非完全脱离库知识，而是更像在库内部“串门串错了门”。真正的时代错误在 API 名称层面反而不算最多，因为很多模型会优先选择高频、常见、跨版本更稳的接口，表面上看起来像是稳了，实际上只是把版本差异藏起来了。表5：API 级别错误分布。Invalid 占了大头，说明很多时候模型不是“编造”，而是“认错了库里真实存在的东西”。到了参数级别，时代错误就更明显了。SR 任务里，模型必须完整说出签名，这时候它过去记住的老参数、新参数、默认值变化都无处可藏。论文发现，参数级别的时代错误占比相当可观，尤其在更高版本上更明显。换句话说，模型在“函数名”层面也许还能蒙混过关，但一旦问到参数，历史包袱就开始冒烟了。表6：参数级别错误分布。这里的时代错误比例更高，说明“签名记忆”比“API 名字记忆”更容易暴露版本混淆。这也解释了为什么 SR 比 API-C 更难。API-C 里模型还能靠上下文、局部模式和高频调用“猜个八九不离十”；但 SR 直接逼它把参数一项项说完整，等于把它的版本记忆摊开验货。于是，原本藏在生成过程里的小错误，到了这个任务里就全都露馅了。
SEUS评分：全面衡量模型的版本感知能力
如果只看单一任务分数，很容易把“某个模型在某个版本上发挥不错”误当成“它真的懂版本演化”。所以论文又设计了一个更综合的指标：SEUS，全称是 Software Evolution Understanding Score，中文可以理解为软件演化理解得分。它的思路很朴素：先看模型在稳定 API 和演化 API 上的平均表现，再惩罚它在不同版本之间的波动，最后再专门扣掉时代错误。这里有一个中间量 Bv，表示某一版本下稳定与演化表现的调和平均。调和平均的好处是：任何一边太差，最后分数都上不去，没法靠另一边“刷存在感”。公式1：Bv=2SvEv/(Sv+Ev)。其中 Sv 是稳定 API 的分数，Ev 是演化 API 的分数。这个设计等于说：只会做稳定题，不算真懂版本演化。公式2：SEUS 的总评分。它把各库、各任务上的 平均版本表现、版本间波动惩罚 和 时代错误惩罚 合在一起。λ 和 γ 都取 0.5，意思是稳定性和时代错误都要认真扣分。这个分数的妙处在于，它不会被“某个模型在旧版本上特别强”这种局部优势骗过去。SEUS 更看重的是：模型能不能在多个版本上都保持一致，能不能少犯“把别的年代的调用拿来用”的错误。对于代码模型来说，这比单纯追一个高分更接近真实开发需求。表2：按 SEUS 排名的模型榜单。GPT-5.4 位居前列，说明它在稳定性和演化能力之间取得了相对更好的平衡。表7：SEUS 详细榜单。这里能看出，单纯高分不够，版本一致性和时代错误控制才是拉开差距的关键。论文还给出一个挺耐人寻味的结论：给出文档能明显提升表现，但给出版本号几乎没用。这说明模型不是“缺少提示”，而是“缺少版本内化的知识”。如果只是告诉它目标版本，它并不会自动把脑子里的知识切换到那个版本；但如果把正确文档直接摆面前，它又能立刻用起来。也就是说，模型会抄作业，但不会自己选对作业本。表3：按稳定 API 和演化 API 划分后的任务结果。这个表直接把“稳定”和“演化”的差距摆出来了。
龙迷三问
下面是龙哥对于大家可能的一些问题的解答：
这篇论文到底解决什么问题？它专门研究大模型在代码生成时，是否真的理解“库版本会变”这件事。论文发现，模型对稳定 API 还行，但对演化 API 明显更差，而且越新的版本越容易出错。
SEUS 和时代错误幻觉是什么意思？SEUS 是 Software Evolution Understanding Score，中文可理解为软件演化理解得分，用来衡量模型对不同版本 API 的综合理解能力；时代错误幻觉则是模型把“别的版本里正确”的 API 拿到“当前版本”里来用，像把旧时代的工具搬进了新版本现场。
