1. 文档目标这份文档的目标是帮助你从“一步到位思维”切换到“小步迭代思维”。读完之后你应该能够理解为什么 Codex 更适合小步迭代而不是一次性大改掌握一套稳定的小步迭代操作流程知道每一步应该让 Codex 做多大范围的事情学会在开发、排错、测试、重构场景里使用小步迭代避免常见的“大改失控”“越改越乱”“最后难以验证”问题一句话概括小步迭代不是保守而是让复杂任务在真实工程中更稳地跑通。2. 什么是“小步迭代”小步迭代不是简单地“分很多次问”而是一种工作方式先拿到一个最小可用版本每次只解决一个主要问题每轮都做局部验证根据结果决定下一轮做什么最后逐步逼近完整目标它强调的是小范围修改快速反馈持续验证可回退可收口3. 为什么 Codex 特别适合小步迭代Codex 很擅长读取当前状态基于当前结果继续修改在每一步里给出分析、实现和验证建议而真实项目里的复杂问题往往并不适合一次性生成最终答案因为需求本身可能不完整代码上下文可能很复杂一个修改可能牵出新的问题最优方案往往是边做边判断出来的所以小步迭代不是“退而求其次”而是更贴合真实工程环境的策略。4. 小步迭代和一次性大改的区别一次性大改的常见问题改动范围太大容易偏离目标问题一多难以判断哪一步改坏了最后验证成本很高不利于 review 和回滚小步迭代的优势每次只改一小块更容易看懂每一步都能验证方向是否正确出问题时更容易回退非常适合真实项目中的渐进式修改5. 什么场景最适合小步迭代下面几类场景尤其适合。5.1 Bug 修复因为你往往需要先定位、再试修、再验证。5.2 功能增量开发例如先支持基础字段流转再补筛选再补展示再补测试。5.3 重构优化重构最怕一口气改太大小步迭代更安全。5.4 测试补充可以先补核心路径再补异常场景再补边界和回归。5.5 项目理解与规范沉淀可以先理解结构再理解调用链再提炼规则再生成文档。6. 什么场景不适合无限细碎迭代小步迭代很重要但也不能拆得过细。下面这些情况要注意平衡一个极小的改动本来一步就能完成任务非常明确没有必要人为分成太多轮每轮都只推进一点点反而拖慢效率一句话小步迭代追求的是可控不是机械地把一切都切成碎片。7. 小步迭代的标准流程1. 明确总目标2. 先做最小可用版本3. 局部验证4. 识别下一步改进点5. 再做一轮小改动6. 再验证7. 持续迭代直到收口8. 第一步明确总目标但不要一开始就追求最终形态很多人一上来就让 Codex 直接交付最终版本但在复杂项目里这通常不稳。更好的做法是总目标保持清晰第一轮目标保持克制示例总目标给会员资料管理增加 customerLevel 字段并完成前后端联动、筛选和测试说明。第一轮目标先只完成后端字段流转不处理前端展示和测试文档。这就叫“目标明确但当前步收缩”。9. 第二步先做最小可用版本这是小步迭代最核心的动作。什么叫最小可用版本就是先解决最核心的一条主链路暂时不做无关增强先保证有一个跑得通的起点常见形式先让接口能通先让字段能保存先让查询能跑先让核心 bug 消失示例提示词先不要做大改先帮我实现一个最小可用版本。 目标 让 customerLevel 字段在后端保存和返回链路里先跑通。 约束 1. 不处理前端展示 2. 不补测试文档 3. 不做无关重构 4. 优先最小改动10. 第三步每完成一小步就做局部验证如果没有验证小步迭代就失去了意义。局部验证可以做什么看改动范围是否正确看链路是否打通看是否影响已有功能看是否存在明显异常日志看是否值得进入下一轮验证的价值避免带着错误继续往下迭代让每一轮都有真实反馈更容易快速纠偏11. 第四步基于当前结果决定下一轮做什么小步迭代不是预先机械写死全部步骤而是每一轮基于当前结果决定下一轮。常见的下一轮决策方式主链路通了下一轮补筛选查询通了下一轮补页面展示功能通了下一轮补日志和异常处理实现通了下一轮补测试与文档这一步为什么重要因为真实项目里最优路径往往不是一开始就完全知道而是在迭代过程中逐步清晰。12. 第五步控制每轮改动范围这是很多人最容易失控的地方。每轮建议只改一个主要维度例如只改接口对象只改 Service 逻辑只改 SQL 条件只补日志只补测试不推荐一轮里既改接口又改 SQL又改前端又重构公共类原因一旦出问题不容易定位是哪一块引起的13. 第六步保留阶段性快照小步迭代如果没有快照就少了一半价值。推荐做法每个关键阶段前后做 commit 或至少有清晰保存点每一轮迭代完成后记录当前状态为什么重要可以快速回退可以对比前后差异便于 code review14. 第七步最终统一收口小步迭代不是无限进行而是需要在合适的点收口。收口时要检查总目标是否已经完成子步骤是否都打通是否还有遗留边界场景是否需要补测试和文档是否还存在无关改动扩散收口提示词模板请基于前面几轮小步迭代结果帮我做统一收口检查。 请输出 1. 当前已完成内容 2. 还缺什么 3. 是否已经满足总目标 4. 最终验证步骤15. 小步迭代的常见模型15.1 模型一功能主链路迭代适用场景功能开发典型路径先打通主链路再补筛选或附加逻辑再补异常处理再补测试和文档15.2 模型二Bug 修复迭代适用场景线上或联调问题修复典型路径先定位再做试修再验证问题是否消失再补回归检查15.3 模型三重构迭代适用场景局部重构典型路径先抽离最明显的重复逻辑再保持行为不变验证再做下一块重构15.4 模型四测试补充迭代适用场景补测试典型路径先补核心路径再补异常路径再补边界与回归16. Java / Spring Boot 项目实战实例场景会员资料管理要新增customerLevel字段。要求新增和编辑接口支持该字段列表支持展示分页支持筛选最后补联调清单和测试说明不推荐的一次性提法请一次性帮我把 customerLevel 相关的后端、前端、SQL、测试、文档全部做完。问题在于范围过大难以控制风险不利于逐步验证推荐的小步迭代方式第一轮只打通后端字段流转先只处理后端字段流转。 目标 让 customerLevel 可以完成新增、编辑、查询返回。 约束 1. 不改前端展示 2. 不补测试文档 3. 不做无关重构第二轮补分页筛选基于当前结果第二轮只补 customerLevel 的分页筛选能力。 要求 1. 检查 ReqVO、Service、Mapper、XML 2. 优先最小修改 3. 修改后给验证建议第三轮补前端展示现在第三轮只处理前端列表和表单展示。 要求 1. 衔接现有后端字段 2. 保持现有 UI 风格 3. 不引入额外复杂交互第四轮补测试和联调清单最后一轮请基于前面改动补充 1. 接口联调清单 2. 功能验证清单 3. 回归测试建议为什么这样更稳因为每一轮都只有一个主要目标出了问题也更容易判断在哪一层。17. Bug 修复实战实例场景订单分页接口在带手机号筛选时返回空数据。推荐的小步迭代方式第一轮先定位先不要改代码先帮我定位手机号筛选相关代码链路。 请输出 1. Controller 入口 2. Service 调用 3. Mapper 与 XML 位置 4. 最可能出问题的地方第二轮再试修请基于刚才判断的根因做最小修复。 要求 1. 不做无关优化 2. 只修手机号筛选问题 3. 修改后说明影响范围第三轮再补回归验证请基于这个修复结果补充 1. 正常筛选验证 2. 异常场景验证 3. 组合条件回归验证图示流程定位问题试做最小修复局部验证补下一步改动最终回归验证18. 测试任务实战实例场景一个需求已经做完但测试覆盖不充分。推荐的小步方式先补核心功能测试再补异常测试再补边界测试最后补回归清单示例提示词请按小步迭代方式帮我补测试 第一轮先输出核心功能测试点 第二轮再输出异常测试点 第三轮再输出边界测试点 最后补回归测试清单。19. 小步迭代中的常见误区19.1 误区一每一步都太大问题名义上在迭代实际上每轮还是大改19.2 误区二每一步都太小问题迭代成本过高推进过慢19.3 误区三没有中间验证问题带着错误一路迭代下去19.4 误区四每轮都顺手重构问题目标不断扩散失去“控制变量”19.5 误区五没有最终收口问题一直在迭代但没有明确完成点20. 注意事项总目标要清晰但当前步要收缩每轮只改一个主要维度修改后立刻局部验证尽量保留阶段性快照不要把无关优化混进当前轮发现方向不对就及时纠偏最后必须统一收口21. 高质量提示词模板21.1 通用模板请不要一次性完成全部任务按小步迭代方式帮我推进。 总目标 当前这一步只做 约束 1. 优先最小改动 2. 不做无关重构 3. 修改后给验证建议21.2 开发任务模板这是一个开发任务请按小步迭代方式处理。 总目标 当前轮目标 只允许修改 不要处理 输出要求 1. 先分析 2. 再最小改动 3. 最后给下一轮建议21.3 Bug 修复模板请按小步迭代方式处理这个 bug。 第一轮先定位问题 确认后第二轮再修复 第三轮再补验证和回归建议。22. 团队落地建议如果你想把这套方式推广到团队里建议这样做先用一个真实需求做“小步迭代演示”固化一套“当前轮目标模板”在AGENTS.md中加入“小步优先”的协作规则对复杂任务要求先给出迭代计划在复盘中总结哪些轮次拆得最合理23. 一句话总结Codex 小步迭代的本质不是把任务做慢而是用更小的改动、更快的反馈和更稳定的验证把复杂问题更稳地推进到完成。24. 快速上手清单先写清总目标第一轮只做最小可用版本每轮只推进一个主要目标每轮结束先局部验证再决定下一轮做什么保留阶段性快照最后统一收口