vibe coding 与 vibe testing：区别在哪，为什么重要

2025 年 3 月，Y Combinator 合伙人 Jared Friedman 说，YC 2025 冬季批次里有四分之一的初创公司，代码库大约 95% 是 AI 生成的。写软件不再是瓶颈，知道那软件能不能用，成了新的瓶颈。

这场转变带出了两个词。一个已经定型、也出了名；另一个还在争论当中。

什么是 vibe coding？

Andrej Karpathy 在 2025 年 2 月 2 日的一条 X 帖子里造出了「vibe coding」这个词：

有一种新的写代码方式，我称之为「vibe coding」，你完全交给感觉，拥抱指数级增长，甚至忘掉代码本身的存在。

它真正的标志动作不是「AI 帮我写了代码」，而是你不再读代码了。你 prompt、你运行、你描述哪里还不对，然后让模型去打补丁。做出来的东西成了一个你全凭感觉操控的黑箱。

这个词很快就进了主流。柯林斯词典把 vibe coding 评为 2025 年度词汇，释义是：借助由自然语言 prompt 的 AI 来帮忙写代码。

Simon Willison 划出了那条要紧的界线。在一篇 2025 年 3 月的文章里，他认为 vibe coding 用在低风险的原型上没问题，用在生产代码库上则是「一个糟糕的主意」。他的判据很利落：哪怕每一行都是 LLM 写的，但只要你审查过、测试过、也真弄懂了，那就不算 vibe coding，那只是把模型当打字助手用。

什么是 vibe testing？

到这儿，地基就松了。没有谁被公认造出了「vibe testing」这个词，而且有两拨人拿它指着完全不同的东西。

一拨人指的是凭感觉测试：应用对一个真实用户来说感觉对不对。TestGrid 就是这么描述的，说它盯的「不只是应用有没有按预期工作，还有应用给人的感觉如何」。

另一拨人——也是大多数自动化厂商用的那种意思——指的是从自然语言意图去编写测试。Testkube 的定义是：「一种对话式的软件测试方法：测试者用大白话写下产品需求和用户场景，AI 再把这些描述转成可执行的测试。」Joe Colantonio 的 TestGuild 播客也做过几期节目，把它框在自愈式 Playwright 测试的角度上。

vibe testing 眼下是一片无主之地。厂商抢这个词的速度，比谁给它下定义的速度都快——这正是为什么把定义弄对很重要。

vibe coding 与 vibe testing：区别

vibe coding 写出那个东西，vibe testing 检查它。前者，正是后者非存在不可的原因。

vibe testing 为什么偏偏现在才出现

当你生成代码的速度快过你能读它的速度，bug 并不会消失。它们只是挪到下游，然后等着。

数据说得很直白。Veracode 的 2025 GenAI 代码安全报告在 80 个编码任务上测了 100 多个模型，发现 AI 生成的代码有 45% 引入了安全漏洞，而且换更新、更大的模型也没有好转。RedHunt Labs 扫描了大约 130,000 个 vibe coding 网站，发现大约五分之一至少泄露了一个 secret，其中包括数千个仍然有效的 Firebase 和 Supabase 凭据。2025 年 7 月，Replit 的编码 agent 在一次代码冻结期间删掉了一个生产数据库，还把自己这一手称作「一次灾难性的失败」。

团队自己也感受得到。SmartBear 的 AI 软件质量差距报告（2026 年 1 月，273 位质量决策者参与）发现，93% 的人已经用上了 AI 编码工具，68% 的人担心更快的 AI 开发会憋出测试瓶颈，60% 的人已经踩到了质量问题。

所以这个差距是真实存在的：更多的代码，更快地发布，出自读得更少的人之手。手动点击跟不上节奏，而没自己手写的代码，你也不会为它手写一整套测试 suite。vibe testing，就是想用当初撑开这个差距的那同一个动作，把它重新合上：你描述什么该为真，检查的活交给 AI 干。

真正要紧的那条断层线

把这个词剥开，它归根结底是一个工程问题：测试运行的时候，到底有没有一个模型在跑？

有些工具在执行时把 AI 一直留在回路里。Stagehand 默认会调用模型去解读每一步，页面一变又重新调一次。这样能跟上漂移，但也意味着每次运行都烧 token、每次运行都不一样，还可能以你从没写过的方式失败。

另一些工具只在编写时花一次模型，然后交给你一个确定性的产物。Playwright 自带的 codegen 会把你的点击录成一个普通的 .spec.ts。QA Wolf 这样的厂商讲的是同一个道理：「自动化测试不会即兴发挥，也不会产生幻觉，所以每次运行之间没有差异。」AI 负责编写，存下来的测试就是普通代码。

这就是那个比流行词活得更久的选择。一个每次运行都要调模型的测试，用着方便，却永远还不清自己的成本。一个已经 crystallize 成普通代码的测试，明年还会用同样的方式运行，免费，在任何 CI 里，没有一个会漂移的模型。

vibe testing 会走向哪里

有两件事很可能会发生。「用英语把它描述出来」这个前端，会变成大多数测试的默认编写方式，因为那个速度是实打实的，而另一条路是手写 selector。至于后端，则会沿着上面那条断层线分裂开：一类产品把模型留在运行时里，另一类产品用模型编写出一个耐久的产物、然后让开路。

那些大批量发布 AI 生成代码的团队，会更偏向耐久产物，道理和他们宁可在 CI 里跑单元测试、也不让人去逐次复查每一次构建是一样的。你想要的测试，得比它守护的东西更便宜、更稳，而不是又来一个哪天状态不好就掉链子的模型调用。

Hover 是怎么做 vibe testing 的

Hover 是一个免费、开源的 MCP server，就建在那条界线上「耐久产物」这一侧。你把它加进已经在用的编码 agent；agent 通过 Hover 那套接地的工具、经由 DevTools 协议驱动你真实的 Chrome，自己盘算出每一步。运行干净利落时，Hover 就把它 crystallize 成一个标准的 @playwright/test spec。

那个 spec 就是全部的意义。它在 CI 里运行，没有 AI，没有 token，没有差异，跟你手写的任何一个 Playwright 测试没两样。关于为什么 AI 编写的测试，应该在 CI 里不留一点 AI，我们写过专文；而同一个 agent，还能去探测 vibe coding 应用默认就自带发布的那些越权访问漏洞。

想 vibe code 功能，尽管去 vibe code。然后 vibe test 一下，等你做完，手里留下一个真正的 Playwright spec。