很多人使用 Codex 修改代码时，都遇到过类似情况：

第一次只是一个小报错，修改后却出现了更多问题；让它继续修复，代码改动范围越来越大；最后原来的问题没解决，项目结构反而变得更乱。

这并不一定代表 Codex 的代码能力不行。很多时候，真正的问题是它拿到的上下文不完整。

Codex可以读取项目文件、执行命令、运行测试和检查代码差异，但它并不知道开发者脑子里的业务规则。官方最佳实践也强调，复杂项目需要明确提供目标、相关文件、限制条件和完成标准，才能减少模型自行猜测。

一、只说“修复报错”，没有说明最终目标

最常见的提问方式是：

这里报错了，帮我修一下。

Codex看到报错后，通常会根据当前代码推测原因，但它不知道你真正想保留什么。

例如，一个接口出现参数校验错误，可能有几种处理方式：

• 修改前端传参；
• 调整后端参数类型；
• 增加默认值；
• 删除当前校验；
• 修改数据库字段。

这些方法都有可能让报错暂时消失，但不一定符合原来的业务设计。

所以在让 Codex 修改代码前，至少要说明三个问题：

1. 当前功能原本应该做什么；
2. 哪些行为不能改变；
3. 允许修改哪些文件或模块。

比起“帮我修复报错”，更有效的描述是：

用户提交表单后，后端应该保存数据并返回成功结果。目前接口提示参数类型错误。请保留现有数据库结构，只检查前端传参和接口参数处理，不要修改其他业务模块。

目标越明确，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修改代码后越改越错，很多时候不是代码生成能力的问题，而是任务上下文存在缺口。

尤其要提前说明五件事：

1. 最终目标和允许修改的范围；
2. 完整日志与问题复现步骤；
3. 系统、版本和依赖环境；
4. 项目结构与开发规范；
5. 测试方式和完成标准。

把 Codex当成一个刚接触项目的新同事，而不是一个自动知道所有业务背景的工具，通常更容易得到稳定、可审查的修改结果。