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。

图示

总目标
子任务A
子任务B
子任务C
A-第一轮小改动
验证 + commit
B-第一轮小改动
验证 + commit
C-第一轮小改动
验证 + commit
统一收口

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

下面这些场景特别适合。

6.1 多模块功能开发

例如：

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

6.2 高风险复杂 Bug 修复

例如：

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

6.3 大型重构或优化任务

例如：

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

6.4 团队协作交付

因为：

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

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

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

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

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

8. 标准操作流程

1. 明确总目标
2. 拆分独立子任务
3. 为每个子任务定义边界
4. 每个子任务再拆小步轮次
5. 子任务并行推进
6. 每轮局部验证
7. 关键轮次 commit 留快照
8. 汇总结果与冲突检查
9. 最终联调、回归、收口

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
• 前后端是否一致
• 筛选、保存、编辑、展示是否全部打通
• 联调和回归清单是否与最终实现一致

图示流程

总目标：customerLevel
A：接口对象
B：Service
C：SQL
D：前端
E：测试文档
小步迭代 + commit
小步迭代 + commit
小步迭代 + commit
小步迭代 + commit
小步迭代 + commit
统一收口

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
• 最后统一做冲突检查、联调和回归