摘要
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需要同时理解：
任务越多，修改范围越容易扩大，也更难判断到底是哪一步出现问题。
更合适的方式是分阶段执行：
第一步，只定位登录报错，不修改代码。
第二步，只修改导致报错的文件。
第三步，运行测试并检查结果。
第四步，再决定是否重构相关模块。
先分析、再修改、最后验证，比一次性要求完成所有工作更容易控制修改范围。
五、修改完成后没有检查差异
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个：
使用Codex处理真实项目时，最重要的不是一句话让它“全部完成”，而是先说明目录、文件、规则和验证方式。项目边界越清楚，误改和返工通常越少。
