Codex 任务太大做不完怎么办？

很多人第一次用 Codex 处理真实项目时，会把“读懂项目、定位问题、修代码、补测试、上线验证”写成一条指令。结果不是做不完，就是改动范围变大，最后人工反而更难 Review。

适用场景：任务目标真实，但范围过大

这篇适合接手旧项目、修跨页面问题、改后台流程、补 AI 自动化办公脚本、整理接口调用日志和上线前自检。典型表现是 Codex 需要读很多文件，却不确定哪些能改；用户只说“帮我优化一下”，但没有验收标准；任务中途发现数据库、远程服务和前端页面都相关。如果只是第一次让 Codex 改项目，可先看 第一次让 Codex 改项目之前要检查什么；大仓库边界可结合 大项目里怎么让 Codex 只改该改的文件。

先判断任务类型：探索、修复、生成还是上线

不要让一个会话同时承担所有角色。探索任务只读文件并输出结论；修复任务只改指定模块并跑测试；生成任务要明确产物格式；上线任务要列出同步、回滚和验证命令。把这些阶段分开，Codex 才能知道当前应该收集证据、写代码，还是做发布检查。

操作步骤：把大任务拆成四段

1. 先写问题边界

用一句话说明真实问题，例如“订单列表筛选后分页错乱”，不要写成“优化订单系统”。再补充影响范围、复现入口、已知报错和不能触碰的目录。涉及远程命令时，先按只读、本地写入、远程变更分级，命令风险可参考 让 Codex 执行命令前怎么确认风险。

2. 第一轮只做只读调查

让 Codex 列出相关文件、数据流、可疑点、缺少的信息和建议验收方式。此时不要让它直接改代码。只读调查能暴露任务是否真的可在当前仓库完成，也能发现是否需要 AI API 接入配置、CCSwitch profile 或外部服务日志。

3. 第二轮只修最小闭环

确认方向后，只允许修改能完成最小闭环的文件。比如修一个表单提交错误，就不要顺手重构整个表单库；补一个模型调用管理字段，就不要同时改所有报表样式。让 Codex 每完成一个阶段都说明改了什么、为什么改、如何验证。

4. 最后写交接说明

交接说明要包含变更范围、验证命令、未覆盖风险、回滚方法和人工复核点。交给同事 Review 时，不要只发一句“已修复”。可以参考 Codex 改完代码后怎么交给同事 Review 的结构。

常见问题/避坑：大任务失败通常不是模型不够聪明

第一个坑是目标太宽，Codex 无法判断优先级。第二个坑是允许修改范围不清，导致它把参考文件也改了。第三个坑是没有验收命令，只靠肉眼看 diff。第四个坑是中途把新需求塞进去，原始问题还没闭环就扩散成另一个项目。

如果任务涉及开发者 AI 调用或 AI 模型接口，边界还要包括接口地址、Key 权限、模型名、日志字段和成本影响。API 错误码排查可参考 AI API 返回 401、429、500 怎么分工排查。不要让 Codex 猜生产 Key，也不要把本地测试 profile 误当成正式配置。

我会要求每个大任务至少有一个“停止条件”。例如只读调查发现缺少生产日志，就先停下来要日志；测试环境无法启动，就先修启动问题或改为静态检查；远程同步需要人工确认，就不继续执行上线。停止条件不是拖延，而是避免在证据不足时继续扩大修改。

任务拆分还有一个好处：失败更容易复盘。如果探索阶段判断错了，损失只是时间；如果直接进入全量修改，后面要从一堆改动里倒查原因。对于 AI 自动化办公流程、支付回调、搜索引擎推送这类链路，分段验收比一次性上线更可靠。

实际使用时，可以把提示词写成“先只读调查，列出计划，等我确认后再改”。自动化日更这类已经有固定规范的任务可以直接执行，但普通开发任务最好保留这个确认点。这样 Codex 的能力被用在阅读和执行上，关键边界仍由项目负责人把关。

检查清单：交给 Codex 前先看一遍

• 是否把真实问题写成一句可复现的描述。
• 是否列出允许修改目录、只读目录和禁止触碰区域。
• 是否先安排只读调查，再进入代码修改。
• 是否为每个阶段准备验收命令或人工检查动作。
• 是否明确远程命令、数据库操作和生产配置的权限边界。
• 是否要求 Codex 输出交接说明和剩余风险。

验收标准：每一段都能独立解释

合格的 Codex 大任务拆分，应能让每个阶段都有输入、输出和检查方式。永沃云枢建议把任务拆分模板和 Codex 安装专题、AI API 接入专题 一起维护，后续在 https://ai.jn83.com 做 Codex 接入、模型调用管理或 AI 自动化办公时，能保持边界清楚、验收明确。