上个月差点出一次事故。客服 Agent 自动给一批用户发了补偿通知其中三封的金额字段被模型填错多了一个零。幸好在那之前我先加了一道人工确认值班同事拦下了。从那以后我把哪些动作必须过人写成了硬规则这篇把这套审核队列的做法整理出来。先给结论表。触发条件处理方式理由涉及资金变动全部人工确认错一次代价最大对外发送内容全部人工确认发出去收不回删除、覆盖类操作全部人工确认不可逆置信度低于阈值抽检加人工模型自己也没把握其余常规动作自动执行留日志不能把人也堵死一、阈值怎么定置信度阈值别拍脑袋。把模型近一个月的输出按置信度排序看错误集中在哪个区间阈值划在错误率陡升的分位数上。我这边划完之后需要人工的比例是 8%把已知的严重错误全拦住了。每季度重新校准一次模型换了、prompt 改了分布都会漂。二、确认卡的设计审核页面别把原始输出扔给人看。卡片三块内容结论一行加粗放最上面中间是模型判断的依据和证据链接底部三个按钮通过、修改后通过、拒绝。金额、日期这类关键字段高亮改过的字段记录修改人和修改前后值。有个细节很省钱同类操作支持批量确认。每日几十条常规通知逐条点开人会被逼疯批量页只展示有差异的字段五分钟能过一百条。三、状态机与超时兜底每条待审任务是个状态机待审、通过、驳回、超时。超时的默认动作是拒绝不自动通过。这条规则救了上面那批通知有一单卡在周末没人审周一超时被拒后重新走了流程。审核动作全部留档谁在什么时间改了什么字段日志留六个月。出问题复盘的时候这是唯一能还原现场的东西。四、实测账指标数值口径人工拦截率每千条拦下 3.2 条审核人点了修改或拒绝误拒率2%复查后确认原本输出可接受单条审核耗时约 20 秒批量页的平均值事故拦截2 起含上面那批错误金额口径说明。数字来自我自己的项目两个月运行数据场景不同差别很大先跑一周拿到自己的基线再调阈值。五、踩坑记录坑一阈值设太高人忙不过来。第一版阈值设得保守需要人工的比例到了 35%审核队列积压业务开始绕过系统走线下。阈值要往拦得住事故上收别往全都看一眼上放。坑二确认卡信息不全审核只能盲点。只给结论没给依据审核人无法判断最后变成无脑点通过这道防线形同虚设。依据和证据链接是卡片的核心比结论还重要。坑三驳回没回流。被驳回的样本是免费的高质量训练和评测数据我一开始没存后来加了自动归档每周把驳回样本过一遍找出共性再改 prompt错误率降得比调参快。六、总结环节一句话触发资金、对外、不可逆操作全量确认阈值按错误率分布划季度重校准卡片结论前置依据必给支持批量兜底超时默认拒绝日志留六个月回流驳回样本归档改 prompt 的原料结合系列。结构化输出篇的校验管的是机器能不能读懂这篇管的是人要不要放行两道闸在流水线上前后相接。RAG 评测篇的回归集口径在这里同样用得上阈值调整之后跑一遍历史样本确认没放走原来能拦住的错误。来源。人工确认的触发分类与状态机设计按自己的项目实践整理阈值分位数法参考了公开的模型校准资料实测数字按自己的项目两个月运行口径。觉得有用点个关注。