Yadda 3.0.0：AI 智能体时代的 BDD

Yadda 3.0.0 已发布到 npm。Yadda 是一个用于 JavaScript 的 BDD（行为驱动开发）库，与 Cucumber 类似，它把自然语言规格说明映射为可执行代码，但它的设计初衷是不规定具体的书写方式。例如，你不需要写出一长串“Given/And/When/Then”的固定句式，而可以直接用更像日常阅读的句子来描述行为，比如“该大学提供计算机科学学位课程，入学要求为 ABB；Steve 是一名 A-Level 毕业生，物理和数学均为 D；当他申请时，大学拒绝了他的申请。”这种写法简洁易读，同时仍然是可执行的规格说明。

Yadda 3.0 的绝大部分工作是现代化改造。项目移除了对浏览器打包和 CasperJS、PhantomJS、Bower、Component 等早已过时的集成，现在只支持 Node。测试套件迁移到了 node:test，开发流程采用 Biome 和 lefthook，源码更新为 ES6 语法，并新增了 TypeScript 定义，同时加入了 Playwright 和 Puppeteer 的当前示例。这些改动让项目更符合当今 JavaScript 生态的实践。

真正值得注意的是，这次现代化改造大部分是由 Claude Code 完成的，使用的模型是 Opus 4.8。Yadda 3.0 的史诗级任务本身也由 Claude 编写，它将工作拆分为多个明确分开的阶段：移除过时功能、更新工具链、将格式调整与行为变化分开、现代化源码、探索 API 变更、更新示例和 CI，最后完善元数据、文档和 TypeScript 定义。每个阶段都先在计划中确定，然后作者基本上让 Claude 自主执行。Claude 犯的错误很少，而且还能识别出一些容易被忽略的边界情况，作者只需要很少的人工干预。一个关键因素是 Yadda 已有相当全面的测试套件，同时作者刻意避免让 Claude 在同一阶段同时修改生产代码和对应测试，因为如果实现和测试一起变，绿色测试套件的说服力会变弱。从开始到发布大约只花了一天时间，期间作者还在并行做其他事情。

作者由此谈到一个更大的趋势：编码已不再是瓶颈。与其想象一个开发者与一个代理对话，不如考虑多个代理并行工作。目前已经有多种方式，例如同时运行多个 Claude Code 会话，用 Git worktrees 隔离工作副本，用 cmux 管理多个会话，或者用 Claude Code Agent View 观察各会话状态。这些方法能显著加速开发，但作者很快遇到了新的限制：自己管理并行工作的能力。舒服的状态是同时推进三到四个任务，再多就会失去上下文。此时模型没有过载，机器也没有过载，瓶颈变成了协调这些工作的人。作者确信良好的编排是下一个重要层次。他的同事 Marco 也经历了类似的转变，从 AI 自动补全、受监督的代理，到并行代理，最终发现认知负荷成为制约，并为此构建了 Otto 编排界面和代理流水线。

那么为什么现在要更新一个 BDD 库？作者一直认为 BDD 有价值：用自然语言写需求能迫使你清晰、一致地表述领域概念，并且这些概念会自然地渗透到代码、API、数据库和界面中；可执行规格说明比传统的程序化测试更容易被产品经理、分析师等非技术人员理解；BDD 还为功能测试提供了良好的抽象层，把意图与选择器、导航等实现细节分开。过去 BDD 的代价是编写和维护成本较高，但 AI 正在改变这种经济学。可执行规格说明对代理来说是极好的上下文：会议记录可以被转录成讨论和 wiki，wiki 被挖掘成需求和 issue，再由一组编码代理实现、审查和协调。一个 wiki 页面无法告诉系统是否真的能做到某件事，但可执行规格可以。因此，在 AI 代理的环境中，BDD 变得更有吸引力。AI 让规格的生成变得廉价，人们只需要关注语言和行为是否正确；一旦被接受，规格就不再只是文档，而是一份契约。实现代理用它们理解行为，测试代理知道要验证什么，审查代理可以用来质疑实现，CI 持续验证，而且由于它是可执行的，始终与真实行为保持耦合。

另外，Yadda v3.1.0 增加了将特性规格编写为 GitHub 风格 Markdown 的支持。这使得规格在仓库中更容易阅读，也能自然地与项目 wiki 和其他知识产物共存。同一个规格现在可以写成包含“# Feature”和“## Scenario”标题的 Markdown 文件，在 GitHub 上看就像普通文档，但它仍然是可执行的。Yadda 3 已可在 npm 上获取，源码、文档和示例都在 GitHub。