14 · 常见工作流：探索、修 Bug、重构与测试

探索代码库、定位修复 Bug、控制重构、补写测试四类高频任务的标准步骤与验收方法。

日常用 Codex，最频繁的无非四类活：探索、修 Bug、重构、写测试。把它们各自的标准流程记下来，能省大量时间。

「探索代码库」：当你接手一个陌生项目，先别让它改任何东西，而是让它「读一读、讲一讲」。让它解释整体结构、关键模块、数据流。这一步是纯读，目标是快速建立理解。

「修 Bug」：标准动作是「先复现、再定位、后修复、终验证」。让它先确认问题能复现，再找到根因，再动手改，改完一定跑测试验证。很多人图快跳过「复现」和「验证」，结果改完引入新问题。

「重构」：重构最怕「牵一发动全身」。所以关键是「控制范围」和「小步走」。一次只重构一个点，每步都验证没破坏原有行为。让它先说明重构计划、再动手，比直接改安全得多。

「补写测试」：给一段没有测试的代码补测试，先让它理解这段代码的输入输出和边界情况，再生成覆盖主要路径的测试。写完之后，跑一遍确认测试本身是绿的、且真的测到了东西。

这四类活有个共同点：都强调「先理解、再动手、后验证」。Codex 不是让你完全撒手，而是让你从「亲手写每一行」变成「指挥它写、然后你审」。

每类任务也有各自的「验收标准」：探索要「讲得清楚」，修 Bug 要「问题不再现」，重构要「行为不变」，写测试要「覆盖到位且通过」。心里有这把尺子，你才能判断它到底干没干好。

动手试一下：比起看十遍，不如立刻打开 Codex 跑一个小任务验证你理解的概念。比如这一篇讲的概念，你可以找一个一分钟能完成的小需求，让它跑一遍，看实际行为是不是和你理解的一致。

动手试一下：你可以花 5 分钟做一个最小验证——找一个真实的代码任务，让 Codex 跑一遍，看它的行为是不是和这一篇描述的一致。理论与实践对照，才知道「懂」和「会用」是两件事。

延伸阅读：学完这一篇，你可以看本组里的下一篇，把相邻的概念连起来读；也可以跳到更后面的组学 MCP、子代理、Skills 这些更深的能力。知识是网状的，多跳几篇会理解更深。

判断决策树：用三个问题判断该不该用——① 这件事值不值得用 Codex 做？② 用的话该用哪个入口？③ 风险高不高需不需要审批？三个问题的答案一出来，怎么做就清楚了。