这项由Meta公司研究团队主导的研究发表于2026年6月论文编号为arXiv:2606.29957有兴趣深入了解的读者可以通过该编号查询完整论文。研究的代码已在GitHub公开网址为github.com/Togetherbench/SWE-Together配套网站为togetherbench.com。**一切都要从一个真实的问题说起**你有没有用过那种AI编程助手你告诉它帮我写一个登录功能它洋洋洒洒给你写了一堆代码但你一看——方向完全不对或者漏掉了关键细节。于是你再说一遍它又改改完还是有问题你再纠正……这样来来回回折腾好几轮最后你甚至开始怀疑这助手到底是在帮你还是在耽误你这个日常体验正是这篇论文想要研究的核心问题我们现有的AI编程助手评测方式根本没有捕捉到这种反复纠正的代价。目前学术界评测AI编程能力的主流方式类似于给一位厨师出一道考试题——把食谱完整地给他看让他把菜做出来然后评分。但现实中真正的客人不是这样点菜的。客人可能说我想吃点清淡的厨师做了一道菜出来客人说这个太咸了厨师改改客人又说能不能换个摆盘……整个过程是一种动态的、来来回回的协作。Meta的研究团队发现现有的编程基准测试也就是给AI出的考试题都是静态的题目一次性给完AI交卷打分。但真实的编程工作恰恰相反——用户会一边看AI的输出一边不断补充要求、指出错误、调整方向。这种一次性考试的评测方式让我们对AI编程助手的实际使用体验知之甚少。正是为了填补这个空白Meta的团队推出了一个全新的评测框架叫做**SWE-Together**。---**一、从真实对话中打捞出来的考试题**SWE-Together最独特的地方在于它的题目不是人工编造的而是从真实的人机编程对话记录中挑选出来的。研究团队从四个公开数据集里收集了超过11,260段真实的用户与AI编程助手的对话记录这四个数据集分别来自DataClaw社区贡献的2,228段对话、Pi-staging流水线的2,397段对话、Hyperswitch生产代码库的784段对话以及SWE-chat项目的5,851段对话。这些对话都是真实用户在使用AI编程工具时留下的记录不是人工设计的充满了各种各样真实的人类需求和行为。但问题来了真实的对话虽然真实却不一定适合拿来直接当考题。就好像你想用某个真实烹饪节目的片段来考厨师但那段片段可能缺少关键步骤或者根本没有最终成品可以评判好坏。因此研究团队设计了一套严格的选题流水线分三个阶段把原始对话变成可用的考题。第一个阶段是纯规则筛选完全不依赖AI来判断。这一步要求每段对话至少有多条真实的用户消息不是单一指令必须包含AI实际修改代码的动作而且对话涉及的代码仓库必须是公开的、有一定知名度的GitHub项目。另外如果最终的代码改动主要是用户自己写的而不是AI完成的这段对话也会被过滤掉——因为研究的重点是评测AI编程能力不是用户自己的能力。经过这轮筛选大概有10%到21%的对话能留下来。第二个阶段是AI辅助的可行性判断。一个AI评审员会看每段对话的摘要判断其中的编程任务能不能在本地、封闭的环境中独立完成和验证。举例来说如果某段对话的核心工作是提交一个Pull Request或者部署到云服务器这种任务依赖外部状态在考场环境里无法重现就会被淘汰。但如果核心工作是修改代码逻辑、添加功能、修复Bug这种有具体代码改动、可以在本地测试的任务就会被保留。经过这轮大约5%到12%的对话还在。第三个阶段是在隔离的沙盒环境里实际生成考题。一个专门的AI在隔离环境中把代码仓库恢复到对话发生时的状态找到可以用来验证答案的测试命令写好评分所需的各种工具同时生成一个后续要用到的用户模拟提示词。整个过程完全在隔离环境里完成防止任何外部环境变量比如本机已安装的工具或已经改好的代码污染考题。经过这三轮筛选11,260段原始对话中最终只有109段变成了可用的考题转化率约为0.97%。这个比例看起来很低但恰恰说明研究团队对质量的要求有多严格。---**二、一个能看情况说话的虚拟用户**有了109道考题下一个问题就是怎么让不同的AI编程助手来参加这场考试同时保证考试条件对每个助手都公平这里有一个微妙的难题。真实的对话是用户和某个特定AI之间发生的。如果换一个AI来做同一道题它的行为可能完全不同——它可能走了一条不同的路径或者在不同的时间点犯了错误。如果把原始对话里用户说的话原封不动地播放给新AI就会出现错位——比如用户原本是在纠正AI走错的方向但新AI压根就没走那条路这个纠正消息就毫无意义甚至会干扰它。为了解决这个问题Meta的团队设计了一个活的虚拟用户而不是简单地播放录音。这个虚拟用户在每次AI完成一个操作后都会认真观察AI干了什么然后根据情况决定要不要说点什么说什么。它有五种可选动作沉默让AI继续干、提问向AI澄清某个细节、重定向AI跑偏了把它拉回来、提出新要求原始用户后来追加的需求以及让AI去查看某个外部信息。默认动作是沉默只有在当前情况确实需要介入的时候虚拟用户才会开口。这个虚拟用户的行为有两个关键原则。第一它的干预是根据AI当前的实际状态来触发的而不是按照时间表固定在某个时间点说某句话。第二它的行为被严格锚定在原始对话用户的真实意图上通过一份从原始对话中提取的用户意图分析报告来约束防止虚拟用户说出原始用户从未表达过的需求或观点。这两条原则共同解决了两种极端的失败情况如果完全按照原始脚本说话时机可能错乱如果完全自由发挥又可能偏离原始任务。锚定但灵活的虚拟用户让不同AI都在相同的任务精神下被测试同时各自面对符合自身实际情况的用户反馈。---**三、怎么给AI的工作打分**评分是整套框架里最讲究的环节。研究团队发现传统的跑单元测试方式来评判AI有没有完成任务存在两个方向的问题。一方面测试用例可能太窄——它只检查某个特定的实现细节但AI用另一种同样正确的方式实现了测试却判它失败。另一方面测试用例可能太宽——它检查了一些原始用户根本没要求的行为导致任何AI都很难通过。事实上OpenAI在2026年2月就因为类似原因停止报告SWE-bench Verified的成绩认为这套测试已经无法准确区分真正完成任务和表面通过测试的情况。SWE-Together的评分方案把两种方式结合起来。可执行的测试仍然会运行但它们只是提供证据而不是最终裁判。最终裁判是一个评审AI它会根据一套从原始对话中提炼出来的行为目标清单来评判AI的最终代码是否达到了用户的真实目的。这套目标清单的生成过程是关键它在评测任何AI之前就已经固定好了不会因为被评测的AI交出了什么样的代码而改变。每个目标有对应的权重最终分数是各个目标完成情况的加权平均数值在0到1之间超过0.85就算通过。同样的清单和标准对所有参加评测的AI一视同仁。除了最终得分研究团队还设计了两个过程诊断指标来观察交互质量。第一个叫做意图覆盖率用来衡量虚拟用户在整个对话过程中有没有忠实地把原始用户的所有需求传递给被测AI。这个指标会把虚拟用户说过的话与从原始对话中提取的原始用户意图一一对照看有没有遗漏或者跑偏然后用70%的权重衡量有多完整30%的权重衡量有多准确合并成一个综合分。这个指标主要是用来确认测试条件本身是否稳定而不是用来给AI排名的。第二个叫做用户纠正次数这才是直接反映AI表现的指标。每当虚拟用户明确指出AI的工作有误比如你写错了、这不是我要的就计1分如果虚拟用户只是隐晦地表示怀疑比如这样真的对吗就计0.2分。这个分数越低说明AI越能自己把任务做对越少需要用户帮忙纠正。---**四、七个顶级AI助手同台竞技结果如何**研究团队用这套框架评测了七个当前最先进的AI编程模型每道题跑两遍取平均一共评测了109道题。排名第一的是Claude Opus 4.8通过率63%而且平均只需要1.38次用户纠正——在七个模型里需要用户帮忙最少。GPT-5.5和Claude Opus 4.6紧随其后通过率都是58%但GPT-5.5在两次运行都成功这个严格标准上表现更稳定而Claude Opus 4.6在平均分标准上略高一点两者基本平分秋色。GLM-5.2和GLM-5.1构成第二梯队通过率分别是55%和52%GLM-5.2的两次运行稳定性明显优于GLM-5.1说明GLM-5.2的表现更可预期。DeepSeek-V4-Pro和MiniMax-2.7排在最后其中MiniMax-2.7的通过率只有40%同时需要的用户纠正次数最多达到2.17次几乎是Opus 4.8的1.6倍。作为参照研究团队还用原始对话中人类用户实际提交的代码改动来跑了一遍评分——这个参考答案的通过率约为78%平均分0.90。最强的AI模型与这个人类水平参考线之间还有约15个百分点的差距说明现在最好的AI还不能完全替代有经验的人类开发者。用户纠正次数与AI能力之间的关系在数据上表现得相当清晰。研究团队计算了用户纠正次数与各项通过率之间的相关系数结果是-0.92与pass1的相关性和-0.84与稳定通过率的相关性负号代表能力越强需要纠正越少数值接近-1说明这种反向关系非常紧密。换句话说AI越厉害用户就越不用操心去纠正它。这个发现呼应了普通用户的直觉一个真正好用的助手应该是你不用反复解释它就能干好的那种。在效率层面GPT-5.5的表现格外突出。它不仅排名第二而且用的token数量可以理解为计算消耗最少——每道题平均2.99万个token完成时间也最短平均10.7分钟。相比之下Opus 4.8虽然最厉害但每道题消耗了7.4万个token是GPT-5.5的两倍多。MiniMax-2.7和GLM-5.1则是耗时最长的分别需要36.2分钟和38.8分钟不过这可能也受到各自服务器位置和基础设施的影响。---**五、虚拟用户够真实吗用四个真人来评判**一个自然的疑问是这个虚拟用户模拟的行为真的像真实用户吗研究团队做了一个类似图灵测试的实验来回答这个问题。他们找来四位人工标注员让他们在一个网页界面上逐一判断眼前这段对话里用户是真实的人还是AI模拟的每次判断是二选一的强制选择不能弃权。实验使用了109道题中有52道被三个不同AI模型都做过的题目这样每道题有三段对话可以配对总共产生156对配对、312次判断。最终结果是标注员认为这是真实用户的概率为46%95%置信区间在40.5%到51.6%之间。因为这个区间包含了50%——也就是纯随机猜测的水平——统计上无法证明标注员能可靠地区分虚拟用户和真实用户。这意味着在普通人眼里这个AI模拟出来的用户的行为与真实用户几乎没有可辨别的差异。---**六、这项研究在整个领域里处于什么位置**在SWE-Together之前编程AI的评测大体上分两类。一类是测试AI与工具环境的交互——AI可以看文件、运行命令、改代码、跑测试但用户的要求从头到尾就是那一句话不会变。SWE-bench系列是这类测试的代表是目前学界最权威的编程AI基准之一。另一类是测试AI与用户的多轮对话但这类测试的题目往往是人工编造的不是来自真实用户的真实需求用户模拟器也没有锚定在真实行为上。SWE-Together是目前极少数同时满足四个条件的评测框架题目来自真实代码仓库而不是玩具级别的编程题、AI可以与工具环境互动、包含真实的多轮用户反馈、且整个任务来源于真实用户与AI的录制对话。麻省理工学院、斯坦福等多个团队此前也做过一些类似的探索比如用模拟用户逐步透露隐藏信息的方式测试AI或者用满意度驱动的模拟用户来测试GitHub Issue的解决能力。但这些工作的用户模拟器大多基于通用的角色扮演提示词没有锚定在真实用户行为上。一项来自外部的研究Suh等人2026年则发现锚定在真实人类行为上的用户模拟器能培养出质量明显更高的协作AI助手这为SWE-Together的设计选择提供了外部支撑。---**七、这套框架有哪些还未解决的问题**任何评测框架都有局限SWE-Together也不例外研究团队在论文中坦诚地提出了这些问题。当前的虚拟用户只能在AI完成一轮操作之后才能说话没法在AI操作到一半的时候插嘴打断。这意味着一些现实中非常自然的用户行为——比如等等我刚才说错了你先停下——目前还无法被模拟。此外虚拟用户只能看到文字和命令行输出看不到界面截图或者视觉化的信息而真实用户有时候会根据看到的网页效果来给反馈这部分信息目前被完全忽略了。这套评测框架最擅长处理的是有明确可测结果的任务——比如加一个功能、修复一个Bug这类任务可以通过检查最终代码来评判是否完成。但如果任务本身是模糊的、开放式的或者结果是主观的比如帮我把代码写得更优雅一点当前框架就力不从心了。---归根结底这项研究揭示了一件对普通用户来说挺重要的事一个AI编程助手到底好不好用不只是看它最终能不能把代码写对还要看在这个过程中你需要纠正它多少次。纠正次数越少你的使用体验就越好省下来的时间和精力也越多。从实验结果来看目前最好的AI助手Opus 4.8在109道真实任务里平均只需要1.38次用户纠正就能完成通过率63%。这已经相当不错但距离人类高手水平78%通过率还有一段距离。这意味着即便是最顶尖的AI编程工具在真实的工作场景中仍然需要你投入相当程度的引导和纠正。对普通用户而言这项研究提供了一种更符合实际的眼光去看待AI编程工具的评测排名当你看到某个AI在传统基准测试上拿了高分不妨问一句——它在真实的来回对话中表现如何它需要你纠正几次才能干好活这两个问题可能比单纯的通过率更能反映你的真实使用体验。有兴趣深入研究的读者可以通过arXiv编号2606.29957获取完整论文或访问togetherbench.com了解更多详情。---QAQ1SWE-Together和SWE-bench有什么区别ASWE-bench是目前最主流的AI编程测试框架它给AI一个完整的任务描述AI提交代码然后打分全程没有用户互动。SWE-Together在此基础上加入了多轮用户对话AI每完成一步一个虚拟用户就会根据情况决定是否介入纠正更贴近真实使用体验。SWE-Together的题目还来自真实用户与AI的录制对话而不是人工编造的。Q2用户纠正次数指标是怎么计算出来的A每当虚拟用户明确指出AI的工作有误就计1分如果虚拟用户只是隐晦地表示怀疑就计0.2分。把每道题两次运行的分数平均后再对109道题取总平均就得到每个模型的用户纠正次数。这个数字越低说明AI越不需要用户帮忙纠正使用体验越好。Q3SWE-Together里的虚拟用户是怎么保证不偏离原始用户意图的A研究团队从每段原始对话中提取了一份用户意图分析报告详细记录了原始用户想要什么、有哪些限制条件、在什么情况下才会开口。虚拟用户在整个测试过程中始终以这份报告为行动依据不会凭空发明原始用户从未表达过的需求同时又能根据被测AI的实际状态灵活决定何时说话。