LLM 治理季度复盘怎么归因：区分执行失败、前提失效与容量配置错误

发表于 分类于 阅读次数： Changyan： 本文字数： 7.1k 阅读时长 ≈ 6 分钟
接着季度结束前的 keep、remove、reopen 决策，这篇整理一套季度复盘偏差分类方法，用证据区分执行失败、前提失效与容量配置错误，并把结论转成下一季度 admission rule。

上一篇在季度结束前给每项 commitment 做恢复预测，并用 keep、remove、reopen 提前完成止损。

这些决策解决了“本季度还要不要继续投入”，却没有回答另一个会影响下季度的问题：承诺为什么偏离原计划。

如果季度复盘只留下“延期”“资源不足”“需求变化”这样的宽泛结论，下一季度很难据此修改准入规则。同一种偏差还会换个项目名称重新进入 roadmap。

这一篇继续往下走：建立季度偏差分类账，区分 execution_failure、premise_invalidation 和 capacity_allocation_error，再把不同归因分别转成下一季度的 admission rule。

1. 不要从最终状态直接推断原因

remove 不等于执行失败，reopen 也不一定说明最初决策错误。

同样是季度内未交付，背后的链路可能完全不同：

1
2
3
4
5
6
7
8
9
10
11
12
quarter_end_results:
  replay_gate:
    decision: remove
    possible_cause: execution_failure

  automated_exception_approval:
    decision: reopen
    possible_cause: premise_invalidation

  evidence_dashboard:
    decision: remove
    possible_cause: capacity_allocation_error

复盘要回到承诺进入季度时的 decision packet，对照当时的前提、容量合同、依赖和验收证据，检查偏差从哪里开始出现。

只看最终状态，会把不同问题都压成“交付管理不到位”。结果往往是给所有项目增加同一套审批和汇报动作，却没有修正真正失效的准入条件。

2. 三类偏差各自回答什么问题

可以先用三个问题做初步分流：

偏差类型 关键问题 典型信号
execution_failure 已确认的方案和条件是否没有被按约执行 milestone 连续错过、已保护容量被挪用、证据任务长期无人处理
premise_invalidation 原决策依赖的事实或假设是否已经失效 风险等级变化、用户路径变化、上游能力替代原方案
capacity_allocation_error 进入季度时的资源配置是否从一开始就不成立 同一 owner 承担过多关键路径、依赖团队没有预留容量、运营成本漏算

这三类偏差的处理对象不同：

  • 执行失败要改执行门禁、升级路径和 owner accountability
  • 前提失效要改假设有效期、重验触发器和 decision reopen 条件
  • 容量配置错误要改准入时的容量证明、并发上限和依赖预留规则

分类的目的不是找一个方便追责的标签，而是确定下一次应该在哪个入口阻止同类问题。

3. execution failure：条件仍成立，但执行链断了

一项承诺可以归为执行失败，需要同时确认两件事：原决策前提在主要执行窗口内仍成立，准入时配置的资源也曾真实可用。

1
2
3
4
5
6
7
8
9
10
variance_evidence:
  commitment_id: replay_gate
  premise_valid_during_window: true
  committed_capacity_available: true
  acceptance_contract_unchanged: true
  execution_trace:
    milestone_missed: 3
    escalation_triggered: false
    evidence_tasks_overdue: 4
  primary_variance: execution_failure

常见问题并不是技术难度估错，而是已有约束没有进入日常执行：

  • milestone 已连续错过，但没有触发 scope review
  • owner 容量被临时工作挤占后，没有重新确认 commitment
  • acceptance 已定义，开发完成后才开始准备证据
  • 依赖逾期已有记录，却没有按约升级或隔离

对应的 admission rule 不应简单提高审批层级。更有效的改动是要求候选项在准入前给出可执行的 escalation contract，并把连续失约后的默认动作写清楚。

1
2
3
4
5
6
7
8
9
admission_rule_update:
  rule: execution_escalation_contract
  require:
    - milestone_owner
    - overdue_threshold
    - scope_reduction_action
    - escalation_recipient
  reject_when:
    - overdue_has_no_default_action

4. premise invalidation：执行对象已经变了

有些承诺按原计划继续做下去也能完成，但完成后已无法支持原来的治理目标。

例如，一个自动审批能力最初只覆盖内部低风险请求，季度中途却被要求处理外部客户数据。交付团队没有偏离方案，原方案适用的风险前提已经不存在。

1
2
3
4
5
6
7
8
9
10
premise_change:
  commitment_id: automated_exception_approval
  original_premise:
    data_scope: internal_only
    risk_level: low
  changed_signal:
    data_scope: external_customer_data
    detected_at: month_2
  old_acceptance_still_meaningful: false
  primary_variance: premise_invalidation

这类偏差需要检查两个时间点：变化何时发生，团队何时能够合理发现。

如果信号出现后很久才被看到，除了记录前提失效，还要补一个次要归因，例如 signal_detection_gap。但不能因为检测较晚，就把主要原因改写成执行失败。

下一季度的规则更新应围绕 premise freshness：

1
2
3
4
5
6
7
8
9
10
admission_rule_update:
  rule: premise_freshness_and_revalidation
  require:
    - named_critical_premises
    - premise_owner
    - validity_window
    - invalidation_signal
    - reopen_deadline
  reject_when:
    - critical_premise_has_no_observable_signal

这样，前提变化会触发 decision reopen，而不是等到验收阶段才发现交付对象已经失去意义。

5. capacity allocation error：承诺进入季度时就超配了

“资源不足”经常被写成不可解释的外部原因。复盘时要继续追问：容量是在执行中被意外打断，还是 roadmap 在准入时就分配了不存在的资源。

1
2
3
4
5
6
7
8
9
10
capacity_variance:
  commitment_id: evidence_dashboard
  admission_snapshot:
    required_owner_hours: 160
    protected_owner_hours: 80
    shared_owner_concurrent_commitments: 4
    dependency_capacity_confirmed: false
  execution_interruptions:
    unplanned_incident_hours: 8
  primary_variance: capacity_allocation_error

上面的主要缺口在准入时已经存在。即使季度内没有事故，承诺也缺少完成所需的容量。把它归为 execution failure，会让团队去优化执行节奏，却继续允许超配项目进入下个季度。

容量配置错误常见于：

  • 用团队总人力替代关键 owner 的可用容量
  • 只估开发时间，没有计算回归、观察和证据冻结成本
  • 外部依赖口头同意，但没有形成容量确认
  • 多项 high-priority commitment 共用同一个不可替代角色
  • 把上季度未完成项直接顺延，没有重新参与容量竞争

对应规则需要把 capacity proof 放进 admission packet：

1
2
3
4
5
6
7
8
9
10
11
admission_rule_update:
  rule: capacity_proof
  require:
    - critical_role_hours
    - protected_capacity_window
    - dependency_capacity_acceptance
    - operational_and_evidence_cost
    - concurrent_commitment_count
  reject_when:
    - protected_capacity_below_minimum
    - critical_owner_exceeds_concurrency_limit

6. 主归因只能有一个，次要因素可以保留

真实项目经常同时出现多个问题。如果给一项承诺贴上三个并列主标签，规则更新仍然会失去焦点。

可以用“最早足以改变决策的偏差”确定 primary variance：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
variance_classification:
  commitment_id: policy_replay_automation
  candidate_causes:
    - type: capacity_allocation_error
      observable_at: admission
      decision_impact: should_not_have_entered
    - type: execution_failure
      observable_at: month_1
      decision_impact: milestone_would_be_missed
    - type: premise_invalidation
      observable_at: month_2
      decision_impact: solution_scope_should_change

  primary_variance: capacity_allocation_error
  contributing_factors:
    - execution_failure
    - premise_invalidation

这里的容量错误在 admission 时已经足以阻止项目进入季度，因此它是主归因。后续的执行和前提问题仍然保留，分别进入改进行动，但不抢占主要规则修订方向。

7. 用反事实问题校验归因

归因会议容易受到角色立场影响。可以用三个反事实问题做交叉检查：

  1. 如果执行完全按计划进行，这项承诺能否在原 acceptance 下成立？不能，则更接近前提失效。
  2. 如果没有任何临时打断，准入时确认的容量是否足够？不够，则更接近容量配置错误。
  3. 如果前提和容量都保持不变，既有执行约束是否仍然被违反？是，则更接近执行失败。

反事实判断必须引用可追溯记录，不能只依赖复盘现场的回忆：

  • admission decision packet
  • owner capacity acceptance
  • milestone 与 escalation trace
  • premise change signal
  • acceptance 与 evidence contract 变更记录
  • pre-quarter-end keep / remove / reopen 决策

缺少关键证据时，状态应标记为 classification_pending，并记录证据 owner 和截止时间。不要用投票填补事实空白。

8. 从偏差账本生成下一季度规则变更

季度复盘不需要为每个失败项新增一条永久规则。可以先聚合重复偏差，再决定规则是新增、收紧还是保持观察。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
quarterly_variance_summary:
  execution_failure:
    count: 3
    repeated_pattern: escalation_not_triggered
    rule_action: tighten

  premise_invalidation:
    count: 2
    repeated_pattern: risk_scope_changed_without_reopen
    rule_action: add

  capacity_allocation_error:
    count: 5
    repeated_pattern: shared_owner_overcommitted
    rule_action: add_hard_gate

规则变更至少要包含五项信息：

字段 用途
source_variance 指向触发变更的偏差记录
rule_change 描述新增、收紧、放宽或删除的内容
expected_prevention 说明它准备提前阻止什么
rule_owner 负责执行和解释规则的人
review_after 防止规则永久累积的复查时间

例如：

1
2
3
4
5
6
7
next_quarter_admission_rule_change:
  source_variance: shared_owner_overcommitted
  rule_change: critical_owner_concurrency_limit_2
  expected_prevention: reject_commitments_without_protected_capacity
  rule_owner: governance_program_owner
  effective_quarter: 2026_q4
  review_after: 2026_q4_month_2

9. 规则更新也需要控制副作用

一次偏差不应自动换来一条更重的流程。

如果每次执行失败都增加审批人，admission 会越来越慢，owner 仍然可能没有可用容量。规则评审要检查三类副作用：

  • 是否把局部问题扩大到所有低风险项目
  • 是否增加了无法被验证的材料要求
  • 是否把责任从明确 owner 稀释到更多审批角色

可以给新规则保留一个最小验证窗口：

1
2
3
4
5
6
7
8
9
rule_validation:
  rule: critical_owner_concurrency_limit_2
  observe:
    - rejected_overcommitment_count
    - admitted_commitment_recovery_rate
    - admission_cycle_time_delta
  rollback_when:
    - cycle_time_cost_exceeds_prevention_benefit
  review_at: month_2_checkpoint

规则既要能阻止重复偏差，也要在成本过高或没有效果时允许回退。

10. 一个最小季度偏差与规则更新模板

整套复盘可以压缩成一份可审查记录：

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
quarterly_variance_review:
  commitment_id: evidence_dashboard
  quarter_end_decision: remove

  evidence:
    premise_valid: true
    required_owner_hours: 160
    protected_owner_hours: 80
    execution_contract_followed: partially

  classification:
    primary: capacity_allocation_error
    contributing:
      - execution_failure
    rationale: capacity_gap_existed_at_admission

  next_quarter_rule:
    change: require_critical_role_capacity_proof
    owner: governance_program_owner
    effective_quarter: 2026_q4
    review_at: month_2_checkpoint

  trace:
    source_decision_packet: q3_evidence_dashboard_admission
    source_stop_loss: q3_evidence_dashboard_remove

模板保持短小，关键是把季度结果、证据、主归因和下一季度规则连在同一条 trace 上。

小结

季度结束前的 keep、remove、reopen 收敛了承诺状态，季度复盘还要解释偏差从哪里产生。

一套可执行的最小方法包括：

  1. 回到 admission packet 和执行记录，不从最终状态直接猜原因
  2. 用执行条件、关键前提和容量证明区分三类偏差
  3. 选择一个 primary variance，同时保留 contributing factors
  4. 用反事实问题和可追溯证据校验分类
  5. 聚合重复偏差，再更新下一季度 admission rule
  6. 给新规则设置 owner、验证指标、复查时间和回退条件

这样，季度复盘留下的就不只是项目成败清单。每一项偏差都会指向一个可以验证的入口修正，让下一季度少重复一次已经看见的问题。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-quarterly-retrospective-variance-taxonomy-next-quarter-admission-rule-update/