AI写的代码库，AI自己会用吗？一篇论文戳破了一个尴尬真相

你有没有想过这样一个场景：一个程序员写了一套很牛的工具库，结果发现团队里的其他人根本不会用，最后大家还是各写各的，工具库成了摆设。

现在把这个场景搬到AI身上，问题就变得更有意思了。

现在的AI编程助手已经能独立写出一整个代码库了。你给它一份需求文档，它能给你一个能跑、能装、结构完整的软件包。听起来很厉害对吧？但这里藏着一个没人认真问过的问题：这个AI写出来的库，另一个AI能不能顺手就用上？还是说,后来的AI压根不知道怎么用它,只能自己重新写一遍功能?

这不是一个抽象的哲学问题。随着越来越多代码由AI生成，未来的AI很可能主要是在别的AI写的代码基础上继续工作,而不是在人写的代码上。如果AI写的库很难被其他AI用起来，那结果就是代码越堆越多，谁都在重复造轮子，整个软件生态会变得越来越臃肿难维护。

来自威斯康星大学麦迪逊分校、MIT、Snorkel AI和斯坦福的研究者们，就盯上了这个问题。他们做了一件挺聪明的事：不去看AI写的库本身写得漂不漂亮，而是把这个库丢给别的AI去实际使用，看它们用得怎么样。

这篇论文提出的评测体系叫LibraryDesignBench。

评测*：一句话解释,指用来衡量AI系统某项能力好坏的标准化测试方法,类似于给学生出的考卷。

这事到底难在哪

先说说为什么这个问题不好评。

如果只是看AI写的库能不能编译、能不能通过单元测试，那太简单了，现在的AI写代码基本都能过测试。但这只能证明库是"对的"，不能证明它是"好用的"。

如果找人类专家去审查这个库的设计，看看接口设不设计得合理，那测出来的是人类的审美偏好，不是AI真正需要什么。人觉得优雅的接口，AI可能压根用不上，因为AI搜索代码的方式和人类阅读代码的方式完全不同。

如果直接对照一份规定好的接口标准去打分，那等于是研究者事先把"正确设计"定死了，这就违背了评测的初衷,因为设计本来就该是开放的,不该被提前规定答案。

研究者们最后得出的结论是,唯一靠谱的办法就是真的把库交给AI用,看它用得怎么样。这就好比你想知道一把新设计的螯钗好不好用,最靠谱的办法不是找厨具专家来鉴赏它的造型,而是直接扔给一群厨师去炒菜,看他们用起来顺不顺手,炒出来的菜好不好吃。

LibraryDesignBench：两阶段的考试

这套评测体系分成两个阶段,设计得挺巧妙。

第一阶段叫设计阶段,让一个AI（论文里管它叫"设计者"）根据一份需求文档去实现一个完整的代码库。这份需求文档很关键,它只规定这个库必须具备哪些功能,比如"要能解析命令行参数""要支持子命令",但完全不告诉AI具体的接口应该长什么样,函数该怎么命名,参数该怎么排列。这种留白是故意的,就是要逼着AI自己去做设计决策。

设计者还会拿到两三个示例用法,这些示例其实来自后面要考的题目本身,类似给学生看几个样题让他知道考试大致方向,但真正的考题他还没见过。

第二阶段叫评测阶段,换上三个不同的、能力相对弱一些的AI（论文里叫"实现者"）,让它们分别用刚才那个库去解决一批实际编程问题。这些问题必须满足几个条件：得是现实中真会遇到的任务,得是这个库能帮上大忙的任务（不然测不出库的价值）,同时又必须是不用这个库也能解决的任务（不然就是在考"有没有这个库"而不是"库好不好用"）。

整个基准测试覆盖了十五个不同的代码库设计任务，横跨Python、TypeScript、Rust和Haskell四种编程语言,还有242道经过专家验证的下游编程题目。

打分的核心公式很直白,一个库的分数等于下游AI写出来的程序的正确性乘以简洁度。正确性好理解,就是测试通过率。简洁度稍微复杂一点,研究者用了循环复杂度、认知复杂度、Halstead体积和代码行数这四种代码度量方式,拿AI写的程序和专家用真实生产库写出来的参考答案对比,如果代码和参考答案差不多简洁,就打满分,如果代码比参考答案臃肿一倍,分数就打对半。

循环复杂度、认知复杂度*：都是衡量代码逻辑复杂程度的经典指标,前者数的是代码里有多少个判断分支,后者更接近人类阅读代码时感到"绕"的程度。

Halstead体积*：一种基于代码里出现了多少种不同符号和运算符来估算代码信息量的度量方法,年代很老,但依然管用。

这里有一个很关键的设计,研究者把测试通过率平方了再乘简洁度。这么做是为了让"正确性"的权重更重,一个只通过80%测试但代码写得跟参考答案一样精简的方案,分数反而比不上一个全部通过测试但代码写得臃肿1.5倍的方案。这个权重设计其实在暗示一件事,宁可代码啰嗦一点,也不能放过任何一个正确性上的瑕疵。

实验结果：AI设计的库到底行不行

答案是,行,但也不完全行。

研究者测了九个主流模型作为设计者,包括Opus 5.5、GPT系列、DeepSeek、GLM、Grok、Kimi等等。结果显示表现最好的Opus 5.5拿到了48.9分,比人类写的生产级库（46.6分）还高出2.3分,相对提升了4.9%。这说明AI确实能设计出比人类专家写的库更好用的东西,至少在这套评测标准下是这样。

但另一头也有翻车的。DeepSeek V4 Pro设计出来的库,分数反而比完全不给库、让AI从零手写还低9.2%。也就是说,这个库不但没帮上忙,反而添了乱。这种"帮倒忙"的情况在Haskell语言上最严重,大约七成的设计者-任务组合里,AI写的库表现不如压根没有库。

这里有个特别值得琢磨的现象。研究者发现,在十五个任务里,有十一个任务上,不同的AI设计者最后趋同,得出了几乎一样的设计方案，而且这个方案往往就是抄袭现有生产库的设计思路。比如在设计一个命令行解析工具时,两个不同的AI（论文里叫它们Astra和Fable）都不约而同地照搬了Rust生态里clap库的builder模式,而不是clap本身更简洁的derive宏写法。

这就好比让两个完全不认识的厨师去设计一款新式炒锅,结果两人做出来的锅长得几乎一模一样,还都长得像市面上已有的老款炒锅,而不是那种真正更适合现代厨房操作习惯的新造型。为什么会这样？大概是因为AI在训练数据里见过太多现成的、成熟的库设计,遇到开放性设计任务时,它下意识就去复刻记忆里那些"标准答案",而不是真正从下游使用者的角度去重新思考什么才是最省心的接口。

如果AI真能跳出这种模仿惯性,重新设计出更贴合AI使用习惯的接口,那这个库的分数应该能明显超过人类写的版本。但现实是大部分AI没能做到这一点,只有少数像Opus 5.5和GPT-6 Astra真正在部分任务上实现了对人类专家的反超。

为什么AI写的库不好用：问题不在于功能缺失

这是整篇论文里我觉得最有意思的一部分。

研究者对810个"部分通过但代码比参考答案臃肿"的失败案例做了细致的归因分析,想搞清楚:这些多写出来的代码,到底是因为库缺了什么功能,还是因为库本身有毛病?

结果出乎意料。研究者把失败原因分成几大类：覆盖不足（库压根没有这个功能）、正确性问题（功能有但有bug）、僵化（功能有个大概样子,但没法灵活适配任务需求）、啰嗦（用起来能实现,但写起来还是要绕一大圈）、以及可发现性问题（功能其实有,但下游AI没找到或没理解怎么用）。

统计下来,64%的多余代码问题出在僵化和啰嗦这两类,而覆盖不足只占14%。换句话说,大部分时候库其实什么都有,只是设计得太死板,或者用起来太麻烦,导致AI宁可自己重新写一遍也不愿意折腾着去适配现成的接口。

一个具体的例子很有说服力。在clirs（命令行解析库）这个任务里,33个AI写出来的库中,有24个都没有轻松实现"长选项前缀推断"这个功能,而这本来是一个功能齐全的命令行库应该具备的东西。缺了这个能力的库,在需要用到它的任务上,得分平均低了16.7分。

这就好比你买了一台号称"全功能"的洗衣机,结果发现它确实能洗衣服,但洗完之后想设置个"轻柔模式"却要翻五层菜单才能找到,而隔壁那台老式洗衣机虽然功能少,但每个按钮都清清楚楚摆在最外面。你最后大概率会选那台功能少但顺手的,而不是那台功能齐全但操作反人类的。如果不去正视这种"僵化"问题,单纯堆功能,库依然会被下游用户嫌弃。

研究者还做了一个更细致的人工分析,发现在180份实现方案里,implementer重写的13562行代码中,有41%其实是在重复实现库本来已经提供、但因为被藏得太深或者本身有bug而没被用上的功能。

AI自己会不会好好用现成的库

这个问题延伸出了另一个子研究,论文里叫LibraryUseBench,专门测试AI在拿到一个成熟的生产库时,到底会不会好好用。

结果显示,即便是给AI人类写的、经过千锤百炼的生产级库,implementer的简洁度得分也只有61.5,远没有达到参考答案那种完美复刻的水平。这说明分数上的差距,一部分确实来自库的设计,但另一部分来自implementer自己没有充分挖掘库的潜力。

研究者进一步分析了GPT-5.6 Luna这个模型在不同"推理强度"和不同"提示语详细程度"下的表现变化,发现两个变量的作用完全不一样。

把推理强度从低调到高,通过率从51.4%飙升到84.5%,模型会去读15个库文件而不是2个,说明推理强度主要在帮模型"读懂"库。而把提示语从最简略版本换成详细指导版本,简洁度从48.7分提升到60.4分,说明详细的提示语主要在帮模型"用好"库。

研究者还扒了模型搜索代码库的行为日志,发现一个挺扎心的规律。在最简略的提示下,24%的实验里模型压根没打开过库的源码,直接靠记忆里的印象去写调用代码。当模型确实去搜索库的时候,64%到87%的搜索关键词是它凭记忆猜的具体函数名,只有16%到20%的搜索词真正和当前任务的描述相关。

这就好比你去一个陌生城市找路,压根不看地图,只凭"我记得这附近好像有条河"这种模糊印象往前走。低推理强度的AI,某种程度上就是在凭着对某个库过去训练数据里的模糊印象在"蒙"接口该怎么用,而不是真的沉下心去读文档、去搜索这个具体版本这个具体库里到底提供了什么。如果不给足够的推理预算,AI很可能因为一次不完整的搜索就断定某个功能"库里没有",实际上功能就摆在那里,只是搜索时被截断的输出漏看了。论文里就举了一个真实的例子，一个模型用grep搜索tantivy库里的"Stemmer"（词干提取器），结果搜索结果被管道命令截断在第100行，模型因此断定这个库不支持词干提取，结果这道题直接得了0分,而其他所有用中高推理强度跑同一道题的模型都顺利找到了默认的词干提取器,拿到了79到96分的高分。

教AI怎么给AI写库,有没有用

看到AI总是在照搬人类习惯的设计,研究者又做了一个挺有意思的干预实验。

他们让GPT-6 Astra在设计库之前,先按照一套更"以AI为中心"的指导原则去思考。这套指导要求它先假想十几个下游任务,把每个任务最理想的调用方式写成三到八行的极简伪代码，再倒过来根据这些伪代码反推出真正的API设计，接着让子智能体（也就是另一个独立的AI实例）拿着这份设计去实际写程序，看看效果如何，根据反馈不断打磨接口，最后把这些示例固化成正式的使用文档。

这套流程有个挺形象的名字叫"neuralese"，字面意思接近"神经语言"，指的是两个AI之间如果只用来互相交流，会自然收敛出的那种高度压缩、不追求人类可读性、只追求信息传递效率的表达方式。

结果显示，这种更明确的指导确实有效果，指导后设计出的库和生产库共享的导出函数名比例从19.4%降到了13.4%，说明AI确实开始摆脱照搬人类库设计的惯性，真正按照AI使用者的需求重新思考接口。分数也从44.1提升到46.4，逼近生产库的46.6分，提升主要来自简洁度上涨了6.8%。

举个具体的例子，标准提示下写出来的命令行参数声明是一连串链式调用，先new再short再long再action，一步步拼出一个flag。而在明确指导下，这一整套操作被压缩成了一个函数调用，直接一句Arg::flag加上短选项名就完事了。

这就好比你本来要拼一台组装家具，说明书要你一个一个拧螺丝、一个一个装板子，装十分钟才能拼好一个柜子。而经过重新设计的说明书，直接告诉你"把这两个模块卡在一起就行"，一步到位。少了那些中间步骤，不是因为功能少了，而是因为设计者提前把常见的组合方式打包好了，你不需要每次都从零件级别开始拼装。

不过这个改进不是免费的。设计成本几乎翻倍,从4.51美元涨到8.24美元,因为要多跑一轮子智能体的验证测试。而且改进后的库依然没能完全超过生产库,说明距离真正为AI优化的设计,还有一段路要走。

写在后面

读完这篇论文，最让我意外的其实不是AI设计库会失败，而是失败的原因这么集中。

大部分人第一反应可能是"AI肯定是漏了什么功能没实现"，但数据摆在那里，64%的问题根本不是功能缺失，而是接口太死板或者太麻烦。这意味着单纯堆功能清单、让AI"应有尽有"地实现规格文档里的每一项要求，可能根本解决不了核心问题。真正卡住下游AI的，往往是那种半成品状态：功能确实在那儿，但调用方式别扭到宁可自己重写。

另一个让我反复琢磨的细节是，那些不同厂商、不同模型家族的AI设计者，在没有任何交流的情况下，最后收敛出了几乎一样的库设计，而且这个设计还带着明显的模仿痕迹。这某种程度上说明，当前的大模型在面对开放式设计任务时，创造力的天花板可能比想象中低，它们更擅长的是在已有模式里做选择和缝合，而不是真正从零构建一个专门服务于机器阅读习惯的新范式。

还有一个细节我觉得值得单独说一说，就是那个被截断输出坑掉的模型。它不是因为能力不够，也不是因为库真的没那个功能，就是因为一次不完整的grep搜索，就下了"库里没有"的结论，然后自己动手重写了一遍。这种因为工具使用习惯上的小疏漏而导致的连锁误判，某种程度上比"模型能力不够"更让人担心，因为这类问题不会随着模型变聪明而自动消失，它需要专门的工程手段去修补。

论文里还留了一个没深挖的问题，就是这套"neuralese"式的设计指导，如果拿去让AI写更复杂的系统级软件会怎样。目前测试的都是相对独立的功能库，如果换成需要跨模块协作、状态管理更复杂的场景，AI设计者还能不能延续这种"先写用例再反推接口"的思路？这个问题目前还没答案。

Q&A

Q1：LibraryDesignBench是什么？

A：LibraryDesignBench是威斯康星大学麦迪逊分校等机构研究者提出的一套评测体系，用来测试AI设计的代码库能不能被其他AI真正用好，包含十五个跨四种编程语言的库设计任务和242道验证过的下游编程题目。

Q2：AI设计的代码库为什么难用，是功能不够吗？

A：不是。研究者的失败分析显示，只有14%的问题是功能缺失，64%的问题出在接口设计僵化或者用起来太啰嗦，也就是功能其实都有，但AI没法灵活调用，宁可自己重写。

Q3：给AI更详细的设计指导有用吗？

A：有用。研究者让GPT-6 Astra按照更贴合AI使用习惯的方式先写用例再反推接口设计，分数从44.1提升到46.4，简洁度提升了6.8%，但设计成本也几乎翻倍，且仍未完全超过人类写的生产库。