在发布前验证 AI 输出：3 个提示词用于检查 AI 的准确性

你使用的每一个 AI 回答都会落在某个地方：配置文件、迁移脚本、或团队成员会信任的文档。未经验证就发布，意味着它的错误也会随之发布——并以你的名义。本文介绍我在发布前验证 AI 输出的工作流程：三个可直接复制粘贴的提示词，用于检查 AI 的准确性，每个提示词负责一个任务，组合起来只需几分钟，而不是一整个下午。

前两个提示词——幻觉扫描和 AI 事实核查提示——来自本系列前文（下方有链接，每个都有自己的测试运行）。第三个提示词——根据风险构建验证清单——是本文的新内容，已在下文的一个陷阱示例上进行了测试。

验证 AI 输出到底需要什么？

三个步骤，按顺序进行，每个回答一个不同的问题：

1. 扫描 — 这里有哪些声明，哪些看起来是编造的？ 覆盖整个回答，广度优先、浅层检查。
2. 压力测试 — 这个关键声明真的成立吗？ 针对会改变你决策的声明，进行窄而深的检查。
3. 清单 — 根据风险水平，这个文本应该接受哪些完整检查？ 把“我检查了一些东西”变成“我检查了正确的东西”。

大多数人在本能地完成第 1 步后就停下了。真正进入生产环境的错误通常出在第 2 步和第 3 步。

提示词 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]

Enter fullscreen mode Exit fullscreen mode

在第一部分的测试运行中，这个模式成功捕捉了样本回答中的全部三处植入错误——包括一个编造的斯坦福研究。权衡之处在于：它返回的是标签而非结论，且标记数量会随文本长度快速增加。

提示词 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]

Enter fullscreen mode Exit fullscreen mode

这个设计故意带有对抗性——它会构建反对该声明的论据，而不是邀请认同。在第二部分的测试运行中，这个事实核查提示词将代码审查中的民间说法“使用 ORM 可以防止 SQL 注入”推翻为 DOUBTFUL，并给出了使其失效的具体逃生口。

提示词 3：根据风险构建验证清单

全新提示词（完整版）——这一步决定文本值得接受多少检查：

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]

Enter fullscreen mode Exit fullscreen mode

按损害程度排序是关键。一个从最危险的声明开始的清单意味着，即使你只做了第一个检查，你也做了正确的检查。

清单提示词真的能抓住关键问题吗？

我给它输入了四句看似合理的 AI 风格升级建议——“使用 pg_upgrade 原地升级 PostgreSQL 12 到 16，停机时间不到一分钟，用 pg_dumpall 备份，之后运行 ANALYZE，扩展会自动升级，无需手动操作”——最后一句是植入的陷阱：流畅、安抚人心，但却是错误的。单次运行，使用 Claude Sonnet，新建上下文。返回结果如下：

• 风险：HIGH，理由正确——在生产数据库上执行此操作，可能在备份窗口关闭后导致静默的数据访问失败。
• 植入陷阱被排在第 1 项检查——被标记为虚假的 blanket claim，并给出了最快的检查方法（SELECT * FROM pg_extension;，然后查看每个扩展的兼容性说明）。
• 同一声明被标记为可使整体失效的声明——运行的结尾写道：依赖它，你可能会“完成升级并认为成功”，却在回滚窗口关闭后发现功能已损坏。
• 未植入的额外覆盖：它标记出“停机时间不到一分钟”默认依赖 --link 模式，未测试恢复的备份不算真正的备份，12→16 的多版本跨度本身需要验证，且文本中完全没有回滚计划——共八项检查，按损害程度排序。

最后一条要点正是清单步骤的真正价值所在：它不仅审计已存在的句子，还会揭示文本本应提及却未提及的检查项。

免费清单提示词的局限在哪里？

在同一次运行中可见三道墙：

• 事实优先的覆盖范围。 检查围绕文本中已有的声明展开。逻辑错误、边界情况和合规风险只有在文本恰好暗示时才会浮现——没有人会问“我们可能因此被谁起诉？”
• 凭感觉判断风险。 用一行文字判断 LOW/MEDIUM/HIGH 只是直觉判断。本次正确，但无法保证在更微妙的输入上也能做出相同判断。
• 结构不稳定。 检查数量、深度和措辞每次运行都会变化——适合一次性使用，但作为日常依赖的流程则不够稳健。

对于日常使用的版本，我将完整提示词维护为付费产品：PromptBase 上的 AI Verification Checklist Builder。它根据风险评估矩阵而非单行猜测来确定清单规模，将检查扩展到逻辑、边界情况和法律审查，而非仅停留在事实层面，并以相同的方式结束每次运行——列出可使其他一切失效的承载性声明。

三个提示词如何组合使用？

组合规则简洁：

凌驾于三个提示词之上的唯一规则：模型的审计只是地图，而非实地。每一个结论和每一项清单项最终仍需由人工执行检查——一次 grep、查阅文档页面、或一次测试恢复。这些提示词不会取代验证；它们确保你花在验证上的几分钟时间，落在真正可能伤害你的声明上。

本文由 AI 辅助撰写。本文中的清单测试运行按所述方式执行——单次运行，Claude Sonnet，新建上下文——并如实报告；此前提示词的测试运行记录在各自的文章中。复现本次测试：输入已在正文中引用。

完整清单版本已在上方章节中链接。如果你卡在提示词本身而非输出，我还维护了 Optimizer: Diagnose & Rewrite。本系列前文：捕捉 AI 幻觉 和 事实核查 ChatGPT。