AI 学习笔记（三十一）：LLM 例外债评分卡、续期阈值与季度治理评审自动化最小实践

发表于 分类于 阅读次数： Changyan： 本文字数： 4.7k 阅读时长 ≈ 4 分钟
例外治理做到后期，真正拖慢系统的是“历史例外债”。这篇给出可落地的评分卡模型、续期阈值策略和季度评审自动化链路，帮助团队从“能批例外”走到“能持续减债”。

上一篇我们把跨团队例外基线收敛成了可执行对象。

但真实生产里，问题不会停在“例外能不能收回来”。

更难的是另一件事：

系统里永远有一批历史例外，它们没有立刻爆炸，但一直在吞治理额度。

这批对象我一般叫它“例外债（exception debt）”。

如果没有统一量化标准，团队常会出现两种极端：

  1. 要么无限续期，最后把临时例外做成长期配置
  2. 要么一刀切回收，误伤还在风险窗口内的业务

这篇就接着前一篇往下走，给一套最小闭环：

  1. 用评分卡给例外债打分
  2. 用续期阈值做分级闸口
  3. 用季度评审自动化把减债动作持续跑起来

1. 先统一“什么算债”

例外不等于债，长期不可收敛的例外才是债。

我建议先定一个简单判定：

满足以下任一条件，就进入例外债池：

  1. 已过期但仍在生效
  2. 同一理由连续续期超过阈值
  3. 补偿控制不完整或证据缺失
  4. 影响范围超出最初申请边界

这一步的目标不是“处罚”，而是把例外从审批语义变成治理对象。

2. 评分卡：先用 5 个维度，不要一上来做复杂模型

第一版评分卡建议只保留 5 个维度，每个维度 0-5 分，分数越高风险越大：

  1. 时效风险：距到期时间、是否逾期
  2. 续期压力：近 90 天续期次数
  3. 影响半径：租户级、工作区级、全局级
  4. 控制完备度：补偿控制、回收证据、owner 完整度
  5. 根因进展：是否有明确整改里程碑与完成状态

可以先给一版线性权重：

  • 时效风险 30%
  • 续期压力 25%
  • 影响半径 20%
  • 控制完备度 15%
  • 根因进展 10%

先求“可解释”，再求“高精度”。第一版能稳定驱动动作就够了。

3. 一个可执行的最小打分实现

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
type ScopeLevel = 'tenant' | 'workspace' | 'global';

interface ExceptionDebtItem {
  id: string;
  scope: ScopeLevel;
  expiresAt: string;
  renewCount90d: number;
  controlsComplete: boolean;
  evidenceComplete: boolean;
  hasRemediationMilestone: boolean;
}

interface DebtScoreResult {
  id: string;
  score: number;
  band: 'green' | 'yellow' | 'orange' | 'red';
  reasons: string[];
}

function scoreExceptionDebt(item: ExceptionDebtItem, nowIso: string): DebtScoreResult {
  const reasons: string[] = [];
  let score = 0;

  const hoursToExpire = (Date.parse(item.expiresAt) - Date.parse(nowIso)) / (1000 * 60 * 60);
  if (hoursToExpire < 0) {
    score += 30;
    reasons.push('already expired but still active');
  } else if (hoursToExpire < 24) {
    score += 18;
    reasons.push('expires within 24h');
  } else if (hoursToExpire < 72) {
    score += 8;
    reasons.push('expires within 72h');
  }

  if (item.renewCount90d >= 3) {
    score += 25;
    reasons.push('renewed >=3 times in 90d');
  } else if (item.renewCount90d === 2) {
    score += 15;
    reasons.push('renewed twice in 90d');
  } else if (item.renewCount90d === 1) {
    score += 8;
    reasons.push('renewed once in 90d');
  }

  if (item.scope === 'global') {
    score += 20;
    reasons.push('global scope');
  } else if (item.scope === 'workspace') {
    score += 10;
    reasons.push('workspace scope');
  }

  if (!item.controlsComplete || !item.evidenceComplete) {
    score += 15;
    reasons.push('missing controls or evidence');
  }

  if (!item.hasRemediationMilestone) {
    score += 10;
    reasons.push('missing remediation milestone');
  }

  let band: DebtScoreResult['band'] = 'green';
  if (score >= 70) band = 'red';
  else if (score >= 45) band = 'orange';
  else if (score >= 25) band = 'yellow';

  return { id: item.id, score, band, reasons };
}

重点不是“分数多科学”，而是分数要直接映射动作。

4. 续期阈值：把“可续期”变成有代价的决策

我建议至少设置三层阈值：

  1. 软阈值（yellow）：允许续期，但必须补齐缺失证据
  2. 硬阈值（orange）：需要升级审批角色，并绑定整改里程碑
  3. 阻断阈值（red）：默认不再续期，除非走紧急变更豁免

这能避免“审批系统默认可续期”导致的隐性通道。

可以直接做成规则：

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
interface RenewalDecision {
  allowRenew: boolean;
  requiredApprovers: string[];
  requiredActions: string[];
}

function decideRenewal(scoreBand: 'green' | 'yellow' | 'orange' | 'red'): RenewalDecision {
  if (scoreBand === 'green') {
    return { allowRenew: true, requiredApprovers: ['team_owner'], requiredActions: [] };
  }
  if (scoreBand === 'yellow') {
    return {
      allowRenew: true,
      requiredApprovers: ['team_owner', 'platform_owner'],
      requiredActions: ['attach_controls', 'attach_evidence'],
    };
  }
  if (scoreBand === 'orange') {
    return {
      allowRenew: true,
      requiredApprovers: ['platform_owner', 'security_owner'],
      requiredActions: ['add_remediation_milestone', 'commit_eta'],
    };
  }
  return {
    allowRenew: false,
    requiredApprovers: ['platform_owner', 'security_owner', 'director'],
    requiredActions: ['raise_emergency_exception_ticket'],
  };
}

5. 季度治理评审自动化：别只开会，要自动生成“欠债清单”

季度评审最常见的问题是材料靠人工拼，导致每次只讲故事，不讲债务结构。

我建议把评审准备自动化成固定产物：

  1. 各团队活跃例外总量与环比
  2. 高分债项（orange/red）清单
  3. 续期超过阈值的重复例外
  4. 到期未回收与证据缺失占比
  5. 已承诺整改但超期未完成的项

可以把“季度包”固定输出为两份：

  1. exception_debt_snapshot.json
  2. exception_debt_review.md

这样评审会议只做决策，不再做数据清洗。

6. 建议的自动化链路

一个够用的链路如下：

  1. 每日批处理计算债分并更新 band
  2. 续期申请实时读取最新 band 并执行阈值规则
  3. 每周推送高风险债项给 owner 与平台 on-call
  4. 每季度自动生成评审包并创建治理任务
  5. 任务状态回写到债项，形成下季度对比基线

这条链路跑通后，治理团队才能回答三个关键问题：

  1. 债务总量是在降还是在升
  2. 哪些团队反复依赖续期在“借未来”
  3. 哪些例外已经应当转为正式策略或被禁止

7. 一周最小落地顺序

如果你当前还没有完整平台，可以按这个顺序做：

  1. Day 1：定义评分字段和 band 阈值
  2. Day 2：实现每日打分任务与结果落盘
  3. Day 3：把续期流程接入 band 决策
  4. Day 4：接入 orange/red 告警与负责人追踪
  5. Day 5：生成季度评审模板和自动汇总脚本
  6. Day 6-7：抽样复核误报漏报并调权重

先跑最小闭环，再扩展到更细粒度指标（如成本、稳定性、合规事件关联）。

总结

例外治理走到后半段，关键不再是“如何审批”，而是“如何持续减债”。

一套可执行的最小体系足够启动：

  1. 统一定义例外债
  2. 用评分卡量化风险
  3. 用续期阈值管控新增债务
  4. 用季度自动评审推动历史债清理

当这四步都接进系统后，例外才不会从“临时机制”慢慢演化成“永久风险库存”。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-exception-debt-scorecard-renewal-threshold-quarterly-review-automation/