8 月 31 日上线的 arXiv 预印本 RealSWE 给出了一个具体的数字：把编码 Agent 的评测输入，从信息完备的 GitHub issue 换成真实用户那种短而随意的请求后，7 个模型的解决率平均下降 6.4 个百分点，降幅最高 8.0 个百分点，而且足以改变模型排名。论文更具操作性的结论是：拖累表现的并不是随意的语气，而是用户普遍省略的两个信息——bug 修复里的「期望行为」与功能请求里的「动机」。
差距不只在任务难度，而在任务如何被描述
SWE-bench 系列已经成为编码 Agent 的事实标准榜单，它的任务取自开源仓库的 GitHub issue 及对应补丁。问题在于，GitHub issue 通常是结构化、信息充分的正式报告：包含复现步骤、环境信息、期望行为，甚至给出建议方案。而真实用户与 Agent 的对话是另一回事。
RealSWE 的作者从 SWE-chat 数据集——一个包含 5,851 段真实开发者与编码 Agent 会话的记录——中筛出 718 条用户亲手写的首个请求，与 SWE-bench Verified 和 Pro 的 1,229 条问题陈述逐条对比。结论很直接：只包含问题陈述（[P]，或加上少量附加信息 [PA]）的请求，占真实用户输入的 88%，但在基准任务里只有 7%。86.8% 的真实请求是随意口吻，而基准问题 84.8%（Verified）到 100%（Pro）是正式表述。真实请求平均只携带 1.4 个信息字段，基准问题是 2.9 个。
差距集中在几个具体的字段上：复现步骤在真实请求里只出现 8.9%（基准 66.9%），环境信息 3.3%（基准 25.9%），期望行为 5.4%（基准 73.5%），动机 8.9%（基准 96.1%）。也就是说，基准几乎总是给了 Agent 一份「标准 bug 报告」，而真实用户往往只丢下一句「空输入会崩，修一下」。
6.4 个百分点，以及排名的变化
为了在「任务不变、只有表述变」的条件下测量这个差距，作者把每个基准问题改造成一个「多变体任务族」：同一个任务、同一个 gold patch，只在信息构成和语言风格上变化。全部 381 个任务族（192 个 bug 修复、189 个功能请求）最终来自 SWE-bench Verified 和 Pro 中信息字段齐全的 403 个任务，经质量筛查删去 22 个。作者用 mini-SWE-agent v2 骨架评测了 DeepSeek V4 Pro/Flash、MiMo V2.5 Pro/V2.5、Claude Haiku 4.5、Qwen3.7 Plus、MiniMax M3 共 7 个模型，每个条件跑三次取均值。
结果是：7 个模型的解决率全部下降，平均 6.4 个百分点，从 MiniMax M3 的 4.0 到 DeepSeek V4 Pro 的 8.0 不等，相对降幅在 10.3% 到 16.2% 之间。降幅并非均匀——bug 修复平均掉 9.1 个百分点，功能请求只掉 3.7 个百分点。代价也在上升：7 个模型里有 6 个在真实输入下花费更高（平均 +6.2%）且步数更多（平均 +1.8%），说明 Agent 试图用更多探索补偿缺失的信息，但没能挽回丢失的解决率。
排名并非保持不变。MiMo V2.5 Pro 从原榜单的第四名升到第二名，反超 Qwen3.7 Plus 和 DeepSeek V4 Flash，两者差距的变化 +3.7 个百分点（95% 置信区间 [+0.7, +7.3]）在统计上显著。而 MiMo V2.5 Pro 每个任务的成本约是 Qwen3.7 Plus 的四成（6.5 美分对 16.1 美分）。这意味着照单看原榜单，用户很可能选到一个「更贵却未必更强」的模型。
语气几乎无关，缺失的期望行为与动机才是关键
论文用控制实验拆开了「信息缺失」与「语气变化」两个因素，结论出乎不少人的直觉：语言风格的影响很小且随模型而异，八个风格对比中没有一个是显著的（Holm 校正后 p≥0.35）。真正起作用的是请求里装了什么，而不是怎么写的。
对 bug 修复，逐项删掉附加信息、环境信息、复现步骤，解决率平均只波动 1.8 个百分点，且没有一项删除带来显著下降；但一旦删掉「期望行为」，解决率平均掉 8.0 个百分点（7.1–8.9），对全部四个模型都显著（p<0.01），超过前三项影响之和的四倍。功能请求呈现出类似但更弱的模式：删掉「动机」平均降 3.4 个百分点，是唯一影响明显不为零的字段，其中 DeepSeek V4 Flash 掉了 7.1 个百分点，其他模型降幅不显著。
论文由此给出一个反直觉的提示：提示词的长短并不是关键。同样短的两个变体，「问题陈述 + 期望行为」比「问题陈述 + 附加信息」在 bug 修复上平均高出 3.8–6.1 个百分点。影响表现的是信息的种类，不是信息的数量。
对榜单、提示词和产品设计的含义
对一线使用者和 Agent 公司，这项研究提供了一条可直接验证的操作建议：报 bug 时写清「期望的正确行为是什么」，提功能需求时写清「为什么要做这个」。这两条恰恰是真实用户最常省略、而基准几乎总是附带的信息。反过来，Agent 产品可以在实现前主动追问这两点，或从请求和仓库上下文里推断缺失的期望行为与动机，再开始动手。
对评估的启示更直接：把 SWE-bench 分数当作产品宣传，会系统性高估 Agent 在信息稀疏的真实请求下的表现。RealSWE 的 6.4 个百分点相对温和，早前一项「Saving SWE-Bench」研究用更激进的改写方式，在 SWE-bench Verified 上观察到了 23%–36% 的相对降幅，并把部分原因归咎于公开榜单的过拟合。两篇工作的口径不同，但指向同一个判断：当前默认榜单衡量的是「Agent 面对一份好 bug 报告的能力」，而不完全是「Agent 面对一个真实用户的能力」。
边界与还无法回答的问题
RealSWE 是一篇尚未同行评审的预印本，其结论有明确的适用边界。评测是单轮的——与 SWE-bench 一致，Agent 收到一次请求后独立完成任务，没有刻画真实场景里用户通过多轮追问逐步补充信息的过程；论文自己也把「多轮澄清能否抵消信息稀疏」列为下一步工作。被测的 7 个模型不包含 GPT-5.6、Opus 5、Kimi K3 等当前在软件工程任务上领先的模型，结论未必能外推到最强模型。「真实输入」来自 SWE-chat 的第一条请求，未必覆盖所有使用习惯。6.4 个百分点是这项实验的口径，不是对「编码 Agent 真实能力」的终极裁决——但论文已经足够说明，下一次比较模型时，值得同时问一句：你给它的，是一份 issue，还是一句用户的话。