让 Codex 一次完成较大的改动时，提示词太笼统往往会增加返工。一个比较稳的做法，是把任务拆成“分析、实现、测试、验收”四段，并为每段写清楚完成条件。
可以这样描述：
1. 分析：先阅读哪些目录、现有约束是什么，只做调查，不修改文件。
2. 实现：限定允许改动的范围，说明要保留的兼容行为。
3. 测试：列出必须运行的测试、失败时需要继续定位还是先报告。
4. 验收：要求对照原始需求逐项核查，并给出改动文件和验证结果。
如果几个子任务互不依赖，还可以分到独立任务中并行处理；如果会修改同一批文件，则更适合串行完成，减少冲突。任务描述里最好同时写明“不做什么”，例如不升级依赖、不改公开接口、不删除现有数据。这样比单纯说“帮我优化一下”更容易得到可检查的结果。

楼主在贴吧发是真分享