用 Codex 排查 bug：先找根因，再让它改代码

Codex 很适合排查 bug，但前提是你不要让它直接“试试看”。随机改代码可能暂时压住症状，却留下更深的问题。

第一句话要限制动作

先不要修改文件。
请根据下面的错误信息分析可能原因，并告诉我还需要看哪些文件或命令输出。

错误信息：
<粘贴日志>

这句话会让 Codex 先进入诊断模式，而不是直接编辑模式。

如果 bug 可以在本地复现，要求 Codex 给出复现步骤：

请先找出最小复现方式。
如果需要运行命令，请说明命令目的。
不要做任何修复，直到复现路径确认。

复现是调试的核心。如果问题无法稳定触发，至少要收集日志、请求参数、环境差异和最近改动。

复杂 bug 往往不是出在报错那一行，而是坏数据从更早的地方传进来。可以这样问：

请从报错位置向上追踪：
1. 这个值从哪里来；
2. 哪一层第一次变成异常值；
3. 哪个组件最可能是根因。

这比“改掉报错”更可靠。

让 Codex 明确说出假设：

请给出一个最可能的根因假设，并说明为什么。
然后只做能验证这个假设的最小修改。

如果这次修改没有解决问题，就回到诊断，不要叠加第二个、第三个猜测。

让 Codex 做三件事：

修复后请：
1. 重新运行最小复现步骤；
2. 运行相关测试；
3. 说明为什么这个修复解决的是根因，而不是只绕过症状。

不要只给一句“报错了”。至少粘贴错误信息、复现动作、最近改动。

不要把日志截图发给 Codex 后不提供文字。可复制的日志更容易定位。

不要允许大范围重构来修小 bug。除非根因就是架构问题，否则先做最小修复。