ChatGPT 输出事实核查的可复用 Prompt

为什么要对ChatGPT的答案进行事实核查？

因为模型被优化到看起来可信，而可信不等于真实。语言模型产生最符合问题形状的答案——这通常与真实重叠，但有时不重叠。失败模式不是明显的荒谬；而是那个90%正确但带有一个错误的承重细节的自信句子。再流畅的措辞也无法从外部区分这两种情况。只有检查才行。

ChatGPT的答案不会停留在聊天窗口。它会被粘贴到PR描述中、被引用在设计文档里、在会议上被重复说出来（"据说……"），这时候它的错误就变成了你的错误，上面还附着你的名字。在重复之前对答案进行事实核查不是偏执，这和在合并前运行测试的卫生标准一样。

好消息是：你不需要验证所有内容，也不需要花一个下午进行研究。你只需要一条分流规则和一个复制粘贴的事实核查prompt——它在ChatGPT、Claude或Gemini中都能用。两者都在下面，还有一个真实的测试运行和对短版本在何处失效的诚实说明。

哪些声称实际上值得检查？

并非所有的——这是让人们完全放弃验证的错误。我使用的分流规则是：

检查那些如果被证明是错误的话会改变你决定的声称。其余的跳过。

在实践中，这意味着三个类别需要按顺序检查：

你即将采取行动的声称 ——"这个API的速率限制是X"、"这个许可证允许Y"。

你即将向他人重复的声称 ——任何进入文档、PR或你作为信息源的对话中的内容。

看起来太整洁的细节 ——精确的百分比、命名的研究、整齐的版本历史。

其他的一切——背景信息、一般上下文、措辞——可以保持未验证状态，因为在这里出错对你没有成本。

复制粘贴的ChatGPT事实核查prompt

一旦分流流程给了你一个重要的声称，对其进行压力测试。将下面的内容粘贴到一个新的聊天中——故意不在产生该声称的聊天中，这样模型就没有辩护的利益了：

Stress-test the claim below. Do not assume it is true.
1. Restate the claim precisely; note any ambiguity.
2. Falsifiability: what evidence would prove it wrong?
3. List the 2-3 conditions the claim silently depends on.
4. Name the most likely confounder or alternative explanation.
5. Verdict: SUPPORTED / UNCLEAR / DOUBTFUL, one line why,
   and the single fastest check a human should run.
Claim: [PASTE ONE CLAIM]

这个设计刻意带有对抗性。大多数"这是真的吗？"prompt邀请模型与自己达成一致；这个则强迫它构建反对该声称的案例——什么会证明它是错误的，它默认依赖什么，什么其他的东西可以解释它。只有经过攻击后还能存活的协议才会出现在判决中。

真实声称会发生什么？

我拿了一个你可能在代码审查中听过作为事实陈述的声称来测试：「使用ORM可以防止SQL注入。」一次通过，Claude Sonnet，新鲜上下文——prompt本身是模型无关的，可以原样粘贴到ChatGPT中。结果是这样的：

歧义首先浮现了：「防止」是指免疫还是降低风险？「使用ORM」是否包括每个ORM都提供的原始SQL逃生舱口？

可证伪性，具体来说：一个真实的ORM代码库注入案例就能证明它是错的——这一通过的结果指出了这样的案例会出现的确切位置：带有字符串连接的raw()、text()、execute()逃生舱口，以及被用作标识符的不受信任输入（表名、列名、排序方向），这些ORM通常不会参数化——它们只参数化值。

沉默的条件：开发者永远不会触及raw-query API；不受信任的输入永远不会到达标识符位置；ORM自己的参数化是无bug的。

混淆因素——我最喜欢的部分：实际上防止注入的东西是参数化查询。ORM只是默认让你走这条路。把功劳归给ORM混淆了工具和机制。

判决：DOUBTFUL——风险降低了，但不是消除了——带上最快的检查方法，这是我会真正使用的：在代码库中grep ORM的raw/execute逃生舱口，然后查找字符串连接。

这是对该声称的比大多数人进行的安全审查更好，而且花费不到一分钟。注意是什么让它发挥作用的：该声称是承重的（人们因为它而跳过输入卫生处理），而且prompt是攻击而不是同意。

单一声称prompt的限制在哪里？

日常使用中，短版本有四堵墙你会撞到：

一次一个声称，且你来做提取。 完整的ChatGPT答案包含十多个声称缠绕在散文中；把它们提取出来并挑选出承重的是你的工作。（这个提取步骤是一个独立的工具——见这个系列第一部分的幻觉检查器。）

没有分级的信心。 SUPPORTED / UNCLEAR / DOUBTFUL是三个桶；当你决定是否要发布时，"到底有多怀疑？"是重要的。

没有证据结构。 短prompt说明了什么证据会解决该声称，但不会组织什么支持对什么反驳——你需要在你的办公桌上重建这个。

一致性漂移。 自由格式的输出意味着审计的深度在运行和模型之间变化。

我常常对声称进行压力测试，所以我维护完整版本作为付费prompt：Fact Checker: Claim Stress Test on PromptBase。同样的对抗性核心，加上1–5的信心评级、结构化的支持证据/反对证据，以及每次运行相同的审计深度——它被构建来反驳，而不是同意。

幻觉检查或事实检查——你需要哪一个？

它们是不同的通过且可组合：

幻觉检查（这个系列的第一部分）： 扫一整个AI答案，提取每一个声称，标记伪造模式。宽泛而浅层——它找到嫌疑人。

声称压力测试（这篇文章）： 取一个重要的声称并深入地压力测试它。狭窄而深层——它询问嫌疑人。

当整个答案未经验证时先扫一遍；对你即将采取行动的幸存者进行压力测试。对于有人单独交给你的声称——会议中的一个统计数据、审查中的一个"最佳实践"——跳过扫一遍，直接进行压力测试。

快速AI事实核查例程

无论判决如何，模型的话是地图，不是领土。结束例程：

DOUBTFUL判决： 运行审计所说的"最快检查"。这通常是一个grep、一个changelog或一个官方文档页面。

高风险声称上的SUPPORTED判决： 仍然抽查它列出的单一最强条件。来自模型的支持是一个论证，不是一个来源。

任何带有命名研究或精确数字的东西： 搜索确切来源。找不到快速？把它当作伪造的并删除。

永远不要比你的验证所支持的更自信地重复一个声称。「文档说X」和「模型推理出X」是不同的句子——要让它们保持不同。

本文由AI协助编写；上面的测试运行如所述进行（一次通过、Claude Sonnet、新鲜上下文），并在摘要中忠实报告。重现它：把ORM声称粘贴到检查器中并比较。

完整版本：Fact Checker: Claim Stress Test。本系列前作：How to Catch AI Hallucinations。