Scale AI揭示编程智能体在真实对话中的巨大短板

这项由Scale AI研究团队完成的研究于2026年6月发表，论文编号为arXiv:2606.30573，有兴趣深入了解的读者可以通过该编号查询完整论文。

**一个被忽视的真相：真实的开发者从来不会把话说清楚**

现实中，没有哪个程序员在委托AI助手完成任务时，会把所有要求一次性说得清清楚楚、毫无遗漏。实际情况更像是：老板走进办公室，扔下一句"把那个语音播放模块改一改"，然后等你做出来之后，才开始一条条告诉你哪里不对，哪里还差一点。

然而，目前绝大多数用来评测AI编程能力的基准测试，都是按照"完美甲方"的假设来设计的——把所有需求、所有接口规范、所有实现细节，一股脑塞进一个超级详细的任务说明，然后让AI去实现。这种测试方式当然能衡量某些能力，但它几乎完全忽略了现实开发场景中最普遍的情况：需求是模糊的、会变的，用户是挑剔的、有时候自己也不清楚想要什么的。

正是为了填补这个空白，Scale AI的研究团队构建了一个名为SWE-INTERACT的全新测试平台。它的核心思想是：把现有的编程任务基准测试，从"一次性交付全部需求"改造成"在来回对话中逐步透露需求"，让AI编程助手真正面对一个像人类一样工作的"甲方用户"。

**一、那个会检查你代码的虚拟甲方是怎么设计出来的**

要理解SWE-INTERACT的独特之处，不妨先想象这样一个场景：你是一名程序员，公司里来了一位资深工程师充当你的客户。他不会把需求文档甩给你，而是先说一句很随意的话："帮我把语音广播模块重构一下，加个录制功能，用事件驱动。"

然后你动手做了第一版，给他看。他扫一眼，说："单例模式，下一步。"你修改，他又看，说："构造函数里的初始状态不对，再改。"这样来来回回，每次他只提一个问题，每次都是在看过你的具体实现之后才说。他不会提前给你完整的规格说明书，也不会一次性把所有问题都告诉你。

这，正是SWE-INTERACT里那个"虚拟用户模拟器"的工作方式。

研究团队在设计这个模拟器之前，首先分析了SWE-chat数据集中数千条真实的用户与编程AI之间的对话记录。他们发现，现实中最常见的使用模式是"振动编码"（vibecoding）——用户几乎不自己写代码，超过99%的代码都由AI完成，用户只负责提要求和审核。而最典型的用户画像是"资深挑剔者"（Expert Nitpicker）——这类用户的消息短、随意、直接，他们关心的是API接口的精确细节，会一轮一轮地迭代批评实现，随时加新需求，直到满意为止。

基于这些真实数据，团队设计了一个具有详细行为规则的用户模拟器。这个模拟器不只是一个静态的"回答问题"的LLM接口，而是一个真正会主动行动的智能体——它能用shell命令检查AI编程助手的工作区，查看代码文件，比对git提交记录，然后根据自己实际看到的内容，给出有针对性的批评和新要求。换句话说，它会"看你写的代码"，而不只是"听你汇报进度"。

整个测试框架从三个知名的编程基准测试中各挑选了25道题，合计75道，涵盖SWE-bench Pro、SWE Atlas和DeepSWE。这些原本都是"一次性给全需求"的单轮任务，被团队改造成了多轮对话任务，任务的最终评分标准不变，还是用原来的验证器检查代码正确性——只是获取需求的过程，变得像真实工作一样曲折。

**二、真实对话让最强模型的通过率直接腰斩**

研究团队选取了五款当时最先进的AI模型进行测试，分别是GPT 5.5、Opus 4.8、Kimi K2.6、Gemini 3.5 Flash和Sonnet 4.6，并为每款模型设置了"单轮基准"和"多轮对话"两种测试条件。

在单轮基准条件下，也就是一次性给出所有需求的传统测试方式，各模型的成绩尚可。Opus 4.8以50.7%的通过率领跑，GPT 5.5紧随其后达到48%，Gemini 3.5 Flash和Kimi K2.6分别是29.3%和25.3%，Sonnet 4.6则是21.3%。

然而，一旦切换到SWE-INTERACT的多轮对话模式，所有模型的成绩都出现了显著下滑。Opus 4.8从50.7%跌至26.7%，GPT 5.5从48%跌至24.7%，下跌幅度都超过了23个百分点。Gemini 3.5 Flash和Kimi K2.6也分别下跌了12和10.7个百分点。唯一跌幅相对较小的是Sonnet 4.6，只跌了2.5个百分点——但这并不是因为它在多轮对话中表现更好，而是因为它在单轮任务中本就表现垫底，下跌空间有限。

换个方式来理解这组数据：原本能完成一半任务的最强模型，在面对真实风格的"挑剔甲方"之后，只能完成大约四分之一的任务。相当于把考试卷的难度调高了一倍，但考试内容其实是同一道题。

与此同时，多轮对话模式所消耗的计算资源也大幅增加。步骤数通常是单轮的3到4倍，token消耗量增加了1.6到4.5倍，运行成本也相应翻涨。其中最极端的一个案例，整个任务轨迹包含了27条用户消息，用户对AI工作区发出了332次工具调用来检查代码，而AI自身则执行了超过1000步操作才完成任务。

**三、AI是如何在对话中逐渐"摸清"任务要求的**

研究团队还设计了一套方法来追踪AI在整个对话过程中"摸清任务要求"的进度，就像给一场侦探破案的过程打进度条。

具体做法是：把每个任务的完整需求拆解成若干个独立的子目标，比如"函数必须放在特定文件里"、"必须正确处理负数输入"、"API接口必须返回特定类型"等，每个子目标都有一个权重，所有子目标的权重加起来等于100分。然后，在AI每次提交一版实现之后，就用一个独立的评分模型来给当前实现打分——看它已经覆盖了多少个子目标。

通过这种方式，研究团队得到了一张每个AI模型的"目标发现曲线"：从最初写下计划文件（PLAN.md）开始，到每次根据用户反馈提交修改，目标覆盖率是如何变化的。

有一个有趣的规律出现了：几乎所有模型在"计划阶段"的得分，都高于"第一次实际实现"时的得分。这背后有两个原因：一方面，给计划打分的模型往往比较宽松，只要计划里提到了某个方向，就算覆盖；另一方面，AI在实际写代码时容易丢失一些在计划里已经考虑到的细节。打个比方，就像一个学生列了一份很完整的考试复习提纲，但真正上考场时，提纲上的知识点并没有全部答出来。

随着对话的推进，用户模拟器会逐渐"揭露"更多外部可见的需求，AI的目标覆盖率也随之上升。GPT 5.5、Opus 4.8和Sonnet 4.6最终都能覆盖超过90%的任务目标，而Gemini 3.5 Flash得分稍低，Kimi K2.6则明显落后。

但"知道了目标"和"真正实现正确"之间，还有一道不小的鸿沟。研究发现，几乎所有最终通过验证器的解决方案，目标覆盖率都在90%以上；但反过来，目标覆盖率高达90%的实现，却未必能通过验证器。换句话说，AI可以"知道该做什么"，但"做对"是另一回事。

**四、失败的原因：不是不懂要求，而是做不对**

为了搞清楚为什么那么多任务最终还是失败了，研究团队对287个失败轨迹进行了系统性的原因归类，每个失败案例可以被贴上一个或多个标签。

占比最大的两类失败，分别是"技术实现错误"和"遗忘了某个需求"，各自占到了所有失败标签的约三分之一。

技术实现错误，指的是需求已经清楚、AI也试图去实现，但最终代码还是出了问题。比如在一个KCP流多路复用的任务中，AI正确地创建了会话、流、帧等所有组件，但最终实现中，字节计数器始终是零，流在不应该关闭的时候被关闭了，远程关闭信号也无法唤醒正在等待的写入操作。这类错误更像是工匠在按图纸施工，但细节处理出了问题。

遗忘需求，指的是某个需求在对话早期已经明确提出，AI也回应说做了，但在后续的修改中，这个需求被悄悄抹掉了。比如在一个消息队列（Kombu）的任务中，用户先要求了取消通知的回调方式，后来又要求加入消费者晋升功能。AI加入晋升功能时，却把之前说好的取消通知行为丢了。这类错误像极了一个装修工人，客户第一天说要留个插座，第三天说要改墙面布局，工人改完之后那个插座就不见了。

排在第三位的是"误解或错误假设"，占约14%。这类错误发生在AI对需求做出了错误的理解，而没有去向用户确认。比如一个任务要求`Invalid`对象把错误存成不可变的元组，但AI把传入`Invalid(...)`的元组当成了单个错误，而不是作为错误集合的存储格式。

第四类是"用户从未告知的需求"，占约12%。这类情况实际上更像是测试本身的漏洞——用户模拟器没有把某个必要的需求传达给AI，导致AI无从得知。研究团队把这类情况识别为模拟器自身的不足，需要在未来改进。

最后还有一类"回归错误"，占约7%，指的是用户提出新需求后，AI修改代码时破坏了之前已经正确实现的功能。比如在一个Helm配置合并策略的任务中，AI针对"无匹配合并键时回退到追加策略"这一需求做了专门的修改，但后续为了处理其他新需求而调整代码时，这个已经正确的逻辑又被覆盖掉了。

**五、"挑剔型用户"角色的设计，直接决定了测试的真实性**

研究团队还专门做了一组对比实验，把他们精心设计的"资深挑剔者"用户角色，与一个极简的"中性用户"版本进行比较。中性版本保留了相同的任务内容和工具接口，但去掉了所有详细的角色行为规则，改成了一个简单的"当AI来问时，把需求告诉它"的通用提示词——这正是此前类似研究常用的做法。

结果非常清楚。使用"资深挑剔者"角色时，AI的对话轮数增加了约90%到97%，执行步骤增加了30%到50%，而通过率对于四个模型来说进一步下降了。这说明精心设计的用户角色确实制造了更真实、更有挑战性的测试环境——因为它不会一次性把所有需求和盘托出，而是像真正的用户那样，一次只提一个问题，分多轮迭代。

定性上看，两种角色之间的差异也非常显著。中性版本的模拟器往往在对话开始就给出相对完整的说明，并在AI完成后直接批准。而研究团队的"挑剔者"版本则真正展现出真实用户的行为模式：先给一个模糊的起始请求，看完AI的实现后再提API形状不对，等AI修改后再说SNMP计数器还有问题，再修改后说流开启的接口签名还差一点……一轮接一轮，每次只扣一颗螺丝。

**六、用什么模型来扮演"用户"也至关重要**

实验中使用了两个不同的模型来扮演"用户模拟器"角色：GPT 5.5和Claude Opus 4.7，并比较了它们各自搭配同一批AI编程助手时的差异。

GPT 5.5版本的用户模拟器明显更好地遵循了"资深挑剔者"的角色设定。它倾向于把需求拆分成更多轮次逐步透露，而不是一次给出一批；它在检查AI工作区时用的工具调用次数是Opus 4.7版本的4到5倍；它给出的批评也更具针对性和准确性。

由此带来的影响是，当用户模拟器是GPT 5.5时，AI编程助手的任务轨迹通常比Opus 4.7版本长出50%到100%，经历的对话轮次也更多。但另一方面，由于GPT 5.5模拟的用户会更彻底地检查实现并揭露更多需求，AI最终在部分任务上的得分反而略高——因为它得到了更完整的需求信息，犯"遗漏需求"类错误的机会减少了。

**七、代码改了多少次、改得有多乱，也能说明问题**

为了评估不同AI模型在多轮对话中处理代码演化的能力，研究团队还设计了两个衡量"修改效率"的指标。

第一个叫"冗余修改量"（Churn Overhead），计算方式是：把所有轮次的代码修改量加起来，减去最终提交的总修改量，再除以最终总修改量。这个数字越低，说明AI的每次修改都更接近最终方向，没有走太多弯路。第二个叫"后期修改占比"（Late Change Share），计算的是第一次实现提交之后的所有修改量，占全部修改量的比例——这个比例越低，说明AI在初期实现中就覆盖了更多的正确方向，不需要后期大幅返工。

Opus 4.8在这两项指标上都表现最好：冗余修改量只有6.9%，说明它的每次修改都相当紧凑，与最终方向高度一致；后期修改占比也只有24.7%，意味着超过四分之三的代码工作在第一次实现中就完成了。GPT 5.5紧随其后，后期修改占比为28.6%。相比之下，Gemini 3.5 Flash的后期修改占比高达54.5%，说明它在初次实现后需要做大量的推翻重写，像是一个没有规划好就动手的施工队，盖到一半才发现地基方向不对。

**八、研究的最后话：这不只是更难的编程考试**

研究团队在结论中明确指出，SWE-INTERACT测量的是一个与单轮自主编程截然不同的能力维度。通过率从50%骤降至25%，这个差距不是因为任务变得更复杂、需要更多代码——任务本身完全没变，唯一变的是获取需求的方式。

最强的模型——Opus 4.8和GPT 5.5——在模糊指令下能保持较好的开局，能坚持到所有需求被揭露，最终产出的代码也相对整洁。但即便如此，它们依然会犯技术错误、遗忘早期需求、在新需求和旧实现之间顾此失彼。

较弱的模型则在模糊指令下就开始走偏，有时候在用户还没说完所有要求时就急着提交，对话轮次更短，但正确性也更差，代码改来改去，留下大量无用的修改痕迹。

说到底，让AI在和人类的来回对话中完成一个编程任务，考验的不是它能不能写出正确的代码——那一关，现在的模型已经勉强过得去。真正的挑战，在于它能不能在需求逐步到来的过程中保持清醒，把前几轮说好的事情记住，把后几轮加进来的新要求融合进去，不把旧代码弄坏，不把新需求搞乱。这需要一种更像"长期注意力"和"多线程协调"的能力，而这恰恰是当前模型最明显的短板之一。

对于普通用户来说，这项研究的意义很直接：现在流行的AI编程助手，确实能帮你写不少代码，但如果你和大多数人一样，习惯于边做边改、随时加需求、事后挑问题，那么你的AI助手很可能会在某个时刻悄悄把你三轮前说的要求给丢掉，或者为了满足你的新要求，把之前已经做对的部分给破坏掉。了解这一点，至少能让你更有意识地检查AI的输出，而不是只看它说"已完成"就直接信任。

对这项研究感兴趣的读者，可以通过arXiv编号2606.30573查阅完整论文，也可以访问论文中提供的GitHub仓库地址github.com/scaleapi/SWE-Interact获取测试平台的完整代码和数据。

Q&A

Q1：SWE-INTERACT和普通的编程AI基准测试有什么本质区别？

A：普通的编程基准测试会把所有需求一次性告诉AI，AI只需要按图纸施工。SWE-INTERACT则模拟真实开发场景：一个虚拟用户先给出模糊指令，等AI提交实现后，才逐步通过对话揭露更多具体要求，而且这个虚拟用户还会实际查看AI写的代码，而不只是听AI的汇报。

Q2：为什么在SWE-INTERACT测试中，AI通过率会大幅下降？

A：主要有三类失败原因：一是代码技术实现有错误，需求懂了但写对是另一回事；二是AI在处理新需求时遗忘了早期轮次里已经确认好的要求；三是为了满足新需求修改代码时，把之前已经正确的功能搞坏了。这些问题在"一次性给全需求"的单轮测试中基本不会出现。

Q3：SWE-INTERACT测试中哪款AI模型表现最好？

A：在多轮对话测试中，Opus 4.8以26.7%的通过率略领先于GPT 5.5的24.7%。两者在代码修改效率上也更好，冗余修改量更低、后期大幅返工更少。相比之下，Gemini 3.5 Flash和Kimi K2.6不仅通过率更低，代码演化过程也更混乱，后期修改占比明显更高。