Codex + GPT-5.5：从“写代码”到“会操作网页”的升级玩法
你有没有遇到过这种烦：
- 产品让你“顺手测一下登录流程”，你一测就是半小时。
- QA 要你复现一个“偶发”问题，你一边点网页一边截图写报告。
- 运营丢来一堆素材，让你“整理成文档”，复制粘贴到手麻。
如果你的 Codex 已经支持更强的模型能力，并且开放了“浏览器/文件/文档/电脑操作”这类工具权限，那它就不止会写代码了。 它更像一个会动手的助手：能在 Web 应用里交互、按步骤测试、截图、看结果，再继续改策略直到任务完成。
下面直接上可执行的方法。咱们把它当成一个“能看屏幕、能点鼠标、能读写文件”的队友来用。😄
你能让它做什么（把能力说清楚，才好下指令）
1）在浏览器里“像人一样”操作 Web 应用
适合这些场景：
- 点按钮、填表单、切 Tab、滚动页面
- 跑一条完整流程：注册 → 登录 → 下单 → 支付页停住
- 抓页面关键信息：提示文案、错误码、表格数据
- 自动截图：每一步留证据，方便写测试记录
2）基于“看到的页面结果”继续迭代
这点很关键。 它不是只执行一次脚本就完事，而是：
- 做完一步 → 看页面变成啥样
- 发现不对 → 换路径/换入口/换关键词
- 直到达到目标
你可以把它理解成“自带复盘的执行者”。
3）文件 + 文档闭环
常见用法：
- 读取项目文件、日志、截图
- 生成测试报告 Markdown/Word 风格内容
- 把页面抓取结果整理成表格/清单
- 批量改配置、改文案、补注释
开始前的准备：别急着让它跑，先把权限和边界讲明白
你要做的不是“给它一个愿望”，而是“给它一张任务单”。
建议你在任务开头固定加三件事：
- 允许使用的工具范围：浏览器、文件、截图、终端（以你实际界面为准）
- 不能碰的东西：线上生产账号、真实支付、删除文件
- 输出物：截图、步骤日志、最终报告
你会发现它的稳定性会上一个台阶。
实战 1：让 Codex 帮你跑一条 Web 测试流程（带截图 + 报告）
适用场景
你刚改完登录页，想确认：
- 输入错误密码时提示文案对不对
- 验证码出现时会不会卡住
- 登录成功后跳转是否正常
推荐提示词（可直接复制）
目标：测试 Web 应用登录流程，并生成带截图编号的测试记录。
约束：不要进行真实支付/不要改线上数据；只用测试账号；遇到异常先截图再继续。
步骤：
- 打开网址：{你的测试环境 URL}
- 依次覆盖 3 种情况：
- 正确账号+正确密码
- 正确账号+错误密码
- 空密码点击登录
- 每个关键页面都截图，命名规则：login_01、login_02…
- 输出一个 Markdown 报告：包含执行步骤、预期结果、实际结果、截图引用、结论。
备注：如果页面元素不好定位，优先用“看得到的文案/按钮文字”来点击，不要猜 DOM。
你会拿到什么结果
- 一组按顺序命名的截图
- 一份可直接丢给 QA/产品的 Markdown 测试记录
这类任务最爽的点：它会边做边看页面反馈。页面跳转慢、弹窗挡住、按钮文案变了，它会尝试绕过去，而不是傻等。
实战 2：让它“边浏览边修正”，直到把任务做完
适用场景
你要在后台找到某个配置项，但入口藏得深：
- 菜单层级多
- 同名按钮多
- 页面会根据权限显示不同内容
这时候别用“去点 A、再点 B”这种死指令。 用“观察 → 判断 → 调整”的写法更稳。
推荐提示词
你现在在浏览器里帮我找到“API 回调地址配置”页面。
工作方式：
- 每走到一个新页面，先用一句话描述你看到的关键区域（菜单、标题、按钮）。
- 如果找不到入口，尝试 2 条备选路径（比如：系统设置/开发者设置/安全设置）。
- 每次改路径前先截图留证据。
输出：给我最终入口路径（例如：设置 → 开发者 → 回调地址），并截图标注该配置项所在区域。
这类提示词的潜台词是：允许它试错。 你不是让它一次命中，而是让它“像人一样”在后台里摸路。
实战 3：文件 + 文档联动：把一堆截图和记录变成可交付的报告
适用场景
你已经跑完流程，手上有：
- 多张截图
- 一些零散的现象描述
- 可能还有控制台日志/网络请求片段
你要的是一份“能交差、能复盘、能追责”的报告。
推荐提示词
我有一批截图和日志文件，请你做一份《登录流程测试报告》。
要求：
- 报告结构固定：背景/环境信息/用例列表/异常汇总/复现步骤/建议
- 每条异常必须引用截图编号或日志片段
- 建议要落到“下一步做什么”：要改哪个页面文案、要加哪个校验、要补哪个埋点
输出格式：Markdown，方便我直接发到飞书/Notion。
这个套路特别适合“你只想早点下班”的夜晚。🫠
写提示词的 5 个小技巧（让它少走弯路）
- 给清楚的完成标准：比如“找到配置项并给出入口路径 + 截图标注”，别只说“帮我看看”。
- 把风险写进约束：不要真实支付、不要删文件、不要改线上数据。
- 要求它每步做记录：让它输出步骤日志，你排查会轻松很多。
- 让它优先用可见文案操作：按钮文字、页面标题通常比 DOM 更可靠。
- 设定失败策略：找不到就尝试两条备选路径，卡住就截图并说明卡点。
避坑清单（踩过一次就够了）
- 页面加载慢导致误判：让它“等待页面稳定/关键元素出现后再操作”，并要求超时策略。
- 弹窗/新标签页打断流程：在提示词里写明“遇到弹窗先关闭或截图记录；新开标签页要切回”。
- 测试账号权限不够：让它在报告里标出“疑似权限问题”的证据（页面提示、按钮不可点）。
- 截图太多不好管理：统一命名规则 + 只截关键节点（入口、提交前、提交后、报错）。
- 把探索当成执行：探索任务要允许试错；执行任务要严格按步骤。两者别混。
一套通用工作流：从“需求一句话”到“交付一份报告”
你下次接到这种活，可以照这个节奏走：
- 用一句话写清目标（要测什么/要找什么/要产出什么）
- 写约束（别碰什么、用什么账号、能不能改数据）
- 让它执行并截图留证
- 让它基于截图/页面现象继续迭代，直到完成
- 让它把过程整理成 Markdown 报告
顺嘴吐槽一句
有人说什么“CloseAI”之类的梗，图个乐就行。 真正重要的是：你能不能把这套能力用在每天的碎活里，少点几百次鼠标，少写几页重复报告。
你要是愿意，把你准备测试的页面类型（登录/表单/支付前页/后台配置）和你希望的报告结构发我，我可以给你一份更贴合场景的提示词模板。
