很多人使用 Codex 修改代码时，都遇到过类似情况：
第一次只是一个小报错，修改后却出现了更多问题；让它继续修复，代码改动范围越来越大；最后原来的问题没解决，项目结构反而变得更乱。
这并不一定代表 Codex 的代码能力不行。很多时候，真正的问题是它拿到的上下文不完整。
Codex可以读取项目文件、执行命令、运行测试和检查代码差异，但它并不知道开发者脑子里的业务规则。官方最佳实践也强调，复杂项目需要明确提供目标、相关文件、限制条件和完成标准，才能减少模型自行猜测。
一、只说“修复报错”，没有说明最终目标
最常见的提问方式是：
这里报错了，帮我修一下。
Codex看到报错后，通常会根据当前代码推测原因，但它不知道你真正想保留什么。
例如，一个接口出现参数校验错误，可能有几种处理方式：
- 修改前端传参；
- 调整后端参数类型；
- 增加默认值；
- 删除当前校验；
- 修改数据库字段。
这些方法都有可能让报错暂时消失，但不一定符合原来的业务设计。
所以在让 Codex 修改代码前，至少要说明三个问题：
- 当前功能原本应该做什么；
- 哪些行为不能改变；
- 允许修改哪些文件或模块。
比起“帮我修复报错”，更有效的描述是：
用户提交表单后，后端应该保存数据并返回成功结果。目前接口提示参数类型错误。请保留现有数据库结构，只检查前端传参和接口参数处理，不要修改其他业务模块。
目标越明确，Codex越不容易为了消除一个报错而大范围改代码。
二、只提供最后一行报错，没有完整日志
很多人看到终端最后一行出现错误，就直接复制给 Codex。
但最后一行通常只是结果，真正的原因可能出现在前面的调用链、警告信息或者初始化日志中。
例如：
- 数据库连接失败，最后却显示接口请求异常；
- 依赖加载失败，最后却显示对象不存在；
- 环境变量为空，最后却变成参数类型错误；
- 前一个请求已经失败，后面连续出现多个关联报错。
如果只把最后一句错误交给 Codex，它只能从结果反推原因。第一次判断错误后，后续修改就可能沿着错误方向继续扩大。
更好的做法是同时提供：
- 完整错误日志；
- 报错前执行的操作；
- 能稳定复现问题的步骤；
- 最近修改过的文件；
- 正常情况下应该出现的结果。
不要只告诉 Codex“哪里错了”，还要告诉它“这个错误是怎么出现的”。
三、没有说明系统、版本和依赖环境
同一段代码，在不同环境中可能产生完全不同的结果。
常见差异包括：
- Windows、macOS和Linux路径格式不同；
- Node.js、Python或Java版本不同；
- 依赖包版本不同；
- 开发环境和生产环境配置不同；
- npm、pnpm和yarn生成的依赖树不同；
- 数据库版本或者字符集不同。
如果没有告诉 Codex实际运行环境，它可能会按照另一套环境给出修改方案。
例如，项目使用旧版本框架，但 Codex根据新版本语法修改代码；本地使用 Windows，它却生成只适合 Linux 的命令；项目使用 pnpm，它却重新生成 npm 的锁文件。
OpenAI官方文档也提到，错误的工作目录、缺少工具、权限不正确或者环境配置不完整，都会影响 Codex的执行结果。
开始修改前，建议先说明：
当前环境为 Windows 11、Node.js 22、pnpm 管理依赖，项目基于 Vue 3 和 Vite。请不要更换包管理器，不要升级主要依赖版本。
这一小段环境说明，往往能避免后面大量无效修改。
四、没有告诉它项目结构和开发规范
Codex能看到代码，不代表它立刻能理解整个项目的设计习惯。
一个真实项目通常有自己的规则：
- 接口请求统一放在哪个目录；
- 公共方法如何封装；
- 错误信息如何处理；
- 数据库操作是否必须经过服务层；
- 能不能增加新的依赖；
- 哪些目录不能直接修改；
- 提交前需要执行哪些检查。
如果这些规则没有说明，Codex可能会选择“最快能运行”的方案，而不是“最符合项目架构”的方案。
例如，项目已经有统一的请求封装，它却在页面里重新写一套请求逻辑；项目规定所有数据库操作必须放在服务层，它却直接在控制器里查询数据库。
对于长期使用 Codex的项目，可以在仓库中增加AGENTS.md，记录项目目录、启动方式、测试命令、代码规范和禁止事项。Codex会在开始任务前读取这些项目说明。
文件内容不需要写得很长，说明清楚核心规则即可：
项目使用 pnpm，不要生成 package-lock.json。 修改接口前先检查 services 目录中的现有封装。 不要修改数据库表结构。 完成修改后运行 lint 和相关单元测试。 除非明确要求，否则不要添加新的生产依赖。这比每次重新解释项目规则更稳定。
五、没有定义“修改完成”的标准
还有一种常见情况：代码已经不报错了，但功能仍然不正常。
原因是开发者只要求 Codex“修复”，却没有告诉它怎样才算真正完成。
不报错只是最低标准。一个修改是否可用，还需要检查：
- 原问题能否稳定复现并确认消失；
- 原有功能有没有受到影响；
- 输入为空或格式错误时是否正常处理；
- 测试、类型检查和构建是否通过；
- 修改范围是否超出预期；
- 是否引入重复代码或新的依赖。
官方建议不要停留在“生成代码”这一步，还应要求 Codex运行测试、检查格式、验证行为并审查最终代码差异。
可以在任务最后明确补充：
修改完成后，请运行相关测试和类型检查，查看最终 Diff，并说明修改了哪些文件、每个文件为什么要修改。如果测试无法运行，请说明具体原因，不要直接跳过。
Codex的有效工作流程并不是“生成一次代码就结束”，而是规划、修改、执行测试、观察结果、修复失败并再次验证。
一个更完整的提问模板
以后让 Codex排查问题时，可以按照下面的结构描述：
目标： 需要解决什么问题，正常结果是什么。 当前现象： 具体报错、完整日志和复现步骤。 项目环境： 操作系统、语言版本、框架版本、包管理器和数据库。 修改范围： 允许修改哪些文件，哪些模块不能动。 项目限制： 是否允许升级依赖、增加第三方库或修改数据库。 完成标准： 需要通过哪些测试、构建或人工验证。 输出要求： 列出修改文件、修改原因、测试结果和可能存在的风险。这套模板看起来比“帮我修一下”多写了几句话，但通常能减少反复修改，也能避免 Codex在错误方向上不断尝试。
总结
Codex修改代码后越改越错，很多时候不是代码生成能力的问题，而是任务上下文存在缺口。
尤其要提前说明五件事：
- 最终目标和允许修改的范围；
- 完整日志与问题复现步骤；
- 系统、版本和依赖环境；
- 项目结构与开发规范；
- 测试方式和完成标准。
把 Codex当成一个刚接触项目的新同事，而不是一个自动知道所有业务背景的工具，通常更容易得到稳定、可审查的修改结果。