换个会改口的需求方，编码智能体榜单就翻盘：UserSWE 的多轮实测

看编码智能体榜单选型，是很多团队的默认动作。但榜单怎么来的，很少有人追问：绝大多数编码基准给模型一道写完的完整工单，单轮交付，没有追问的机会。真实开发里的日常却是另一副样子——需求方自己也说不清，边看边改口，聊着聊着还加新活。10 月 21 日提交的 arXiv 论文 UserSWE（编号 2610.29822，八位作者）把这道落差做成了可测量的考场。

UserSWE 的构造流水线分四步：从仓库历史和既有单轮基准里挖出真实缺陷，改造成多轮任务；给模拟用户套上信息池——它只能透露池子里的信息，防止开场就把答案倒给智能体；说话方式由一条画像链驱动，转移模型用 20,859 条真实开发会话校准过，用户会补需求、会改口、会加任务；判卷则是每轮都跑测试，由两个不同模型家族的智能体写裁决并互相把关，测试结果当主证据，模型判断只兜测试罩不住的底。这套设计直指旧基准的两类误判：把错误补丁当满分，或者把正确补丁错杀。 实测盘子是 11 个编码智能体对 42 个仓库的 72 道任务，结果相当有意思：排名不是能力常数，而是交互预算的函数。只给一轮对话，Claude Fable 5.1 解出的任务最多；预算放到中间档，Claude Opus 5 在多数档位领先；放宽到八轮，GPT-6-Astra 的累计解题数反超。同一家模型在不同预算档各有优势区间，说明「一次说清就动手」和「陪着聊八轮」考的根本是两种能力。 判卷环节的设计也值得单独交待一句。每轮跑测试意味着智能体不能靠嘴皮子蒙混过关，写完就得见真章；而裁决由两个不同模型家族的智能体互相把关，等于在评测内部嵌了一道反串供机制——单一评委容易被模型间的「共同口味」带偏，跨家族互查把这种偏差压下去了。对想复现这套评测的团队来说，论文的贡献还包括这条可复制流水线本身。

这与 1895 期写过的 TiGanEval 形成互补：那篇量的是「需求侧缺口」——实测 56% 的初始指令缺关键需求，plan 模式也补不全；UserSWE 则更进一步，证明预算本身就会改变结论。对采购方来说，两篇合起来给了一个务实建议：选型时先想清楚你的使用场景更接近哪种轮数预算，再去看对应口径的榜单，单轮成绩单拿出来比高低意义有限。局限在于 72 道任务的盘子不算大，结论外推到更大规模仓库时需谨慎；模拟用户与真实需求方之间隔着多少行为差，论文未做交叉验证，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。