pd-bdd — Behavior Driven Development Skill

用自然语言精确描述产品行为，让 AI 一次把需求做对。

核心理念

"你要个病弱林黛玉，AI 给你完美交付了一个秃头程序员，还告诉你测试都通过了——但那不是我要的林妹妹。"

TDD 能防止 bug，但无法保证功能符合预期。BDD 用自然语言（而非代码）描述产品的预期行为，补上这层保险。

BDD + TDD = 约束 AI 的双保险：

• TDD 防止 AI 把代码改出 bug
• BDD 让 AI 做的东西精确符合你的要求

核心公式

Given（假如） → 处于什么状态
When（当）    → 发生了什么操作
Then（那么）  → 应该得到什么结果

实例：战棋游戏 — 吸血鬼攻击

需求：吸血鬼攻击敌人时，恢复造成伤害等量的生命值

Scenario: 吸血鬼攻击敌方单位

Given 棋盘上有两个棋子：
  - 吸血鬼：攻击力 2，满血 5 点，当前 1 点血
  - 敌方主将：10 点血，位于吸血鬼邻格

When 吸血鬼攻击一次敌方主将

Then:
  - 敌方主将变为 8 点血（受到 2 点伤害）
  - 吸血鬼变为 3 点血（恢复 2 点血）

使用流程

Step 1：接收需求

用户提供一句话或简短的需求描述。例如：

"毒蛇可以使用技能给敌方单位施加中毒状态，中毒单位每回合结束掉 1 点血"

Step 2：生成 BDD 用例

将需求转换为多个 Given-When-Then 用例。AI 必须主动识别边界情况，包括：

• 正常路径（happy path）
• 边界条件（最小值、最大值、零值）
• 异常处理（错误输入、状态冲突）
• 叠加/互斥规则（状态是否可叠加）

模板：

# BDD 用例：{需求名称}

## 用例 1：{场景名称}
**Given** {初始状态描述}
**When** {操作描述}
**Then** {预期结果}

## 用例 2：{场景名称}
...

Step 3：用户确认

将生成的用例展示给用户确认。AI 必须主动确认不确定的细节，例如：

• "中毒状态是否可以叠加？"
• "如果敌人血量不足被消灭，恢复的生命值如何处理？"
• "是否存在免疫中毒的单位类型？"

根据用户反馈修改用例，直到确认。

Step 4：编写测试代码

将确认后的 BDD 用例转换为测试代码：

• 每个 Given-When-Then 用例对应一个测试函数
• 测试函数名应清晰反映场景（如 test_vampire_attack_recover_hp）
• 测试中保留 BDD 注释作为说明

测试代码模板：

def test_{场景名}():
    """
    BDD: {场景描述}
    Given {初始状态}
    When {操作}
    Then {预期结果}
    """
    # Given
    ...
    
    # When
    ...
    
    # Then
    ...

Step 5：实现代码

根据 BDD 用例和测试代码实现业务逻辑，确保所有测试通过。

Step 6：验证

运行实际程序，确认功能与 BDD 用例描述一致。

AI 时代为什么 BDD 特别有用？

关键洞察：

• 传统开发中 BDD 使用率低，不是因为没用，而是因为沟通成本高
• AI 时代这个成本被大幅降低，收益（沟通精确性）不变甚至更高
• 你只需要写一句需求描述，AI 分分钟给你几个精确的行为描述

BDD 用例编写规则

✅ 好的用例

Scenario: 中毒单位每回合扣血

Given 战场上有一个单位，当前 5 点血，处于中毒状态

When 该回合结束

Then 该单位变为 4 点血

特点：

• 用自然语言，不说代码
• 状态精确（具体的数值、具体的位置）
• 因果关系明确（When 做了什么，Then 会怎样）
• 一个用例只测一个场景

❌ 不好的用例

需求：中毒机制要好玩

问题：

• 模糊，没有具体行为
• 无法验证
• "好玩"对 AI 来说是歧义

❌ 过于笼统

当单位中毒时会掉血

问题：

• 没说初始状态（Given 缺失）
• 没说掉多少血
• 没说什么时候掉血

与 TDD 配合使用

用户提交需求
     ↓
BDD 生成用例（Given-When-Then）
     ↓
用户确认 + 补充细节
     ↓
TDD 写测试代码（先写跑不通的测试）
     ↓
实现代码（让测试通过）
     ↓
实际验证

双保险机制：

1. BDD 确保功能描述精确（不会做成秃头程序员）
2. TDD 确保代码实现正确（测试通过不会出 bug）

适用场景

对代码结构的要求

TDD 的一个优势：能测试的代码结构，天然是好结构。

要让 BDD + TDD 流程有效工作，代码应该：

• 将业务逻辑与界面分离（如剥离状态层）
• 接口清晰，依赖明确
• 可以脱离界面单独运行测试

如果代码结构不可测，先重构再写用例。

快速启动

当用户提供需求时，按以下步骤执行：

1. 读取需求，理解意图
2. 生成 3-5 个 BDD 用例（覆盖正常路径 + 边界条件）
3. 询问用户确认或补充细节
4. 确认后，将用例转为测试代码
5. 实现代码，让测试通过

提示词示例（用户可以说）：

"用 pd-bdd 分析这个需求：{需求描述}"

或者直接描述需求，Skill 会自动识别并执行 BDD 流程。