这段时间，Codex 促销力度空前，额度重置一个接着一个。我从每天盘算着额度够不够用，变成了每天盘算着额度怎么才能花完。
毕竟今天额度用少了，明天再一重置可就亏了。更何况自己还有一张重置卡快过期了。
如果你也面临着和我一样的问题，在寻找一种任务，能够以简单的 Prompt 自动运行，不需要自己过多干预，就能花掉额度，做一些有用的工作，那么不妨学习一下我的思路：让 Sol Ultra 自动修复项目里的 bug。
自动修复 bug 思路
模型配置
先说模型配置：
- Codex app
- 模型：5.6 Sol Ultra
- 开启 Goal 模式
Sol 是 GPT 5.6 系列最贵的模型，Ultra 不仅有最强的推理强度，还会尽可能开启多 Agent，解决复杂问题。
Codex app 是为了使用 Chrome 插件来操控浏览器，这是自动修复 bug 最有用的武器。接下来会介绍如何使用
开启 Goal 模式是为了防止任务中断，因为我都是挂机一整晚的。不过 Sol Ultra 本身完成任务的意愿极强，Goal 只是双保险。
当然，为了让 Codex 能够自动发现、分析和修复问题，还需要一些 Prompt 技巧
如何挖掘隐藏的 bug
以用户视角，从浏览器入口探索项目各个功能，挖掘潜藏的的 bug，并修复。
从不明显的、常规人工验证不容易发现的场景入手，提升挖掘 bug 的可能性。例如：
- 看浏览器 F12 中的报错请求、重复请求
- 看服务日志中的报错
- 看一些不起眼的 UI 或者边界情况
在探索过程中多考虑不同功能场景间交叉的、可能相互影响的 case，这其中更可能潜藏着复杂的问题。技巧一：以用户视角，从浏览器入口探索
很多自动化测试都是从 API 入口开始的，这样适合确定性的程序化的调用。但是我们既然不缺钱（Token 够用）、不缺时间（挂机跑一夜），那么不妨从浏览器入口，不仅可以让 Agent 更自由地进行探索，还能贴近真实的使用场景（发现真正的 bug）。
能够这么探索需要归功于 Codex 的强大的 Chrome 插件，可以方便地操控浏览器，并且复用浏览器中我的登录状态。
技巧二：考虑边界场景、交叉场景
产品主链路、常见的场景，因为平时人经常使用，不太容易出现问题。真正容易出问题的往往是人用得比较少的或者注意不到的场景。所以我特地引导 Agent 向这个方向探索。这样才容易发现大 bug，而不是鸡毛蒜皮的小 bug。
在 Codex 运行过程中，我还发现它一开始的策略比较保守，只是一个模块一个模块地进行分析，于是我特地加上了「交叉场景」的提示。毕竟，多个场景间的交叉影响，平时使用到的可能性更小，更容易发现潜藏的 bug。
如何修复 bug
我使用的策略是让 Codex 现场发现 bug，现场修复。
有些人可能会觉得，发现 bug 和修复 bug 可以分开来，先让 Agent 探索发现一批 bug，记录成 issue。后续再让另一个 Agent 根据 issue 修复。
但是这种方法有一个巨大的缺陷：你如何判断发现 bug 的 Agent 和修复 bug 的 Agent 思路是一致的？如何保证修复 bug 不会引入新的问题？
这相信是很多人最大的痛点：我只想用一条 Prompt 让 Agent 帮我花点额度，把项目代码变得更好一点，如果让我花时间去一个个人工分析 bug，那显然是做不到的。
所以我的思路是：
- 让 Agent 对「修复方案确定性」打个分，只有分数在 80% 以上才自动修复。这样可以跳过一些架构决策、产品设计上的问题，避免 Agent 对项目做大型改动，导致失控
- 当场发现问题当场修复问题，这样思路是最连贯的
- 要求 Agent 在修复问题之后立即用复现问题的路径重跑一遍，当场验证修复效果。避免 Agent 产生幻觉，「以为自己已经修复了问题」
一套组合拳下来，加上 5.6 Sol 的实力，基本上可以相信 Agent 自动修复的结果，不需要做很多人工检查了。
总结
我在一个项目上跑了 13 个小时左右，Sol Ultra 工作尽心尽力，开启了巨量的 Subagents，一共修复了 48 个 bug。
这个数字已经大大超出我的预期了，大部分的 bug 都是实际的问题，而不是错别字、文案这种小问题。更何况，我花费的只是一些 Codex 额度而已（而这些额度如果不用的话就过期浪费了）。
因为额度用不完而发愁的朋友，也可以试着跑一跑。
附：Prompt 全文
## 目标
以用户视角，从浏览器入口探索项目各个功能，挖掘潜藏的的 bug，并修复。
## 如何挖掘潜藏的 bug
从不明显的、常规人工验证不容易发现的场景入手，提升挖掘 bug 的可能性。例如：
- 看浏览器 F12 中的报错请求、重复请求
- 看服务日志中的报错
- 看一些不起眼的 UI 或者边界情况
在探索过程中多考虑不同功能场景间交叉的、可能相互影响的 case，这其中更可能潜藏着复杂的问题。
## 如何探索
在本地启动服务，并操作浏览器验证。
主要的探索方式应该是阅读代码 + 浏览器操作。
允许的操作：
- 浏览器操控
- 查询日志、数据库记录
不允许的操作：
- 删除或修改数据库数据
- 直接调用 API 构造测试场景（所有的 bug 必须是能通过浏览器操作复现出来的）
## 修复方式
发现 bug 后立即修复，必须通过相同的复现路径回归测试，验证修复效果。
用 bugs.md 记录 bug 发现、bug 修复过程
对发现的 bug 进行修复方案确定性打分，如果确定性低于 80%，则不修复，移动到 open-bugs.md，只记录复现路径、预期结果、实际结果。无论 bug 是否修复，都记录每个 bug 的修复方案确定性分数。
## 停止条件
满足以下之一：
- 时间超过 10 小时
- 已完成一轮你所计划的探索，并修复所有 bug