如何用 Codex 修复 Bug：从复现到验证

用 Codex 修 Bug，最重要的不是让它“猜原因”，而是让它先复现、再定位、再做最小修改。很多 Bug 不是代码一眼看错，而是来自环境、数据、权限、路由、样式或缓存。你给 Codex 的信息越接近真实问题，它越能做出稳妥修复。

一个可靠的 Bug 修复流程包括：问题描述、复现步骤、实际结果、期望结果、错误日志、受影响范围和验证方式。Codex 可以帮你执行这些步骤，但你需要提供方向和边界。

适合谁阅读

• 网站出现报错但不知道从哪里查的站长
• 想用 AI 提高 Debug 效率的开发者
• 需要修复按钮、表单、页面渲染或构建错误的小团队
• 想减少外包沟通成本的创业者
• 正在学习系统化排错的新手程序员

Codex 可以做什么

• 根据错误日志和截图搜索相关代码位置
• 分析报错栈、构建失败、类型错误或浏览器控制台错误
• 提出可能原因，并验证最可能的一项
• 做最小范围修复，避免顺手重构无关代码
• 运行测试、构建或手动检查来确认问题是否解决

实际操作步骤

1. 写清楚 Bug 发生在哪个页面、哪个按钮、哪个设备或哪个环境。
2. 提供复现步骤：先打开什么、点击什么、输入什么、看到什么。
3. 贴出错误日志、截图或终端输出，不要只说“不能用”。
4. 要求 Codex 先定位相关文件和可能原因，不要马上大改。
5. 让它做最小修复，并说明为什么这个修复能解决问题。
6. 要求它运行验证：测试、构建、页面访问或人工检查清单。

示例 Prompt

目标：请帮我修复文章页 FAQ 标题不显示的问题。
复现步骤：打开 /codex-tutorial/what-is-openai-codex，滚动到 FAQ 区块，只有答案但没有 H3 标题。
期望结果：FAQ 问题以 H3 显示，答案以段落显示。
限制：只修改 Markdown 渲染相关代码，不要重写文章系统。
完成标准：该页面和其他文章页都能正常渲染，build 通过。
验证：请检查 renderer 文件并运行 typecheck。

实战说明

先复现，避免修错问题

如果 Codex 没有复现路径，它可能会根据表面现象修错地方。比如“按钮不能点”可能是 CSS 覆盖、链接为空、事件没绑定、移动端遮挡或外部服务跳转失败。复现步骤能让它把问题范围缩小。

要求最小修改

Debug 时最怕把小问题修成大改动。你可以明确要求 Codex 不做无关重构、不新增依赖、不改 UI 风格。它应该只改导致 Bug 的关键位置，并解释副作用。

验证要对应问题类型

构建错误适合运行 build；类型错误适合运行 typecheck；按钮问题需要浏览器点击；链接问题要检查 href 和跳转；内容显示问题要打开页面看渲染。不同 Bug 需要不同验证。

注意事项

• 不要只给一句“网站坏了”，要给复现步骤和错误信息。
• 不要接受没有验证的“应该修好了”。
• 如果涉及线上用户数据，先在测试环境或本地复现。
• 修复后要检查是否影响相邻页面或相同组件的其他使用场景。
• 复杂 Bug 可以先让 Codex 写调查报告，再决定修改。

内部链接建议

• 用 Codex 做代码审查
• 用 Codex 补测试
• Codex 权限、安全与沙盒
• AI 自动化工具

FAQ

Codex 修 Bug 会不会改坏其他地方？

有可能，所以要要求最小修改、查看 diff，并运行相关测试或构建检查。

没有错误日志可以修吗？

可以尝试，但效率较低。最好提供截图、复现步骤和期望结果。

Bug 修复后一定要写测试吗？

关键流程建议补测试。小文案或样式问题可以用页面检查代替。

Codex 找不到原因怎么办？

让它先列出已排除项、还需要的日志和下一步调查方向，不要继续盲改。

总结

用 Codex 修 Bug 的正确顺序是：描述现象、复现问题、定位原因、最小修改、运行验证。只要你坚持这个流程，AI Debug 会比单纯问答可靠很多。

如果你想学习更多 AI 工具、AI 自动化和 Codex 实战教学，欢迎持续关注 ai.no1.my。