BDD场景编写：用 Gherkin 把业务需求变成可执行的行为规范
- 它是什么：BDD场景编写（bdd-scenarios）是一个专注于行为驱动开发（BDD）场景撰写的 AI 技能，帮你把模糊的业务需求翻译成结构清晰、可执行的 Gherkin 场景。
- 解决什么痛点：需求文档写得像"天书"、验收标准缺失、边缘案例永远靠测试同学临场发挥——这些问题它一次性对齐。
- 核心方法：以"具体、声明性、业务聚焦、独立"四条准则约束场景质量，配合 Rule 规则块、边缘案例清单和标签体系，让场景可读、可维护、可过滤执行。
- 适合谁用：产品经理、业务分析师、测试工程师、开发工程师，以及任何需要在编码前把"系统应该怎么表现"说清楚的团队。
- 一句话价值：让验收标准从"会后口头确认"变成"写进仓库的活文档"。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：BDD场景编写Skill 技能英文名：bdd-scenarios 技能ID：14089
它要解决的问题非常具体：在敏捷开发中，用户故事常常只有一句"作为用户，我希望……"，验收标准靠开会口述，测试用例在实现完成之后才补写，边缘案例（重复邮箱、空字段、非法格式）永远在线上才被发现。这个技能把"写场景"这件事变成一个有方法论、有范式、有检查清单的动作——你描述需求，它按 Gherkin 语法输出结构化的 Feature / Rule / Scenario，并且自动提醒你补上负面测试案例。
一键安装的思路与步骤
AI 技能的"一键安装"本质上是把一份技能说明挂载到 AI 助手的上下文里，让助手在遇到 BDD 相关任务时自动加载对应的写作规范。通用流程如下：
- 确认前提：你所使用的 AI 编程助手/客户端支持"技能（Skill）"机制，且已登录可用账号；同时建议具备仓库读取权限（该技能声明可用的工具为 Bash 与 Read，意味着它能读取项目中的需求文档、代码与已有 feature 文件来对齐上下文）。具体的支持范围与权限要求，以官方说明为准。
- 找到入口：进入技能市场/技能管理页，使用技能名称「BDD场景编写」或技能ID「14089」检索，也可以直接搜索英文名 bdd-scenarios。
- 一键安装：点击安装/启用按钮完成挂载。部分平台支持通过命令行或配置文件声明式引入技能，具体命令与参数以官方说明为准。
- 验证是否生效：安装后向助手提一个典型请求，例如"帮我为『用户注册』写 4 个 BDD 场景，包含 3 个边缘案例"，如果输出中包含
Feature:、Scenario:、Given/When/Then结构，并主动覆盖重复邮箱、非法格式等负面案例，说明技能已生效。 - 长期使用：把场景文件随代码一起入库（如
features/目录），让技能每次都基于项目真实文件续写，避免风格漂移。
该技能的主要功能和特点
- 场景质量四准则：强制场景满足"具体（只测一个行为）、声明性（描述 what 而非 how）、业务聚焦（用领域语言）、独立（不依赖其他场景）"，从源头杜绝"点击下拉菜单"式的实现细节泄漏。
- 业务语言 vs 实现语言的对照示范：内置"好场景 / 坏场景"对照示例，例如同样是折扣功能，好场景写"拥有黄金会员状态的客户结账时应应用 10% 折扣，最终总金额 90 美元"，坏场景写"我点击会员下拉菜单、JavaScript 计算 10% 折扣"——帮助团队建立可执行的评审标尺。
- 基于 Rule 的验收标准格式：支持
Rule:规则块把业务规则与具体场景分层，例如"30 天内可全额退款"这条规则下，分别给出 15 天订单（应全额退款）与 45 天订单（应被拒绝并提示"退货窗口已过期"）两个场景，规则改了只改一处。 - 边缘案例系统化产出：默认覆盖成功路径之外的负面与边界情况，如重复邮箱注册、无效邮箱格式、必填字段为空，并给出对应的用户可见文案断言。
- 标签与组织体系：支持
@authentication、@critical、@smoke、@security、@wip等标签，用于按业务域分组、按优先级过滤执行、标记进行中的场景。 - 最佳实践与常见陷阱清单：明确"从快乐路径开始、系统补充边缘案例、3-7 个步骤、实现前写场景、与利益相关者评审"，同时点名"实现后才补场景、单场景步骤过多、语言含糊、忘记负面案例、标签滥用"五类高频错误。
- 和普通测试工具的区别：Cucumber、SpecFlow 这类框架解决的是"场景怎么被执行"，而本技能解决的是"场景怎么被写好"——它不引入运行时，专注在需求到规范的翻译环节，且能结合仓库上下文持续产出。
如何使用该技能？
第 1 步：明确需求对象。 先用一句话写清你要规范的功能，例如"订单退款"。不要一上来就说"帮我写测试"，而是告诉助手业务规则。
第 2 步：触发技能。 在对话中描述任务即可，例如：
帮我为「订单退款」编写 BDD 场景。业务规则：下单 30 天内可全额退款，超过 30 天拒绝退款并提示"退货窗口已过期"。请用 Rule 结构组织，并补充至少 2 个边缘案例。
第 3 步：查看输出结构。 预期输出形如：
Feature: 订单退款
Rule: 30天内可全额退款
Scenario: 退货窗口内请求退款
Given 一个15天前下的订单
When 客户请求退款
Then 应处理全额退款
Scenario: 退货窗口后请求退款
Given 一个45天前下的订单
When 客户请求退款
Then 退款应被拒绝
And 客户应看到"退货窗口已过期"
第 4 步：迭代补充边缘案例。 继续追问"如果订单已发货呢？如果已经退过一次呢？"，技能会按"边缘案例场景"范式补出独立 Scenario，每个场景只断言一个行为。
第 5 步：加标签并组织。
要求加上 @refund @critical 之类的标签，便于后续按优先级跑 smoke 集或按域过滤。
第 6 步：评审与落库。
把场景贴进 features/*.feature 文件，与产品、测试一起过一遍：步骤是否超过 7 步？有没有出现"点击""输入框"这类实现词汇？负面案例是否齐全？
第 7 步：实现前先跑通评审。 技能明确建议"在实现前编写场景"，因此最佳实践是场景先合入仓库，再开始写代码，让场景成为开发的对齐依据。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| BDD场景编写（bdd-scenarios） | AI 辅助的场景撰写方法论技能 | Gherkin 场景生成、Rule 验收标准、边缘案例清单、标签组织、质量准则与陷阱检查 | 在支持技能机制的 AI 助手中按名称或技能ID安装；无需额外运行时，以官方说明为准 | 需求评审前快速产出验收标准、补齐负面案例、统一团队场景风格 | 优势：零运行时成本、产出即规范、能结合仓库上下文；不足：不负责场景的执行与报告，需配合 Cucumber 等框架落地 |
| Cucumber / Gherkin 原生 | 行为驱动开发的执行框架 | 解析 feature 文件、绑定步骤定义、生成测试报告 | 需引入依赖、编写 step definitions，对工程能力有要求 | 已有自动化测试体系的团队 | 优势：生态成熟、可直接跑 CI；不足：只负责执行，不解决"场景写得烂"的问题 |
| SpecFlow / Behave | .NET 与 Python 生态的 BDD 框架 | 与 Cucumber 类似的解析与执行能力 | 需按语言生态配置项目、维护绑定代码 | .NET 或 Python 技术栈团队 | 优势：贴合本语言栈；不足：跨语言协作时需重复维护，场景质量仍依赖人工 |
| 传统测试用例文档（Excel/用例管理平台） | 手工测试用例管理 | 用例编号、步骤、预期结果表格化记录 | 门槛低，但全靠人工撰写与维护 | 传统瀑布或半敏捷团队 | 优势：上手快、格式熟悉；不足：与代码脱节、不可执行、边缘案例容易遗漏、评审成本高 |
| 通用大模型直接生成测试用例 | 无约束的 AI 生成 | 任意格式输出 | 零门槛 | 临时补充思路 | 优势：灵活；不足：缺少统一范式，容易写出实现聚焦、步骤冗长的"坏场景"，风格不可控 |
该技能的典型应用场景与实际体验情况
场景一：产品经理写用户故事验收标准。 产品经理拿到"会员折扣"需求，过去只能写"会员结账时享受折扣"，开发理解成 5%，测试理解成所有会员。使用技能后，输入"黄金会员、购物车 100 美元、应享 10% 折扣、最终 90 美元"，立刻得到一段声明式场景，歧义当场消除。体验：上手几乎零学习成本，只要把业务规则说清楚即可；注意不要混入 UI 操作细节，否则会被"坏场景"示例打回。
场景二：测试工程师设计边缘案例。 测试同学最怕"快乐路径写得很漂亮，负面案例全漏掉"。技能会系统化补出重复邮箱、无效邮箱格式、空必填字段等场景，并给出用户可见的提示文案断言。体验：边缘案例的覆盖度提升最明显，尤其适合注册、支付、退款这类分支多的流程；建议在场景数量上做取舍，不必把每个分支都写成一个 Scenario。
场景三：开发在编码前对齐行为。
接手一个退款功能的开发，先把 Rule: 30天内可全额退款 写进 feature 文件，再写代码。体验：技能强调"实现前写场景"，实际使用中能明显减少返工；配合 @wip 标签，可以把还没实现的双因素认证场景先登记下来而不阻塞流水线。
场景四：团队统一场景风格与 CI 过滤。
多小组各自写 feature，风格五花八门。以本技能的四准则作为评审标尺，并用 @smoke、@critical、@security 标签分层，CI 中按标签过滤执行。体验：长期收益在于"可维护性"，场景不会随着迭代变成一坨 20 步的巨型脚本；注意标签要约定命名规范，否则会退化成堆砌。
整体上手难度：低。真正的门槛不在工具，而在团队是否愿意在写代码之前把行为说清楚。
该技能能为用户带来的价值
- 把需求歧义提前消灭：声明式的 Given/When/Then 让"到底应不应该打折""窗口期是 30 天还是自然月"这类问题在评审会上暴露，而不是在线上暴露。
- 边缘案例不再靠灵感：技能内置的负面测试清单，让重复邮箱、非法格式、空字段这类高频漏洞变成默认动作，而不是资深测试的个人经验。
- 场景即活文档：feature 文件入库后与代码同源演进，取代了容易过期的 Excel 用例表，新人读场景就能理解业务规则。
- 降低协作门槛：产品、测试、开发用同一套领域语言沟通，"业务聚焦"的约束让非技术角色也能读懂并参与评审。
- 长期可维护性收益：3-7 步的场景粒度、Rule 分层、标签组织，使回归测试集在多次迭代后仍然可读可筛，减少"改一个需求崩一片用例"的维护成本。
- 可量化的方向：场景评审返工次数下降、上线后因需求理解偏差导致的缺陷减少、负面案例覆盖率提升——这三项是最容易在团队内被观察到的变化。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？ 在支持技能机制的 AI 助手中，用「BDD场景编写」、英文名 bdd-scenarios 或技能ID「14089」检索并一键启用即可。是否需要付费、支持哪些客户端、是否提供命令行安装方式，取决于所在平台的规则，以官方说明为准。
Q2：它和 Cucumber、SpecFlow 是什么关系？会冲突吗？ 不冲突，是上下游关系。本技能负责"把需求写成好的 Gherkin 场景"，Cucumber/SpecFlow 负责"把 Gherkin 场景跑起来"。你可以先用技能产出并评审场景，再交给已有 BDD 框架绑定步骤定义执行。
Q3：我不用 BDD 框架，只是想要更清晰的需求文档，能用吗？ 完全可以。技能的四条准则（具体、声明性、业务聚焦、独立）和边缘案例清单本身就是一套需求写作方法，即使不落地为自动化测试，也能显著提升需求文档的可读性与完整性。
Q4：它会不会生成一大堆用不上的场景？ 技能的最佳实践明确要求"从快乐路径开始、系统地添加边缘案例、保持场景 3-7 个步骤"，因此更倾向于少而精。如果输出过多，直接告诉它"只保留关键规则与 3 个最高优先级边缘案例"即可收敛。
Q5：适合谁用？新手能上手吗？ 最适合产品经理、业务分析师、测试工程师和需要写验收标准的开发者。新手只需把业务规则用日常语言描述清楚，技能负责转成规范格式；真正的学习点在于理解"声明性"——描述系统应该做什么，而不是界面怎么点。