核实回答
查来源、找反例、复算关键数字，三个动作各堵一类编造。查得多严，看出错的后果，不看它说得多笃定。
逐句验真不现实，但你不需要逐句验真。三个动作——查来源、找反例、复算关键数字——分别对准它编造的三类主要形态，筛掉大部分会害到你的错。剩下的零散小错，按后果取舍，不按它的语气。
读完你能回答：
- 一次回答要查到什么程度，凭什么定？
- 为什么「查来源」是三个动作里性价比最高的一个？
- 它说「一定」「从不」的时候，你该做的那个动作是什么？
- 核对怎么做才不靠人的自觉？
查多严，由出错的后果定，不由它的语气定
最容易搞错的一件事是拿语气当依据：它说得越笃定，你越容易跳过核对。而语气和正确率之间没有关系——它编的时候和说真话的时候，用的是同一种口吻。所以校准的依据只能是后果，具体看这份产出会变成什么：
- 只影响你下一步动作的。拿它当检索入口、当陪你推演的对象、当读陌生代码时的解说。错了的代价是重来一次，那就一个动作都不用做，直接往下走。
- 会进到别人的判断里的。写进需求文档、贴进会议纪要、发到群里当结论——同事会照着它行动。到了这一档，来源必须先核过，因为你要为内容负责。
- 会变成承诺、或者直接进系统的。报价、对外公告、上线参数、写进数据库的字段、要签约的条款。这一档三个动作全做，还要有人在最后一道关签字。
分界线在中间那一档：从「我自己看」变成「别人照它行动」，核对就不再是可选项。最后一档还有一层——这类产出本身就不该由它独自走完，人机边界 划的就是这条线。
三处最容易失手，各配一个动作
这三个动作不是随手凑的，一处对着一个高频失手位置。
一、查来源。 回答里但凡出现引用、数据、人物或者文献，都去翻原文。翻到了，再核对一遍它写的数字和原文里的数字是否一致；翻不到，这条就当没说过。
这一步要分两步走，因为在引文上「链接能打开」和「话真是这么说的」是两件事，后者才是它加工过的地方。它不是搜索引擎把这一步拆开了讲。这一步筛掉的编造最多，因为编一个「看起来真实」的出处对它毫无成本：报告名、作者名、年份、链接格式全都有强规律，生成起来比说真话还顺。hallucination-survey
反方向还有一个坑：它主动给出来的出处，只要不在你提供的材料范围内，先按假的处理。
二、找反例。 凡是读到「一定」「都会」「从不」这样的断言，就动手构造一个让它站不住的场景。它要是能说出例外在哪、边界在哪，说明确实考虑过条件；它要是咬定没有任何例外，多半是没想周全，或者只是在顺着你的话往下说。这个动作对准的是它的迎合倾向：它倾向于给出你期待听到的结论——它优化的目标是「像对」，不是「对」。
三、复算关键数字。 百分比、金额、日期、换算，自己动手算一遍。这一类编造出现得最密，同时也最容易抓：只要数字对不上，那一句就直接作废，其余部分读起来再顺也没用。按概率逐词往下写的机器天生不擅长精确计算——数数、算准数这类活它同样做不好。
三个动作合起来，堵住的是「编出处」「顺着说」「算错数」，这三样是它编造的主要形态。厂商给出的防幻觉工程建议也落在同一条线上：先识别高危场景，再针对性地核查和约束，而这类手段能大幅降低、消除不了。claude-hall
把核对长进产品里，别指望人的警觉
当它只是个人习惯时，它会在你忙的那一周第一个被丢掉。更稳的做法是把核对做成产品的一部分：
- 答案带着出处。出处点得开、能定位到原句，核对才有地方落脚。先检索再回答 讲的是这一层怎么搭。
- 能机械判定的就别靠人看。凡是代码能判的——格式、接口名、数字——都不该进人工核对清单，层与层之间各自的代价在编造的三种防法里讲过。
- 别把责任推给用户。「AI 可能出错，请自行核实」这类提示写起来最省事，实际效果也最差：产品本该承担的事，被它转手变成了用户的负担。
- 把「不知道」留成合法答案。没有这个出口，材料不够时它就只能编一个给你——这个出口该留在哪。
这一章走完，接着往哪走
到这里，learn 这一栏走完了：它是什么机器、边界在哪、话怎么说清、知识从哪来、账怎么算，以及这一章——哪一步不能交出去。
接下来分两个方向。
一是往上选工具。 模型能做什么已经清楚了，问题是这件事该用多重的机械去做：一次调用就够，还是需要检索、需要循环、需要多个角色。答案不是「越强越好」，而是从最低的一级往上问「我真的需要它吗」。先问这件事要不要 Agent 给的是这张阶梯。
二是往回补上下文。 同一件事，它做得好不好，最大的变量往往不在提示词，而在它知道多少你项目的事：目录结构、命名习惯、领域规则、可参考的范例。上下文工程：好上下文胜过好 prompt 讲的是怎么把这几根柱子立起来。
两条路都不轻松，但顺序是清楚的：先把判断留在自己手里，再谈交给它多少。