TDD、BDD、DDD、SDD 在 AI Vibecoding 中的作用
Created: 2026-05-05
公众号名称：栈顶动态
作者名称：栈顶动态
发布时间：2026-05-05 18:28
Vibecoding 是由 Andrej Karpathy 于 2025 年初提出的概念，指”用自然语言提示，让 AI 协助编写代码”的开发范式。开发者从”手写每一行代码”转向”人类提供战略方向，AI 处理战术实现”的协同模式。然而，纯粹的 Vibecoding 虽然带来了极大的效率提升（据调研可达 126% 的生产力增益），但也面临着代码质量失控、可维护性下降等挑战。
本文将分析 TDD（测试驱动开发）、BDD（行为驱动开发）、DDD（领域驱动设计）、SDD（规格驱动开发） 四大方法论如何在 AI Vibecoding 中发挥关键作用，为”氛围编程”注入工程化保障。
目录
1. 什么是 AI Vibecoding？
2. TDD — 测试驱动开发
3. BDD — 行为驱动开发
4. DDD — 领域驱动设计
5. SDD — 规格驱动开发
6. 四者对比与在 Vibecoding 中的协同
7. 实战案例：用四种方法论构建一个 AI 驱动的待办事项应用
8. 总结
1. 什么是 AI Vibecoding？
Vibe Coding 的核心工作流：描述 → 生成 → 运行 → 调整
核心定义
Vibecoding 是一种以开发者创意/意图为核心、以大语言模型（LLM）为协作伙伴，通过自然语言交互快速生成、迭代、验证代码的沉浸式开发模式。开发者不再逐行编写代码，而是通过自然语言”描述”需求，让 AI 生成代码，然后通过”运行 → 观察 → 调整”的循环来逼近目标。
关键特征
| 特征 | 说明 |
|---|---|
| 🎯 意图驱动 | 开发者聚焦于”想要什么”，而非”怎么实现” |
| 🤖 AI 协作 | LLM 作为编码伙伴，处理战术层面的实现 |
| 🔄 快速迭代 | 通过自然语言反馈循环快速调整 |
| ⚡ 高效原型 | 从想法到可运行代码的时间大幅缩短 |
挑战
-
代码质量不可控：AI 生成的代码可能隐藏 bug
-
缺乏架构一致性：快速迭代容易导致代码结构混乱
-
测试覆盖不足：Vibecoding 天然倾向”跳过测试直接运行”
-
团队协作困难：缺乏统一的规格文档和验收标准
💡 这正是 TDD、BDD、DDD、SDD 四大方法论的价值所在——它们为 Vibecoding 提供了工程化的”护栏”。
2. TDD — 测试驱动开发
TDD 的核心循环：红（编写失败测试）→ 绿（编写最少代码通过测试）→ 重构（优化代码）
2.1 概念介绍
TDD（Test-Driven Development，测试驱动开发） 是由 Kent Beck 提出的软件开发方法，其核心理念是：在编写功能代码之前，先编写测试代码。
TDD 遵循 “Red → Green → Refactor” 循环：
-
🔴 Red（红）：编写一个会失败的测试，定义期望的行为
-
🟢 Green（绿）：编写最少的代码使测试通过
-
🔵 Refactor（重构）：在不改变行为的前提下优化代码结构
2.2 在 AI Vibecoding 中的作用
在 Vibecoding 中，TDD 扮演着质量守门人的角色：
| 作用 | 说明 |
|---|---|
| 防止 AI 幻觉 | 测试用例作为明确的约束，防止 AI 生成”看起来对但实际错”的代码 |
| 回归保护 | 每次 AI 修改代码后，测试套件确保已有功能不被破坏 |
| 行为契约 | 测试用例本身就是对 AI 的”提示词”，告诉 AI 期望的行为 |
| 渐进式开发 | 强制 AI 一次只实现一个小功能，避免”一步到位”带来的复杂性 |
2.3 Vibecoding + TDD 实战示例
场景：用 AI 构建一个字符串反转函数
步骤 1 — Red：先写测试
# test_string_utils.py
import pytest
def test_reverse_string():
"""测试基本字符串反转"""
from string_utils import reverse_string
assert reverse_string("hello") == "olleh"
def test_reverse_empty_string():
"""测试空字符串"""
from string_utils import reverse_string
assert reverse_string("") == ""
def test_reverse_palindrome():
"""测试回文字符串"""
from string_utils import reverse_string
assert reverse_string("madam") == "madam"步骤 2 — 用 AI 提示生成代码
提示词：
请实现 string_utils.py 中的 reverse_string 函数，
使其通过以下测试：
- reverse_string("hello") == "olleh"
- reverse_string("") == ""
- reverse_string("madam") == "madam"步骤 3 — AI 生成实现
# string_utils.py
def reverse_string(s: str) -> str:
return s[::-1]步骤 4 — 运行测试验证
$ pytest test_string_utils.py -v
=== test session starts ===
test_string_utils.py::test_reverse_string PASSED
test_string_utils.py::test_reverse_empty_string PASSED
test_string_utils.py::test_reverse_palindrome PASSED
=== 3 passed in 0.02s ===💡 VibeTDD（vibetdd.dev）是一个专门将 TDD 与 AI Vibecoding 结合的实践社区，主张”让 TDD 增强而非拖慢快速开发”。
3. BDD — 行为驱动开发
BDD 的核心结构：Given（前提）→ When（操作）→ Then（预期结果）
3.1 概念介绍
BDD（Behavior-Driven Development，行为驱动开发） 是由 Dan North 在 TDD 基础上发展而来的方法，其核心思想是：用自然语言描述软件行为，让非技术人员也能理解和参与。
BDD 使用 Gherkin 语法，以 Given-When-Then 三段式结构描述行为：
Feature: 用户登录
作为一名注册用户
我想要登录系统
以便访问我的个人数据
Scenario: 使用正确的凭据成功登录
Given 用户已注册账号 "alice@example.com" 密码 "password123"
When 用户在登录页面输入邮箱和密码并点击登录
Then 系统显示"登录成功"并跳转到首页3.2 在 AI Vibecoding 中的作用
| 作用 | 说明 |
|---|---|
| 统一语言 | Gherkin 场景本身就是高质量的 AI 提示词，消除了需求到代码的翻译损耗 |
| 可执行的验收标准 | 将业务需求转化为可自动化的测试，AI 生成的代码必须通过这些测试 |
| 跨角色协作 | 产品经理、测试、开发、AI 都能理解同一份行为描述 |
| 需求清晰化 | 编写 Given-When-Then 场景的过程本身就是对需求的深度思考 |
3.3 Vibecoding + BDD 实战示例
场景：用 AI 构建购物车功能
步骤 1 — 用 Gherkin 编写行为规格
Feature: 购物车管理
Scenario: 添加商品到购物车
Given 商品 "Python编程指南" 价格为 59.00 元且有库存
When 用户将该商品添加到购物车
Then 购物车中应有 1 件商品
And 购物车总价应为 59.00 元
Scenario: 购物车商品数量超过库存
Given 商品 "Python编程指南" 库存为 3 件
And 购物车中已有 3 件该商品
When 用户尝试再添加 1 件
Then 系统提示"库存不足"
And 购物车中该商品数量仍为 3 件步骤 2 — 将 Gherkin 作为 AI 提示词
提示词：
请根据以下 BDD 场景实现购物车功能：
Feature: 购物车管理
Scenario: 添加商品到购物车
Given 商品 "Python编程指南" 价格为 59.00 元且有库存
When 用户将该商品添加到购物车
Then 购物车中应有 1 件商品
And 购物车总价应为 59.00 元
Scenario: 购物车商品数量超过库存
Given 商品 "Python编程指南" 库存为 3 件
And 购物车中已有 3 件该商品
When 用户尝试再添加 1 件
Then 系统提示"库存不足"
And 购物车中该商品数量仍为 3 件
请使用 Python 实现，并包含对应的 pytest 测试。步骤 3 — AI 生成代码
# cart.py
class CartItem:
def __init__(self, name: str, price: float, stock: int):
self.name = name
self.price = price
self.stock = stock
self.quantity = 0
class ShoppingCart:
def __init__(self):
self.items: dict[str, CartItem] = {}
def add_item(self, item: CartItem, quantity: int = 1) -> str | None:
"""添加商品到购物车，返回错误信息或 None"""
current = self.items.get(item.name)
current_qty = current.quantity if current else 0
if current_qty + quantity > item.stock:
return "库存不足"
if current:
current.quantity += quantity
else:
item.quantity = quantity
self.items[item.name] = item
return None
def total_price(self) -> float:
return sum(item.price * item.quantity for item in self.items.values())
def item_count(self) -> int:
return sum(item.quantity for item in self.items.values())# test_cart.py
import pytest
from cart import CartItem, ShoppingCart
def test_add_item_to_cart():
cart = ShoppingCart()
book = CartItem("Python编程指南", 59.00, 10)
result = cart.add_item(book, 1)
assert result is None
assert cart.item_count() == 1
assert cart.total_price() == 59.00
def test_add_item_exceeds_stock():
cart = ShoppingCart()
book = CartItem("Python编程指南", 59.00, 3)
cart.add_item(book, 3)
result = cart.add_item(book, 1)
assert result == "库存不足"
assert cart.item_count() == 34. DDD — 领域驱动设计
DDD 的战术模式：实体、值对象、聚合、领域服务、领域事件、仓储
4.1 概念介绍
DDD（Domain-Driven Design，领域驱动设计） 是由 Eric Evans 在其 2003 年的著作《领域驱动设计》中提出的软件设计方法论。其核心思想是：以业务领域为中心来驱动软件设计。
DDD 分为两个层面：
战略设计（Strategic Design）
| 概念 | 说明 |
|---|---|
| 统一语言（Ubiquitous Language） | 团队使用一致的术语，消除沟通歧义 |
| 限界上下文（Bounded Context） | 将大型系统划分为多个语义边界清晰的上下文 |
| 上下文映射（Context Mapping） | 定义不同限界上下文之间的关系 |
战术设计（Tactical Design）
| 模式 | 说明 |
|---|---|
| 实体（Entity） | 具有唯一标识和生命周期的对象 |
| 值对象（Value Object） | 通过属性值定义的对象，无唯一标识 |
| 聚合（Aggregate） | 一组相关对象的集合，对外暴露唯一入口 |
| 领域服务（Domain Service） | 不属于任何实体的业务逻辑 |
| 领域事件（Domain Event） | 表示领域中发生的重要事件 |
| 仓储（Repository） | 提供聚合根的持久化抽象 |
4.2 在 AI Vibecoding 中的作用
| 作用 | 说明 |
|---|---|
| 架构护栏 | 为 AI 生成的代码提供清晰的架构边界，防止”意大利面条式代码” |
| 统一语言作为提示词 | 领域术语直接成为 AI 提示词的一部分，提高生成代码的准确性 |
| 限界上下文指导模块化 | 帮助 AI 理解系统的边界，生成高内聚低耦合的代码 |
| 领域模型作为知识库 | 将领域知识显式化，AI 可以基于领域模型生成更符合业务逻辑的代码 |
4.3 Vibecoding + DDD 实战示例
场景：用 AI 构建一个在线订单系统
步骤 1 — 定义统一语言和限界上下文
限界上下文：
├── 订单上下文（Order Context）
│ ├── 实体：Order, OrderItem
│ ├── 值对象：Money, Address
│ └── 聚合根：Order
├── 商品上下文（Catalog Context）
│ ├── 实体：Product
│ └── 值对象：Price
└── 支付上下文（Payment Context）
├── 实体：Payment
└── 领域事件：PaymentCompleted, PaymentFailed步骤 2 — 用统一语言编写 AI 提示词
提示词：
请按照 DDD 战术模式实现订单上下文，要求：
1. Order 是聚合根，包含 OrderItem 列表和 Address 值对象
2. OrderItem 包含 ProductId（字符串）、Quantity（整数）、UnitPrice（Money 值对象）
3. Money 是值对象，包含 Amount（Decimal）和 Currency（字符串）
4. Address 是值对象，包含 Province、City、Street、ZipCode
5. Order 必须通过工厂方法 create_order() 创建
6. Order 有 add_item() 和 calculate_total() 方法
7. 当订单总价超过 10000 时，抛出 OrderTotalExceededException
请使用 Python dataclass 实现，并遵循 DDD 分层架构。步骤 3 — AI 生成领域模型
# domain/value_objects.py
from dataclasses import dataclass
from decimal import Decimal
@dataclass(frozen=True)
class Money:
amount: Decimal
currency: str = "CNY"
def __post_init__(self):
if self.amount < 0:
raise ValueError("金额不能为负数")
def __add__(self, other: "Money") -> "Money":
if self.currency != other.currency:
raise ValueError("货币类型不一致")
return Money(self.amount + other.amount, self.currency)
@dataclass(frozen=True)
class Address:
province: str
city: str
street: str
zip_code: str
# domain/entities.py
from dataclasses import dataclass, field
from domain.value_objects import Money, Address
class OrderTotalExceededException(Exception):
pass
@dataclass
class OrderItem:
product_id: str
quantity: int
unit_price: Money
def subtotal(self) -> Money:
return Money(
self.unit_price.amount * self.quantity,
self.unit_price.currency
)
@dataclass
class Order:
order_id: str
items: list[OrderItem] = field(default_factory=list)
shipping_address: Address | None = None
_max_total: Decimal = Decimal("10000")
@classmethod
def create_order(cls, order_id: str, address: Address) -> "Order":
return cls(order_id=order_id, shipping_address=address)
def add_item(self, product_id: str, quantity: int, unit_price: Money):
item = OrderItem(product_id=product_id, quantity=quantity, unit_price=unit_price)
self.items.append(item)
total = self.calculate_total()
if total.amount > self._max_total:
self.items.pop()
raise OrderTotalExceededException(
f"订单总价 {total} 超过限额 {self._max_total}"
)
def calculate_total(self) -> Money:
if not self.items:
return Money(Decimal("0"))
total = self.items[0].subtotal()
for item in self.items[1:]:
total = total + item.subtotal()
return total5. SDD — 规格驱动开发
SDD 的核心流程：Specify（规格定义）→ Clarify（消除歧义）→ Plan（技术规划）→ Tasks（任务分解）→ Implement（实现）
5.1 概念介绍
SDD（Spec-Driven Development，规格驱动开发） 是在生成式 AI 时代应运而生的全新软件开发方法论，由 Microsoft 的 GitHub Spec Kit 等工具推动。其核心理念是：将规格说明（Specification）作为开发过程的唯一事实来源（Single Source of Truth），代码只是规格的表达。
SDD 的核心流程分为四个阶段：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Specify │───▶│ Clarify │───▶│ Plan │───▶│ Implement │
│ 定义规格 │ │ 消除歧义 │ │ 技术规划 │ │ 逐项实现 │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
spec.md clarified.md plan.md task-by-task| 阶段 | 输出 | 说明 |
|---|---|---|
| Specify（定义规格） | spec.md | 描述软件应该做什么、为什么做，而非怎么做 |
| Clarify（消除歧义） | clarified.md | 结构化地发现边界情况、空状态、错误处理等 |
| Plan（技术规划） | plan.md | 将规格转化为技术方案和架构决策 |
| Tasks（任务分解） | 任务清单 | 将计划分解为可独立实现和验证的小任务 |
| Implement（实现） | 代码 | 逐项执行任务，每项完成后验证 |
5.2 在 AI Vibecoding 中的作用
SDD 可以说是为 AI Vibecoding 量身定制的方法论：
| 作用 | 说明 |
|---|---|
| AI 的”说明书” | 规格文档直接作为 AI 的上下文输入，大幅提升生成代码的质量 |
| 消除 Vibecoding 的歧义 | 强制在编码前消除需求歧义，减少 AI 的”自由发挥”空间 |
| 可追溯性 | 每一行代码都能追溯到规格中的具体条目 |
| 渐进式细化 | 从高层规格到具体任务，逐步细化，与 AI 的能力边界完美匹配 |
| 团队协作基础 | 规格文档是人类团队和 AI 之间的”动态契约” |
5.3 Vibecoding + SDD 实战示例
场景：用 AI 构建一个 Markdown 笔记应用
阶段 1 — Specify（定义规格）
# spec.md — Markdown 笔记应用
## 概述
一个支持 Markdown 编辑和实时预览的 Web 笔记应用。
## 功能需求
- FR1: 用户可以创建、编辑、删除笔记
- FR2: 编辑器支持 Markdown 语法
- FR3: 实时预览 Markdown 渲染结果
- FR4: 笔记按创建时间倒序排列
- FR5: 支持搜索笔记标题和内容
## 约束
- C1: 使用 React + TypeScript 前端
- C2: 笔记存储在 localStorage
- C3: 单页应用，无需后端
## 验收标准
- AC1: 创建笔记后，列表中立即显示新笔记
- AC2: 编辑笔记时，预览区域实时更新
- AC3: 删除笔记时，弹出确认对话框
- AC4: 搜索结果高亮匹配文本阶段 2 — Clarify（消除歧义）
# clarified.md
## 边界情况
- EC1: 笔记标题为空时，使用"无标题笔记"作为默认标题
- EC2: 笔记内容为空时，允许保存
- EC3: 搜索无结果时，显示"未找到匹配笔记"
- EC4: localStorage 已满时，提示用户清理空间
## 错误处理
- EH1: Markdown 解析失败时，显示原始文本并提示错误
- EH2: localStorage 不可用时，降级为内存存储并提示用户
## 空状态
- ES1: 无笔记时，显示引导创建的空状态页面阶段 3 — Plan（技术规划）
# plan.md
## 技术栈
- React 18 + TypeScript
- Vite 构建工具
- react-markdown 渲染库
- CSS Modules 样式方案
## 架构
# tasks.md
## T001: 项目初始化
- [ ] 使用 Vite 创建 React + TypeScript 项目
- [ ] 安装依赖：react-markdown
- [ ] 配置目录结构
## T002: 类型定义
- [ ] 定义 Note 接口（id, title, content, createdAt, updatedAt）
## T003: localStorage 封装
- [ ] 实现 saveNote / loadNotes / deleteNote
- [ ] 实现错误处理（降级为内存存储）
## T004: 笔记列表组件
- [ ] 渲染笔记列表（按时间倒序）
- [ ] 实现空状态显示
- [ ] 实现删除确认对话框
## T005: 编辑器 + 预览组件
- [ ] 实现 Markdown 编辑器
- [ ] 实现实时预览
- [ ] 处理 Markdown 解析错误
## T006: 搜索功能
- [ ] 实现标题和内容搜索
- [ ] 实现搜索结果高亮阶段 5 — 用 AI 逐项实现
提示词（执行 T002）：
请根据以下规格实现 TypeScript 类型定义：
Note 接口：
- id: string（UUID 格式）
- title: string
- content: string（Markdown 格式）
- createdAt: Date
- updatedAt: Date
请创建 src/types/note.ts 文件。6. 四者对比与在 Vibecoding 中的协同
6.1 核心对比
| 维度 | TDD | BDD | DDD | SDD |
|---|---|---|---|---|
| 全称 | Test-Driven Development | Behavior-Driven Development | Domain-Driven Design | Spec-Driven Development |
| 关注点 | 代码正确性 | 业务行为 | 领域建模 | 需求规格 |
| 核心产出 | 测试用例 | Gherkin 场景 | 领域模型 | 规格文档 |
| 驱动对象 | 测试驱动代码 | 行为驱动设计 | 领域驱动架构 | 规格驱动实现 |
| 适用阶段 | 编码阶段 | 需求 + 编码 | 架构 + 编码 | 全生命周期 |
| AI 适配度 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 学习曲线 | 低 | 中 | 高 | 中 |
6.2 在 Vibecoding 中的角色定位
┌─────────────────────────────────────┐
│ AI Vibecoding 环境 │
│ │
┌───────────────┼─────────────────────────────────────┼───────────────┐
│ │ │ │
│ SDD │ DDD │ TDD + BDD │
│ (战略层) │ (架构层) │ (执行层) │
│ │ │ │
│ "做什么" │ "怎么组织" │ "怎么验证" │
│ │ │ │
│ spec.md │ 领域模型 │ 测试用例 │
│ 规格文档 │ 限界上下文 │ BDD 场景 │
│ │ 统一语言 │ │
└───────────────┼─────────────────────────────────────┼───────────────┘
│ │
│ AI 编码助手 │
│ (Claude / GPT / Copilot) │
│ │
└─────────────────────────────────────┘6.3 协同工作流
步骤 1: SDD — 编写规格文档（spec.md）
↓
步骤 2: DDD — 基于规格进行领域建模，定义限界上下文和统一语言
↓
步骤 3: BDD — 用 Gherkin 编写行为场景，作为验收标准
↓
步骤 4: TDD — 编写测试用例，定义具体的技术行为
↓
步骤 5: AI Vibecoding — 将以上所有文档作为上下文，让 AI 生成代码
↓
步骤 6: 验证 — 运行 TDD 测试 + BDD 场景，确保代码符合规格💡 关键洞察：在 AI Vibecoding 中，SDD 提供了”做什么”的答案，DDD 提供了”怎么组织”的答案，BDD 提供了”怎么验证业务行为”的答案，TDD 提供了”怎么验证技术实现”的答案。四者结合，构成了完整的工程化 Vibecoding 体系。
7. 实战案例：用四种方法论构建一个 AI 驱动的待办事项应用
7.1 SDD 阶段 — 定义规格
# spec.md — 待办事项应用
## 概述
一个支持任务创建、分类、优先级管理的待办事项应用。
## 功能需求
- FR1: 用户可以创建待办事项（标题、描述、截止日期、优先级）
- FR2: 支持高/中/低三个优先级
- FR3: 支持按优先级和截止日期排序
- FR4: 支持标记完成/未完成
- FR5: 支持按分类筛选7.2 DDD 阶段 — 领域建模
统一语言：
- Todo（待办事项）— 核心实体
- Priority（优先级）— 值对象：HIGH / MEDIUM / LOW
- Category（分类）— 值对象
- TodoList（待办列表）— 聚合根
- TodoCompleted（待办完成）— 领域事件7.3 BDD 阶段 — 行为规格
Feature: 待办事项管理
Scenario: 创建高优先级待办事项
Given 用户在待办事项页面
When 用户输入标题"完成项目报告"
And 用户选择优先级为"高"
And 用户设置截止日期为"2025-12-31"
And 用户点击"创建"按钮
Then 待办列表中显示新创建的事项
And 该事项标记为高优先级
Scenario: 标记待办事项为已完成
Given 待办列表中有一个未完成的事项"完成项目报告"
When 用户点击该事项的完成按钮
Then 该事项状态变为"已完成"
And 该事项从活跃列表中移除7.4 TDD 阶段 — 测试驱动实现
# test_todo.py
import pytest
from datetime import date
from todo import Todo, Priority, TodoList
def test_create_high_priority_todo():
todo = Todo.create(
title="完成项目报告",
description="Q4季度报告",
priority=Priority.HIGH,
due_date=date(2025, 12, 31)
)
assert todo.title == "完成项目报告"
assert todo.priority == Priority.HIGH
assert todo.is_completed is False
def test_mark_todo_as_completed():
todo = Todo.create("测试任务", priority=Priority.MEDIUM)
todo.mark_completed()
assert todo.is_completed is True
def test_todo_list_sorted_by_priority():
todo_list = TodoList()
todo_list.add(Todo.create("低优先级", priority=Priority.LOW))
todo_list.add(Todo.create("高优先级", priority=Priority.HIGH))
todo_list.add(Todo.create("中优先级", priority=Priority.MEDIUM))
active = todo_list.get_active_sorted_by_priority()
assert active[0].priority == Priority.HIGH
assert active[1].priority == Priority.MEDIUM
assert active[2].priority == Priority.LOW7.5 AI Vibecoding — 生成实现
将以上 SDD 规格 + DDD 模型 + BDD 场景 + TDD 测试一起提供给 AI：
提示词：
请根据以下规格、领域模型和测试用例，实现一个 Python 待办事项应用。
[附上 spec.md、DDD 模型定义、BDD 场景、TDD 测试代码]
要求：
1. 遵循 DDD 分层架构
2. 所有测试必须通过
3. 使用 Python enum 定义优先级
4. 使用 dataclass 定义实体和值对象AI 生成的核心实现：
# todo.py
from dataclasses import dataclass, field
from datetime import date
from enum import Enum
class Priority(Enum):
HIGH = 3
MEDIUM = 2
LOW = 1
@dataclass
class Todo:
title: str
description: str = ""
priority: Priority = Priority.MEDIUM
due_date: date | None = None
is_completed: bool = False
id: str = field(default_factory=lambda: str(hash(title)))
@classmethod
def create(cls, title: str, description: str = "",
priority: Priority = Priority.MEDIUM,
due_date: date | None = None) -> "Todo":
return cls(title=title, description=description,
priority=priority, due_date=due_date)
def mark_completed(self):
self.is_completed = True
class TodoList:
def __init__(self):
self._todos: list[Todo] = []
def add(self, todo: Todo):
self._todos.append(todo)
def get_active_sorted_by_priority(self) -> list[Todo]:
active = [t for t in self._todos if not t.is_completed]
return sorted(active, key=lambda t: t.priority.value, reverse=True)8. 总结
四大方法论在 AI Vibecoding 中的价值矩阵
| 方法论 | 解决的 Vibecoding 痛点 | 核心价值 | 推荐使用场景 |
|---|---|---|---|
| TDD | AI 生成代码的正确性无法保证 | 用测试为 AI 设定明确的”成功标准” | 所有需要质量保障的项目 |
| BDD | 需求与实现之间存在翻译损耗 | 用自然语言行为描述作为 AI 提示词 | 需要业务方参与的项目 |
| DDD | AI 生成的代码缺乏架构一致性 | 用领域模型为 AI 提供架构约束 | 复杂业务系统 |
| SDD | Vibecoding 缺乏系统性的需求管理 | 用规格文档作为 AI 的完整上下文 | 所有 AI 辅助开发项目 |
最佳实践建议
-
从 SDD 开始：在让 AI 写任何代码之前，先写好规格文档
-
用 DDD 建模：对于复杂系统，先定义领域模型和限界上下文
-
用 BDD 对齐：用 Gherkin 场景确保团队和 AI 对需求的理解一致
-
用 TDD 兜底：用自动化测试确保 AI 生成的代码持续正确
🎯 一句话总结：在 AI Vibecoding 时代，SDD 告诉 AI “做什么”，DDD 告诉 AI “怎么组织”，BDD 告诉 AI “行为是什么”，TDD 告诉 AI “怎么算对”。四者结合，让 Vibecoding 从”氛围驱动”升级为”工程驱动”。
Original 栈顶动态 栈顶动态