TL;DR：TDVD 把测试先行与 AI 氛围编程结合，用 BDD 定义业务行为、SDD 约束技术规范、TDD 保证代码正确，让 AI 生成的代码可验证、可交付。
本文所称 TDVD 为本文所用缩写，指 Test-Driven Vibe Development（测试驱动的氛围开发），全文统一使用该缩写，不再与其他术语混用。
一、TDVD 是什么
TDVD（Test-Driven Vibe Development，测试驱动的氛围开发）是一种将测试先行（Test-First）质量工程实践与 AI 辅助的“氛围编程”（Vibe Coding）融合的开发方法，由 ASOS 首席测试工程师 Irfan 提出。其核心约束是：在让 AI 生成代码之前，先确定“什么算完成”，测试或验收标准先行，AI 在这个约束内生成实现，人类审核测试本身和最终执行结果。
传统氛围编程允许开发者用自然语言描述需求、让 AI 直接生成代码，效率高但质量不可控。TDVD 的修正在于把“完成”的定义前置，用可执行的测试约束 AI 的输出，而不是让 AI 自由发挥后靠人工事后补测试。
ASOS 团队在内部工具上实践 TDVD，报告了约 7–10 倍的加速，但同时承认该数据是对比“团队不熟悉该技术栈时的估算基线”，且项目本身是低风险内部工具，选型存在一定偏差。
二、TDVD 的三层拆分：BDD + SDD + TDD
TDVD 的核心拆分包含三个部分，分工如下：
| BDD | Behavior-Driven Development | 业务上什么算对（外部行为） | Gherkin 行为场景 |
| SDD | Spec-Driven Development | 用规范作为单一事实源，驱动 AI 生成实现和测试 | 规范 / 计划 / 任务三类 Markdown 工件 |
| TDD | Test-Driven Development | 代码层面什么算对（单元测试） | 红-绿-重构循环下的单元测试 |
三、BDD：定义业务上什么算对
3.1 BDD 是什么
BDD（Behavior-Driven Development，行为驱动开发）的核心是用业务语言描述系统“应该表现出什么行为”，并把这些描述变成可自动执行的验收测试。它关注的不是“代码怎么写”，而是“用户看到的结果对不对”。
3.2 Gherkin 语法
Gherkin 是 BDD 使用的结构化自然语言语法，文件后缀为 .feature，标准写法为 Given-When-Then：
Given 我在测试环境登录页
When 我输入正确的账号密码并点击登录
Then 我应该在 3 秒内进入工作台首页
关键约束：Then 步骤必须验证用户或外部系统可观测的输出，而不是数据库内部记录。否则隐蔽缺陷（内部状态错误但用户可见结果暂时正常）会被漏掉。
3.3 BDD 与左移的区别
左移（Shift Left）是一种质量策略方向：把测试和验证活动尽可能提前到开发生命周期的早期阶段，因为缺陷发现得越晚，修复成本越高。它本身不规定“具体怎么提前”，只规定“必须提前”。
BDD 则是一套具体的协作与形式化方法，通过 Given-When-Then 让业务方、开发和测试在写代码之前就用可执行的行为场景达成一致。BDD 天然发生在需求细化和验收标准制定阶段，因此它本身就是一种“左移行为”。左移是“为什么要早做”的理由，BDD 是“早做什么、怎么做”的载体。
四、SDD：用规范驱动 AI 生成
4.1 SDD 是什么
SDD（Spec-Driven Development，规范驱动开发）是一种将规范而非代码置于开发流程中心的软件工程方法。其核心主张是：规范是单一事实源，代码是从规范派生出来的产物；维护软件意味着持续演进规范，而不是直接修补代码。
4.2 Spec Kit 核心落地路径
SDD 的落地路径为四步：规范先行 → 计划/设计 → 任务拆解 → 实现验证。
| 指定（Specify） | /speckit.specify | spec.md | 定义“做什么、为什么”，包含用户需求、验收标准和约束条件 |
| 计划（Plan） | /speckit.plan | plan.md | 决定技术路径，包括架构、技术栈和设计约束 |
| 任务（Tasks） | /speckit.tasks | tasks.md | 将规范与计划拆解为可独立实现和验证的小任务 |
| 实现（Implement） | /speckit.implement | 源代码 | 依据前三者编写代码，每个任务完成后对照规范验证 |
此外还有一个全局约束文件 constitution.md（项目宪法），定义架构约束和标准，不属于单个功能。
4.3 三层工件对应关系
| 预期行为 | spec.md / requirements.md | 规范 | 用可验证的验收条件定义“什么算对”，可用 Given-When-Then 或 EARS 语法书写 |
| 实现框架 | plan.md / design.md | 技术计划 | 锁定技术栈、架构风格与组件关系，限制 AI 只能在既定框架内生成代码 |
| 模块 | tasks.md | 任务拆解 | 把规范拆成离散、可独立验证的小任务，每个任务像 AI 要逐一满足的验收测试 |
4.4 SDD 与 BDD 的关系
BDD 是 SDD 的前身和验收层组件：
- 旧义 SDD：规格驱动测试，本质就是 BDD 的可执行规格理念（Gherkin + Cucumber）。
- 新义 SDD：规格驱动 AI 生成代码，BDD 的 Given-When-Then 降为 requirements.md 中“预期行为”的一种写法。
- 分工：BDD 定义行为，SDD 额外管理技术约束和任务拆解。
五、TDD：定义代码层面什么算对
5.1 TDD 三条核心规则
5.2 红-绿-重构循环
| 红（Red） | 写一个失败的测试 | 针对下一个最小功能点写测试，运行确认失败；若一开始就通过，说明没验证新东西 |
| 绿（Green） | 写刚好够用的代码 | 用最简单直接的方式让测试通过，不写测试未覆盖的生产代码 |
| 重构（Refactor） | 在测试保护下清理代码 | 不改变外部行为，消除重复、改善命名、调整结构，测试套件是安全网 |
一次循环通常很短，很少超过 10 分钟。开始前先列测试清单，每次挑一个能最快引导设计重点的测试执行。
5.3 Python 示例：优惠券 + 积分抵扣
需求：订单 100 元，使用满 100 减 20 优惠券，再抵扣 500 积分（500 积分 = 5 元），实付应为 75 元。
| 红 | 写一个会失败的测试 | assert calculate(100.00, 20.00, 500) == 75.00 | ModuleNotFoundError → 失败 |
| 绿 | 写刚好够用的实现 | return amount – coupon – points / 100 | 通过 |
| 重构 | 测试保护下清理代码 | 抽 _points_to_amount()，定义 POINTS_PER_YUAN | 仍通过 |
| 红（第二轮） | 写边界测试 | assert calculate(100.00, 20.00, 10000) == 0.00 | 返回 -20 → 失败 |
| 绿（第二轮） | 加钳制逻辑 | return max(0, amount – coupon – points / 100) | 通过 |
| 重构（第二轮） | 再清理 | 保持测试绿 | 仍通过 |
核心：每轮只解决一个小问题，边界由新测试逐步逼出来，不提前写。
六、三层如何协同
以“优惠券 + 积分抵扣”中的高危隐蔽缺陷（金额恰好等于优惠券门槛、积分抵扣溢出）为例：
| BDD | 用 Gherkin 写“订单金额恰好等于优惠券门槛且使用积分”场景，Then 断言用户可见的实付金额 |
| SDD | spec.md 显式列出“金额恰好等于门槛”“积分抵扣溢出”作为边缘情况；plan.md 锁定金额计算必须用 BigDecimal；tasks.md 拆出“实现积分转金额”“实现钳制逻辑”等小任务 |
| TDD | 先写 assert calculate(100.00, 20.00, 10000) == 0.00 看它失败，再写实现让它通过，最后在测试保护下重构 |
三者关系：SDD 说“建什么、为什么建”，BDD 说“业务行为长什么样”，TDD 说“每个代码单元怎么算对”。
七、TDVD 的适用边界
TDVD 的价值在于用测试约束 AI 生成代码的质量，但它并非万能：
- ASOS 报告的 7–10 倍加速，基线是“团队不熟悉该技术栈时的估算”，且项目为低风险内部工具，选型存在偏差。
- AI 可能声称“测试通过”但实际未执行，因此必须由人或 CI 实际运行测试，不能采信 AI 的自述。
- 当编码被加速后，瓶颈会转移到基础设施、权限审批和部署环节。
八、术语速查
| TDVD | Test-Driven Vibe Development | 测试先行 + AI 辅助编程，用测试约束 AI 生成代码 |
| BDD | Behavior-Driven Development | 用 Given-When-Then 描述业务行为，变成可执行验收测试 |
| SDD | Spec-Driven Development | 规范作为单一事实源，驱动 AI 生成实现和测试 |
| TDD | Test-Driven Development | 红-绿-重构循环，先写失败测试再写实现 |
| Gherkin | — | BDD 的结构化自然语言语法，.feature 文件 |
| 左移 | Shift Left | 把测试和验证提前到开发早期阶段的策略方向 |
