本文作者：sitin（@sitinme）。版权归作者所有，未经授权禁止转载。
最近不停在上一些小功能，就需要验收。
验收时有几个麻烦点。它涉及登录态、数据、扣费、历史记录等。只看代码或者只跑单元测试都不够，最后一定要有人在真实环境里过一遍完整流程。
推荐一个很丝滑的协作方式：依旧 Claude Code 负责写代码、实现功能，最后把需要验证的测试用例整理清楚；Codex 接过测试用例，用 Chrome 插件控制浏览器，直接在已有登录态里做端到端验收。
为什么适合交给 Codex 验收
以前做这种验收，最烦的地方不是点击按钮，而是中间要不断判断状态。
比如页面上的入口有没有出现，弹窗或表单里的数据能不能正常选择，选择后的状态有没有回填，点击提交以后有没有前端校验错误，异步任务最终有没有结果，余额有没有变化，历史记录有没有新增。
这些事情连在一起就很容易漏。验收过程里还要截图、记录余额、记录错误文案，最好能把每一步结论都留下。
Codex 做这类任务有一个很舒服的点：它可以按测试用例一步一步执行，同时把过程可视化地反馈出来。哪一步通过了，哪一步有问题，它会直接标出来。需要证据时，它也会把截图保存下来。
这张图里能看到，A 到 H 每个断言都有状态。有些通过，有些失败，有些因为预算或条件跳过。对我来说，这比口头说"我测过了"可靠很多，因为它保留了过程。
Chrome 登录态是一个很实用的优势
Codex 通过 Chrome 插件接管浏览器。
普通 Playwright 测试也可以处理登录态。Playwright 官方文档里就推荐用storageState 保存认证状态，后续测试可以复用这个状态文件。
不过这通常意味着你要维护测试账号、登录脚本、状态文件，还要处理状态过期和环境隔离。
在研发阶段的人工终验里，我更需要的是另一种能力：直接用我当前 Chrome 里已经登录好的账号，接管现有页面，继续往下操作。
这对很多真实产品场景很方便。比如后台权限已经配置好，账号已经在某个分组里，或者页面状态和环境刚刚调好。让 Codex 直接接管这个浏览器，会比重新写一套登录和准备脚本省很多时间。
当然，这不代表它可以替代 CI 里的 Playwright。我的理解是，两者适合不同阶段。
CI 里的 Playwright 更适合稳定、可重复、批量跑的回归测试；Codex 接管 Chrome 更适合上线前后的人肉终验、一次性排查、扣费路径、复杂后台状态验证。
测试用例越具体，Codex 执行越稳
这次让我感受最明显的一点是，测试用例要写得足够具体。
不要只写"测试这个功能是否可用"，这句话太宽了。更好的写法是把每一步拆清楚：打开哪个 URL，点击哪个入口，选择什么测试数据，表单里填什么，参数选哪个档位，提交后不要重复点击，最多等几分钟，失败时要记录哪些信息。
当流程写清楚以后，Codex 执行起来就很像一个耐心的验收同事。它不会只看页面有没有报错，而是会按断言逐项收集证据。
在一次带扣费的异步任务验收里，它会先记录初始余额，按测试用例选择素材和参数，确认页面预估费用，提交后检查有没有前端校验错误，再等待任务结果。任务完成后，它还会回到 dashboard 和 history 页确认扣费与产物记录。
最后的报告里，它不仅说"通过了"，还列出了每张截图证据：初始状态、关键输入已选中、提交前参数、提交后生成中、成功结果、最终历史记录。以后有人要追查这个功能是否真的验过，直接看这些证据就行。
这类验收应该怎么分工
Claude Code 更适合放在实现阶段。它读代码、改代码、补测试、整理变更点都很顺手。实现完以后，让它顺便写一份验收 runbook，把关键路径、边界条件、预算和失败取证步骤讲清楚。
Codex 更适合放在验收阶段。尤其是需要真实浏览器、真实登录态、真实环境、真实产物的时候，它可以像人一样操作页面，又比人更稳定地记录每一步。
中间最重要的交接物不是代码，是一份清楚的测试用例。里面最好包含这些信息：测试环境、账号或登录方式、初始状态、每一步操作、每一步断言、预算、失败时需要保留什么证据、哪些动作明确不要做。
一个可复用的小结论
AI Agent 写代码已经很常见了，但我觉得更值得长期复用的，是把它们放进研发流程里的不同位置。实现功能是一件事，验证功能又是另一件事。这次的体验让我觉得，端到端验收很适合交给 Codex 这类能控制浏览器、能保留上下文、能截图取证的 Agent。前提是测试用例要写清楚，尤其是涉及登录态、扣费、权限、历史数据和异步任务的路径。推荐这种模式。
欢迎关注，这个账号还会持续分享更多AI编程、出海工具、实战经验、踩坑记录。
想了解更多可以加我 vx: 257735 聊。
