客服系统建议给一笔订单退款。页面显示“高信心”，员工却看不到是哪笔订单、使用了哪一版政策，也不知道是否已经发出替换商品。建议可能是对的，但员工无从判断。这是说明问题的客服情境，不是已报道的事件。
一场决策支持演示展示了更容易核查的做法：复核者可以看到构成建议的测量值，并打开底层检查，而不是只收到最终建议。演示发生在医疗环境，独立验证尤其重要；它本身并未证明临床准确性。我们可以把设计原则用于风险较低的工作，却不能照搬提供方对结果的宣称。
结论压缩了证据
压缩很有用。一个要判断是否退款的人，并不想逐条读取漫长日志。建议能把长记录变成下一步行动，但压缩会丢掉细节，其中可能正有足以推翻结论的信息。
看一段示例订单历史。客户说包裹丢失；模型看到承运商状态是“未送达”，建议退款。另一条记录却说今天早上已经发出替换商品。如果建议隐藏后者，员工可能对同一问题给出两次补偿。若两条事实及其时间都可见，员工就能据此判断。
要求行动之前，界面应回答四个问题：观察到了什么？来自哪里？有多新？什么情况可能使建议错误？一段流畅的理由只是答案的一部分。
来源观察和复核者由一条注明出处与不确定性的建议连接；复核者能够检查原始记录。
“因为配送失败所以退款”听起来通顺，承运商状态却可能已经过时。
| 可见元素 | 让复核者测试什么 |
|---|---|
| 建议与拟采取的行动 | 行动是否符合任务 |
| 带时间的来源观察 | 事实是否最新且完整 |
| 缺失或冲突的证据 | 是否应暂停或继续调查 |
| 原始记录入口 | 摘要是否漏掉关键细节 |
| 结果与修正记录 | 类似建议是否反复出错 |
这是一张概念性的界面检查表，不声称某个仪表板已改善决策。
把不确定性放进工作，而不是脚注
系统不确定可能有多种原因：来源没有响应，两个标识可能指同一订单，政策在上次建立索引后变了，或模型无法确定自由文本投诉的含义。它们是不同失败模式，应该用不同方式显示。
当操作人员可以查清一项缺失事实时，仅写“信心低”远远不够。应显示“承运商数据最后更新于昨天”或“无法获取替换商品记录”。若系统没有可靠的评分依据，就别在页面上放一个精确百分比。目标是让复核者知道下一步该查什么。
数据同步也需要这套结构。目标收到新客户状态时，保留产生变化的源事件 ID、时间和规则。有人问某客户为什么进入活动受众时，团队可以逆向追踪。无法解释的复制值，就是没有证据的结论。
这个拟议的 Tajo 视图区分活动记录报告的结果与尚未证实的事。写入显示为已应用，目标系统检查仍待进行。Tajo 现有活动记录提供结果和原始事件；新增验证面板只是说明如何让这条边界更清楚。
写入完成仍需证据
客户同步完成了吗？
写入已应用，验证待进行。
尚未检查目标系统的状态。
同步活动
- 请求已接受
- 更新已应用
- 目标系统检查待进行
示例运行 · 14:32 UTC
已知信息
- 服务商响应
- 已接受
- 写入结果
- 已应用
- 从目标系统回读
- 待进行
调用成功不能证明最终状态。
此拟议布局参考 Tajo 的活动记录。图中增加了验证状态，并不表示目标系统回读功能已经实现。
让复核有用，同时限制暴露
大多数日常行动不需要打开整份案卷。好的界面可以让建议保持简短，让证据一步可达，也可以只突出可能改变选择的差异。这不等于把依据全部藏起来。
展示更多数据有真实的隐私代价。复核者只应看到决策所需的字段，且遵守底层记录的访问规则。证据可见不等于可以查看客户所有历史。保留期限和审计日志也要有负责人。
还有自动化偏见：即使展示建议，也可能影响复核者。测试他们能否发现刻意设置的矛盾，能否不受界面阻碍地选择“证据不足”。上线后测量修正和撤销情况。悦耳的解释不是结果指标。
复核界面还应记录不同意见。员工拒绝退款建议时，让他选一个足以改进系统的具体原因：订单匹配错误、承运商状态过时、替换记录缺失，或政策例外。不要让每次不同意都变成长篇说明。汇总原因，检查是否某个来源反复出问题。这样才能从一次复核走向系统修复。工作流发现指南帮助在建建议前找到真实的例外路径。结论旁的证据帮助今天的复核者，修正数据则可能改善明天的决策流程。
对于有后果的行动，复核路径应该写进产品契约。系统提出建议，列出所用证据，说明无法核查什么，并记录最终结果。证据不足时，最有用的结论可能是“先等一等”。
常见问题
解释会让一条建议可靠吗？
不会。看似合理的解释也可能伴随错误结果。复核者需要原始观察、来源、不确定性和实际结果，而不只是一句自信的说明。
自动建议旁应展示哪些证据？
展示使用的具体观察及其来源和时间、缺失的输入、必要时的规则或模型版本，以及查看原始记录的方法。
什么时候必须有人复核？
当后果超出系统授权范围，或证据不完整、过时、存在争议时。复核者必须能够真正提出异议并停止行动。