上一篇写的是季度 roadmap 决策进入新季度后，如何通过 first-month execution checkpoint 和 owner acceptance window，确认 owner 容量、阻塞项、证据约束和漂移信号没有在启动阶段被稀释。
但第一个月检查完之后，还会遇到一个更现实的问题：发现了漂移信号以后，团队到底怎么改 roadmap？
如果只是把问题记进周报，季度 roadmap 仍然会继续按原计划滚动。等到季度末复盘时，很多偏移已经变成事实，只能重新解释为什么没有完成。
这一篇写一个轻量做法：把 first-month drift signals 转成 monthly roadmap adjustment ledger，让季度执行在月末就能重新校准。
1. 月度调整不是重排整个季度 roadmap
monthly roadmap adjustment ledger 的目标不是每个月重做一次 roadmap。
它只处理第一个月真实执行暴露出的偏移：
1
2
3
4
5
6
7
8
9
10
11
| monthly_adjustment_scope:
in_scope:
- owner_capacity_drift
- blocking_work_bypassed
- evidence_contract_weakened
- new_dependency_or_incident_pressure
- acceptance_window_reopened
out_of_scope:
- new_strategy_theme_without_source_decision
- preference_based_priority_shuffle
- full_quarter_roadmap_rewrite
|
这里的边界很重要。
月度调整只改“已经被事实证明需要调整的部分”，不把 roadmap 重新变成开放讨论池。
否则每个月都会出现新的偏好、新的声音和新的紧急事项，季度复盘刚形成的决策顺序会很快失效。
2. ledger 的第一列必须是 drift signal
roadmap 调整不能从“我想改什么”开始。
它应该从 drift signal 开始：
1
2
3
4
5
6
7
8
9
10
| roadmap_adjustment_ledger:
- signal_id: drift_owner_capacity_release_platform_week_3
source_checkpoint: q1_w2_replay_gate_integrity_check
signal_type: owner_capacity_drift
observed_fact:
- incident_buffer_consumed_by_unplanned_policy_review
- replay_gate_manual_step_still_exists
- owner_declines_new_exception_preview_scope
affected_decision:
- allow_one_new_governance_item_with_incident_buffer
|
这样可以避免一个常见问题：团队先提出调整结论，再回头找理由。
ledger 的第一列是信号，后面才是影响范围、调整动作和 owner 重新承诺。
3. 每条调整都要绑定原始 roadmap decision
月度调整最怕变成新的孤立决策。
所以 ledger 中每条记录都要能追溯到原始 roadmap decision：
1
2
3
4
5
6
| adjustment_trace:
source_dispute: dispute_audit_replay_manual_step
source_decision: treat_remaining_manual_step_as_blocking_baseline_gap
original_roadmap_action: replay_gate_completion
first_month_checkpoint: q1_w2_replay_gate_integrity_check
monthly_signal: drift_owner_capacity_release_platform_week_3
|
这条 trace 的作用不是为了文档完整，而是为了防止调整动作越界。
如果某个调整找不到来源决策，它就不应该直接改季度 roadmap。更合理的处理方式是进入新的 dispute backlog，等待下一次有证据的评审。
4. 调整动作要分成三类
月度调整不应该只有“延期”这一种动作。
更稳的做法是把动作分成三类：保留、收窄、重开争议。
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
| adjustment_actions:
keep:
when:
- drift_signal_is_temporary
- owner_capacity_still_above_threshold
- evidence_contract_not_changed
output:
- keep_original_roadmap_action
- add_next_checkpoint
narrow:
when:
- capacity_buffer_is_consumed
- acceptance_criteria_too_large_for_month_2
- dependency_changed_but_decision_still_valid
output:
- reduce_scope
- freeze_non_blocking_subtasks
- restate_acceptance
reopen_dispute:
when:
- original_evidence_is_invalidated
- owner_rejects_capacity_contract
- blocking_work_is_bypassed_by_new_policy
output:
- reopen_decision_packet
- move_to_dispute_review
- stop_related_new_scope
|
这三类动作能让月度调整保持克制。
不是所有偏移都需要重开 roadmap；也不是所有偏移都能靠 owner “再努力一下”解决。
5. owner 需要重新确认 capacity contract
第一个月跑完后，owner capacity contract 往往会发生变化。
例如原计划中预留的 incident buffer 被临时审计消耗，或者某个跨团队依赖没有按时交付。
这时 monthly ledger 不能只写“进度有风险”。它要把 owner 的新容量约束写清楚：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| owner_capacity_reconfirmation:
owner: release_platform_team
original_contract:
max_new_governance_items: 1
incident_buffer_required: true
month_1_reality:
incident_buffer_consumed: true
blocking_work_remaining: replay_gate_manual_step
unplanned_dependency: audit_team_policy_review
revised_contract:
max_new_governance_items: 0
allowed_work:
- replay_gate_completion
- audit_policy_review_support
frozen_work:
- new_exception_preview_workflow
|
这个 reconfirmation 是 roadmap 调整的核心证据之一。
如果 owner 的容量合同变了，roadmap 就必须反映这个事实。否则后续执行只是在用旧承诺覆盖新现实。
6. evidence contract 也要被重新校准
除了容量，证据口径也容易在第一个月被稀释。
比如原本要求两个稳定 release cycle 的 API 使用证据，但执行中只拿到了一个 demo 或一次口头集成承诺。
ledger 中要明确证据是否仍然满足原 contract：
1
2
3
4
5
6
7
8
9
10
11
12
13
| evidence_recalibration:
decision: api_contract_entry_requires_two_cycles_of_stable_usage
accepted_evidence_status:
named_downstream_consumer: confirmed
stable_api_contract_for_2_release_cycles: missing
repeated_use_metric_above_threshold: missing
rejected_evidence_used:
- internal_demo_without_consumer
adjustment:
action: narrow
new_month_2_scope:
- keep_api_contract_observation
- do_not_promote_to_default_workflow_entry
|
这一步可以把“证据不够但先做起来”的风险拦在月度层面。
它不会否定方向，但会阻止缺证据的能力提前进入默认路径。
7. ledger 输出要能改执行包，而不是只改状态
一份有效的 adjustment ledger 最后必须能影响执行包。
如果输出只是“关注风险”“继续跟进”，它不会改变任何行为。
更可执行的输出应该像这样：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| monthly_adjustment_output:
ledger_id: 2026_q1_month_1_adjustment
changed_packages:
- package: replay_gate_completion
change: keep_as_blocking_work
month_2_acceptance:
- manual_step_removed_for_top_3_audit_paths
- replay_api_has_named_owner_signoff
- package: new_exception_preview_workflow
change: freeze
reason: owner_capacity_contract_reduced_to_zero_new_items
- package: api_contract_entry
change: narrow_to_observation
reason: evidence_contract_not_met
next_checkpoint:
week: month_2_week_2
verify:
- blocking_work_closed_or_reopened
- frozen_scope_not_started
- evidence_gap_reduced
|
注意这里的输出直接改变了执行包：保留阻塞项、冻结新范围、把某个能力收窄成观察项。
这才是 ledger 和普通风险清单的区别。
8. 一个最小模板
把上面的内容合起来，可以形成一个最小模板：
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
| monthly_roadmap_adjustment_ledger:
month: 2026_q1_month_1
inputs:
- first_month_checkpoint_result
- owner_acceptance_window_result
- drift_signal_list
- evidence_contract_status
rows:
required_fields:
- signal_id
- source_checkpoint
- source_roadmap_decision
- affected_package
- owner_capacity_status
- evidence_status
- adjustment_action
- changed_execution_package
- next_checkpoint
allowed_actions:
- keep
- narrow
- reopen_dispute
- freeze_scope
guardrails:
- no_adjustment_without_drift_signal
- no_new_scope_without_source_decision
- no_capacity_expansion_without_owner_reconfirmation
|
这个模板不复杂，但能让月度调整变得可追踪。
它把“发生了什么”“影响哪条决策”“owner 现在还能承诺什么”“执行包要怎么改”放在同一张表里。
小结
first-month checkpoint 负责发现季度 roadmap 在启动阶段有没有偏移。monthly roadmap adjustment ledger 负责把这些偏移转成可执行的调整。
月度调整不要重排整个季度 roadmap，也不要只写风险状态。它应该从 drift signal 开始，绑定原始 roadmap decision，重新确认 owner capacity 和 evidence contract，并输出对执行包的明确修改。
这样季度执行就不需要等到季度末才复盘失败原因。第一个月发现的偏移可以在月末被收进 ledger，第二个月继续用更真实的容量、证据和范围运行。
下一篇可以继续写第二个月 checkpoint 如何验证这些 adjustment 是否真正生效，尤其是 frozen scope 有没有被偷偷启动、evidence gap 有没有缩小、owner capacity contract 有没有再次漂移。
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-monthly-roadmap-adjustment-ledger-drift-signal-recalibration/