AI 学习笔记（三十五）：LLM 季度控制证据质量评分、审计回放演练与关闭 SLA 加固最小实践

发表于 分类于 阅读次数： Changyan： 本文字数： 4.1k 阅读时长 ≈ 4 分钟
evidence pack 做出来后，团队常卡在证据能不能复核、关单多久算超时、审计抽样能不能快速回放。这篇把质量评分、回放演练和 closure SLA 串成一条最小治理闭环。

上一篇我们把退役状态机和季度 evidence pack 接起来了。

那一篇解决的是“能不能把债正式关掉”和“季度审查有没有固定材料”。

真跑上一个季度后，新的坑很快就会露出来：

  1. evidence pack 是有了，reviewer 还是看不懂
  2. 关闭请求提上来后，一挂就是很多天，没人说得清到底卡在哪
  3. 审计真来抽样时，团队只能翻截图和聊天记录，回放速度慢得离谱

平台团队到这一步，缺的通常不是更多表单，缺的是三件更硬的东西：

  1. 证据质量评分
  2. 审计回放演练
  3. 关闭 SLA

这篇就只补这三块，目标很简单：

  1. 把“有证据”升级成“证据可复核”
  2. 把季度抽查变成平时就在跑的回放演练
  3. 把关闭流程从人盯人，收成可追责的时效链路

1. evidence pack 有文件，不代表审查真能过

很多团队第一次把 evidence pack 跑起来时，体感会很好。

目录有了，工单也挂上了，审查会前还能自动导出压缩包。

真正到 reviewer 手里，问题还是一堆：

  1. 截图能证明“某个时刻存在”，证明不了“这一段时间都成立”
  2. 指标有趋势图，但没有对应控制对象的 scope snapshot
  3. 工单里写了“已恢复”，却找不到恢复动作对应的变更记录
  4. 风险接受到期了，pack 里还是旧 owner 和旧审批链

所以 evidence pack 的核心标准，不该停在“附件齐不齐”。

更实用的问法只有一个：

换一个从没参与过这条例外的人，他能不能在二十分钟内复原当时的判断。

如果做不到，说明包虽然存在，质量还不够。

2. 先给证据质量打分，不要继续靠经验判断

我更推荐先做一个轻量评分卡，维度别太多，第一版抓住五项就够了。

1) 覆盖度 coverage

要回答的是：该有的对象有没有都进包。

最低要求通常包括：

  1. 例外申请原文
  2. 风险接受记录
  3. 控制恢复或补偿控制证据
  4. 观察窗口指标
  5. owner 与 reviewer 的签字记录

缺任何一项，都不该直接进关闭流程。

2) 新鲜度 freshness

证据得和当前关闭动作处在同一时间带。

我一般会给一条简单规则：

  1. 指标快照距离申请关闭时间超过 7 天，扣分
  2. owner / reviewer 信息不是当前组织结构，直接判为失效
  3. 外部附件链接失效或需要个人私有权限，直接判为高风险

3) 可追溯性 traceability

审查最怕“看到结果，看不到来源”。

所以 pack 里每条结论最好都能回到原始对象：

  1. 监控图回到 dashboard URL
  2. 控制恢复回到变更单或 PR
  3. 风险接受回到审批工单
  4. 观察窗口回到原始查询条件

没有来源链路的“结论截图”，参考价值其实很低。

4) 可回放性 replayability

这项是很多团队最晚才补，代价也最大。

回放不是重新跑一遍生产动作，而是确认：

  1. 另一个 reviewer 能不能按 pack 中的链接、时间窗和查询条件拿到同类证据
  2. 当时为什么可以关闭，这个判断今天还能不能被解释清楚
  3. 如果同一条债要重开，团队能不能迅速定位失效环节

5) 签收完整度 signoff

关闭动作本质上还是治理决策。

没有明确签收，后面最容易扯皮。

最小要求至少包括：

  1. owner 提交关闭
  2. 平台或安全 reviewer 审核
  3. 需要合规参与的场景，留下最终签收

一个够用的阈值就行

第一版不用做复杂权重模型。

我通常会先用 100 分制，按下面的闸门收口：

  1. 90-100
    可直接进入关闭审批
  2. 75-89
    允许继续流转，但必须补件
  3. <75
    不进入关闭流程，退回补材料
  4. 任一关键项缺失
    直接判定 blocked

这样做的好处很直接：

reviewer 不再只会说“感觉这包还差点东西”，而是能指出差在哪里。

3. 季度抽查别只看结果，做成 audit replay drill

很多团队把季度审查看成“审计来了再准备一下”。

这会让 pack 长期停在静态归档状态。

更稳的方式，是把季度抽查改成固定的 audit replay drill。

意思很简单：

每个季度，从最近关闭或退役的例外里抽一批样本，让没参与过原关闭的人按证据包做一次回放。

回放关注的不是文章写得漂不漂亮，而是三件事：

  1. 能不能复原当时的风险边界
  2. 能不能解释清楚为什么批准关闭
  3. 能不能定位一旦失效该从哪重开

回放演练怎么抽样

第一版不需要抽很多。

我建议：

  1. 每季度抽最近关闭样本的 5%-10%
  2. 高风险或跨团队例外强制入样
  3. 当季度被 reopen 过的对象优先入样

回放演练至少产出什么

每次 replay 最少落四个结果：

  1. pass
    证据完整，判断可复原
  2. warn
    能复原，但有缺口
  3. fail
    无法复原或关键链路断裂
  4. action
    对应补件、补链路或改规则的整改项

回放演练最有价值的地方

它会很快把“平时看不出来，审计时一定出事”的问题翻出来：

  1. dashboard 已经换了，旧链接没人维护
  2. 关闭说明写了结论，没有写观察窗口
  3. 原 owner 离职后，签收链没人补位
  4. pack 里的数据导出来自临时查询，没人知道查询条件

这些问题靠人工经验很难持续抓，靠 replay 反而最容易发现。

4. 把关闭 SLA 单独拉出来，不要跟普通工单混算

很多关闭动作拖延，不是因为事情做不完，而是因为时钟根本没定义。

常见混乱点有三个：

  1. 从申请创建那一刻就开始算 SLA，结果大部分时间其实在补材料
  2. reviewer 看完提了一轮意见，状态没切回来，队列里像是“还在处理中”
  3. 高风险关闭和低风险关闭共用一个队列，结果全都慢

我更建议给关闭链路单独定义状态和计时点。

一条够用的关闭状态机

第一版用下面五个状态已经够了：

  1. draft
    owner 还在补 evidence
  2. ready_for_review
    证据达到最低门槛，开始计 SLA
  3. needs_patch
    reviewer 退回补件，SLA 暂停
  4. approved
    关闭获批，等待系统落账
  5. closed
    正式关闭，可进入季度 replay 样本池

计时点怎么定义更合理

我一般会这么切：

  1. ready_for_review -> approved
    作为主审 SLA
  2. approved -> closed
    作为系统落账 SLA
  3. needs_patch
    不计 reviewer 时长，单独记 owner 补件时长

这样你就能把“审得慢”和“补件慢”拆开。

关闭 SLA 的最小阈值

可以先给一个朴素版本：

  1. 低风险关闭：2 个工作日内完成审核
  2. 中风险关闭：3 个工作日
  3. 高风险或跨团队关闭：5 个工作日，并要求额外签收
  4. approved 后 24 小时内未正式 closed，自动告警

别一开始就做复杂优先级系统。

先把时钟跑起来，比设计一套很漂亮却没人维护的路由更有用。

5. 用一条自动化流水线把评分、回放和 SLA 串起来

这一步最关键的不是写多少脚本，而是让三个动作用同一份对象模型。

一个简单的 closure case 至少要有：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
const closureCase = {
  caseId: 'exc_2026_0412',
  riskLevel: 'medium',
  status: 'ready_for_review',
  score: {
    coverage: 20,
    freshness: 18,
    traceability: 20,
    replayability: 16,
    signoff: 20,
    total: 94
  },
  sla: {
    reviewStartedAt: '2026-04-06T01:00:00Z',
    approvedAt: null,
    closedAt: null
  },
  replay: {
    required: true,
    sampled: false,
    result: null
  }
};

有了同一份对象，流水线就能拆成三步：

  1. 每天跑一次证据评分，低于阈值直接退回
  2. 每小时扫一次 ready_for_review 和 approved，做 SLA 告警
  3. 每周或每季度按规则抽样，把 closed 对象推到 replay 队列

我更倾向先用最朴素的三张表或三个 JSON 集合：

  1. closure_cases
  2. evidence_scores
  3. replay_results

不要一上来为了治理系统去造治理平台。

6. 这条链路里最容易漏掉的四个坑

1) 只给 pack 打分，不给查询路径打分

附件齐全不代表可复核。

如果 pack 里没有原始查询入口，审查时还是会退化成“相信上传的人”。

2) replay 还是原 owner 自己做

这样很容易变成自证清白。

回放一定要换人，至少换到同域但不同责任人的 reviewer。

3) 用关闭完成时间考核 reviewer

这会把 owner 补件耗时也算到 reviewer 头上。

指标一旦混了，后面改流程很难说清责任。

4) 只看平均 SLA，不看卡点分布

平均值很容易把长尾问题盖掉。

真正该盯的往往是：

  1. 哪个队列最常进 needs_patch
  2. 哪类证据最常被退回
  3. 哪类关闭最容易在 approved -> closed 之间掉链子

7. 一周最小落地顺序

如果你准备把这套东西补起来，我建议按下面的顺序做。

第 1 天：给现有 evidence pack 补评分字段

先别改审批流。

只要让每个关闭对象多出一份可解释的质量分，你就已经比“凭经验看包”前进了一大截。

第 2-3 天：把 ready_for_review 设成唯一 SLA 起点

这一步会立刻把流程时钟清楚很多。

你会第一次看清楚，到底是谁在拖。

第 4 天：拿最近 10 条已关闭样本做一次 replay

不要挑最规范的样本。

挑最近、最容易出事、跨团队最多的那批。

跑完一次，你大概率就知道 pack 结构该怎么改了。

第 5-7 天：补自动告警和季度样本池

到这一步再上自动化最合适。

因为你已经知道：

  1. 分数怎么算
  2. 状态怎么流转
  3. replay 到底会暴露哪些真问题

总结

退役机制和 evidence pack 做完后，治理系统离“可审查”还差半步。

这半步通常就卡在三个地方：

  1. 证据质量没有统一标准
  2. 关闭动作没有独立 SLA
  3. 季度抽查没有被做成可重复的 replay

把这三件事补上，例外债治理才算从“能关单”走到“关得住，也讲得清”。

下一篇我会继续沿这条线往下写，重点放到例外债关闭后的复开预警、季度治理例会节奏，以及跨季度整改承诺追踪。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-control-evidence-quality-audit-replay-closure-sla-minimal-practice/