vibe coding 的应用，上线前该怎么测

先说结论： 别想着全测——只把「一旦坏了你会很难堪」的那几条流程锁死（注册、登录、结账），每一条变成一个你自己拥有、在 CI 里零 AI 运行的测试，然后逼着下一次 agent 改动去过它。目标不是覆盖率，而是一份 AI 没法偷偷违反的契约。

Vibe coding 是一种真正新的开发方式：你描述想要什么，agent 把它写出来，几分钟后你就有了一个能用的界面。坑出现在第二个功能上。agent 只对着眼前这句 prompt 优化——「加个折扣码输入框」——它并不记得结账昨天是好的。它把框加上了，顺手在某个地方把原本没问题的东西弄坏了。而你没发现，因为你点的是新功能，不是旧功能。

所以「给 vibe coding 的应用做测试」其实就一个问题：哪些行为必须扛过接下来上百次 AI 改动，你怎么让它们坏不了？ 下面这套流程有效。

1. 点名哪几条流程绝不能坏

别冲动去测所有东西——对一个刚起步的应用，那是你一周后就会放弃的维护负担。列出那三到五条、一旦悄无声息地挂掉就会让你丢客户或丢脸的流程：

• 新用户能不能注册完直接进到登录态？
• 他们能不能做你这个应用存在的意义那件事（发帖、上传、生成、预订）？
• 他们能不能付钱？

这就是你的上线关键集。其余的都能等。

2. 声明行为，而不是实现

在碰 selector 之前，先用大白话写下每条流程里「能用」到底指什么：一个访客开始结账，会被送去登录，而且他的购物车在这一来一回之后还在。 这就是契约。它不提按钮什么颜色、也不提哪个 CSS 类，所以它扛得住重设计——只有当行为真的错了，它才会红。

先写契约，是这里最关键的一步。如果你让 AI 先写代码、再写测试，那测试只会把代码碰巧做的事重新描述一遍——连 bug 一起描述进去。需求必须在前，代码去拟合它。

3. 把每条契约变成一个你拥有的测试

现在让它可执行。最快的路子，是让编码 agent 把真实流程走一遍，结晶成一个纯粹的 @playwright/test——就是那种你本来会手写、躺在你自己仓库里的文件。用 Hover，一个 MCP prompt 就行：

/mcp__hover__guard    # 记下契约：什么必须为真
/mcp__hover__test_app checkout   # agent 走一遍流程，存下 spec

要紧的性质不是「agent 写的」，而是 record == replay：agent 通过接地工具操作（按 role 和 name），所以驱动每次点击的那个 selector，正是被存下来的那个。这个 spec 是确定性的、语义化的，而且归你。明天删掉 Hover，它照样跑。

你也可以手写这些。这一步的重点只有一个：产出是你仓库里一个标准的测试文件，而不是困在别人云端的一段录制。

4. 每次改动都在 CI 里跑——而且零 AI

回归就是在这里被真正抓住的。把这些 spec 接进 CI（每个 pull request 都 npx playwright test），让它们在每一次 AI 改动时都跑，而不是等你想起来才跑。关键在于：这一步没有任何模型参与，就是纯 Playwright——所以一次绿是确定性的、不烧 token、而且每次都代表同一件事。写功能的那个 agent，没资格给自己的作业打分。

到这里闭环就合上了。agent 加上折扣框；CI 重放结账；如果购物车过不了登录了，pull request 会在到达用户之前变红。

5. spec 漂移时，本地自愈——别在 CI 里自动重写

真实 UI 会有意地改，所以一个 spec 迟早会因为行为合理地变了而失败，而不是因为有 bug。错误的修法，是让 CI 在跑的过程中调模型来自愈——这下你的闸变成非确定性的，你还在花 token 把红的刷成绿的，而这恰恰就是真回归被糊弄过去的方式。

正确的修法是分诊：这是漂移（应用改了，更新测试），还是 bug（应用坏了，修应用）？Hover Cloud 对每一次失败做这个判断，把 heal 提示回传到你的编辑器，你在本地修、像审别的改动一样审那条 diff。契约只有在你去动它时才动。

别这么做

• 别指望 agent 自查。 这次 prompt 之前什么是好的，它根本不记得（详见你的编码 agent 不知道自己弄坏了什么）。
• 别靠点点点的手动 QA。 你测的是刚做的功能，回归藏在你没再打开的那个功能里。
• 别第一天就追 100% 覆盖。 五条坏不了的流程，胜过五百条一碰就红的。
• 别把 AI 放进 CI 关键路径。 绿，应该是免费、快速、确定的。

常见问题

做这个需要会 Playwright 吗？ 不需要。agent 从真实流程里把 spec 写出来；它们落成标准的 Playwright 文件，你想的话之后能随时读、随时手改。

UI 一改测试是不是就全红？ 很少——它们盯的是 role 和 label，不是 CSS。只有行为变了才会红，而那正是你想被通知的时候。

对 vibe coding 的节奏来说，跑测试是不是太慢？ 上线关键集很小，在你正常的 CI 里几秒到一两分钟就跑完——重点是它自动跑，所以迭代速度还在，而安全网一直开着。

这一切会把我的代码发给第三方吗？ 不会。spec 在你自己的 CI 里跑，编写工具在本地跑。离开你机器的是行为契约，不是你的源代码。

Vibe coding 把「造东西」的成本压到了几乎为零。剩下的成本是知道它还能用——而这一部分，恰恰是你最不该交还给那个造出它的 AI 的。