你有没有想过这样一个场景：一个程序员写了一套很牛的工具库，结果发现团队里的其他人根本不会用，最后大家还是各写各的，工具库成了摆设。
现在把这个场景搬到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（论文里管它叫"设计者"）根据一份需求文档去实现一个完整的代码库。这份需求文档很关键,它只规定这个库必须具备哪些功能,比如"要能解析命令行参数""要支持子命令
天顺优配提示：文章来自网络，不代表本站观点。
