PostHog ReviewHog 评估实验中的运行报告深度解析：以 `A-sonnet5-xhigh-1` 为例的 Reviewer 模型质量评测方法

PostHog ReviewHog 评估实验中的运行报告深度解析：以A-sonnet5-xhigh-1为例的 Reviewer 模型质量评测方法

【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog

导读

本文围绕 PostHog 开源仓库中 products/review_hog/eval/experiments/2026-07-reviewer-model-glm52/runs/A-sonnet5-xhigh-1.md 这一份完整的 reviewer 质量评估运行报告展开，系统讲解 ReviewHog 自动化 PR 审查系统如何设计并执行「评审模型对比实验」、如何解读一份 run dump 中的每个指标（漏斗、缓存感知成本、阶段耗时、单审查单元分解），以及如何通过 validator 判定 + 对抗式验证来从噪声中沉淀真正值得修复的问题。读者读完后，将能够独立读懂该实验目录下任意一份*-xhigh-*.md运行报告，理解其成本核算方法与发现判定标准，并掌握在本地复现此类评估运行的关键步骤。

一、实验背景：为什么需要一个「运行报告」

ReviewHog（products/review_hog）是 PostHog 的自动化 GitHub PR 代码审查器：拉取 PR → 切分 chunk → 按视角（perspective）并行审查 → 合并去重 → 验证 → 渲染并发布审查评论。其审查质量直接取决于执行「视角审查」（perspective review）的 LLM 模型。

2026-07 的2026-07-reviewer-model-glm52实验要回答的核心问题是（见 PLAN.md）：

@cf/zai-org/glm-5.2是否比claude-sonnet-5更擅长应用 ReviewHog 的审查视角？其余条件全部保持恒定。

实验设计为 A/B 双臂：A 臂（基线 = 生产配置）为claude-sonnet-5@xhigh，B 臂为@cf/zai-org/glm-5.2@MAX。为了确保可比性，一批变量被刻意冻结：验证阶段统一用claude-opus-4-8@ xhigh；chunking / 视角选择 / 去重等一次性调用统一用claude-sonnet-5@ xhigh；所有提示与技能（skill）重置为默认；目标 PR（PostHog/posthog#72680）在实验期间冻结在 head1341596e，不做任何推送。每轮运行结束后，通过 dump_result.py 把数据库中的ReviewReport及其 artefact 导出为一份 Markdown 运行报告——即本文解析的这份A-sonnet5-xhigh-1.md。

注意：报告多处注明 PR head1341596e不在当前 checkout 中（如 migration 0019、queue_inbox_pr_review等改动均不存在），因此对 PR 内容的分析只能基于基线代码；这一点在解读「发现的判定」部分时需要记住。

二、Config snapshot：一次运行在什么配置下发生

运行报告头部是「Config snapshot」，它声明了本次运行的模型与管线常量：

• runtime / model / effort：claude/claude-sonnet-5/xhigh—— 即 A 臂的基线配置。在真实代码中，这些值对应 constants.py 中的REVIEW_RUNTIME_ADAPTER/REVIEW_MODEL/REVIEW_REASONING_EFFORT常量（当前 master 上这些常量已是实验结论落地后的gpt-5.6-sol，说明实验完成后默认评审模型已被替换）。
• single-chunk gate / chunk target / soft-max additions = 400 / 300 / 600—— 对应 constants.py 中的SINGLE_CHUNK_GATE_ADDITIONS（≤400 行新增走单 chunk 路径，不调用 chunking LLM）、CHUNK_TARGET_ADDITIONS（LLM 切分器瞄准的每 chunk 新增行数）、CHUNK_SOFT_MAX_ADDITIONS（软上限，不强制）。本报告最终产出 4 个 chunk，说明该 PR（约 742 行可审查新增）走的是 LLM 语义切分路径。

实验还记录了每条运行的环境前置条件（PLAN.md Preflight 章节）：Temporal worker 与 backend 进程运行中、三个 ngrok 隧道（django→:8010、gateway→:3308、mcp→:8787）可用、网关 allowlist 已加入 GLM 模型、本地$ai_generation遥测链路打通（LLM_GATEWAY_POSTHOG_AI_LANE_CAPTURE=false）等——这些是任何本地评估运行的硬前提。

三、Funnel & cost：从原始问题到有效发现的数量漏斗

报告的「Funnel & cost」表给出了本次运行的核心产出：

漏斗含义（对应 ARCHITECTURE.md 的流水线）：

1. raw issues（25）：所有(perspective|blind-spot) × chunk沙箱审查单元产出的原始问题总数。
2. after dedup（20）：经过 combine + scope-clean + 去重后保留的问题。去重先跑确定性位置预过滤（_select_dedup_candidates，只有文件相同且行区间重叠的问题才可能重复），碰撞候选才交给 LLM 去重调用。
3. passed validator（3）：通过 validator（claude-opus-4-8@ xhigh 的按 chunk 多轮验证会话）判定为is_valid的问题。

报告特别强调：review units = 每个 (perspective|blind-spot × chunk) 沙箱审查单元 = 模型保持恒定的成本代理。A1 共运行 13 个单元——3 个视角 × 3 个 chunk（9 个视角单元）+ 4 个 blind-spot 单元（每个 chunk 一个）。

3.1 缓存感知成本（cache-aware spend）：naive 计价的 4.4 倍虚高

报告的第二张表是「Cache-aware spend」，这是本实验成本核算的核心方法。它按model × stage统计每次生成的 token 拆分：

关键事实与解读：

• true $= 列表价回算：fresh input × 1.0 + cache write × 1.25 + cache read × 0.1 + output。该公式在 dump_result.py 的_spend_report中实现，每个 gen 的输入 token 被拆成fresh = input − read − write三部分分别计价。
• gw $= 网关$ai_total_cost_usd（LiteLLM 计算）。本次两种口径完全一致（Δ +0.0%），互相交叉验证通过。
• naive 方法（全部 prompt token 按输入价计价）为 $203.82，是真实成本的 4.4 倍——报告明确警告「never gate on it」。原因在于$ai_input_tokens包含 cache read/write，而 cache read 只按 0.1× 计价，$53.7M 的 cache read 实际只值约 $17.84。这是 POTENTIAL_EXPERIMENTS.md 中反复强调的「scary input token 数字 ~90% 是廉价缓存读取」的具体实例。
• unpriced 模型：@cf/zai-org/glm-5.2只有 1 次 gen（other阶段），网关对其计价为 $0.00，true $总计中排除该模型。这正是 FINAL_REPORT.md 提到的「GLM 成本没有网关定价」问题的表现——GLM 臂的成本只能按 token 数 × LiteLLM CF 定价手工推算。
• 21 个 gen 的 prompt 超过 20 万 token（_LONG_CTX_TOKENS阈值），网关对这组模型按平价格计价，故两列都不含长上下文溢价——该列只是诊断计数，不是定价输入。
• 跨端交叉校验：输入侧（fresh + cache write + cache read）$35.4477，其中 cache read $17.8399、cache write $16.2597、fresh（推导）$1.3481，输出侧 $11.0685——与true $逐项对账一致（Δ +0.0%）。

这些数据的来源是本地 ClickHouse 的$ai_generation事件（dump_result.py 的_spend_rowsSQL 查询FROM events WHERE event = '$ai_generation'），按task_title中的[sandbox_prompt:<step>]前缀归类到 review / blind-spot / validation / chunking / dedup / warmup 各阶段。

3.2 Turn-1 缓存读取：跨沙箱缓存共享的「绊线」

报告的第三张表列出每个沙箱单元第一轮 gen 的 cache read / cache write 与模型列表，其用途是探测跨沙箱缓存共享是否存在：

• 表中 18 个单元里 14 个 turn-1 cache_read > 0（14/18），说明多数单元的第一轮 prompt 命中了其他沙箱写入的缓存前缀。
• 3 个单元（…33a62b9f、…a7859b17、…06074ce8）标记为⚠️SWITCHED——会话中途从claude-sonnet-5切到了claude-opus-4-8。这是 Claude SDK 的fallbackModel「过载救援」机制导致的（FINAL_REPORT.md 称 Sonnet 臂约 20% 的 finder gens 被 Opus 4.8 污染）。对这些单元，缓存共享与成本钉扎（cost pinning）都是失效的，dump 工具会在模型集合 >1 时自动打上 SWITCHED 标记（_spend_report中len(models) > 1的判断）。
• 报告提醒：「report the distribution, not a median」——即不要用中位数概括这个分布，而应报告有多少单元命中了缓存、多少发生了切换。

四、Stage timing：哪个阶段吃掉了墙钟时间

「Stage timing」表按 artefactcreated_at推导各阶段墙钟耗时（只有在全新、非恢复（non-resumed）的运行中才有意义）：

• Review stage total（selection → last finder unit，wave + blind-spot）= 44m38s——这是报告明确标注的「reviewer-model speed comparison number」，即比较不同评审模型速度的头号指标。GLM 臂的对应数字是 42m41s / 65m39s，Opus 4.8 臂则只要 24–26 分钟（见 FINAL_REPORT.md）。
• 阶段耗时来自 artefact 的created_at（dump_result.py 的_stage_secs），因此恢复（resume）过的运行会因复用旧 artefact 而扭曲耗时数据。
• 本次运行总墙钟 4044 秒（67.4 分钟）。其中审查 + 验证占绝大多数时间，符合 POTENTIAL_EXPERIMENTS.md 中「review + blind-spot ≈ 80% 运行成本」的经验结论。

五、Chunking 与 Per-review-unit breakdown：审查工作量的分解

5.1 本次的 4 个 chunk

报告列出本次运行实际采用的 4 个 chunk（该切分随后被固定为整个实验的 pinned chunks，供其余 7 次运行复用）：

• chunk 1（8 文件）：products/review_hog/backend/models.py、migration0019_reviewusersettings_stamphog_review_inbox_prs.py、backend/api/settings.py、backend/receivers.py，以及 review_hog 前端与 MCP 的生成类型文件（CodeReviewScene.tsx、api.schemas.ts、api.zod.ts、services/mcp/src/api/generated.ts）
• chunk 2（8 文件）：stamphog 后端 facade（facade/api.py、facade/inbox_hooks.py）、任务（tasks/tasks.py、temporal/activities.py、logic/reviewer.py）、tasks 产品 facade（facade/api.py、facade/contracts.py）与tach.toml
• chunk 3（4 文件）：tools/pr-approval-agent/下的review_pr.py、review_local.py、reviewer.py、version.py（注：该目录不在当前 checkout 中）
• chunk 4（2 文件）：products/stamphog/AGENTS.md与README.md

5.2 13 个审查单元如何组成

「Per-review-unit breakdown」把 13 个单元逐一列明：pass 1/2/3 分别对应三个视角（contracts-security、logic-correctness、performance-reliability）在 chunk 1–3 上的 9 个单元，pass 1000 是 blind-spots-general 在每个 chunk（1–4）上的 4 个盲区扫描单元。这与 constants.py 中BLIND_SPOT_PASS_NUMBER = 1000的保留 pass 号约定完全吻合——盲区单元使用远高于任何视角枚举的固定 pass 号，确保持久化的(pass, chunk)恢复键不会与视角 wave 冲突。视角与盲区技能分别位于 skills/ 目录（如review-hog-perspective-contracts-security/SKILL.md、review-hog-blind-spots-general/SKILL.md）。

六、Findings with validator verdict：本报告最有价值的部分

报告主体是 15 条去重后的发现（findings），每条都附带完整的 Problem → Suggestion → Validator 三段式结构。最终判定为 3 条✅ VALID、13 条❌ dismissed——与漏斗中「passed validator: 3」吻合。

6.1 两条 VALID 发现（安全/性能）

发现一（security，must_fix → validator 降级 should_fix）：find_signal_implementation_run在底层任务运行被取消/失败或任务被删除后，仍继续授予 self-driving 豁免。

• Problem：stamphog 的 webhook 豁免路径（_inbox_rereview_carve_out）把find_signal_implementation_run当作唯一的正向识别检查，用于跳过 bot 作者拒绝、draft 前置、review-mode 与作者写权限四道门。但它委托的find_task_run（webhooks.py）的pr_url分支「偏好非终止运行，但会回退到终止运行」（order_by('terminal_rank', '-created_at').first()），且所有分支都不过滤task.deleted。取消（CANCELLED/FAILED）或软删除任务只翻转 DB 标志、拆除沙箱，没有任何代码路径去关闭对应的 GitHub PR。因此团队取消/删除一个失控的 self-driving 任务后，只要其 bot PR 仍在 GitHub 上开着，之后的任何 push（synchronize/reopened/retarget）仍会命中find_signal_implementation_run，stamphog 会重新套上全套豁免——包括真实批准一个其背后自动化已被明确停止的 PR。
• Suggestion：在正向识别检查中排除取消/失败运行与已删除任务，例如在返回前增加run.status in (CANCELLED, FAILED) or task.deleted判断；COMPLETED 运行仍可匹配（已合并 self-driving PR 的后续合法 push 是 leg-2 的预期场景）。
• Validator 判定（VALID，降级 should_fix）：逐条核验了find_task_run的三个分支、facade 门（api.py:504-516）、唯一调用方_inbox_rereview_carve_out（tasks.py:144-215）、取消/软删除路径与 webhook 测试。确认pr_url分支在无活跃运行时会返回终止运行（test_pr_url_prefers_active_run_over_terminal只断言了「偏好」），_TERMINAL_RUN_STATUSES= COMPLETED/FAILED/CANCELLED，Task.soft_delete()只翻 DB 标志（models.py:445-448）。结论：这是真实的授权作用域缺口，达到保留标准；但正向识别无法伪造（需要真实携带 signal-report、非 internal、绑定该 PR 且同 team 的运行），因此不是可跨租户利用的关键漏洞，从 must_fix 降为 should_fix。

发现二（performance，consider）：carve-out 对非 self-driving 的 bot PR 触发了posthog_task_run.branch的无索引顺序扫描。

• Problem：find_signal_implementation_run调用find_task_run(pr_url=…, branch=head_branch, repository=…)。pr_url分支由函数索引task_run_output_pr_url_idx服务，但未命中时回退到纯 branch 查询（filter(branch=…, task__repository__iexact=…, state__wizard_head_branch__isnull=True)）——TaskRun.branch与大小写不敏感的task__repository都没有索引（TaskRun.Meta.indexes只覆盖output__pr_url、state__wizard_head_branch、created_at、task+created_at、team+stage+task）。真正的 self-driving PR 在索引的pr_url分支命中；该扫描恰好被不匹配的 bot PR（dependabot/renovate 的 synchronize 事件）命中，永不匹配、纯属浪费。
• Suggestion：self-driving 运行由已索引的output.pr_url正向标识，carve-out 可传head_branch=None跳过纯 branch 分支；若保留回退，则为TaskRun.branch加作用域索引。
• Validator 判定（VALID，维持 consider）：核验了TaskRun.Meta.indexes（models.py:1147-1174）、branch 分支查询（webhooks.py:64-78）与调用链。确认不存在服务该查询的索引、iexactjoin 无法使用 btree，且该扫描正可被描述的 bot 场景到达。这是「无界增长表上的可达缺失索引顺序扫描」，有具体触发条件（stamphog 仓库上的日常 dependabot/renovate synchronize）和廉价修复，但为潜在（latent）问题且是既有 backstop 路径，consider 评级恰当。

发现三（security，should_fix → validator 降级 consider）：receiver leg 在零正向 PR 识别（不查 bot 作者、不复查任务关联）的情况下发布真实批准。

• Problem：process_inbox_pr_review是初始审查 leg：抓取调用方提供的pr_url处的 PR → 盖上output={"inbox_review": …}的 provenance → 启动审查 workflow。该 provenance 在引擎中翻转self_driving_review=True（放宽 bot 拒绝与 draft 前置），且此 leg 直接启动 workflow、不经过process_pull_request_event，因此 per-reporeview_mode门与作者写权限门完全不被应用。它唯一的保护是解析该 PR 仓库的 synced+enabledStamphogRepoConfig。与兄弟 webhook leg（_inbox_rereview_carve_out，会检查_is_bot_authored、复查find_signal_implementation_run、检查 fork 安全）相比，此 leg 缺失全部正向识别。
• Suggestion：在授予 self-driving 豁免前镜像 webhook leg 的正向识别——至少抓取 PR 后if not _is_bot_authored(pr): return，更好的是复查调用方断言的关联。
• Validator 判定（VALID，降级 consider）：确认 receiver leg 确实不做任何 PR 身份验证，且其pr_url直接读自TaskRun.output["pr_url"]（receivers.py:93），非 bot PR URL 进入该字段的唯一方式是 tasks webhook backstop_record_run_pr_url（webhooks.py:212）的上游误绑定——但该路径有 fork 保护（is_internal_branch）且只写一次。正常不变量（self-driving 运行记录自己的 bot PR）成立，所以被取回的 PR 在每次普通运行中都是 bot 作者。有害路径是低概率、多条件的边缘情形，但廉价修复 + 严重最坏情况使其值得保留在记录中，而非彻底丢弃。

6.2 13 条被驳回的发现：precision-over-recall 的判定标准

其余 13 条发现全部被 validator 驳回，驳回理由高度一致，构成理解 ReviewHog validator 判定哲学的窗口：

• 「今天无害 / 不可达」类：如has_reviewable_repo_config缺provider="github"过滤（api.py:120-124）——validator 核实 GitHub 是唯一已实现 provider，非 github 行永远无法满足其门槛条件（installation_id与connected_by_user_id只由 GitHub App 流程写入）；stamphog_connected报告项目级而非仓库级连通性——settings 端点在渲染时没有「该仓库」的上下文，且真实 per-PR 门已经是 per-repository 的（StamphogRepoConfig唯一键(team_id, repository)）。
• 「上游已处理」类：如_format_self_driving不交叉核对pr.author_is_bot——validator 确认self_driving只从 inbox provenance 派生（activities.py:451），webhook leg 非 bot 作者拒绝盖章（tasks.py:169early return），引擎的is_bot_author（github.py:79）是 facade_is_bot_authored的严格超集，不存在可达的「self_driving=True + 人类作者」路径；bool()强制转换问题——产端是类型化bool+json.dumps，"false"字符串在任何可达路径下都不会出现；_attach_familiarity未被 self_driving 守卫——服务端在 self-driving 场景下显式把author_pr_numbers置为[]（activities.py:237-238）。
• 「文档措辞偏好」类：如 AGENTS.md 的两条文档交叉引用建议——validator 核实 carve-out 段落已完整记录运行时分歧、Engine parity 段落本 PR 未改动，纯属「文档导航便利性」，不属于正确性/安全/数据丢失/契约/性能/可靠性缺陷。
• 「类型注解收紧」类：signal_report_id: strvsAny的宽松类型——validator 核实SignalReport extends UUIDModel、report_id是 UUID FK，Django 的UUIDField在查询准备时对 str 与 UUID 一视同仁，产出相同 SQL、匹配相同行，且失败方向是 fail-closed。
• 「防御性偏执」类：transaction.on_commit双回调队列耦合——_start_review的唯一现实失败操作已在 try/except 内，队列外只剩缓存于sys.modules的延迟 import；deferred import 位于 try 外——这是_start_review已确立的既有约定，且 on_commit 在事务提交后运行，import 失败无回滚/数据损失。

这 13 条驳回正是 validator 依据 review-hog-validation-criteria 技能中的判定标准执行的结果：保留真实的用户可感正确性/安全/数据丢失/契约/性能问题，丢弃过度工程、投机、防御性偏执、never-gonna-happen 边缘与风格问题——即precision over recall。

6.3 判定的可信度：对抗式验证协议

需要强调的是，报告内的 validator 判定只是管线内的一层；FINAL_REPORT.md 记录了实验的完整验证协议：

• 每条去重后的发现（实验总计 73 条）都由独立的对抗式验证 agent针对真实 PR worktree（head1341596e）逐一核验，refutation-first（先尝试推翻）。
• 跨集合聚类器把 73 条发现归并为 53 个底层问题簇（后续轮次扩至 74–76）。
• 三位盲审（blind judges）分别从 recall-reliability / precision / impact 三个透镜对匿名模型打分，权重倾向「可重复捕获」而非单次运气。
• 关键校准结论：管线 validator 的选择与独立验证只部分重合——A1 的 validator 只放行了 3 条，独立验证确认了 7 条真实问题。这说明 validator 偏严，也解释了为什么实验结论要依赖独立验证而非管线 validator 的通过数。

七、从这份报告到实验结论：Sonnet 5 为什么留任

虽然本文主体是 A1 这份单运行报告，但它所属实验的结论（FINAL_REPORT.md）可以帮你理解这份报告在整体证据链中的位置：

• A/B 结论：GLM 5.2 不是「更好」，而是「不同」——盲审面板 2:1 倾向 GLM（recall-reliability 与 impact），但代价是约 1.6× 的精度差距（Sonnet 31.8% vs GLM 19.4%）、80% 的噪声率与 40–100% 更高的 finder 阶段成本（Cloudflare 路径无 prompt 缓存）。
• 后续扩展：实验随后扩展到 4-way（gpt-5.5、opus-4-8）、round 4（gpt-5.6-luna/terra）、round 5（gpt-5.6-sol + Sonnet 稳定性复核）、round 6（带注入记忆的顺序 Sol）。Sonnet 5 四次运行每次都恰好验证 7 条真实发现（7/20、7/24、7/23、7/26），精度等级稳定，recall 王座未被撼动——「不是运气」。
• 最终推荐：claude-sonnet-5@ xhigh 继续担任默认评审模型；gpt-5.6-sol（~$11/run、~8 分钟干净审查）成为第二意见 lens 的候选，其顺序轮次在管线原生记忆（<already_covered_findings_for_chunk>注入）下能叠加而非重复。
• 实验还顺带发现了多个真实产品 bug（独立于胜负）：poll_for_turn不把stopReason:"refusal"视为终止导致 30 分钟挂起、Codex MCP 闪断导致无技能审查、Codex 缓存遥测缺口、120MB handoff 包上传失败等，其中 refusal fail-fast 修复已落地并有回归测试。

八、如何复现一次同类评估运行

结合 PLAN.md 的 per-run 循环与 ARCHITECTURE.md 的本地运行说明，一次评估运行的完整流程是：

1. 设置臂常量：修改backend/reviewer/constants.py的REVIEW_MODEL/REVIEW_REASONING_EFFORT（实验期 hack，评估后回滚到 Sonnet 基线）；确认 temporal-worker 已热重载（nodemon监听products/**/*.py），绝不在飞行中翻转常量。
2. 记录起点：date +%s得到RUN_START_EPOCH（dump 脚本据此划定$ai_generation时间窗口）。
3. 运行审查：

   flox activate -- bash -c "SANDBOX_PROVIDER=MODAL_DOCKER DJANGO_SETTINGS_MODULE=posthog.settings \ python manage.py run_review --pr-url https://github.com/PostHog/posthog/pull/72680 --team-id 1 --user-id 1"

   --pr-url/--team-id/--user-id三个参数必填；评估运行不使用--publish（零 GitHub 写入）。

4. 导出 dump：

   LABEL=<label> RUN_SECONDS=<s> RUN_START_EPOCH=<epoch> \ OUT_DIR=products/review_hog/eval/experiments/<exp>/runs \ python manage.py shell -c "exec(open('products/review_hog/eval/scripts/dump_result.py').read())"

   脚本读取 team 1 最近的ReviewReport及其 artefacts，写出包含配置快照、chunking、逐单元分解、漏斗、缓存感知成本、阶段耗时与完整发现清单的 Markdown。

5. 模型完整性检查（每轮强制）：dump 的消费表必须显示该臂的模型出现在每个issues-review-*/blind-spots-*gen 上——$ai_model是唯一可信信号；403 或未列入的模型会静默回退到 Opus 且无警告（这正是 A1 出现 SWITCHED 单元的机制）。
6. 清理：DEBUG=1 python manage.py reset_review_hog --yes（每次 dump 之后必做；会清空全部四个 review_hog 表并将技能配置重新播种为默认，保证每轮 roster 一致）。

预检清单还包括：本地遥测前置（LLM_GATEWAY_POSTHOG_AI_LANE_CAPTURE=false+ 重启本地网关，否则$ai_generation全部丢失）、三个 ngrok 隧道、网关 allowlist 已含目标模型并探测/review_hog/v1/models、无目标 PR 的既有ReviewReport行。

九、结语：一份运行报告教给我们什么

A-sonnet5-xhigh-1.md展示了 PostHog 团队如何用工程化、可复现、成本敏感的方式回答「换一个评审模型值不值」：通过冻结一切无关变量（同一 PR、同一 pinned chunks、同一 validator、同一干净环境），把模型质量差异暴露在漏斗数字、缓存感知成本与逐条对抗验证的发现清单里。真正值得借鉴的方法论有三点：

1. 成本必须缓存感知——naive 的 input-token 计价在缓存密集型管线上会虚高 4.4 倍，任何基于成本的模型决策都必须拆分 fresh/write/read 三档计价。
2. 发现必须双重验证——管线 validator 是保守的第一道闸，独立对抗式验证（refutation-first）才是判断「真实问题」的最终仲裁者；validator 的放行与独立验证只部分重合，这一校准本身值得追踪。
3. 精度优先于召回——在每条发现的逐条核验中，validator 反复执行「上游已处理 → 丢弃」「不可达触发 → 丢弃」「纯文档偏好 → 丢弃」的判定，把噪声挡在产物之外，同时把「降级保留」的真实边界情况（如 A1 的三条 VALID）留在记录里供后续处理。

这份报告及其所在实验目录（runs/、FINAL_REPORT.md、judge 系列 JSON）是研究 LLM 驱动的代码审查系统如何自我评估的完整案例，值得任何构建 agentic 审查管线的团队研读。

【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog