Codex为什么总改错文件？项目边界、同名文件与工作目录排查

2601_96395508

363人浏览 · 2026-08-19 16:53:11

2601_96395508 · 2026-08-19 16:53:11 发布

用 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证明它找对了，再让它动手。