hero

Stephen Cresswell 把一個歷史悠久的 JavaScript BDD 函式庫翻新成 Yadda 3.0.0，但這篇文章真正重要的不是版本更新，而是他用親身經驗畫出的那條線：從「一個人監督一個 coding agent」，到「好幾個 agent 並行、人類變成瓶頸」。這條線現在每個開發者都在走。而他在為 BDD 辯護的過程裡，不小心以經把自己論點最脆的那根骨頭露出來——這正是這篇值得細讀的原因。

原文摘要

Stephen Cresswell 開頭宣布他把 Yadda 3.0.0 發佈到 npm。對不熟的人來說，Yadda 是給 JavaScript 用的 BDD（行為驅動開發）函式庫；跟 Cucumber 一樣，它把日常語言的規格對應到可執行的程式碼，但從設計之初就刻意不去規範規格該怎麼寫——比 Cucumber 鬆得多。

他舉了一組對照。傳統 Cucumber 風格的寫法是一連串 Given／When／Then 的固定句式（「Given a university, The University of East Anglia」「When Steve applies…」「Then … rejects the application」）；而 Yadda 允許你寫成更接近自然語言的版本（「The University of East Anglia offers a degree course in Computer Science」「When Steve applies…」「They reject his application」）。兩種都是可執行的規格，但作者覺得第二種好讀得多。

接著進入「Yadda 3 改了些什麼」。作者說 Yadda 3.0 大部分是一次現代化工程。Yadda 已經存在很久，倉庫裡累積了一堆如今已成歷史遺跡的整合與工具。Yadda 3 只支援 Node，移除了瀏覽器打包，以及 CasperJS、PhantomJS、Bower、Component 這些過時整合，測試套件也搬到 node:test。這些都有用，但沒什麼好寫的；真正值得寫的是另外兩件事。

第一件是「Claude 寫了大部分程式碼」。作者用 Claude Code 搭配 Opus 4.8 來做這次現代化。整個 Yadda 3.0 epic 本身就是 Claude 寫的，它把工作拆成一連串刻意分離的階段：先移除過時功能、更新工具鏈、把機械式格式化與行為變更分開處理、現代化原始碼、探索 API 變更、更新範例與 CI，最後收尾 metadata、文件與 TypeScript 定義。每個階段先規劃再實作，之後作者大多放手讓 Claude 去做。Claude 犯的錯少得驚人，更令人印象深刻的是，它抓出了一些在一開始看起來只是機械式現代化、很容易被漏掉的細微邊界案例。作者的介入非常少。

一個關鍵因素是 Yadda 本來就有一套完整的測試套件。作者還刻意避免在同一步驟裡同時要求 Claude 修改 production code 與對應的測試。如果 agent 同時改兩邊，綠色的測試套件會變成比較弱的證據，因為它可以在改實作的同時也改掉「正確」的定義。把這兩種變更分開，給了 Claude 一個更硬的外部約束。

從開工到發佈上 npm，大約花了一天（elapsed time），而且作者同時還在處理別的事。

作者回顧今年初他寫過一個實驗，探討為什麼 vibe coding 的體驗如此兩極化。當時的結論是：結果極大程度取決於 agent 怎麼被使用。一個被緊密約束、受到監督的 Claude，能非常快產出極好的結果；放它自己亂跑，就容易走向架構漂移、多餘的程式碼和營運債務。

那只是七個月前的事，而能力已經大幅進步。即便如此，說「Claude 現在幾乎不用介入就能寫這種程式碼」，仍然只搔到正在發生之事的皮毛。

接著進入核心段落「coding 不再是瓶頸」。要理解這會走向哪裡，應該停止想像「一個開發者跟一個 coding agent 對話」，改成考慮好幾個 agent 並行工作。已經有好幾種做法：直接開多個 Claude Code session；Git worktrees 讓每個 agent 在隔離的工作副本上做事；cmux 之類的工具讓管理一堆 Claude session 更容易；Claude Code 的 Agent View 則提供另一種方式，讓你看到多個 session 正在做什麼、哪些需要你的注意。

這些都能讓你比序列式工作快得多，但作者很快就撞上另一個極限：他自己管理並行工作的能力。他能舒適地同時推進三個任務，有時四五個；超過這個數，他就開始失去每個 agent 在做什麼、哪些決定已經做了、哪個任務在等他、接下來要 review 什麼的上下文。

到那個時候，模型沒有過載，機器也沒有過載，瓶頸是負責協調的人類。作者說他已經確信：好的編排（orchestration）是下一層重要的東西。

他不是唯一得到這個結論的人。他的同事 Marco 在《My AI Engineering Journey》裡描述了幾乎一模一樣的進程：從把 AI 當 autocomplete，經過受監督、受信任的 agent，最後到並行 agent——認知負荷變成真正的限制。Marco 走得比他更遠，並回應性地打造了 Otto（一個圍繞 Claude Code 與 worktrees 的編排 UI），接著又走向協調實作、審查、回饋與文件的 agent pipeline。

更大的重點是：AI 輔助的軟體開發仍在以驚人的速度前進。個人寫碼能力大幅提升，並行執行已經實用，而下一個限制越來越集中在「如何協調這些能力」。這方面的工具與方法也發展得一樣快，現在甚至比模型更新本身更重要。

這就帶回了 Yadda。接著「為什麼現在要更新一個 BDD 函式庫？」作者說他一直認為 BDD 有幾個價值。

第一，用日常語言寫需求會逼你把領域講清楚，更重要的是逼你一致地講。如果你在寫實作之前先寫這些規格，那套領域語言有種習慣，會滲透進整個 codebase——同樣的概念開始出現在類別名、函式名、API 定義、資料庫 schema、CSS class 和使用者介面裡。這給了 codebase 一種事後非常難達成的連貫性。

第二，可執行規格遠比傳統的程式化測試更容易理解。一個 PM、分析師或領域專家，有實際機會看懂「When Steve applies to study Computer Science, Then the university rejects his application」；他們要從一個充滿 fixtures、mocks、builders 和 assertions 的 Jest 測試裡擠出同樣的意思，機會小得多。

第三，BDD 為功能性測試提供了一個有用的抽象層。規格描述意圖，step 的實作處理機制細節——selector、導航、瀏覽器互動。這提供了跟 Page Object 模式類似的一些好處：UI 的變更常常可以被吸收在抽象層裡，而不是滲漏到幾百個測試裡。

不過一直都有成本。BDD 測試一開始寫起來比較久：你得想語言、建立可重用的 step，還得抵抗把程序式腳本偽裝成英文的誘惑。回報來得比較晚——透過更好的領域建模、更好的溝通、更好維護的功能性測試。這種延遲回報一直讓 BDD 比較難說服人，但作者認為 AI 改變了這個經濟學。

最後一段是「可執行規格是 agent 非常好的上下文」。作者請我們考慮一個越來越有可能發生的工程工作流：會議被自動轉錄、存成 GitHub discussions；這些 discussion 被分析、用來更新專案 wiki；wiki 被挖掘成需求與 issue；這些 issue 再由一群 coding agent 接手、實作、審查與協調。

一個 wiki 可以告訴你「某人認為系統應該做什麼」，可以告訴你「系統以前做什麼」，甚至可以告訴你「agent 推論系統應該做什麼」；但 wiki 本身沒辦法告訴你「系統實際上是不是真的這樣做」。可執行規格可以。這讓 BDD 在 agent 化的開發環境裡，比以往有趣得多。

BDD 昂貴的部分一直是「產出與維護規格」，而 AI 讓這份工作大部分變便宜。一份逐字稿、一段討論或一條需求，幾乎可以無痛地轉換成一份候選規格，人類只需專注在「語言與行為是否正確」，而不是把整份東西打出來。一旦被接受，那份規格就不只是文件——它變成一份契約。

實作 agent 可以用它理解所需行為；測試 agent 可以用它判斷該驗證什麼；審查 agent 可以用它挑戰一份實作；CI 可以持續驗證它。因為它是可執行的，它跟軟體行為的耦合，是 wiki 頁面永遠達不到的。

這裡有個有趣的倒轉。BDD 最初有一部分是為了讓軟體規格對人類更有用而誕生的，但可執行規格在「大部分軟體由機器撰寫」的時代，可能反而更有價值。自然語言給 agent 豐富的領域上下文，而可執行步驟確保規格始終紮根在系統行為裡。

還有一個變更（加在 Yadda v3.1.0）：支援用 GitHub-flavoured Markdown 撰寫 feature 規格。這讓它們在倉庫裡更好讀，更重要的是，讓它們能自然地住在專案 wiki 和其他「人類與 agent 用來理解系統的關鍵知識產物」旁邊。同一份規格現在可以寫成 Markdown 的 Feature／Scenario 格式。它仍然是一份可執行規格，但在 GitHub 上查看時，看起來和行為都更像專案其餘的文件。

最後作者收尾：Yadda 3 已經在 npm 上，原始碼、文件與範例都在 GitHub。

城武觀點

Cresswell 這篇文章的賣點是「coding is no longer the bottleneck」和「AI changes the economics of BDD」。我賭這兩個句子都錯，而且證據就藏在他自己的文字裡。

先把「coding 不再是瓶頸」拆開。他說對的那一半是：當他同時開三個、五個 Claude session，模型沒過載、機器沒過載，先垮的是他自己記不住每個 agent 在做什麼。所以真正的瓶頸不是 coding，是協調。但協調是什麼？協調就是思微與判斷——知道該做什麼、做到哪、接下來該做什麼。AI 沒有把這個變便宜，它只是把它從「動手寫」的環節，整包搬到「動腦盯」的環節。瓶頸從來都在人類的頭上，只是位置從鍵盤移到螢幕前面而已。

然後是他最漂亮、也最致命的那段自白。他刻意把「改 production code」和「改 test」拆成兩步，理由是：如果 agent 同時改兩邊，綠色測試套件就會變成弱證據，因為它可以在改實作的同時改掉「正確」的定義。請把這句話再讀一遍。他的意思是——唯一能真正約束一個 agent 的，是那份 agent 自己沒寫過的東西。測試之所以還有證據力，純粹因為它是「上一輪、別的手、不同的意圖」留下來的。這等於承認了：一旦 agent 能碰到「正確」的定義，測試就只是它自己的回音。那請問，當整條 pipeline 從逐字稿、wiki、需求到規格，全都沾過 agent 的手，那個「agent 沒碰過」的錨點還剩什麼？只剩一個：簽名的人類。

這就接到他為 BDD 辯護時的那個漏洞。他說可執行規格會「變成一份契約」、會「持續扣住系統行為」，聽起來 BDD 終於迎來春天。但同一段他又說，規格是由 AI 從會議逐字稿草擬的，人類只需要「專注確認語言和行為是否正確」。注意那個「只」字背後藏了什麼——「確認是否正確」從來就不是打字，而是 BDD 從誕生第一天起最貴、最難、最沒人想碰的那部分。AI 把便宜的部分（打字）變得更便宜，然後把最貴的部分（判定什麼叫正確）原封不動地留給一個更薄的人類層。經濟學沒有被改變，只是帳單的品項被重新分類了。

所以他這篇文章其實是一個無意的招供：BDD 最貴的部分，正是 AI 完全沒碰到的那部分。契約值多少錢，從來不取決於寫契約的紙有多便宜，而取決於在上面簽名的那個人。那個簽名，到今天為止，仍然是人類的。

（順帶一提，這篇文章本身也是 LLM 輔助寫出來的。打字便宜，是真的；但上面這幾段的立場，是我自己的——這正是我想講的那件事。）

城武的未解檔案——打字變免費的那天，整條產線上唯一還值錢的，就是那個到現在 AI 還簽不了的簽名。