Codex 怎么修现有项目的 Bug？从复现到浏览器验收的完整示例
让 Codex 修现有项目的 Bug，最好从一个可重复的错误开始：交代在哪个页面、怎样操作、实际出现什么、应该出现什么，再让它读取项目、定位原因、修改并重跑同一路径。Codex 可以在项目环境中处理代码和工具操作，能做哪些检查取决于你提供的运行环境。Codex 官方文档
下面用“删除最后一条订单后，列表停在空白页”举例。这是可套用到自己项目的练习场景，订单状态和接口名称需要换成你的实际实现。
给出足以复现的输入
假设列表每页显示 20 条记录，当前筛选条件下有 21 条。进入第二页，删除唯一一条记录，页面仍停在第二页。此时第一页还有 20 条，用户却看到了空列表。
先记下筛选条件、当前页码、删除结果和刷新后的现象。如果错误只在某个角色下出现，也把角色写清楚。账号、令牌和客户信息不必粘贴进任务，使用本地测试数据即可。
订单列表每页 20 条，筛选后共有 21 条。
在第二页删除唯一一条记录后，列表显示空白，第一页仍有数据。
期望删除成功后跳到有效页，并重新加载列表。
请先确认当前分支和未提交改动，阅读项目运行说明。
复现问题，再检查删除、总条数、页码及刷新之间的关系。
沿用已有组件和接口，不重写整个列表。本轮不提交或部署。
这时不急着要求它“把页码减一”。页面状态可能在 URL 中，也可能由列表组件或请求缓存管理。提前猜一个修法，容易修好眼前数据，却破坏筛选切换后的行为。
先建立一条能看出错误的检查路径
可以是浏览器操作，也可以是已有测试里的一组数据：先建立 21 条记录，进入第二页，删除末行，再确认当前页和展示内容。重要的是检查真的走到出问题的删除逻辑，而非另写一个与页面无关的分页公式。
如果只有接口日志，先看删除是否成功、列表请求有没有再次发出、第二次请求仍传了哪个页码。三处证据连起来，通常就能分清是删除失败、没有刷新，还是页码已经越界。暂时无法复现时，先缩小触发条件，别让 Agent 同时改三个猜测。
这一阶段适合参考 mattpocock 的 diagnosing-bugs：建立可执行的复现，再逐项检验原因。作者当前调试说明
修改后，检查相邻行为
修复应该跟随项目已有的状态来源。例如服务端返回了新的总数，就据此判断当前页是否有效；不能在前端猜删除一定成功，也不能让页码和地址栏各维护一套不同值。
最少检查下面几种情况：
| 操作 | 要看到的结果 |
|---|---|
| 删除第二页唯一记录 | 回到有效页，列表重新加载 |
| 删除普通页中的一条 | 留在当前有效页 |
| 删除全部数据中的最后一条 | 显示正常空状态，不出现第 0 页 |
| 删除接口报错 | 保留原列表，并显示失败反馈 |
| 删除后切换筛选 | 页码遵循现有筛选规则 |
如果项目有自动化测试，就把这次导致错误的路径保留下来。断言应检查用户能观察到的页码和列表结果，而不是要求某个内部函数必须调用一次。将来调整实现方式时，正确行为仍然能受到约束。
让交付说明能直接用于审查
一份实用的结果说明，应当讲清根因、涉及文件、实际运行的检查，以及本地页面在哪里。没有跑到的浏览器或外部接口就写明缺口。依赖安装成功、构建成功，都不能单独证明删除后的交互已经正确。
项目启动命令、时区和组件约定可以留在现有项目说明中；这次复现数据和修改原因放进相关问题记录。下次出现类似问题，就不用重新解释整个项目。
如果你还在选择调试和实现技能，可以接着看 mattpocock skills 的场景分工。修改完成后的审查方法见 TDD 与 code-review 怎么配合。作者的 日常 Agent Skills 视频与文章也适合了解工作思路。
日常开发需要持续使用 ChatGPT 与 Codex，可按实际用量查看 已有账号的 ChatGPT 订阅服务。