JetBrains扒了4782次编程助手会话：现有评测基准考偏了方向

IDE里那些能帮着写代码、改bug的编程AI助手，它们平时做的"考试题"究竟长什么样，你琢磨过吗？

多数人大概没往这上面想过。JetBrains的研究团队却认真研究了一番，给出的结论有点出人意料。

他们翻查了4782次程序员真实使用编程助手的会话，发现一个让人不太好受的现实：眼下给AI编程助手打分用的那些测试题，跟程序员平时真正拿助手干的事，根本对不上号。

这可不是无关紧要的小偏差。整个评测体系，可能一直考的都是错题。

**先瞧瞧现在的考题是什么样**

眼下业界公认权威度较高的编程助手测试集里，SWE-Bench Pro是其中之一。

SWE-Bench Pro*：这是个以真实GitHub issue为基础搭起来的编程智能体评测基准，玩法是让AI读一段软件缺陷或功能需求的描述，再产出一个能通过测试的代码补丁。

此类基准的路数相当一致：把一个描述得清清楚楚的问题丢给AI，AI一口气交出一个补丁，跑一遍测试，过了就得分。

研究团队做了统计，SWE-Bench Pro里94%的任务，不是"修个bug"就是"加个新功能"，而且需求都一次性交代明白，一锤子买卖。

打个比方，这就像考驾照时科目二翻来覆去只考"倒车入库"和"侧方停车"，教练也只教这两样，因为整个驾考体系默认这就是"标准路况"。

可真正开车上路的人每天碰到的是什么？堵车了要不要变道、导航忽然重新规划路线、副驾驶临时改主意说绕路去买杯咖啡。

假如驾校的全部训练和考试只覆盖"倒车入库"一种场景，那考出来的司机面对真实路况，究竟有几成把握把车开好？

**真实用户到底在干什么**

研究团队从拿到手的4782次真实会话里，挑出消息数量大于等于3条的"长对话"样本，这部分占33%。

为什么只盯长对话？短对话里用户只发一条消息、AI回一次就结束，多半是简单问答，研究价值不大。真正能看出用户和AI怎么"打交道"的，是那些来回好几轮的会话。

这么一看，问题就露出来了。

这些长会话中，修bug和加新功能两类任务加在一起，占比离一半还差得远。其余大部分时间，用户在问AI项目里某段代码怎么运作、让AI帮忙做规划、请AI审查一段改动、要求重构代码、执行某个命令。

第二个发现更关键：同一次对话里，用户会反反复复切换任务类型。

一个典型的真实场景是这样：用户先提了个新功能需求，AI刚动手写，用户突然插一句"等等，这段现有代码是干嘛的？"，等AI解释完，用户又说"那你先帮我规划一下怎么改"，规划定了才真正开始写代码，写完用户还要求"review一下这段改动"。

这条路走得曲曲折折，有问有答，有计划也有调整，不是一条直线冲到底。

可现在的评测基准只测那条直线冲刺，AI能不能应付这种九曲十八弯的真实对话，根本不在考核范围内。

论文里有张图专门画出了这层差异：左边是SWE-Bench Pro的任务类型图，只有三种颜色的色块（新功能、修bug、重构），简单得像儿童识字卡片；右边是真实生产会话的图，一张色彩斑斓、线条交织的桑基图，十几种任务类型来回流动、互相转化。

这张对比图本身就是最直白的证据，一边是单色道具，一边是万花筒。

**更麻烦的是，连"真实"本身都没有统一标准**

研究团队并未就此收手，又拿另外三份公开的人机交互数据集做了对照：从IDE导出的真实会话SpecStory、社区里分享的AI编程助手会话DataClaw，以及基于聊天场景的编程交互数据SWE-chat。

比对下来，这三份数据集在“任务流”上的表现同样各不相同。

比如SpecStory，规划类任务占了相当大的比重；DataClaw则由“执行命令”和短平快的操作型对话撑起主体；到了SWE-chat，执行与规划两类任务合起来拿走了大半份额。

这背后是一条挺要紧的结论：所谓“放之四海而皆准”的真实用户行为分布，其实并不存在。

产品不一样，用户群体不一样，使用场景不一样，长出来的交互模式也就完全不一样。

打个比方，问“中国人平均一天吃几顿饭”，南方人和北方人对不上，上班族和自由职业者也对不上，想拿一个数字把所有人概括进去，根本做不到。

由此，研究团队亮出了这篇论文最核心的立场：不存在一个普遍适用、可以被称作“最真实”的编程智能体评测基准。基准设计者得先讲明白自己要测的是哪一类用户、哪一种使用场景，再去实际测量这类用户的行为分布，然后按照这个分布校准评测基准的交互方式。

听上去不复杂，但它实际冲着行业里默认的评测思路去的。

**任务流到底怎么量化**

只讲“用户行为很复杂”显然不够，研究团队需要把这份复杂性变成能算、能比的东西，于是提出了“任务流”这个概念。

任务流（Task Flow）：一批对话的整体特征，靠三组统计分布来描述：一是会话长度分布，看一次对话平均包含几条消息；二是任务类型分布，看各类任务各自占多大比例；三是类型转移分布，看从一种任务类型转向下一种类型的概率有多大。

要得到这三组分布，第一步是给每条用户消息打标签，判断它究竟归哪一类任务。

研究团队为此搭了一套16类的任务分类体系，修bug、加新功能、写测试、重构、解释代码、规划、代码审查、执行命令等都列在其中，再由一个开源大模型逐条给用户消息打标签。

这套分类靠不靠谱？他们让三个不同的开源模型对同样的100条会话分别打标签，三个模型两两之间的平均一致率落在76.1%。

这个数字意味着，给自然语言消息分类本身就带模糊性，模型之间会分歧，但大方向可信。

统计结果是这样的：4782次会话中，超过一半（50.9%）只有1条用户消息，75分位数是3条，90分位数是8条。第一条消息平均30.7个词，后续消息平均只有16到19个词——用户一上来会把需求讲得比较完整，后面的交流更简短、更即兴。

长会话里的构成则是：修bug占25.9%，新功能占18.9%，两项加起来不到一半，与SWE-Bench Pro的94%对比鲜明。

“解释代码”这一类（EXPLAIN）值得单独拎出来说。长会话中，“帮我看看这段代码到底在干嘛”这类请求占6.1%，再加上更泛化的编程问答（QUESTION）类型的9.7%，两者合计接近16%。

这类需求在issue驱动的基准里几乎找不到影子，可在真实使用中，它稳定地出现在对话的各个位置。论文后面提出的一个解决方案，正是由这个发现直接引出来的。

**怎么把老基准改造成新基准**

找出问题只是第一步，研究团队没有停在“吐槽现状”，而是给出了一套具体的改造方案，名叫SWE-TaskFlow。

SWE-TaskFlow：一种把现有issue驱动型编程基准（比如SWE-Bench Pro）改造成多轮交互式评测的方法，核心思路是保留原有任务验证机制不变，只重新设计交互层。

这里有个关键的设计取舍：为什么不干脆重新收集一批真实多轮对话数据，自己造一个全新的基准？

原因在于成本太高，而且现有基准里已经攒下的宝贵资产会被白白浪费，比如每个任务对应的代码仓库环境、验证补丁是否正确的测试用例。这些东西经过大量人力验证，扔掉重来不划算。

这就像装修房子，地基和水电管线要是已经铺好、验收也过了，为改个风格把房子推倒重建完全没必要，重新设计室内布局和软装就够了。

真推倒重建，工程量会急剧上升，出错概率也跟着涨，还可能带进新的质量问题，反而得不偿失。

SWE-TaskFlow具体做了两件事。

第一步是“提示拆分”（prompt splitting）。在SWE-Bench风格的issue描述中，目标、背景、约束条件乃至实现思路往往被一次性塞进同一条消息，这本身就属于“过度规范化”，真实用户几乎不会这么干。具体操作上，用大模型把一条issue改写成3条用户消息，彼此独立成立、按先后顺序排列，以此模拟真实用户一点点透露需求的过程。

拆分不能随意进行，拆分模型必须满足几条硬性要求：原始issue中的需求一条都不能少，不允许无中生有地添加新需求，代码片段、接口名等技术细节要原样保留；并且每条新消息都得能在前一步留下的代码仓库状态上接着操作。

只有通过这套严格检查的任务才会被保留下来，731个公开SWE-Bench Pro任务里，最终700个通过了检验。

第二步是“仓库问答”（repository QA），它的任务是把EXPLAIN这一类型的缺口补上。办法是从此前成功解决过该issue的AI运行记录中，找出0到3个与代码仓库行为相关的问题，再把这些问 题插进由issue拆出的几条消息之间——可以置于开头、穿插在中段，也可以放到末尾。

难点在于如何确保生成的问题可靠。每个问题都自带一份隐藏的参考答案，并且要在一个干净的代码仓库副本里，由一个可执行的“证明脚本”实际跑一遍加以验证：确认该问题确实能从代码仓库本身推出答案，确认它在补丁应用前后都成立，同时不会提前把issue的解决方案泄露出去。

这套机制保证了“仓库问答”不是随便编的送分题，而是真正能检验AI对代码理解能力的硬指标。

把拆分与问答两种手段合在一起，每个任务便能生成1到6条用户消息；其中消息数不少于3条的那部分任务，就构成了对齐真实长会话场景的新基准。

**怎么知道改造得够不够像**

有了拆分和问答这两个工具，接下来的问题是：怎么量化“这个改造后的基准，到底有多接近真实用户的任务流”？

研究团队为此设计了一个专门的打分指标，叫TaskFlow对齐分数。

TaskFlow Alignment Score，简称TFAS*：用来衡量一个生成的基准，在会话长度分布、任务类型分布、类型转移分布这三个维度上，和目标真实任务流有多接近的综合评分，取值范围0到100，100代表完全匹配。

TFAS的计算用到了一个叫Jensen-Shannon散度的统计工具，用来衡量两个概率分布之间的差异程度，差异越小，对应维度的得分越接近1，三个维度得分的几何平均数乘以100，就是最终的TFAS。

有了这套衡量标准，研究团队就能做一件颇有价值的事：针对同一个任务，生成多种拆分方案与问答插入方案，再从中选出TFAS分数最高的一版，作为最终校准后的基准任务。

实验结果很说明问题。纯拆分（Split）的TFAS是59.6分，加上固定位置插入的问答后能提升到75.6到77.1分，而经过算法优化、自动选择插入几个问题以及插在哪个位置之后，TFAS进一步

经过这一轮优化，共保留454个仓库问答问题，覆盖700个任务中的255个；113个会话插入了1个问题，85个插入了2个，57个插入了3个。插入位置同样分布多样：有的全部放在issue消息之前，有的全部放在其后，还有的穿插在中间。

这组数据指向一个结论：只做拆分，距离真实用户的任务流仍差得远；必须把“解释代码”这类此前缺失的意图类型补齐，基准的交互分布才会真正向真实场景靠拢。

**改造之后，考出来的成绩会不一样吗**

这是整篇论文最硬核的实证部分。研究团队用mini-swe-agent这个开源AI编程助手框架，在GPT-5.6 Luna、GPT-5.6 Terra、GPT-5.4 Mini、Gemini 3.7 Flash四个模型上，对比了三种交互方式：Single（原版一次性给完整issue）、Split（拆分成3条消息）、Split+QA（拆分加仓库问答）。

结果超乎不少人预料：与Single相比，Split让AI解决同一批任务的开销大约翻倍，可成功率（resolve rate）并未稳定走高或走低——各模型的变化方向并不一致，幅度大致等同于同一设置下多次重复运行产生的波动。

这个结果值得细细琢磨。

这既不能说明“交互方式拆分后AI变弱了”，也不能说明“变强了”；它说明的是，交互协议本身会明显改变AI完成任务要付出的代价，却未必影响它最终能否做对。

这个发现的分量不轻。评测若只盯住“做没做对”一项，就会把“做对花了多少代价”整个漏掉。两个AI最后都完成了任务，可一个两分钟、一轮问答就收工，另一个被拆成三轮对话、中途还被追问了两次代码细节、掏了双倍的钱才做成，放到真实使用里，这两种表现差得远。

好比两个学生都拿了满分，一个提笔就写完交卷，另一个被老师拦下追问三遍“这步为什么这么写”，问完才勉强把分拿满。

卷面分数相同，两人露出的真实本事却完全不是一回事。后者说不定只是蒙对了答案，前者才是真懂了。

评测只看最终分数，这种差别就永远浮不出来；只用“一锤子买卖”式的基准去测AI，这种差别同样无从体现。

另一个可关注的数据是仓库问答的答题准确率，四个模型落在69.8%到83.0%之间，这是“任务解决率”之外的第二个可验证信号。拆分加问答之后，新基准不再只给一个0或1的终极判断，每一轮对话都能产生独立的验证结果，后续做更精细的诊断和训练都用得上。

研究团队还设了一组对照实验，专门排除“拆分过程本身是否丢失或扭曲了原始信息”这个干扰。他们造了个叫Concat的对照组，把拆开的三段内容原样拼回一条消息发给AI，结果Concat和Single的表现接近。可见拆分本身没有明显损伤原始issue信息，真正带来成本变化的是“分批次、按顺序发送”这种交互形式。

仓库问答插入的位置（放最前、放最后、随机穿插）也被测了一遍，怎么摆放，成功率和答题准确率都没有稳定差异。这说明TFAS优化算法可以放心按目标任务流去调整问题插入位置，不必担心这种调整会意外改变任务本身的难度。

**这事儿还没做完**

研究团队坦言，论文目前只覆盖了16种意图类型里的一小部分。拆分方法只用于“修bug”“加新功能”这类实现型任务，仓库问答只覆盖了“解释代码”这一种类型。

此外，真实任务流中还有大量别的情形，比如一般性编程问答、规划、代码审查、重构、执行命令、不带修复的纯调试，这些类型眼下都缺少对应的改造办法。

难点在于，很多这类任务没有现成的、可自动化的验证标准。一个规划步骤对不对，一次代码审查的意见好不好，眼下都很难用脚本判定对错，这是留给后续研究的开放问题。

研究团队还点出了一个更根本的区分：SWE-TaskFlow归为“静态交互”，也就是AI动手之前，所有用户消息就已经定死了，好处是能精确复现、让不同AI模型公平比较。可现实里还存在“反应式交互”——AI先做了什么，用户才据此给出下一步反馈。这种方式更接近真实场景，却没法完全复现，每次跑都可能因为模拟用户的随机性而不一样。

两种交互方式各有取舍，论文认为一个完整的评测体系应该把两者结合起来，用校准过的静态核心加上针对性的反应式压力测试。

论文末尾也承认了几处不足：意图分类器没用人工标注的标准答案集验证过准确率，只能拿模型间一致性作参考；有些issue本身不满足拆分条件，因此被排除；仓库问答的难度会随生成模型不同而波动；每组实验仅跑了三次，给出的是最大最小值区间，并非统计学意义上的置信区间。所以文中报告的成功率变化只能当方向性参考，还不足以作为有统计显著性的结论。

写在后面

读完论文，我一直在想一个问题：我们是不是太习惯把“评测基准越标准、越干净”直接当成进步，却忘了追问，标准化之后测出来的结果，还和真实世界对得上吗？

这让我联想到一个更大的现象。不少领域的“标准化测试”最初都是为了便于比较、便于复现才设计的，教育里的标准化考试、机器学习里的固定数据集都是如此。标准化本身没问题，问题在于我们慢慢忘了，这些标准不过是“真实世界的一个简化切片”。时间一长，大家开始围着考好这个切片去优化，而不是围着解决真实世界的问题去优化。

让我意外的是，这篇论文没有简单喊一句“基准不行，要重做”，而是给了一个更可操作的思路：先测量，再校准。先把真实用户到底在干什么老老实实统计清楚，再拿这份统计去调整评测该测什么、怎么测。这种“先调研再设计”的朴素逻辑，放在很多工程领域都成立，偏偏在AI评测这个被“刷榜”心态裹得很深的圈子里，显得有点新鲜。

还有个细节值得单独说：论文提到，拆分交互让AI解决任务的成本翻了一倍，成功率却没有明显变化。这组数据乍看有点“所以呢”的味道，细想却挺扎心——它说明眼下不少AI编程助手所谓的“聪明”，可能很大程度上建立在“用户把话一次说清楚”这个隐藏假设上。交互一旦更像真实对话，AI就得多花力气去理解、去追问、去适应，这正是真实世界里AI助手每天面对的隐性成本，只不过过去的评测体系从没把这部分算进去过。

如果你的编程助手在实际使用中常让你觉得“每次都得额外解释几句它才懂”，现在可以确定了，这不是错觉，而是整个评测体系长期存在的一个盲区。

Q&A

Q1：SWE-TaskFlow是什么？

A：SWE-TaskFlow是一套方法，把现有的issue驱动型编程基准改造成多轮交互式评测。它靠提示拆分和仓库问答两种手段，在原有任务验证机制保持不变的情况下，让交互方式更接近真实用户的使用习惯。

Q2：为什么现有的编程助手评测基准不够真实？

A：原因在于，SWE-Bench Pro这类基准里94%的任务都是一次性讲清需求的修bug或加新功能；而真实用户在长对话中会频繁切换提问、解释、规划、审查等多种任务类型，两者的交互模式差别很大。

Q3：交互方式改变后，AI编程助手的表现会有什么变化？

实验结果显示，把一次性提的需求拆成多轮对话来提，AI 完成任务的成本大约翻一倍；可最终把问题解决掉的成功率，并没有出现稳定变化。可见交互方式本身就是左右 AI 使用成本的一大因素，不能只盯着最后做没做对。