ReviewHog 评审器拓扑实验C6-pinnedchunks 固定分块运行全解析【免费下载链接】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本篇文章以products/review_hog/eval/experiments/2026-07-reviewer-topology/runs/C6-pinnedchunks-2.md这份运行 dump 为主骨架完整解读 PostHog ReviewHog 自动 PR 评审器评审器拓扑质量实验中 C6固定分块配置的一次典型运行从配置快照、成本漏斗、分块结构到 8 条发现逐条展开的评审与校验器裁决并回到当前仓库源码验证每条发现的技术前提。读完你将掌握如何阅读 ReviewHog 实验运行记录、理解其漏斗式评审管线以及固定分块 vs 评审随机性这一实验问题的最终答案。一次运行的完整档案C6 要回答什么问题ReviewHog 是 PostHog 仓库内一个基于 Django 的自动 GitHub PR 评审器架构全貌见 products/review_hog/ARCHITECTURE.md。它抓取 PR → 拆分为可评审的分块chunk→ 为每个分块选择评审视角perspective→ 在沙箱 Agent 中并行执行视角评审 → 合并、去重、校验 → 渲染 Markdown 报告并回贴评审评论。2026 年 7 月的评审器拓扑质量实验PLAN.md在冻结的 PR #62096action CRUD 工具 PR674 增 / 1 删 / 10 文件上对比 7 种评审拓扑回答一个根因问题云上评审器在 #67371 上只找到旧版 4/11 的问题原因究竟是分块粒度还是视角拓扑C6 是其中专门设计的去混淆de-confound配置——它的由来是C1 小分块配置的三次运行中恰好抽到与旧版一致的 3 分块结构的那次run 2给出了最佳漏斗13→10→5但分块器本身是随机的众数为 2 分块。为了判断好结构究竟是因果还是评审运气C6 把 C1-run-2 的 3 分块结构硬编码固定EXPERIMENT_PINNED_CHUNKS绕过分块器 LLM其余不变。本运行C6-pinnedchunks-2是该配置的第二次运行是全部 15 次实验运行的收官之作其结论直接进入 FINAL_REPORT.md 的最终裁定。运行快照配置与实验常量运行记录开头的元数据与配置快照是整个实验可复现性的基石字段值Dumped2026-07-02T03:46:5300:00Report id019f20e0-9e8f-7b9c-881b-995a579674b8Headba725a897db35053525e5bdfac2c64a8b007fcb4run_count / status1 / idleWall-clock965s16.1 分钟配置快照逐项列出实验条件评审模型claude/claude-opus-4-8/xhigh——评审器模型全程恒定Codex 因不可靠被弃用排除模型差异干扰EXPERIMENT_FORCE_CHUNKING False未强制调用语义分块器——因为本次走EXPERIMENT_PINNED_CHUNKS固定分块路径分块器 LLM 被短路与 ≤1000 增行的确定性单块闸门同理只是这里闸门换成硬编码的ChunksListeffective chunk target / soft-max additions 1000 / 1500这是生产默认值C1/C3/C4/C5 才下调到 250/400固定分块配置完全不需要分块参数生效EXPERIMENT_SEQUENTIAL_PERSPECTIVES False三个视角仍并行执行不做后视角看前视角发现的顺序累积EXPERIMENT_COMPLETENESS_PASS False不加大家漏了什么的补漏 pass那是 C4/C7 的机制EXPERIMENT_WARM_REVIEW_SESSION False每个(视角 × 分块)仍是独立冷沙箱会话不做按视角的温会话复用C5 的机制EXPERIMENT_PINNED_CHUNKS三个 chunk 的硬编码文件清单见下节。也就是说C6 是实验矩阵中最便宜的配置之一没有分块器调用、没有串行化、没有额外补漏 pass固定 3 分块 × 并行 3 视角 9 个评审单元。漏斗与成本从 12 条原始问题到 4 条有效实验的核心衡量物是漏斗原始发现 → 去重后 → 通过校验器chunksreview unitsraw issuesafter deduppassed validator391284review units 定义每个实际运行的(视角或补漏 × 分块)沙箱评审 模型恒定前提下的成本代理。C6 没有补漏 pass所以 units 3 视角 × 3 分块 912 条原始发现经去重收敛到 8 条丢失 1/3来自跨视角重叠再经严格校验器只剩 4 条有效——约 2/3 的原始发现被校验器压掉这一压缩率与实验全体的 55%~65% 一致。Token 成本本地$ai_generation事件的尽力统计可能为摄取前/部分数据modelgensinput tokoutput tokclaude-opus-4-814714,611,570162,879claude-sonnet-4-6291,241,3388,134total17615,852,908171,013约 15.9M 输入 token / 171K 输出 token、176 次生成。对比姊妹运行 C6-pinnedchunks-118.7M 输入192 次生成两次运行量级一致而漏斗上 run 1 是 9→5→3本运行是 12→8→4同为中游水平——这正是 C6 结论的伏笔。固定分块结构三个 chunk 的文件构成EXPERIMENT_PINNED_CHUNKS硬编码的清单取自 C1-smallchunks-2 那次好分块按评审优先级组织chunk 11 文件ee/hogai/tools/actions/core.py——Action CRUD 工具的核心实现参数模型、list_actions、格式化函数chunk 24 文件ee/hogai/tools/actions/tool.py、ee/hogai/tools/actions/__init__.py、ee/hogai/tools/__init__.py、ee/hogai/chat_agent/toolkit.py——工具包装器与 agent 工具包接线覆盖工具如何被 agent 使用的层面chunk 34 文件frontend/src/scenes/max/max-constants.tsx、frontend/src/queries/schema/schema-assistant-messages.ts、frontend/src/queries/schema.json、posthog/schema_enums.py——前端常量与 schema 相关Max 助手消息 schema 及其后端枚举镜像。需要说明这些ee/hogai/tools/actions/文件是 PR #62096 新增的评审对象行号引用均来自该 PR 的 diff 与本运行记录当前仓库快照中ee/hogai/tools/下仍保留着read_data/、upsert_dashboard/等同类 Max 工具实现见下文源码佐证ee/hogai/chat_agent/对应的 agent 工具包接线逻辑亦可对照。审查单元矩阵视角 × 分块的产出分布运行记录给出每次评审单元pass × chunk × perspective的原始发现数passchunkperspectiveraw issues11review-hog-perspective-contracts-security212review-hog-perspective-contracts-security213?021review-hog-perspective-logic-correctness322review-hog-perspective-logic-correctness123?031review-hog-perspective-performance-reliability232review-hog-perspective-performance-reliability233?0值得注意的模式chunk 1core.py承载了最多发现2327chunk 2 次之2125而chunk 3前端/schema三个视角全部产出 0——这在 C6 两次运行中是一致的run 1 的 chunk 3 也是 0。从结构看前端 chunk 是评审信号的弱区三个视角均有产出且量级接近security 4 / logic 4 / performance 4不存在某一视角空转?标记表示该单元未跑出任何发现perspective 名由 pass 序号推断。12 条原始发现中 8 条进入去重后列表其中 7 条直接命中 chunk 1/chunk 2 的后端文件印证了核心问题集中在工具实现层的判断。通过校验器的四条发现去重后的 8 条发现中4 条被校验器判定 VALID1 条 must_fix、2 条 should_fix、1 条 consider。校验器是独立于评审视角的验证环节温会话逐条核对源码判据通过review-hog-validation-criteria技能拉取见 ARCHITECTURE.md其裁决过程本身就是高质量的代码审查证据。must_fix · securityListActionsTool 绕过对象级访问控制数据暴露位置ee/hogai/tools/actions/tool.py:61-73ListActionsTool._arun_impl问题ListActionsTool._arun_impl调用list_actions(self._team, ...)而list_actionscore.py:142-166只按teamteam, deletedFalse过滤没有复刻 REST 列表路径的对象级访问过滤。RESTActionViewSet.list会经self.filter_queryset(self.get_queryset())→_filter_queryset_by_access_level→UserAccessControl.filter_queryset_by_access_level(...)posthog/api/routing.py:362-388剔除对象级被阻止的 action而action本身是 per-object 访问控制资源ACCESS_CONTROL_RESOURCESposthog/rbac/user_access_control.py:59。同一 PR 已经给 Get/Update/Delete 三个工具补上了check_object_access唯独 list 工具是缺失的兄弟被对象级限制为none的用户仍可通过 Max 的list_actions读取这些 action 的名称、描述与完整 step 定义。资源级检查get_required_resource_access()只门控整个工具并不会过滤掉单个被阻止的对象。建议把self.user_access_control传入list_actions在team/deleted过滤之后、count()与切片之前执行qs user_access_control.filter_queryset_by_access_level(qs)与 REST viewset 及本 PR 已加的 Get/Update/Delete 对象级检查保持一致。校验器裁决确认为真实的 broken-object-level-authorization 缺口。list_actions从不应用对象级过滤返回用户被对象级明确阻止的 action通过 Max 暴露其名称、描述与完整 step 定义而 Get/Update/Delete 已通过check_object_accesstool.py:86,124,153守护同类缺口。建议的修复直接镜像 REST 路径简单直接。作用域说明对象级过滤仅在开启企业ACCESS_CONTROL功能且管理员配置了显式 per-objectAccessControl行的组织里生效否则是 no-op——但对这些组织而言这是真实的数据暴露授权绕过故定为 must_fix。当前仓库源码佐证MaxTool类定义于 ee/hogai/tool.py其资源级检查_check_resource_access在 L313-L324check_access_level_for_resource对象级检查check_object_access在 L326-L349check_access_level_for_object两者都依赖self.user_access_control实例。更直接的先例是 ee/hogai/context/entity_search/context.py 的_list_feature_flags_sync它在 L399-L401 对FeatureFlag.objects.filter(team..., deletedFalse)直接套用filter_queryset_by_access_level并在 L394-L396 的注释中明确比 fail-closed 基线更严格无 feature flag 访问的调用者什么都得不到——这正是本发现建议 list 工具采用的既有模式可以推断该修复的落地方式与_list_feature_flags_sync几乎逐行同构。should_fix · bug负 limit/offset 触发未处理 ValueError位置ee/hogai/tools/actions/core.py:148-150list_actions的切片逻辑问题list_actions把MAX_LIST_LIMIT当上界但从未夹紧limit/offset的下界。ListActionsToolArgs把limit/offset声明为普通Optional[int]没有ge/le约束1-100的范围指导只存在于描述文本里LLM 可以传入负值。capped_limit min(limit or DEFAULT_LIST_LIMIT, MAX_LIST_LIMIT)让负 limit 保持为负start offset or 0让负 offset 保持为负随后qs[start : start capped_limit]触发 Django 守卫raise ValueError(Negative indexing is not supported.)django/db/models/query.py:417。与 create/update/delete 不同list_actions没有包在ActionToolError→MaxToolRetryableError的守卫里因此表现为未处理内部错误而非优雅的可重试消息。次要问题limit or DEFAULT_LIST_LIMIT把显式limit0当 falsy静默返回 25 行而非 0 行。建议切片前夹紧下界start max(0, offset or 0)、capped_limit max(1, min(...))或在ListActionsToolArgs上声明limit: Optional[int] Field(defaultNone, ge1, leMAX_LIST_LIMIT)、offset: Optional[int] Field(defaultNone, ge0)让 Pydantic 在值到达 ORM 之前就拒绝。校验器裁决验证属实。ListActionsToolArgscore.py:56-60无下界约束list_actions的切片计算core.py:148-149让负值穿透到切片ListActionsTool._arun_impltool.py:69-73独缺兄弟工具有的错误包装ValueError作为未处理内部错误传播。触发是合理的——分页算术从页码推导 offset正是 LLM 容易算错成负值的场景且没有任何校验兜底。属命名触发 命名后果的真实正确性/可靠性缺陷修复琐碎should_fix 优先级恰当。当前仓库源码佐证DjangoModel.save()/queryset 不校验模型字段的max_length那是验证层约束负切片守卫由 Django queryset 的__getitem__抛出——这一机制在 products/actions/backend/models/action.py 的Action模型name CharField(max_length400, nullTrue, blankTrue)上同样成立。可重试错误包装的既有模式可见 ee/hogai/tools/read_data/tool.pyraise MaxToolRetryableError(...)即LLM 可修正的输入错误应以可重试错误返回而非内部异常。should_fix · bugorder_by(name) 分页非确定性位置ee/hogai/tools/actions/core.py:147-150list_actions的分页排序问题list_actions以 offset/limit 在qs.order_by(name)上分页。Action.name是非唯一、可空的CharFieldproducts/actions/backend/models/action.py:43名称相等或 NULL的行在 Postgres 中没有确定的相对顺序跨分页调用时tie 行之间的顺序可能变化agent 逐页走 offset 时会出现某个 action 被跳过、或同时出现在两页。_check_name_available只对未来非删除写入强制唯一性现有行与 REST 创建的 action 完全可能共享名称或未命名。建议加稳定 tiebreaker例如qs.order_by(name, id)——唯一id保证全序offset 分页不再跳行或重行。校验器裁决正当且广为人知的分页正确性 bug。offset 分页要求跨调用稳定的全序tie/NULL 名称下 Postgres 不保证 tie 行的相对顺序。_check_name_available只阻止工具自身创建重复非删除名称不能阻止存量行、REST 创建的行或无名称NULL-name行共享排序键。工具描述本身提到项目可能有数千个 action并专为分页而建触发真实存在agent 流同时创建/删除 action 时数据集在页间变化会加剧风险。修复是标准一行式 tiebreaker非过度工程should_fix 合理。当前仓库源码佐证products/actions/backend/models/action.py 确认name models.CharField(max_length400, nullTrue, blankTrue)可空 非唯一模型Meta未声明默认ordering因此order_by(name)是唯一排序键tie 场景真实可达。consider · bugAction 名称长度校验缺失可能抛出未处理的 DB DataError位置ee/hogai/tools/actions/core.py:181-189_check_name_available问题_check_name_available只校验名称非空CreateActionToolArgs.name/UpdateActionToolArgs.name都是普通strcore.py:68,78不限制长度。而Action.name列是varchar(400)products/actions/backend/models/action.py。REST 端ActionSerializer从模型构建 nameDRF 在 API 边界强制max_length400并返回干净的 400 校验错误工具路径没有此检查超过 400 字符的名称会到达action.save()并抛出未处理的 PostgresDataErrorvalue too long for type character varying(400)。该异常不是ActionToolError不会被转换成可重试消息而是作为未捕获错误传播——工具输入契约静默偏离 REST/DB schema。建议在工具边界强制 400 字符约束——给 schema 字段加name: str Field(..., max_length400)/name: Optional[str] Field(defaultNone, max_length400)或在_check_name_available里加显式长度检查并抛ActionToolError可重试、LLM 可修正。校验器裁决前提成立。Action.name是CharField(max_length400)action.py:43而 Django不在Model.save()上强制max_length——它只是验证层约束由 DRFActionSerializer在 REST 边界应用save()把原始值发给 Postgresvarchar(400)列以DataError拒绝超长字符串。工具路径无界且_check_name_available只拒绝空白tool.py 的包装器只把ActionToolError转成可重试MaxToolRetryableErrortool.py:103-104, 127-128DataError两者都不是故作为未捕获异常传播。这是真实的触发→后果对400 字符名称 → 未捕获 DB 错误且与 PR 想复刻的 REST/DB 契约真实背离修复琐碎Field(max_length400)还能向 LLM 传达约束。LLM 生成 400 字符名称的可能性低因此consider是恰当严重度。当前仓库源码佐证products/actions/backend/models/action.py 直接确认name models.CharField(max_length400, nullTrue, blankTrue)。校验器DRF 在 API 边界强制、save()不强制的论断对应 Django 验证层与 ORM 持久化层的分工——这是 Django 框架级事实与本仓库任何模型一致。被校验器驳回的四条发现驳回不等于假阳性——校验器逐条承认其技术前提大多准确但按precision over recall宁缺毋滥的团队判据见review-hog-validation-criteria技能默认标准保留真实影响用户的正确定性/安全/数据丢失/契约/性能问题丢弃过度工程、投机、防御性偏执、不可能发生的边界与风格问题判定不值得浮现。dismissed · code_quality空字符串 event 的渲染与编译行为不一致位置ee/hogai/tools/actions/core.py:107-108_format_step问题_format_step用if step.event is not None门控 event 行而其他字段都用 truthiness 检查。空字符串 event会被ActionStepInput.to_step_dictmodel_dump(exclude_noneTrue)保留保留于是带event的 step 渲染成event但字节码编译器把空 event 视为无过滤器——steps_to_expr用if step.event:不添加任何 event 约束。工具于是告诉 LLM该 step 匹配某事件而实际编译出的 action 匹配所有事件。建议改用与函数其余部分及编译器一致的 truthiness 检查if step.event:。校验器裁决技术前提准确core.py:107 与steps_to_expr的if step.event:不一致exclude_noneTrue确实保留空串但不值得浮现触发是罕见、几乎不可达的输入——LLM 构造 step 时要么给真实事件名要么省略该字段得到None几乎不会显式传空串即便发生event渲染也肉眼可见为空误导性弱。属于低影响、几乎不可达边界的一致性 nitprecision 优先于 recall 予以丢弃。当前仓库源码佐证posthog/hogql/property.py 的steps_to_expr明确写的是if step.event:L1676——空字符串事件不会生成event ...约束直接证实校验器引用的编译器行为。dismissed · performancelist 模式输出渲染每个 step破坏有界输出目标位置ee/hogai/tools/actions/core.py:133-134_format_action非详细模式问题非详细 list 模式下_format_action用; .join(_format_step(s) for s in steps)渲染每个 action 的完整 step 明细。结果数上限MAX_LIST_LIMIT100只限制 action 数量不限制总输出大小最多 100 个 action、每个多 step 多属性过滤器时字符串可增长到很大消耗大量 agent 上下文/token——正是分页上限注释声称要防止的淹没 agent 上下文窗口。建议list 模式输出有界摘要step 数量 可选事件名完整_format_step明细只留给detailedTrue的 get_action。校验器裁决观察事实正确core.py:134 确实逐 step join但实际 flood 风险已被大幅缓解建议读起来像投机优化而非具体缺陷step 中最贵的属性过滤器以紧凑计数渲染f{len(step.properties)} property filter(s)core.py:120其余字段是短keyvalue片段真实 action 通常只有少量 step默认页 25最大 100。真正淹没上下文需要很多 action × 异常多的 step的罕见最坏情况。进一步摘要 vs 保留紧凑逐 step 展开是设计/品味取舍不是正确性、安全、数据丢失、契约或现实规模性能问题。dismissed · performanceDeleteActionTool 审批恢复时重复获取与访问检查位置ee/hogai/tools/actions/tool.py:143-155问题delete 被危险操作审批流门控使用 LangGraph 的interrupt()。用户批准后图恢复时MaxTool._arun_with_context从顶部重新执行节点is_dangerous_operation()再跑一遍format_dangerous_operation_preview()再跑一遍第二次_fetch_action 第二次check_object_access其渲染的预览因interrupt()现在返回恢复载荷而立即被丢弃之后_arun_impl()才执行自己的_fetch_actioncheck_object_access再删除。恢复 pass 上 action 在同一工具实例内被连续两次获取和访问检查预览的工作全部浪费。注意_arun_impl内的重新获取本身是有意保留的action 可能在审批延迟期间变化或被删可避免的只是恢复 pass 上预览重算与执行获取的冲突。建议在工具实例上缓存 pass 内第一次_fetch_action/check_object_access的结果供同一 pass 复用镜像UpsertDashboardTool缓存_cached_update_diff的做法同时保留执行 pass 开始时的全新获取若认为罕见的人类门控 delete 不值得加状态则至少加注释说明冗余是有意的。校验器裁决前提技术上准确LangGraph 恢复时确实从顶部重执行但过不了 precision-over-recall 门槛。性能保留标准针对真实规模问题热路径 N1、无界循环、异步路径阻塞 I/O这里是人类审批门控、天生罕见的单 action 软删除可避免成本恰是一次额外索引单行查询 一次访问检查且仅在人类点击批准后发生。更重要的是建议的 pass 级实例缓存与_cached_update_diff的对比并不完美该缓存每次实例新建、根本不跨恢复边界存活只压缩 pass 内重复为微小罕见成本引入必须小心失效的状态化缓存属于过度工程。当前仓库源码佐证UpsertDashboardTool的缓存模式真实存在于 ee/hogai/tools/upsert_dashboard/tool.py_cached_update_diff: UpdateDiff | None None类字段与 L607-L628is_dangerous_operation/format_dangerous_operation_preview共用缓存危险操作钩子定义在 L109/L118——校验器关于该缓存不跨恢复边界实例化存活的论断与源码一致。dismissed · performancelist 输出按数量而非大小有界位置ee/hogai/tools/actions/tool.py:69-73ListActionsTool._arun_impl问题ListActionsTool._arun_impl把list_actions()的原始字符串直接返回进 LLM 上下文。设计目标LIST_ACTIONS_DESCRIPTION与 PR body 声明是工具构造上有界、发现过程永远不会淹没 agent 上下文——但该保证只对行数上限 100成立不对每行大小成立非详细模式每个 action 渲染为steps: N (每个 step 内联)展开每个 step 的 event/url/selector/tag/text/href 以及未截断的完整 description。几十个大 action 的项目可以产生单次数万 token 的 list 响应。建议让紧凑列表真正紧凑——非详细渲染只发 step 数量与第一步或短截断摘要长描述截断到固定长度完整逐 step 展开只保留给 get_action 详细路径。校验器裁决技术观察准确core.py:124-139 非详细模式仍逐 step 内联 完整未截断 description但不过真实规模才会咬人的门槛。flood 场景依赖非典型项目形态几十个 action 各带大量 step/长描述而真实 action 绝大多数只有少量 step默认 25 的紧凑列表落在低数千 token 范围。更重要的是紧凑视图内联逐 step 摘要是可辩护的刻意设计而非缺陷它让模型在发现阶段就能区分 action不必为细节触发 25 次独立的 get_action。建议的修复从列表砍掉 step 细节、强制 get_action 取详情以常见路径的额外往返换取罕见大项目的 token 节省是得失难定的交易而非明确胜利。跨运行对比同一发现的 validator 分歧C6 两次运行给出了一个特别有信息量的对比同一发现list_actions 绕过对象级访问控制在两次运行中被校验器给出相反裁决。在 C6-pinnedchunks-1.md 中该发现tool.py:69-73被dismissed校验器论证minimum_access_level(action)返回 viewervalidate_access_level拒绝低于资源最小值的访问级别因此 API 不可能为 action 创建noneACL——前提不可达filter_queryset_by_access_level的阻止条件对 action 是死代码还顺带指出该 PR 给 get_action 加的check_object_access对读操作本身就是 no-op在本运行C6-pinnedchunks-2中同一发现被VALID · must_fix校验器确认缺口真实建议把user_access_control传入list_actions镜像 REST 路径并限定作用域仅企业 ACCESS_CONTROL 组织 显式 AccessControl 行配置时生效。可以观察到两次裁决的分歧点集中在action 对象级 none 状态是否可达这一前提上——这正是校验器本身对同一代码库得出的互相矛盾的结论。这一分歧不是孤例FINAL_REPORT 明确指出校验器严格度本身是独立变量旧发现 #6 被 8 次运行浮现却 7 次被校验器杀掉、#2 的捕获 9 次里 4 次被驳回并把校验器校准列为下一轮的两个重点方向之一。对于阅读运行记录的人这提示validator 判定应视为证据而非终审关键发现值得人工复核尤其在裁决依赖状态是否可达这类前提推断时。实验结论与生产启示本运行C6-pinnedchunks-2是 15 次运行的最后一次它的价值在于把 C6 的判定钉死固定好结构并未复现幸运运行的顶尖漏斗。run 1 为 9→5→3、本运行为 12→8→4都落在中游而不是 C1-run-2 / C3-run-1 的 5~6 条有效。两次 C6 的有效数3、4系统性低于好结构 好运气的 5~6——结构有帮助但评审 pass 的随机性review-pass variance同样是顶级漏斗的共同驱动因素PLAN.md 运行日志的 C6 判定语。结合 FINAL_REPORT 的全局裁定15 次运行、7 种拓扑下旧版 10 条发现中有 5 条从未被任何配置浮现含两条 must_fix 安全发现如子代理工具包可达、Markdown 注入——约束瓶颈不是分块或 pass 结构而是视角技能的内容与校验器严格度拓扑调优单独无法弥合与旧版的差距。最佳拓扑是 C4小分块 并行视角 每 chunk 一次补漏 pass其后续 C7补漏 固定分块以 11→6 的有效数两次复制自身结果成为最一致、产出最高的配置但旧标尺召回并未随之上升2/10、1/10再次印证召回由技能内容与校验器严格度决定。对生产的直接启示FINAL_REPORT 的建议采用 C4/C7 的补漏 pass 提升广度与一致性分块仅在实验复现性需要时固定/确定性化下一轮投入方向是视角技能内容覆盖那 5 条从未浮现的发现与校验器校准。参考与延伸阅读本运行姊妹记录C6-pinnedchunks-1.md9→5→3含同发现的 validator 分歧原始论证实验设计与运行日志PLAN.mdC6 的动机、固定分块清单来源、全部 17 次运行的漏斗/成本/墙钟表最终报告与全局裁定FINAL_REPORT.md覆盖矩阵、配置排名、C7 增补评审器管线架构ARCHITECTURE.mdReviewPRWorkflow、沙箱执行层、三视角技能、校验器、数据模型与持久化被校验器引用的模型事实products/actions/backend/models/action.pyAction.namevarchar(400)、bytecodeJSONField、steps_json编译器行为佐证posthog/hogql/property.pysteps_to_expr的空 event 语义Max 工具访问控制机制ee/hogai/tool.py资源级与对象级检查、ee/hogai/context/entity_search/context.py_list_feature_flags_sync的对象级过滤先例、ee/hogai/tools/upsert_dashboard/tool.py危险操作预览缓存模式【免费下载链接】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），仅供参考