先说结论：Codex 修 Bug 的正确姿势不是把报错截图一丢就等结果。你需要走一个完整流程——报错信息给全、让它先复现、定位根因、做最小改动、跑测试验证、最后你看 diff 确认。跳过任何一步都容易翻车。
完整流程分六步
第一步：把报错信息给全。 不是只截一行红字，而是完整的错误堆栈、触发条件、你的操作步骤、环境信息（Node 版本、操作系统、包管理器）。信息越完整，Codex 定位越准。如果报错很长，直接全文粘贴，不要自己截断——你觉得没用的那几行，可能恰好是关键线索。
第二步：让它先复现。 在提示词里明确要求”先复现这个问题，确认能稳定触发再动手修”。复现不了的 Bug，改了也不知道改没改对。
第三步：定位根因。 让 Codex 列出可能的原因和对应文件，不要直接跳到改代码。你可以用 /plan 模式，让它先出方案你确认后再动手。
第四步：最小改动。 明确告诉它”只做最小修改，不要顺手重构”。Codex 有时候热心过头，改一个 Bug 顺便重构了半个模块，引入新问题的风险很大。如果确实需要重构，那是另一条线程的事，不要和修 Bug 混在一起。
第五步：跑测试。 修完之后让它跑项目里已有的测试。如果没有现成测试，让它写一个针对这个 Bug 的回归测试，确保修完就过、回退就挂。
第六步：你看 diff。 在 Codex App 里按 Cmd + Option + B 打开 diff 面板，逐行看它改了什么。确认改动范围和预期一致，再提交。
提示词模板：报错排查型
下面是完整的报错信息和复现步骤。请先尝试复现，确认能触发后再定位原因。
列出可能的根因（按可能性排序），不要直接修改文件。等我确认后再做最小改动，并运行相关测试。
报错信息：
[粘贴完整堆栈]
复现步骤：
1. ...
2. ...
环境：Node xx / macOS / pnpm提示词模板：回归验证型
我刚修复了 [简述问题]，请帮我写一个回归测试：
1. 测试用例要覆盖修复前会失败的场景
2. 同时覆盖正常路径确保没有副作用
3. 写完后运行测试并报告结果
相关文件：[列出涉及的文件路径]三个常见翻车原因
不给上下文。 只丢一行报错，不给堆栈、不给复现步骤、不给环境信息。Codex 只能猜，猜错了改出来的东西更糟。
一次改太多。 把五个 Bug 塞进一条消息让它一起修。结果改动混在一起，分不清哪个修了哪个没修，出了问题也没法回滚单个改动。一条线程一个 Bug，这是铁律。
不验收就提交。 Codex 说”已修复”你就直接 commit。一定要看 diff、跑测试。它说修好了不代表真修好了，尤其是涉及异步逻辑和边界条件的时候。养成习惯：Codex 改完后，先在 diff 面板逐行过一遍，再手动跑一次测试，确认通过了再提交。
修 Bug 和 Codex 执行机制的关系
Codex 修 Bug 时默认会读取项目里的 AGENTS.md 来了解项目约定。如果你的 AGENTS.md 里写了测试命令和代码风格要求，它会自动遵守，省掉你每次口头交代的时间。
关于 Codex 的任务执行机制和沙箱环境，参考站内 Codex 任务执行机制详解。CLI 环境下修 Bug 的基本流程相同，但查看 diff 用 /diff 命令、切模型用 /model 命令，操作细节参考 Codex CLI 安装教程。
修 Bug 是 Codex 最实用的场景之一，但它的效果完全取决于你给的信息质量和验收习惯。流程跑顺了，一个中等难度的 Bug 从报错到测试通过通常十几分钟就能搞定。
升级 ChatGPT Plus 遇到付款问题，可以直接在这里一站式解决：ChatGPT Plus 国内充值升级教程。
套餐、价格、模型以 OpenAI 官网当时显示为准，本文核对日期 2026-09-17。