
摘要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或ReactJavaScript或TypeScriptAxios或FetchPinia、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处理真实项目时最重要的不是一句话让它“全部完成”而是先说明目录、文件、规则和验证方式。项目边界越清楚误改和返工通常越少。