Codex修复Bug为何总在原地打转：这5个信息必须一次给全

用Codex排查Bug时，经常会遇到一种情况：

第一次修改后问题还在，第二次又换了一种写法，第三次甚至把原本正常的代码也改坏了。

这不一定是Codex不会修，而是它拿到的信息不足，只能根据有限的代码和报错反复猜测。

OpenAI官方的Codex提示指南也建议，在提交任务时提供相关文件、运行结果和明确的上下文，让Codex减少假设并缩小修改范围。(developers.openai.com)

下面这5类信息，最好在第一次提问时就给全。

一、完整的报错信息

不要只告诉Codex：

至少要提供：

• 完整错误堆栈；
• 报错发生的文件和行号；
• 执行了什么命令；
• 错误出现前做过什么操作；
• 问题是否稳定复现。

很多报错真正有用的信息并不在最后一行，而是在堆栈中间。

例如数据库连接失败，最后可能只显示“请求处理异常”，真正原因却可能是连接超时、字段不存在或环境变量没有加载。

只复制一句错误摘要，Codex很容易修错位置。

二、问题出现前后的操作步骤

排查Bug不能只看最终结果，还要知道问题是怎么出现的。

例如：

1. 用户进入订单页面；
2. 选择两个商品；
3. 使用优惠券；
4. 修改收货地址；
5. 点击提交后页面卡住。

如果只说“订单提交失败”，Codex可能直接检查提交接口。

但真实问题也可能发生在优惠券状态、地址校验或前端请求参数中。

最好把能够稳定触发问题的操作步骤按顺序写出来，让Codex按照同样的路径定位。

三、预期结果和实际结果

很多人只描述“哪里不对”，却没有说明正确结果应该是什么。

例如：

这句话的信息量很低。

更清楚的写法是：

预期结果明确后，Codex才能判断应该修改后端返回值、前端判空逻辑，还是同时补充测试。

否则它可能只是让报错暂时消失，却没有解决业务逻辑问题。

四、运行环境和依赖版本

同一段代码在不同环境中的表现可能完全不同。

排查前最好说明：

• 操作系统；
• 编程语言版本；
• 框架版本；
• 包管理器；
• 数据库类型；
• 关键依赖版本；
• 本地、测试环境还是生产环境。

特别是下面几类问题，通常和环境有关：

• 本地正常，服务器报错；
• Windows能运行，Linux不能运行；
• 升级依赖后突然出现异常；
• 开发环境正常，打包后失败；
• Node、Python或JDK版本不一致。

如果不提供版本信息，Codex可能按照最新版语法修改代码，结果与当前项目环境并不兼容。

五、允许修改的范围

排查一个小Bug时，最好明确告诉Codex哪些地方可以改，哪些地方不能动。

例如：

如果没有限制修改范围，Codex可能为了让测试通过，顺便修改公共方法、配置文件或测试用例。

最后Bug可能修好了，但改动范围比原需求大得多，代码也更难审查。

OpenAI的Codex最佳实践建议把任务拆成范围明确、容易验证的小任务。对于复杂修改，可以先让Codex分析问题并给出计划，确认后再开始写代码。(developers.openai.com)

一个更有效的排错模板

我现在给Codex提交Bug时，通常会按照下面的结构描述：

 复制代码问题现象：
用户提交订单后，页面一直显示加载中。复现步骤：
1. 登录测试账号；
2. 将两个商品加入购物车；
3. 使用优惠券；
4. 点击提交订单。实际结果：
前端请求返回500，控制台出现TypeError。预期结果：
订单创建成功，并跳转到支付页面。运行环境：
Node.js 22、React、NestJS、MySQL。相关文件：
前端提交逻辑在src/pages/order.tsx；
后端接口在src/modules/order/order.service.ts。修改限制：
不要修改数据库结构，不要升级依赖。
先分析根因，再给出最小修改方案，修改后运行相关测试。

这种写法看起来比“帮我修Bug”麻烦一点，但通常能减少Codex反复尝试和大范围改动。

对于测试失败，也可以直接把命令输出交给Codex分析。Codex支持把日志或测试结果作为上下文输入，先总结失败原因，再提出最小修复方案。(developers.openai.com)

总结

Codex排查Bug时反复修改，不一定是模型能力不够。

更常见的原因是缺少以下信息：

• 完整报错；
• 复现步骤；
• 预期结果；
• 运行环境；
• 修改范围。

给Codex的信息越准确，它需要猜测的地方就越少。

真正有效的排错提示，不是写得越长越好，而是让问题能够复现、结果能够验证、修改范围能够控制。