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