Yadda 3.0.0：AI智能体时代下的行为驱动开发

# Yadda 3.0.0：AI 代理时代的 BDD 来源：http://www.stephen-cresswell.com/2026/08/15/Yadda-3.0.0-BDD-in-the-Age-of-AI-Agents.html 我刚在 npm 上发布了Yadda 3.0.0 (https://www.npmjs.com/package/yadda)。 对于不熟悉它的人来说，Yadda (https://github.com/acuminous/yadda) 是一个用于 JavaScript 的 BDD 库。它像 Cucumber 一样，将自然语言规格说明映射到可执行代码，但它从一开始就被设计成对这些规格说明的编写方式要求宽松得多。 这意味着，你不必写成这样： `` Given a university, The University of Bouvet Island And The University of Bouvet Island offers a degree course in Computer Science with entry requirements of ABB And an A-Level graduate, Steve And Steve has a D in Physics And Steve has a D in Maths When Steve applies to study Computer Science at The University of Bouvet Island Then The University of Bouvet Island rejects the application `` 而可以写成： `` The University of Bouvet Island offers a degree course in Computer Science The entry requirements for which are ABB Steve is an A-Level graduate With a D in Physics And a D in Maths When Steve applies to study Computer Science at The University of Bouvet Island They reject his application `` 两者都是可执行的规格说明。我个人觉得第二种写法更易读。 ## Yadda 3 有什么变化？ Yadda 3.0 的大部分工作是现代化改造。 Yadda 已经存在了很长时间，代码库中积累了许多针对 JavaScript 生态系统中如今已属历史产物的部分的集成和工具。Yadda 3 仅支持 Node.js，移除了浏览器打包和过时的集成（如 CasperJS、PhantomJS、Bower 和 Component），将测试套件迁移到 `node:test`，采用了 Biome 和 lefthook，将源代码现代化为 ES6 语法，并增加了包括 Playwright 和 Puppeteer 在内的当前示例。现在它还附带了 TypeScript 类型定义。 这些都很有用，但写起来并不特别有趣。我认为此次发布中有两点意义更为重大。 ## Claude 编写了大部分代码 我使用 Claude Code 配合 Opus 4.8 进行了 Yadda 的现代化改造。 Yadda 3.0 的史诗故事 (https://github.com/acuminous/yadda/issues/344)（本身也由 Claude 撰写）将工作拆分成一系列刻意分离的阶段：移除过时功能、更新工具链、将机械格式化与行为变更分开进行、现代化源代码、探索 API 变更、更新示例和 CI，最后完成元数据、文档和 TypeScript 类型定义。 我们在实施每个阶段之前都进行了规划，然后我基本上就让 Claude 自己去完成工作。它犯的错误少得惊人，更令人印象深刻的是，它发现了一些相当细微的边界情况，这些在最初看似机械化的现代化过程中很容易被忽略。我几乎不需要干预。 一个重要因素是 Yadda 已经拥有全面的测试套件。我也刻意避免让 Claude 在同一步骤中修改生产代码和相应的测试。如果一个代理同时改变两者，通过的测试套件作为证据的效力就会变弱，因为它可以在改变实现的同时，自由地改变“正确性”的定义。将这些变更分开，为 Claude 提供了更坚实的外部约束。 从开始工作到包发布，大致耗时一天，而在此期间我还在并行处理其他事情。 今年初，我曾写过一篇关于一项实验的文章，探讨了为何对 vibe coding 的体验如此两极分化 (https://www.stephen-cresswell.com/2026/01/01/Why-Are-Experiences-Of-Vibe-Coding-So-Polarised.html)。当时的结论是，结果在很大程度上取决于代理的使用方式。一个受到严格约束和监督的 Claude 能够非常快速地产生极好的结果。如果放任其自由行事，它往往会导致架构漂移、不必要的代码和运维债务。 那仅仅是在七个月前，而其能力已经取得了巨大进步。即便如此，说 Claude 现在几乎无需干预就能编写这样的代码，也只是触及了变化的皮毛。 ## 编码不再是瓶颈 要理解这一切的发展方向，与其考虑单个开发者与单个编码代理对话，不如考虑多个代理并行工作，这会更有帮助。 目前已有几种方法可以做到这一点。你可以简单地运行多个 Claude Code 会话。Git worktrees (https://git-scm.com/docs/git-worktree) 让每个代理在隔离的工作副本上工作。像 cmux (https://cmux.com/) 这样的工具使得管理多个 Claude 会话变得更加容易，而 Claude Code Agent View 则提供了另一种方式来查看多个会话正在做什么以及哪些需要关注。 所有这些方法都能让你比串行工作快得多，但我很快就遇到了另一个限制：我自己管理并行工作的能力。我能轻松地同时推进三个任务，有时是四个或五个。超过这个数量，我开始丢失上下文信息，比如每个代理在做什么，做了哪些决策，哪个任务在等我，以及我接下来需要审查什么。 这时候，模型没有过载，机器也没有过载。瓶颈在于协调工作的人类。我确信良好的编排是下一个重要的层次。 得出这一结论的并非只有我一人。我的同事 Marco 在他的《我的 AI 工程之旅》(https://www.marcomark.co.uk/blog/ai-engineering-journey.html) 中几乎描述了完全相同的进展过程，从 AI 作为自动补全工具，到受监督的、可信的代理，再到并行代理，此时认知负荷成为制约因素。他在这条路上走得比我更远，其回应是构建了 Otto——一个围绕 Claude Code 和 worktrees 的编排 UI，然后转向了协调实现、评审、反馈和文档的代理工作流。 更重要的一点是，AI 辅助的软件开发仍在以极快的速度发展。单个编码能力已显著提升，并行执行已切实可行，而下一个限制因素越来越是所有这些能力的协调。相关的工具和方法也在以同样快的速度发展，如今其重要性甚至超过了模型更新。 这又让我回到了 Yadda。 ## 为什么现在要更新一个 BDD 库？ 我一直认为 BDD 很有价值，原因有几个。 首先，用自然语言编写需求迫使你清晰地表达领域概念，更重要的是，鼓励你以一致的方式表达。如果你在编写实现之前先写这些规格说明，这种领域语言往往会渗透到整个代码库中。相同的概念开始出现在类名和函数名、API 定义、数据库模式、CSS 类和用户界面中。这赋予了代码库一种连贯性，事后追溯是很难实现的。 其次，可执行的规格说明比传统的编程测试更容易被理解。产品经理、分析师或领域专家有相当大的机会能理解： `` When Steve applies to study Computer Science Then the university rejects his application `` 他们从一个包含 fixtures、mocks、builders 和 assertions 的 Jest 测试中提取相同含义的可能性则小得多。 第三，BDD 为功能测试提供了一个有用的抽象层。规格说明描述了意图，而步骤实现则处理选择器、导航和浏览器交互等机制。这提供了一些与 Page Object 模式 (https://www.selenium.dev/documentation/test_practices/encouraged/page_object_models/) 相同的好处：用户界面的更改通常可以被吸收在抽象内部，而不是泄露到数百个测试中。 不过，这总是有代价的。BDD 测试最初编写起来更耗时。你需要思考语言，创建可复用的步骤，并抵制编写伪装成英文的过程式脚本的诱惑。回报会在后期体现，通过更好的领域建模、更好的沟通和更易于维护的功能测试。这种延迟的回报一直使 BDD 难以证明其合理性，但我认为 AI 改变了这个经济账。 ## 可执行的规格说明是代理的绝佳上下文 设想一种日益成为可能的工作流程。 会议被自动转录并存储为 GitHub 讨论。这些讨论经过分析，用于更新项目 wiki。wiki 被挖掘出需求和问题。然后，这些问题由一组编码代理接手、实现、评审和协调。 Wiki 可以告诉你某人认为系统应该做什么。它可以告诉你系统过去做过什么。它甚至可以告诉你一个代理推断出系统应该做什么。但它本身无法告诉你系统是否真的做到了这一点。可执行的规格说明可以。这使得 BDD 在代理化的开发环境中比以往任何时候都更有趣。 BDD 的高昂成本在于制作和维护规格说明。AI 使大部分工作变得廉价。一份记录、讨论或需求可以几乎不费吹灰之力地转化为候选规格说明，人类则专注于语言和行为是否正确，而不是把所有内容都打出来。一旦被接受，这份规格说明就不仅仅是文档了。它成为了一份契约。 实现代理可以使用它来理解所需的行为。测试代理可以使用它来确定需要验证什么。评审代理可以使用它来质疑实现。CI 可以持续验证它。因为它是可执行的，所以它能够以一种 wiki 页面永远无法做到的方式，与软件的行为保持耦合。 这里有一个有趣的逆转。BDD 的创建部分是为了让软件规格说明对人类更有用，但当大部分软件由机器编写时，可执行的规格说明可能被证明更有价值。自然语言为代理提供了丰富的领域上下文，而可执行的步骤则确保了规格说明始终与系统行为紧密关联。 另一个变化（在 Yadda v3.1.0 中添加）是支持用 GitHub 风格的 Markdown 编写功能规格说明。这使得它们在代码库中更易阅读，更重要的是，允许它们与项目 wiki 和其他人类与代理用来理解系统的关键知识工件自然并存。同一份规格说明现在可以写成： `` # Feature: University applications ## Scenario: Applicant does not meet the entry requirements - The University of Bouvet Island offers a degree course in Computer Science - The entry requirements for which are ABB - Steve is an A-Level graduate - With a D in Physics - And a D in Maths - When Steve applies to study Computer Science at The University of Bouvet Island - They reject his application `` 它仍然是可执行的规格说明，但在 GitHub 上查看时，它的外观和行为更像项目其余部分的文档了。 Yadda 3 可在 npm (https://www.npmjs.com/package/yadda) 上获取，源代码、文档和示例位于 GitHub (https://github.com/acuminous/yadda)。