Codex 冷审怎么用，才不会把复核做成流程负担

Codex 做完一项工作以后，最常见的收尾是跑测试、看结果、告诉你已经完成。这个流程对大多数日常任务都够用。问题出在另一类工作上。

比如它刚改完一套跨模块配置，又要自己判断有没有漏项。或者它准备执行一个无法轻易撤回的外部操作，还要自己确认风险。写答案的人和判卷的人是同一个，很多错误会从同一个盲区里溜过去。它前面认定某个前提成立，后面复查时往往还会沿着这条路继续走。

冷审就是在这个位置插进来的一次独立复核。

这里说的冷审，是一条写进 Codex 工作规则的审查机制。它没有一个点开就能用的固定按钮。主任务先完成候选结果，再把必要材料交给一个没有参与前面推理的新审查者。审查者只看任务要求、交付物和证据，不继承原任务里的判断习惯。

它最有价值的地方，也正在这点陌生感里。

冷审主要解决什么

普通自检擅长抓显眼错误。文件有没有生成，测试有没有通过，数量对不对，格式能不能打开，这些都适合交给脚本和确定性检查。

冷审更适合抓另一层问题。

第一类是前提带偏。主任务一开始理解错了要求，后面的实现和自检可能都很完整，只是完整地做错了。新审查者没有跟着走过那条推理路径，更容易问出一句，这真是用户要的吗。

第二类是结论过头。测试只证明了局部结果，正文却写成全面成立。一次实验没有设置对照，报告却开始归因。冷审经常能抓到证据和结论之间多跨出去的那一步。

第三类是风险遗漏。涉及账号、权限、付款、法律、医疗、数据删除、跨项目迁移时，一个小误判可能带来很大的后果。主任务忙着把事情办成，冷审专门看哪里不能轻易回头。

第四类是要求漏读。长任务里常有数量、尺寸、保存位置、命名、不得覆盖原文件之类的硬条件。实现者容易盯着核心功能，审查者可以逐条对照验收。

冷审没有取代测试。它解决的是测试不擅长证明的部分，包括任务理解、证据边界、风险判断和交付完整性。

什么情况下值得开

冷审一旦变成每次必做，很快就会沦为流程税。改一个文案错字也拉一个新审查者，既慢，也很难得到有价值的新发现。

更合适的做法是按风险触发。下面几种情况值得开。

一项操作很难撤回，或者会直接影响外部系统。任务碰到登录凭据、安全、付款、法律、医疗和数据丢失。要做较大的迁移，或者修改会穿过多个模块的公共配置。确定性检查跑完以后，关键结论仍然拿不准。还有一种最简单，用户明确要求独立复核。

反过来，普通文件修改、能跑测试的常规代码改动、资料整理、一般建议、提示词草拟、本地状态查询，通常不需要冷审。先把能自动检查的部分检查完，再做一次专注的自检，已经足够。

这个开关很重要。冷审稀缺的是审查者还能不能保持陌生视角。什么都审，最后往往什么都只是再读一遍。

一次冷审该怎么跑

主任务先把工作做到可交付状态。不要拿半成品去问审查者哪里不好。半成品的问题太多，审查结果会被表面缺口淹没。

接着准备一份自包含的审查材料。里面至少要有原始要求、验收条件、候选结果、已经跑过的检查和当前仍有疑问的地方。审查者不应继承主任务的完整聊天历史。完整历史会把原来的暗示、偏好和推理路径一起带过去，冷审也就不冷了。

审查任务要写得窄一些。让它核对哪些硬要求，寻找哪些高风险问题，所有发现必须指出具体位置和对应要求。没有实质问题就返回通过。别只问一句整体感觉怎么样，这种问法最容易收到一篇措辞很满、作用很小的评语。

一般只需要一个新审查者。第二个审查者适合两种情况，一处风险需要完全不同的专业视角，或者第一个审查结论与现有证据发生了真正的冲突。为了显得稳妥连续叫来三四个人，常见结果是意见互相覆盖，主任务开始在评语之间来回改。

收到反馈以后，决定权仍在主任务手里。审查意见是一份新证据，最终判断还要回到要求和可核验的结果上。主任务要逐条核对，接受成立的问题，拒绝没有证据的猜测，改完以后重跑相关检查。只有改动触及了关键逻辑，才需要做一次有目标的复审。

一个更省事的工作顺序

我更推荐下面这套顺序。

先跑机器能判断的检查。数量、哈希、文件是否可读、测试结果、字段完整性，都别浪费审查者的注意力。

再做主任务自检。把原始要求逐条过一遍，先修掉自己已经看见的问题。

然后判断风险。没有高风险，也没有悬而未决的关键结论，到这里就可以交付。

确实触发冷审时，交给一个全新上下文的审查者。只给它完成判断所需的材料，要求每条问题都能定位、能对应原要求、能说明把握有多大。

最后由主任务处置反馈并留下简短记录。哪些接受了，哪些拒绝了，理由是什么。这个记录不必每次展示给用户，但在高风险任务里很有用，过后能看清决定是怎样做出的。

整套流程的重点是把确定性检查放前面。冷审不该替你数文件，也不该替你跑一遍本来就有的测试。

生成图片和视频时要格外小心

生成资产很容易把冷审用歪。

假设用户让做一张封面，模型已经返回一张可以打开的图片。审查者觉得构图还能更好，这个意见只能算审美建议，不能自动授权再生成一张。用户要求的数量应当看成硬额度。一份成功返回、非空、可以读取的原图会占掉一个名额。

只有彻底没有产出，接口报错、返回为空、文件损坏到无法打开，才算没有占用名额。比例不够准、字不好看、人物手指有问题、风格偏了，都属于已经产生了作品以后发现的缺陷。它们不会把名额还回来。

这条规则听起来有点硬，却解决了一个很现实的问题。若审查者既能挑问题，又能顺手批准重做，复核会悄悄变成无限迭代。成本、配额和用户原本要求的数量都会失控。

实用的分法是把问题分成三档。

P0 是可以直接验证的交付失败，比如文件打不开、格式错了、明确要求的交付物缺失。P1 是会影响使用的核心歧义，比如主体身份、年代、空间关系可能被看错。P2 是审美和偏好，比如希望更高级、更有张力、更漂亮。

P0 和 P1 都要写清对应的原要求、画面或文件里的具体位置，以及判断把握。P2 可以记录，但不能触发自动重做。能用非生成方式修复的客观问题可以处理，比如补元数据、重算校验值。凡是会重新画图、补画、生成式放大或改变构图的操作，都应等用户明确增加生成名额。

每份已经生成的原始结果也要保留。后续重做应当作为新版本归档，不能悄悄覆盖前一版。冷审有评价权，没有追加生成的授权。

冷审的优点很明确

它能切断同一套错误前提的自我循环。尤其在长任务里，主任务越投入，越容易把已经花掉的时间当成继续相信当前方向的理由。新审查者没有这份沉没成本。

它也能让结论更守边界。实验报告、复杂排查、跨文件改动都容易出现局部证据支撑全局判断的情况。一个好的冷审会追问证据究竟走到了哪一步。

还有一个常被忽略的好处。冷审迫使主任务把验收条件说清楚。很多审查困难，都源于任务从头到尾没有明确什么叫完成。准备审查材料的过程，本身就在补这块缺口。

它的缺点也不能藏

冷审会增加等待时间和模型消耗。任务越长，整理自包含材料的成本越高。

审查者也会看错。它可能把个人偏好写成硬缺陷，可能因为材料缺了一段背景而误判，也可能为了证明自己有用，硬找出几条无关痛痒的问题。新上下文减少了旧偏见，也失去了部分现场信息。

另一个麻烦是审查回旋。主任务按评语改，第二次审查又建议改回去。若没有明确的验收条件和证据优先级，两个模型可以围绕措辞和风格来回争很久。

解决办法很朴素。只在风险够高时开。先做确定性检查。审查问题写窄。所有发现必须落到具体要求和具体位置。主任务保留最后决定权。一般一轮就停，关键逻辑真的变了再复审。

最容易踩的几个坑

第一个坑是把冷审当成质量仪式。任务不分大小，每次都走一遍。这样做看上去严谨，实际会让审查者把时间花在低价值差异上。

第二个坑是把全部聊天记录原样交过去。新审查者读完前面的推理，很可能继续沿用原来的框架。最好给一份重新整理过的事实包，够判断就行。

第三个坑是让审查者直接改文件、执行操作或者重新生成。冷审应以只读检查为主。它可以指出问题，修不修、怎么修、是否需要新的外部操作，由主任务决定。

第四个坑是把审查意见当权威。两名审查者说法一致，也不能替代证据。能复现就复现，能跑测试就跑测试，能定位就定位。

第五个坑是没有停手条件。只要有人说还能优化，就继续开下一轮，最后会把一次复核做成长时间的意见征集。冷审需要明确出口。高风险问题处理完，验收条件满足，就交付。

一套可以直接照着用的判断法

任务完成以后，先问自己几件事。

这次操作能不能轻易撤回。是否碰到权限、资金、合规、健康或数据安全。改动是否跨过多个模块和公共配置。脚本与测试跑完以后，关键结论还有没有拿不准的地方。用户有没有明确要求独立复核。

全部都是否定，就做确定性检查和自检，然后交付。

只要有一项成立，就准备冷审材料。给一个新审查者，限制为只读，要求它对照原始要求检查候选结果。每条发现都要能定位，并说明影响。主任务核验后修正，再跑相关检查。

如果任务涉及生成图片或视频，再加一条硬约束。审查不能增加生成名额，任何创意重做都要等用户授权。

这套规则并不复杂，难处在于克制。该审的时候别省，不该审的时候别给流程加戏。冷审的价值来自陌生视角和风险边界，多叫一个模型重复已知内容没有用。

用得好，它是一道保险。用得太勤，它只是更慢的自检。