Codex为什么总改错文件？5个项目边界必须先说明

摘要

Codex修改错文件，不一定是模型没有理解需求，更多时候是项目目录、修改范围、技术栈和验证标准没有说明清楚。本文整理5个常见的项目边界问题，帮助减少误删文件、跨目录修改和反复返工。

使用Codex修改项目时，不少人遇到过类似情况：

明明只让它调整登录页面，结果配置文件也被修改了；只想修复一个接口，它却顺手重构了其他模块；代码看起来已经完成，运行后才发现改错了目录。

这些问题不一定是Codex能力不足，而可能是任务边界没有提前说明。

一、没有明确项目根目录

一个项目中可能同时存在：

• 前端目录；
• 后端目录；
• 测试目录；
• 构建产物；
• 历史版本；
• 示例项目。

如果只告诉Codex“修复登录问题”，它可能需要自行判断登录功能位于哪个目录。

当项目里存在多个名称相似的文件时，就容易出现误判。

例如：

src/pages/login.tsx admin/src/pages/login.tsx demo/pages/login.tsx

更清楚的指令应该是：

只检查项目根目录下的 src/pages 和 src/api， 不要读取 admin、demo 和 dist 目录。

先限定工作目录，再描述具体任务，可以减少无关文件被扫描和修改。

二、没有说明哪些文件允许修改

很多用户只说“完成这个功能”，却没有告诉Codex修改范围。

为了让功能正常运行，Codex可能主动修改：

• 配置文件；
• 依赖文件；
• 数据库结构；
• 公共组件；
• 测试文件；
• 环境变量示例。

这些修改不一定完全错误，但可能超出原本预期。

比较稳妥的写法是：

只允许修改以下文件： src/pages/Login.tsx src/api/auth.ts 其他文件只能读取，不能修改。 如果必须修改其他文件，先说明原因，不要直接执行。

任务范围越明确，出现跨目录修改的概率通常越低。

三、没有提供项目规则和技术栈

不同项目即使实现同一个功能，也可能使用完全不同的技术方案。

例如前端项目可能使用：

• Vue或React；
• JavaScript或TypeScript；
• Axios或Fetch；
• Pinia、Vuex或Redux；
• 不同版本的组件库。

如果没有提供技术栈，Codex可能按照常见写法生成代码，却与当前项目的版本和规范不兼容。

OpenAI官方建议通过AGENTS.md为Codex提供长期有效的项目说明，包括目录结构、构建命令、测试方式、代码规范以及禁止修改的内容。Codex开始工作前会读取这些项目说明。

一个简单的AGENTS.md可以写：

项目使用 React、TypeScript 和 Vite。 要求： 1. 不要修改 package-lock.json。 2. 不要使用 any 类型。 3. 新增接口统一放在 src/api。 4. 修改完成后运行 npm run lint。 5. 未经允许不要删除现有测试。

在Codex应用中，也可以使用/init生成基础的AGENTS.md文件，再根据项目实际情况进行补充。

四、一次让Codex修改太多内容

下面这种指令看起来效率很高：

修复登录报错，重构权限模块，更新接口， 补充测试，并优化所有相关代码。

但它实际上包含了多个任务。

Codex需要同时理解：

1. 当前报错原因；
2. 登录流程；
3. 权限逻辑；
4. 接口结构；
5. 测试框架；
6. 代码优化标准。

任务越多，修改范围越容易扩大，也更难判断到底是哪一步出现问题。

更合适的方式是分阶段执行：

第一步，只定位登录报错，不修改代码。

第二步，只修改导致报错的文件。

第三步，运行测试并检查结果。

第四步，再决定是否重构相关模块。

先分析、再修改、最后验证，比一次性要求完成所有工作更容易控制修改范围。

五、修改完成后没有检查差异

Codex提示“任务完成”，并不代表所有改动都应该直接保留。

修改后至少要检查：

• 改了哪些文件；
• 是否删除了原有逻辑；
• 是否新增了不需要的依赖；
• 配置文件是否被修改；
• 是否出现大范围格式化；
• 测试是否真正通过。

Codex应用提供Review面板，可以查看发生变化的文件和具体代码差异，也可以针对某段改动提出反馈、保留或撤销修改。

使用Git项目时，也可以执行：

git status git diff

不要只查看最终页面是否能运行，还要确认Codex有没有修改任务范围之外的内容。

一个更清楚的任务模板

以后让Codex修改项目时，可以直接使用下面的格式：

任务： 修复用户登录后无法跳转首页的问题。 项目范围： 只检查 src/pages/login 和 src/api/auth。 允许修改： src/pages/login/index.tsx src/api/auth.ts 禁止修改： package.json 配置文件 数据库文件 其他业务模块 技术要求： 使用现有React和TypeScript写法， 不要新增第三方依赖。 执行步骤： 1. 先分析原因； 2. 列出准备修改的文件； 3. 等确认后再修改； 4. 修改完成后运行测试； 5. 最后列出所有改动。

这种提示方式并不会让Codex变得更强，但能让它更清楚地知道哪里可以改、哪里不能改，以及怎样才算完成任务。

总结

Codex总是改错文件，常见原因主要有5个：

1. 没有明确项目根目录；
2. 没有限制允许修改的文件；
3. 没有提供技术栈和项目规则；
4. 一次安排了太多修改任务；
5. 修改完成后没有检查代码差异。

使用Codex处理真实项目时，最重要的不是一句话让它“全部完成”，而是先说明目录、文件、规则和验证方式。项目边界越清楚，误改和返工通常越少。