ARTICLE · 1031884
【让AI自己检查等于没检查】解决它每次自查都说没问题
怎么使唤 AI · 核查员
AI 编程助手做项目级对接方案工具链
让 AI 自己检查
等于没检查
解决它每次自查都说没问题
它干完一件活，你说「检查一下有没有问题」，它检查完回你「已核对，没有问题」。这句话你听过多少次？又有多少次是真的？问题不在它不认真，在于你让作者去审自己刚交的稿——谁审自己的东西都会手软。
办法是另开一个干净会话，让它以核查员的身份对着判据逐条核。这篇给一段可以直接抄的核查提示词，讲清核查项该怎么写才让它没法含糊，以及三条都过了之后那句「过了」该由谁说。工具是 Claude Code，环境按 Windows 写。
先说为什么
作者审自己的稿，和没立场的人对着判据核，是两回事
在干活的那个会话里，它是这些产物的作者。你让它自查，它带着「我刚才做得不错」的前提去看——不是撒谎，是它的上下文里全是自己做这件事的理由，每一处它都知道为什么这么写，看什么都顺眼。
换一个干净会话，它面对的是一堆陌生文件加一份明确判据。没有「我刚才干得不错」这个前提，只有「这几条满足没满足」。它不知道这是谁做的、为什么这么做，只能对着判据一条条看——这正是你要的。
这不是让 AI 互相监督的花活。它和人审自己代码的道理一样：写代码的人和审代码的人，最好不是同一个上下文。开一个新会话的成本很低，比你自己翻文件低得多。
可抄的原文
核查提示词，另开会话粘这段
在同一个项目根目录另开一个新会话——不用发开场白守则，那是给干活的会话用的，核查会话只干一件事。把下面这段粘进去，方括号按你的活替换：
本项目刚做完 [一句话说清做了什么]，产出在 [目录或文件]。
你没参与，请以核查者的身份，逐条给我结论：
① [有没有空着的、写「待定」「视情况」的？]
有就列出来，是哪几行。
② [关键的几个值现在是什么？逐个列出]
凡是带「待验证」「推测」「可能」的，标出来。
后面要直接用它们，不能是猜的。
③ [有没有向人提了问、但还没答复的条目？]
悬着的列出来。
三条都没问题就说「三条均满足」，别客气地放过。
有问题直说，别为了让我放行而含糊。
开头那句「你没参与」和身份「核查者」是这段的骨架，别删。最后两句也别删：「别客气地放过」堵的是它顺手替你圆场，「别为了让我放行而含糊」堵的是它猜你想听什么就说什么。这两种毛病，核查的时候尤其要防。
方括号怎么填
核查项要能数、能列，不能是「合不合理」
三个方括号是这段里唯一要你动脑的地方。写核查项有一条原则：问的必须是能数出来、能列出来的东西。「哪几行是空的」「这个值现在是什么」「几条悬着」——这种问题它答不含糊。而「设计合不合理」「有没有遗漏」这种问题，它答什么都对，等于没问。
举个填好的例子。接着《让 AI 当向导不当代驾》那篇的场景——你让它给老项目补了一批单元测试，现在要核：
本项目刚补了一批单元测试，产出在 src/test/ 下。
你没参与，请以核查者的身份，逐条给我结论：
① 新加的测试文件有哪几个？逐个列文件名。
每个文件里有没有写了方法名但方法体是空的、
或者只有一行 TODO 的？有就列出来。
② 这批测试跑过没有？
找测试报告或输出文件，贴通过数和失败数。
找不到报告就直说「没有运行证据」，别推测。
③ 被测的业务代码有没有被改动？
对比版本管理的改动列表，列出 src/main/ 下
所有被改的文件。这次只许加测试，不该动它们。
三条都没问题就说「三条均满足」，别客气地放过。
有问题直说，别为了让我放行而含糊。
注意第 ② 条的写法：不是问「测试通过了吗」，是问「找报告、贴数字、找不到就说没有」。问前者它会回「通过了」，问后者它得拿出东西来。第 ③ 条也一样——不是问「有没有改业务代码」，是让它去对比改动列表。每一条都要给它一个去处：去哪找、找到贴什么。
拿到结论之后
你只看它列出来的那几行
核查会话回来的东西，你不用通读，只看它列出来的那几行——空着的哪几行、带推测的哪几个值、悬着的哪几条。每一类对应一个固定动作：
① 有空着的
→ 回干活的会话让它补齐；补不了的明确标「待办」
② 带「推测」的
→ 回干活的会话让它回代码里查，查到出处为止
这条最要紧：后面要直接用的值，错一个后面全虚
③ 还悬着的
→ 该你答的答；能跳过的，明说跳过并记一笔
三条都干净
→ 回干活的会话说「三条都过了，进下一步」
前三类都是让干活的会话去补、去查、去答。最后那一类看着最简单，反而最容易做错——错在谁开口：
这句话谁说
「三条都过了，进下一步」——这句结论是你说的，不是它说的。核查会话回「三条均满足」，只是它对着判据看完的汇报；干活的会话更不能自己宣布过了。两个会话都只报状态，「过」这个字由你写回去。这和《让 AI 当向导不当代驾》守则第三条「只报状态，不下结论」是同一条规矩，只是换了个地方用。
对一下答案
核查会话有没有真核，看它回的样子
核查员本身也可能偷懒。判断它有没有真去看文件，盯回复的形态：
真核了 每条都带具体行号、文件名、数值
「第 3、7 行空着」「通过 12 失败 0」「改了 2 个文件」
没真核 通篇形容词，没有一个可以去查证的东西
「整体完善」「基本满足」「看起来没有问题」
最该警惕 三条全答「满足」，但没列任何东西
→ 让它把每条的依据贴出来，贴不出就是没看
这也是为什么核查项必须写成「能列出来」的——它回来的东西能不能查证，取决于你问的东西能不能查证。问得含糊，它答得含糊，你连它有没有真看都判断不了。
本篇做完你手里有什么
[ ] 一段可直接抄的核查提示词，「你没参与」别删
[ ] 三个核查项，每条都能数能列、都给了去处
[ ] 三类结果各对应一个动作
[ ] 「过了」这句话由你说，两个会话都只报状态
[ ] 会看核查员的回复形态，判断它有没有真看
这套做法不限于代码。它写的文档、它盘的清单、它给的方案，凡是你不想自己逐字审的，都可以另开会话让它核——前提永远是：核查项能数能列，结论由你下。
下一篇讲另一个常见的烦：它问题一个接一个，有的该你答，有的其实它自己翻代码就能答——怎么分，哪些直接顶回去。
怎么使唤 AI · 核查员 ｜ 四端异构 · SVN 主线 · 三个月 · 十轮全量评审