LLM 治理平台季度 roadmap 复盘：看交付包结果、组合漂移和下季度准入规则

发表于 分类于 阅读次数： Changyan： 本文字数： 7.1k 阅读时长 ≈ 6 分钟
接着季度 roadmap 拆解，这篇继续写复盘：季度结束时不要只清点任务完成率，而要看 delivery package 是否产生结果、组合投入是否漂移，以及下季度准入规则该如何调整。

上一篇把年度治理组合拆成了季度 roadmap：先定季度主题，再拆 delivery package、指标阶梯和准入门槛。

这解决的是季度开始时怎么排计划。但一个季度结束以后，真正有价值的动作不是把任务状态从 todo 改成 done，而是回头看三个问题：

  1. 交付包有没有产生当初承诺的治理结果；
  2. 可靠性 baseline、收益型能力和探索投入的组合有没有漂移；
  3. 下季度的准入规则要不要收紧、放宽或换方向。

如果季度复盘只看完成率，平台团队很容易得到一个过于乐观的结论：大部分任务都完成了，所以 roadmap 执行不错。可治理平台的问题经常藏在完成率后面。页面上线了，但试点团队没用；探索样本收了，但没有形成决策；baseline 修了几个点，但证据回放仍然断在关键链路上。

这一篇就接着写季度 roadmap 的下一步：怎么把季度复盘做成下季度计划的输入，而不是一份例行总结。

1. 季度复盘先看交付包，不先看任务

季度结束时，最容易拿到的是任务列表。

1
2
3
4
5
6
7
q1_task_status:
  normalize_policy_hit_event_schema: done
  backfill_missing_evidence_for_top_20_policies: done
  add_replay_check_to_release_gate: delayed
  document_audit_replay_runbook: done
  build_policy_hit_detail_page: done
  collect_agent_tool_call_samples: done

这份列表有用，但它只能说明单个任务走到哪里了。它不能回答 evidence_replay_baseline 这个交付包是否真的让高风险策略具备了完整回放能力。

复盘应该先回到包级结果：

1
2
3
4
5
6
7
8
delivery_package_review:
  package: evidence_replay_baseline
  promised_outcome: top_risk_policies_can_be_replayed_with_complete_evidence
  result:
    replay_success_rate_for_top_20_policies: 85
    release_gate_replay_check: delayed
    audit_runbook_dry_run: passed_with_2_manual_steps
  judgment: partially_met

这个结论比“4 个任务完成了 3 个”更有价值。因为它直接指出：证据回放已经改善，但发布门禁里的 replay check 延迟了，审计 runbook 仍然有两个手工步骤。下季度要补的是结果缺口，不是机械延续未完成任务。

治理平台复盘要避免一个误区：把任务延期等同于失败，把任务完成等同于成功。真正的判断对象应该是交付包承诺的治理结果。

2. 每个交付包都要有结果判定

一个实用的复盘表，可以把交付包分成四种状态：

状态 含义 下季度动作
met 承诺结果已达到 进入运行维护或扩大覆盖
partially_met 结果部分达到，有明确缺口 下季度补缺口或降级目标
missed 关键结果没有达到 复盘原因，重新决定是否继续
invalidated 目标本身被证明不成立 停止或改成观察项

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
q1_package_review:
  - name: evidence_replay_baseline
    type: reliability_baseline
    status: partially_met
    gap: release_gate_replay_check_not_ready
  - name: policy_hit_self_service_mvp
    type: benefit_capability
    status: met
    evidence: 3_pilot_teams_use_diagnosis_before_opening_ticket
  - name: agent_tool_call_sample_probe
    type: exploration_investment
    status: invalidated
    evidence: samples_show_risk_is_covered_by_existing_tool_policy

invalidated 很重要。探索项如果证明“不值得继续做”，也算有效产出。它帮团队省掉了后续产品化投入。

这比含糊写一句“探索项目完成调研”更清楚。完成调研不是结果，形成继续、观察或停止的判断才是结果。

3. 可靠性 baseline 要看缺口是否进入运行风险

可靠性 baseline 的复盘重点，不是做了多少能力，而是还有哪些缺口会进入运行风险。

例如：

1
2
3
4
5
6
7
8
9
baseline_gap_review:
  package: evidence_replay_baseline
  remaining_gaps:
    - gap: replay_check_not_in_release_gate
      risk: policy_change_can_ship_without_replay_sample
      severity: high
    - gap: 2_manual_steps_in_audit_runbook
      risk: audit_response_time_unstable
      severity: medium

这类缺口不能只放进普通 backlog。它们已经影响现有治理承诺，下季度要么继续作为 baseline 包推进，要么明确接受风险。

可以给 baseline 缺口设置一个简单规则：

1
2
3
4
5
6
7
8
9
baseline_carryover_rule:
  carry_to_next_quarter_when:
    - affects_existing_governance_promise
    - can_cause_audit_replay_failure
    - can_cause_false_block_or_missed_block
  require_risk_acceptance_when:
    - delayed_more_than_one_quarter
    - no_clear_owner
    - depends_on_external_system_change

这样做的好处是，baseline 延期不会被轻飘飘地写成“下季度继续”。如果它已经进入运行风险，就要有人明确接受这个风险，或者腾出资源补掉。

4. 收益型能力要区分被使用和产生收益

收益型能力最容易在复盘里被高估。

一个自助诊断页面上线，并且有试点团队用过，不代表它已经产生收益。季度复盘要把 readiness、adoption 和 outcome 分开看。

1
2
3
4
5
6
7
8
9
10
11
12
benefit_capability_review:
  package: policy_hit_self_service_mvp
  metric_stage: adoption_readiness
  readiness:
    top_5_common_policy_hits_have_explanation: true
    diagnosis_entry_visible_in_policy_hit_detail: true
  adoption:
    pilot_teams_used_before_opening_ticket: 3
    repeated_use_team_count: 1
  outcome:
    explanation_ticket_reduction: not_measured_yet
  judgment: ready_to_enter_adoption_stage

这个结论不是“已经成功”，而是“可以进入 adoption 阶段”。这两个说法差别很大。

下季度的计划也会因此不同：

1
2
3
4
5
6
7
next_quarter_adjustment:
  package: policy_hit_self_service_mvp
  from_stage: adoption_readiness
  to_stage: adoption
  next_targets:
    - top_20_teams_use_diagnosis_monthly
    - duplicated_explanation_tickets_down_15_percent

如果 Q1 的目标本来就是 readiness，就不要急着用 outcome 指标否定它。反过来，如果一个能力已经连续两个季度停在 readiness，没有真实团队反复使用，也不能继续用“还在培养习惯”解释。

5. 探索项要在复盘会上做出口决定

探索项进入季度 roadmap 时，应该带 timebox 和决策点。复盘就是兑现这个决策点的时候。

1
2
3
4
5
6
7
8
9
exploration_review:
  item: agent_tool_call_sample_probe
  timebox: 6_weeks
  evidence_collected:
    real_agent_workflow_samples: 24
    unique_risk_patterns: 1
    covered_by_existing_policy: true
  decision: keep_as_watch_item
  reason: no_dedicated_policy_layer_needed_yet

这个例子里，探索没有升级成正式能力。它的结论是继续观察。

下季度就不应该再把它伪装成产品需求：

1
2
3
4
5
6
7
next_quarter_exploration_state:
  agent_tool_call_risk:
    state: watch_item
    review_trigger:
      - unique_tool_risk_pattern_appears
      - provider_changes_tool_permission_model
      - incident_related_to_agent_tool_call

探索项如果复盘时没有出口决定，就会自然滑进下季度 backlog。几轮以后，团队会发现探索池里堆了一批没人敢停、也没人能说明价值的半成品。

复盘会要对探索项说清楚三句话之一：转正、继续观察、停止。

6. 组合漂移比单个项目延期更值得警惕

季度复盘还要看组合投入有没有漂移。

上一篇设定的 Q1 投入比例可能是：

1
2
3
4
planned_allocation:
  reliability_baseline: 55
  benefit_capability: 35
  exploration_investment: 10

实际执行完以后，可能变成：

1
2
3
4
actual_allocation:
  reliability_baseline: 38
  benefit_capability: 32
  exploration_investment: 30

这说明探索投入明显吃掉了 baseline。单看每个探索项目，可能都能解释；放到组合层面看，运行责任已经被挤压。

复盘里可以记录成：

1
2
3
4
5
6
7
portfolio_drift_review:
  drift:
    reliability_baseline: -17
    benefit_capability: -3
    exploration_investment: +20
  judgment: exploration_overran_baseline_capacity
  required_action: next_quarter_exploration_admission_tightened

组合漂移不一定都是坏事。比如某个外部审计突然提前，baseline 超配也合理；某个 provider 重大变更带来新风险，探索短期加码也合理。关键是漂移要被看见，被解释，并进入下季度准入规则。

最危险的是漂移已经发生，但复盘只讨论单个项目为什么延期。

7. 准入规则要跟着复盘结果调整

季度复盘的最终产出，不应该只是“下季度继续推进”。它要更新准入规则。

如果 Q1 发现探索投入过多，下季度可以收紧：

1
2
3
4
5
6
7
8
9
next_quarter_admission_rule:
  exploration_investment:
    accept_when:
      - has_real_incident_or_sample_signal
      - has_timebox_shorter_than_4_weeks
      - has_named_stop_decision_owner
    reject_when:
      - only_based_on_industry_trend
      - no_clear_policy_decision_output

如果 Q1 发现收益型能力 readiness 做完了，但 adoption 起不来，下季度要把团队使用条件写进准入：

1
2
3
4
5
6
7
8
benefit_capability_admission_rule:
  accept_when:
    - has_pilot_team_owner
    - has_usage_feedback_loop
    - replaces_existing_manual_platform_work
  defer_when:
    - only_adds_page_without_workflow_entry
    - no_team_commits_to_repeated_use

如果 Q1 baseline 缺口已经进入运行风险，下季度则要提高 baseline 优先级：

1
2
3
4
5
baseline_admission_rule:
  must_include_when:
    - open_gap_affects_existing_governance_promise
    - audit_replay_has_manual_steps
    - release_gate_can_ship_without_required_evidence

准入规则不是静态政策。它应该随着季度复盘不断校准。这样 roadmap 才会一季比一季更接近真实约束。

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
30
31
llm_governance_quarterly_roadmap_retrospective:
  quarter: 2027_q1
  planned_theme: make_governance_evidence_replayable_before_scaling_self_service
  package_results:
    - name: evidence_replay_baseline
      type: reliability_baseline
      status: partially_met
      remaining_gap: release_gate_replay_check_not_ready
      next_action: carry_as_baseline_risk
    - name: policy_hit_self_service_mvp
      type: benefit_capability
      status: met
      next_action: move_from_readiness_to_adoption
    - name: agent_tool_call_sample_probe
      type: exploration_investment
      status: invalidated
      next_action: keep_as_watch_item
  allocation_review:
    planned:
      reliability_baseline: 55
      benefit_capability: 35
      exploration_investment: 10
    actual:
      reliability_baseline: 38
      benefit_capability: 32
      exploration_investment: 30
    judgment: exploration_overran_baseline_capacity
  next_quarter_rule_changes:
    - tighten_exploration_admission
    - require_owner_for_benefit_adoption_feedback_loop
    - carry_high_risk_baseline_gap_with_explicit_risk_acceptance

这份模板不追求复杂。它只保证复盘不会停在任务层，而是能把结果、漂移和准入规则串起来。

更关键的是，它能直接成为下季度 roadmap 的输入。下季度不是重新开一张白纸排需求，而是接着上一季度的真实结果往前走。

结语

LLM 治理平台的季度 roadmap 复盘，不应该是一场任务完成率汇报。

它更像一次校准：校准交付包是否产生结果，校准组合投入有没有偏离年度策略，校准下季度哪些需求能进、哪些要挡在外面。

任务完成只能说明团队做了事。交付包结果、组合漂移和准入规则调整，才能说明治理平台有没有沿着正确方向变稳、变轻、变清楚。

下一篇可以继续把节奏拉细：当季度复盘结论已经形成，如何设计月度推进节奏、风险 review 和跨团队同步机制，让治理平台不只在季度节点校准，也能在日常执行中持续修正方向。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-quarterly-roadmap-retrospective-delivery-package-result-portfolio-drift-next-quarter-admission-rule-adjustment/