AI 学习笔记（二十七）：LLM 例外正式化、退出标准与策略收敛最小实践

发表于 分类于 阅读次数： Changyan： 本文字数： 3.9k 阅读时长 ≈ 4 分钟
把临时例外从“反复续期”推进到“可正式化、可退出、可收敛”的治理闭环，避免长期依赖特批路径运行生产系统。

上一篇我们把“到期复盘”和“例外债清理”落地了。
但线上继续跑几周之后，团队通常会遇到第三层问题：

有些例外并不是该续期或关闭，而是已经变成长期能力候选。

常见场景很典型：

  1. 一个高风险工具白名单连续续期 3 次，业务仍强依赖
  2. 某条降级路由本是临时应急，后来成了常态流量路径
  3. 某个 prompt guard bypass 原本只给事故窗口，最后被多个团队默认复用

这时如果还只用 renew / close 二分法，治理会越来越僵。
因为你缺的是中间地带：

  1. 什么时候应该把“例外”升级成“正式策略”
  2. 什么时候必须定义硬退出标准（sunset criteria）
  3. 多条例外并存时，怎么收敛成一套可维护策略

这篇继续沿着生产运维主线，给一套最小可执行框架：

用 formalize + sunset + convergence 三步，把例外治理从“审批动作”变成“策略演进”。

1. 例外治理最容易卡住的三种状态

做到到期复盘后，很多团队会进入下面三种反复状态。

状态 A：可续可不续，长期拖延

复盘会上大家都承认风险还在，但也说不清什么时候能关。
最后通常是“再续一周”。

状态 B：明明是长期刚需，却不敢正式化

团队担心一旦正式化就“失去谨慎”，于是一直挂在临时例外名下。
结果是长期能力没有配套审计、权限模型和发布约束。

状态 C：例外越来越多，策略逐渐碎片化

每次事故、每次紧急变更都多一条例外。
半年后已经没人能完整回答：

  1. 默认策略到底是什么
  2. 哪些分支是临时，哪些分支是长期
  3. 不同团队对同一风险的处理是否一致

所以仅靠到期复盘还不够。
要稳定运行，需要再加两条强约束：

  1. 例外要么走向退出，要么走向正式化
  2. 多条例外必须周期性收敛回统一策略

2. 什么时候该 formalize，不要再“伪临时”

“正式化”不是放松治理，而是把已经事实长期存在的路径拉回可控系统。

一个例外满足下面 4 条中的 3 条，就应该优先进入 formalize 评估：

  1. 连续续期次数高（例如 renew_count >= 2）
  2. 覆盖范围持续扩大（从单租户到多租户，或从只读到写路径）
  3. 业务流程对该例外形成明确依赖
  4. 关闭成本显著高于补齐治理成本

formalize 的最小落地，不是“改个字段”。
至少要补齐这 5 件事：

  1. 把临时规则写入正式 policy 文档与配置源
  2. 为该能力补充权限边界和审计事件
  3. 接入发布闸门和回滚校验
  4. 明确 owner、SLO 影响与观测指标
  5. 关闭旧例外记录，防止“双轨并行”

关键点在于：

如果团队已经长期依赖这条路径，就不该再让它以“特批残留”身份存在。

3. Sunset Criteria：退出标准必须可验证、可执行

很多团队会写“条件成熟后关闭”。
这不算 sunset criteria，这只是愿望。

可执行的退出标准，建议至少覆盖 4 层。

1) 业务层（Business）

  • 哪类流量可迁回默认路径
  • 哪些租户已完成迁移
  • 是否存在不可替代场景

2) 技术层（Technical）

  • 替代方案是否上线并稳定一段观察窗
  • 关键指标是否达到阈值（错误率、延迟、成本）
  • 回滚路径是否演练通过

3) 治理层（Governance）

  • 例外所需临时权限是否可回收
  • 相关 runbook / on-call 手册是否更新
  • 审计字段是否完整归档

4) 时间层（Time-bound）

  • 明确最晚退出日（hard deadline）
  • 超期后的强制动作（冻结新增、限制发布、升级审批）

只有这四层同时成立，close 才不是口头承诺。

4. Policy Convergence：把“很多例外”收回“一套策略”

例外数量增长不可怕，可怕的是不收敛。
策略收敛建议做成固定节奏，比如双周一次。

每次收敛只做三件事：

  1. 聚类：按风险类型、影响面、触发条件聚合同类例外
  2. 归并：把可复用的处理逻辑沉淀为统一 policy 条目
  3. 清理：关闭被新 policy 覆盖的历史例外

一个实用判据是：

  • 当同类例外数量 >= 3
  • 且适用条件 70% 以上重叠
  • 且持续出现超过一个迭代

就应触发 convergence review，而不是继续新增独立例外单。

这一步能直接降低两类长期成本：

  1. 决策成本：值班和审批不再每次“从零判断”
  2. 维护成本：策略逻辑集中后，变更风险更可预测

5. 一个最小可落地的数据模型与决策函数

下面给一个服务层最小示例，核心是把 renew / close / formalize 判定显式化，并把 sunset 检查独立成函数。

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
type Disposition = 'close' | 'renew' | 'downgrade' | 'formalize';

interface ExceptionItem {
  id: string;
  renewCount: number;
  scope: 'tenant' | 'workspace' | 'global';
  hasWriteSideEffects: boolean;
  dependencyLevel: 'low' | 'medium' | 'high';
  sunsetCriteriaPassed: boolean;
}

function shouldFormalize(item: ExceptionItem): boolean {
  let score = 0;
  if (item.renewCount >= 2) score += 2;
  if (item.scope === 'global') score += 2;
  if (item.hasWriteSideEffects) score += 1;
  if (item.dependencyLevel === 'high') score += 2;
  return score >= 5;
}

function decideDisposition(item: ExceptionItem, riskStillExists: boolean): Disposition {
  if (!riskStillExists && item.sunsetCriteriaPassed) return 'close';
  if (shouldFormalize(item)) return 'formalize';
  if (riskStillExists && item.scope === 'global') return 'downgrade';
  return 'renew';
}

这里的重点不是分值本身，而是三条工程约束：

  1. formalize 需要明确触发条件，不靠会议感觉
  2. close 必须绑定 sunset 通过，而不是只看“风险似乎变小”
  3. 高影响例外默认先 downgrade 缩范围，再谈续期

6. 接进现有发布与事故治理链路

把 formalize / sunset / convergence 接回你已有流程，才能避免它再次沦为文档。

发布闸门

  • 存在超期例外且未通过 sunset：阻断高风险发布
  • 存在高依赖高续期例外：要求补 formalize 决策记录

事故关闭

  • 事故关联例外必须声明最终去向：close / renew / downgrade / formalize
  • 无去向记录，incident 不允许直接 closeout

值班节奏

  • 在 on-call 周会固定过一遍 “T-72h 即将到期例外”
  • 对连续续期项强制创建 action item，指定拆除 owner

策略评审

  • 双周做一次 convergence review
  • 输出“新增正式策略”和“可关闭历史例外”清单

把这几处打通后，例外治理会从“单点审批”升级为“持续工程动作”。

7. 一周最小落地顺序

如果你希望在不改大架构的前提下快速落地，可以按这个顺序推进：

  1. Day 1：在现有例外单里补 renew_count 与 disposition 字段
  2. Day 2：定义统一 sunset 模板（业务/技术/治理/时间四层）
  3. Day 3：给 renew_count >= 2 的例外强制触发 formalize 评审
  4. Day 4：把超期未通过 sunset 的例外接入发布阻断条件
  5. Day 5：执行一次 convergence review，关闭一批已覆盖旧例外

你不需要一开始就上完整平台。
只要先把“何时正式化、何时退出、何时收敛”三件事写成硬规则，例外治理质量就会明显提升。

总结

风险接受治理做到后半段，真正的分水岭不是审批做得多细，而是能不能回答三个问题：

  1. 哪些例外应该正式化
  2. 哪些例外必须按退出标准关闭
  3. 多条临时策略如何收敛成统一 policy

当这三件事可执行、可验证、可追踪时，系统才不会长期依赖“临时特批路径”运行。

参考资料

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-exception-formalization-sunset-criteria-policy-convergence/