方法论 术语 v2 编辑稿

Vibetest 驱动开发

客户成果即验收标准。自然语言场景，证明产品在真实客户手里仍然可用——即使代码由机器交付。

代码越来越便宜，但成本转移到了验证环节。

单测全绿，新用户却在注册页迷路。端到端脚本通过，结账流程依然让人抓狂。一次性的爬虫能找出死链，却说不出一个谨慎的用户能否找回密码，或者一个新手能否独立完成首单。

在 vibecoding 时代，我们倡导 VDD (Vibetest-driven-development) 开发方式，让 agent 驱动项目开发，同时让客户也能参与进来。

阅读定义 看完整示例
一句话

一条客户成果用大白话说出来，同时就是验收标准、agent 任务和回归契约。

把客户成果写成自然语言场景；让独立 agent 在真实产品表面上扮演客户；仅当验收结果可接受时才发布——并且把这些场景当作长期契约，而不是一次性演示。

成果优先 工作从编撰“客户成果”开始，用自然语言描述客户必须完成的具体目标，而非编写选择器或启动漫无目的的爬虫。
agent 验证 验收者与刚交付变更的实现者不是同一个角色。
有材料支撑 通过或不通过不是凭感觉。截图、trace、记录让人可以复核。
可判定 结果足够清晰，可以用来合入、阻断发布或开启修复。
01

新的瓶颈不是写代码

软件史上的稀缺资源一直是「改动系统的能力」。验证也曾昂贵，但它大致与人类的实现能力成正比。这个平衡已经被打破。

图 01
失效模式
A

agent 放大变更面；人定义成果

编码 agent 和不间断迭代不只是加速单个 PR。它们成倍增加表面面积：更多文件被改动、更多边缘路径、更多永远不会出现在工单里的 UI 状态。人不再是打字员，而是成果的设计师——在机器能草拟出实现路径时，定义「完成」意味着什么。问题从「能不能做出来？」变成了「发布后客户还能不能成功？」

B

脚本和套件对真实客户语焉不详

脆弱的端到端脚本耦合在选择器和布局上。一次提升体验的重设计可能让套件因错误原因失败；一个只让人困惑的回归可能让套件保持绿色。维护成本随每一次有意 UI 变更而上升。快乐路径偏差是结构性的：最容易保持绿色的测试，很少是真实用户挣扎的地方。

C

一次性探针不是开发实践

爬虫、探针和 ad-hoc 的「vibetest」是有用的。它们无需手写脚本就能发现死链、空白页和明显故障。但它们本身不是开发实践。没有命名客户成果的探针，无法告诉你这个目标是否仍然成立。一次性的运行不会变成回归契约。

验证滞后

从「代码已合入」到「确认真实用户能成功」之间的时间与不确定性。AI 压缩了左侧，却放大了右侧——或者更糟糕，把风险推到了生产环境的分析系统和工单里。逃逸的缺陷不总是崩溃，而是安静地失败：邀请函从未送达、恢复流程在循环、首单路径需要内部知识才能走完。

论点

团队需要一个持久的、可复跑的定义来说明「真实用户能成功」——用产品、工程和客服已经在使用的语言来表达；由实现者之外的独立方验证；有验收材料支撑，让人信任；并且清晰到可以决定是接受还是阻断发布。这个定义就是本文接下来要展开的工作单元。

02

什么是 VDD

一种成果优先的实践：你把客户必须能做的事写成自然语言，由独立 agent 在真实产品表面上尝试这份场景，并把有验收材料支撑的验收结果当作发布的门槛——然后把场景保留为每一次重要变更后的长期契约。

图 02
核心对象

核心对象 工作单元

对象作用
场景自然语言契约：客户是谁（隐式或通过参与视角）、追求什么成果、成功是什么样子、什么不在范围内。持久的资产。
运行在特定产品表面（环境、构建、夹具）上对某场景的一次独立尝试。临时的。
验收材料一次运行留下的持久记录：agent 做了什么、看到了什么、记录了什么。
验收结果可判定的摘要——状态、得分或证据汇总、问题列表——人和自动化都能消费。

客户参与度内嵌在场景措辞里——谁在尝试、什么算「好」——不是额外叠加的又一套方法论。

非目标 VDD 不是

  • 爬虫或探针。爬虫用来发现；场景用来断言命名客户成果。
  • 实现者自检。交付变更的人不能给自己打分作为唯一验收。
  • 单元测试的替代。下层仍然廉价地捕获逻辑和契约。VDD 站在客户成果层。
  • 一次性演示。一次 impressive 的运行不是 VDD。实践要求场景能作为参与回归持续存活。
区别不在于浏览器里的模型。区别在于客户真相是否是一份持久契约。
§2 — VDD 是什么
03

六项原则

这些原则让实践始终围绕客户真相，而不是工具时尚。它们不绑定任何特定厂商或框架。

图 03
原则
01

成果先于（或并行于）实现

在交付变更之前——或至少同时——写清楚对客户来说成功意味着什么。顺序不是教条；纪律在于「完成」不能只靠实现者对界面的熟悉来定义。

02

自然语言是唯一真相源

场景文本就是契约。选择器和页面对象可能作为底层存在；它们不是产品和客服能拥有的东西。

03

agent 扮演客户，不是定位器

验证意味着像真人一样尝试目标：读标签、跟随 affordance、在产品允许时从困惑中恢复。一个只会点击预设坐标的 agent 只是在伪装脚本。

04

重验收材料，轻堆砌断言

满屏绿色对勾没有产物是软弱的验收。宁可要少量有持久验收材料支撑的场景——发生了什么、在哪失败、agent 看到了什么——也不要几百个没人信任的脆弱断言。

05

用验收，不用感觉

「看起来还行」不是发布决策。状态、阈值和问题严重度必须清晰到一次运行就能阻断、放行或开启工作，不需要开会重新解读输出。

06

场景长期保留、持续复跑

一次通过就被丢弃的场景只是演示。在 VDD 中，场景作为参与回归不断累积：当产品变化时，同一份契约反复检查首单、恢复、邀请和结账是否仍然成立。

04

为什么自然语言是接口

工程、产品和客户成功已经在用一种媒介描述好的体验：大白话。这些句子从不提及选择器或页面对象。

图 04
一份产物，
三重职责
真相源 "新用户应该在没有销售电话的情况下拿到第一份价值。"
职责 01

验收标准

给交付变更的团队。

职责 02

agent 任务

给扮演客户的独立验证者。

职责 03

回归契约

产品表面变化时复跑。

当三重职责 collapse 到同一份自然语言产物上，产品成果就不再漂移于自动化实际验证的东西之外。

参与视角 措辞，不是角色扮演

新手

首次访问，产品词汇有限，对术语和假设有先验知识的空状态容忍度低。

回访

已有账号或上下文；期待连续性、保存状态和尊重历史的恢复。

审慎

如果信任、定价或退出选项不透明就会放弃；需要在投入前看到明确价值。

不需要编造人物小传。写这样的句子："作为从未用过这个产品的访客，完成注册并创建一个项目，不看外部文档。" 或者 "作为会话过期的回访会员，恢复访问并回到离开时的位置。" 视角收紧验收标准和摩擦信号；不要求 agent 扮演一个带名字和爱好的人。

为什么不用脚本作为真相源

基于定位器的脚本编码的是上周 UI 的接线方式。自然语言编码的是客户成果必须仍然可达。布局和文案持续变化——尤其当 agent 生成 UI 时。成果变化更慢，而且当它变化时，产品和工程编辑的是同一段话，而不是逆向工程一串脆弱的点击链。

05

场景拆解

一份命名的、自然语言的单一客户成果契约——清晰到独立 agent 能在真实产品表面上尝试它，并产出可判定的验收结果。

图 05
必备要素
目标
客户试图达成的成果，一句话说清。优先结果而非 UI 观光——"完成下单并收到确认"，而不是"浏览购物车"。
验收标准
可观察条件，说明成果已达成——功能完整性，以及必要时参与质量。第三方应该能在不看屏幕共享的情况下打分。
上下文
基础 URL 或环境、认证状态、夹具、语言和标志，定义了产品表面。没有上下文，"通过"不可复现。
约束
追求成果时的规则：留在应用内、不走管理后台后门、走快乐路径除非恢复本身就是目标。
范围外
明确的非目标，防止运行蔓延成对产品的自由探索。
参与视角 （可选）
当同一成果对不同客户感受不同时："首次访客；如果定价在注册后才显示就放弃。"

可验收清单 仅凭材料就能判定

  • 命名一个单一主要成果。
  • 把成功绑定到客户可见的信号。
  • 把必过项和锦上添花分开。
  • 避免无界探索。
  • 用相同上下文干净复跑。

五个短示例 展开

注册 / 新手
目标
创建账号并进入一个可直接使用的空间。
验收标准
验证完成或明确推迟；下一步动作无需外部文档即可看见。
上下文
预发环境，已退出。
范围外
OAuth 边缘情况。
下单
目标
用测试卡购买所列套餐并收到确认。
验收标准
金额与套餐一致；确认页有可引用给客服的参考号；账号显示已支付。
上下文
已填充的商品目录，测试凭据。
邀请
目标
接受邀请并以预期角色加入正确工作空间——不是空白个人账号。
上下文
邀请链接夹具，已退出。
范围外
邀请创建 UI。
恢复 / 回访
目标
会话过期或忘记密码后恢复访问，无需客服介入即可继续之前的工作。
上下文
已有项目数据的用户；期望合理的登录后目的地。
首单 / 新手
目标
从落地页出发，不通过销售电话就拿到一个有意义的产品结果。
验收标准
结果已保存且再次访问可见；阻断性空状态被标记。
范围外
计费与高级设置。

不要这样写

避免"测试应用"、"确保没坏"或让 agent 漫无目的地游荡并报告感觉的爬虫简报——那些是探针，不是契约。优先客户可识别的成果，而不是实现步骤（"点击第三张卡片里的蓝色按钮"），除非路径本身就是重点。如果你从文字里看不出一次运行该通过还是失败，在任何人在此基础上发布之前重写。

06

独立验证

VDD 把构建变更的系统与判定客户是否还能成功的过程分开。实现者不是验收者。

图 06
实现者 ≠ 验收者

为什么自检会失效

实现者知道预设路径，会跳过陌生人会撞上的死胡同。他们一开始就已经认证了、已经在正确的 URL 上了、已经掌握了客户没有的夹具知识。他们把部分成功当作"差不多行了"，因为他们记得昨天修复时的艰辛。这些都不需要恶意——熟悉就够了。一个编码 agent 可以同时生成 UI 和一份乐观的"流程 works"叙述，而新手在真实浏览器会话里仍然在第一个表单就失败。

可信验收的结构

01

独立运行

与实现分离，有自己的会话和环境绑定。

02

独立报告

为审阅者和机器而写，不只是滚屏消失的聊天回复。

03

持久产物

截图、trace、步骤日志和结构化结果，比运行本身活得更久。

没有持久验收材料，"通过了"只是传闻。有了材料，失败的场景是可行动的：你能看到客户会在哪卡住，而不只是一个布尔值从 true 变成了 false。

要避开的软弱验收

  • 没有评分标准的"看起来还行"。
  • 没有截图或可复现上下文的状态。
  • 无法映射到通过/失败或明确阻断的长篇大论。
  • 没有命名客户成果的无界爬虫。
07

VDD 在发布流程中

VDD 不替代你的流水线设计。它提供一份契约（场景）和一份可复跑的验收结果，任何阶段都能使用。流程刻意保持简单。

图 07
五步
1

编写成果

目标、验收标准、上下文、约束、范围外、必要时加视角。测试：陌生人能否从文字判定通过或失败？

2

交付候选

人或 agent 对照成果实现。分支、预发或本地表面——任何暴露真实 UI 的东西。

3

独立验证

agent 在真实产品表面上扮演客户，在场景定义的上下文下运行。捕获结构化结果和持久验收材料。

4

按结果行动

合入或晋级，修复并复跑，或者当场景本身有误时开启工作。行动包括拒绝发布。

5

保留场景

上线后不要删除。它成为参与回归——"真实用户还能成功"的烟雾测试。

复跑入口 → 在 PR 时 · 在部署时 · 按定时 · 在发布列车前

角色

编写者

拥有客户成果

通常是产品协同工程。决定什么必须保持成立。

修复者

消费验收材料

通常是交付团队：修复产品或夹具，复跑到结果可接受。

验收负责人

设定阈值

保护实践不被模糊场景和无材料的分数侵蚀。

总是想办法 green却不改动代码或契约，不是真正的验收。

08

可判定的验收结果

没有可判定结果的场景只是提示词，不是验收。重点不是魔法数字——而是 PR 或发布清单可以在不复跑会话的情况下据此行动。

图 08
双信号

可靠性

走通了吗？

账号创建完成、邀请被接受、首份报告生成、支付确认。如果路径被阻断——错误页、缺失控件、认证损坏——无论表面多 polished，运行都在可靠性上失败。

参与质量

真人会留下来吗？

成果也许达成了，但中间经历了死胡同、晦涩文案或新手会放弃的可选步骤。两个信号同一次运行评估，避免团队发布"对 bot 能用"而客户仍在流失。

可靠性可以绿而参与质量差；参与质量可以 smooth 而静默失败导致成果从未达成。

状态、阈值、严重度 状态是执行器

通过 不通过 无法判定
阻断成果不可能完成。此类可靠性失败阻断合入。
严重路径能走但充满敌意或极易出错。阻断发布，不一定阻断每个草稿 PR。
轻微细枝末节，不应单独翻转验收结果。

阈值应该明确且稳定。每周改动阈值会教会人们无视验收。

得分概括验收材料

得分是对已打分标准和观察到问题的紧凑摘要——不是凭空飘浮的感觉。它应该能从验收材料包还原：哪些验收标准成立、哪些约束被违反、哪些摩擦点被记录。如果两个审阅者无法解释得分为什么变化，这个得分就不适合驱动合入或发布。

flakes 但不要杀死实践

  • 当环境、认证夹具或第三方依赖明显污染运行时，优先无法判定而非随机失败。
  • 在软性参与质量投诉变成硬性失败前，要求可复现的验收材料。
  • 区分场景 flakiness（模糊成果）和产品 flakiness（竞态条件、不稳定部署）。修复其一或另一；绝不"重试到绿"。
  • 限制重试次数。无限重试把验收变成抽奖。
10

组织落地

少些工具表演，多些选择几条定义产品对使用者是否仍然可用的路径——并把这些路径当作持久契约。

图 10
推广

参与烟雾测试 3–7 个场景

从真实的首单或收入关键成果开始：注册到首单成功、核心下单、接受邀请、密码找回。抵制覆盖每个屏幕的冲动。没有可判定性的广度只会制造噪音，并训练团队无视结果。产品或客服通常起草谁和什么算好；工程拥有环境、夹具和可行动的失败。

1

一条路径

编写一个关键场景，在真实表面上独立运行，审阅验收材料包直到人信任通过和失败。

2

PR 或预发验收

把同一场景绑定到重要发布。需要时从建议开始；flakiness 受控后升级为硬阻断。

3

场景库

随功能发布持续生长。只在产品成果消亡时退役场景——不是因为 UI class 名变了。

轻量级实践指标

M1

场景通过率

在主干或发布候选上；如果结果允许，拆分为可靠性与参与质量。

M2

修复时长

场景失败后，多久成果与产品再次达成一致。

M3

逃逸缺陷

支持工单、漏斗流失和场景本应拦截的 P0。

如果通过率总是 100%，阈值可能太软或场景太浅。如果永远 green 不了，标准可能不可判定或环境在说谎。在增加场景之前，先调整契约和夹具。

落地成功的标志

一个新工程师能找到关键场景，读一份验收结果，就知道是否允许发布——无需实时盯着浏览器。

11

完整示例：项目摘要

一个功能走完 VDD。重要的是形状：成果优先、独立验证、参与感知的失败、修复、通过、场景保留。

图 11
时间线
  1. 节点 01 — 功能想法

    用户一眼就能信任的周报摘要

    用户连接数据源后，产品生成简短摘要。工程可以快速搭建 pipeline 和 UI。悬而未决的问题是新手能否在没有电话指导的情况下，拿到第一份有价值的摘要。

  2. 节点 02 — 场景

    在"完成"之前编写

    新手 · 首单 你是从未用过这个产品的新用户。从摘要的营销落地页开始，如果需要就创建账号，仅使用产品内引导连接提供的示例数据源，并到达示例项目的摘要可见的状态。成功：屏幕上有一个标题清晰的摘要，至少包含一个有实质内容的汇总区域，并且你能用一句话解释它在汇总什么。约束：不使用外部文档或客服聊天；不了解内部字段名。范围外：自定义调度或分享摘要。
  3. 节点 03 — 首次独立运行

    可靠性接近通过。参与质量失败。

    账号创建成功；示例数据源连接；摘要页加载。验收材料包展示了为什么客户仍然失败了——无需实时观看：

    • 步骤时间线 — 在"配置字段"上长时间停顿，必填下拉框用内部 schema 名做标签。
    • 截图 — 空白摘要壳显示"等待首次成功同步"，没有白话文的下一步动作。
    • 问题（严重） — 新手无法在不猜测的情况下映射示例字段；实质内容摘要标准未达成。
    • 得分 — 从失败的验收标准和主要摩擦汇总而来，不是审美评分。
    可靠性：软通过 参与质量：失败 状态：不通过
  4. 节点 04 — 修复并通过

    修复产品，不是场景

    为示例数据源设置合理默认值、白话文标签、空状态显示部分摘要或一个"生成示例摘要"按钮。第二次独立运行完成成果，没有重大参与质量问题。得分上升是因为材料改善了——不是因为有人为感觉争辩。

    状态：通过
  5. 节点 05 — 场景保留

    几周后，一次 UI 清理重新引入术语

    同一份契约以可比材料失败。修复显而易见，因为客户成果从未移动。代码和 agent 可以在下方自由迭代；首单的客户证明保持为验收门槛。

12

失效模式与反模式

VDD 的失败很少来自缺少工具，而是来自软契约。这六种看起来很有生产力，却仍然让你无法获得可靠的客户验收。

图 12
反模式
✕ 01

模糊场景

"测试注册"不是成果。没有目标、标准、上下文和边界，两次运行无法产生有意义的差异——验收也无法判定。

✕ 02

不可解读的结果

依赖人类重读一部长篇日志才能判定通过/失败，不是可用的验收。合入、修复或搁置必须无需开会就能决定。

✕ 03

没有材料的分数

没有截图、步骤或失败注释的数字只是穿了数字衣服的感觉。如果没人能重构为什么它变化了，运行就不完整。

✕ 04

一次性演示

一次 impressive 的走查对下一个发布证明不了什么。归档演示；保留契约。

✕ 05

爬虫当替代

全站探针发现死链和意外，但不编码命名客户成果。发现可以启发场景；不能替代。

✕ 06

只给自己打分

实现变更的人给自己的结果打分，实现者和验收者 collapse。自检是有用的草稿；不是验收。

13 — 结语

成果才是稀缺资产

代码不再是稀缺输入。agent 能比任何人工审阅队列更快地产出、重构和迭代。稀缺的是一份持久的记录，说明对真实客户来说什么必须保持成立。

VDD 就是让这份记录可运行：客户成果写成自然语言场景，在真实产品表面上独立验证，并保留为长期契约。

随着自主迭代增加，谁拥有客户真相谁就有优势。拥有它的方式是把真相写下来，让它能被复跑——而不是指望下一次人工 QA 能抓住上一次漏掉的东西。

实践不依赖任何单一产品。它依赖于把客户成果当作验收标准——并让这个门槛保持诚实。

起步 01

编写一个关键场景，针对一条如果崩了会让你尴尬的路径。

起步 02

让结果可判定——状态、阈值、陌生人能读懂的验收材料。

起步 03

在每一次重要发布前复跑。只有当这个循环变得无聊地可靠时才扩展。

A

附录

概念性内容——字段名和存储请根据你的技术栈调整。方法论要求场景、独立运行、验收材料和可判定验收结果；不要求特定 schema 或厂商。

A.1
术语表

术语表 精简版

术语含义
客户成果真实客户在变更后仍然必须能达成的事。
场景针对单一成果的自然语言验收契约。
验收标准可观察条件，说明成果已达成。
运行在真实表面上对场景的一次独立尝试。
验收材料一次运行留下的持久产物。
验收结果状态、得分、问题列表和材料指针。
参与视角可选措辞：新手、回访、审慎。

场景模板示例 A.2

注册 / 新手
目标
新用户创建账号，无需支持就到达首个可用界面。
验收
账号已创建；显示确认或引导；必填字段没有死胡同。
上下文
预发 URL；空夹具；无前置 cookie。
范围外
社交 OAuth 变体、管理员邀请路径。
下单
目标
回访客户用已知购物车和测试支付方式完成购买。
验收
订单确认金额正确；购物车已清空；如邮件为辅助则 UI 确认足够。
上下文
认证夹具；已填充购物车；支付沙盒。
约束
不使用生产卡。
邀请 / 首单
目标
被邀请的队友接受并执行产品承诺的首个动作。
验收
邀请已接受；动作完成；产品显示明确的成功证明。
上下文
新鲜邀请令牌；指定角色。
范围外
计费升级、SSO 设置。

最小验收结果 schema A.3 · 概念性

acceptance-result.json 
{
  "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 意味着在把状态当作决定性结论之前应触发复跑策略——环境、超时或夹具失败，不是静默通过。