refactor: clarify misconceptions about BDD, emphasizing the importance of collaboration and avoiding implementation details in scenarios

Author: AndyWang505

src/content/blog/Behavior-Driven Development(BDD).md

@@ -147,8 +147,20 @@ Feature: 提款功能
 
 ## BDD 常見誤區
 
-許多人在使用 BDD 時會陷入一個誤區：為了自動化而寫 Given/When/Then。
+最常見的情況，是團隊把 BDD 當成一種測試框架，大家開始撰寫大量 Given / When / Then 腳本，卻沒有改變原本的開發流程，沒有真正的討論、沒有對齊需求，只是把測試換了一種語法來寫。
 
-但 BDD 的核心價值在於那一場「三個火槍手」的會議。工具（Cucumber, Gherkin）只是輔助，真正的魔法發生在當工程師問出：「如果使用者在提款時斷網會怎樣？」而 PO 拍案說：「好問題，我們來定義這個行為」的那一刻。
+而結果就會變成，程式寫完驗收結果一樣出現落差，只是多了一層看似結構化的腳本。
 
-這才是 BDD 真正能讓開發團隊擺脫「做白工」循環的關鍵。
+因為一旦少了 Discovery，那些 Scenario 就只是另一種形式的 Spec，而不是共識。
+
+另一個常見的偏差，是 Scenario 開始往「實作細節」傾斜，描述變成：
+
+- 應該打哪隻 API
+- 回傳什麼 status code
+- 執行什麼 function
+
+那其實就已經退回「工程師視角」了，也失去共通語言的特性。
+
+還有一種情況，是團隊試圖把所有情境都寫進 Scenario。
+
+雖然表面上看起來很完整，但實際上卻會帶來另一個問題「維護成本太高」，重複情境越來越多，且每次需求變動都需要大規模修改，最後這些文件反而變得沒有人想碰，因此重點應該放在確定那些重要的核心行為，而不是所有可能性。