任务顺序执行与并行

最后核对日期

2026-05-30。任务执行、并行能力和 UI 名称可能随版本变化，请以当前 Codex 桌面 App 为准。

Codex 不是只能一问一答。一个项目里可以有顺序任务，也可以开多个对话并行推进。关键是你要知道什么时候排队，什么时候引导当前任务，什么时候并行，什么时候不要让两个任务改同一个文件。

这篇解决什么问题

本章用原教程里的任务执行思路，讲清楚顺序执行、任务引导、并行对话和冲突控制。你会知道如何让 Codex 同时干活，又不把项目改乱。

任务执行模式示例

同一个项目可以创建多个对话，但每个对话的任务状态要分清。一个对话像一条工作线，适合围绕同一个目标连续推进。

顺序任务示例

当前任务正在执行时，新指令可能会排队等待。如果新要求会影响当前正在做的事，要用引导或补充说明，而不是等它做完再推翻。

并行任务示例

需要同时推进不同方向时，可以开新对话并行处理。并行前先划清文件边界，避免两个任务同时改同一个文件。

适合谁

已经完成第一个任务，想提高 Codex 使用效率的人。
想让 Codex 同时整理文档、修页面、查问题的人。
害怕多个任务互相覆盖文件的人。

前置条件

已经会创建 Project 和工作目录。
项目最好使用 Git 管理，方便查看 diff 和回滚。
每个任务都能说清楚范围和不能碰的文件。

操作步骤

单个任务还没跑完时，先判断新需求是否必须马上影响当前任务。
如果只是补充要求，可以在当前对话里追加说明或引导。
如果是完全不同的任务，开一个新对话并行处理。
并行任务要明确文件边界，比如一个只改 docs，一个只改 styles。
结束后统一看改动文件、运行验证、再决定是否合并。

顺序执行是什么

顺序执行适合一条任务线上的连续工作。比如你让 Codex 先做一个网站首页，再让它解释技术选型，再让它把风格改成手绘风，这三个要求如果都在同一个对话里，通常会按先后顺序处理。

问题在于：有些补充要求应该尽早影响当前任务，而不是等任务完成后再返工。例如 Codex 正在设计页面，你突然想到“背景要手绘风格”。这时如果只是追加一条普通命令，它可能排在后面；更合适的是把它作为当前任务的补充要求，引导 Codex 立即纳入正在进行的设计。

什么时候要引导当前任务

适合引导的情况：

新要求会影响当前正在生成的结果。
你发现 Codex 理解错了方向，需要及时纠偏。
当前任务还没结束，继续跑下去会浪费时间。
你只是在补充约束，不是开启一个全新的任务。

不适合引导的情况：

你想做另一个独立功能。
你想让 Codex 同时查资料、写文档、修代码。
新需求会改到另一批文件。

这些更适合新建对话并行处理。

适合顺序执行的任务

同一个文件内的连续修改。
需要先理解需求再实现的功能。
需要先跑检查，再根据结果修复的问题。
高风险操作，例如部署、迁移、删除、重命名大量文件。
需要先确认方案、再按方案实现的任务。
需要逐步看 diff、逐步批准命令的任务。

适合并行的任务

一个任务写文档，另一个任务查资料。
一个任务修前端样式，另一个任务补 README。
一个任务探索问题原因，另一个任务整理测试用例。
多个互不重叠目录的小改动。
一个对话做实现，另一个对话只做资料整理或测试方案。
一个对话分析失败日志，另一个对话补充文档说明。

并行任务怎么避免冲突

并行前给每个对话写清楚边界：

本对话只负责 docs/ 目录下的教程文案。
不要修改 src/、package.json、配置文件和图片资源。
完成后列出修改文件和验证方式。

另一个对话可以写：

本对话只负责 src/styles/ 下的样式问题。
不要修改 docs/、README、图片资源和依赖配置。
完成后列出修改文件和可视化检查方式。

如果项目有 Git，建议每个并行任务开始前先看状态，结束后再统一看 diff。没有 Git 的目录不建议开太多并行任务，因为你很难判断谁覆盖了谁。

常见坑

两个对话同时改同一个文件，后完成的覆盖先完成的。
没有告诉 Codex 当前对话负责哪部分。
并行太多，自己没时间 review。
让 Codex 边修边发布，没有人工确认。
没给每个对话划文件边界，结果多个对话互相覆盖。
并行任务都成功了，但最后没人统一验收整体效果。

Redman 实测建议

并行不是越多越好。Redman 自己更常用“三段式”：一个主任务做实现，一个旁路任务查资料，一个验证任务跑检查。超过这个数量，新手很容易顾不过来。