从一次运行读懂 ReviewHog 评审拓扑实验C4-completeness 运行记录与 Findings 裁决全解读【免费下载链接】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/posthogReviewHog 是 PostHog 仓库中的自动化 GitHub PR 代码评审系统它把 PR 拆成逻辑块chunk为每个块挑选评审视角perspective在沙箱 agent 中并行跑视角评审再经过合并、去重、验证后把结论以 Markdown 报告和内联评论的形式发回 PR。本篇以2026-07-reviewer-topology实验中的C4-completeness-1运行记录为骨架逐字段解读一份 ReviewHog 运行 dump——从配置快照、成本漏斗、chunk 划分到 8 条去重后 findings 的验证器裁决——并结合仓库源码posthog/hogql/property.py的steps_to_expr、frontend/src/scenes/max/max-constants.tsx的工具展示格式化还原每条发现的底层证据。读完你将能独立读懂 ReviewHog 任意一次运行 dump并理解评审拓扑实验的结论与后续方向。一、实验背景为什么 PostHog 要做 reviewer-topology 对比ReviewHog 的运行管线见 ARCHITECTURE.md大致是拉取 PR → 语义切分为 chunk → 用一次廉价调用挑选每个 chunk 需要的视角 → 在沙箱 agent 内并行执行视角评审 → 组合、清理、去重、验证 findings → 渲染报告并回帖。评审视角Logic Correctness、Contracts Security、Performance Reliability是数据库同步的 LLM skill沙箱 agent 通过 MCP 拉取。实验的直接动因来自 PR #67371 的复盘见 PLAN.md云端评审器只找到 4 个问题而旧版 ReviewHog 找到 11 个。根因是结构性的而非提示词差异旧版 8 chunks × 3 轮累积扫描 ≈ 24 个聚焦评审单元每轮都能看到前一轮的发现并被要求继续深挖云端版 1 chunk × 3 个并行视角 3 次宽扫描每个视角只扫一遍之后再统一去重没有深挖环节单 chunk 大小门CHUNK_TARGET_ADDITIONS1000只按新增行数算把一次 495 新增行 / 36 文件的改动压成了 1 个 chunk。于是实验锁定两个可调杠杆chunk 粒度是否强制小 chunk与视角拓扑并行 vs 顺序。测试 PR 固定为 #62096feat(ph AI): add action CRUD tools to ph AI674 新增 / 1 删除 / 10 文件评审模型固定为 Claude Opus 4.8 xhigh验证器固定为当前的严格版本只改变拓扑形成了 C0–C7 共 7 个配置。C4-completeness的定位是小 chunk 并行视角 每个 chunk 额外一次完整性补漏扫描gap pass——以最低的串行化成本换取顺序拓扑的覆盖面。二、运行元数据与配置快照一次 C4 运行的前置条件C4-completeness-1.md的头部是本次运行的元数据任何一次 ReviewHog 运行 dump 都以固定格式记录这些字段Dumped2026-07-02T00:04:3900:00dump 导出时间Report id019f200e-bda0-7190-8cf2-24e79072921f唯一报告标识PR#62096冻结的测试 PRhead 为ba725a897db35053525e5bdfac2c64a8b007fcb4run_count / status1 / idle本配置只跑了一次、无重试Wall-clock1409s约 23.5 分钟单次运行全流程耗时。紧随其后的Config snapshot记录了本次实验的变量取值这些条件常量定义在 ReviewHog 后端可对照 backend/reviewer/constants.py 及 PLAN.md 中Variables configs一节的说明运行栈为claude / claude-opus-4-8 / xhigh即评审模型与推理强度全程锁定EXPERIMENT_FORCE_CHUNKING True绕过 ≤1000 新增行的单 chunk 门强制走语义 chunkereffective chunk target / soft-max additions 250 / 400小 chunk 目标线即每个 chunk 期望约 250 行新增、软上限 400 行让 PR 按关注点拆成多个块EXPERIMENT_SEQUENTIAL_PERSPECTIVES False视角之间保持并行不启用 C2/C3 的顺序扫描EXPERIMENT_COMPLETENESS_PASS True本次配置的核心变量——每个 chunk 在并行视角波之后追加一次gap pass补漏扫描。三、成本漏斗与 token 消耗ReviewHog 的性价比核算方式运行的产出数量可以用一条漏斗链表示chunksreview unitsraw issuesafter deduppassed validator281184漏斗各阶段的含义记录中特别注释了review units的定义review units 每个perspective | gap × chunk实际执行的沙箱评审是模型持有恒定的成本代理——本配置为 2 chunks × 3 个并行视角 2 次 gap pass 8 个单元。这 8 个单元共产生 11 条 raw issues去重后剩 8 条最终只有 4 条通过验证器——约 64% 的原始发现被压缩掉这一压缩比例在实验中被验证为与拓扑无关详见 FINAL_REPORT.md 的Secondary observations。token 成本按模型汇总dump 中注明为 best-effort 估算可能发生在入库前或部分modelgensinput tokoutput tokclaude-opus-4-815816152133143480total15816152133143480158 次生成调用、约 1615 万输入 token 与 14.3 万输出 token——输入输出比接近 112:1这正是代码评审场景的典型特征每次评审单元都要灌入大段代码上下文与 skill 内容而产出只是少量发现文本。这也解释了实验中units → raw volume 近似单调3 单元 ⇒ 4–7 条原始发现12 单元 ⇒ 19 条但验证器无论拓扑如何都会压缩约 55–65%的观察。四、Chunking 与 per-review-unit 明细谁在哪一块上发现了什么本次运行把 PR 的 10 个文件按关注点切成了 2 个 chunkchunk 15 个文件ee/hogai/tools/actions/core.py、ee/hogai/tools/actions/tool.py、ee/hogai/tools/actions/__init__.py、ee/hogai/tools/__init__.py、ee/hogai/chat_agent/toolkit.py——即 PR 新增的 action CRUD 工具及其挂载进 chat agent 工具包的部分chunk 24 个文件frontend/src/queries/schema/schema-assistant-messages.ts、frontend/src/scenes/max/max-constants.tsx、frontend/src/queries/schema.json、posthog/schema_enums.py——即前端工具展示与共享 schema 定义。每个评审单元pass × chunk × perspective的原始产出如下表passchunkperspectiveraw issues11review-hog-perspective-contracts-security212?021review-hog-perspective-logic-correctness222review-hog-perspective-logic-correctness131review-hog-perspective-performance-reliability232?041review-hog-completeness-gap342review-hog-completeness-gap1值得注意的几点pass 1 与 pass 3 的 chunk 2 视角名称在 dump 中记录为?原始记录未回填完整且两个单元都产出 0 条原始发现——说明前端/schema chunk 在这两个视角下没有触发问题而 pass 4 的 gap pass 在 chunk 1 上独立产出了 3 条原始发现验证了补漏扫描确实能增加广度的实验假设FINAL_REPORT 中统计 C4 的 4–6 条原始发现/次来自 gap pass。五、去重后的 8 条 Findings逐条裁决与源码级佐证去重后共 8 条发现每条都带视角来源、directly-related标记、问题描述、修复建议与验证器裁决。裁决结果4 条 VALID保留、4 条 dismissed丢弃其中被丢弃的 3 条为consider级、1 条为被推翻的must_fix安全发现。以下按裁决分类逐条还原。5.1 VALID元素匹配器selector/tag_name/text/href静默编译为匹配所有事件裁决[✅ VALID] should_fix · bug来源视角review-hog-completeness-gap定位ee/hogai/tools/actions/core.py:34-45PR 分支上的行号。问题ActionStepInput的selector、tag_name、text/text_matching、href/href_matching只有在 step 的event $autocapture时才会被翻译成字节码。该行为在当前仓库 HEAD 中可以直接验证posthog/hogql/property.py 的steps_to_expr中整个元素匹配块被if step.event AUTOCAPTURE_EVENT:第 1679 行门控。因此一个只设置selectorbutton.cta而未设置event的 step其元素匹配器在编译时被整体丢弃如果该匹配器恰好是 step 的唯一条件exprs为空列表编译器会追加ast.Constant(valueTrue)第 1783 行附近同类逻辑——该 step 最终匹配每一个事件。而create_action的成功输出format_action_detail会把 selector 原样回显导致 agent 与用户都以为创建了一个精确匹配的 action。触发场景agent 被要求为 button.cta 的点击创建 action时天然只填selectorREST 前端路径因为 UI 强制先设event$autocapture才暴露元素字段而 raw-JSON 工具面没有这道护栏字段描述与CREATE_ACTION_DESCRIPTION中也都没有说明元素匹配器依赖$autocapture。建议三选一或组合——(a) 在to_step_dict/create_action/update_action中当提供了任意元素匹配器且 event 未设置时自动默认event$autocapture最贴合用户意图(b) 校验并抛出ActionToolError(c) 至少在字段描述与工具描述中显式声明该依赖。验证器核实验证器对照 live 代码确认steps_to_expr的元素匹配块确实整体被AUTOCAPTURE_EVENT门控Action.save() → refresh_bytecode() → action_to_expr → steps_to_expr链路中没有任何归一化会自动补设event触发路径具体且后果为静默正确性 bug符合保留标准。5.2 VALID无步骤 action 静默匹配所有事件而 create_action 把它描述成无害占位裁决[✅ VALID] should_fix · bug视角review-hog-completeness-gap定位core.py:70-73。问题CreateActionToolArgs.steps的字段描述写着 Omit for an empty action youll fill in later把无步骤 action 描述成惰性占位符。但steps_to_expr对空 steps 列表显式返回ast.Constant(valueTrue)property.py 第 1670-1671 行即零步骤 action 编译出的字节码匹配每个事件。若 agent 先创建这样一个占位 action 并接入 insight/funnel再稍后填充该 insight/funnel 会静默包含全部事件产生严重错误的分析结果。雪上加霜的是_format_action渲染为steps: nonecore.py:136完全没有提示 match-all 语义对比_format_step对单个空 step 会正确渲染为 matches all events但零 steps 的情况从不走这条路。建议修正steps字段与CREATE_ACTION_DESCRIPTION的描述警告无步骤 action 匹配所有事件而非什么都不匹配可选地让_format_action渲染为steps: none (⚠ matches all events)或让create_action默认拒绝创建零步骤 action。验证器核实确认零步骤返回ast.Constant(valueTrue)属实该发现与 5.1 的根因不同零步骤 vs 部分步骤且工具自身文案主动鼓励危险路径应保留should_fix级别恰当。5.3 VALIDlist_actions 不校验 limit/offset负值引发未捕获 ValueError裁决[✅ VALID] should_fix验证器降级为 consider· bug视角review-hog-perspective-logic-correctness定位core.py:148-150。问题ListActionsToolArgs的limit/offset是裸Optional[int]无ge/le约束描述里只有 1-100 提示list_actions内部也不做钳制。两个具体边界 bug(1) 负offset经start offset or 0保留原值-1 or 0→ -1负limit经capped_limit min(limit or DEFAULT_LIST_LIMIT, MAX_LIST_LIMIT)保留min(-5,100)→ -5切片qs[start : start capped_limit]出现负边界Django QuerySet 会抛ValueError(Negative indexing is not supported.)而ListActionsTool._arun_impl没有 try/except 包裹异常直接冒泡为不可重试的致命错误破坏了工具可重试错误让 LLM 自纠的设计(2)limit0经0 or DEFAULT_LIST_LIMIT静默变成默认页25 条与文档声称的 1-100 范围矛盾。建议在list_actions内部防御性钳制start max(offset or 0, 0)、capped_limit max(1, min(limit or DEFAULT_LIST_LIMIT, MAX_LIST_LIMIT))可选地在 pydantic 层加ge1/leMAX_LIST_LIMIT与ge0让坏值在到达 ORM 前被拒。验证器核实逐行验证了参数声明与钳制缺失确认 Django 对负切片抛ValueError且_arun_impl无异常兜底。但因 blast radius 仅限单次工具调用失败框架的通用异常安全网会兜住无数据丢失/安全影响limit0无害负分页值也非 LLM 常见输出故从should_fix降为consider。5.4 VALID分页按非唯一键排序offset/limit 翻页可能丢条或重复裁决[✅ VALID] consider · bug视角review-hog-perspective-logic-correctness定位core.py:147-150。问题list_actions在切片前只qs.order_by(name)而Action.name是CharField(nullTrue, blankTrue)数据库层无唯一约束。_check_name_available只拦新建的非空重名历史行、空/空值名、其他路径创建的 action 都可能同名或无名。非唯一排序键下并列行的相对顺序在多次查询间不稳定agent 按工具描述引导的 offset 0 → 25 → … 翻页时可能静默跳过某些 action、重复返回另一些——这是分页契约的数据完整性 bug不只是观感问题。建议加唯一决胜键保证全序qs qs.order_by(name, id)末尾id保证 offset/limit 分页稳定无损。验证器核实确认排序与字段定义属实。这是公认的非稳定分页bug 类别修复琐碎且无损但实际触发需要名字并列且并列顺序在两次分页间真发生变化通常仅在并发写或执行计划变化时且 RESTActionViewSet也使用同样的非唯一排序——属一致性加固而非回归consider级别恰当。5.5 dismissed动作名称长度未校验best_practice裁决[❌ dismissed] consider · best_practice视角review-hog-perspective-contracts-security定位core.py:181-189。问题描述_check_name_available只拒绝空名不限制长度。Action.name是CharField(max_length400)Postgresvarchar(400)REST 契约在序列化层会返回干净的 400 错误但工具路径直接Action(...).save()——Django 的.save()不跑字段校验器超过 400 字符的 LLM 名称会直达 Postgres 抛django.db.utils.DataError且该异常不是ActionToolError不会被映射为可重试错误。验证器驳回理由技术前提基本准确varchar(400)、.save()跳过字段校验、create_action/update_action只捕获ActionToolError但影响极小、触发几乎不可达——action 名是短人类标签Signup、CTA clickLLM 产出 400 字符名称实际不可能发生且后果轻微无数据丢失/安全/隔离影响写入只是失败。unhandled failure的说法也言过其实tool_errors.py记录了通用 Exception 会被兜底为致命安全网错误agent 不会崩溃只是得到不可重试的致命消息而非可重试消息。按 precision-over-recall 原则丢弃。5.6 dismissedlist_actions 全量展开每步削弱紧凑/有界的上下文安全声明code_quality裁决[❌ dismissed] consider · code_quality视角review-hog-completeness-gap定位core.py:133-134。问题描述PR 设计说明声称list_actionsbounded by construction 且 compact但非详述列表分支对每个返回 action 的每个 step 做全量展开; .join(_format_step(s) for s in steps)上限只限 action 数默认 25、最大 100不限 step 体量100 个重度配置的 action 仍可能产生很大的输出。验证器驳回理由观察在技术上正确core.py:134确实内联每个 step上限确实在 action 数而非 step 量但影响有界且属推测而非缺陷输出被 100 条硬上限封顶最坏情况也只是数十 KB 文本现代 LLM 上下文窗口轻松容纳工具描述已引导模型用search与分页而非全量拉取。无正确性 bug、无无界增长只是设计说明略夸大 渲染更美观的建议属品味范畴按 precision-over-recall 丢弃。5.7 dismissedlist_actions 状态格式化丢失分页/搜索上下文code_quality裁决[❌ dismissed] consider · code_quality定位frontend/src/scenes/max/max-constants.tsx:176-185视角review-hog-completeness-gap。问题描述list_actions接受search/limit/offset后端也明确鼓励 agent 分页与搜索但其展示格式化器是通用skillStatusFormatter无论参数如何都只渲染扁平的 Listing actions.../Listed actions同文件中最接近的两个同类工具list_data与list_feature_flags都会读取toolCall.args.offset/kind/status渲染页码与过滤条件如 Listing stale feature flags (page 2)...。agent 分页/搜索时会连续多次调用list_actions用户看到的是一串无法区分的 Listing actions...与其他 list 工具不一致。源码佐证当前仓库 HEAD 中 max-constants.tsx 的对比仍然成立skillStatusFormatter第 186-196 行只拼接固定标签与可选的 name 参数而list_data第 561-576 行与list_feature_flags第 577-588 行各自实现了读取offset计算(page N)的displayFormatter。dump 记录的 176-185 行是 PR #62096 引入list_actions时的位置。验证器驳回理由前提完全正确不一致是真实的但这是纯展示标签差异零行为/正确性/安全/性能影响——工具功能与状态行写什么无关唯一后果是重复翻页时状态行不可区分。属 UX 打磨/一致性范畴落入纯风格/品味丢弃桶。5.8 dismissedlist_actions 绕过对象级访问控制暴露受限 actionmust_fix 安全发现被推翻裁决[❌ dismissed] must_fix · security被验证器整体推翻视角review-hog-perspective-contracts-security定位core.py:142-150。问题描述list_actions用Action.objects.filter(teamteam, deletedFalse)拉取ListActionsTool只做了资源级检查get_required_resource_access() - [(action, viewer)]从不应用对象级访问过滤而action是对象级访问控制资源RESTActionViewSet.list会跑self.user_access_control.filter_queryset_by_access_level(queryset)排除被显式屏蔽的对象。PR 在早前评审中已给 get/update/delete 加了check_object_access但 list 被遗漏——具有默认资源级 viewer 但对某 action 有显式 object 级none/受限AccessControl的用户仍可通过 Max 的list_actions读到该 action 的名称、描述与完整 step 定义而 REST list 路径会隐藏它们。验证器驳回理由这条看起来最严重的发现恰恰被验证器以充分的代码证据推翻。关键链条minimum_access_level(action)返回 viewer、default_access_level(action)返回 editor而AccessControlSerializer.validate_access_level拒绝任何低于资源最小值的访问控制设置——对 action 根本不可能创建 object 级none/屏蔽记录每个有 action 资源访问权的用户对每个 action 至少是 viewer。在filter_queryset_by_access_level中blocked_resource_ids只由 object 级none控制填充此处不可能因此有资源级访问的用户走 REST list 得到的就是未过滤的全量 queryset与list_actions完全一致。唯一分叉场景资源级none 特定对象授权反而让工具更严格——_check_resource_access要求资源级(action, viewer)且 fail-closed直接拒绝工具而非暴露任何东西。结论对 actions 而言不存在数据暴露缺口给 list 加过滤是 no-opget/update/delete 的对象检查也仅对 editor 级别有意义。这是有意设计action 是项目共享的构建块不能被单独隐藏must_fix 前提有误应丢弃。这也是整个 dump 中最能体现验证器不是橡皮图章的一条它会逐条核实前提可达性并推翻高优先级误报。六、从单次运行到实验结论C4 的定位与后续方向C4-completeness-1只是2026-07-reviewer-topology实验 15 次运行中的一份 dump配置 C4 共 2 次运行17 份 dump 全部位于 runs/ 目录。把这份单次运行放回实验全景结论才完整见 FINAL_REPORT.mdC4 是质量/成本最优拓扑其最佳运行在旧版覆盖率3/10 valid与总有效发现数8 条上均领先gap pass 被证明切实增加广度每次运行 4–6 条原始发现来自补漏扫描代价只是每 chunk 增加 1 个评审单元无串行化延迟。拓扑不是全部旧版 10 条发现中有 5 条在任何拓扑、任何运行的 15 次尝试中从未浮出水面含旧版报告仅有的两条 must_fix 安全发现。约束不在 chunk 划分或 pass 结构而在视角 skill 的找什么以及验证器严格度——这是 skill 内容盲区拓扑调参无法弥合。验证器严格度有代价旧版 #6 被 8 次运行捕获却在 7 次中被验证器驳回、#2 的捕获 9 次中有 4 次被驳回。严格验证器以约 1–2 个旧覆盖率点换取各拓扑下普遍较高的已发布精度。新评审器并非全面退化而是侧重不同每次运行都产出 1–3 条旧工具从未发现的 judge 验证发现其中两条match-all 元素 step action、root-team scoping被评为强于旧报告中的任何一条。后续方向按覆盖率/投入排序先做视角 skill 内容轮针对那 5 条 never-surfaced 发现特权工具接线/agent 安全、写路径鉴权顺序、输出通道注入、负载大小限制再做验证器校准#6 与 #2 的推测性/可达性驳回标准最后采纳 C4 的 gap pass 作为性价比最高的广度机制。补充实验C7-gappinnedC4 拓扑 固定 3 分块×2 次进一步收紧了结论gap pass 固定结构是实验中最一致、产出最高的配置两次运行均为 11 去重 / 6 valid但旧版尺标召回率并未随一致性上升2/10、1/10且去重在发现量上升时漏过了 3 对重复——最终建议不变但证据更硬采纳 gap pass 求广度与一致性chunking 只在评测可复现性上固定/确定化把接下来两轮预算投给视角 skill 内容与验证器校准。七、如何查看与复现本次实验数据全部实验产物都在仓库内可自行深入运行 dumpproducts/review_hog/eval/experiments/2026-07-reviewer-topology/runs/17 份含本文解读的C4-completeness-1.md实验设计与实现地图PLAN.md根因分析、C0–C7 配置矩阵、C5 warm-session 与 C6 pinned-chunks 的实现清单汇总结论与覆盖矩阵FINAL_REPORT.md判定原始输出judge_results.json注意报告提醒judge 判定未经人工复核行动前应抽查各 run 的 notes测试用 PR 材料fixtures/PR diff、先前 bot 评论、旧版 ReviewHog 报告副本dump 导出脚本products/review_hog/eval/scripts/dump_result.py。需要提醒的是dump 中引用的ee/hogai/tools/actions/core.py、tool.py是 PR #62096 分支上的路径当前仓库 HEAD 中该 action CRUD 工具目录已不在原位置而两条 VALID 发现的底层编译逻辑仍可 HEAD 中的 posthog/hogql/property.pysteps_to_expr的空步骤 match-all 与AUTOCAPTURE_EVENT门控直接验证前端展示对比则在 frontend/src/scenes/max/max-constants.tsx 与同文件list_data/list_feature_flags的displayFormatter实现中随时可查。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考