最近接手了一个自己并不熟悉的老项目，我发现自己使用 Codex 的方式也开始发生变化。
以前会觉得，既然 Codex 能扫描整个项目，那把需求告诉它，让它一次把功能做完不是更省事吗？
但现在我反而越来越不敢让它一次改太多代码。
一次改太多，自己反而看不懂了
问题不一定是 Codex 写错了。
很多时候功能确实能正常运行，编译也没有问题，但它一次修改的文件和代码太多，我自己又本来就不熟悉这个项目，看diff 的时候很容易出现一种感觉：
这些地方为什么要改？
尤其是老项目，本身就有不少历史逻辑。如果 Codex 一次修改十几个地方，又增加一些新的方法和封装，我很难马上判断哪些改动是完成需求必须的，哪些只是它自己认为应该顺手处理的。
最后看起来 AI 很快把需求做完了，但我还得重新花时间理解它到底做了什么。
AI 改得快，不代表一次改得越多越好
用 Codex 时，如果它一次改得太快、太多，我就有点跟不上。
如果一次只改一个比较明确的范围，我还能认真检查这次修改，确认业务逻辑没有问题，再继续下一步。
但如果一个需求直接让它从头做到尾，等它一次生成大量修改以后，审查成本也会跟着上升。
尤其是在自己不熟悉的项目里，这种感觉更加明显。
因为我连原来的业务都还没有完全搞清楚，如果再让 AI 一次改变太多东西，最后可能出现功能已经完成了，但我自己却说不清整个修改过程。
我现在更愿意把任务拆小一点
所以现在遇到这种项目，我更倾向于先让 Codex 找到业务入口和调用关系，自己先看一遍。
确认大致流程以后，再让它修改一个相对明确的范围。
改完以后先看 diff，确认这一步我能理解，再继续后面的修改。
这样可能没有“一句话让 AI 完成整个需求”看起来那么爽，但至少整个修改过程还在自己的掌控范围内。
我更在意自己能不能掌控这次修改
如果是自己非常熟悉的项目，或者任务边界本身就很清楚，让它一次完成更多工作当然可以提高效率。
但对于刚接手、自己都还没完全理解的老项目，我现在会更谨慎一些。
功能做出来以后，我还得知道它改了哪些地方、为什么要这样改。
如果这些都说不清，我就得回头重新看代码，前面省下来的时间也就花回去了。