似曾相識的故事

一間明亮的會議室，桌上擺著白板、便條紙和一杯熱咖啡。顧問大衛受邀來協助一家軟體團隊釐清需求與品質問題，與會者包括專案經理小李（PM）、研發工程師阿志（RD）和測試人員小玲（QA）。

大衛（顧問）：各位，今天我們先聊聊「現在最痛的點」是什麼？別急著談工具或流程，先從最直接的困擾說起。

(1) 「不知道從哪裡開始」

小李（PM）：（嘆氣）
「我們看過各種 DevOps、CI/CD、SBE、BDD……最後還是摸不到頭緒。大家最能共識的就是『品質』這件事，因為誰也不會反對要把品質顧好。」
大衛：
沒錯，品質是個絕對安全牌。但光講「品質」很籠統，得再往下拆──要從哪個面向切入，才不會全團隊陷入「到底該先做什麼」的焦慮。

(2) 主管最有感：需求就是他們的責任

小李（PM）：
「對我來說，需求這塊直接關乎我的 OKR，業績能不能上、客戶滿不滿意，都指望我把需求訂得又清又準。所以一提到『需求品質管理』，我整個人起來很專注！」
大衛：
「很好，只要需求先釐清，其他人就能跟著進度往下做，不會卡在半路出現無解問題。」

(3) 工程師的同一聲音：需求模糊＋文件缺失

阿志（RD）：（翻開筆記本）
「拜託，PM 給的需求常常像口述歷史，一下要這樣、一下又改那樣，文件幾乎沒有，生出一堆疑問還得一直揪人開會。」
小玲（QA）：
「對啊，寫測試腳本前我根本不知道要驗什麼，只能到處問開發或 PM，痛點一樣到處都是。」

(4) 程式開發問題太多、太分散

阿志：
「可是除了需求，我們專案還有架構、相依套件、效能、資安……每個人遇到的技術挑戰不一樣，根本沒辦法全團隊在同一頁。」
大衛：
「那就先不要一次解決所有技術問題，而是在『需求釐清』這個最共通的痛點上取得突破，團隊先練習一個範例如何從討論到驗收，再循序漸進去處理其他技術議題。」

(5) 過度聚焦自動化，卻沒解決核心痛點

阿志：
「很多顧問都跟我們說，先導入 Cucumber、SpecFlow，寫自動化測試才能顯示技術含量。但寫完腳本後，需求一改自動化又要重寫，根本沒解決『需求不清』的問題。」
小玲：
「對，測試腳本只是後段流程，真正的痛點在前面──沒有人一起討論好例子，導致自動化只是形式，卻沒幫助團隊共識。」

(6) 「沒空做自動化」成為放棄的藉口

阿志：（苦笑）
「我很想把自動化弄好，但我每天都在追進度、修 Bug，哪來時間寫測試腳本？於是我們根本沒機會好好搞 SBE/BDD。」
大衛：
「這就回到一開始的重點：先把『手動撰寫範例』當作主要任務，大家只要用 10 分鐘就能在白板上，把一個核心業務場景寫成 Given/When/Then。等共識到手，再慢慢把最關鍵的場景導入自動化。這樣既減少門檻，也能讓自動化更有價值。」

大衛（結語）：
「總結一下，我們不需要從工具或自動化起步，而是從『用業務範例落實需求品質』開始。下一步就讓我們挑一個最常見的功能場景，實際動手在白板或文件上寫出來，先把共識抓到，大家覺得如何？」
眾人：
「好！（紛紛拿起白板筆）我們開始吧！」

從上面對話中你可以，要改的東西太多，痛苦的東西也是五花八門，說了半天後最容易找到的共識就是品質，尤其是對於需求的品質。無論是主管、PM 還是工程師，都對「需求說不清、改了又改」深感痛苦。從這點開始入手，不僅能快速凝聚共識，更能真正提升開發效率與產品品質。

GenAI – 另一個更高速的自動化??

但是，就是這個但是，最近這一年，往往還會出現下一段對話：

會議室裡，白板上還留著「實例化需求」的討論筆記。眾人先歸納接下來最想釐清的問題，真正的解方將由顧問在下一階段詳述。

小李（PM）：（皺眉）
「最近聽大家都在談 GenAI，能不能用 AI 直接產出需求範例？或是接上 MCP，讓 AI agent 幫我們跑整個流程？」

阿志（RD）：
「沒錯，我看過有人說，只要丟給 GenAI，需求品質就自動搞定，也能快速產生測試自動化程式，馬上就可以交付。」

小玲（QA）：（搖頭）
「我試過用 AI 產文字範例，裡面常常漏掉邊界條件，還要再請 PM 補、開發再釐清，最後搞得更混亂。」

小李（PM）：
「那 MCP + AI agent 呢？聽說可以自動管版本、自動提醒該補文件，真的能省掉一堆會議？」

阿志（RD）：
「技術上可行，但如果 AI 沒搞清楚我們的業務邏輯，最後還是得回到白板前手動討論。」

小玲（QA）：
「大家似乎都以為 GenAI 上場就沒問題，其實不是這麼一回事……」

「實例化需求」到底能幫上什麼忙？

大家都知道要改善品質，但多數人不知道該從哪裡下手。

這時候，「實例化需求（Specification by Example, SBE）」就像一盞燈塔。它不是什麼高大上的流程，而是讓團隊坐下來，針對一個需求，用具體例子來對話，共同釐清到底什麼才算「做完」，什麼情境要處理，邊界在哪裡，錯誤要如何應對。

當範例清楚，開發就不需要靠猜；測試也不必事後補破網。它讓團隊的共識，不再是靠記憶或口述，而是白紙黑字、可以回顧、可以討論的東西。這，就是實例化需求最實用的地方。

那在 GenAI 時代，實例化需求還重要嗎？我認為：比以往更關鍵。

很多人誤以為，現在有 AI 了，就可以「跳過對話，直接產出文件」。但事實上，GenAI 再厲害，也沒辦法幫你想清楚「你到底要什麼」，尤其是那些模糊的業務邏輯與例外狀況。

AI 不會讀心，它只能根據你給它的上下文工作。

而「實例化需求」正好提供了 AI 理解需求的最佳上下文：具體、結構化、可被驗證的輸入。

在 GenAI 流程中，SBE 可以：
 幫你快速生成清晰、一致的 Prompt 範本
 幫你讓需求文件與測試流程有一致依據
 幫你建立 MCP + AI agent 的追蹤基礎
 幫你補上 AI 漏掉的場景與業務例外
 最重要的：讓 AI 成為共識的加速器，而不是混亂的放大器

所以，這系列文章的初衷是：不是要介紹一個又一個新工具，而是想告訴大家：
從需求的共識開始，你才能真的讓流程自動化有意義，讓 GenAI 有舞台發揮。

你不需要一次推動整套實例化需求，你只需要從白板上的第一個例子開始，就能一點一滴把團隊從混亂中拉回對話中心。就請大家繼續看下去吧！！