这个提示词用来做什么

agent 给出了一个会影响决策的结论（一段分析、一个判定、一份生成结果），你知道单点信任风险高，要一套真能证伪它的复核方案

提示词全文

下面是一份 AI 给出的结论，我要在拿它做决定之前先验一遍。请帮我设计一份复核方案，不能只是让同一个模型「再想一遍」。

## 输入
待复核结论：{粘贴结论或判定}
它会被用在哪儿：{比如写进报告 / 触发一次自动操作 / 决定要不要投产}
如果它错了，代价是什么：{最坏情况}

## 输出
1）把结论拆成 2-4 个「可独立验证的子判断」，每个子判断单独写清楚「什么算成立、什么算不成立」。
2）给每个子判断配一条复核路径，并按可靠性排序：(a) 换一个独立来源或独立实现重算；(b) 换一批数据（不同时间段 / 不同样本）再跑；(c) 主动构造反例，专门去找能让它崩的输入；(d) 只换提示词重问一遍——这条排最后，因为相关性太高。
3）列出「如果复核结果和原结论不一致，优先信哪一个」的判据，并说明理由。
4）给出一个「在什么情况下值得直接放弃这条结论」的止损条件。

要求：不要用「多方验证可提高可信度」这种空话收尾；每一条复核路径都要写清具体怎么做、由谁或用什么工具做；如果某个子判断根本没法独立验证，就直接说「不可验证」并说明原因。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

第 2 步的排序是这份方案的关键：换一个独立实现（比如另一个检查器、另一套统计口径）才算真正复核，而「换个说法再问同一个模型」经常只是把同一个错误换了个措辞说回来。把最弱的那条路径排在最后并写明原因，能避免团队用「我们再确认过了」当成已经验证。

基本信息

  • 分类：工程
  • 标签：交叉验证 · 复核 · 可靠性 · 评测 · 工程
  • 收录日期：2026-10-11

同类提示词