JetBrains研究：4782次会话揭示编程助手评测偏了

天天在用IDE里那个能写代码、能改bug的编程助手，你想过没有，它被考的那些“试题”到底是什么样的？

多数人恐怕没往这儿想过。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刚动笔，用户突然插一句“等等，这段现有代码是干嘛的？”，解释完，用户又说“那你先帮我规划一下怎么改”，规划完才真正开写，写完还要“review一下这段改动”。

这条路弯弯绕绕，有问有答，有计划也有调整，不是一条直线冲到底。

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

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

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

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

研究者接着又调取了三份公开的人机交互数据集来做横向对比：SpecStory 来自 IDE 导出的真实会话，DataClaw 是社区里分享的 AI 编程助手对话，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进一步提到77.8分。

经过这轮筛选，最终留下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（拆分加仓库问答）。

结果出乎很多人预料：Split相比Single，AI解决同一批任务的花费大约翻了一倍，但解决问题的成功率（resolve rate）并没有稳定地上升或下降，各个模型之间的变化方向还不一致，基本和同一设置多次重复运行产生的波动差不多大。

这个结果值得细细琢磨。

它不是说交互方式拆开之后AI变弱了，也不是说变强了，而是说交互协议本身这件事会显著改变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使用成本的一个关键因素，光盯着最终做没做对并不够。