很多人把 Codex 接进来第一件事是跑个 demo，觉得顺就铺到全流程，结果 CI 里挂了、批量重构跑一半断流、账单对不上。问题不在模型，在你没先判断它该待在哪个环节。这篇给一套判断顺序：先按任务类型分档，再配超时、并发与降级，最后补日志和评测，让它在合适的位置干活。
很多人把 Codex 接进来的第一件事是跑个 demo，感觉挺顺，就一路铺到全流程。结果 CI 里挂了、批量重构跑到一半断流、月底账单对不上。问题基本不在模型，而在你压根没判断过它该待在哪个环节。
这篇给一套判断顺序：先按任务类型分档，决定哪些活交给它、哪些别交；再定超时、重试、降级；然后管住批量与并发；最后补日志和评测。照着走一遍，比先追新模型有用。
先分档：哪些活交给 Codex，哪些别交
| 判断维度 | 可以放心交 | 先别让它拍板 |
|---|---|---|
| 改动是否可回滚 | 单文件补全、写测试、解释代码、生成样板 | 跨模块重构、数据库迁移、鉴权逻辑改动 |
| 上下文是否干净 | 需求一句话说得清、相关文件能整段喂进去 | 需求散在聊天记录和口头约定里 |
| 失败代价 | 本地分支上错了重来就行 | 直接推主干、直接调生产接口 |
分档不是给模型贴标签，是给你自己的工作流划边界。同一件事，放在本地分支上可以放开跑，放在主干路径上就得加闸门。判断标准其实就一条：出错之后，你几分钟能收拾干净。
- 先看上下文：需求能不能一句话说清，相关文件能不能整段喂给它；命中率高不高，一大半取决于这个
- 再看回滚成本：错了是重跑一次，还是要回滚发布、通知用户
- 最后看有没有人接盘：团队有没有代码评审流程、有没有回滚手段
- 不适用的情况：既没有评审、也没有回滚手段时，别把 Codex 放进主干路径，只放在个人本地环节
接线：把超时、重试和降级先定下来
接线阶段最常见的错误，是用一个超时值打通所有环节。交互式补全要短，等三秒没反应人就走了；批量任务可以长，等几分钟没关系。具体档位别抄别人的，先用站内测速页面量出你自己的延迟基线，再往上加一档余量。
- 量基线到 /tools/speed-test 测你所在通道的实际延迟，记下波动范围，而不是只看平均值
- 分档设超时交互式场景用一个短超时，批量任务用一个长超时，两个值写进配置文件，不要散在代码里
- 分清可重试错误鉴权失败、参数错误重试多少次都一样，先按 /guides/api-401-auth-troubleshoot 的思路把错误类型分开
- 写降级顺序主通道超时换备用源；备用源也不通，就退成「只输出建议、不自动改文件」，别让流程静默卡死
多模型拼接的场景，换源与降级规则要落到配置文件，参照 /guides/multi-model-routing-fallback 的思路，别把判断逻辑写死在业务代码里。写死之后，换一次通道就要改一次代码，迟早出事。
批量与并发：别一把梭
一次改几十个文件这种事，按批次推进、每批留一个人工确认点，通常比开满并发跑到底更省时间——因为你省下的是事后排查的功夫。并发上限不要拍脑袋定，先看你所用通道的限流口径，再留一档余量。
- 长任务做成断点续跑：每完成一个文件就落一次状态，重跑时跳过已完成的，不然一次断流全白干
- 触发限流时的退避与排队怎么设，参照 /guides/429-concurrency-backoff，别用固定间隔硬等
- 先排除低级问题再怀疑模型：参数类型、必填字段缺失这类错误，按 /guides/tool-call-param-errors 的路子过一遍
- 批量任务的产物先落在独立分支或临时目录，不要就地覆盖工作区
日志与评测：让「好不好用」有依据
没有日志和评测，你对 Codex 的判断就只能靠感觉，而感觉在换模型、改提示词之后经常会骗人。日志至少记：请求目标、耗时、是否命中降级、改动文件数、是否被人回退。字段清单可以参照 /guides/api-log-fields-replay。
评测别只看总成功率。把「生成之后被人改掉多少」也算进去，这部分才是真实收益。改得越多，说明它在这一类任务上的位置放错了，该往回收一档。
- 攒一小批固定用例：改 bug、加测试、写文档各几条，覆盖你真实的工作类型
- 每次换模型、换通道、改提示词后重跑同一批用例，思路见 /guides/prompt-version-regression-testing
- 记录每次改动的人工返工比例，比单看通过率更能反映实际成本
- 不确定当前额度与计费口径时，去 /coding-plans 与 /official-api 核对当时的数字，不要凭印象估算
常见问题
Codex 和普通代码补全插件，工作流上有什么区别？
补全类工具贴着编辑器光标走，一次产出一小段，人对结果默认会看；Codex 这类助手更偏向「给一个任务、它自己读多个文件再动手改」，输出是一整批改动。所以它的工程重点不在编辑器配置，而在改动范围控制、批量执行的断点与人工确认点。判断标准很简单：要求它自己找文件、自己改多处，就按助手流程配；只要求补下一行，就当补全用。
接进 CI 靠谱吗？
可以，但要限定成不会写坏东西的角色：比如让它跑代码解释、生成变更摘要、给评审提建议，产出只当评论不阻塞流水线。让它自动改代码并直接推分支，前提是你有评审门禁、有回滚路径，并且改动范围被限制在指定目录。没有这些前提时，CI 里只做只读分析更稳。
怎么知道自己是不是用错了场景？
几个信号：同一类任务反复要人工大改、生成的改动经常跨到无关文件、每次都要你重述一遍背景、出错后你查不出是哪一步断的。出现两条以上，就不是模型不行，是任务和流程没配上，先缩小任务粒度或补上日志再谈换工具。换之前也可以到 /tools/verify 与 /codex-radar 看看当前服务侧的稳定性情况。
