Vibe Coding 原型交付后：用浏览器智能体做一次可回放验收

把 Vibe Coding 想成一块能快速搭好的样板间：你描述页面和交互，代码很快就能跑起来。它适合前端、后端、运维和 Web Coding 开发者在当天验证想法。真正交付前，最容易被低估的是验收：每次改动都要重新打开页面、提交测试数据、核对状态、截图，再把“哪里通过、哪里失败”讲给同事听。本文用一个脱敏的浏览器验收台演示最小做法：只给智能体测试页面、截图和日志权限，跑完一张四步任务卡；提交、合并、发布和删除仍停在人手里的确认点。

Vibe Coding 已经能生成页面，为什么还需要智能体？

Vibe Coding 解决的是“从自然语言想到能看的原型”。你可以让它生成表单、接口样例和状态切换，很快知道方向是否值得继续。它的默认单位是一段对话或一次代码修改，结果通常需要开发者自己重新点一遍。

智能体解决的是“把一次任务做完并留下证据”。它会先拆分任务，再在授权范围内调用浏览器或测试工具，执行断言，保存截图和失败原因，最后把需要决定的事项交给人。两者不是替代关系：原型让想法可见，智能体让验收过程可重复、可追溯。

最近 30 天的官方资料里，OpenAI Agents SDK 0.22.0 持续强调工具调用、运行状态和可恢复执行；GitHub Copilot 的入门工作流把“进行中、已完成、下一步”放在同一视图。它们都说明智能体的增量不只是更长的提示词，而是任务状态和工具边界。最近 90 天的 Playwright 1.62.1 发布也表明浏览器自动化仍有稳定维护。这里的事实只代表官方发布页描述，不代表本文演示的生产性能。

一个熟悉场景：页面能打开，验收却总要重复做

假设你刚用 Vibe Coding 做出一个订单确认页。页面能打开，按钮也能点击，但每次改动后仍要人工完成四件事：打开页面、提交测试订单、核对“待确认”和“库存不足”等分支、整理截图。手动做一次并不难，难的是每次都要重新复述步骤，失败时还要回忆当时的输入。

这正适合第一个低风险智能体任务。先选测试数据隔离、能够回滚的页面；再写清成功条件和失败条件；最后规定什么动作必须停下来等人确认。不要一上来就让智能体修改业务代码或点击发布按钮。

最小工作流应该拆成哪几步？

我把演示拆成四步，每一步都有输入、动作和可检查的结果：

1. 打开隔离页面并记录版本：记录页面地址、前端构建标识和开始时间，避免“看的是哪一版”说不清。
2. 2. 提交一条测试订单：只使用演示数据，不读取真实客户信息，不写入真实业务系统。
3. 3. 核对状态与失败提示：断言状态文案、错误分支和按钮是否符合任务卡；发现差异就保留原始证据，不擅自修改页面。
4. 4. 生成验收记录：把步骤、截图、日志和待确认事项放在同一个结果里，供开发者复核或回放。
      

这四步就是“从提示词到可控工作流”的最小闭环。任务拆分让智能体知道先后顺序，工具范围让它知道能做什么，断言让“看起来没问题”变成可检查条件，记录让下一次排查不必从聊天历史里找线索。

工具权限怎样设，才能让验收有用又不越界？

权限设计可以从只读开始，按下面的清单逐项开放：

• 可以读取：测试页面、脱敏截图、浏览器控制台日志和本次任务的配置文件。
• • 可以执行：打开页面、填写演示表单、点击测试按钮、运行只读断言和保存截图。
• • 明确禁止：生产数据写入、账号设置、合并代码、发布、删除和扩大权限。
• • 必须人工确认：任何会改变共享环境的动作，任何无法解释的异常结果，以及任何需要改业务代码的建议。
    可以把这份边界写成任务卡，而不是藏在一段很长的提示词里：

目标：验收订单确认页的成功与库存不足分支
允许：打开测试页面、填写演示订单、读取日志、截图
禁止：写入真实数据、合并、发布、删除、修改权限
成功：两个分支的状态文案和按钮均符合断言
失败：保存差异、输入来源、截图和待人工确认事项

验证记录要留下什么，才算可回放？

一条可回放记录至少要回答五个问题：使用了哪一版页面，输入从哪里来，调用了哪些工具，断言结果是什么，下一步由谁决定。演示台的日志按时间顺序记录打开页面、输入演示订单、通过状态断言、捕获库存不足分支和保存截图。

这不是把日志写得越多越好。记录应当脱敏、可定位、可复现；不要把账号凭据、个人信息或真实业务数据塞进快照。失败也要作为一等结果保存，不能用空字符串包装成“任务完成”。如果需要重试，先标记重试次数和原因，再由人决定是否扩大范围。

趋势推断：开发者会更看重“证据”而不是“生成速度”吗？

这是趋势推断，不是已经发生的行业结论。依据一是 Playwright 1.62.1 仍在维护浏览器自动化验证能力；依据二是 GitHub 与 OpenAI 的官方资料都把任务状态、工具边界和人工确认放进智能体工作流。基于这两条独立依据，可以推断：当团队面对可拆分、可回滚的测试任务时，可能会更关注“能否回放和审阅”，而不只比较一次生成快不快。

这个推断有明确适用条件：测试数据必须隔离，工具权限可以限制，验证规则有人维护，团队愿意复核结果。不确定性也很大：不同项目的测试质量、上下文完整度、成本和人工审查能力差异明显，不能据此推出普遍效率提升，更不能推出开发者不再需要人工判断。

哪些判断必须留给人？

至少保留五类决定：是否允许写入共享环境，是否修改接口或页面，是否合并代码，是否灰度或正式发布，是否接受异常结果。智能体可以整理证据、指出差异、生成待办，但不应该替你承担业务后果。

如果你今天就想试，建议从一个每周都会重复、且能快速回滚的验收任务开始：写一张四步任务卡；开放只读页面、截图和日志；跑一次成功与失败分支；让智能体生成记录；最后由你决定是否继续扩大权限。跑通一次之后，再考虑接入接口联调、发布前检查或运维告警解释。

结语

Vibe Coding 让原型更快出现，浏览器智能体则把任务、工具、上下文、验证和交付记录连接起来。真正值得尝试的下一步，不是把所有按钮都交给它，而是选一个可回滚的小任务，让每一次执行都留下能被人读懂、复查和否决的证据。

来源与事实边界

• Vercel AI SDK releases（2026-08-25）：用于说明 AI SDK 与工作流相关包在 7 天窗口内持续迭代。
• • Anthropic Claude Code v2.1.245（2026-08-25）：用于说明代码代理工具的近期版本活动。
• • OpenAI Agents SDK v0.22.0（2026-08-19）：用于说明工具调用、运行状态和可恢复执行的官方能力边界。
• • GitHub Copilot：Managing your work（2026-08-19）：用于说明统一任务状态视图的产品实践。
• • Playwright v1.62.1（2026-07-30）：用于说明浏览器自动化工具的维护状态。
• • GitHub Copilot app：agent-native desktop experience（2026-06-02）：用于说明隔离工作区和开发者决定自动化范围的原则。
    文中的界面、日志和订单号均为本地脱敏演示，不是线上业务数据，也不是独立性能测试。