LLM 治理平台周级风险看板：让 owner 跟进不再卡在月会之后

发表于 分类于 阅读次数： Changyan： 本文字数： 6k 阅读时长 ≈ 5 分钟
接着月度推进节奏，这篇继续写更短周期的周级风险看板和 owner 跟进机制：月度 review 做出判断以后，平台团队如何在两次月会之间追踪风险状态、owner 承诺和升级条件。

上一篇写的是月度推进节奏：每个月要把风险 review、交付包跟踪和跨团队同步串起来，让季度 roadmap 不至于等到季度末才发现偏差。

但月度 review 做完以后，还有一个很现实的问题：结论怎么在接下来的三四周里真的发生作用。

很多治理动作不是在月会上失效的，而是在月会之后失效的。风险被确认了，但 owner 没有继续推进；依赖被记录了，但没人追交付日期；新信号被放进 watch 状态，但触发升级以后没人更新判断。

所以，月度节奏还需要一个更轻的周级机制。它不负责重新开一轮 review，而是把月度判断拆成每周可见的风险状态、owner 承诺和升级条件。

这一篇就写一个最小周级风险看板：看什么字段，怎么跟进 owner，什么情况下升级，怎么避免周报变成新的管理噪音。

1. 周级看板只服务三类风险

周级看板不要试图覆盖所有工作项。

它只适合放三类东西：

1
2
3
4
weekly_risk_dashboard_scope:
  baseline_gaps: risks_that_break_governance_promise
  delivery_blockers: blockers_that_change_package_outcome
  watch_signals: new_signals_with_clear_upgrade_triggers

baseline_gaps 是会破坏治理承诺的缺口，例如 release gate 缺少必要证据、审计回放链路还有人工步骤、策略命中数据无法复核。

delivery_blockers 是会改变交付包结果的阻塞，例如试点团队没有接入入口、跨团队接口没有排期、样本数据拿不到。

watch_signals 是月度 review 中暂时没有升级为项目的新信号，但已经定义了观察阈值。

除此之外的普通任务进度，不应该进入周级风险看板。任务进度可以留在项目管理工具里，周级看板只看会改变治理判断的东西。

2. 每条风险都要有 owner 和下次动作

风险看板最容易变成“风险列表”。列表本身没有价值，关键是每条风险有没有明确 owner 和下次动作。

可以把单条风险压成这个结构：

1
2
3
4
5
6
7
8
9
weekly_risk_item:
  id: risk_2026_07_01
  type: baseline_gap
  title: release_gate_can_ship_without_required_evidence
  status: open
  owner: release_platform_team
  next_action: confirm_replay_check_integration_slot
  due: 2026-07-05
  escalation_rule: no_slot_confirmed_after_due

这里的 owner 指的不是泛泛相关方，必须对应下一步动作的负责人。

比如 release gate 缺少证据校验，真正的风险可能牵涉平台、安全、审计三个团队。但这一周的下次动作只需要一个 owner：谁负责确认接入排期，谁就写在看板上。

如果每条风险都写多个 owner，实际效果通常是没人负责。周级跟进要把责任缩到一个具体动作上，再按动作滚动更新 owner。

3. 状态不要太多，四种够用

周级看板的状态不宜复杂。状态太多，团队会花时间讨论“应该归到哪个状态”；状态太少，又看不出风险有没有变坏。

一个可用的最小集合是四种：

状态 含义 本周动作
open 风险存在，已有明确动作 跟进 owner
waiting 等外部依赖或决策 确认等待对象和日期
escalated 已触发升级条件 拉入更高层决策
closed 风险关闭或降级 记录关闭证据

例如：

1
2
3
4
5
6
risk_status_update:
  risk: release_gate_can_ship_without_required_evidence
  last_week_status: waiting
  current_status: escalated
  reason: integration_slot_not_confirmed_after_due
  escalation_target: platform_arch_review

状态变化要带原因。只写 waiting -> escalated 不够，必须写明触发了什么条件。

这样做的好处是，周会不用重新解释整段背景，只要看本周状态差异和触发原因。

4. owner 跟进要跟动作，不跟人

很多 owner 跟进会变得很尴尬，因为它像是在催人。

治理平台更适合跟动作：

1
2
3
4
5
6
owner_follow_up:
  action: confirm_replay_check_integration_slot
  owner: release_platform_team
  expected_output: integration_slot_date_or_rejection_reason
  due: 2026-07-05
  follow_up_channel: weekly_dashboard_comment

这里要跟的是“接入排期或拒绝理由有没有给出来”，不要把讨论带成“release 团队为什么还没做”。

动作定义得越清楚，跟进越不容易变成人情压力。owner 可以给出三种有效反馈：

  1. 已完成，给出证据；
  2. 无法完成，给出原因；
  3. 需要改 owner 或改截止时间，给出新的承诺。

无效反馈也要识别，比如“推进中”“沟通中”“看看下周”。这些词没有输出物，也没有改变风险状态，只能算没有更新。

5. 周级看板要保留承诺历史

只看当前状态，很难判断风险是在推进还是原地打转。

看板至少要保留最近几次承诺：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
commitment_history:
  risk: policy_hit_self_service_adoption_not_formed
  commitments:
    - date: 2026-07-01
      owner: pilot_team_a
      promise: use_self_service_entry_for_next_20_tickets
      result: missed
    - date: 2026-07-08
      owner: platform_team
      promise: embed_entry_into_ticket_template
      result: done
    - date: 2026-07-15
      owner: pilot_team_a
      promise: repeat_use_for_next_10_tickets
      result: pending

保留承诺历史的目的不是追责；更关键的是看风险有没有换成另一种形态。

比如试点团队没有重复使用自助诊断入口，原因未必是团队不配合，也可能是入口没有嵌入原有 ticket 模板。承诺历史能帮助平台团队发现：原来的 adoption 问题，其实是工作流嵌入问题。

没有承诺历史，周级看板很容易每周都写同一句“继续跟进”。

6. 升级条件要提前写好

风险升级不能只靠感觉。

每条风险进入周级看板时，就应该写清楚什么情况下升级：

1
2
3
4
5
6
7
8
9
10
escalation_rule:
  risk: provider_tool_call_schema_changed_in_beta_channel
  current_decision: watch
  upgrade_when:
    - appears_in_production_channel
    - affected_policies_over_5
    - release_gate_policy_affected
  downgrade_when:
    - no_new_sample_for_14_days
    - provider_confirms_no_contract_change

这样周级跟进就不会变成“再观察一下”。

观察可以持续，但必须知道继续观察的边界。达到升级条件，就进入月度决策或临时风险评审；达到降级条件，就从看板移除或回到普通记录。

对 LLM 治理平台来说，这一点尤其重要。provider 行为、工具调用 schema、模型路由策略、策略命中样本都可能快速变化。如果没有提前写升级条件，团队很容易在新信号面前反复犹豫。

7. 看板要输出本周 delta

周级看板每周最重要的输出不是全量列表，而是本周 delta。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
weekly_risk_delta:
  week: 2026_w28
  newly_added:
    - provider_tool_call_schema_changed_in_beta_channel
  escalated:
    - release_gate_can_ship_without_required_evidence
  closed:
    - audit_replay_manual_export_step
  stale:
    - policy_hit_self_service_adoption_not_formed
  owner_changes:
    - risk: ticket_entry_embedding_missing
      from: platform_team
      to: workflow_team

这个 delta 决定本周要讨论什么。

如果没有新增、升级、关闭、过期、换 owner，就不需要开很长的同步会。直接异步更新也可以。

周级机制的目标是降低失真，不是制造固定仪式。没有风险变化，就少开会；有风险变化，就只讨论变化。

8. stale 风险要有单独处理

周级看板里更容易被低估的，其实是 stale 风险。

它们看起来一直在跟进，但状态没有变化，owner 没有新承诺，风险也没有关闭。

可以给 stale 一个明确规则：

1
2
3
4
5
6
7
8
9
10
11
stale_rule:
  mark_stale_when:
    - no_status_change_for_2_weeks
    - no_valid_owner_update_for_2_weeks
    - same_next_action_repeated_3_times
  required_decision:
    - escalate
    - replace_owner
    - split_action
    - accept_risk_until_date
    - close_as_not_actionable

stale 的作用也不是批评谁，它提示的是当前跟进方式已经失效。

例如一个风险连续三周都写“等待业务团队确认入口”，可能说明 owner 不对，也可能说明动作太大，需要拆成“确认入口位置”“确认权限”“确认灰度团队”三个更小动作。

把 stale 单独标出来，可以避免风险在看板上长期占位，却不产生任何决策。

9. 一个最小周级风险看板模板

把前面的内容合起来，可以得到一份足够轻的模板：

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
32
33
34
35
36
37
38
39
llm_governance_weekly_risk_dashboard:
  week: 2026_w28
  source_monthly_review: 2026_07
  risks:
    - id: risk_2026_07_01
      type: baseline_gap
      title: release_gate_can_ship_without_required_evidence
      status: escalated
      owner: release_platform_team
      next_action: confirm_replay_check_integration_slot
      due: 2026-07-05
      escalation_rule: no_slot_confirmed_after_due
      last_valid_update: integration_slot_not_confirmed
    - id: risk_2026_07_02
      type: delivery_blocker
      title: policy_hit_self_service_adoption_not_formed
      status: open
      owner: workflow_team
      next_action: embed_self_service_entry_into_ticket_template
      due: 2026-07-10
      stale_rule: same_next_action_repeated_3_times
    - id: risk_2026_07_03
      type: watch_signal
      title: provider_tool_call_schema_changed_in_beta_channel
      status: waiting
      owner: governance_platform_team
      next_action: collect_next_50_samples
      due: 2026-07-12
      escalation_rule: appears_in_production_channel
  weekly_delta:
    newly_added:
      - provider_tool_call_schema_changed_in_beta_channel
    escalated:
      - release_gate_can_ship_without_required_evidence
    stale:
      - policy_hit_self_service_adoption_not_formed
  decisions_needed:
    - platform_arch_review_accepts_release_gate_blocking_priority
    - workflow_team_confirms_ticket_template_change_date

模板不复杂，但它强制每条风险回答几个问题：谁负责下一步，什么时候给出输出，什么情况下升级，本周状态和上周有什么不同。

只要这些问题能持续回答，周级看板就不会变成周报。

小结

月度 review 负责做判断，周级风险看板负责让判断继续移动。

它不用覆盖所有任务，也不需要做成复杂系统。先从三类风险开始：baseline 缺口、交付阻塞、新信号观察。每条风险只保留 owner、下次动作、截止日期、升级条件和本周 delta。

真正有用的周级机制，应该让团队更少靠记忆和催促推进风险：该升级的升级，该换 owner 的换 owner，该关闭的关闭，该承认 stale 的承认 stale。

下一篇可以继续写 owner 承诺进入执行以后，如何把周级风险信号沉淀回季度复盘材料，避免每周看见的问题在季度复盘时又重新从零整理。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-weekly-risk-dashboard-owner-follow-up-mechanism/