跳至交互体验

02 / 验证

数字没错⁠。 问题答偏了⁠。

答案生成的速度,早已超过人核验的速度⁠。数字越像真的,错误越难察觉⁠。给出答案时,也要给出核验的依据⁠。

亲手体验这个机制

说它正确,要有依据。

交互体验虚构案例
02 / 验证

向下探索,亲手操作。

01同一个问题,又是 94%。

一周后,另一笔大额订单带来了同一个问题。智能体又回答了 94%。记忆里还留着上次的修正,但这不代表答案会遵守它。

做决定前,分开查两件事:算得对不对,答的是不是这个问题。

02算得对吗?

按答案采用的口径,重新统计上个月的 100 笔订单。

03回答了这个问题吗?

把答案采用的口径,与记忆中的修正逐项对照。

还未核对计算。 先核对计算

04用两种口径,各算一次。

同样的 100 笔订单,分别按工厂承诺交期和客户要求交期统计。

还未核对计算。 先核对计算

05接不接,由人决定。

答案连同口径和依据,一起交给销售负责人。这笔交期紧迫的大额订单,接不接?

还未核对计算。 先核对计算

算得对, 不代表答得对。

设计原则

把验证拆成两步:计算是否正确,口径是否符合问题。口径不明,就明确说不明。决定交给人,决定本身也要留下记录。

这是一个虚构的简化示例,用 100 笔模拟订单验证一个问题。两组比例均由页面中的订单数据实际计算得出。真实验证还需要核对口径的来源和统计范围。