v0.3 · 验证合约设计与九个维度

系列进行中 把「验证」拆成九个正交维度，逐个子版本收敛

这个系列做什么

verification contract design · sub-versions v0.3.x

v0.3 系列围绕一个问题：一份好的验证合约到底该规定什么、规定到多硬。它把「验证」拆成九个正交维度（谁来验证、何时验、验什么、喂什么、判定形式、冲突处理、修复纪律、回归防护、何时停止），每个子版本在 case 上做受控对比，用数据逐条收敛这些维度的取舍。下面先看九个维度的拆分与建议，再进入各子版本的具体实验。

v0.3.1.preview · Case5 六版本验证对比

case5 · C0–C5 × 3 replicates · 18/18 完成 · 最优 C3 4.283，C5 pass@4 3/3
查看实验对比 →

九个验证维度

跨 V0–V4 / W 系列的设计张力与建议，用于收敛新版验证合约

把「验证」拆成九个正交维度，逐条对照历史各版本的做法、数据信号与取舍。总控信号是第十条元维度：验证越多分越低，甜点区是「轻而准 + 明确收手」，而不是「严而全」。数据来自 v0.3.1.preview 及更早的 W 系列。

一 · 谁来验证 · 权威归属（WHO）必留 · 零成本

核心问题：验证结论算谁的？agent 自己看一眼算不算？

所有版本共识：必须 CallMLLM，外部，不能拿自评当验证。W1 多加两点：①验证器是独立上下文（防 agent 把自己的上文当依据）；②自评是「输入」不是「验证」——不禁止 agent 观察，而是把它降级成喂给外部的材料。

张力：这是整个体系的地基。case5 老 bug 的病根就是 agent 用自评推翻了外部。
建议：保留（外部 + 独立上下文 + 自评降级为输入）。几乎零成本，最该保留的维度。
二 · 什么时候验证（WHEN）留两级 · 局部要轻

核心问题：验证是最终一锤，还是过程中持续做？

V0 只说「先空间后视觉」，没分层。V1 起两级：局部/聚焦验证（中间产物、关键 claim）+ checkpoint 全面验证，一直沿用到 W。V1 专门写了 focused validate 的 WHEN 清单（下游依赖、抽取了 bbox、绑定变化、工具返回重要结果…），W 系列压成一句「实质问题/不确定/刚改动时」。

张力：局部验证给多细？V1 列 7 种触发场景（重），W 压成一句（轻）。数据看，轻的反而好（C3/W1 验得少却分高）。
建议：保留两级结构，但局部验证要轻——V1 那种重清单没赢。
三 · 验证什么 · 检查维度（WHAT TO CHECK）留全维度 · 几何待议

核心问题：全面验证时，眼睛盯哪些方面？

历史都覆盖：空间对应（几何/漂移/边界/对齐/间距/包含）、文字（裁切/重叠/溢出/换行）、内容与元素存在性、外观（字体/颜色/描边/背景/结构）。V1 拆成「先空间闭环（<5px）→ 后视觉」两阶段；V2/W 合并进一次全面验证。

关键缺口：v-diff 的 gate 有确定性几何（grounding→绑 DOM→算 bbox，连 font-size 都卡），而所有 prompt 版本都没有——全靠模型「看像不像」。这是 prompt 路线相对 harness gate 最大的能力空洞。
待议：要不要在 prompt 里更硬地要求「建立元素↔区域对应并用坐标算差」，逼近 gate 的确定性？还是接受这块交给模型？
四 · 给验证器什么输入（WHAT TO FEED）必留 · 核心诉求

核心问题：验证时附什么证据？

V1/V2 都说可附代码、测量、绑定，但重心还是两张图。W1 显式强调「不限于图片」——可给 HTML/CSS/JS、DOM、裁图。配套要求：标明每个输入的角色和版本，且必须对应最新 artifact（别拿旧 render 验新代码）。

建议：保留（不限图片）。零成本增益，是你最看重的维度。
五 · 判定的形式（VERDICT FORMAT）必留 · 对症老 bug

核心问题：验证结论怎么表达，才能防 agent 打太极？

V0–V3：自然语言 PASS/FAIL/INSUFFICIENT。V4 起：强制首行 VERDICT: PASS/FAIL/INSUFFICIENT，其他一律按 INSUFFICIENT，即使语气正面。配套：verdict 归外部，agent 无权重新解释/降级/推翻。

建议：保留（首行契约 + 外部权威）。这是最对症 case5 老 bug 的一刀，数据上 C5 最稳 3/3。
六 · agent 与 verifier 冲突怎么办（CONFLICT）留 · 必配停止上限

核心问题：agent 有具体反证、认为 verifier 错了，怎么办？

V4：「若认为 verdict 有误，附反证再问一次全面 checkpoint」，只有新的外部 PASS 才改状态。V5：更精细——争议 FAIL 时，不盲改也不自清，发起一次独立 adjudication 复裁，以复裁为准。W1：把 V5 精神提纯成一节「独立复裁打破僵局」，去掉双 checkpoint 包袱。

张力（重要）：冲突机制越强，越容易诱发验证爆炸——agent 反复申诉、反复验。C5 验 16 次、改 33 版、花 $26，一部分就来自这。冲突机制是「防自我说服」和「防验证失控」之间走钢丝。
建议：保留（独立复裁），但必须配停止上限（见第九条）。
七 · 失败后怎么修（REPAIR DISCIPLINE）可不加 · 留白更好

核心问题：确认了多个缺陷，一把梭还是一个一个修？

V0–V5、W1：留白，不规定修复顺序。V6 / W3：原子化——按因果簇一次修一个，修完就地复验再修下一个，禁止打包大改。

数据：W3（原子）4.05 < W1（留白）4.14，且更贵。留白反而好——agent 自己决定怎么修比被约束着修更有效（至少 case5）。
建议：可以不加，或只作为可选变量。
八 · 迭代闭环 · 回归防护（RE-VERIFICATION）只留温和版

核心问题：改了 A 可能弄坏 B，每次验证要不要全查？

V2/W1：证据时效原则——「编辑作废其影响部分的旧证据，重渲染重验」（增量思路）。W2：全量重验——每次全面验证从零重查整个 artifact，不信任历史通过。v-diff gate 更进一步：问题库跨 epoch 累积，覆盖只增不减。

数据：W2（全量）3.96，最贵（$15）最差——全量重验逼 agent 反复推翻自己，负收益。
建议：全量重验不加；但「增量 + 编辑作废旧证据」这条温和版要留。
九 · 什么时候停止（STOP / COMPLETION）去双 CP · 加验证预算

核心问题：什么条件算完成？怎么防止停不下来？

完成条件：所有版本都要求「最后一次验证在最后一次实质编辑之后 + 无未解决显著失败」。V3/V4 加了双 checkpoint 闭环（连续两次独立通过）——已明确不要，不优雅。

所有版本都缺的东西：显式的「验证预算/停止上限」。没有任何一版写「验证最多 N 次」或「没有新的确认缺陷就必须停」。这正是 C5/W2 验证爆炸失控的结构性原因。
建议：去掉双 checkpoint；加验证预算。这可能是新版最该补的空白——一条明确的「收手」规则。
元维度 · 强度总控C0(0 验证) 3.91 → C3(1.3 次) 4.28 → W1(1.7) 4.14 → W3(4.7) 4.05 → W2(10) 3.96；C5(16 次) 4.21 但 $26/29 分钟。验证越多分越低（除 C5 靠蛮力换稳定）。甜点区是「轻验证、及时收手」。新版的隐含目标应该是精准触发 + 明确停止，而不是堆规则。