你有没有遇到过这种情况：改一个功能，本来以为在一个文件里搞定就行，结果改完发现另一个地方也得跟着变，不然整个系统就崩了。
现在把这个场景放大一百倍，放到真实的软件世界里。
Sentry 这家做错误监控的公司，给自己的 Go、Python、Ruby 语言客户端加一个新功能，得同时改三个仓库的代码，一个都不能漏。PHP 客户端要是加了新能力，还得连带更新另外两个依赖它的仓库。这不是特例，研究团队扒了 103 个开源生态里的 172 万多条 PR（拉取请求，可以理解成程序员提交代码修改的申请单），发现有 10.9 万条明确提到了同生态里的另一个仓库。
也就是说，跨仓库协同修改是软件工程里的家常便饭。
那问题来了：现在这些能自动写代码、跑测试、修 bug 的 AI 编程助手，能不能搞定这种"改一个地方，另外几个地方也得跟着动"的活儿？
一群来自浙江大学和清华大学的研究者决定认真测一测这件事，做了一个叫 WideSWE 的评测基准，结果相当打脸。
当AI助手只盯着一个仓库看
在这篇论文之前，业内最有名的编程助手测试叫 SWE-bench
SWE-bench：一个让AI去解决GitHub上真实issue（问题反馈）的评测基准，核心逻辑是在单个代码仓库里改代码、跑测试，看能不能解决问题。
SWE-bench 这几年催生了 SWE-agent、AutoCodeRover、OpenHands 等一大批编程智能体，后续还有 DeepSWE 做更长周期的工程任务，ProgramBench 要求从可执行文件反推整个程序。这些评测把任务做得越来越难、越来越长，但有个共同的盲点：它们都默认改动只发生在一个仓库里。
这就好比考驾照只考倒车入库，却从来不考在复杂路口怎么和其他车协调。现实中的软件开发，尤其是大公司维护的生态系统，经常是"一个需求，散落在好几个仓库里"。
研究团队把这个空白点单独拎出来，做了 WideSWE。他们从 GitHub 上按仓库星标数排名前 200 的组织里，筛出 103 个活跃的软件生态，比如 Kubernetes、Django、Rails、Sentry 这些耳熟能详的项目。然后从这些生态里挖出真实发生过的跨仓库改动，经过人工审核和可执行验证，最终留下 120 个任务，一半是修 bug，一半是加新功能。
每个任务至少涉及两个仓库，而且这两个仓库都必须真的需要实质性代码改动才算数，光是提了一句"参考另一个项目"不算。
先说结论有多打脸。
论文里测试了七种"AI编程助手+大模型"的组合，表现最好的是 Codex CLI 配 GPT-5.6-sol 这个组合，完整解决率也只有 42.5%。这意味着，就算是表现最好的组合，十次跨仓库任务里也有近六次是没能完全做对的。而表现最差的组合，成功率只有 10.83%。
更值得琢磨的是另一个数字：这个最强组合虽然只有 42.5% 的任务全对，但它在 83.33% 的任务里，至少能把其中一个仓库改对。
这说明什么？
说明AI助手大概率能搞定单点问题，但一旦涉及多点协同，就掉链子了。就像一个厨师能同时做好红烧肉，也能单独炒好青菜，但让他同时兼顾两口锅、火候还要配合上桌时间，就手忙脚乱了。
三种典型翻车现场
论文里详细拆解了失败的具体原因，归成了三类。
第一类叫范围识别不全
范围识别不全：AI助手没有意识到某个仓库也需要改动，或者去检查了那个仓库，却错误判断"这里不用动"。
Sentry 的例子特别典型。任务要求在 Go、Python、Ruby 三个语言的 SDK（软件开发工具包）里实现同一个策略，Codex CLI 配 GPT-5.6-sol 这个组合直接说"目标是 Go SDK"，然后去读了 Python 的代码作为参考，最后却只改了 Go，Python 和 Ruby 两个仓库原封不动。测试结果显示 Go 拿了满分 14/14，Python 和 Ruby 都是 0 分。
它甚至知道要参考 Python 的实现，却没意识到 Python 本身也是被要求修改的目标之一。这就好比你去邻居家借调料，回来自己做菜，却忘了邻居家其实也点了同样一份外卖等着你送过去。
第二类是识别了但没交付
识别了但没交付：AI助手已经明确说出了需要改哪里、为什么要改，但最后没有真的把代码改完。
Godot 和它的底层 Native SDK 那个案例很说明问题。AI助手在分析过程中直接说出"故障出在 Godot 的调用端"，诊断完全正确，但它只去改了 Native SDK 那边的接口，Godot 端那个已经被自己点名的调用问题，压根没动。Native SDK 那边本地跑了 304 个单元测试全部通过，看起来一片大好，但正式评测时 Godot 仓库是 0/1，问题根本没解决。
这种情况有点像医生诊断出你左脚和右脚都有毛病，甚至准确说出了病因，最后却只给左脚打了石膏，右脚放着不管，然后告诉你"治疗完成了"。
第三类是改完了但没改对
改完了但没改对：两个目标仓库都被实质性修改了，但组合起来还是没能满足任务要求，或者破坏了原有的正常功能。
这一类在几乎所有配置里都是占比最高的失败类型，Codex CLI 配 GPT-5.6-sol 的组合里占了 59.42%。一个典型例子是 Kubernetes 那个任务，要求迁移一个代码生成工具并保证下游消费者的行为不变。AI助手确实两个仓库都改了，还专门检查了生成的 1362 个模型名称是否完全一致，检查结果显示名字集合完全匹配，局部测试也通过了。但正式评测一跑，Kubernetes 那边 824 个回归测试里，有 48 个没通过。
名字对得上，不代表这些名字背后对应的实际行为也对得上。这就好比你把公司所有员工的工牌重新设计了一遍，名字和照片都换成新版，检查工牌本身完全没问题，结果发现门禁系统压根识别不了新工牌上的芯片，员工进不了门。表面的一致性验证，遮住了更深层的逻辑漏洞。
独立跑还是一起跑，这是个问题
发现问题之后，研究团队做了个很直觉的实验：既然AI助手在同时处理多个仓库时容易顾此失彼，那能不能让它一次只专心搞一个仓库？
他们把同样一批任务拆开，用同一套提示词，一种是把整个生态的所有仓库都丢给AI助手一次性处理，叫联合执行；另一种是每个目标仓库单独开一次全新的任务，叫独立执行。为了保证公平对比，两种模式用完全相同的提示词，只在 89 个任务上做对比。
结果有点意思，不是简单的谁比谁好。
联合执行整体解决了 40.45% 的任务，独立执行是 35.96%，联合执行反而略胜一筹。但如果按任务类型拆开看，情况完全反过来了：修 bug 类任务里，独立执行从 34.48% 涨到 44.83%；但加新功能类任务里，独立执行从 43.33% 掉到了 31.67%。
这个反差背后的逻辑值得琢磨一下。
修 bug 这种任务，往往是定位一个具体错误、在一个地方精准修复，缩小范围反而有助于AI助手集中注意力,不被别的仓库的信息干扰。但加新功能通常需要多个仓库配合着实现同一套新行为，这时候把仓库拆开跑，AI助手就失去了参照系统。
论文里给了个特别生动的例子。Symfony 的一个任务，要求原生扩展和 PHP 兼容层实现完全一样的行为。联合执行时，AI助手主动把两边的实现拿来对比，发现原生扩展里有个校验逻辑，PHP 那边漏掉了，随手就补上了,两个仓库最后都通过测试。独立执行时，两次跑动各自为战，谁都没意识到对方那边多了一道校验，结果两边都留下了同样的错误。
这就像两个人分头去装修同一套房子的两间屋子，说好了风格要统一。如果两人能随时看到对方那间屋子装的样子，发现一个细节没对齐，立刻能纠正。但要是完全隔离开各干各的，谁都不知道另一间屋子长什么样，最后两间屋子肯定对不上。
还有个更直接的例子来自 Ansible。任务要求一个工具从另一个服务的数据库表里读取执行记录。联合执行时，AI助手先去读了那个服务真实的数据模型代码，看清楚了表名和字段名，再照着写查询语句，一次成功。独立执行时，AI助手只能靠猜测，四处搜索类似名字的文件，最后猜错了表名和字段名，查询逻辑压根跑不通。
独立执行不是没有用处，论文数据显示，在联合执行时完全没被改动过的仓库里，独立单独跑一次后有 60% 能被修复；但如果这个仓库在联合执行里已经被改过、只是改得不对，独立跑的成功率骤降到 9.43%。
这说明独立执行更擅长找回被彻底遗漏的活儿，而不擅长纠正已经做错的东西。而且独立执行的代价也不低，平均要调用 296.6 次 API（应用程序接口，可以理解成AI助手和外部系统交互一次的计数单位），是联合执行 94.7 次的三倍多，用了三倍的资源却没换来更好的整体效果。
换个大模型，表现天差地别
论文还测试了固定用 Claude Code 这个编程助手框架，只换后面驱动它的大模型会怎样，结果差异挺有意思。
Gemini 3.8 Flash 这个模型有个很鲜明的特点：它在失败案例里，52.34% 属于"识别了但没交付"，比其他所有模型都高得多。往细了看，这些案例里 82.14% 停留在调研、方案规划、准备性检查阶段，压根没动手实现。
论文举了个 Elastic 公司的例子，任务要求客户端做请求压缩、服务端做对应解压。Gemini 明确规划了两边都要改，然后做了 68 次文件读取、43 次搜索，一次代码修改都没提交。相比之下，Opus 模型直接写了压缩和解压的代码，还专门验证了压缩后和压缩前的请求处理结果是否一致，两边全部通过。
这个对比挺扎心的。
规划能力再强，如果不落地成实际代码，测试永远是零分。这就好比一个人把装修方案画得极其详尽，材料清单、施工步骤全写好了，但从头到尾没拿起一把锤子。
而 DeepSeek、Qwen、GLM 这几个模型呈现出另一种模式：它们"识别了但没交付"的比例都比较低，问题更多出在"改完了但没改对"，占比分别是 61.36%、73.33%、60.42%。也就是说这几个模型更愿意动手，但动手之后经常没考虑周全，留下逻辑漏洞。
固定用 GPT-5.6-sol 这个模型，换成不同的编程助手框架也有明显差异。Codex CLI 配它能拿到 42.5% 的成功率，换成 Claude Code 配它只有 32.5%，但 Claude Code 反而平均多调用了将近 50 次 API。调用次数更多，效果反而更差,这说明API调用频率和任务完成质量之间没有简单的正相关关系，框架本身的任务分解和检查逻辑同样关键。
仓库越多，越容易顾此失彼吗
论文还专门看了仓库数量对成功率的影响。多数配置在三仓库任务上的表现都比两仓库任务差，但深挖下去会发现，这个差距不完全是因为AI助手"漏看"了某个仓库。
以表现最好的 Codex CLI 配 GPT-5.6-sol 为例，它在三仓库任务里的单仓库成功率其实是 66.67%，比两仓库任务的 63.08% 还高一点，但整体任务成功率反而从 42.99% 掉到了 38.46%。
也就是说，仓库越多，AI越容易做到"每个都碰一下"，但越难做到"每个都做对"。在它失败的三仓库任务里，87.5% 是三个仓库都动手改了，62.5% 能解决其中两个，卡在最后一个上。
这个现象有点像杂技演员抛球。抛两个球时，每一次接抛都能兼顾住；抛到第三个球时，手忙脚乱之下，前两个球接得还算稳，但第三个球总是落地。不是完全不会玩，是同时协调的对象一多，精细的协调就跟不上了。
论文里有个具体案例，Sentry 一个涉及三仓库的任务，PHP SDK 和 Laravel 的改动都完成得挺好，但轮到 Symfony 时，AI助手加了一个只能接受整数的配置项，而任务明确要求要支持"空值"这个选项。前两个仓库做对了，第三个功亏一篑。
语言种类多，任务就更难吗
论文还统计了一个维度：一个任务涉及的编程语言种类。有的任务里几个仓库都用同一种语言，有的任务横跨好几种语言家族。
结果发现，语言种类的多寡对成功率的影响并不是简单的"越多越难"。
在修 bug 类任务里，几乎所有测试的组合在跨多语言的任务上表现都比单一语言任务好。但在加新功能类任务里，规律完全相反,大部分组合在单一语言任务上反而做得更好。
比如 Qwen 这个模型在单语言功能类任务上拿到 37.14% 的成功率，是所有 Claude Code 配置里最高的，但切换到多语言功能类任务，直接掉到 12%，反而落后于 GPT 和 Opus 的 28%。
论文的结论是，语言种类本身不能直接用来判断任务难度，任务类型和具体要改的内容才是更关键的变量。这提醒我们一个常见的直觉误区：不能简单假设"语言越复杂，AI表现越差"，真正决定难度的是需求本身有多绕。
测试题本身也得下功夫
这篇论文还有一个不太起眼但很实在的贡献，就是他们花了大力气去修正评测用的测试用例。
这个问题的起因是，很多原始 PR 里附带的测试代码，写得过于具体，只认某一种实现方式。比如某个测试要求异常信息里必须包含"generator must be"这几个字，但任务需求本身只要求抛出正确类型的异常，并没有规定具体的文字内容。
研究团队定了两条修订规则。第一条是放宽实现细节的限制，只要行为对了，不强求具体的命名、文件路径或错误信息措辞。第二条是删除任务需求里没提到的额外功能检查,比如 Nextcloud 一个日历提醒功能的任务，原始补丁里顺手加了三个额外的预设提醒选项，但用户提出的需求里根本没要求这些，团队就把这部分多余的检查从测试里去掉了。
这个工作看起来琐碎,但意义不小。如果测试题本身就带着"只认一种正确答案"的偏见,那AI就算想出了另一种同样合理的解法,也会被误判成失败。这就像批改作文时，如果标准答案只认一种表达方式，写出同样意思但措辞不同的学生就会被冤枉扣分。论文最终对 120 个任务里的 88 个做了这种修订，尽量保证评判的公正性。
Q&A
Q1：WideSWE评测基准主要用来测试什么？
A：WideSWE用来测试AI编程助手能不能处理跨多个代码仓库的协同任务，也就是一个功能或bug修复需要同时改动两个及以上仓库才能完成的情况，共包含120个来自真实开源项目的任务。
Q2：AI编程助手在跨仓库任务上的最高成功率是多少？
A：表现最好的组合是Codex CLI搭配GPT-5.6-sol模型,完整解决率为42.5%,其余六种组合的成功率在10.83%到37.5%之间。
Q3：让AI一个仓库一个仓库单独处理会不会效果更好？
A：不一定。独立执行在修bug类任务上确实提升明显,成功率从34.48%涨到44.83%,但在加新功能类任务上反而从43.33%降到31.67%,因为独立处理会丢失仓库之间可以互相参照的关键信息。
