LLM 治理 roadmap 调整后的第二个月：验证冻结范围、证据缺口与 owner 容量是否再次漂移

发表于 分类于 阅读次数： Changyan： 本文字数： 4.6k 阅读时长 ≈ 4 分钟
接着 monthly roadmap adjustment ledger，这篇继续写第二个月如何验证调整动作是否真正生效，重点检查冻结范围有没有被重新打开、证据缺口是否缩小，以及 owner capacity contract 是否再次漂移。

上一篇把第一个月暴露出的 drift signals 整理成 monthly roadmap adjustment ledger，并用 keep、narrow、reopen dispute 三类动作更新季度执行包。

到了第二个月，问题不再是“有没有做调整”，而是调整有没有改变执行结果。

如果被冻结的范围又被悄悄打开，证据缺口仍然停在原地，owner 的容量承诺也再次失效，那么 ledger 只是留下了一次决策记录，并没有把季度 roadmap 拉回可执行状态。

这一篇继续往下走：设计一个 second-month adjustment checkpoint，用少量硬证据验证月度调整是否生效。

1. 第二个月不需要再做一次完整复盘

second-month adjustment checkpoint 的职责很窄，只回答三类问题：

1
2
3
4
5
6
7
second_month_checkpoint:
  scope_integrity:
    question: frozen_scope_still_frozen
  evidence_progress:
    question: evidence_gap_is_narrowing
  capacity_stability:
    question: owner_capacity_contract_still_valid

它不重新讨论季度目标，也不重新收集所有需求。

第一个月已经完成了 drift 识别和 adjustment decision，第二个月只验证这些决定是否被执行。如果再次开放全部议题，团队会把验证会重新开成优先级讨论会，原来的调整动作反而无法被评价。

2. 先检查被冻结的范围有没有被重新打开

月度调整里最常见的动作之一是 narrow：保留阻塞项，冻结非关键范围，把 owner 容量集中到最小交付包。

第二个月要检查的不是任务列表有没有更新，而是 frozen scope 是否仍然保持冻结：

1
2
3
4
5
6
7
8
9
10
11
scope_freeze_check:
  adjustment_id: adj_replay_gate_month_1
  frozen_items:
    - new_exception_preview
    - dashboard_visual_polish
    - non_blocking_policy_export
  validation:
    reopened_without_decision: 1
    hidden_work_hours: 12
    new_acceptance_items: 2
  result: failed

这里需要特别关注三种隐性 reopen：

  • 没有正式 decision，但任务重新进入迭代
  • 没有改 roadmap，却持续消耗 owner 工时
  • 没有新增 scope 记录，却在 acceptance criteria 中加了要求

只看 roadmap 状态，很容易得到“范围仍然冻结”的结论。把实际工时、验收项和迭代任务一起对照，才能发现冻结范围是否从旁路回来了。

3. 证据缺口要看 burn-down，不看文档数量

月度调整通常会重新校准 evidence contract，例如把“大而全的报告”收窄为几个能支撑决策的关键证据。

第二个月应该验证 evidence gap 是否缩小：

1
2
3
4
5
6
7
8
9
10
11
evidence_gap_burn_down:
  checkpoint_start:
    required: 6
    valid: 2
    missing: 4
  checkpoint_end:
    required: 6
    valid: 4
    missing: 2
  invalidated_during_month: 1
  net_gap_reduction: 2

这里的 valid 不能用“已上传文档”代替。

每份证据仍然要满足原来的有效性约束：来源明确、时间窗口正确、能够重放、能支撑对应 decision。否则团队可能新增了很多材料，但关键问题依旧没有答案。

如果 gap 数量下降，但新增证据全部来自过期窗口，checkpoint 仍然应该判定为未通过。

4. owner capacity contract 必须重新用实际投入校验

第一个月调整时，owner 可能重新承诺了容量：

1
2
3
4
5
6
7
capacity_contract:
  owner: governance_platform_owner
  committed_hours_per_week: 16
  incident_buffer_hours: 4
  protected_work:
    - replay_gate_completion
    - evidence_gap_closure

第二个月不能只问 owner“还能不能做完”，而要核对真实投入：

1
2
3
4
5
6
7
capacity_validation:
  committed_hours: 64
  actual_protected_work_hours: 36
  incident_hours: 18
  hidden_support_hours: 14
  capacity_variance: -28
  result: drifted_again

如果 capacity 再次漂移，需要区分两种情况：

  • 临时事件消耗了 buffer，但 protected work 仍在推进
  • 隐性支持和新增范围长期挤占了 protected work

第一种可以补一个短 checkpoint；第二种说明原 capacity contract 已经失效，不能继续依赖同一个交付承诺。

5. adjustment action 要用结果信号验收

不同 adjustment action 的成功信号不同。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
adjustment_effectiveness:
  keep:
    pass_when:
      - original_acceptance_progresses
      - temporary_drift_disappears
  narrow:
    pass_when:
      - frozen_scope_has_no_hidden_reopen
      - protected_work_receives_committed_capacity
  reopen_dispute:
    pass_when:
      - decision_packet_is_rebuilt
      - disputed_execution_is_paused
      - new_decision_has_owner_and_due_date

这一步能避免“动作已登记”被误当成“动作已生效”。

例如 ledger 中已经记录 narrow，但 owner 的实际工时仍被冻结项占用，这条调整就应该判定为 failed，而不是 in progress。

6. 第二次漂移不能继续只追加备注

同一类 drift 在第二个月再次出现时，处理级别应该升级。

1
2
3
4
5
6
7
8
9
10
11
12
13
repeat_drift_routing:
  first_occurrence:
    action: monthly_adjustment
  second_occurrence:
    action:
      - mark_adjustment_failed
      - stop_new_scope
      - reopen_owner_capacity_decision
      - escalate_to_quarterly_roadmap_owner
  third_occurrence:
    action:
      - remove_unreliable_commitment
      - rebuild_delivery_baseline

原因很简单：第一次漂移可能来自估算误差，第二次同类漂移通常说明约束没有被真正执行。

如果团队继续在 ledger 后面追加说明，roadmap 会保留一个形式上的承诺，但所有人都知道它已经无法按原条件完成。这种“未正式失败”的状态最容易持续消耗容量。

7. checkpoint 输出只保留四种结果

为了让第二月检查能直接改变执行包，输出状态不宜过多：

1
2
3
4
5
checkpoint_result:
  - validated
  - validated_with_follow_up
  - adjustment_failed
  - decision_reopened

对应动作可以固定下来：

结果 含义 后续动作
validated 调整有效，核心约束稳定 保持当前 roadmap
validated_with_follow_up 主体有效，但存在可收敛缺口 增加一次短 checkpoint
adjustment_failed 冻结、证据或容量约束再次失效 停止新增范围并升级处理
decision_reopened 原决策依据已经不成立 重建 decision packet

不要使用“基本完成”“继续关注”这类无法触发动作的状态。checkpoint 的价值在于让下一步明确，而不是让问题显得没那么严重。

8. 一个最小 checkpoint 模板

可以把第二个月检查压缩成一份短记录：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
second_month_adjustment_checkpoint:
  checkpoint_id: q1_month_2_adjustment_validation
  source_adjustment_ledger: q1_month_1_roadmap_adjustments

  scope_integrity:
    frozen_items: 3
    hidden_reopen_count: 0
    result: passed

  evidence_progress:
    gap_at_start: 4
    gap_at_end: 2
    invalidated_evidence: 0
    result: passed

  capacity_stability:
    committed_hours: 64
    protected_work_hours: 52
    unplanned_hours: 12
    result: warning

  adjustment_effectiveness:
    action: narrow
    result: validated_with_follow_up

  follow_up:
    owner: governance_platform_owner
    due: 2026-08-01
    check:
      - protected_work_hours_recover
      - remaining_evidence_gap_closed

这份模板不追求覆盖所有执行细节，只保留能判断调整是否有效的证据。

小结

monthly roadmap adjustment ledger 解决的是第一个月“发现漂移后怎么改”的问题，second-month adjustment checkpoint 解决的是“改完以后有没有真的变好”。

最小闭环可以概括为：

  1. 检查 frozen scope 有没有通过任务、工时或验收项被重新打开
  2. 用有效证据的 gap burn-down 判断 evidence contract 是否在收敛
  3. 用真实投入重新验证 owner capacity contract
  4. 按 adjustment action 的结果信号验收，而不是只看登记状态
  5. 同类 drift 第二次出现时升级处理，停止用备注掩盖失效承诺

这样，季度 roadmap 的月度调整才不是一次文档修订，而是一组可以在第二个月被证伪、被升级、也能被确认有效的执行约束。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-second-month-adjustment-checkpoint-scope-evidence-owner-capacity-validation/