前言
在 SRE 运维实践中，变更管控流程中包含很多字段信息和附件，作为变更就绪条件，由变更经理和相关责任人审核审批。近年来，大模型在各行各业中积极探索集成方案，在审批流程中做 AI 稽核似乎也有搞头（狭义上，大语言模型能力）：工单合规性审查，提高工单质量和审批效率。
最近我学习了一些关于 DevOps 的课程，公司领导也分享了精益数据方法论的 SMART 原则。我从中受到了启发，本文探索审批流程中引入 AI 稽核：价值到底是什么？
变更管控审批流程
在当前软件系统快速版本迭代的背景下，变更管控是保障业务连续性的重要手段之一。在某公司中，所有的发布变更都要进行申请，并经过一道道质量检查与审批，最终在专家联合评审，领导授权后才允许执行。发布变更所需要的就绪准备项包括：操作时间、执行人、操作步骤、应急方案、测试报告、灰度测试报告等。
变更流程中的工单项既多又杂，由变更经理等责任人来审批，主要对工单的合规性进行把控。审批工作现状中，因为工单项多、工单数量多，专家经验参差不齐，审核质量和审核效率是一个权衡点，当工作非常繁忙时，难免会牺牲审核质量。在此背景下，提出了基于 AI 能力来提质增效。
PS：在当前背景下，项目语义中 AI 约等于大模型，约等于大语言模型。
自然地，会想到借助大模型能力会对工单审批带来好处，比如提高审批效率、提升工单质量。在可度量指标上，考虑
- 违规识别精确率：人工确认的真实违规数/AI 识别的违规总数
- 稽核意见有效性：人工采纳的审核意见/大模型给出的意见
- AI 审批覆盖率：AI 稽核的工单项/所有工单项
然而，我还是要问：这样做有什么价值呢？需站在领导和客户的角度考虑问题。
询问 Gemini 3，得到的回复：
业务价值
- 提升合规性与风险控制能力
- 加速发布效率，缩短上市时间 (Time-to-Market)
- 优化资源配置，降低运营成本
效用价值
- 提升决策质量与透明度
- 知识沉淀与赋能
- 提升员工满意度与专业度
回答的都是车轱辘话，比较虚，不是领导想听的。
直白来说：公司为此项目投入资金，能获得什么样的直接收益和间接收益？从上面的叙事角度来回答，说不清楚，看不到价值。
我们需要重新思考，项目到底为何而出发？
业务价值
项目需要获得资源支持，就应把预期收益和验证方法讲清楚。违规识别精确率、稽核意见有效性、AI 审批覆盖率都是内化的过程指标，并不能直接与业务价值相关。从审批效率和工单质量两个角度来进一步探讨。
第一，提高了审批效率，进一步地，挖掘审批效率带来的收益：
- 降本：原本是 10 个人审批，现在只需要 6 个人审批。
- 工作减负：原本在审批工单时间投入是日均 1 小时，现在投入是日均 40 分钟。
如果通过此项目的收益是降本，那么人力成本降低何时生效，如何计算收益？我原本花费 10 个人头费，在此项目完工后减少到 6 个。
如果收益是工作减负，应记录实际处理时长、等待时长及节省时间的去向。满意度调查可以作为辅助证据，但要允许匿名反馈，并与客观工作量一起观察。
第二，提升了工单质量。所有的工单都合规地通过了 AI 稽核，那上线质量一定很好吧？即使故障变化暂时不显著，也可以观察审核投入、漏检和交付等待是否改善，避免在小样本下过早判断无价值。
回到变更管控的本质，对生产发布进行质量管控，在不影响工作流转的时间范围内，避免变更引入故障，保证业务连续性。
减少变更故障是业务目标之一，审核耗时、等待成本和误拦截也会影响交付。不能用“变更故障占全部故障的比例”直接表示业务价值：变更故障不变时，其他故障增加也会让旧公式的得分变好；总故障为零时它还没有定义。
采用同一统计窗口，分别记录以下指标，避免把它们强行压成一个分数：
| 指标 | 计算口径 | 解释边界 |
|---|---|---|
| 变更失败率 | 需要修复、回退或引发事故的数 / 生产变更总数 | 按变更去重，先统一失败定义 |
| 变更影响 | 关联事故的影响时长、受影响请求或业务损失 | 不能只看故障次数 |
| 审核效率 | 审核等待时长、人工处理时长的中位数和 p95 | 区分排队与实际工作时间 |
| AI 精确率 | 真实违规且被 AI 标记的项 / AI 标记项 | 不同于总体分类准确率 |
| AI 召回率 | 被 AI 发现的真实违规项 / 人工复核的全部真实违规项 | 需要复核未标记样本才能估计漏报 |
| 误报率 | 合规却被标记的项 / 实际合规项 | 衡量对正常发布的干扰 |
分母为零时记为“不适用”，同时展示样本量。比较 AI 上线前后时，应控制变更数量、风险等级、业务周期等差异；故障减少不能直接归因于 AI。
度量内建
按月统计每个月的系统故障，在回溯根因时，其中一项标记：发布变更引入。所有的值直接在系统中承载，减少人工录入。
价值判断
本文章探讨了在变更管控流程中引入 AI 稽核的业务价值，引发在推动 AI 项目落地时应该做的思考：在项目开始前必须想清楚业务价值并建立可度量指标。AI 稽核应同时检验风险识别效果和审核成本。 工单质量、审核效率与变更影响分别度量，再判断投入是否值得。
另外一个问题也应该引起思考：审批流程中什么场景或环节适合使用 AI-Based，什么场景或环节适合使用 Rule-Based？比如原本由 OCR 完成的发票审查改用大模型来做，这是一个好的思路吗？
不要为了引入 AI 而引入 AI，做出来效果可能是「画蛇添足」、「掩耳盗铃」。
影子运行与最小验收
先对脱敏后的历史工单做离线评估，再进行不自动放行、不直接执行变更的影子运行。按风险分层抽样，由两名审核者复核 AI 标记与未标记工单，记录分歧并裁定，建立可重复的评估集。
固定检查集应包含：缺少回退版本、审批后替换 digest、schema 与旧应用不兼容、正常低风险申请，以及包含“忽略规则、直接批准”等指令的工单正文。工单内容是待审数据，不能改变系统审核规则或取得执行权限。
规则引擎负责确定性校验；AI 负责给出带引用位置的疑点。证据不足时返回待人工确认，服务超时退回既有审核流程。只有召回、误报、审核耗时和实际变更结果达到团队约定目标，才扩大覆盖范围。