常见任务实战：让 Codex 修复前端 Bug

修 Bug 是最常见的 Codex 使用场景。

前置教程：修 Bug 任务模板
如果你还不知道 Bug 任务应该包含哪些信息，先完成前置教程。

依据来源：OpenAI Codex 官方手册中的提示词、代码审查、验证、沙箱和任务边界建议。

这个案例适合谁

适合这些情况：

页面有明显异常。
你能描述复现步骤。
你知道期望结果。
你希望 Codex 先分析再修复。

不适合：

只说“页面坏了”。
没有复现步骤。
不知道什么才算修好。
想让 Codex 顺手重构整个页面。

Bug 示例

假设问题是：

移动端打开首页时，顶部按钮文字溢出，遮住了右侧图标。

你要告诉 Codex：

在什么页面。
什么设备或宽度。
怎么复现。
现在看到什么。
应该看到什么。
哪些文件可以改。
哪些文件不能改。

第 1 步：先写清楚 Bug

复制这个模板：

请帮我修复一个前端 Bug。

现象：
【描述你现在看到的问题】

复现步骤：
1. 打开【页面路径】
2. 使用【浏览器/设备/宽度】
3. 执行【具体操作】
4. 看到【错误现象】

期望结果：
【修好后应该是什么样】

限制：
1. 请先分析原因，不要马上修改。
2. 只修改和这个 Bug 直接相关的文件。
3. 不要重构无关代码。
4. 不要引入新依赖。
5. 修改后请说明如何验证。

示例：

请帮我修复一个前端 Bug。

现象：
移动端打开首页时，顶部“进入文档”按钮文字溢出，遮住了右侧区域。

复现步骤：
1. 打开首页 `/`
2. 把浏览器宽度调到 390px
3. 查看顶部导航
4. 看到按钮文字挤出容器

期望结果：
移动端顶部导航不出现文字溢出；如果空间不足，可以隐藏按钮或调整布局。

限制：
1. 请先分析原因，不要马上修改。
2. 只修改首页或导航相关样式。
3. 不要重构整个导航组件。
4. 不要引入新依赖。
5. 修改后请说明如何验证。

第 2 步：要求 Codex 先分析

如果 Codex 直接动手，你可以要求它先停一下：

先不要修改。
请先告诉我：
1. 你认为最可能的原因是什么。
2. 需要查看哪些文件。
3. 最小修复范围是什么。
4. 修复后应该怎么验收。

分析阶段你要关注：

它有没有找到正确文件。
它有没有把原因说具体。
它有没有扩大范围。
它有没有提出可验收方案。

第 3 步：批准最小修复

确认分析靠谱后，再说：

可以按最小修复方案修改。
请只修复这个 Bug，不要顺手优化其他样式。
完成后请总结 diff 和验证方式。

不要让 Codex 一边修 Bug 一边美化页面、一边重构组件。

一个任务只解决一个问题。

第 4 步：看修改是否超范围

修完后问：

请检查本次修改是否超出 Bug 修复范围。

要求：
1. 列出修改文件。
2. 说明每个文件为什么需要修改。
3. 判断是否有无关格式化或无关重构。
4. 判断是否引入新依赖。

如果它改了太多：

请把本次修复收窄，只保留解决移动端溢出的必要修改。
撤回无关重构和无关样式调整。

第 5 步：验收 Bug

前端 Bug 必须看页面。

至少验证：

复现步骤里的问题消失了。
桌面端没有被破坏。
其他导航项仍然可点击。
没有新的文字溢出。

如果 Bug 没修好，把截图继续发给 Codex：

Bug 还没有完全修好。

新截图说明：
【描述截图里的问题】

请继续修复，但仍然只修改和这个 Bug 直接相关的文件。
不要扩大范围。

第 6 步：让 Codex 总结

最后让 Codex 输出交付总结：

请给出本次 Bug 修复总结：
1. Bug 原因。
2. 修改文件。
3. 修复方式。
4. 验证结果。
5. 剩余风险。

这份总结可以直接放到你的提交说明或项目记录里。

本案例验收

完成后，你应该得到：

Bug 可复现描述。
Codex 的原因分析。
最小范围修复。
修改后截图。
验证结果。
可用于提交的总结。

下一篇看：常见任务实战：让 Codex 排查构建失败。