你是否曾在 Vibe Coding 開發過程中，發現 AI 產出的程式碼邏輯漏洞百出，改到懷疑人生？
在傳統開發裡， Spec 就是正義。但在與 AI 協作時，我們更像是「導演」。
想要讓那個很有才華但偶爾會「發瘋」的 AI 演員演出一場好戲，你需要的是兩套強大的工具：EARS（劇本邏輯） 與 BDD（驗收劇照）。
EARS：把需求變成「邏輯積木」
你一定遇過這種 PM，需求寫著：「系統要好用一點」、「處理速度要快」。這在寫程式時根本是災難。
EARS (Easy Approach to Requirements Syntax) 說白了，就是要把這些「模糊的形容詞」轉化為「精準的指令」。
EARS 就像是頂級的 Prompt Engineering，它強迫你把話講得邏輯封閉。主要的 5 種句型，讓你隨時都能「鎖死」需求邊界：
| 類型 | 說明 |
|---|---|
| Ubiquitous (通用型) | 系統必須...（就像呼吸一樣，隨時都要遵守）。 |
| Event-driven (事件驅動型) | 當 [事件發生] 時，系統必須...。 |
| Unwanted Behavior (異常處理型) | 如果 [壞事發生] 了，系統必須...（這就是 Error Handling 的靈魂）。 |
| State-driven (狀態驅動型) | 當處於 [某種狀態] 時，系統必須...。 |
| Optional Feature (選配型) | 若有 [特殊功能] 時，系統必須...。 |
EARS 幫你立下嚴謹的規矩
讓 AI 沒辦法在邏輯上「一本正經地胡說八道」。
BDD：把測試變成「電影劇本」
如果 EARS 是嚴謹的合約，那 BDD (Behavior Driven Development) 就是「有血有肉的故事」。它不測 a == b，它測的是「使用者覺得發生了什麼事」。
BDD 用的語法叫 Gherkin（小黃瓜，就是要清脆爽口！），核心三部曲如下：
| 語法 | 說明 |
|---|---|
| 🎬 Given (背景) | 設定開拍前的場景（例如：口袋裡有 100 塊）。 |
| ⚡ When (動作) | 導演喊 Action 的那一刻（例如：點了一份大辣魷魚）。 |
| ✅ Then (結果) | 觀眾看到的結局（例如：拿到香噴噴的魷魚，錢包少了 60 塊）。 |
透過這種「說故事」的方式，即便不是工程師也能跟我們溝通，而 AI 也能透過這些「實例」理解你的真正意圖。
EARS vs BDD 的差異是什麼？
這兩者各司其職，結合起來才是真正的「無敵」。
| 特性 | EARS (需求語法) | BDD (行為驅動) |
|---|---|---|
| 核心精神 | 精準定義 (消除歧義) | 共識與驗證 (說故事) |
| 像是在寫… | 法律條文 | 電影劇本 |
| 主要聽眾 | PM、架構師、規則制定者 | 工程師、QA、AI 助手 |
| 解決痛點 | 「你做的跟我想的不一樣！」 | 「這功能邏輯對了，但沒法用！」 |
簡單來說：EARS 幫你定規矩，BDD 幫你確認結果。
EARS 高階運用：Vibe Coding 實戰
我們在 Prompt 裡直接塞進 EARS 的規則和 BDD 的劇本讓 AI 開發。
你可以試試看開發「電子錢包扣款」時這樣下指令：
# 任務：請幫我實作扣款 API
## EARS 邏輯 (請嚴格遵守)：
- [Event-driven]: 當收到請求，必須驗證餘額。
- [Unwanted]: 如果餘額不足，回傳 400 錯誤碼 'INSUFFICIENT_FUNDS'。
- [State-driven]: 當錢包處於 'Frozen' 狀態，拒絕所有扣款。
## BDD 驗收劇本 (作為 Jest 測試用)：
Scenario: 餘額不足扣款失敗
Given 用戶餘額為 50 元
When 收到扣款 100 元的請求
Then API 應回傳 HTTP 400
And 錯誤代碼應為 'INSUFFICIENT_FUNDS'
你試試看丟給 AI，產出來的 Code 不會偏離目標太多！
總結
不管是在日常開發還是 Vibe Coding，EARS 與 BDD 都是提昇效率的神器。
EARS 幫你立下嚴謹的規矩，BDD 幫你確認演出的結果。