Codex 小步迭代 + Git Commit + 多任务并行组合版

1. 文档目标

这份文档解决的是复杂任务在真实项目中的推进问题：

• 只会小步迭代，速度可能不够快
• 只会多任务并行，风险可能很高
• 只会 commit 留快照，但不会控制粒度，也难以真正降低复杂度

读完后，你应该能够：

• 理解三种能力各自解决什么问题
• 知道什么时候先小步、什么时候再并行
• 知道并行过程中如何用 commit 控制风险
• 设计一套既能推进速度、又能保住稳定性的执行流程
• 用这套方法处理多模块功能开发、复杂 bug 修复、重构和联调场景

2. 三种能力各自解决什么问题

2.1 小步迭代

解决的问题：

• 单轮改动过大
• 难以快速验证
• 一步到位容易失控

核心价值：

• 让每一步更小、更稳、更容易判断方向

2.2 Git commit

解决的问题：

• 中间状态没有锚点
• 出问题难以回退
• review 难以聚焦

核心价值：

• 让每轮稳定结果都可保留、可回退、可对比

2.3 多任务并行

解决的问题：

• 所有事情都串行，整体太慢
• 大任务无法充分拆开利用独立模块边界

核心价值：

• 把独立任务同时推进，提升整体交付效率

3. 为什么要把三者组合起来

只用其中一项，通常都不够。

只用小步迭代的问题

• 稳是稳了，但可能整体推进偏慢

只用 Git commit 的问题

• 虽然能回退，但如果每轮都很大，风险仍然高

只用并行的问题

• 如果没有小步和快照，并行任务更容易互相打架

组合之后

• 小步迭代负责控制单轮风险
• Git commit 负责保留阶段状态
• 多任务并行负责提升整体效率

4. 这套高级打法的核心思想

可以把它理解成一句话：

单任务内部用小步迭代，关键节点用 commit 锁定稳定点，多个独立子任务再按边界并行推进。

这套方法的本质不是“同时做更多事”，而是“用更有节奏的方式做复杂事”。

5. 推荐的三层节奏

这套方法非常适合按三层节奏理解。

第一层：总目标层

先定义总目标和总体范围。

第二层：子任务层

把总目标拆成多个边界清晰、彼此尽量独立的子任务。

第三层：迭代轮次层

每个子任务内部再按小步迭代推进，并在关键轮次做 commit。

图示

6. 什么场景最适合这套高级组合版

下面这些场景特别适合。

6.1 多模块功能开发

例如：

• 后端新增字段
• SQL 支持筛选
• 前端展示联动
• 测试与文档补充

6.2 高风险复杂 Bug 修复

例如：

• 事务问题
• SQL 查询问题
• 权限问题
• 偶发联调失败

6.3 大型重构或优化任务

例如：

• 拆 Service
• 抽公共组件
• 梳理旧逻辑

6.4 团队协作交付

因为：

• 任务边界更清晰
• review 粒度更合理
• 回退和定位更容易

7. 什么场景不适合强行上三件套

下面这些情况不建议一上来就用完整高级组合版：

• 非常简单的一次性小修改
• 需求还完全没想清楚
• 多个任务强依赖且共享同一批关键文件
• 团队还没有基本的 commit 习惯

一句话：高级打法适合复杂任务，不适合把简单问题人为复杂化。

8. 标准操作流程

9. 第一步：先定义总目标，不要一开始就并行

并行不是起点，目标清晰才是起点。

示例

目标：给会员资料管理增加 customerLevel 字段，完成后端、查询、前端展示和测试说明联动。

这一步要输出什么

• 总目标
• 涉及模块
• 主要风险
• 是否适合并行

10. 第二步：先拆成独立子任务

高级组合版里，第一层拆分通常按模块或职责来做。

推荐拆法

1. 子任务 A：接口对象与 Controller
2. 子任务 B：Service 业务逻辑
3. 子任务 C：Mapper / XML / SQL
4. 子任务 D：前端展示
5. 子任务 E：测试与文档

原则

• 尽量避免多个子任务同时改同一文件
• 高风险文件尽量只归一个子任务负责

11. 第三步：每个子任务内部再拆迭代轮次

这一步是高级组合版和普通并行方式最大的区别。

不是“每个子任务一口气做完”，而是“每个子任务内部也要小步推进”。

例如

子任务 B：Service 业务逻辑，可以拆成：

1. 第一轮：保存链路支持字段
2. 第二轮：查询链路支持字段
3. 第三轮：异常与日志补充

好处

• 并行任务本身也可控
• 即使某个子任务内部出问题，也不会拖垮整个任务

12. 第四步：子任务可以并行，但每轮都要验证

并行推进不等于盲目同时改很多东西。

更好的方式是：

• 不同子任务同时推进
• 每个子任务内部依然保持“小轮次 -> 验证 -> 下一轮”

示例节奏

• 子任务 A 完成第一轮后先验证，再进入第二轮
• 子任务 C 完成第一轮后先验证，再决定是否进入第二轮
• 子任务 E 可以和前面几个任务并行准备联调清单

13. 第五步：关键轮次要 commit，不要等到最后一起提交

这是高级组合版最重要的保命点。

推荐提交时机

• 某个子任务第一轮主链路打通后
• 某个子任务一个明显阶段完成后
• 从“实现阶段”切到“测试补充阶段”前
• 在准备合并多个子任务结果前

推荐 commit 粒度

• 一个 commit 对应一个子任务的一轮稳定结果

例如

feat: 打通 customerLevel 后端对象与接口链路 feat: 支持 customerLevel Service 保存与查询逻辑 feat: 增加 customerLevel SQL 筛选条件 feat: 增加 customerLevel 前端展示 test: 补充 customerLevel 联调与回归清单

14. 第六步：统一做冲突检查与结果汇总

并行推进后，必须做总检查。

检查项

• 是否有多个子任务改了同一文件
• 字段命名是否一致
• 接口与前端展示是否一致
• SQL 支持后，Service 是否已经接入
• 测试与文档是否跟上最终实现

15. 第七步：最终统一联调、回归和收口

所有子任务都完成后，不意味着工作结束，还要做最后一轮整体验证。

最终收口建议

• 编译和运行检查
• 关键接口联调
• 核心路径验证
• 回归影响点检查
• commit 粒度和提交说明检查

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

场景

会员资料管理新增customerLevel字段，要求：

• 后端新增和编辑支持
• 分页查询支持筛选
• 列表和表单展示
• 联调和测试说明同步补充

第一步：拆成 5 个子任务

1. A：ReqVO / RespVO / Controller
2. B：Service 层逻辑
3. C：Mapper / XML / SQL
4. D：前端列表和表单
5. E：测试与联调文档

第二步：每个子任务内部再拆小步轮次

子任务 A

1. 第一轮：增加对象字段
2. 第二轮：打通接口入参与返回

子任务 B

1. 第一轮：保存逻辑支持字段
2. 第二轮：查询返回支持字段

子任务 C

1. 第一轮：持久化字段支持
2. 第二轮：筛选条件支持

子任务 D

1. 第一轮：列表展示
2. 第二轮：表单支持

子任务 E

1. 第一轮：接口联调清单
2. 第二轮：回归测试建议

第三步：关键轮次 commit

示例：

feat: 增加 customerLevel 接口对象字段 feat: 打通 customerLevel Service 保存链路 feat: 支持 customerLevel SQL 持久化 feat: 增加 customerLevel 列表展示 test: 补充 customerLevel 联调清单

第四步：统一收口

最后检查：

• 字段命名是否全部统一为customerLevel
• 前后端是否一致
• 筛选、保存、编辑、展示是否全部打通
• 联调和回归清单是否与最终实现一致

图示流程

17. 复杂 Bug 修复实战实例

场景

订单提交流程偶发失败，现象包括：

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

推荐高级组合做法

子任务拆分

1. A：调用链与事务边界分析
2. B：日志和异常堆栈分析
3. C：SQL 与数据落库检查
4. D：测试复现路径整理
5. E：修复后回归建议

每个子任务内部依然做小步

例如 A：

1. 第一轮：梳理调用链
2. 第二轮：识别事务边界

例如 B：

1. 第一轮：归类异常日志
2. 第二轮：判断最可能根因

关键点 commit

如果修复方案已经验证可用，可以单独形成：

fix: 修复订单提交事务边界导致的部分成功问题 test: 补充订单提交异常场景回归验证

这样做的价值

• 分析和修复不混在一起
• 修复和回归建议不混在一起
• 局部问题不会拖垮整体节奏

18. 这套高级打法的常见误区

18.1 误区一：一开始就并行，没有先做总分析

问题：

• 方向不清时并行只会放大混乱

18.2 误区二：子任务并行了，但内部没有小步迭代

问题：

• 每个子任务仍然是大改，风险没有真正下降

18.3 误区三：并行了很多任务，但没有 commit 锚点

问题：

• 一旦出问题，还是很难回退

18.4 误区四：commit 粒度过粗

问题：

• 虽然有快照，但不能精确定位和回退

18.5 误区五：收口检查不足

问题：

• 局部都对，整体没打通

19. 注意事项

• 并行之前先确认任务边界
• 子任务内部依然保持小步推进
• 每轮稳定结果尽量形成快照
• 不要让多个子任务随意改同一关键文件
• 高风险模块优先串行，不要强行并行
• 最终必须统一做冲突检查和回归验证

20. 高质量提示词模板

20.1 总任务模板

请帮我按“子任务并行 + 子任务内部小步迭代 + 关键轮次留快照”的方式设计执行方案。 总目标： 上下文： 输出要求： 1. 是否适合并行 2. 推荐拆成哪些子任务 3. 每个子任务内部建议几轮迭代 4. 哪些轮次建议形成独立 commit 5. 最终收口和验证建议

20.2 功能开发模板

这是一个多模块功能开发任务，请按高级组合方式帮我设计执行路径。 要求： 1. 先按模块拆任务 2. 每个模块内部再拆小步轮次 3. 指出适合 commit 的阶段点 4. 指出哪些任务可并行、哪些任务应串行

20.3 Bug 修复模板

这是一个复杂 bug，请按“分析并行 + 修复小步 + 关键轮次 commit”的方式帮我设计执行方案。 要求： 1. 先拆分析子任务 2. 明确修复轮次 3. 给出回归轮次 4. 指出哪些结果适合独立提交

21. 团队落地建议

如果你想把这套高级打法推广到团队里，建议这样做：

1. 先在一个中等复杂度需求上试点
2. 把“先总分析、再拆子任务、子任务内部再小步”的方法固化下来
3. 把“一个 commit 对应一个稳定轮次”写入提交规范
4. 在AGENTS.md中加入复杂任务的并行和收口规则
5. 在复盘中总结哪些任务真的适合三件套，哪些只需要其中两件套

22. 一句话总结

Codex 小步迭代 + Git commit + 多任务并行的高级组合版，本质上是在速度、稳定性、可回退性之间建立平衡，让复杂任务既能拆得开，也能收得住。

23. 快速上手清单

• 先写清总目标
• 先拆独立子任务
• 再给每个子任务拆小步轮次
• 并行推进时保持边界清晰
• 每轮稳定结果尽量 commit
• 最后统一做冲突检查、联调和回归