用 Codex 改真实项目时，有一种问题非常让人头疼：

你明明让它修改 A 文件，它最后却改到了 B 文件。

或者更常见的是：

• 项目里有两个同名文件，Codex改错了那个；

• 明明要改前端，它却跑去动后端代码；

• 当前任务只针对一个模块，它却顺手修改了旁边目录；

• 你说的是 src/config.ts，它实际改的是另一个子项目里的 config.ts；

• Monorepo里多个包结构相似，Codex经常选错目标；

• 改完以后代码看起来没问题，但真正运行的文件其实根本没被改。

这种情况很多时候不是“模型看不懂代码”。

真正的问题往往是：

项目边界不清楚 + 工作目录不明确 + 同名文件太多。

所以遇到 Codex 改错文件时，不要第一时间让它继续重写。

先把“它到底在哪个项目里工作、它认为目标文件是哪一个”确认清楚。

---

一、先确认当前工作目录

这是最基础，也是最容易被忽略的一步。

比如你的完整项目结构是：

workspace/
├── frontend/
├── backend/
└── admin/

你真正想修改的是：

frontend/src/config.ts

但 Codex 当前实际上进入的是：

workspace/

这时项目里如果刚好还有：

admin/src/config.ts
backend/src/config.ts

就很容易出现：

目标描述没问题，但实际匹配到了错误文件。

所以任务开始前，可以先让 Codex确认：

当前工作目录是什么？
列出当前目录下一级和二级主要文件夹。
暂时不要修改代码。

先确认它看到的项目结构，和你脑子里的是不是同一个。

---

二、同名文件是最容易导致误改的情况之一

大型项目里出现同名文件非常正常。

例如：

frontend/src/utils/config.ts
backend/src/utils/config.ts
admin/src/utils/config.ts

你如果只说：

修改 config.ts。

这个要求其实非常危险。

因为从 Agent 角度看：

到底是哪一个 config.ts？

更稳定的任务写法应该是：

只修改：
frontend/src/utils/config.ts

不要修改：
backend/
admin/

把完整路径直接写出来。

尤其是：

• index.ts

• config.ts

• utils.ts

• api.ts

• types.ts

• constants.ts

这些非常常见的文件名，尽量不要只说文件名。

路径越具体，误改概率越低。

---

三、Monorepo项目尤其要先确定包边界

如果项目是 Monorepo，问题会更明显。

例如：

apps/
├── web/
├── admin/
└── api/

packages/
├── ui/
├── auth/
└── shared/

这时候一个“登录问题”，可能同时涉及：

apps/web/
packages/auth/
packages/shared/

但也可能只需要修改：

apps/web/

如果任务里没有定义边界，Codex可能会主动搜索整个仓库。

这并不一定是错误。

但它很可能找到一个“看起来也相关”的文件，然后开始修改。

所以 Monorepo里最好提前说明：

本次任务只处理 apps/web。

可以读取 packages/auth 作为参考，
但未经说明不要修改 packages/ 下任何文件。

这句话非常有用。

因为“允许读取”和“允许修改”其实是两回事。

---

四、不要一开始就让Codex直接改

很多误改其实发生在任务第一步。

例如：

登录页按钮有问题，帮我修一下。

Agent看到“登录页”，开始搜索。

找到：

Login.tsx

然后马上修改。

但真实运行的页面可能其实是：

pages/auth/login/index.tsx

这种情况非常常见：

项目里旧文件还存在，但已经不再被真正使用。

所以更稳的方式是：

先不要修改。

请先找到当前登录页面真正使用的入口文件，
说明它是如何被路由或引用的，
确认后再告诉我需要修改哪个文件。

等它先证明：

“这个文件确实在当前调用链里。”

再开始改。

这比“看到名字像就动手”稳定很多。

---

五、要检查文件是不是“真的被引用”

有时候 Codex 并没有选错名字。

它确实找到了一个：

Button.tsx

但项目真正使用的是另一个：

components/common/Button.tsx

这时真正需要检查的不是文件名。

而是：

谁引用了它。

比如前端项目里可以检查：

import Button from ...

后端则可以检查：

require(...)
import ...

或者函数调用链。

可以让 Codex先回答：

请确认这个文件当前被哪些入口或模块引用。
如果没有真实调用，不要修改。

这一步对老项目尤其重要。

因为项目里经常会残留：

旧版本；

废弃目录；

复制文件；

备份代码；

已经不再调用的组件。

---

六、相对路径容易在不同工作目录下产生误解

假设你告诉 Codex：

修改 src/api/user.ts

如果当前目录是：

frontend/

那么它理解的是：

frontend/src/api/user.ts

但如果当前目录其实是：

workspace/

它可能会寻找：

workspace/src/api/user.ts

如果又刚好存在这个文件，就很容易改错。

所以在复杂项目里，路径最好相对于一个明确根目录。

例如：

以 workspace/frontend 为项目根目录。

本次目标文件：
src/api/user.ts

先建立根目录，再给相对路径。

比单独给一句：

改 src/api/user.ts

更可靠。

---

七、任务描述里要同时写“改什么”和“不改什么”

很多开发者只写：

修改这个登录模块。

但对于 Agent 来说，真正重要的还有：

哪些地方不能动。

例如：

任务：
修复前端登录按钮重复提交问题。

允许修改：
frontend/src/pages/login/
frontend/src/hooks/useLogin.ts

禁止修改：
backend/
数据库Schema
package.json
测试之外的公共组件

这样一来，它即使搜索到其他相关文件，也知道：

这些只是参考，不应该直接动。

这就是项目边界。

长期使用 Codex 时，比单纯提示词更重要的，往往就是这种边界意识。

---

八、如果改动文件突然变多，要立即停下来

假设你只是要求：

修改一个按钮的状态逻辑。

结果 Codex最后显示：

12 files changed

这时候不要马上接受。

先问：

为什么这个任务需要修改12个文件？
分别说明每个文件和本次任务的直接关系。

如果有些文件只是：

“顺便重构”

“顺便优化”

“顺便统一风格”

就需要特别小心。

因为 Agent 最容易失控的地方之一就是：

从修问题，逐渐变成扩大修改范围。

真实项目里，一个小 Bug 通常更适合产生一个小 Diff。

---

九、旧项目特别要注意“同名旧文件”

很多维护了几年的项目都有这种情况：

login-old.ts
login.ts
login-v2.ts
auth/login.ts
legacy/login.ts

有时候真正在线上运行的是：

auth/login.ts

但从名字上看：

login.ts

反而更像“正确答案”。

如果直接让 AI 根据文件名判断，很容易误导。

这时候更可靠的方法是看：

入口 → 引用 → 调用链。

例如让 Codex：

从当前路由入口开始追踪登录流程，
确认真正执行的登录函数在哪个文件，
不要根据文件名直接猜。

这句话非常适合老项目。

---

十、改完以后一定要检查实际Diff

即使任务开始前路径确认正确，最后还是建议检查：

git status

先看：

到底哪些文件变了。

然后：

git diff

确认：

每一个改动是不是都在预期范围内。

如果任务要求只改：

frontend/src/login.ts

最终却多出：

backend/auth.ts
package.json
tests/config.ts

就需要逐一解释。

不要只因为：

“测试通过了。”

就默认所有修改都合理。

---

十一、可以固定使用一个“防改错文件”任务模板

以后涉及大型项目，可以直接套这套：

任务：
修复XXX问题。

项目根目录：
frontend/

目标范围：
src/pages/login/
src/hooks/useLogin.ts

允许读取：
src/shared/
src/api/

禁止修改：
backend/
package.json
数据库配置
其他无关模块

执行要求：
1. 先确认真实调用链；
2. 列出计划修改文件；
3. 暂时不要修改；
4. 等确认目标文件后再开始；
5. 如果需要新增修改范围，先说明原因；
6. 完成后列出全部变更文件。

这套方式最大的价值是：

先让Agent证明它找对了，再让它动手。

---

十二、什么时候最容易改错文件？

可以重点警惕下面几种项目：

Monorepo

多个App和Package并存。

前后端放在一个仓库

文件名高度相似。

老项目

存在大量废弃和历史文件。

多版本目录

例如v1、v2、legacy并存。

大量index.ts

单看文件名完全无法判断用途。

工作目录经常切换

当前Agent所在位置和开发者想象的不一致。

只要遇到这些情况，最好先做路径确认。

---

最后

Codex总改错文件，很多时候真正的问题并不是：

“AI不认识文件。”

而是：

项目里存在太多可能正确的目标。

想减少误改，最重要的是做好四件事：

先确认工作目录；

给完整文件路径；

明确允许和禁止修改范围；

修改前先确认真实调用链。

尤其是大型项目和 Monorepo，不要只告诉 Codex：

帮我改这个功能。

更稳的方式应该是：

先让它证明“应该改哪个文件”，再让它开始改。

这样不仅更容易避免改错文件，也能显著减少后续大规模回退和重复调试。

---

持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容欢迎搜索关注「仙逆GPT」。