企业官网建设流程全解析

上个月差点出一次事故。客服 Agent 自动给一批用户发了补偿通知，其中三封的金额字段被模型填错，多了一个零。幸好在那之前我先加了一道人工确认，值班同事拦下了。从那以后我把"哪些动作必须过人"写成了硬规则，这篇把这套审核队列的做法整理出来。

先给结论表。

一、阈值怎么定

置信度阈值别拍脑袋。把模型近一个月的输出按置信度排序，看错误集中在哪个区间，阈值划在错误率陡升的分位数上。我这边划完之后，需要人工的比例是 8%，把已知的严重错误全拦住了。每季度重新校准一次，模型换了、prompt 改了，分布都会漂。

二、确认卡的设计

审核页面别把原始输出扔给人看。卡片三块内容：结论一行加粗放最上面，中间是模型判断的依据和证据链接，底部三个按钮：通过、修改后通过、拒绝。金额、日期这类关键字段高亮，改过的字段记录修改人和修改前后值。

有个细节很省钱：同类操作支持批量确认。每日几十条常规通知，逐条点开人会被逼疯，批量页只展示有差异的字段，五分钟能过一百条。

三、状态机与超时兜底

每条待审任务是个状态机：待审、通过、驳回、超时。超时的默认动作是拒绝，不自动通过。这条规则救了上面那批通知，有一单卡在周末没人审，周一超时被拒后重新走了流程。

审核动作全部留档：谁在什么时间改了什么字段，日志留六个月。出问题复盘的时候，这是唯一能还原现场的东西。

四、实测账

口径说明。数字来自我自己的项目两个月运行数据，场景不同差别很大，先跑一周拿到自己的基线再调阈值。

五、踩坑记录

坑一，阈值设太高，人忙不过来。第一版阈值设得保守，需要人工的比例到了 35%，审核队列积压，业务开始绕过系统走线下。阈值要往"拦得住事故"上收，别往"全都看一眼"上放。

坑二，确认卡信息不全，审核只能盲点。只给结论没给依据，审核人无法判断，最后变成无脑点通过，这道防线形同虚设。依据和证据链接是卡片的核心，比结论还重要。

坑三，驳回没回流。被驳回的样本是免费的高质量训练和评测数据，我一开始没存，后来加了自动归档，每周把驳回样本过一遍，找出共性再改 prompt，错误率降得比调参快。

六、总结

结合系列。结构化输出篇的校验管的是机器能不能读懂，这篇管的是人要不要放行，两道闸在流水线上前后相接。RAG 评测篇的回归集口径在这里同样用得上，阈值调整之后跑一遍历史样本，确认没放走原来能拦住的错误。

来源。人工确认的触发分类与状态机设计按自己的项目实践整理，阈值分位数法参考了公开的模型校准资料，实测数字按自己的项目两个月运行口径。

觉得有用点个关注。