什么是对抗互查？让两个模型互相检查

两个智能体各写各的，容易错得整整齐齐；对抗互查的思路是让一个模型出稿，再请另一个模型专挑毛病，两个角色互相牵制，把单模型的盲区照出来。

先说结论

对抗互查是一种双模型协作方式：模型甲负责产出，模型乙负责审查，甲乙优先来自不同产品，至少也要是不同会话。它解决的痛点很具体——同一个模型自己检查自己的答案，连错误都常常长得一样；换一个「人」来看，问题才容易被看见。让腾讯元宝和 DeepSeek 互相核对一份材料，效果往往好过让 DeepSeek 检查自己写的稿子。为什么自查靠不住？模型给答案时用了一套思路，检查时大概率沿用同一套思路，错在哪一步它就看不见哪一步——这是视角问题，不是能力问题。具体到日常用法：让元宝写初稿，让另一个模型按「逐条找茬」的要求过一遍，再回到元宝修订，一轮下来大部分明显问题都能清掉。

生活里的对应

学校里互改作文就是这么回事：同桌帮你挑病句，比你自己读十遍管用，因为你脑子里装着「想写的」，看不出「实际写的」差在哪。类比有两条边界要交代：同桌水平相近时可能互相看不出问题，互查的两方视角差异越大越好；另外互查只负责发现问题，改稿仍要回到产出方或人来做，它自己不动笔。互查还有个附带好处：审查方为了挑错，会把原稿读得比产出方还细，很多含糊的表述正是被审查方先发现的。

多花一步值不值

分情况。答案很短、错了也一眼能看出来时，加一轮互查纯属折腾。内容要用于正式场合、错误藏在细节里、或者你对自己的检查没把握时，这一步就值。折中做法是把互查范围收窄，只查最要紧的部分——数字、结论和引用来源，其余放过。团队里经常做这类核查，可以把问法沉淀成提示复用的模板，写进团队提示规范，新人照着用即可；互查中发现的典型错误，也该随提示的文档化留档，下不为例。成本也要算清楚：互查至少多一倍的时间和用量，所以收窄范围比全篇互查更现实，先查最要紧的部分，尝到甜头再扩大。

怎么提问才像互查

给审查方的提示要给足立场：明确要求它找错、列出怀疑点，别泛泛问一句「这个答案对吗」。更硬一点的做法是要求逐句表态：认可、存疑还是反驳，并说明理由。查完把存疑项汇总回产出方修订，一轮不够就再一轮，两轮后仍争执不下的条目，留给人裁决。审查方的意见也要过筛，它同样会误报，照单全收等于换了一个犯错的人。还有一条纪律：给审查方只看成品，别附上产出方的解释说明——解释会带偏审查，让它顺着解释走，错处反而被圆过去。

对抗互查对照表

• 产出方：只管写，不理会挑刺
• 审查方：只管挑错，不用重写
• 查什么：数字、结论、来源优先
• 收束：两轮后分歧交给人

一句话带走：自己查自己容易走过场，换双眼睛才算真检查。

对抗互查快问快答三则

• 两个模型必须是不同产品吗？：不同产品视角差异大，效果更明显；同一产品开两个新会话也聊胜于无，只是盲区重叠更多。
• 审查方说的都对吗？：不都对，审查方也会误报，分歧条目要人工裁决，别全信也别全弃。
• 它和级联提示冲突吗？：不冲突，先级联提示出稿，再互查把关，两套动作各管一段。

把视角再放大一点：人和模型都需要外部视角，模型有对抗互查，人有同事审校，道理是同一个——写出一份东西和看出它的毛病，从来都是两种能力。