上一篇写的是季度复盘素材回灌：周级风险信号、owner 承诺结果、stale 处理、升级记录和关闭证据，应该沉淀成季度复盘可以直接消费的材料。
复盘材料准备好以后，还有一个更容易被忽略的动作：把复盘结论写回下季度的准入规则。
很多团队会在季度复盘会上说清楚问题，却在下一轮 roadmap 里重新放进同类需求。风险换了一个名字，owner 还是同一批人，容量还是没有腾出来，上一季度已经证明失效的推进方式继续被沿用。
这样复盘就只停在解释层。它解释了上一季度为什么偏差，却没有改变下一季度怎么进项目、谁能接、什么时候必须挡掉。
这一篇就写一个最小机制：季度复盘结论如何转成 admission rule、owner capacity constraint 和 carryover risk，让同类风险不要原样回到下一轮计划里。
1. 复盘结论先拆成三类输入
季度复盘结束时，不要只留下“继续推进”“加强协同”“补齐能力”这类结论。
它至少要拆成三类输入：
1
2
3
4
5
6
7
| quarterly_retrospective_outputs:
rule_change:
- what_should_be_allowed_or_blocked_next_quarter
capacity_constraint:
- which_owner_or_team_has_real_available_capacity
carryover_risk:
- which_gap_enters_next_quarter_with_explicit_risk_state
|
rule_change 用来改变下季度准入规则。
capacity_constraint 用来约束 owner 和交付包数量。
carryover_risk 用来标记没有关闭、但仍然会影响下季度承诺的风险。
这三类输入分别回答三个问题：哪些需求还能进，谁真的接得住，哪些风险不能假装已经清掉。
如果复盘结论没有被拆到这个粒度，下一轮排期时很容易回到熟悉的讨论方式：看起来重要的都想做，声音更大的先进入 roadmap，上一季度暴露的容量问题继续被压在执行阶段。
2. 准入规则不是价值排序
admission rule 不是判断一个想法有没有价值。
它判断的是：这个想法在下一个季度是否已经具备进入计划的条件。
例如季度复盘发现“自助诊断页面上线了，但没有进入 ticket 工作流，试点团队没有反复使用”。这不代表自助诊断没有价值，它说明下季度不能再接受只做页面、不绑定工作流入口的需求。
1
2
3
4
5
6
7
8
9
10
11
| admission_rule_change:
source_finding: self_service_page_ready_but_repeated_use_not_formed
next_quarter_rule:
benefit_capability:
accept_when:
- has_workflow_entry
- has_named_pilot_team_owner
- has_repeated_use_metric
reject_when:
- only_adds_page_or_report
- no_team_commits_to_use_in_existing_flow
|
这个规则把复盘结论变成了下季度的门槛。
再有人提出“做一个更完整的诊断页”，准入讨论就不用重新争论价值。它只需要检查：入口是否进入真实工作流，pilot owner 是否明确，重复使用指标是否存在。
没有这些条件，需求可以保留为候选，但不要进入季度承诺。
3. 反复出现的风险不能换名重进
季度复盘里最值得警惕的是 recurring risk。
它们上一季度出现过，没有被真正关闭，下季度又换成新的需求名进入计划。
例如：
1
2
3
4
5
6
7
| recurring_risk_detection:
previous_risk: release_gate_can_ship_without_required_evidence
new_request: add_policy_exception_preview_before_release
overlap:
- same_release_gate_owner
- same_missing_evidence_contract
- same_audit_replay_dependency
|
新需求看起来是“exception preview”，但它仍然依赖 release gate 证据契约。如果上一季度证据链没有补齐，下季度直接做 preview，只会把风险搬到另一个界面里。
可以给 recurring risk 加一条硬规则：
1
2
3
4
5
6
7
8
9
| recurring_risk_admission_rule:
block_when:
- same_gap_not_closed
- same_owner_capacity_not_changed
- no_new_evidence_or_dependency_removed
allow_when:
- closure_evidence_exists
- owner_capacity_reserved
- scope_reduced_to_close_original_gap
|
这条规则不是用来阻止新想法。它要求每个新想法解释清楚和上一季度风险的关系。
如果它只是换了标题，就应该挡住。如果它真的把原风险收窄成一个可关闭动作，可以进入，但必须把关闭证据和容量预约写清楚。
4. owner 容量要变成准入字段
很多季度计划失败，并非需求判断本身错了。更常见的原因是 owner 容量被当成默认存在。
复盘以后，下季度准入字段里应该有 owner capacity：
1
2
3
4
5
6
7
8
| owner_capacity_constraint:
owner: release_platform_team
quarter: 2026_q4
reserved_capacity:
baseline_maintenance: 40
committed_delivery_packages: 45
incident_buffer: 10
available_for_new_items: 5
|
这个字段不需要精确到工时，但要足够明确：某个 owner 在下季度还能接多少新增治理动作。
如果 available_for_new_items 只有 5%，就不能再让这个 owner 同时承接三个新交付包。即使每个交付包都合理，组合起来也不合理。
owner 容量不是执行阶段才暴露的风险，它应该在准入阶段就被看见。
5. 交付包数量也要受容量约束
owner 容量不能只停在单个需求层面。它要影响交付包数量。
例如下季度候选队列是：
1
2
3
4
5
6
7
8
9
10
| candidate_delivery_packages:
- name: evidence_replay_gate_completion
primary_owner: release_platform_team
capacity_need: 25
- name: exception_preview_workflow
primary_owner: release_platform_team
capacity_need: 20
- name: policy_hit_self_service_adoption
primary_owner: workflow_team
capacity_need: 30
|
如果 release platform team 的剩余容量只有 25%，就不能同时接受前两个包。
准入结果应该直接写出来：
1
2
3
4
5
6
7
8
| admission_result_with_capacity:
accepted:
- evidence_replay_gate_completion
deferred:
- exception_preview_workflow
reason:
- release_platform_team_capacity_exhausted
- exception_preview_depends_on_replay_gate_completion
|
这样延期就不再是“排不过来”这种模糊说法。真正原因会落到容量和依赖都不支持它进入本季度。
这也能减少下季度中途的被动调整。已经知道同一个 owner 接不住，就不要把风险留给执行阶段。
6. carryover risk 必须带状态进入下季度
上一季度没有关闭的风险，不应该在下季度自动变成普通 backlog。
它要带着状态进入：
1
2
3
4
5
6
7
8
9
10
| carryover_risk_record:
risk: audit_replay_manual_step_remaining
source_quarter: 2026_q3
current_state: accepted_until
accepted_until: 2026-10-31
acceptance_owner: governance_platform_lead
required_next_decision:
- close_with_replay_api
- extend_acceptance_with_reason
- escalate_to_blocking_baseline
|
这份记录让下季度计划无法假装风险已经消失。
如果风险被接受，就写明接受到什么时候、谁负责重新判断、到期后有哪些选择。
如果风险已经影响现有治理承诺，就不要以“优化项”身份进入 backlog。它应该作为 baseline 缺口进入下季度，并明确是否阻塞其他收益型能力。
7. 准入规则要有生效窗口
下季度准入规则不应该无限期有效。
它来自某一次复盘，就应该有生效窗口和复查时间：
1
2
3
4
5
6
7
8
9
| admission_rule_lifecycle:
rule: benefit_capability_requires_workflow_entry
source: 2026_q3_retrospective
effective_quarter: 2026_q4
owner: governance_platform_team
review_at: 2026_q4_retrospective
expire_when:
- repeated_use_metric_stabilized_for_2_quarters
- workflow_entry_becomes_default_platform_contract
|
这样规则不会变成新的僵化流程。
有些规则只是为了解决一个阶段性问题。比如自助诊断入口尚未进入工作流时，需要强制要求 workflow entry。等它变成平台默认契约以后，这条准入规则可以降级成普通检查项。
治理规则也要治理。否则复盘越做越多，门槛越堆越厚，久了团队会绕开规则，而不是使用规则。
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
28
29
| llm_governance_next_quarter_admission:
quarter: 2026_q4
source_retrospective: 2026_q3
rule_changes:
- rule: benefit_capability_requires_workflow_entry
source_finding: self_service_page_ready_but_repeated_use_not_formed
effective_quarter: 2026_q4
- rule: recurring_risk_cannot_reenter_without_new_evidence
source_finding: release_gate_evidence_gap_reappeared
effective_quarter: 2026_q4
owner_capacity:
release_platform_team:
available_for_new_items: 5
accepted_packages:
- evidence_replay_gate_completion
deferred_packages:
- exception_preview_workflow
workflow_team:
available_for_new_items: 30
accepted_packages:
- policy_hit_self_service_adoption
carryover_risks:
- risk: audit_replay_manual_step_remaining
state: accepted_until
accepted_until: 2026-10-31
next_decision_owner: governance_platform_lead
rejected_or_deferred:
- item: exception_preview_workflow
reason: depends_on_replay_gate_completion_and_owner_capacity_exhausted
|
这份模板不追求复杂。它只是把复盘结论连接到下季度计划入口。
准入会上不再只问“这个需求重不重要”，还要问：上一季度相关风险是否关闭，owner 是否有容量，同类风险是否换名重进，carryover risk 是否已经明确接受或阻塞。
9. 复盘会后要马上更新准入表
准入规则最好不要等到下季度规划会才写。
季度复盘会结束后的当天，就应该把规则变化和容量约束写进准入表。时间拖得越久，复盘里的细节越容易丢失。
一个可操作的节奏是：
1
2
3
4
5
6
7
8
9
10
11
12
| retrospective_to_admission_flow:
day_0:
- finish_quarterly_retrospective
- classify_outputs_into_rule_capacity_carryover
day_1:
- update_next_quarter_admission_table
- confirm_owner_capacity_with_team_leads
day_2:
- apply_rules_to_candidate_delivery_packages
- mark_accepted_deferred_rejected
planning_day:
- review_only_disputed_items
|
规划会只处理争议项，不重新整理所有材料。
这样做可以让复盘和规划之间形成连续动作。复盘不是季度末的总结文档，规划也不是从空白列表开始排优先级。
小结
季度复盘真正产生作用的地方，不在复盘报告里，而在下季度入口处。
把复盘结论拆成准入规则、owner 容量约束和 carryover risk，能让下一轮 roadmap 少带旧问题进场。反复出现的风险不能换名重进，owner 容量不能默认存在，没有关闭的 baseline 缺口也不能降级成普通优化项。
下季度计划因此会更窄，但更真实。它承认上一季度暴露过的边界，也把这些边界写进新的准入条件。
下一篇可以继续写下季度启动以后，如何用前几周的执行信号校验这些 admission rule 是否真的有效，避免规则写得很漂亮，执行时又被例外慢慢掏空。
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-quarterly-retrospective-next-quarter-admission-rule-owner-capacity-constraint/