你是否曾遇到过这样的困境？在使用Codex排查Bug时，第一次修改未能解决问题，第二次尝试换了一种写法，到第三次居然连原本正常的代码也被顺带改坏了。这并非Codex本身不会修复Bug，而是因为它获取到的信息太少，只能依赖有限的代码片段和报错信息反复猜测，结果越修越偏离正确方向。
OpenAI官方发布的Codex提示指南也明确指出：提交任务时最好附带相关文件、运行结果和明确的上下文信息，这能有效减少Codex的假设空间，并缩小修改范围。那么，在第一次提问时，究竟应该提供哪些信息？以下5类内容，建议一次性完整给出。
一、完整的报错信息
很多人一上来只丢给Codex一句“报错了”，然后静待结果。这样的信息量其实远远不够。真正高效的做法是提供：
- 完整的错误堆栈；
- 报错出现的具体文件和行号；
- 执行的具体命令；
- 错误出现前刚刚进行的操作；
- 问题是否能够稳定复现。
一个值得留意的细节是：许多报错的关键线索并不位于最后一行，而是隐藏在堆栈的中间部分。比如数据库连接失败，最后可能只显示“请求处理异常”，但真正的根源可能是连接超时、字段不存在或环境变量未加载。如果只复制一句错误摘要给Codex，它很可能修复到完全无关的地方去。
二、问题出现前后的操作步骤
排查Bug不能只盯着最终结果，还要理清问题是如何一步步产生的。举个例子：
- 用户进入订单页面；
- 选择两个商品；
- 使用优惠券；
- 修改收货地址；
- 点击提交后页面卡住。
如果只说“订单提交失败”，Codex很可能直接去检查提交接口。但真实的触发点或许在优惠券状态、地址校验逻辑或前端请求参数上。因此，最好把能够稳定触发问题的操作步骤按顺序写清楚，让Codex能沿着相同的路径去定位。
三、预期结果和实际结果
不少人习惯只描述“哪里不对”，却没说正确的结果应当是什么样子。例如只说“页面一直转圈”，这句话的信息量极低。更清晰的写法是：
预期结果：点击提交后，订单创建成功并跳转到支付页面；实际结果：前端请求返回500，控制台出现TypeError错误。
明确了预期结果，Codex才能判断应该修改后端返回值、前端判空逻辑，还是同时补充测试用例。否则它可能只是让某个报错暂时消失，但业务逻辑的根本问题并未真正解决。
四、运行环境和依赖版本
同一段代码在不同环境下的运行结果可能天差地别。排查前最好说明：
- 操作系统类型；
- 编程语言版本；
- 框架版本；
- 包管理器信息；
- 数据库类型；
- 关键依赖版本；
- 当前环境是本地、测试还是生产。
尤其以下几类问题，通常与环境密切相关：
- 本地正常，服务器报错；
- Windows上能运行，Linux上跑不起来；
- 升级依赖后突然报错；
- 开发环境正常，打包后失败；
- Node、Python或JDK版本不一致。
如果这些版本信息不提供，Codex可能默认使用最新版语法去修改代码，结果改出来的内容与当前项目环境完全不兼容。
五、允许修改的范围
排查一个小Bug时，最好明确告诉Codex哪些地方可以改、哪些地方不能动。比如可以说：不要修改数据库结构，不要升级依赖；先分析根因，再给出最小修改方案；修改后跑一遍相关测试。
如果没有限制修改范围，Codex可能为了通过测试，顺手把公共方法、配置文件或测试用例也改了。Bug或许修好了，但改动范围比原需求大得多，代码审查的工作量也跟着翻倍。
OpenAI的Codex最佳实践也建议将大任务拆分成范围明确、容易验证的小任务。对于复杂修改，可以先让Codex分析问题原因并给出计划，确认无误后再开始写代码。
一个更有效的排错模板
现在我在给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排查Bug时反复修改、原地打转，很多时候不是模型不行，而是我们给予的信息不够充分。真正有效的一次性提示，核心就包含这五样东西：
- 完整报错信息；
- 可以复现的操作步骤；
- 明确的预期结果和实际结果；
- 精准的运行环境和依赖版本；
- 清楚的修改范围限制。
给Codex的信息越准确，它需要猜测的就越少。真正高效的排错提示，不是越长越好，而是让问题能够复现、结果可以验证、修改范围可控。