做产品 PMaker
空格的键盘
不用逐条查证 —— 三个动作就能筛掉大部分编造 ① 查来源 它说「根据 XX 报告」——去翻原文 引用不存在 = 一眼假 能翻到原文,顺便核对数据 ② 找反例 「这样一定行」——想一个反例 有反例而不提 = 没想全 能说出例外 = 真懂 ③ 复算数字 关键数字自己算一遍 百分比、金额、日期最容易编 算出来对不上 = 别信那句 什么时候必须做 要转发、要汇报、要做决策的时候 —— 一个动作都别省 目标是筛掉「会害你的错」,不是逐句验真 —— 三个动作恰好够用

核实不是逐句验真,是筛掉会害你的错。三个动作,覆盖了模型编造最密集的三个位置。

核实 AI 回答的三个动作

模型的编造能力远被低估——它编得流畅、自信、有出处。逐句验真不现实,但三个动作就能筛掉大部分会害你的错。

你会遇到的现象
  • 它引用了不存在的报告、不存在的作者、不存在的网址
  • 讲了一堆听起来很对的「道理」,但经不起一个反例
  • 百分比、日期、金额算出来对不上,你没发现就用了

三个动作

① 查来源。凡是回答里出现的引用、数据、人物、文献——去翻原文。这一步筛掉的编造最多:模型最擅长编出「看似真实的来源」,从报告名到作者名全编。引用查不到,这条基本不可信。能查到原文,顺手把原文里的数字和它引用的数字对一遍——它经常「记得」个大概就写出来。

② 找反例。回答里所有「一定」「都会」「从不」这类断言,想一个反例。它说「这个方法一定能提升转化」——想一个它失效的场景。说得出例外、能主动交代边界,说明真懂;一口咬定没有例外,多半是没想全,甚至是在顺着你说。这个动作针对的是模型的「迎合倾向」:它倾向于说出你期待听到的结论。

③ 复算关键数字。百分比、金额、日期、换算——自己动手算一遍。这是模型编造最密集的区,也是最好抓的一类:数字对不上,那一句就不能信,无论其他部分多顺。算一遍只要几秒,却能拦下最致命的那类错误。

为什么够用

这三个动作不是随机挑的,它们对应模型编造的三个高频区:

来源最容易编。生成「看似可信的引用」不需要任何代价,模型随手就来。所以查来源的性价比最高。

逻辑最容易迎合。模型被训练得倾向给出「合理、平滑」的回答,遇到不确定的也会顺下去。它的目标不是「对」,是「像对」。找反例专治这种平滑。

数字最容易错。Token 预测天然不擅长精确计算。它学的是「这段文字大概长这样」,不是真的做算术。所以复算数字是必杀技。

三个动作合起来,覆盖了「编来源」「顺着说」「算错数」——模型编造的主要形态。剩下的零散小错,用「会不会害到我」来权衡要不要查:会,查;不会,放过。

什么时候必须做

不是每个回答都要三个动作。按场景分级:

随便看看 → 可以不做。获取灵感、头脑风暴、理解概念。错了也无妨,直接信。

要转发、要汇报 → 至少查来源。你要对内容负责,就要先对它核过。

要决策、要操作 → 三个全做。涉及花钱、签约、改数据——这一类的确不能省。模型只是提建议,决策是你做的,责任也在你。

最后一条:把核验当成产品功能,而不只是个人习惯。如果你的产品里 AI 会给出可能影响用户判断的回答,设计时就要带上出处、带上可核验的链接、甚至主动提示「本段可能需要核实」。带出处的回答不只是工程细节,它把「可不可信」从用户的问题变成了产品的设计。

不是每个回答都要三个动作,按场景分级就好 随便看看 获取灵感、头脑风暴、理解概念——错了也无妨 可以一个都不做 要转发、要汇报 你要对内容负责,就要先对它核过 至少查来源 要决策、要操作 涉及花钱、签约、改数据——模型只是提建议,责任在你 三个动作全做 查来源 · 找反例 · 复算关键数字 —— 分别对着模型编造的三个高频区:编来源、顺着说、算错数 把核验做成产品功能,而不只是个人习惯:带出处、带可核验的链接、必要时主动提示「本段可能需要核实」。
最后那条是关键的转变:带出处的回答把「可不可信」从用户的问题,变成了产品的设计。剩下的零散小错,用「会不会害到我」来权衡要不要查——会,查;不会,放过。