Codex 改坏代码时，最忌讳马上到处手动删。先保留 diff，确认哪些文件是它改的，再按 Git 粒度回退。这样既能恢复项目，也能留下问题线索，避免下次重复踩坑。
第一件事：先看改了什么
在项目根目录执行 git status，再看 git diff。如果改动很多，不要直接全撤，先按文件分类：业务代码、配置文件、锁文件、生成文件、测试文件。很多失败其实只来自一两个配置或导入路径，不一定要丢掉全部成果。
如果你还没提交过，建议先保存一个临时补丁：git diff > codex-bad-change.patch。这个文件不是为了上线，而是为了之后对照问题。
怎么回退更稳
如果只坏了某个文件，就只恢复那个文件，不要整仓库清空。可以用编辑器里的 Source Control 面板逐文件 discard，也可以用 Git 的文件级恢复。
如果 Codex 改动跨了很多文件，先让它解释每个文件为什么改。解释不清的文件优先撤掉；解释清楚但实现有 bug 的文件再局部修。
下次怎么避免改太多
让 Codex 每次只处理一个目标：先写测试、再改实现、最后跑验证。不要一条消息里同时让它重构、修 bug、改 UI、优化性能。任务越混，diff 越难回退。
也可以在开始前明确：“每次最多改 3 个文件，修改前先列计划，完成后列出实际改动和验证命令。”这会显著降低失控概率。
没有 Git 怎么办
没有 Git 的项目，先复制备份当前目录再让 AI 改。更好的做法是立刻初始化 Git，把当前可运行状态提交一次。AI 编程工具很适合快改，但前提是你有回滚点。
结论很简单：Codex 改坏代码不可怕，可怕的是没有 diff、没有提交、没有边界。只要先留证据，再按文件回退，大部分问题都能很快恢复。
