养成从业者的三个反射动作——对照官方文档交叉核对、自己动手测试、搜寻幻觉信号——然后再把任何东西集成进去。
在 Kodokon 中打开本课幻觉并不是一个荒谬的回答：它是一个貌似有理却错误的回答——一个本该存在却不存在的方法，一个两个版本前就被改了名的选项，一个被反转过来的默认行为。这恰恰是合格开发者的软肋所在：幻觉出的代码地道、命名讲究、与生态系统一致。它看起来是对的。在集成任何东西之前，有三个不容商量的反射动作：对照你所用版本的官方文档交叉核对，在一个极简环境里自己动手测试代码，以及让这个回答接受审计——包括让模型自己来审。
拿起你上一个回答，把它当成别人写的来审计。
1. 列出每一条可核实的技术断言：API 或函数名、所描述的行为、默认值、版本号。
2. 对每一条，给出你的置信度：确定 / 很可能 / 待核实。
3. 对每一条“待核实”，明确说出该去官方文档里查什么：相关页面、函数或模块的名字。
4. 标出任何可能取决于版本或平台的东西，若你知道，就注明它从哪个版本起成立。
对自己要比我更狠：一条被高估为“确定”的断言，让我付出的代价比一条被低估的更大。这套自我审计本身证明不了什么——一个模型可以既自信又出错——但它把流畅的行文变成一份可核实事实的清单，每一条都带着通往文档的入口。核实的人是你；AI 只是把地铺好了。也要学会识别那些危险信号：一个恰好裁剪得贴合你需求的 API（好得不像真的），同一个代码片段里混着来自不同版本的约定，一种完美均匀的自信——真正的专业会说“视情况而定”，幻觉从不这样——以及对任何限制或边界情形的只字不提。没有哪个单一信号构成证据，但每一个都该触发一次核实。
你刚才断言 [要核实的精确断言]。
1. 帮我设计一个尽可能短的测试，好让我自己去核实它：要创建的最小文件、要运行的确切命令、如果你说得对我应当观察到的精确结果——以及如果你错了我将观察到的又是什么。
2. 然后唱反调：在哪些情况下你的断言会是错的？版本、平台、配置、是否严格模式——统统过一遍。
我会自己跑这个测试：不要让我听你的一面之词，给我推翻你的手段。这条提示词把一条科学原则用到了日常工作中：一个断言若要有价值，就得可证伪——你得知道，一旦它是错的，你会观察到什么。一个用完即弃的文件里十行代码加一次运行，胜过任何声明出来的置信度。至于对照文档交叉核对，有三个习惯：在你所用版本的文档里核实（模型会毫不在意地把一个 API 的不同年代混在一起），当某个行为看似变了时查更新日志，以及始终开着一个 REPL 或草稿文件——核实的成本应当低到你永远没有借口跳过这一步。