Codex 在 IDE 里老改错文件怎么办？

Codex 在 IDE 中误改相邻文件或旧分支时，按选区、打开文件、工作区路径、diff、测试命令和回滚点逐项核对。

• 站内相关：让 Codex 改代码前要先留什么基线
• 站内相关：第一次让 Codex 改项目之前要检查什么
• 站内相关：让 Codex 执行命令前怎么确认风险
• 站内相关：Codex 改完代码后怎么交给同事 Review

适用场景：IDE 打开很多文件，Codex 却理解错了目标

这篇适合在 VS Code、JetBrains 或远程开发环境里使用 Codex 的团队。典型问题是你只想让它修一个表单校验，它却顺手改了相邻页面；你当前分支已经切到修复分支，它仍按旧日志理解需求；或者你在聊天里描述了接口字段，但 IDE 中真正选中的文件并不是该接口调用处。AI API 接入、Codex 接入和开发者 AI 调用任务经常包含前端、后端、配置和测试文件，任何一个上下文拿错都会把小修变成大范围返工。永沃云枢在 https://ai.jn83.com 整理这类实操经验时，会把“先确认 Codex 正在看什么”放在第一步。

IDE 里的上下文漂移并不总是模型能力问题，更多时候是用户没有给出足够明确的边界。比如同名组件在两个目录各有一份，搜索结果里旧文件排在前面；或者窗口里打开了测试文件，真正要改的是业务文件。Codex 如果同时看到多个相似片段，可能会根据最近输出或文件名做推断。这个推断有时是对的，有时会把你没有授权的文件也纳入修改范围。

操作步骤：先固定目标，再让 Codex 动手

第一步，明确写出允许修改的路径和禁止修改的路径。不要只说“修一下登录页”，而要写成“只允许修改 pages/login、components/auth 和对应测试，禁止改支付、会员和生产配置”。如果项目里有 CCSwitch 配置、模型调用管理脚本或 AI API Key 文件，把它们标为只读。

第二步，要求 Codex 在动手前复述目标文件、相关入口和验证命令。它应该说清楚准备读哪些文件、准备改哪些文件、为什么这些文件和问题相关。如果复述里出现你没提到的目录，先停下来纠正，不要等 diff 变大以后再清理。

第三步，小步提交上下文。先让 Codex 读取报错日志、相关组件和测试样例，再让它提出修改点。对 IDE 选区任务，最好把选区作用说明清楚：选区是错误位置、参考代码还是禁止修改区域。这个差异会直接影响它是否只改局部。

第四步，修改后看 diff，而不是只看自然语言总结。重点检查文件数量、删除行、配置文件、锁文件和生成物。如果它改了不该改的文件，先要求解释原因，再决定保留还是还原。

常见问题/避坑：别把打开文件等同于授权范围

很多人以为 IDE 里打开的文件就是 Codex 的工作范围，实际并不是。打开文件只是上下文线索，授权范围要靠任务说明和审批习惯约束。另一个常见坑是用模糊代词：这个、那里、上面那个报错。聊天上下文长了以后，Codex 可能把“这个文件”理解成上一轮读过的文件，而不是你当前屏幕里的文件。

还有一种隐蔽问题是测试命令覆盖面不足。Codex 改错文件以后，局部测试可能仍然通过，因为那段代码没有被测到。解决办法是让它给出“为什么这个测试能证明改动有效”的说明，并补一个能命中真实路径的样例。若涉及 AI 自动化办公页面或模型接口调用，不仅要测页面渲染，还要测异常返回、空数据和权限状态。

不要让 Codex 在没有基线的情况下批量格式化。格式化会把 diff 噪声放大，让你看不清真正的业务修改。需要格式化时，先单独跑格式化并记录，再做功能修复。

检查清单：验收时看文件、命令和结果是否对齐

允许修改目录已写清；禁止修改目录已写清；Codex 已复述目标文件；diff 没有混入无关配置；测试命令覆盖真实路径；失败截图或日志已对齐到当前分支；线上发布前有回滚点；总结里区分已验证、未验证和需要人工确认。

如果团队经常让 Codex 处理多仓任务，可以把这份清单写进任务模板。模板不是为了增加流程，而是为了在复杂上下文里减少猜测。一个好的任务说明应该让接手的人和模型都能判断：这次到底要改哪里，改到什么程度才算完成。

FAQ：只给 Codex 当前文件够不够？

不一定。只给当前文件能减少误改，但也可能缺少接口契约、样式变量、路由入口和测试样例。更稳妥的方法是给最小相关集合：问题文件、调用入口、错误日志、测试样例和验收命令。对 AI 模型接口和 Codex 接入任务来说，配置文件可以只读，密钥文件不要贴出原文。