Vibetest 驱动开发
以客户成果为验收标准

现在的研发团队，diff 越来越大、节奏越来越快，agent 还会在没人值守的时候自己一轮轮迭代。瓶颈已经不在写代码，而在验证。单元测试全绿，新用户却在注册页上不知所措；端到端脚本全过，结账流程却让人想放弃。

Vibetest 驱动开发（VDD）要补的就是这个缺口：把客户成果写成自然语言场景；让一个独立的 agent 在真实产品上扮演客户，把这个场景走一遍；验收结果过关，才合入、才发布。而且这些场景不是演示一次就丢，而是作为长期契约留下来，之后每次发布都再跑一遍。

读完本文，你应该能做到三件事：写出一条关键场景；把它的验收结果当作合入或发布的门槛；在之后每一次值得在意的发布上，把这份契约再跑一遍。

Agent 负责产出改动，人负责定义成果

编码 agent 和无人值守的迭代，带来的不只是单个 PR 更快。它们把改动的覆盖面成倍放大：碰到的文件更多，边缘路径更多，工单里根本没写过的界面状态也更多。人不再是敲代码的，而是成果的设计者——当机器可以自己找到一条通往目标的路，就得由人来定义什么叫「做完了」。问题也从「我们能不能做出来」，变成了「发布之后，我们凭什么相信客户还能用」。

这份信心不再是白来的。一个团队可以一夜之间生成三个功能版本，但还是得有人打开浏览器，像用户一样把产品从头走一遍——这笔固定成本一点没少。人工检查追不上 agent 的产出速度，最后变成一群疲惫的人机械地重复主流程，而真正的风险，藏在那些没人再跑一遍的场景里。

脚本和测试套件，测不出客户到底能不能用

团队转向自动化，却常常换来另一种麻烦。端到端脚本脆弱，跟选择器和页面布局绑死：一次让体验变好的改版，可能因为不相干的原因让整套测试变红；一次只有真人才会被困住的回归，测试却全绿。界面每有意地改一次，维护成本就往上加一层。而「只测主流程」是结构性的偏差：最容易保持全绿的测试，恰恰很少是真实用户卡住的地方。

单元测试和更底层的集成测试依然必要，但它们回答不了客户关心的那个问题。覆盖率全绿，和流程断掉、走进死胡同、操作后没反馈，完全可以同时存在——这些问题在早就知道按钮在哪的实现者眼里，根本不算问题。测试套件证明的是机器在正常运转，不是用户愿意留下来。

跑一次的探测，不算开发实践

全站爬取、批量探测、随手来一次 vibetest，这些都有用：不用手写脚本就能发现 broken links、空白页和明显的故障。但它们本身不构成一种开发实践。没有指明客户成果的探测，说不清「这一个目标」到底还能不能达成；跑一次的结果，也不会自动变成回归契约。没有一份持久的「成功的定义」，这些发现就回不到交付流程里，变不成团队可以重跑、可以要求、可以留下来的东西。

Agent 觉得做完了，就会停下来

还有一种失败比「检查太慢」更隐蔽：过早收工。一个独立工作的 agent 很少是因为时间或预算用完才停下——它停下来，是因为按它自己的判断，事情已经做完了。Factory 的研究把这个差距量化了：让前沿模型从零重建大型程序，如果由它自己判断做没做完，它复现了 gdal 36% 的行为；如果先由另一个独立角色在动手之前写好一份可执行的「完成标准」，再要求实现对照这份标准，复现率达到 90%。

模型的能力没有变，变的只是「什么叫做完」由谁说了算。一个自己决定不再往下做的 agent，给它再多算力也没用。这个结论可以直接搬到产品工作上：瓶颈不只是发布之后检查跑得多快，更是「做完」的定义从一开始是不是独立于实现者。

从发布到「确认用户能用」，中间有一段空白

我们把这段空白叫作验证滞后：从「代码已合入」到「我们确认真实用户能把事办成」之间的时间差和不确定性。AI 压缩了前半段，后半段却原地不动——更糟的是，风险被推到了线上数据和客服工单里才暴露。这类漏网的缺陷往往不是崩溃，而是悄悄失败的场景：一直没送到的邀请邮件、绕来绕去的找回密码流程、非得有人带才走得通的首次上手路径。

Vibetest 驱动开发是一种成果优先的实践：先用自然语言写下客户必须能做成的事；让一个独立的 agent 在真实产品上把这个场景走一遍；把由此得到的、有验收材料支撑的验收结果当作发布门槛；然后把场景作为长期契约留下来，之后每一次有意义的变更都再跑一遍。

在这几样东西里，场景才是真正的长期资产。运行是一次性的；验收材料和验收结果是记录，有了它们，验收和回归才成为可能。客户的使用体验直接写在场景的措辞里——谁在用、用得「顺」是什么样——不需要在 VDD 之上再叠一套方法论。

VDD 不是什么

• 不是爬虫，也不是批量探测。爬取负责发现问题，场景负责确认一条明确的客户成果是否达成。发现可以启发场景，但替代不了场景。
• 不是实现者的自检。写这个改动的 agent 或工程师，不能自己给自己打分就算验收。
• 不是单元测试的替代品。底层测试依然用最低的成本抓逻辑和接口契约问题。VDD 站在客户成果这一层。
• 不是一次性的演示。一次漂亮的运行不等于 VDD。这门实践要求场景作为参与回归长期留存、反复跑。

让 agent 在网站上跑一遍、再聊聊哪里坏了，是有用的探索，但还不是 VDD。VDD 从这里开始：成果有了明确的名字，成功与否可以判定，运行是独立的，材料被留了下来，同一个场景在下一次发布时还会再跑。区别不在于浏览器里跑的是哪个模型，而在于「客户到底能不能用」这件事，有没有变成一份长期有效的契约。

这些原则不依赖某个特定厂商或框架。它们要求团队把自然语言写成的客户成果当作持久的、独立验证的、有材料支撑的验收——并且在产品的整个生命周期里守住这条线。

工程、产品和客户成功团队本来就共用同一种媒介来描述「好的体验」：大白话。产品经理写「新用户应该不需要销售介入就能拿到第一份价值」；客服记录「老客户在邀请链接过期时会卡住」；工程师说「多疑的买家需要在注册之前看到价格」。这些句子里没有一句提到选择器或页面对象。VDD 就把这种语言当作契约——不是脚本上的注释，也不是启动会之后就作废的幻灯片。

当这三个用途落在同一份自然语言产物上，产品成果就不会再和自动化实际覆盖的东西渐行渐远。

参与体验写在场景里

客户的参与体验不是叠在 VDD 上的第二套方法论，它就是你写场景的方式：谁在尝试、他们为了什么成果而来、拿到之后「好」是什么感觉。仅仅功能走通是不够的。一个只有你事先知道优惠码输入框在哪才能走通的结账流程，哪怕每个接口都返回 200，对客户来说依然是失败的。

这条标准体现在措辞上，而不是戴面具演戏。参与视角在不搞戏剧化人设的前提下引导场景：

你不需要给角色编一段人生故事。你只需要写这样的句子：「作为一个从没用过这个产品的人，不查任何外部文档，完成注册并创建一个项目」，或者「作为一个会话已过期的老成员，找回访问权限并回到上次离开的地方」。视角收紧的是验收标准和摩擦信号，不要求 agent 扮演一个有名字、有爱好的人。

为什么不把脚本当事实来源

基于定位器的脚本记录的是上周界面是怎么接线的；自然语言记录的是哪条客户成果必须依然可达。布局和文案一直在变——尤其当界面是 agent 生成的时候。成果变得慢得多；而当它真的变了，产品和工程改的是同一段话，而不是去反向工程一串脆弱的点击。

已经在用自然语言写工单、PRD 和客服话术的团队，不是在学一种陌生的格式。他们是在把这种语言从「聊天」提升为「验收」：一个独立 agent 可以在真实产品上尝试、用材料记录、并作为下一次发布必须遵守的契约留下来的东西。

可选：参与视角

当同一条成果对不同客户感受不同时，加一句短短的视角——新手、回访、审慎，或者一句话：「首次访问者；如果价格要注册之后才能看到，就放弃。」视角调节的是信任和摩擦，它不是戏服，也不是一篇长长的人设。

什么样的场景才算可验收

当验证者仅凭验收材料就能回答「是 / 否」（或约定的阈值）时，场景就可以验收了。可判定的场景只指明一条主成果，把成功绑定在客户可见的信号上，把必须通过和加分项分开，避免无边界的探索，并且用同一上下文就能干净地重跑。含糊的目标产出的是感觉报告；可判定的目标产出的是合入策略能直接消费的产物。

当代码发布的速度快过人能点遍每条路径的速度时，这种分离就是「充满希望的演示」和「可以信任的验收」之间的区别。

为什么自己打分不行

当同一个 agent——或同一个工程师——先实现功能、再把场景标记为完成时，失败就藏在明处。实现者知道预期路径，会跳过陌生人会撞上的死胡同；他们一开始就已登录、已在正确的 URL 上、已经知道客户并不知道的测试数据；他们记得昨天费劲修好的那些地方，于是把「差不多」当作「够好了」。

这些都不需要恶意，熟悉就够了。在 AI 辅助交付下，一个编码 agent 可以同时生成界面和一段「流程没问题」的乐观叙述，而一个新手在真实浏览器里依然会在第一个表单上失败。自检在开发过程中是有用的冒烟；但它替代不了对照场景契约的独立验证。

比「熟悉」更深一层的是结构性问题：检查会继承产生它的工作的视野。实现者把功能拆解时，会在每一块上决定「什么算证据、够不够」。这些检查能确认实现者想到要做的一切，却把从未被表达出来的成果、交互和客户排除在外。每个局部判断都合理，而整体的大部分依然没有被度量。所以场景必须从客户成果出发来写，而不是从构建反推：一条从已交付界面反向工程出来的检查，验证的是实现对自身的记忆。

Agent 作为客户，在真实表面上

独立验证意味着 agent 像客户一样尝试这个场景：在真实的产品（或忠实的预发环境）上，通过真实的界面，在场景指定的上下文下。它不是回放已知选择器的定位器脚本。它追求的是自然语言写下的成果，像用户一样发现界面上的指引，在验收标准达成或尝试明显失败时停下。

这种姿态让契约在标记变动时保持稳定。场景说的依然是「完成结账并看到确认」。这周的布局是 agent 在这次运行里要自己解决的问题，而不是每挪一个按钮产品就要重写一次的东西。

场景可以共享；验证者的路径不能

有人说，把测试给实现者看会引来「应试」。这个风险是真的，但它发生在用例层面，而不是成果层面。一段固定的脚本——精确的输入、写死的选择器、已知的点击路径——只是客户真正需要的行为的一个稀疏采样。一旦这个采样可见，它就成了靶子：实现者（人或 agent）可以一直打补丁直到它变绿，而成果从未真正成立。

VDD 的契约位于这一层之上。场景是刻意共享的——产品和工程共同撰写，对「新手不查外部文档完成注册」这样的成果去「应试」，就是在做产品本身。留在验证者一侧的，是具体路径：会话、发现的指引、每次运行中具体的探索——每次重新生成，而不是从固定产物里回放。这也是为什么交给实现者的定位器脚本，是比目标导向 agent 更弱的工具，哪怕两者都算「自动化」。

独立运行、独立报告、持久材料

可信的验收有结构：

• 独立运行 —— 与实现分开，有自己的会话和环境绑定。
• 独立报告 —— 面向复核者和机器，而不只是一条会滚走的聊天回复。
• 持久产物 —— 截图、trace、步骤日志和结构化的验收结果，在运行结束后依然存在。

没有持久材料，「通过了」只是传闻。有了材料，一次失败的场景就是可以行动的：你看到的是客户会在哪里停住，而不只是一个布尔值翻成了 false。

要避开的弱验收

独立性会被软塌塌的东西浪费掉：没有评分依据的「看着还行」；没有截图、没有可复现上下文的状态；无法对应到通过/不通过或明确阻塞点的长篇作文；没有指明客户成果的无边界爬取。探测有用，但不是发布决策。

强验证回答一个硬问题：给定这个场景和这个构建，客户能达成成果吗？我们留下了什么证明？VDD 坚持让「刚才没写这段代码的人或系统」来问这个问题，并用关掉标签页之后依然说得通的产物来回答。

重新进入与角色

同一条场景可以在任何你再次关心这条成果的时候重新进入：PR 上、部署时、定时、或发版列车之前。触发方式怎么接是你的自动化的事；VDD 负责让契约稳定、让验收结果可解释，这样每次重跑的含义都一样。

撰写者拥有客户成果——通常是产品加工程。修复者一般是交付团队：消费材料、修产品或测试数据、重跑直到验收结果可接受。验收负责人设定阈值，并保护这门实践不被含糊的场景和没有材料的分数侵蚀。

这个循环刻意保持无聊：成果进，候选出，独立的客户尝试，决策，保留。当机器写下候选版本中越来越多的部分，谁掌握「客户到底能不能用」的答案——以及何时重新核查——就是优势所在。

重点不是一个神奇的数字，而是一份自动化、PR 或发布清单不必回放现场就能据此行动的结果。

双信号：可靠性与参与质量

每次运行都要回答两个经常分道扬镳的问题。

VDD 把两个信号放在同一次运行里，团队才不会一边发布「机器人跑通了」，一边客户照样流失。

得分是对材料的概括

得分是对打分标准和观察到的问题的紧凑概括——不是飘在空中的感觉。它应当能从验收材料包里还原：哪些验收标准成立，哪些约束被违反，哪些摩擦点被记录。如果两个复核者说不出得分为什么变了，这个得分就还不够资格来驱动合入或发布。

优先使用绑定在场景契约上的标准（成果达成、关键文案存在、禁止路径未被触碰），而不是没人负责的全局「UX 质量」量表。主观判断放进有标签的问题和备注里，而不是一个没有解释的 0 到 100 之间的浮点数。

状态、阈值与严重级别

一份实用的验收结果通常包括：

状态是主要的执行器。得分和问题列表解释为什么。阈值应当明确而稳定；每周都改阈值，只会教会大家忽略验收。

抖动与主观判断：别让它们毁了实践

自然语言场景和真实浏览器都会带来波动。把抖动当作实践的一部分，而不是放弃它的理由。

• 当环境、登录测试账号或第三方依赖明显污染了这次运行时，宁标无法判定，不给随机的不通过。
• 一条软性的参与质量投诉要变成硬性不通过，先要求可复现的材料——截图、步骤时间线或死胡同处的记录。
• 区分场景抖动（成果含糊、验收标准不稳定）和产品抖动（竞态、部署不稳）。修契约或修产品；别用「重试直到变绿」糊弄任何一个。
• 限制重试次数。无限重试会把验收变成抽奖。

主观判断——「这个流程让人困惑」——当它附着在一个具体时刻和一个约定的严重级别上时是有价值的；当它是报告里唯一的一行、而状态依然被强行标为通过时，它就是毒药。

有了状态、双信号、得分只是材料的概括、严重级别和持久材料，同一条场景就能在 PR、预发部署或定时冒烟上重新进入，而不必重写契约。人复核失败，机器执行阈值。成果不变，候选版本在变，验收结果决定接下来发生什么。

组合而不重复劳动：单元测试管代码形状，脚本管你牢牢掌控的稳定界面，场景管客户关键的参与体验，爬取管发现，分析管上线后的真相。当场景失败时，先修产品或修成果；然后再把回归锁到更低的层次。VDD 的主张很窄：明确的自然语言客户成果、独立验证、可判定的验收结果，应该站在你已经信任的工具旁边——而不是取而代之。

从一小组关键场景开始

从一套参与体验冒烟开始：三到七条场景，覆盖真正的首次价值或与收入直接相关的成果（注册到首次成功、核心结账、接受邀请、找回密码）。用自然语言写，带清晰的验收标准，在需要的地方加参与视角。克制住覆盖每个屏幕的冲动。没有可判定性的广度只会产生噪音，并训练团队忽略结果。

所有权应当共享：产品或客户成功团队通常起草谁和好是什么感觉；工程拥有环境、测试数据和可行动的失败。场景是团队的产物，不是某个人的私有 QA 脚本。

同一份契约可以在 PR、部署或定时任务上重新进入。怎么调度运行是你交付系统的事；VDD 提供契约和验收结果。

早期要避开的反模式

含糊的场景、只有自检、从已交付界面反推的场景、没有材料的分数、一次性演示、用爬取代替、无法解读的验收结果。第一个月就把它们抓出来；否则它们会在后面以正式失败模式的形式再次出现。

轻量的实践指标

如果通过率永远是 100%，可能是阈值太软或场景太浅；如果永远绿不了，可能是标准不可判定或环境在说谎。先调契约和测试数据，再加场景。

当一个新来的工程师能找到关键场景、读懂一份验收结果、并知道现在能不能发布——而不用盯着浏览器现场看——落地就成功了。

功能想法

团队要发布项目摘要：用户接入一个数据源后，产品应产出一份一眼就能信任的每周简报。工程能很快搭好管线和界面。悬而未决的问题是：一个新手能不能不靠电话里的人指导，就拿到第一份有价值的摘要。

自然语言场景（新手，首次价值）

在把功能视为完成之前，团队先写下：

可选参与视角：新手，好奇心有时限——如果路径感觉像在「搭台子」，记下你会在哪里放弃。

实现与第一次独立运行

候选版本上了预发环境。一次独立运行——与实现者的自检分开——在真实浏览器上执行场景，并写下一份持久报告。

修复并变绿

团队没有去改场景来迁就坏掉的界面。他们修的是产品：给示例数据源加上合理的默认值，把标签换成大白话，空状态要么显示一份部分摘要、要么给一个「生成示例摘要」的按钮。第二次独立运行走完了成果，死胡同更少，没有严重的参与质量问题。状态：通过。得分上升是因为验收标准的材料变好了——不是因为谁争取到了更高的「感觉分」。

场景留下来

这条场景进入场景库。摘要引导流程变动时、登录或空状态重构时、发布候选上，它都会重新进入。几周后，一次界面清理又把术语带回了字段映射。同一份契约再次失败，材料可比。修复一目了然，因为客户成果从没动过。

这就是缩微版的 VDD。代码和 agent 可以在下面自由迭代；「客户能拿到首次价值」的证明始终是验收门槛。

代码不再是稀缺的输入。Agent 起草、重构、迭代的速度，快过任何评审队列手动盯完每条路径的速度。依然稀缺的——也是把「自信地发布」和「大声地发布」区分开的——是一份关于对真实客户来说什么必须依然成立的持久记录。

Vibetest 驱动开发就是把这份记录变成可操作的东西：客户成果用自然语言写成场景，在真实产品上独立验证，并作为活的契约保留。场景不是一次演示的文档；它是机器可以在每次有意义的变更之后重新核查的「完成的定义」。

随着自主迭代增多，谁掌握「客户到底能不能用」的答案就是优势所在。拥有它的方式，是把它写成能重跑的东西，而不是指望下一轮人工 QA 能抓住上一轮漏掉的。

往前看，同一个形状可以扩展而不改变想法：以措辞形式表达的、更丰富的参与视角库；同一成果库之下跨应用、跨表面的场景；对每次运行的成本和延迟做有意的取舍。这门实践不依赖任何单一产品。它依赖的是把客户成果当作验收——并守住这条线的诚实。

{
  "scenarioId": "string",
  "runId": "string",
  "status": "pass | fail | inconclusive",
  "score": 0,
  "threshold": 0,
  "summary": "string",
  "reliability": "pass | fail | inconclusive",
  "engagement": "pass | fail | inconclusive",
  "issues": [
    { "severity": "blocker | major | minor", "title": "string", "detail": "string" }
  ],
  "evidence": {
    "steps": ["string"],
    "artifacts": ["uri-or-path"]
  },
  "startedAt": "ISO-8601",
  "finishedAt": "ISO-8601"
}

score 是对场景验收材料的概括；没有产物时绝不能仅凭分数放行。inconclusive（无法判定）表示先执行复跑策略，再把状态当作定论——它对应的是环境、超时或测试数据出问题，不是静默通过。

延伸阅读

• 经典的验收测试与行为驱动开发（BDD）文献——团队如何用散文给成果命名。
• 探索性测试文献——关于参与摩擦与测试章程；适合在撰写场景时借鉴，但不能替代可重跑的契约。
• 产品分析与会话回放——作为流量之后的补充；VDD 在真实用户到来之前预先验证关键路径。
• Factory 关于编码 agent 完成大型软件任务的研究——同一个模型，因为有了独立撰写、先于实现的完成标准而交付得更多的实证。