WebTestBench：这个任务的最好成绩是 F1 26.4%

如果你也在做「让 agent 读需求、自己生成测试、自己跑」这件事，那 WebTestBench 是目前离这个任务最近的一把尺子。

它量出来的成绩是：十个模型，没有一个 F1 超过 30%。

模型	F1
GPT-5.1	26.4%
MiMo-V2-Flash	25.1%
Claude Sonnet 4.5	21.9%

这个数值得先摆在前面，因为它决定了看这个方向的心态：现在不是「调优一下就能用」的阶段，是「最好的模型也才做到四分之一」的阶段。

它把任务切成了两段，正好是两级产物

大多数早期工作的做法是给 agent 一份预先写好的检查清单，让它去执行。那篇的批评很直接：这类设定依赖预定义的、僵硬的清单，限制了它在开放式开发环境里的用处。

WebTestBench 不给清单，任务分两级：

Checklist Generation —— 把用户需求拆成一条条可验证的测试项
Defect Detection —— 真去界面上交互，对每一条给出 Pass / Fail

这个切法和「文本用例 → 可运行用例」是同一个结构。它的价值在于把两段分开评分，于是「做得不好」可以被定位到底是拆得不全，还是拆对了但查不出来。

评分方式也值得抄：Coverage 量拆出来的测试项覆盖了多少条黄金标准，然后把 Fail 当作正类算 Precision / Recall / F1。把「报错」当正类是个关键选择 —— 它让误报直接压低精确率，而不是被淹没在大量正确的 Pass 里。

最有信息量的不是总分，是失败方式分成两派

那篇报告的失败模式里，这一条最该记住：模型要么误报率高达约 70%，要么召回低于 25%。原文管这叫策略分化（strategic divergence）。

翻译成人话：没有一个模型能同时做到「报得准」和「报得全」，它们各自滑向一个极端。

滑向误报的那一派：什么都觉得是 bug，报告里全是噪音
滑向漏报的那一派：几乎什么都判通过，报告干净但没用

这两种坏法在产品上的后果完全不同。误报那派会先被人骂，然后被弃用；漏报那派会安静地活很久，直到某次线上事故。而它们在总分上可能长得差不多。

所以只报一个 F1 是不够的 —— 得知道这套东西滑向哪一边。这一点直接影响 harness 该怎么设计：如果你的模型天生滑向误报，那你要加的是收紧的门；如果天生滑向漏报，加门只会让它更沉默。

另外两个数

Coverage 一致地低于 70%。 也就是说黄金标准里至少三成的测试项，agent 压根没想到。这不是判定问题，是想象力问题 —— 而它发生在第一段，之后所有的努力都建立在一个缺了三成的清单上。

用户生成内容那类任务平均 F1 只有 15.6%。 需要人类语义判断的东西（内容对不对、文案合不合适）是最难的一格。这和判定分层那件事对得上：能程序判死的和只能让模型看着说像不像话的，中间差着一个数量级的可靠性。

它点出了一个我没想到的维度

那篇特别强调了一个它认为被现有工作忽略的维度：latent logical constraints（潜在逻辑约束），举的例子是预订系统里不能重复预订同一个位置。

这类约束的特点是：需求文档里不会写，界面上也看不出来，但它一旦被违反就是严重缺陷。 它既不在 spec 的字面里，也不在 DOM 里，只存在于业务的常识中。

这一条对「从 spec 生成用例」这条路是个硬提醒：spec 里没写的东西，你的用例里也不会有。 而恰恰是这类没写的约束，出事最狠。

要覆盖它，靠读 spec 不够，得有别的信息源 —— 领域知识库、历史缺陷、或者干脆让人补。这一格我现在还没有答案。

长时程那一段的失败，和我撞的是同一堵墙

它报告的第三类失败是长时程不可靠：任务需要几十个交互回合、数百万 token，然后出现追踪失败和重复操作。

这个我有第一手对照。我自己那套东西接执行引擎跑一条四步的登录用例，实测每步一次视觉调用要 85–90 秒，一条用例十六分钟；日志显示每次请求的 prompt 都在 9000 token 上下，而其中 6144 已经命中前缀缓存 —— 也就是说瓶颈是每一步都要重新编码一张截图。

把这个数乘进去：几十个回合的任务，在本地小显存上就是几小时。「长时程不可靠」在论文里是准确率问题，在我这儿先是成本问题 —— 还没跑到不可靠，先跑不完。

这篇改变了我什么

一、评测得先于优化。 我之前那套东西攒了 66 条用例，却答不上来「这 66 条对不对」。WebTestBench 的两段式评分给了一个可抄的形状：拆解那段量 Coverage，判定那段量 Precision / Recall。没有这两个数，任何「我改进了 harness」的说法都不成立。

二、要报滑向哪边，不只报总分。 我准备在自己的报告里加一个明确的量：误报数和漏报数分开列，而不是合成一个通过率。

三、latent constraints 那一格先写进「不做」清单。 我现在没有信息源能覆盖它，与其假装能覆盖，不如明确说这类缺陷这套东西查不出来。

边界与代价

这是一个基准，不是一个产品。 基准任务的边界是人为划定的（黄金标准从哪来、Coverage 怎么算都是设计选择），真实项目的分布不一样。F1 26.4% 不代表「用 agent 做测试只能到这个水平」，只代表在这套题上如此。

匹配环节本身用的是模型。 预测项和黄金标准的对齐用 Qwen3.5-27B 来判。这是没办法的办法，但它意味着评测本身带着一层模型误差 —— 而这层误差有多大，那篇没有单独量。

没有和人工写的测试做对照。 26.4% 是高是低，需要一个基线：同样这批需求，一个人类测试工程师能做到多少？没有这个数，读者只能凭感觉判断。

WebTestBench 量的是「一次生成得怎么样」。而真实系统会做的另一件事是失败之后自己修。

那修得怎么样？下一篇那篇论文给了一组更难看的数字，其中最刺眼的是：系统为了让报告变绿，会把 expect(value).toBe(5) 改成 expect(value).toBeTruthy()，或者干脆把失败的用例删掉。