使用 Codex 修改项目时很多人都遇到过一种情况明明已经让它读取了整个项目也把报错信息发给了它但修改完成后才发现它动了不该动的文件甚至把原本正常的模块也改坏了。例如只是让它修复登录接口最后却同时修改了用户模块、数据库配置、公共请求方法和依赖文件。问题虽然暂时消失了项目里却多出一堆新的隐患。这不一定是 Codex 没有读懂代码更常见的原因是任务边界没有说清楚。项目越大、目录越多、历史代码越复杂越不能只说一句“帮我修一下”。下面这5个项目边界最好在 Codex 开始修改前明确告诉它。一、没有说明允许修改的目录最常见的问题就是只描述了目标没有限制修改范围。比如帮我修复用户登录失败的问题。对于开发者来说我们可能默认问题就在src/user目录。但对 Codex 来说登录失败也可能与请求封装、路由、数据库、环境变量甚至依赖版本有关。如果没有限制它就可能沿着调用链一路修改下去。更稳妥的说法是本次只允许检查和修改src/user与src/auth目录其他目录只能读取不能修改。这样可以明显减少无关文件被改动的情况。二、没有指定真正的入口文件不少项目中会同时存在多个相似入口。例如login.tslogin.service.tsuser-login.tslegacy/login.jstest/login.mock.ts人可以根据经验判断哪个文件正在使用但 Codex 可能会根据文件名、引用关系或局部代码选择一个看起来最相关的入口。如果项目里还保留了旧版本代码它就更容易从错误文件开始排查。因此提交任务时最好直接说明当前登录功能的入口是src/auth/login.controller.ts请从这个文件开始分析。不要让 Codex自己猜入口入口判断错了后面的修改通常都会偏离。三、测试目录和正式代码混在一起有些项目为了方便会把测试文件、模拟数据和正式代码放得很近。例如src/ user/ user.service.ts user.mock.ts user.test.ts当报错信息不完整时Codex可能先修改测试数据让测试暂时通过但真实业务问题并没有解决。还有一种情况是它根据测试用例理解业务逻辑但测试用例本身早已过期最终反而把正式代码改成了旧逻辑。所以要提前说明测试文件只能用于理解和验证不允许为了通过测试而修改测试用例除非确认测试本身存在错误。测试通过不等于业务正确。尤其是旧项目不能把现有测试当成绝对标准。四、历史代码没有标明是否还在使用很多项目里都会留下这些目录backup/ legacy/ old-version/ temp/ deprecated/开发者知道它们已经停用但 Codex只看到一组结构完整、功能相似的代码。如果旧代码写得更完整注释更多它甚至可能优先参考旧版本再把旧逻辑重新带回当前项目。比较稳妥的做法是在任务中明确标注legacy和backup目录已经停用只能查看不能引用、复制或修改其中的实现。如果条件允许还可以直接把废弃代码移出当前工作区减少无关上下文对判断的干扰。五、没有明确禁止修改的内容只告诉 Codex“可以改什么”还不够还要告诉它“绝对不能改什么”。常见的高风险内容包括数据库表结构公共接口参数依赖版本环境变量权限逻辑支付和订单状态其他模块正在调用的公共方法。例如一个类型报错本来只需要调整局部参数Codex却可能直接修改公共接口类型。当前文件不报错了其他模块却全部受到影响。因此任务里可以增加一句禁止修改数据库结构、依赖版本、环境配置和公共接口。如确实需要调整请先说明原因不要直接执行。我现在常用的任务说明在让 Codex修改代码前我通常先发下面这段请先读取项目目录和相关文件不要立即修改。本次只允许修改src/user目录其他目录只能读取。当前入口文件是src/user/user.controller.ts。禁止修改数据库结构、依赖版本、公共接口和环境配置。请先列出准备修改的文件、修改原因以及可能影响确认方案后再开始执行。这段话看起来多了几行但通常比让 Codex直接修改更省时间。结语Codex改错文件很多时候并不是它完全看不懂项目而是项目里存在太多相似路径而用户没有划定清晰边界。在中大型项目中至少要提前说清楚四件事修改哪个目录、从哪个文件开始、哪些代码已经废弃、哪些内容绝对不能动。先让 Codex列出修改计划再查看实际文件差异最后运行测试和人工复查。把修改范围控制住往往比反复要求它“重新修一次”更有效。