用 Codex 排查 Bug：先找到证据，再修改代码

遇到错误时，直接让 Codex“修好它”有时足够，但复杂问题更需要稳定的调查起点。尤其是偶发故障，如果还没保存请求、日志和环境信息就重启服务，最有价值的线索可能随之消失。

OpenAI 的修复工作流文章采用检查、定向修复、验证的循环。下面把这个思路用于日常 Bug 排查，并把每一步的交付物写清楚。[1]

写下能重新发生的条件

记录使用的版本、操作顺序、输入、实际结果和期望结果。对网页问题，还应说明浏览器、屏幕宽度，以及是否需要登录。对接口问题，保留状态码、脱敏后的请求和响应、发生时间。

偶发问题也应尽量描述条件，比如“连续切换两次分类后更容易出现”，而不要过早把它归因为缓存或网络。症状是观察，原因是待验证的假设。

让第一轮调查产生证据

筛选文章后切换到第二页，列表会恢复成全部分类。
请先定位原因，暂不修改文件。

重现步骤：
进入文章列表 → 选择一个分类 → 点击第二页。

预期：第二页仍只显示所选分类。
实际：第二页出现其他分类文章。

请检查筛选状态、分页链接和请求参数，
给出相关代码位置、已确认事实和下一步验证方法。

这个请求将调查集中在一条数据路径上。Codex 可以检查页面状态如何进入链接，再追踪链接如何变成请求参数。即使最终原因不在这里，也能排除一部分假设。

修复前，尽量让检查先失败

能自动化的行为，最好用一个有意义的回归检查固定下来：旧实现应失败，修复后应通过。检查应验证用户可观察的结果，而不是照着实现细节写同一套逻辑。

如果问题依赖真实浏览器或设备，也可以保存清楚的人工复现流程。重要的是修复前后采用相同条件；换了输入、账号或环境，结果就不再具有可比性。

一次修复一个已确认的原因

不要同时重构状态管理、升级路由库和重写请求层来修复一个丢失参数的问题。改动越多，越难知道哪个变化真正起作用，也越难回退。

找到原因后，让 Codex 解释修复作用于哪条路径，为什么不会破坏相邻行为。随后检查默认分类、空结果、第一页和最后一页等边界，不需要为了追求数量而加入无关检查。

区分修好了什么与还不知道什么

本地验证通过、测试环境通过和线上验证通过，是不同层级的证据。如果没有访问线上环境，就明确写“尚未线上验证”。如果无法稳定重现，则把结论限定为“修复了已确认的参数丢失路径”，不要声称所有偶发问题都已解决。

保留一份简短记录：原因、改动、复现方法、验证结果和剩余不确定性。下一次同类问题出现时，这些信息会比一段长长的调试聊天更容易利用。