验证 AI 输出：三个可复用的 Prompt 检查清单

你采用的每一个 AI 答案，最终都会落到某个实际位置：一份配置、一次数据库迁移，或是一篇团队成员会信赖的文档。如果未经验证就发布，那么其中的错误也会一并上线——而且署着你的名字。本文介绍的是我在发布前验证 AI 输出的日常流程：三个可以直接复制粘贴、用于检查 AI 准确性的 prompt。每个 prompt 各司其职，组合起来只需几分钟，而不是耗费整整一个下午。

前两个 prompt——幻觉扫描和 AI 事实核查 prompt——来自本系列之前的文章（链接见下文，每个 prompt 都有各自的测试过程）。第三个 prompt——根据风险级别生成相应规模的验证清单——是本文新增的内容，后面还会使用一个暗藏陷阱的示例对它进行测试。

验证 AI 输出究竟需要做什么？

按顺序执行三个动作，每个动作回答一个不同的问题：

扫描——这里究竟包含哪些主张？哪些看起来像是编造的？对整个答案进行广泛但浅层的检查。

压力测试——这个会影响全局的关键主张真的成立吗？针对那些会改变你决策的主张，进行聚焦而深入的检查。

清单——考虑到风险级别，这段文本应该接受哪些完整检查？这一步会把“我检查了一些内容”变成“我检查了正确的内容”。

大多数人只会凭直觉完成第一步，然后就停下来了。最终进入生产环境的问题，通常藏在第二步和第三步中。

Prompt 1：扫描答案中的幻觉

精简版如下：

Audit the text below for hallucinations.
List every factual claim as a numbered line; label each
VERIFIABLE, SUSPECT, or FABRICATION-PATTERN (named
source/study/number with no citation).
End with the 3 claims most likely to be wrong, ranked.
Text: [PASTE THE AI ANSWER]

在第一部分的测试中，这个模式成功找出了示例答案中人为埋入的全部三个错误，其中还包括一项虚构的斯坦福研究。它的代价是：返回的只是标签，而不是最终判定；并且随着文本长度增加，被标记的内容数量会迅速增长。

Prompt 2：对你即将据此采取行动的主张进行压力测试

Stress-test this claim. Do not assume it is true.
State what evidence would prove it wrong, the 2-3 conditions
it silently depends on, and the likeliest confounder.
Verdict: SUPPORTED / UNCLEAR / DOUBTFUL, one line why,
plus the single fastest check a human should run.
Claim: [PASTE ONE CLAIM]

这种设计是刻意带有对抗性的——它要求构建反对该主张的论据，而不是诱导模型表示认同。在第二部分的测试中，这个事实核查 prompt 将“使用 ORM 可以防止 SQL 注入”从代码审查中的经验之谈，转变为 DOUBTFUL 的判定，并准确指出了会让这一说法失效的那些绕过路径。

Prompt 3：根据风险级别生成相应规模的验证清单

下面是这个新 prompt 的完整版本——这一步用于决定文本值得接受多大程度的检查：

Build a verification checklist for the AI-generated text below.
1. State the stakes: LOW / MEDIUM / HIGH, and why in one line.
2. List 3 checks for LOW stakes, 6-8 for MEDIUM or HIGH — each
   check names what to verify and the fastest way to verify it.
3. Order checks so the most damaging-if-wrong claim comes first.
4. End with the one claim that invalidates everything if wrong.
Text: [PASTE]

重点在于按照潜在损害排序。一份从最危险主张开始的清单意味着：即使你只完成了第一项检查，也检查了最应该检查的内容。

这个清单 prompt 真的能抓住关键问题吗？

我向它提供了四句话，这些内容看起来很像 AI 给出的、颇具可信度的升级建议——“使用 pg_upgrade 将 PostgreSQL 12 原地升级到 16，停机时间不超过一分钟；使用 pg_dumpall 备份；升级后运行 ANALYZE；扩展会自动升级，因此不需要任何手动操作。”最后一个主张就是我预先埋下的陷阱：表达流畅、令人安心，但事实错误。测试使用 Claude Sonnet，在全新上下文中只运行一次。返回结果如下：

风险级别：HIGH，理由也正确——如果在生产数据库上照此操作，可能会在备份窗口关闭后出现无声的数据访问故障。

预先埋下的陷阱被列为第 1 项检查——模型指出，将它当成普遍成立的主张是错误的，同时还明确给出了最快的检查方法（SELECT * FROM pg_extension;，然后查看各个扩展的兼容性说明）。

同一个主张也被认定为能够让其他一切失效的关键主张——本次运行最后指出，如果依赖这一说法，你可能会“在相信升级已经成功的情况下完成升级”，结果却在回滚机会消失后才发现功能已经损坏。

它还覆盖了我没有预先埋入的问题：它指出，“停机时间不超过一分钟”暗中依赖 --link mode；没有进行过测试恢复的备份不能算真正的备份；从 12→16 的跨多个版本升级本身也需要验证；而且原文完全没有提供回滚方案——总共八项检查，并按照潜在损害进行了排序。

最后一点才是采用清单步骤的真正理由：它不只是审查文本中已经出现的句子，还会找出那些文本本应提及、却没有提及的检查项。

免费版清单 prompt 的能力边界在哪里？

从同一次测试中，可以清楚看到三项局限：

以事实为中心的覆盖范围。检查项主要围绕文本中已经出现的主张展开。逻辑错误、边缘情况和合规风险，只有在文本恰好有所暗示时才会浮现——毕竟没人问过：“谁可能因此起诉我们？”

依靠直觉判断风险级别。用一行文字在 LOW、MEDIUM、HIGH 之间做出判断，本质上只是一种凭感觉的检查。这次判断正确，并不意味着面对更微妙的输入时也能做出同样准确的判断。

结构会发生漂移。每次运行时，检查项的数量、深度和措辞都会有所不同——用于一次性任务没有问题，但作为每天依赖的固定流程就不够可靠。

对于日常流程版本，我将完整 prompt 作为付费产品维护：PromptBase 上的 AI Verification Checklist Builder。它会依据风险评估标准确定清单规模，而不是依赖一句话的猜测；检查范围也会扩展到逻辑、边缘情况和法律审查，而不是止步于事实；并且每次运行都会以相同方式收尾——列出那些一旦出错，就会让其他一切失效的关键主张。

这三个 prompt 如何配合使用？

组合规则很简短：

此外，还有一条凌驾于这三个 prompt 之上的规则：模型给出的审查结果是地图，而不是现实本身。每一个判定和每一项清单内容，最终仍然需要由人来执行实际检查——可能是一次 grep、查阅一个文档页面，或进行一次测试恢复。这些 prompt 不能替代验证；它们的作用，是确保你花在验证上的那几分钟，真正落在那些可能伤害你的主张上。

本文在 AI 协助下完成。文中的清单测试严格按照所述方式执行——使用 Claude Sonnet、全新上下文、仅运行一次——并如实报告了结果；前两个 prompt 的测试过程记录在各自的文章中。你也可以复现这次测试：输入内容已在上文完整引用。

清单的完整版本已在上一节中提及。如果你的瓶颈在于 prompt 本身，而不是它的输出，我还维护了 Optimizer: Diagnose & Rewrite。本系列之前的内容还包括：识别 AI 幻觉，以及对 ChatGPT 进行事实核查。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。