“页面偶尔打不开”不是可修复的问题描述。它缺少触发条件、期望结果和失败证据。Codex 在这种模糊输入下很容易写出看似合理、却无法验证的补丁。先把现象压缩成一次稳定复现，修复才有终点。
问题单至少写五项
- 环境：版本、分支、账号或数据条件；
- 步骤：从什么操作开始，到哪里出现失败；
- 期望与实际：用户本该看到什么，实际发生什么；
- 证据：报错、日志、截图或失败测试；
- 范围：目前确认受影响的功能和未确认的猜测。
让 Codex 先缩小，不要先修
先让它根据证据列出可能路径，并设计能区分这些路径的最小检查。确认根因后，再要求仅修改必要文件、补一条能先失败后通过的测试。修复完成后，除了重跑失败场景，还要检查相邻流程。
根据以下复现步骤和日志：
1. 列出三个最可能的代码路径；
2. 为每条路径设计最小验证；
3. 未确认根因前不要修改；
4. 根因确认后提出最小补丁与回归清单。修复的质量不在于改得快，而在于你能证明：旧问题消失了，邻近功能没有被带坏。
