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。