Codex 多任务同时开发操作指南

1. 文档目标

这份文档专门解决一个问题：如何让 Codex 在真实项目中同时推进多个开发任务，而不是一次只做一件事。

读完后，你应该能够：

• 判断什么任务适合并行开发
• 设计一套安全的多任务拆分方式
• 让 Codex 同时处理多个子任务而不互相打架
• 在并行开发后完成合并、验证和收口
• 把这套方式用于 Java / Spring Boot 项目、前后端联动需求和团队协作场景

2. 什么是"多任务同时开发"

多任务同时开发，不是让 Codex "一口气做很多事"，而是：

• 先把一个较大的目标拆成多个彼此相对独立的子任务
• 再让这些子任务并行推进
• 最后再统一整合、验证和交付

它更像项目经理和开发负责人在做的事情：

• 主任务负责目标定义和总控
• 子任务负责模块级实现
• 最终统一检查整体是否可用

3. 多任务开发适合哪些场景

下面几类场景，最适合用 Codex 做并行推进。

3.1 一个需求涉及多个独立模块

例如：

• 用户模块要加字段
• 订单模块要联动展示
• 报表模块要同步统计

这类任务适合拆成多个模块子任务并行处理。

3.2 一个需求包含多种不同类型工作

例如：

• 一部分是后端接口改造
• 一部分是前端页面调整
• 一部分是文档和测试补充

这类任务天然可以分轨推进。

3.3 一个问题需要"分析"和"实施"同时进行

例如：

• 一边让 Codex 梳理调用链
• 一边让 Codex 起草修复方案
• 另一边让 Codex 准备验证清单

这种方式特别适合时间紧、影响面大的问题处理。

3.4 一个大需求可以按文件或目录边界拆开

例如：

• controller 一组任务
• service 一组任务
• mapper/xml 一组任务
• test/docs 一组任务

这时最容易做安全并行，因为写入范围相对清晰。

4. 什么场景不适合并行

不是所有任务都适合多任务同时开发。下面这些情况更适合串行推进：

• 需求本身还没想清楚
• 关键设计方案尚未确定
• 多个任务会同时改同一个文件
• 任务之间强依赖，上一步不完成，下一步无法判断
• 涉及数据库迁移、权限核心逻辑、支付等高风险改动

一句话判断：如果拆开后彼此仍然高度耦合，就不要强行并行。

5. 多任务同时开发的核心原则

真正稳定的多任务开发，不是"开更多任务"，而是遵守几个关键原则。

5.1 先总后分

先让 Codex 理解总任务，再决定如何拆分，不能一上来就把任务扔给多个分支。

5.2 一任务一目标

每个子任务只负责一个明确目标，不要让它既改代码、又补测试、又写文档、又顺手重构。

5.3 明确边界

给每个子任务指定：

• 负责模块
• 允许修改的文件范围
• 不允许碰的区域
• 输出要求

5.4 可合并

拆分出来的子任务，最终必须能重新合并成一个完整结果。

5.5 可验证

并行推进后，必须统一验证，不然很容易出现"每个局部都看起来对，整体却跑不通"的问题。

6. 标准操作流程

下面是一套推荐的 Codex 多任务同时开发流程。

1. 明确总目标
2. 理解项目与影响范围
3. 拆分独立子任务
4. 为每个子任务定义边界
5. 并行推进分析/修改/测试准备
6. 汇总结果与冲突检查
7. 统一联调与验证
8. 提交、沉淀、复盘

6.1 第一步：明确总目标

先用一句话说清楚最终要完成什么。

示例：

目标：完成"会员资料扩展字段"需求，要求后端接口、数据库查询、列表展示、日志和测试说明都同步更新。

6.2 第二步：让 Codex 理解整体上下文

先不要急着并行，先让 Codex 读懂：

• 项目结构
• 核心模块
• 涉及的调用链
• 可能影响的文件

示例提示词：

请先帮我理解这个需求涉及哪些模块。
目标：会员资料扩展字段
请阅读相关 Controller、Service、Mapper、VO、DO、前端页面和 SQL，
输出：
1. 影响范围
2. 需要修改的模块
3. 适合拆成哪些独立任务
4. 风险点

6.3 第三步：拆分独立子任务

一个好的拆分，通常有下面几种维度：

• 按模块拆
• 按目录拆
• 按职责拆
• 按阶段拆

典型拆分示例：

1. 后端接口层改造
2. Service 业务逻辑改造
3. Mapper / XML / SQL 改造
4. 前端展示改造
5. 测试与验证清单整理
6. 文档和规范补充

6.4 第四步：给每个子任务定义边界

每个子任务都应该具备一份最小任务说明。

模板如下：

子任务名称：

目标：

负责范围：

允许修改的文件：

不要修改的内容：

输出要求：
1. 先分析
2. 再改动
3. 最后给验证建议

6.5 第五步：并行推进

这一步是多任务开发的核心。并行不只是"同时改"，更包括：

• 一个任务负责查代码
• 一个任务负责做实现
• 一个任务负责准备测试
• 一个任务负责写说明文档

你可以理解成一个总控流，下面挂多个子任务流。
总任务：会员资料扩展字段
子任务A：接口与VO
子任务B：Service逻辑
子任务C：Mapper/XML/SQL
子任务D：前端列表展示
子任务E：测试与文档

6.6 第六步：汇总与冲突检查

并行任务结束后，不要立刻提交，要先做统一检查：

• 是否改了同一个文件
• 是否字段命名不一致
• 是否接口出参与页面展示不一致
• 是否 SQL 已支持但 Service 没接入
• 是否后端改了但测试说明没更新

6.7 第七步：统一验证

统一验证通常包括：

• 编译通过
• 单元测试或关键接口测试通过
• 日志输出合理
• 前后端联调正常
• 关键边界场景可覆盖

6.8 第八步：提交与沉淀

最后做三件事：

1. 按模块或按目标整理提交
2. 记录多任务拆分方式是否合理
3. 把可复用的提示词和规则写进文档或 AGENTS.md

7. 推荐的任务拆分模型

下面是几种在真实项目中很好用的拆分模型。

7.1 模型一：按技术层拆

适合典型 Spring Boot 分层架构：

• Controller
• Service
• Mapper
• Mapper XML
• VO / DTO / DO
• Test / Docs

适用场景：

• 后端单体项目
• 分层清晰
• 需求主要在服务端

7.2 模型二：按业务子域拆

例如一个商城需求，可以拆成：

• 会员域
• 订单域
• 营销域
• 报表域

适用场景：

• 大型业务系统
• 模块之间相对独立

7.3 模型三：按阶段拆

适合高风险需求：

1. 分析影响范围
2. 产出实施方案
3. 改代码
4. 补测试
5. 补文档

适用场景：

• 你希望先确认方向再执行
• 团队 review 要求较高

7.4 模型四：按角色拆

适合培训或多人协作演示：

• 一个任务负责"代码理解"
• 一个任务负责"业务实现"
• 一个任务负责"测试验证"
• 一个任务负责"文档沉淀"

这种方式很适合给团队演示"Codex 不只是写代码"。

8. Java / Spring Boot 项目实战实例

下面用一个典型后端需求，演示如何让 Codex 多任务同时开发。

需求背景

要给"会员资料管理"增加一个 customerLevel 字段，并完成以下工作：

• 后端接口支持查询和保存
• 数据库查询支持筛选
• 列表页展示该字段
• 日志和异常提示更清晰
• 输出联调和测试说明

8.1 第一步：总任务分析

可以先这样问：

这是一个 Java / Spring Boot 项目。
请先不要改代码，先帮我分析"会员资料增加 customerLevel 字段"这个需求的影响范围。

请重点查看：
1. Controller
2. Service
3. Mapper 和 Mapper XML
4. 请求/响应对象
5. 前端列表和表单

输出：
1. 涉及模块
2. 需要修改的文件
3. 可以如何拆成并行子任务
4. 风险点和验证点

8.2 第二步：拆出 5 个并行子任务

推荐拆法：

1. 子任务 A：接口入参与返回对象调整
2. 子任务 B：Service 业务逻辑调整
3. 子任务 C：Mapper / XML / SQL 调整
4. 子任务 D：前端列表和表单展示调整
5. 子任务 E：测试清单、联调清单和文档说明

8.3 第三步：给每个子任务独立指令

子任务 A：接口与对象层

请负责"接口与对象层"修改。

目标：
为会员资料增加 customerLevel 字段。

负责范围：
Controller、ReqVO、RespVO、SaveVO。

约束：
1. 不修改 Service 和 Mapper 实现
2. 字段命名统一使用 customerLevel
3. 保持现有接口结构稳定

输出要求：
1. 先列出准备改哪些文件
2. 再实施最小改动
3. 最后说明对联调的影响

子任务 B：Service 层

请负责"Service 业务逻辑层"修改。

目标：
让 customerLevel 在保存、更新、分页查询时正确流转。

负责范围：
Service 接口和实现类。

约束：
1. 不改 Controller 层接口定义
2. 不直接修改前端代码
3. 不做无关重构

子任务 C：Mapper / XML / SQL

请负责"Mapper / XML / SQL"调整。

目标：
让 customerLevel 支持持久化和查询筛选。

负责范围：
Mapper.java、Mapper.xml、相关 SQL 条件。

约束：
1. 保持现有分页逻辑不变
2. 检查动态条件是否完整
3. 说明是否存在索引或性能影响

子任务 D：前端展示

请负责"前端列表和表单展示"修改。

目标：
在会员列表和编辑表单中展示 customerLevel。

负责范围：
列表列定义、搜索条件、编辑表单、详情展示。

约束：
1. 不改后端接口路径
2. 不引入新的页面交互复杂度
3. 保持现有 UI 风格

子任务 E：测试与文档

请负责"测试与文档"输出。

目标：
基于 customerLevel 改动，生成联调和测试清单。

输出要求：
1. 正常场景
2. 异常场景
3. 参数边界场景
4. 前后端联调要点
5. 上线前检查清单

8.4 第四步：统一收口

所有并行任务完成后，再让 Codex 做一次总检查：

请基于刚才的多个子任务结果，做一次统一收口检查。

请输出：
1. 是否存在文件冲突
2. 是否存在字段命名不一致
3. 是否存在前后端接口不一致
4. 是否存在 SQL 已支持但业务未接入
5. 最终验证步骤

8.5 第五步：统一验证

最终验证建议包含：

• 保存接口正常
• 更新接口正常
• 分页筛选正常
• 列表字段展示正常
• 搜索条件可用
• 异常提示清晰
• 日志中可以定位关键流程

9. Bug 修复场景实战实例

多任务开发不只适合新需求，也很适合复杂 Bug 修复。

场景

某个订单提交流程偶发失败，表现如下：

• 有时库存扣减成功，但订单保存失败
• 有时报空指针
• 有时前端只看到"系统异常"

推荐并行拆法

1. 子任务 A：分析调用链和事务边界
2. 子任务 B：分析日志和报错堆栈
3. 子任务 C：检查数据库落库与 Mapper SQL
4. 子任务 D：整理测试复现步骤
5. 子任务 E：起草修复后的验证方案

图示流程

订单提交异常
A: 调用链与事务分析
B: 日志与异常堆栈分析
C: SQL与落库检查
D: 复现路径整理
E: 修复后验证方案
统一收口判断根因
输出修复方案并实施

这类拆法的优势

• 既能查代码，也能查日志
• 不会把全部时间耗在单一路径上
• 更容易快速收敛到真正根因

10. 多任务开发中的风险与防冲突方法

并行开发最怕的不是"任务多"，而是"边界不清"。

10.1 常见风险

• 多个任务修改同一个文件
• 字段命名不统一
• 一个任务按旧接口开发，另一个任务已经改了接口
• 一个任务顺手重构，影响了其他任务判断
• 局部正确，但整体流程没打通

10.2 防冲突建议

• 先定义每个子任务负责的文件范围
• 尽量按目录或职责拆分
• 每个子任务都写清"不允许改什么"
• 高风险文件只允许一个任务负责
• 并行结束后必须做统一汇总检查

10.3 一个简单的边界表模板

子任务	负责内容	允许修改	禁止修改
A	Controller / VO	接口对象、返回对象	Service / Mapper
B	Service	业务流转	Controller / 前端
C	Mapper / XML	SQL、查询条件	页面展示
D	Frontend	列表、表单、搜索	后端逻辑
E	Test / Docs	测试说明、联调文档	业务代码

11. 高质量提示词模板

11.1 总任务模板

请帮我处理一个需要并行推进的开发任务。

总目标：
[一句话说清楚最终目标]

上下文：
[项目背景、模块范围、关键文件、现状]

要求：
1. 先分析影响范围
2. 再拆分成适合并行推进的子任务
3. 为每个子任务定义边界、目标和风险
4. 最后给出统一收口和验证方案

11.2 子任务模板

你现在只负责一个子任务，请不要扩散修改范围。

子任务名称：

目标：

负责范围：

允许修改的文件：

不要修改的内容：

输出要求：
1. 先分析
2. 再执行最小改动
3. 最后输出影响范围和验证建议

11.3 收口检查模板

请基于多个子任务的结果，做统一收口检查。

检查项：
1. 文件修改是否冲突
2. 字段命名是否一致
3. 接口和前端是否一致
4. SQL、Service、Controller 是否全部打通
5. 最终验证步骤是否完整

12. 团队落地建议

如果你要把这套方式推广到团队里，建议按下面步骤落地：

1. 先选一个中等复杂度需求做试点
2. 固化一套"总任务分析模板 + 子任务模板"
3. 在 AGENTS.md 中写入多任务协作规则
4. 要求每次并行前先明确边界和禁止修改项
5. 要求并行结束后统一做收口检查

13. 一句话总结

Codex 多任务同时开发的本质，不是让 AI 一次做更多事，而是让复杂需求被拆成多个独立、可控、可合并、可验证的子任务，并行推进后再统一收口。

14. 快速上手清单

• 先明确总目标
• 先理解项目和影响范围
• 再拆出彼此独立的子任务
• 每个子任务都写清边界
• 并行推进时避免改同一文件
• 完成后统一做冲突检查
• 最后再编译、联调、验证、提交