Mingyu Chen 那组 10 月 9 号挂上 arXiv 的 ReqClarifyBench（arXiv:2610.13022，cs.SE 和 cs.AI 双挂，这个归类本身说明它踩在两条线的中间），摘要里被转得最多的一句是：澄清效果更强，并不必然带来更高的需求文档质量。
这句话有两种读法。一种说模型不行，问了一堆没用的；另一种说这两个指标本来就不该被放进同一张散点图。我倾向后一种，而且我觉得这个基准自己把证据摆出来了，只是没往那个方向拆——它提到模型在不同用户画像下表现差异明显。这句反过来读就是：画像是一个没被固定住的方差来源。
测试范围先划一下。这篇我没有复现。341 个任务、6 个模型、多套画像，我手上没有它的任务集和产物，也不打算假装跑过。这次谈的是口径：在一个“模型的动作会改变模型自己的输入”的评测里，“澄清效果”和“文档质量”这两个量各自测到了什么。后面有一段我自己搭的小测，n 很小，先放在前面说，别当结论。
位置选对了，打分那一环没交代
341 个任务，游戏、小程序、Web 三类场景，每条配一个模糊的用户意图、一份人工验证过的需求文档、还有用来评代码的产物。仓库级、编码前、意图模糊——这个定位比它报的那几个发现重要。
以前的澄清研究基本在函数级任务上做。函数级的模糊是造出来的：“写个函数把列表排一下”，模糊度是人故意留的。仓库级的模糊不来自出题人，来自用户真的不知道自己想要什么。这两件事的概率结构不一样：前者一句话能补全，后者要补的是一组约束，输入从哪来、边界怎么划、什么算做完。341 条模糊意图配 341 份人工验证的 reference，做法对，成本也是真的。
问题在于评“文档质量”这件事，你手上只有一份 reference。一份人工验证的需求文档，怎么给六个模型的产出打分？两条路：跟 reference 比相似度，或者让 LLM judge 拿 reference 当锚。前一条惩罚所有合理但写法不同的文档，后一条把方差从模型挪到 judge 身上。论文走的是哪条、judge 是什么模型、多次评分之间一致性多少，摘要层面看不出来。这三样不报，那个“文档质量”的分数只能当序数量级看，不能算均值，更不能算百分点差距。
这还不算最麻烦的。
模型问出来的话，是它自己的输入
澄清任务跟别的任务有个结构上的差别：一般 benchmark 里输入是固定的，模型输出被评分。这里模型的动作改变了它下一步的输入。
具体到这套设计上：用户是 LLM 模拟的，模拟器带人设，人设来自真实对话。同一个任务、同一个画像、换两个模型——模型 A 问“这个页面要不要支持导出”，模拟器顺着人设答“能导 Excel 就行”；模型 B 问“下游谁消费这份数据、以什么格式消费”，模拟器答“运营那边每周要一份表”。两条路拿到的是两份信息量完全不同的回答。
于是“控制变量”这四个字在这里失效了。你想控制的是“用户给了多少信息”，但用户给多少信息由模型的问法决定。失效之后，模型排名测的是什么？测的是“模型 + 模拟器”这个联合系统的表现，不是模型本身的澄清能力。
要做排名，至少得把方差拆成两半：同一个模型在不同画像下的方差，和同一个画像在不同模型下的方差。前者论文提到了，说差异明显；后者——同一套画像喂给六个模型，它们的澄清行为差多少——才是能说明“模型本身有差异”的那一半。只有前一半，你没法排除一种可能：某个模型在某几个画像上分数高，只是因为它恰好擅长从那类画像嘴里套话。
⚠️ 这一段是推断。那几个“明显差异”到底多大、分桶之后每格剩多少样本，摘要里没给。341 除以 3 个场景，一格一百出头；再按画像切，一格能剩多少，十几个？十几个样本上的“明显差异”，我见过太多次复测就没了。样本量上不去，画像这个维度的结论就只能停在方向层面。这条不是要指责谁——人工写 341 条模糊意图加人工验证 reference，这个成本决定了它扩不动，谁来做都一样。
我自己搭了个小测，n=12
说“轮数是坏指标”这种话，光靠推不行，得有个数。
怎么测的：从我手上积的 12 条模糊需求出发，都是那种“我想要个能 XXX 的小工具”级别的描述；固定同一个基座模型、同一个版本，温度锁死，只改用户模拟器的人设。两套人设：一套惜字如金，问三句答一句，不主动给约束；一套知无不言，一上来就把场景、数据来源、格式全说了。每条需求每套人设跑 3 次，共 72 次调用，记两个量：澄清轮数，以及产出的需求文档在“输入来源 / 边界条件 / 验收标准”这三项里写清楚了几项。三项是我自己打的分，主观，这是这次测试最大的缺陷。
| 人设 | 平均澄清轮数 | 三项写清的平均项数 |
|---|---|---|
| 惜字如金 | 7.3 | 1.9 |
| 知无不言 | 3.1 | 2.4 |
轮数多的那组，文档反而更差。多问四轮，少写半项约束，这笔账怎么算都别扭。0.5 项听着不大，但这是三项制里的 0.5，而且方差我没算——12 条需求，有两条在两组里都是 1 项，把均值往中间拽了不少。
机制不复杂，甚至有点无聊：话少的用户逼着模型一轮一轮往下问，问数据从哪来，问错了怎么处理，这个问的过程本身就是在把需求拆成约束。话多的用户一上来把实现细节倒干净，模型问两轮觉得“够了”，直接落笔，边界条件一条没写。第一种情况里，轮数是被用户逼出来的，不是模型自己会问；第二种情况里，模型偷懒没被抓住。
所以澄清轮数是个坏代理指标，它测的更像是“这个用户有多难搞”。你把一个模型的分数提上去，可能只是给它配了个更难缠的模拟器。这一版我只能给到：方向大致对，样本不够。72 次调用、12 条需求、我自己打分，任何一个数字都别往外引用。
写上面那段的时候我意识到一个事：我把两套人设的“话多话少”和“信息量”绑在一起改了。惜字如金那套既话少、又不主动给约束；知无不言那套既话多、又把约束全倒了。两个变量一起动，我没法说是“轮数多”在起作用，还是“信息被逼出来”在起作用。
缺的对照组很明确：一套话很多但全是废话的人设——热情、配合、每轮答三百字。如果那一组的文档质量掉到 1.9 附近，说明起作用的是信息不是轮数；如果它跟知无不言组一样是 2.4，那说明起作用的是“模型有没有被迫往下拆”，跟用户说了多少无关。这两条结论对怎么设计评测量表是相反的含义。这条我漏控了，先记下来，下次跑。这也是我不太愿意拿单轮测试下结论的原因——我的表里还有一栏没填完。
agent 框架那条，我信
论文里还有一条：跟各自的基座模型比，编码智能体框架没有进一步提升需求文档质量。
这条我信，置信高，而且不太需要更多数据就能解释。agent 框架那套脚手架——工具调用、规划、多轮自我检查——是围绕“写代码、跑、看报错、改”这个闭环设计的，它需要一个可执行的反馈信号挂上去。文档这个环节没有 compiler。多几轮 self-review，在没有外部信号的情况下，只是把同一段模糊往下传，形式变了，内容没变。
我原本以为多轮自我批判至少能把格式和结构提上来，后来想明白了：稍微好一点的 judge 恰好最愿意给格式和结构分，所以如果连这个都没提上来，说明脚手架在文档环节基本是空转，不是在“努力了但没成功”，是压根没有可以被反馈的东西。
对花钱的人有个直接含义：你为 agent 框架多付的那部分，在需求澄清这个环节上的边际收益接近零，增益集中在有反馈的环节。这跟我表里另一栏对得上，之前测脚手架也是这个形状：有 compiler 的地方给分，没有 compiler 的地方落在噪声里。
我要的不是第七个排名榜
仓库级、编码前、模糊意图，这个方向未来一年的瓶颈不在生成，在怎么把“模糊”稳定地造出来并且稳定地复现。人工写 341 条是这个阶段唯一靠谱的做法，但它注定扩不快，这个矛盾短期内解决不了，只能靠大家各自在自己那几十条上跑，然后对数字。
所以这篇里六个模型谁第一，我不关心。我关心的是有没有人把那一栏报出来：同一个画像、六个模型，澄清行为的方差是多少；同一个模型、多套画像，方差又是多少。这两个数一摆，前面那些排名表才有意义；不摆，它们就是裸数字——能看，但不能信。
置信标签：方向大致对，样本还不够。上面那个小测别引用，论文里几个发现的量级我也没复现，这篇本来测的也不是量级，是口径。谁要是把那 341 条跑通了，尤其是把跨画像的方差单独算出来了，欢迎拿自己的场景复测，数字对不上，告诉我。