BDD协作技能：让业务、开发、测试在同一张示例卡片上说同一种语言
- 它是什么：bdd-collaboration 是一个专注于行为驱动开发（BDD）协作环节的 AI 技能，用来主持"三个朋友会议"、示例映射工作坊和发现研讨会，而不是又一个写测试代码的框架。
- 它解决什么问题：需求在业务、开发、测试三方之间反复走样，往往不是工具问题，而是"没人把话说到一起"。这个技能把对话过程结构化，让分歧在编码前暴露。
- 怎么用：安装后在对话中直接以自然语言描述你的用户故事，让技能按发现研讨会的四段式流程（介绍—探索—文档—回顾）主持讨论，并产出 Gherkin 场景与待办问题清单。
- 关键亮点：内置示例映射的"故事卡—规则卡—示例卡—问题卡"模型、通用语言词汇表写法、活文档标签（如
@jira、@confluence、@since），以及一份现成的常见陷阱清单。 - 适合谁：产品经理、业务分析师、测试/QA、开发工程师，以及正在推行 BDD 但"卡在会议开不起来"的敏捷团队。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | BDD协作技能 |
| 技能英文名 | bdd-collaboration |
| 技能 ID | 14092 |
| 声明工具权限 | Bash、Read |
| 核心定位 | BDD 协作流程主持与场景产出 |
它到底解决什么问题
很多团队引入 BDD 时，真正的卡点不在自动化工具，而在协作：产品经理把需求写成一份文档丢过来，开发按自己的理解实现，测试按第三套理解写用例，等到验收才发现三方的"完成"定义完全不同。bdd-collaboration 针对的正是这个断层——它把"三个朋友会议"“示例映射”"发现研讨会"这些原本靠个人经验支撑的实践，变成一套 AI 可以陪跑的标准流程，并在过程中持续输出可复用的场景与词汇表。
一键安装的思路与步骤
这个技能的价值在于"装上就能开一场结构化的会"，所以安装原则是：入口优先查官方，权限尽量从简。
- 确认前提：你的 AI 客户端或平台需要支持"技能（Skill）"机制，并能授予 Bash 与 Read 两类工具权限。本技能只声明了这两个工具，属于偏只读、低风险的类型，不会主动改写你的代码库。
- 找到技能入口：在平台的技能市场、技能库或技能管理页面中，使用技能 ID
14092或英文名bdd-collaboration进行检索。具体入口名称与位置以官方说明为准。 - 执行安装：在技能详情页选择安装或添加，按提示确认权限范围。若平台支持"一键安装"，通常只需一次点击即可完成；若需要手动导入，请以官方提供的导入方式为准。
- 启用并验证是否生效：新建一个对话，先问一句"这个技能包含哪几种会议形式？“，若回答中出现"三个朋友会议”“示例映射”"发现研讨会"三类内容，并给出 5/20/15/10 分钟的议程分段，说明技能已正常加载。
- 准备输入材料：安装只是第一步，真正决定效果的是你喂给它的上下文——一条清晰写的用户故事、涉及的领域术语、已知的业务规则，越具体越好。
该技能的主要功能和特点
- 三个朋友会议主持：把业务/产品、开发、测试三个视角固定到同一场会议里，并给出五步结构——产品负责人展示用户故事、开发提出澄清问题、测试识别边缘情况、团队共同编写场景、所有人对验收标准达成一致。相比"拉个群随便聊聊"，它保证了三方视角一个都不缺席。
- 示例映射（Example Mapping）结构化输出：按"故事（黄色卡片）→规则（蓝色卡片）→示例（绿色卡片）→问题（红色卡片）“的层次组织讨论。比如"订单满 50 美元免运费"这条规则下，会同时列出"60 美元订单 = 免费”"49 美元订单 = 5 美元运费"两类具体示例，并把"正好 50 美元怎么办"单独拎成红色问题卡，避免边界被含糊带过。
- 发现研讨会的四段时间盒：介绍 5 分钟、探索 20 分钟、文档 15 分钟、回顾 10 分钟。探索阶段用三个固定提问驱动——“规则是什么？”“你能给我一个例子吗？”“可能出什么问题？”——让讨论不至于发散。
- 通用语言与领域词汇表：引导团队用 Gherkin 风格明确定义术语，例如把"订阅者"“流失订阅者”"赢回"写成功能描述里的定义句，让后续所有场景共用同一套词。
- 活文档的写法规范：支持在场景上挂业务文档链接与版本标签，如
@jira:PAY-123、@confluence:payment-rules、@since:v2.1，并记录"最后验证"日期，让场景随业务演进而非一次性归档。 - 自带最佳实践与陷阱清单：明确点出"跳过协作单独写场景"“只拉两个角色开会”“对业务方讲技术黑话”“让场景过期”“对简单功能过度记录”"提出问题却不跟进"等高频错误，相当于给会议配了一位有经验的引导者。
- 和普通工具比强在哪：Cucumber 一类工具解决的是"场景怎么跑"，文档工具解决的是"内容存哪"，而这个技能解决的是"话怎么谈拢"。它产出的不是又一份文档，而是一段被三方共同确认过的共识。
如何使用该技能？
步骤 1：启用技能并设定角色 在新对话中启用 bdd-collaboration，用一句话交代场景，例如：“接下来请以 BDD 协作技能的角色，主持我们的需求发现研讨会。”
步骤 2：提供上下文材料 给出用户故事原文、涉及的业务规则、已知的领域术语，以及参会角色。示例输入：
用户故事：作为一名在线商城客户，我希望订单满 50 美元享受免运费，以便节省配送成本。 已知规则：标准配送订单满 50 美元免运费，不满 50 美元收 5 美元运费；快递配送不论金额一律 15 美元。 参会角色：产品经理、后端开发、QA 各一名。
步骤 3：让技能组织三个朋友会议 请求它输出会议议程与三方提问清单。典型输出会包含：产品方补充的行为定义、开发方关于实现影响的问题（如运费计算发生在下单还是结算环节）、测试方识别的边缘情况（如刚好 50 美元、使用优惠券后金额变化、部分退货后的运费处理）。
步骤 4：要求生成示例映射 把讨论内容交给技能整理成卡片式结构，输出应包含：一条用户故事、若干条规则、每条规则下 2-3 个具体示例，以及红色的待确认问题列表。这一步的产出质量取决于你提供的示例是否具体——让技能主动追问"能再给我一个边界例子吗"是常态。
步骤 5：产出 Gherkin 场景 在示例确认后，要求把示例转成场景。输出形如：
功能：运费计算 场景：订单金额达到免运费门槛 给定一位客户已选购价值 60 美元的商品 当该客户选择标准配送并结账 那么运费应为 0 美元
步骤 6：建立与维护活文档 让技能为场景补充文档链接标签与版本标记，并约定复核周期。后续需求变更时，回到同一对话中说"这条规则改了"，让它同步更新场景与词汇表。
步骤 7：回顾与跟进 会议结束前，请技能朗读全部场景并列出遗留问题清单，逐条指定负责人。技能本身不会替你拍板，但会确保"没结论的问题"被显式记录下来。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| bdd-collaboration（本技能） | BDD 协作流程主持 | 三个朋友会议、示例映射、发现研讨会、通用语言、活文档规范 | 在支持技能的 AI 平台一键安装，自然语言调用；需授予 Bash 与 Read 权限 | 需求澄清会、跨角色对齐、复杂故事的边界梳理 | 优势：把"会议方法"产品化，上手几乎无学习成本；不足：不直接执行测试，产出仍需团队确认 |
| Cucumber / SpecFlow 等 BDD 框架 | 自动化测试执行框架 | 解析 Gherkin、绑定步骤定义、驱动自动化测试、生成报告 | 需要工程设计、依赖管理与 CI 集成 | 已有稳定场景、需要回归自动化 | 优势：可执行、可回归；不足：解决不了"场景从哪来""三方怎么谈"的前置问题 |
| 通用大模型直接对话 | 通用写作与问答 | 可临时生成 Gherkin 用例或会议提纲 | 零门槛 | 个人快速起草 | 优势：灵活；不足：缺少固定议程、卡片模型与陷阱清单，输出易漂移，团队难复现 |
| 传统需求文档 + 例会 | 文档与项目管理协作 | Jira/Confluence 记录需求、例会口头对齐 | 依赖组织流程与人的自觉 | 需求量大、流程规范的团队 | 优势：留痕完整；不足：易退化为"文档下发"，边缘情况与分歧往往在编码后才暴露 |
该技能的典型应用场景与实际体验情况
场景一：产品经理准备一场需求澄清会 痛点：每次评审会开成"产品念文档、开发点头、测试沉默"，散会后各写各的。使用方式：会前把用户故事丢给技能，让它先生成三个朋友会议的议程与三方提问清单，会上按清单逐条过。实际体验：上手难度低，几乎不需要学习提示词；最明显的效果是议程有了"节奏感"，5/20/15/10 分钟的时间盒让讨论不容易被单个技术细节拖走。注意事项：提问清单只是起点，产品经理仍需在会前补足业务背景，否则技能只能生成通用问题。
场景二：测试工程师梳理边界条件 痛点：规则看似清楚，一写用例就发现"满 50 美元免运费"里的"满"到底含不含 50 说不清。使用方式：让技能做示例映射，把规则拆成具体金额示例，并强制输出红色问题卡。实际体验：边界被显性化是最大收获，“正好 50 美元怎么办"这类问题会在编码前就被摆上桌。注意事项：示例卡需要真实数字支撑，如果只给"大额订单”"小额订单"这类模糊描述，输出也会跟着模糊。
场景三：新成员快速理解业务领域
痛点：新入职的开发或测试要花大量时间理解"流失订阅者""赢回"这类内部黑话。使用方式：让技能基于现有场景整理通用语言词汇表，并挂上 @jira、@confluence 等文档链接形成活文档。实际体验：词汇表对新人极其友好，比翻历史群聊高效得多。注意事项：活文档的价值完全取决于维护频率，标签和"最后验证"日期必须随需求变更同步更新，否则会加速过期。
场景四：跨团队构建共享领域知识
痛点：多个团队共用一套订单、支付逻辑，各自维护的场景版本不一致。使用方式：用活文档标签统一版本口径（如 @since:v2.1），在场景评审时邀请各团队利益相关者参与。实际体验：结构化的卡片输出便于跨团队传阅，减少"我以为你们那边也是这样"的误判。注意事项：多团队协作时，技能的产出应作为讨论底稿而非最终裁决，规则冲突必须由业务方拍板。
该技能能为用户带来的价值
把隐性经验变成可复制的流程。三个朋友会议、示例映射这些实践在书里都写着，但真正落地依赖一两位有经验的引导者。技能把这些方法固化成议程、卡片模型和提问清单，团队不必先培养专家就能开出一场结构完整的会。
把分歧提前到最便宜的阶段。需求阶段的误解成本最低，编码后返工成本最高。通过强制输出红色问题卡和边缘示例，技能让"没想清楚的地方"在写第一行代码之前就暴露出来。
降低跨角色的沟通门槛。业务方不必学 Gherkin 语法，开发不必充当翻译，测试不必靠猜。统一的词汇表让三方围绕同一套术语讨论，减少来回确认的轮次。
沉淀可长期复用的资产。示例映射的卡片、Gherkin 场景、领域词汇表、带版本标签的活文档，这些产出会随着项目推进不断累积，成为团队理解业务的知识底座，而不是散落在各次群聊里的碎片。
收敛个人与团队的效率差。个人随手让通用模型写几条用例也能用，但换个人、换次对话，风格和深度就变了。技能提供的固定结构让不同成员产出的场景具备可比性和可合并性，这对多人协作的团队尤为关键。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
A：在支持技能机制的 AI 平台中，用技能 ID 14092 或英文名 bdd-collaboration 检索后安装，通常一键即可完成，安装时需确认 Bash 与 Read 两项工具权限。是否收费、有哪些授权档位，取决于所在平台的商业政策，请以官方说明为准。
Q2：它是自动化测试工具吗？装了能直接跑用例吗？ A：不是。它只声明了 Bash 与 Read 两项权限，定位是协作流程的引导与场景产出，不负责执行测试。它产出的 Gherkin 场景可以作为 Cucumber、SpecFlow 等框架的输入，两者是上下游关系，不是替代关系。
Q3：必须整个团队都安装才有用吗？ A：不必。实践中常见做法是由产品经理或测试负责人单独使用，用它组织会议议程、整理卡片、输出场景初稿，再把结果带到会上讨论。当然，如果三方成员都装了，讨论的颗粒度和一致性会更好。技能负责结构，共识仍然要靠人来达成。
Q4：它生成的场景可以直接当作验收标准吗？ A：建议当作讨论底稿而非最终结论。技能擅长的是把规则拆成示例、把示例写成场景、把疑问列成清单，但业务规则的最终解释权在业务方。推荐的流程是：技能生成初稿 → 三方评审 → 确认后固化为活文档，并标注版本与复核日期。
Q5：和直接用大模型写 Gherkin 相比，差别在哪？ A：差别在"过程"而非"文本"。通用对话可以直接给你几条用例，但不会坚持三个视角齐全、不会强制输出红色问题卡、不会提醒你"跳过协作单独写场景"是个陷阱。如果你只是临时需要几条用例，通用对话够用；如果需求复杂、涉及多角色、需要团队复现同一套方法，这个技能的结构化价值才真正体现。