当AI说它能修好你的代码时，它其实假设了一件事

你有没有遇到过这种情况：跟同事描述一个bug，你就说了一句"这玩意儿一遇到空值就崩溃，帮我看看"，同事立刻就懂了，三分钟给你改好了。

但如果你把同样这句话丢给一个AI编程助手呢？

结果可能会让你意外。一群研究者做了个实验，把这句简单的话和一份写得工工整整、有背景有步骤有环境说明的GitHub技术报告分别喂给七个当红的AI模型，结果发现：所有模型在面对"人话版"请求时，解决问题的成功率平均掉了6.4个百分点。

这背后藏着一个被我们长期忽视的问题：我们评价AI编程能力的标准，可能从一开始就跑偏了。

**跑分标准和真实需求，早就不是一回事了**

现在业界评价一个AI编程模型强不强，几乎都靠一套叫SWE-BENCH的测试集。

SWE-Bench：一套从GitHub上真实开源项目里挑出的代码修复任务集合，每个任务都配有对应的问题描述和验证测试，是目前评估AI编程能力的行业标准

这套东西的问题在于，它里面的"问题描述"来源太特殊了。它们全都是从GitHub Issues里精挑细选出来的，通常写得极其详细：这个bug是什么现象、期望的正确行为是什么、怎么复现、在什么系统环境下出现的，甚至有时候提交者还顺手给出了解决思路。

但你自己平时跟AI编程工具聊天的时候，是这么说话的吗？

大概率不是。你可能就是甩过去一句"这个函数处理空字典的时候崩了，修一下"，然后就撒手不管了。

这就好比你拿着一份米其林大厨写的、精确到克数和秒数的菜谱去考察一个厨师的水平，但这个厨师日常接到的订单其实都是"随便做点好吃的，要快"。用第一种标准考出来的高分，未必能预测他在第二种真实场景下的表现。研究者们意识到，如果不这样区分测试，得出的模型排名可能完全是虚的，因为它测的根本不是模型在真实世界里会遇到的挑战。

为了把这个模糊的直觉变成可以量化的证据，研究团队做了一件挺笨但很扎实的事：他们找来一个叫SWE-CHAT的数据集，里面装着六千多个真实开发者和AI编程助手的对话记录，然后从中筛出718条真正由用户亲手打字写的请求（滤掉了AI自己生成的、工具自动插入的那些噪音），拿去和SWE-BENCH里1229个标准问题逐条比对。

比对的维度分成两块，一块是"内容成分"，一块是"说话风格"。

**内容缺什么，比内容有多少更重要**

先说内容成分。

研究者设计了一套信息分类体系，把一份代码请求可能包含的信息拆成几类。对于修bug的请求，分成问题描述、期望行为、复现步骤、环境信息、附加信息这五类；对于加新功能的请求，分成问题描述、动机、附加信息这三类。

信息分类体系：研究者根据GitHub官方issue模板总结出的一套框架，用来拆解一份代码请求里到底包含了哪些类型的信息，比如"到底出了什么问题"和"你希望它变成什么样"是两类不同的信息

结果非常悬殊。真实用户发的请求里，88%只包含"问题描述"这一项，或者再加一点无关紧要的附加信息（比如一个链接、一个日期）。而在SWE-BENCH的标准问题里，这种"光秃秃"的请求只占7%。反过来说，标准问题里93%都塞满了各种额外信息，而真实用户几乎从来不写这些。

这就好比你去医院看病，标准病例卡上写着"患者何时开始头疼、疼痛部位、伴随症状、既往病史、近期用药情况"一应俱全，但现实中大部分病人走进诊室说的第一句话是"我头疼，帮我看看"。医生要在这句简短的描述里推断出病人没说的那些关键信息，这个推断过程本身就充满了风险，医生越依赖病人主动详细描述，遇到"惜字如金"的病人时就越容易误诊。

再看说话风格。这个维度上，研究者又划了四条线：正式程度、句子类型、确定性、人称视角。

数据显示，真实用户87%的请求都是随口一说的口语风格，51%用的是祈使句，直接甩命令，比如"修一下"、"加个功能"。而标准问题里94%都写得规规矩矩、正儿八经，接近九成用的是陈述句，像是在写一份正式报告而不是聊天。

这两个维度的发现引出了这篇论文最核心的贡献：一个叫REALSWE的评测框架，它没有满足于笼统地说"真实场景和标准测试不一样"，而是把这种"不一样"拆解成了可以精确控制的变量。

**把同一个bug，用381种方式讲给AI听**

REALSWE的做法说起来简单，但工程量不小。

研究者从SWE-BENCH VERIFIED和SWE-BENCH PRO里挑出了381个任务，注意，这些不是随便挑的，而是必须满足一个苛刻的条件：这个任务的原始问题描述里，必须同时包含前面提到的所有信息类别（对bug任务来说是五类，对功能任务来说是三类）。只有这样，才能把它拆开重组成各种版本。

SWE-BENCH VERIFIED：由93名经验丰富的开发者人工审核过的500个高质量任务集合，用来做模型间的标准化对比

SWE-BENCH PRO：难度更高、跨度更长的731个任务集合，来自规模更大、结构更复杂的代码仓库

对每一个任务，研究团队先用大模型（GPT-5.4）把原始问题描述拆解开，把每一句话精确归类到对应的信息字段里，注意这一步不改写任何原文，只是重新分类摆放，确保不会在拆解过程中悄悄改变信息含量。之后再用大模型把这些内容按照真实用户的口吻重新表达一遍，只改变说话的方式，不改变技术内容，代码块、报错信息、文件路径这些硬核细节原样保留。

这样一来，同一个底层的编程任务，就可以生成一整个"变体家族"：既可以选择只保留问题描述、去掉其他所有信息，也可以保留问题描述加期望行为但去掉复现步骤，还可以在保留全部信息的基础上，单纯把语气从正式变成口语化。这个设计的巧妙之处在于，它把"内容多少"和"说话方式"这两个此前混在一起、很难拆开研究的变量，彻底解耦了。

打个比方，这就像做菜实验，你想知道到底是"少放盐"还是"火候不对"导致这道菜难吃，如果每次实验都同时改变盐量和火候，你永远搞不清楚问题出在哪。REALSWE相当于把每个变量都单独锁定，一次只改一个东西，然后观察结果的变化。如果不这样拆解，之前有些研究虽然也尝试模拟"真实用户的请求"，但往往是把好几个属性同时改掉，结果没法说清楚到底是内容变少导致模型表现变差，还是语气变随意导致的。

基于这套变体体系，研究团队又按照SWE-CHAT里观察到的真实分布比例，抽取出一个固定的评测集，叫REALSWE-BENCH，一共381个任务，bug修复类里74%只含问题描述、26%含问题描述加附加信息，功能请求类里也是类似比例。这个固定评测集的平均任务描述长度是1417个字符，跟SWE-CHAT里真实用户请求的1427个字符几乎一模一样，而传统的SWE-BENCH系列基准动辄1600到2700多字符，长了将近一倍。

**七个模型集体"翻车"，但翻车方式各不相同**

理论框架搭好之后，接下来就是拿真枪实弹去测试。

研究者选了七个当前主流的大模型，包括DeepSeek V4 Pro、DeepSeek V4 Flash、MiMo V2.5 Pro、MiMo V2.5、Claude Haiku 4.5、Qwen3.7 Plus和MiniMax M3，覆盖了不同规模和不同厂商，全部开启推理模式，用统一的代理框架跑测试，每个任务跑三次取平均值保证结果稳定。

结果印证了前面的猜测：全部七个模型在面对REALSWE-BENCH的真实风格任务时，解决率都下降了。降幅从MiniMax M3的4个百分点，到DeepSeek V4 Pro的8个百分点不等，平均降幅6.4个百分点，相对于各自原本的成绩来说，平均掉了13.6%的相对表现。

更值得琢磨的是，性能下降的同时，计算成本反而涨了。七个模型里有六个在面对真实风格任务时花费更多token、走更多步骤，平均多花6.2%的成本，平均多走1.8%的步骤。这说明模型在遇到信息不足的时候，确实会尝试通过多探索来补救,它会去翻代码库、查上下文、猜测用户到底想要什么,但这种补救的效果很有限，花了更多力气，最后解决率还是掉了。

这就好比你本来给了工人一份详细的装修图纸，工人三天就能干完活。现在图纸变成了一句"帮我把厨房弄得好看点"，工人不得不花更多时间在现场反复揣摩、试错、推倒重来，最后不仅活儿干得没那么完美，工时还超了。

但这个实验里最有意思的发现，其实是排名的洗牌。

在原始标准测试上，MiMo V2.5 Pro排在第四位，落后于Qwen3.7 Plus和DeepSeek V4 Flash。可一换成真实风格的任务，MiMo V2.5 Pro直接跳到了第二位，反超了那两个模型。研究者专门做了统计检验，确认这个排名变化在统计学上是显著的，不是运气。

而且MiMo V2.5 Pro每个任务的花费还只有Qwen3.7 Plus的四成左右。

如果你完全信任传统跑分榜单，选了那个花钱更多的模型，结果在真实使用场景下，它的表现其实和便宜的选项没有本质差别，甚至更差。这就好像你根据某款汽车在赛道上的圈速排行榜买车，结果买回来发现日常通勤路况完全不是那么回事，你花大价钱买的性能优势，在真实道路上根本体现不出来。

除了排名洗牌，研究还发现了一个规律：原本在标准测试上表现接近的几个头部模型（Qwen3.7 Plus、DeepSeek V4 Flash、MiMo V2.5 Pro、MiMo V2.5），在真实场景下彼此之间的差距反而拉大了一倍，从1.7个百分点变成3.3个百分点。但与此同时，因为最强的模型在真实场景下损失得也更多，整个榜单从最强到最弱的总跨度反而收窄了。也就是说，真实输入没有简单地把所有分数往下平移，而是重新洗牌了模型之间的相对位置。

另外一个细节是，bug修复类任务的表现下降幅度平均达到9.1个百分点，而功能请求类任务只下降了3.7个百分点。这个差异不是巧合，它直接指向了下一个更深层的问题：到底是哪种缺失的信息，最伤害模型的表现？

**不是信息越多越好，是缺了"关键那一项"才要命**

前面的实验只是告诉我们"信息少了会变差"，但这个说法还不够精确，因为一个bug报告可能缺很多种信息,可能缺复现步骤，可能缺环境说明，也可能缺期望行为的描述。这些缺失是不是同等重要？

研究者设计了一组精细的消融实验来回答这个问题。他们选取四个模型，针对bug修复任务，从信息最完整的版本开始，一次去掉一个字段：先去掉附加信息，再去掉环境信息，再去掉复现步骤，最后去掉期望行为，只剩最基础的问题描述。

结果出乎很多人的预料。

去掉附加信息、环境信息、复现步骤这三项，对解决率的影响加起来平均只有1.8个百分点，几乎可以忽略不计，有些情况下甚至还提高了。但是，一旦去掉"期望行为"这一项，也就是不告诉AI"修好之后应该是什么样子"，解决率直接暴跌7.1到8.9个百分点，四个模型全部出现了具有统计显著性的下降，这个降幅是前面三项加起来的四倍还多。

这个发现，简单来说就是: 环境信息、报错的详细复现代码，这些看起来"专业"的技术细节，其实对AI来说没那么关键；但一句简单的"我希望它变成什么样"，反而是决定成败的命门。

期望行为：在bug修复类请求中，明确说明"修复之后应该表现出的正确行为是什么样子"的那部分描述，是区分模型能否成功修复的关键信息

功能请求任务里也有类似的规律，只不过关键信息换成了"动机"。研究者对比了只有问题描述和加上动机说明这两种情况，发现四个模型平均提升了3.4个百分点，其中DeepSeek V4 Flash提升幅度达到7.1个百分点。

动机：在功能请求类请求中，说明"为什么需要这个新功能、它要解决什么现实痛点"的那部分描述，能帮助模型更准确理解用户真正的需求

为什么"期望行为"和"动机"会这么关键？研究者给出的解释很有意思：对bug修复来说，问题本身描述的往往只是"哪里坏了"，但没说"修好该是啥样"，这中间存在推断空间，AI要么猜对要么猜错。而对功能请求来说，问题描述本身通常已经隐含了想要的行为是什么（因为你提的功能需求本来就是在描述你想要什么），所以"期望行为"这个变量本来就内含在问题描述里了，剩下能额外补充的最有价值的信息，就变成了"你为什么需要这个"。

这就好比你委托装修师傅改造你家阳台，如果你只说"阳台漏水，修一下"，师傅可能会简单堵住漏点就交差；但如果你补一句"我希望以后能在这里种花不怕淋雨"，师傅立刻明白你要的是彻底的防水层加装排水系统，而不是敷衍的补丁。这一句补充的分量，远超过你去详细描述漏水的具体位置和天气数据。如果没有这句关于"期望效果"的说明，师傅只能凭经验猜测你的真实诉求，猜对了皆大欢喜，猜错了返工重来。

研究者还专门验证了一件事：语言风格本身（比如是用正式语气还是随意口语，是用祈使句还是陈述句）到底有没有独立的影响？

答案是几乎没有。对比原始正式表达和改写成口语化表达但信息量完全一致的两个版本，八组对比里没有一组呈现出统计学意义上的显著差异，平均变化几乎为零。这意味着"怎么说"这件事对AI的理解能力影响不大，真正决定成败的是"说了什么"。

**当我们抱怨AI"听不懂人话"时，其实是我们没说到点子上**

这篇研究给普通用户和AI产品设计者都提供了一个挺具体的启发。

对用户而言，与其纠结要不要把请求写得像一份正式的技术文档，不如记住一件更简单的事：修bug时说清楚"你希望它变成什么样"，提新需求时说清楚"你为什么需要这个"。这两句话花不了几秒钟，但可能是决定AI能不能一次做对的关键。

问题是，现实中用户之所以不说这些，往往不是懒，而是自己也没想清楚。你可能自己也说不上来"应该是什么样"，或者根本没意识到这句话有这么重要。

这就给AI产品的设计留出了一个明确的方向：与其被动等待用户提供完整信息，不如主动追问。在开始动手改代码之前，先问一句"你希望修好之后是什么效果？"，或者干脆让AI自己根据代码库的上下文去推测一个合理的期望行为，先跟用户确认再动手。

当然，这项研究也留了一些没有覆盖到的角落。参与测试的模型里没有包括当前最顶尖的一批闭源系统，所以这些发现能不能完全套用到最强模型身上，还有待观察。而且整个实验都是"一次性"的对话，AI收到任务就直接开始干活，不存在中途追问澄清的环节，这跟现实中很多人机协作的多轮对话场景还是有出入的。

写在后面

读到"期望行为"和"动机"这两个字段的实验结果时，我脑子里冒出的第一个念头是：这跟我们平时给人分派任务时犯的错误其实一模一样。

很多管理者布置工作只说"这份报表有问题，改一下"，却从不说清楚改完之后应该长什么样，结果下属改了三版都不对，最后管理者自己也说不清到底哪里不满意。AI在这件事上暴露出的短板，恰好照出了人类沟通里长期存在的一个盲点：我们总以为"问题描述清楚"就够了，却常常忘了补上"期望的结果"。

另一个让我意外的细节是，环境信息和复现步骤这些看起来最"技术含量"的内容，对AI的帮助居然微乎其微。这多少打破了一种直觉，就是我们总觉得给AI喂越多细节越好，代码越具体、报错信息越完整就越容易被理解。但这项研究说的是，信息的种类比信息的数量重要得多，塞给AI一堆无关痛痒的上下文，除了让它多花点token和时间去消化，并不能真正提高它解决问题的概率。

这也许是这项研究最值得记住的一句话：不是信息越多越好，是缺的那块拼图刚好是最要命的那块。

Q&A

Q1：REALSWE-BENCH和传统的SWE-BENCH有什么区别？

A：传统SWE-BENCH的问题描述来自精心整理的GitHub issue，通常内容详细、结构完整、语言正式，而REALSWE-BENCH是根据真实用户对AI编程助手说话的方式（简短、口语化、信息少）重新构建的评测集，更贴近实际使用场景。

Q2：为什么去掉环境信息和复现步骤对AI的影响很小？

A：研究发现这类细节虽然看起来专业，但对模型理解任务核心目标的帮助有限。真正影响解决率的是"期望行为"（修bug任务）和"动机"（功能需求任务）这两类信息，缺了它们模型很容易猜错方向，而环境信息缺失时模型往往能通过代码库自行补全。

Q3：真实用户请求变简单后，AI编程模型表现会差多少？

A：研究测试了七个主流模型，发现在面对真实风格的简短请求时，平均解决率下降了6.4个百分点，同时计算成本还略有上升，说明模型需要花更多力气去猜测缺失的信息，但效果依然打了折扣。