別讓自動化成為你的誤解：實例化需求的核心是「對話」，而非程式碼

作者：柯文傑（三叔公）

這幾年，軟體開發圈掀起了一股「規格即實例」的風潮。隨著 Spec by Example (SBE)、到最近火紅的 Vibe Coding，再加上生成式 AI 的強大產能，開發團隊比以往任何時候都更加興奮。我們常聽到這樣的對話：「太好了，AI 可以幫我寫範例！」、「我可以更快完成自動化！」、「Scenario 越多越安全！」。

然而，當這股熱潮席捲開發現場時，我觀察到一個令人擔憂的趨勢：大家幾乎把所有的精力都投注在「如何產出腳本」與「如何跑 CI/CD」，卻唯獨遺忘了最核心的那件事——實例化需求的核心不是為了「自動化」，而是為了達成「共同理解」。

迷思：開發人員的「單機自動化」秀

在許多敏捷團隊中，最常見的劇情是：開發人員在看完需求文件後，憑藉著卓越的理解力與 AI 的協助，迅速寫出一套美觀、格式正確的 Gherkin 場景，並引以為傲地展示 CI 系統上一片翠綠的測試結果。

這種做法看起來既敏捷又充滿科技感，但本質上卻是極其危險的。因為當你追問：「這些範例是誰一起討論出來的？」或是「PM 與 QA 是否確認過這些案例符合商業邏輯？」時，換來的通常是尷尬的沉默。這種缺乏對話的過程，我們不稱之為 SBE，而應稱之為「自動化你的個人想像」。 如果範例只是某個人寫爽的 Code Artifact，它就失去了作為「溝通媒介」的靈魂。

策略一：先有談話，才有範例的落筆

範例不應該是開發者獨自在電腦前構思出來的 UI 腳本，它更像是一份「決策具體化」的會議記錄。

真正的實例化需求起源於 PM、Dev 與 QA 這「三方（Three Amigos）」的共同對話。範例存在的價值在於：當 PM 說出一個模糊的商業規則時，開發者與測試者能透過「舉例」來探測邊界。例如：「如果使用者在結帳前一秒取消，會發生什麼事？」。透過這些對話，我們才能把那些躲在文字背後的歧義抓出來，在程式碼動工前就達成共識。

策略二：釐清意圖，而非填寫格式

我們舉例是為了把模糊的商業邏輯拆開、揉碎，直到每個人心目中的產品輪廓都重疊在一起。

很多團隊會陷入「填空迷思」，覺得只要寫出 Given/When/Then 就算完成了任務。但如果沒先釐清「為什麼要這個功能」，寫再多例子也只是在填補格式。

範例應該是為了服務「理解意圖」而存在的。當我們對意圖不夠清晰時，盲目追求範例的數量，只會讓團隊在錯誤的細節中迷路，最後產出一堆符合規格卻不符合市場需求的程式碼。

策略三：自動化是「理解之後」的驗證，而非目標

Scenario 顯示綠燈，並不代表需求已經正確落實，它僅僅代表程式碼符合「撰寫範例者的想像」。

我們必須釐清優先順序：理解是因，自動化是果。如果你跳過理解直接追求自動化，那麼當需求變更或出現 Bug 時，那些原本用來保命的測試腳本，反而會變成沉重的技術債務。

自動化應該是用來「保護共識」的，而不是用來取代對話的。沒有共識的綠燈，就像是一張沒有價值的保單，無法在風險發生時提供實質的保障。

策略四：AI 是助手，它無法代替你做決策

AI 確實可以幫你把一個範例擴充成十個邊界測試，也可以幫你把口語轉成漂亮的 Gherkin 格式，但它無法坐在會議室裡，感受到 PM 的焦慮或 QA 的擔憂。

AI 可以補齊案例，但不能補齊「共識」。它能幫你把文件寫得更專業，但無法判斷什麼才是對客戶最重要的需求意圖。決策的責任始終在人身上，而非工具。

結語：跑得快，更要走得對

AI 與各種新興的 Coding 模式確實縮短了實作的距離，但這不代表我們可以省略「人與人對齊」的過程。

請記住，範例不是程式碼，它是協作的產物。 別讓冷冰冰的綠燈，取代了團隊之間那溫暖且必要的對話。