修 Bug 是最常见的 Codex 使用场景。
> 前置教程：修 Bug 任务模板
> 如果你还不知道 Bug 任务应该包含哪些信息，先完成前置教程。
> 依据来源：OpenAI Codex 官方手册中的提示词、代码审查、验证、沙箱和任务边界建议。
适合这些情况：
- 页面有明显异常。
- 你能描述复现步骤。
- 你知道期望结果。
- 你希望 Codex 先分析再修复。
不适合：
- 只说“页面坏了”。
- 没有复现步骤。
- 不知道什么才算修好。
- 想让 Codex 顺手重构整个页面。
第 1 步：发出修复任务
假设问题是：
``
移动端打开首页时，顶部按钮文字溢出，遮住了右侧图标。
`
你要告诉 Codex：
- 在什么页面。
- 什么设备或宽度。
- 怎么复现。
- 现在看到什么。
- 应该看到什么。
- 哪些文件可以改。
- 哪些文件不能改。
复制这个模板：
`
请帮我修复一个前端 Bug。
现象：
【描述你现在看到的问题】
复现步骤：
- 打开【页面路径】
- 请先分析原因，不要马上修改。
- 打开首页 /
- 请先分析原因，不要马上修改。
- 你认为最可能的原因是什么。
- 它有没有找到正确文件。
- 它有没有把原因说具体。
- 它有没有扩大范围。
- 它有没有提出可验收方案。
- 列出修改文件。
- 复现步骤里的问题消失了。
- 桌面端没有被破坏。
- 其他导航项仍然可点击。
- 没有新的文字溢出。
- Bug 原因。
- Bug 可复现描述。
- Codex 的原因分析。
- 最小范围修复。
- 修改后截图。
- 验证结果。
- 可用于提交的总结。
2. 使用【浏览器/设备/宽度】
3. 执行【具体操作】
4. 看到【错误现象】
期望结果：
【修好后应该是什么样】
限制：
2. 只修改和这个 Bug 直接相关的文件。
3. 不要重构无关代码。
4. 不要引入新依赖。
5. 修改后请说明如何验证。
`
示例：
`
请帮我修复一个前端 Bug。
现象：
移动端打开首页时，顶部“进入文档”按钮文字溢出，遮住了右侧区域。
复现步骤：
2. 把浏览器宽度调到 390px
3. 查看顶部导航
4. 看到按钮文字挤出容器
期望结果：
移动端顶部导航不出现文字溢出；如果空间不足，可以隐藏按钮或调整布局。
限制：
2. 只修改首页或导航相关样式。
3. 不要重构整个导航组件。
4. 不要引入新依赖。
5. 修改后请说明如何验证。
`
第 2 步：要求 Codex 先分析
如果 Codex 直接动手，你可以要求它先停一下：
`
先不要修改。
请先告诉我：
2. 需要查看哪些文件。
3. 最小修复范围是什么。
4. 修复后应该怎么验收。
`
分析阶段你要关注：
第 3 步：开始最小修复
确认分析靠谱后，再说：
`
可以按最小修复方案修改。
请只修复这个 Bug，不要顺手优化其他样式。
完成后请总结 diff 和验证方式。
`
不要让 Codex 一边修 Bug 一边美化页面、一边重构组件。
一个任务只解决一个问题。
第 4 步：让 Codex 自查 diff
修完后问：
`
请检查本次修改是否超出 Bug 修复范围。
要求：
2. 说明每个文件为什么需要修改。
3. 判断是否有无关格式化或无关重构。
4. 判断是否引入新依赖。
`
如果它改了太多：
`
请把本次修复收窄，只保留解决移动端溢出的必要修改。
撤回无关重构和无关样式调整。
`
第 5 步：截图验证
前端 Bug 必须看页面。
至少验证：
如果 Bug 没修好，把截图继续发给 Codex：
`
Bug 还没有完全修好。
新截图说明：
【描述截图里的问题】
请继续修复，但仍然只修改和这个 Bug 直接相关的文件。
不要扩大范围。
`
第 6 步：交付总结
最后让 Codex 输出交付总结：
`
请给出本次 Bug 修复总结：
2. 修改文件。
3. 修复方式。
4. 验证结果。
5. 剩余风险。
``
这份总结可以直接放到你的提交说明或项目记录里。
完成后，你应该得到：
下一篇看：常见任务实战：让 Codex 排查构建失败。