LLM 治理季度结束前怎么止损：用恢复预测决定承诺保留、移除还是重开

发表于 分类于 阅读次数： Changyan： 本文字数： 5.3k 阅读时长 ≈ 5 分钟
接着第二个月 adjustment checkpoint，这篇继续写季度结束前如何基于剩余工作、证据收敛、owner 容量和依赖波动生成恢复预测，并据此决定哪些承诺继续保留、及时移除或重新进入决策。

上一篇用 second-month adjustment checkpoint 验证月度调整是否生效，并把结果收敛为 validated、validated_with_follow_up、adjustment_failed 和 decision_reopened。

到了季度结束前，团队还要回答一个更直接的问题：剩下的时间里，哪些承诺仍有可信恢复路径，哪些已经需要止损。

如果所有未完成项都继续挂在 roadmap 上，季度末会同时出现赶工、补材料和重新解释目标。最终不仅交付质量下降，季度复盘也很难分辨哪些承诺是真的完成了，哪些只是被延后确认失败。

这一篇继续往下走：把第二个月 checkpoint 结果转成 pre-quarter-end recovery forecast，并用 keep、remove、reopen 三类决策提前收敛季度承诺。

1. 恢复预测不是重新估一次完成时间

很多季度末预测只做一件事：让 owner 再报一次预计完成日期。

这种预测很容易重复原来的乐观假设。真正需要判断的是，剩余条件是否足以让承诺恢复到可验收状态：

1
2
3
4
5
6
7
8
9
recovery_forecast_inputs:
  remaining_work:
    question: can_the_minimum_package_finish_in_window
  evidence_closure:
    question: can_required_evidence_become_valid
  owner_capacity:
    question: is_protected_capacity_still_available
  dependency_volatility:
    question: can_external_blockers_be_resolved_or_isolated

预测对象也不应该是整条 roadmap，而应该是单个 commitment。

同一个交付包里，回放门禁可能仍能完成，辅助看板可能已经没有必要继续投入，某个策略例外又可能因为前提变化需要重新决策。把它们合成一个百分比，会掩盖完全不同的处理方式。

2. 先建立季度结束前的可恢复窗口

恢复预测必须有明确时间边界。

1
2
3
4
5
6
recovery_window:
  forecast_date: 2026-07-14
  quarter_end: 2026-09-30
  decision_deadline: 2026-09-12
  stabilization_buffer_days: 10
  evidence_freeze_days: 5

这里至少要保留两个 buffer：

  • stabilization buffer：用于回归、观察和处理上线后的异常
  • evidence freeze：用于冻结最终证据，避免季度复盘继续引用变化中的数据

因此，可恢复窗口不是从今天一直算到季度最后一天。

如果一个承诺必须在季度最后三天才能完成开发，就没有足够时间证明它满足 acceptance 和 evidence contract。这类承诺即使代码可能写完，也不应该被预测为可按季度闭环。

3. 用四个硬信号计算恢复可信度

恢复预测不需要复杂模型，但需要避免只听 owner 的单点判断。

可以给每个 commitment 保留四组信号：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
commitment_recovery_signals:
  commitment_id: replay_gate_completion

  remaining_work:
    estimated_days: 8
    unknown_work_items: 1

  evidence_closure:
    required: 5
    valid: 4
    missing: 1
    closure_rate_per_week: 1

  owner_capacity:
    required_hours: 48
    protected_hours_available: 56
    capacity_confidence: high

  dependencies:
    unresolved: 1
    isolatable: true
    decision_due: 2026-08-20

判断时可以使用一个简单原则：任何一组关键条件为零，整体预测都不能是高可信。

例如 owner 容量充足，但剩余证据无法在 freeze date 前形成，这项承诺仍然不能按“可恢复”处理。相反，如果依赖还未完全关闭，但已经有明确隔离方案，预测可以保留为有条件恢复。

4. 把预测结果收敛成三个等级

为了直接连接止损决策，预测结果不宜使用过多模糊状态：

1
2
3
4
recovery_forecast_result:
  - recoverable
  - recoverable_with_condition
  - unrecoverable_in_window

三种结果分别表示：

结果 判断标准 默认动作
recoverable 工作、证据、容量和依赖都能在窗口内闭环 keep
recoverable_with_condition 存在一个可验证的关键条件，且有 owner 与截止时间 临时 keep，条件失败则自动升级
unrecoverable_in_window 至少一个关键条件无法在窗口内满足 remove 或 reopen

recoverable_with_condition 不能成为延迟决策的容器。

它必须只有少量明确条件，例如依赖方需要在某日之前提供测试环境。到了截止时间条件未满足，状态应自动变为 unrecoverable_in_window，而不是继续改日期。

5. keep：只保留仍有完整闭环路径的承诺

一项承诺可以继续留在季度 roadmap 中，至少要同时满足：

1
2
3
4
5
6
keep_gate:
  minimum_package_defined: true
  protected_capacity_confirmed: true
  acceptance_can_finish_before_buffer: true
  evidence_can_freeze_before_review: true
  unresolved_dependency_has_owner: true

这里的重点是“完整闭环路径”。

不能因为开发进度已经达到 80%，就自动保留承诺。如果剩余 20% 包含关键回归、真实流量观察和审计证据，那么未完成部分可能决定整项交付是否成立。

keep 之后也不要继续扩充 scope。季度末的保留动作应该同时冻结 minimum package、acceptance 和 evidence contract，防止团队用新增能力稀释最小闭环。

6. remove：对窗口内无法闭环的承诺及时止损

remove 不是把失败从记录里删掉，而是停止继续消耗本季度容量。

典型触发条件包括：

  • owner capacity contract 连续两个月失效
  • 关键证据无法在 freeze date 前形成
  • 外部依赖没有可隔离方案，也没有可信恢复日期
  • 剩余价值不足以覆盖赶工、回归和运营风险
  • minimum package 继续收窄后已经无法支持原 decision

可以把移除动作记录为：

1
2
3
4
5
6
7
8
9
10
commitment_stop_loss:
  commitment_id: exception_preview_dashboard
  forecast: unrecoverable_in_window
  action: remove
  stop_work_at: 2026-09-12
  preserve:
    - completed_design
    - reusable_query
    - unresolved_risk_record
  quarter_result: not_delivered

这样既承认季度承诺没有完成，也保留可复用资产和失败证据。

最危险的做法是继续让它保持 in progress，同时默认下季度自然顺延。没有重新进入 admission rule 的顺延，会把本季度错误的容量假设直接复制到下一个季度。

7. reopen：前提变化时重开决策，而不是继续执行旧承诺

有些承诺无法恢复，并不是执行能力不足，而是原 decision premise 已经变化。

例如：

  • 风险等级上升，原来的轻量验收不再够用
  • 上游能力变化，原方案已经不是最小成本路径
  • 业务流量结构变化，原证据窗口失去代表性
  • 新的合规约束要求补充人工审批或审计链路

这类情况不适合直接 remove，也不应该按旧方案继续赶工，而要 reopen decision：

1
2
3
4
5
6
7
8
9
10
decision_reopen:
  commitment_id: automated_exception_approval
  previous_premise: low_risk_internal_workflow
  changed_signal: external_customer_data_involved
  paused_execution: true
  decision_packet_due: 2026-09-05
  options:
    - add_human_review_gate
    - reduce_automation_scope
    - move_to_next_quarter

reopen 的核心动作是暂停旧承诺，重新比较方案，而不是一边执行一边等待新结论。

8. 止损决策要在季度复盘前完成

如果 keep、remove、reopen 到季度复盘当天才决定，复盘会被迫同时承担状态确认、资源争议和方案重选。

更合理的节奏是：

1
2
3
4
5
6
7
8
9
pre_quarter_end_rhythm:
  forecast_cutoff:
    action: collect_recovery_signals
  decision_deadline:
    action: approve_keep_remove_reopen
  stabilization_window:
    action: finish_kept_commitments_and_freeze_evidence
  quarterly_retrospective:
    action: review_results_and_update_next_quarter_rules

这样季度复盘看到的是已经执行过的止损结果，而不是一组仍在争论的未完成项。

复盘也能更准确地区分：哪些承诺因为执行漂移失败，哪些因为假设变化被重开，哪些因为容量配置不合理被移除。

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
pre_quarter_end_recovery_decision:
  commitment_id: replay_gate_completion
  source_checkpoint: q3_month_2_adjustment_validation

  recovery_window:
    decision_deadline: 2026-09-12
    evidence_freeze: 2026-09-25

  signals:
    remaining_work_days: 8
    evidence_gap: 1
    protected_hours_available: 56
    unresolved_dependencies: 1
    dependency_isolatable: true

  forecast: recoverable_with_condition
  condition:
    owner: runtime_platform_owner
    due: 2026-08-20
    requirement: replay_environment_ready

  decision: keep
  automatic_escalation:
    when: condition_overdue
    forecast: unrecoverable_in_window
    decision: remove

这份模板的价值不在于精确预测每一天，而在于提前暴露决定恢复可信度的关键条件，并给条件失败后的动作设好默认值。

小结

second-month adjustment checkpoint 解决的是“调整是否生效”，pre-quarter-end recovery forecast 解决的是“剩余时间里是否还有可信闭环路径”。

最小实践可以概括为：

  1. 为每项 commitment 单独建立恢复预测，不用整条 roadmap 的完成百分比替代
  2. 扣除 stabilization 和 evidence freeze，得到真实可恢复窗口
  3. 同时检查剩余工作、证据收敛、owner 容量和依赖波动
  4. 用 recoverable、recoverable_with_condition、unrecoverable_in_window 收敛判断
  5. 在季度复盘前完成 keep、remove、reopen，并为条件失败设置自动升级

这样，季度末就不需要靠赶工和模糊状态维持表面完整，而是能主动保留仍然可信的承诺、停止无效投入，并把前提已经变化的问题重新送回决策链路。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-pre-quarter-end-recovery-forecast-stop-loss-commitment-decision/