← 开发文档

ops 独立审查 — 回审轮数预算

建立 2026-09-29 · 四份规则副本逐字同步 · 异族审查(kimi)两轮通过
已生效 母本 AGENTS.md §10 副本 3 份 首审 2 P0 已闭环 迭代方向 5 项待观察
0 · 一句话

把原条款「本轮新发现的 P0 → 计数重置,不受上限约束」换成两层硬预算:

到顶仍有未闭环 P0 → 不假装收敛,一页交 chief 仲裁,不再自动开新轮。另加禁 relitigate:已闭环的点,没有新的可复跑反例输出就不许重审。

1 · 为什么改(实测数据)

数据源 ~/.hermes/profiles/ops/state.db,窗口 2026-09-19 ~ 09-28。

指标首审回审结论
派发次数5854—
累计时长466 分钟588 分钟回审更贵
平均单次482s653s回审反而更慢
平均工具调用45 次58 次名为增量,实为全量重跑

三个结论

  1. 回审比首审更重。§10 写了「增量复审」,实测回审的工具调用数高于首审 —— 没落地。
  2. 单主题轮数无上限。Hermes 3.11→3.14 回滚链产生 12 份回审报告(同一 P0 链);是她热力图审到 R13。
  3. 根因是条款本身。原「计数重置」= 只要本轮又发现新 P0 就重置计数。在判据密集的改动上(每条新 P0 常有后代)必然触发 ⇒ 变相无上限。

补充:这十天单步响应时间没有变慢(9/15-9/18:5.5 / 7.1 / 6.7 / 6.7 秒;9/20 后:4.6 / 4.7 / 4.1 / 3.6 / 5.3 / 4.5 / 5.5 秒)。慢的是轮数与派发频次。

2 · 新条款

2.1 两层预算

两层独立计数、任一层到顶即停,不因新发现 P0 而重置。

2.2「链」的可判定口径(关键 · 防拆链绕过)

链 = 同一批冻结清单(同一回滚点)下的全部 P0 及其后代。

跨批 = 新链、各自计数。禁止按单个 P0 编号拆链。

为什么必须写这句:不定义「链」时,读法 B(链 = 单个 P0 编号)也合文义 —— 每轮出新编号就开新链、各享 3 轮,预算一轮都拦不住。实测该读法下 3.11→3.14 那批 12 份报告可拆成 ≥4 个链,无一轮被拦,等于旧「计数重置」原样复现。

2.3 到顶处置(三件套,缺一即为静默失败)

  1. 不假装收敛(claudex-loop:present unresolved findings instead of manufacturing convergence)
  2. 未决项 + 己方立场 + 每轮反例输出,整理成一页交 chief 仲裁
  3. 同时在 UNREVIEWED.tsv 开一行 blocked(含复核期限 + 触发条件)—— 无登记 = 无追踪 = 未闭环 P0 蒸发

chief 裁决书必须显式写出:① 接受 / 驳回;② 授权追加的验证轮数 N(该 N 轮从预算豁免、单列计数)。

未裁决前不开新轮。继续修允许,继续以「回审」名义开轮不允许(除非裁决书显式授权)。

第 ② 条堵的洞:真 P0 在第 4 轮才发现时,若只允许「修」不允许「验证」,那个 P0 就永远无法闭环。

2.4 禁 relitigate

已判闭环的点在新一轮不再重审,除非提出新证据。

新证据 = 新的可复跑反例输出 —— 不是重读一遍代码,不是换个措辞重述原疑点。

2.5 回审任务书固定模板(2026-09-29 起)

禁止写「复核 P0/P1/P2 修复」这类全量措辞 —— 它会让 ops 重读全量。

任务书只写三项:

  1. diff
  2. 指定反例的运行输出
  3. 改动所在判据链的相邻判据

硬前置 = 实现方已跑的反例复跑输出(附在任务书内,不让 ops 自己造)。
要求 = 逐条判定反例是否被覆盖 + 有新 P0 附可执行反例 + 正文 ≤6KB(P2 一行)。

实测依据:新措辞 11 次工具调用 / 2.8 分钟 vs 旧措辞 57.9 次 / 10.7 分钟(1 : 5.3)。见第 4 节 counterfactual-task-template.sh。

3 · 落点与冻结值
#文件角色收工 md5
①/home/ubuntu/AGENTS.md §10母本d5df8d67
②profiles/ops/…/ops-independent-review/SKILL.md驱动 ops 写报告8f27e317
③skills/infrastructure/task-channel-routing/SKILL.md派发路由口径f975f38b
④skills/infrastructure/multi-profile-workflow/SKILL.md三 profile 协作流程c3947374

一致性校验口径(母本 11 词,逐项 ≥1,不看总数)

相邻判据 / 反事实 / 复核期限 / 无人值守消费者 / 计数重置 / UNREVIEWED
sha256 / 受保护 / 副本清单 / 运行时读取 / 注释不算

词在 ≠ 规则在:逐项还要读该词所在句子,确认它带的是规则而不是名单。本批里「计数重置」这个词保留在词表中,但语义由「生效」改为「已废除」。

4 · 证据与复跑

目录 ~/.hermes/backups/ops-retest-budget-20260929-0920/

文件作用
verify-11words.sh11 词母本校验 + 变异体自证
counterfactual.sh政策轨硬前置:真实历史案例跑新旧规则
reverse-p01-chain.shP0-1 自证:拆链读法下预算是否失效
evidence-11words.txt四份 0 缺口;变异体(删 6 词)报 6 缺口
evidence-counterfactual.txt3.11→3.14 链 12 份报告 → 新规则省 9 轮 ≈ 97 分钟
evidence-p01-chain.txt拆链读法 12 份可拆 ≥4 链 ⇒ 无一轮被拦;整批 3 轮 ⇒ 拦下 9 轮
kimi-review.md首审报告(2 P0 / 2 P1 / 1 P2)
kimi-review-round2.md增量回审(6 项反例全被覆盖,无新 P0)

变异体自证(判校验器本身灵不灵):删掉 6 个词后,11 词口径必须报出 6 个缺口;若只报 5 词会判「已同步」 = 假绿。

5 · 审查记录(kimi 异族,两轮)
级别发现修法
P0-1「链」未定义 ⇒ 可拆链绕过,预算形同虚设加链的可判定口径 + 明禁按编号拆链
P0-2a四副本层数不一致(① 三层 vs ②③④ 两层)① 改两层,与 ②③④ 对齐
P0-2b① 内部矛盾(「首审 1 轮」与「完整审查 ≤2 轮」冲突,事实废掉后者)删「首审 1 轮」层,明确「首审计入完整审查层」
P1-1chief 仲裁通道无追踪要求 ⇒ 未闭环 P0 可蒸发加「同时在 UNREVIEWED.tsv 开 blocked 行」
P1-2真 P0 晚发现时修允许、验证被禁 ⇒ 无法闭环加「裁决书须显式授权验证轮数 N,N 从预算豁免」
P2④ 中「59 次回审」笔误(应为 54)已改

增量回审(第 2 轮):冻结核对一致;6 项反例全部被覆盖,无新 P0 ⇒ 台账标 reviewed。新增 2 个 P2 已顺手修。

本批的流程违规(记录在案)

派审后改了冻结清单内的文件(AGENTS.md)—— 违反「审查期硬冻结」。两次写入均走 patch + 系统审批通过(不是 terminal 绕闸),但流程错了:正确做法是先 kill 审查、改完重派。

已补一条规则进 ④:派审前先冻结 —— 批内文件必须已落地且本轮不会再改;等审批的文件要么先落地再派、要么从冻结清单剔除并注明。冻结是派审的前置条件,不是事后核对项。

5.5 · 收敛效果评估(2026-10-13 起)

评估前提(owner 判断,2026-09-29)

「提高准确度的收益被繁复的过程消耗过多,收益反而不大」⇒ 必须收敛;且要评估是否有效收敛,没效就继续迭代。

三项判据(改后 ≥2 周样本):

  1. 硬规则守住:同一 P0 链最大回审轮数 ≤3(违反 = 机制失效)
  2. 过程成本下降:ops 总时长 / 派发次数低于改前(10 天 17.5 小时 / 129 次)
  3. 反向指标(最重要):没有出现「本该审到却漏掉」的 P0 —— 若出现,说明收敛过头,预算要回退

未达标时下一根杠杆(不是继续压轮数):

  1. 回审任务书措辞 —— 已于 2026-09-29 落地(见 2.5);实测这是杠杆最大的一条(1 : 5.3)
  2. 触发面执行率 —— §10 只列 5 类风险型触发,实际派发频次远高于触发面

本日实测:一批规则改动的过程成本(2026-09-29,主题=回审任务书固定模板)

⇒ 这组数字本身就是「提高准确度的收益被繁复的过程消耗过多」的样本:3 轮审查 × 3 次人工落地,换来 4 条 P0,其中 2 条是本可避免的自伤。

6 · 迭代方向(以后可能继续改)
  1. 预算数字需实践检验。2 / 3 轮是照实测分布定的(claudex-loop 用 5/2/2,loop-skills 用 6)。本机真 P0 少(9/21 统计:17 份报告里真 P0 只 5 条),3 轮够不够看后续数据。
  2. 「链」的跨批边界。现在按「同一批冻结清单(同一回滚点)」划链。若一个主题被硬拆成两批,理论上可绕开预算 —— 需观察是否真发生。
  3. chief 仲裁通道的实际响应率未验证。chief 是 on-demand profile,若没人派它,升级会悬置。已用 UNREVIEWED.tsv 登记兜底,首次实践要盯。
  4. 回审任务书模板(最直接的杠杆,尚未写进规则)。写「复核 P0/P1/P2 修复」会让 ops 读全量;应固定为「只验 ①diff ②1 个反例 ③相邻判据」。
  5. 报告体量。§10 定「正文 ≤6KB」,实测 evidence 常 10-19KB,reviews/ 目录已 99M(其中 93M 是单个 treemap-v6-artifacts)。清理项,与速度无关。
7 · 规则来源(MIT)

社区没有的东西:增量复审(只有 CodeRabbit 区分 review 增量 vs full review 全量)。§10 的设计超前于社区,问题是执行没落地 —— 所以这次抄的是控制机制,不是审查方法论。

源文档:ops-review-budget.md · 台账:~/.hermes/backups/reviews/UNREVIEWED.tsv · 2026-09-29