上一篇写的是下季度启动后的前几周，如何用 rule trace、exception pressure、owner capacity 和 carryover risk 检查准入规则有没有被现实慢慢削弱。
启动校验只能解决早期失真。进入月度执行节奏以后，新的问题会出现：规则压力被拆散在周会、项目同步、风险看板和 owner 私下协调里，等到季度末复盘时，大家只能凭印象讨论“这条规则是不是太硬”。
如果没有月度回灌机制，admission rule 会在两个极端之间摆动。要么坚持原规则，把真实执行困难压成例外；要么在执行中不断让步，季度末才发现规则已经没有约束力。
这一篇写一个轻量做法：把 rule pressure 和 drift ledger 放进月度执行节奏，让规则修订不等到季度末。
1. 月度节奏要接住启动期信号
启动校验结束后，不要只产出一个健康结论。
每条 admission rule 都应该带着状态进入月度执行会：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| monthly_rule_feedback_input:
month: 2026-10
source_window:
from: 2026-10-01
to: 2026-10-21
rules:
recurring_risk_cannot_reenter_without_new_evidence:
startup_health: stressed
pressure_events: 3
drift_types:
- sequence_bypass
- evidence_gap
open_decision:
- keep_rule_and_reduce_preview_scope
benefit_capability_requires_workflow_entry:
startup_health: needs_revision
pressure_events: 1
open_decision:
- add_api_contract_path_to_acceptance
|
这份输入的目的很简单：月度执行会要带着过去三周已经发生的压力进入讨论，不能从空白状态重新判断。
如果某条规则在启动期被压了三次，月度会就要给动作。继续观察只会把判断推到下个月。
2. 把规则压力放进固定议程
很多执行会只看交付进度、风险红黄绿和下周动作。admission rule 的压力如果没有固定位置，很容易被归入“其他问题”。
可以在月度执行节奏中增加一个很短的议程块：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| monthly_execution_agenda:
recurring_items:
- delivery_package_progress
- owner_capacity_delta
- external_dependency_risk
- admission_rule_pressure
- carryover_risk_closure
admission_rule_pressure:
max_discussion_minutes: 20
required_outputs:
- keep_rule
- revise_rule
- reduce_scope
- defer_item
- escalate_to_quarterly_decision
|
这里不需要开成规则评审大会。20 分钟足够处理最关键的几条压力。
重点是输出必须是动作，而不是“已同步”“持续跟进”。规则压力如果只被记录，没有对应动作，下一次还会以同样方式出现。
3. 区分月度可改和季度才改
并不是所有 admission rule 都能在月度会直接修订。
有些规则属于季度级边界，比如年度可靠性 baseline、跨团队容量上限、强合规证据要求。它们可以在月度会上形成建议，但不应该被当场放松。
可以给规则加一个修订层级：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| rule_revision_level:
rules:
owner_capacity_must_be_available_before_acceptance:
level: monthly_adjustable
allowed_monthly_actions:
- reduce_scope
- split_package
- freeze_new_items
recurring_risk_cannot_reenter_without_new_evidence:
level: quarterly_guardrail
allowed_monthly_actions:
- reject_exception
- require_new_evidence
- escalate_for_quarterly_revision
benefit_capability_requires_workflow_entry:
level: monthly_adjustable
allowed_monthly_actions:
- add_api_contract_path
- clarify_consumer_metric
|
monthly_adjustable 的规则可以在月度会改判定方式。
quarterly_guardrail 的规则只允许收缩范围、补证据或升级讨论，不允许临时放松。这样做能避免执行压力把季度边界拆掉。
4. drift ledger 要转成月度决策队列
drift ledger 只记录事件还不够。
到了月度会，它要变成一个决策队列：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| monthly_drift_decision_queue:
month: 2026-10
items:
- rule: recurring_risk_cannot_reenter_without_new_evidence
drift_event: pilot_team_added_without_repeated_use_metric
drift_type: evidence_gap
owner: governance_pm
decision_needed_by: 2026-10-28
options:
- reject_pilot_scope
- require_repeated_use_metric_before_expansion
- escalate_to_quarterly_guardrail_review
current_decision: require_repeated_use_metric_before_expansion
- rule: benefit_capability_requires_workflow_entry
drift_event: internal_api_used_by_two_downstream_services
drift_type: acceptance_path_gap
owner: platform_arch
decision_needed_by: 2026-10-28
options:
- keep_workflow_entry_required
- add_api_contract_path
current_decision: add_api_contract_path
|
这样每个 drift event 都有 owner、期限和选项。
没有这个队列，ledger 很容易变成事后材料。队列让它进入执行层，不必等季度复盘才处理。
5. owner 容量变化要回写到准入判断
月度执行节奏里最容易被低估的是 owner 容量。
很多团队会在月度会上承认容量变了，但仍然维持原交付范围。结果 admission rule 的容量约束名义存在，实际靠透支解决。
可以把容量变化直接回写到准入判断：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| owner_capacity_feedback:
month: 2026-10
owner: release_platform_team
original_capacity_for_admitted_items: 5
actual_capacity_after_incident_and_hotfix: 1
affected_packages:
- replay_gate_completion
- preview_policy_cleanup
admission_feedback:
replay_gate_completion:
action: keep_minimum_closure
removed_scope:
- preview_ui_refinement
preview_policy_cleanup:
action: defer_to_next_month
reason:
- owner_capacity_below_admission_threshold
|
这一步很关键。容量变化不能只停在周报背景里，它会改变 admission rule 的输入。
只要真实容量低于准入阈值，就必须触发缩范围、拆包或延期。否则容量规则会变成摆设。
6. carryover risk 每月只问关闭证据
carryover risk 不适合每月重新讲背景。
月度会上只问两个问题：原风险有没有关闭证据；如果没有，当前动作是否改变了风险状态。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| carryover_risk_monthly_check:
risk: audit_replay_manual_step_remaining
original_closure_condition:
- replay_api_covers_top_3_audit_paths
- manual_step_removed_from_release_gate
current_month_actions:
- add_replay_log_filter
- improve_replay_page_entry
closure_evidence:
replay_api_covers_top_3_audit_paths: false
manual_step_removed_from_release_gate: false
monthly_decision:
status: still_open
action:
- keep_as_baseline_gap
- reject_closure_by_ui_improvement_only
|
这个检查能挡住一种常见漂移：用相关优化替代风险关闭。
优化可以继续做，但不能把 carryover risk 标成已关闭。月度节奏要保留这条线。
7. 给每条修订留下 decision trace
月度会如果改了 admission rule，需要留下最小 decision trace。
不需要长文档，至少要写清楚：改了什么、依据是什么、哪些限制仍然保留。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| admission_rule_monthly_revision:
rule: benefit_capability_requires_workflow_entry
previous_acceptance:
- must_have_workflow_entry
- must_have_repeated_use_metric
observed_signal:
- two_downstream_services_call_api_contract_weekly
- no_manual_workflow_entry_needed_for_internal_capability
revised_acceptance:
- has_workflow_entry
- or_has_stable_downstream_api_contract
- must_have_repeated_use_metric
kept_restrictions:
- named_consumer_required
- no_metric_no_admission
decision_owner: platform_arch
effective_from: 2026-10-29
|
没有 trace 的修订，到了下个月很难分清是规则升级，还是执行让步。
尤其是 admission rule 这种会影响准入边界的规则，每次修订都要保留约束仍然存在的部分。
8. 一个最小月度回灌模板
把上面的动作合起来，可以形成一份很轻的月度模板：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| monthly_admission_feedback_loop:
month: 2026-10
inputs:
- startup_admission_validation
- weekly_risk_dashboard
- owner_capacity_delta
- drift_ledger
- carryover_risk_check
meeting_blocks:
admission_rule_pressure:
output_required: true
drift_decision_queue:
owner_and_due_date_required: true
capacity_feedback:
update_admission_status: true
carryover_risk:
closure_evidence_required: true
outputs:
- rule_kept
- rule_revised_with_trace
- scope_reduced
- item_deferred
- guardrail_escalated_to_quarterly_review
|
这份模板不追求完整治理系统。
它只做一件事：把启动期和周度节奏里已经暴露的规则压力，带回月度执行层处理。
小结
admission rule 不应该只在季度规划和季度复盘里出现。
启动期暴露的 rule pressure、drift ledger、owner capacity delta 和 carryover risk 状态，都要进入月度执行节奏。月度会要决定哪些规则保持不变，哪些规则可以修订，哪些交付包需要收缩，哪些边界必须升级到季度级讨论。
规则修订要快，也要保留 trace。团队要能看到每一次修订来自什么信号，仍然保留哪些限制。这样 admission rule 才能在执行中调整，同时不失去原本的约束力。
下一篇可以继续写月度回灌之后，如何把 rule revision trace 和 owner capacity 变化沉淀成下一轮季度复盘材料，避免复盘重新收集证据。
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-rule-pressure-monthly-execution-rhythm-drift-ledger-feedback-loop/