核心验证方法 V1
来源：1-Docs/core-verification-method/v1/verification-method-v1.md先把 verification 拆成四个核心问题
V1 不是先去实现一个 verifier，而是给 pdf-image -> html
的实验建立可复用的记录框架：每次尝试都要说明什么时候验证、验证什么、怎么验证，以及验证到底带来了什么效果。
不验证、main agent 自己决定、每轮结束强制验证、关键中间节点验证，或由 verifier-controller 自适应决定。
整体视觉相似、text fidelity、layout skeleton、element binding、region-level rubric，或由 verifier 自己规划 tests。
self-review、same-model verifier subagent、independent model、OCR / DOM / VDiff / tool hybrid，或 parallel v-tests。
看 final quality、issue fix rate、early quit rate、regression rate、cost，以及 feedback 的 precision / actionability。
V1 的用途
这页是第一版方法归档，不是最终实验实现。它把 L0/L1/L2/L3/L8/L9
作为可独立管理的条件，先固定“如何描述一个 verification experiment”，方便后续 V2/V3、条件重叠、结果复用和替换。
- 每个实验结果必须绑定
method_version + condition_id - 每个
L*都对应独立条件卡，可以复用、替换或标记 overlap - 先把研究问题、控制轴和记录字段讲清楚，再进入 runner / verifier 实现
- 不在 V1 文档里固化最终 verifier prompt 或 backend
- 不把所有维度一次性做 factorial ablation
- 不把 VDiff-rich run 直接作为论文主条件，先作为内部 reference
先分清两个角色
docs 里最关键的提醒是：verifier subagent 和 verification controller
不是同一个概念。前者执行或规划检查，后者控制验证策略和 repair loop。
负责看 source、render、crop、DOM、OCR、code 或 VDiff evidence，输出 evidence-grounded failure report。 在更强设置里，它也可以主动规划局部 tests。
负责决定何时验证、是否强制验证、失败后是否阻止结束、如何把 feedback 送回 generator， 以及是否继续 repair。
更干净的记录轴
每次尽量固定其他轴，只改变一个关键变量C0无显式 in-loop verifier，对应强 baselineC1main agent 可选调用 verifier subagentC2harness / controller 每轮强制调用同一个 verifierC3verifier-controller 决定 when / what / continue repair
S1global critic，粗粒度视觉 critique / scoreS2structured v-tests，输出 text / layout / binding / region failuresS3verifier-planned v-tests，独立规划 evidence pathS4VDiff rich-evidence internal reference，用来理解上限和失败类型
Round-level vs Intermediate
在完整 answer.html candidate 和 render screenshot 已经产生后验证。
适合 first candidate check、repair round check 和 final gate。
在生成过程中验证局部计划、区域理解、文本、layout、binding 或 partial artifact。 目标是在错误结构被固化前更早发现问题。
V1 主线梯度
线性 ladder 仍然保留，但它只是主线视图。真正记录时，要同时写清楚四个问题和两条控制轴。
V1 条件表
每个条件都可独立 tag、复用、替换| 条件 | 谁决定何时验证 | 谁决定验证什么 | 谁决定怎么验证 | Loop 控制 | V1 作用 |
|---|---|---|---|---|---|
| L0 Pure API | 无 | 无 | 无 | 无 | 裸模型一次生成能力锚点 |
| L1 Native Claude SDK | main agent self-directed | main agent self-directed | main agent tools | main agent | 强 SDK / Claude Code-style harness baseline |
| L2 Round-forced verifier | harness | main agent | verifier executes only | harness 控制调用时机；main agent 负责 repair | 完整 candidate 后的 round-level verification baseline |
| L3 Main-agent-orchestrated verifier | main agent | main agent | verifier executes only | main agent | main-agent-controlled verifier baseline |
| L8 Sub-detail verifier agent | main agent | verifier subagent | verifier plans and executes | main agent | verifier-planned detail / intermediate condition |
| L9 Full verifier-controller | verifier-controller | verifier-controller | controller / delegated verifier agents | verifier-controller | 最强 exploratory controller condition |
每次 run 的记录方式
我建议后续每条实验记录都先回答四问，再写固定轴、变化轴和 outcome。这样即使条件有 overlap，也能快速看出这次 run 真正改变了什么。
用短句写清 when / what / how / effect，避免只写一个 L 编号导致实验含义不清。
例如固定同一个 structured verifier，只比较 optional use 和 forced use。
同时记录质量、修复率、early quit、regression、cost，以及 feedback 是否能驱动下一步修复。
method_version = v1
primary_condition_id = L*
condition_name = ...
secondary_condition_tags = [...]
control_axis = C*
signal_axis = S*v2/conditions/L2-...
supersedes: v1/L2
overlaps_with: v1/L3
fixed_axes = [...]
changed_axis = ...暂不实现
当前页面只做归档和表达思路：暂不开始 verifier 实现、runner 改造、prompt 固化或具体实验执行。
下一步实验计划应按每个具体 L* 条件管理，同时保留四问、控制轴和 signal 轴，方便复用、替换和比较。