上一篇写的是周级风险看板：月度 review 做出判断以后，平台团队需要用更短的周期追踪风险状态、owner 承诺、stale 项和升级条件。
周级机制跑起来以后，还会遇到另一个问题：每周都看见的风险，到了季度复盘时又要重新整理一遍。
这件事很浪费。周会上已经记录了风险为什么升级、哪个 owner 改过承诺、哪些动作连续失效、哪些证据支持关闭。如果季度复盘还要从聊天记录、看板评论和会议纪要里重新翻材料，说明周级信号没有进入复盘资产。
所以，周级风险看板需要一条回灌链路。它不用把所有周报都搬进季度报告，只要把能改变季度判断的信号沉淀下来：风险变化、owner 承诺履约、stale 处理、升级决策和关闭证据。
这一篇就写一个最小回灌机制：周级信号怎么归档，季度复盘怎么消费，哪些字段要保留，怎样避免复盘材料变成截图堆。
1. 回灌的对象不是周报全文
季度复盘不需要每周看板的完整副本。
真正有价值的是能解释季度结果为什么变成现在这样的信号：
1
2
3
4
5
| weekly_signal_feedback_scope:
risk_delta: added_escalated_closed_or_stale_risks
commitment_result: owner_promises_and_actual_outputs
decision_trace: escalations_acceptance_and_stop_decisions
evidence_link: artifacts_that_support_closure_or_reopen
|
risk_delta 说明风险在这个季度内怎么变化。
commitment_result 说明 owner 承诺有没有兑现，没兑现时发生了什么调整。
decision_trace 说明哪些风险被升级、接受、拆分或停止。
evidence_link 说明某个风险关闭或降级时，凭的是什么材料。
周报里的普通状态播报、临时沟通背景、重复提醒，都不应该进入季度复盘素材库。素材库只收能支撑季度判断的东西。
2. 每周结束时生成一份信号摘要
周级看板每周更新后，应该自动或半自动生成一份信号摘要。
它可以很短：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| weekly_governance_signal_summary:
week: 2026_w28
source_dashboard: weekly_risk_dashboard_2026_w28
risk_changes:
escalated:
- release_gate_can_ship_without_required_evidence
stale:
- policy_hit_self_service_adoption_not_formed
closed:
- audit_replay_manual_export_step
owner_commitments:
missed:
- owner: release_platform_team
action: confirm_replay_check_integration_slot
impact: evidence_replay_baseline_blocked
completed:
- owner: audit_platform_team
action: replace_manual_export_with_replay_api
evidence: replay_job_2026_w28
decisions:
- escalate_release_gate_gap_to_platform_arch_review
|
这份摘要的作用是把“本周发生了什么”压缩成季度复盘以后能读懂的材料。
如果没有这一步，季度复盘时只能回头翻每周看板。翻材料的人通常会记住最刺眼的事件，却漏掉连续三周都没有变化的 stale 信号。
3. 信号要挂到季度主题和交付包上
周级风险信号不能只按时间堆放。
它必须挂到季度主题和交付包上，否则季度复盘无法判断它影响了哪个目标。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| signal_to_quarter_mapping:
quarter: 2026_q3
quarterly_theme: make_governance_evidence_replayable_before_scaling_self_service
delivery_packages:
evidence_replay_baseline:
weekly_signals:
- release_gate_can_ship_without_required_evidence
- audit_replay_manual_export_step
policy_hit_self_service_adoption:
weekly_signals:
- policy_hit_self_service_adoption_not_formed
- ticket_entry_embedding_missing
agent_tool_call_risk_probe:
weekly_signals:
- provider_tool_call_schema_changed_in_beta_channel
|
这样季度复盘时，平台团队不用先问“这个风险归哪个包”。它已经在周级阶段完成归档。
对治理平台来说，这个映射很关键。很多风险表面上是同一个问题，实际影响的交付包不同。比如 provider schema 变化可能影响探索项，也可能影响 release gate baseline。如果归档时没有挂包，季度复盘就容易把它当成一个泛泛技术风险。
4. owner 承诺要保留结果，而不只是记录承诺
季度复盘更需要看承诺结果，而不是只看 owner 曾经说过什么。
可以把承诺记录压成这个结构：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| quarterly_commitment_trace:
package: policy_hit_self_service_adoption
risk: policy_hit_self_service_adoption_not_formed
commitments:
- week: 2026_w27
owner: pilot_team_a
promise: use_self_service_entry_for_next_20_tickets
result: missed
reason: entry_not_embedded_in_ticket_template
- week: 2026_w28
owner: workflow_team
promise: embed_entry_into_ticket_template
result: done
evidence: template_change_pr_1842
- week: 2026_w29
owner: pilot_team_a
promise: repeat_use_for_next_10_tickets
result: pending
|
这段材料能直接支撑季度复盘里的判断：自助诊断入口 adoption 没有形成，原因不只是业务团队没用，也包括入口没有进入原有 ticket 工作流。
如果只保留“pilot team 承诺使用”，复盘就会把问题误判成执行不力。保留承诺结果，才能看到风险形态怎样变化。
5. stale 风险要单独进入复盘素材
stale 风险很容易在季度复盘里被低估。
它们没有事故，也没有明显升级，常常被写成“持续跟进”。但连续几周没有变化，本身就是一个季度信号。
可以为 stale 风险建立单独归档：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| stale_risk_quarterly_input:
risk: release_gate_can_ship_without_required_evidence
package: evidence_replay_baseline
stale_detected_at: 2026_w28
stale_reason:
- no_status_change_for_2_weeks
- same_next_action_repeated_3_times
actions_after_stale:
- split_action_into_api_slot_and_policy_owner_confirmation
- escalate_to_platform_arch_review
quarterly_question:
- was_original_owner_wrong
- was_delivery_package_under_scoped
- should_next_quarter_make_this_a_blocking_baseline_item
|
stale 归档的重点是把“没有变化”变成可讨论的事实。
季度复盘如果只看完成项和升级项，会漏掉大量慢性失真。治理平台的很多债务并非突然爆发，它们往往是在两三个月里一直没有人能把动作推到关闭。
6. 升级和接受风险都要留下决策痕迹
风险升级通常会被记录，风险接受却容易被轻描淡写。
但季度复盘时，接受风险和升级风险一样重要。它会影响下季度 baseline、资源优先级和准入规则。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| risk_decision_trace:
risk: provider_tool_call_schema_changed_in_beta_channel
package: agent_tool_call_risk_probe
decision_history:
- week: 2026_w27
decision: watch
reason: beta_channel_only_and_sample_count_low
- week: 2026_w28
decision: accept_until
until: 2026-07-31
reason: no_production_channel_evidence
- week: 2026_w30
decision: escalate
reason: affected_release_gate_policy
target: governance_arch_review
|
这份记录能回答季度复盘里一个常见问题：当时为什么没有立刻做，后来为什么又升级了。
没有决策痕迹，复盘很容易变成事后判断。事后看起来清楚的事情，在当时可能只有少量样本、灰度渠道信号和不完整证据。把当时的判断条件留下来，才能做出更公平也更有用的复盘。
7. 关闭证据要能被复用
风险关闭不能只写 closed。
季度复盘需要知道它为什么可以关闭，关闭证据能不能复用到下季度 baseline。
1
2
3
4
5
6
7
8
9
10
11
12
| closure_evidence_record:
risk: audit_replay_manual_export_step
package: evidence_replay_baseline
closed_at: 2026_w28
closure_reason: manual_export_replaced_by_replay_api
evidence:
- replay_job_id: replay_job_2026_w28
- audit_sample_set: sample_set_2026_07_a
- verification_owner: audit_platform_team
reusable_asset:
- replay_api_checklist
- evidence_retention_policy_update
|
这里的 reusable_asset 很重要。
季度复盘不只是确认风险有没有关闭，还要判断这个关闭动作有没有形成资产。比如手工导出被 replay API 替代以后，是否沉淀成 checklist、接口契约、保留策略或 release gate 检查项。
没有复用资产，关闭只是一个点状修复。进入复盘以后，它应该变成下一季度可以继承的 baseline。
8. 季度复盘只消费四张视图
素材库可以存很多字段，但季度复盘不应该打开一堆原始记录。
实际复盘时，四张视图够用：
1
2
3
4
5
| quarterly_retrospective_inputs:
package_result_view: delivery_package_result_with_weekly_signal_count
risk_timeline_view: major_risk_delta_by_week
commitment_reliability_view: owner_commitment_done_missed_changed
asset_reuse_view: closed_risks_and_reusable_assets
|
package_result_view 说明每个交付包的结果和周级信号数量。
risk_timeline_view 说明风险在季度内什么时候新增、升级、stale、关闭。
commitment_reliability_view 说明 owner 承诺的履约情况，以及哪些承诺被反复改写。
asset_reuse_view 说明关闭风险以后留下了哪些可继承资产。
季度复盘只看这四张视图，可以避免材料泛滥。需要追溯时再点回原始周级摘要和证据链接。
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
| llm_governance_quarterly_signal_feedback:
quarter: 2026_q3
weekly_sources:
- weekly_risk_dashboard_2026_w27
- weekly_risk_dashboard_2026_w28
- weekly_risk_dashboard_2026_w29
package_signal_map:
evidence_replay_baseline:
escalated:
- release_gate_can_ship_without_required_evidence
closed:
- audit_replay_manual_export_step
reusable_assets:
- replay_api_checklist
policy_hit_self_service_adoption:
stale:
- policy_hit_self_service_adoption_not_formed
owner_commitment_changes:
- from_pilot_team_to_workflow_team
agent_tool_call_risk_probe:
accepted_until:
- provider_tool_call_schema_changed_in_beta_channel
quarterly_views:
package_result_view: ready
risk_timeline_view: ready
commitment_reliability_view: ready
asset_reuse_view: ready
next_quarter_questions:
- should_release_gate_evidence_check_become_blocking_baseline
- should_self_service_adoption_move_from_page_metric_to_workflow_metric
- should_beta_schema_watch_continue_or_close
|
这份模板没有引入新流程，只是在周级看板和季度复盘之间加了一层材料回灌。
它要求每周留下可复用的信号摘要，季度复盘时按交付包、风险时间线、owner 承诺和资产复用来消费。
小结
周级风险看板关注“风险在两次月会之间有没有继续移动”。季度复盘素材回灌关注“这些移动有没有进入季度判断”。
回灌机制不需要很重。每周只抽取风险 delta、承诺结果、决策痕迹和关闭证据；归档时挂到季度主题和交付包；复盘时只消费四张视图。
这样季度复盘就不再依赖临时翻记录，也不会只记住少数最醒目的事件。它能看到整个季度里风险怎样变化、承诺怎样履约、哪些动作真的沉淀成资产。
下一篇可以继续写季度复盘完成以后，如何把这些复盘结论转成下季度 admission rule 和 owner capacity 约束，避免下一轮 roadmap 又把同类风险带进去。
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-weekly-risk-signal-quarterly-retrospective-material-feedback-loop/