代码 审查 报错怎么解决

你把 Codex 挂进代码审查流程，结果报错五花八门：读不到文件、审到一半停住、输出格式对不上、批量跑几十个 PR 就整体崩。这篇不解释原理，只给排查顺序：从确认任务边界开始，逐层往下定位是上下文、限流、格式还是单文件太大，最后给出改成稳定流水线的做法。

你把 Codex 挂进代码审查流程，结果报错五花八门：读不到文件、审到一半停住、输出格式对不上、批量跑几十个 PR 就整体崩。这篇不解释原理，只给排查顺序，从确认任务边界开始，逐层往下定位是上下文、限流、格式还是单文件太大，最后给出改成稳定流水线的做法。

先记住一个判断：审查报错分两大类——任务根本没跑起来，或者跑完了但结果不能用。这两类的排查入口完全不同，混着查只会浪费时间。下面按阶段拆开讲，每节都给判断标准和动作，你可以照着顺序往下走。

先分清是哪一类失败：任务没跑起来，还是跑完结果不对

报错出现时别急着改提示词，先把失败按阶段切开。发起请求就失败、跑到一半中断、跑完输出为空或格式错，这三类的成因和排查路径完全不一样。切错阶段，后面的动作全是白费。

• 先确认这次审查的范围是不是太大——一次塞进整个仓库通常不是模型不行，是任务本身没切干净
• 用一个最小可控样本复现，而不是拿真实的大 PR 反复试，样本越小越容易定位
• 把每次失败的原始报错原文留下来，转述过的错误信息会丢掉关键线索
• 当报错来自版本控制或 CI 平台本身时，要先看平台日志，不要先怀疑模型

读不到文件、改了没生效：上下文类报错的排查顺序

这类报错最容易被误判成模型理解能力问题，其实多半是它根本没看到你以为它看到的那些文件。判断标准很简单：让它复述一下这次审查涉及哪些文件，复述出来的清单和你预期的不一致，问题就在这一层。

1. 第一步：确认路径可见性查审查工具实际能读到的目录范围，确认目标文件没被忽略规则挡掉、没有被权限拦住、不在排除清单里。
2. 第二步：确认内容新鲜度如果改了代码但审查结果没变，八成读到的是缓存副本，清掉缓存再跑一次，对比结果是否变化。
3. 第三步：确认分片粒度文件太多时按改动集中的目录分片审查，分片跑通后再合并结论，不要一上来就整仓投喂。
4. 第四步：回头验证用同一个小样本重跑，确认修改后报错消失或变成了另一种，没变化说明改的地方不对。

这三层是有先后顺序的：路径可见性不通过，就别去调内容新鲜度；内容不新鲜，调分片粒度也没意义。一层一层过，能省掉大量无效试错。全站工具与环境相关的说明可以去 /tools/speed-test 看当时的检测项，对照你的实际环境。

跑一半断了：限流、超时与并发相关的表现与处理

这两个问题经常被混在一起，但表现不同。限流通常有明确的状态码或提示，告诉你请求太密了；超时往往是任务卡住之后没有任何响应，日志停在某一步不动。先看报错形态，再决定动哪个参数。

限流

有明确的状态码或限流提示，处理方向是降频、排队、错峰

超时

任务无响应、日志停住，处理方向是先看单次负载大小，再考虑加超时

可重入

失败时能单独重跑出问题的那一个文件，而不是整批从头来

• 批量审查多个改动时，先降并发再考虑加超时，顺序反了只是把失败往后推
• 给每个审查单元编号并记录状态，失败时能精确定位到是哪一个文件、哪一个改动
• 单次审查就超时，先看是不是单个文件过大或依赖太多，别急着改并发参数
• 限流提示出现后，加一层退避重试比直接调大并发更稳

结果不可用：输出格式、截断与结论空洞怎么修

任务跑通了但结果用不了，这类问题最容易被当成模型质量问题，其实大多是对齐问题。判断标准是：先固定输出契约，再调提示；反过来做，你会一直在猜它为什么换格式。

加一层结果校验很关键：解析失败不要让坏结果直接进评论，先拦住。重试仍失败就降级成纯文本建议，人工再扫一眼，总比把格式错的内容推给同事强。想了解各家工具在结构化输出上的实际表现，可以去 /rankings 看当时的评测数据。

从能跑到稳定：把审查做成可复盘的流水线

单次跑通不算数，能在别人手里、在别的改动上稳定跑通才算。稳定的前提是条件一致——每次运行的审查范围、输入格式、输出契约、重试次数都固定下来，出问题时才有对照。

1. 固化运行条件把审查范围、输入格式、输出契约、重试次数写进配置，让每次运行的条件一致。
2. 保留可追溯记录每次审查保留输入摘要与报错信息，出问题时能对上是哪一步变了。
3. 小批历史改动先跑通先在一小批历史改动上验证，确认稳定后再接到日常流程里。
4. 留人工兜底口审查结论先进草稿或评论待确认，别直接作为最终意见发出。

顺序不能反：先拿真实提交当试验品，出了问题连是哪一步变的都说不清。什么情况下不适用——改动量很小、人工看一眼就够的时候，不值得为它专门搭流水线，直接人工看更省事。