許多人在 AI coding 的過程中，總是在追求某種輕量的 SDD 工具，並希望自己跟這套工具可以合而為一，然後花更多時間在 review 細節上，但我不同意，我認為這個想法注定使你低效。
我認為 SDD 工具就是要替你代勞各種細節——我們該追求的並不是輕量工具，而是 “重工程思想” 的 AI 工具。人類累積了數十年的軟體工程實踐，最核心的道理就在於：你如何從業務的問題領域，一路把語言、邏輯、流程映射到你的程式碼裡面？
為什麼以前我們在追求 DDD（領域驅動設計）時，往往很難導入到各種團隊中？原因就是裡面有太多大同小異的資料和 Mapping 需要人工維護。好比說 DDD 從 Ubiquitous Language 一路到 Bounded Context，再到裡面的 Tactic Pattern，最後到程式碼實作，這過程中的層層映射是需要有紀律地落實要求的。大多數團隊走到後面總是排斥寫更多的文件、做更多的溝通，往往就比較難以落實。
但現在 AI 時代已經來了，這些問題早就應該被 AI 解決。以前那些我們感受到需要大量人為維護的地方，現在都能靠 AI 來維護。所以我會說，DDD 的時代正式來臨了。
在這個時代下，你追求的工具就不該是那些原始的工具，好比說 SpecKit 或 OpenSpec。那些工具只是把你的想法寫成一個或多個 Markdowns，再逼你去閱讀，這個過程本來就不夠人性化。如果你的工具本身不具備軟體工程 / DDD 的 Know-how，那麼這些負擔不都還是在你自己身上嗎？
因此，我研發了一套我認為最貼近實務方法論、能夠落地的工具。基本上軟體工程一定是 Domain Driven 的，但為了區別，我選了一個最能把業務語言映射到程式碼的實踐，那就是「行為驅動開發」（BDD）。
BDD 的核心在於：
- 抓取 Domain Expert 與 Solution Expert 之間，對於系統行為的共同理解與詞彙。
- 將這些詞彙寫成「可執行規格」。
- 可執行規格背後執行的是測試程式碼，所以能夠駕馭 AI 所產出的程式。
當你的業務語句和測試程式碼有所綁定時，你的業務語句就能直接決定 AI 開發出來的程式碼是對是錯。所以 BDD 其實是我們做到規格驅動開發中，一個最反英雄主義、最能夠擴充到企業級實踐的路線。
因此，這些 Skills 一定是 Heavy Engineering 的，只是那個「Heavy」燒的是你的 Token，而不應是你的心智。這個 Token 本來就該燒，因為它帶來的可靠度絕對會是其他 SDD 工具的數十倍。如果多燒一點 Token 就能換取數十倍的可靠度，那這就是這個時代最值得的投資。
另外我們不只是做出了 aixbdd 的 skills，也圍繞在他之上，開發出我們認為比較人性化的視覺化介面工具，這個工具主打更人性化地「需求澄清」過程，並且能做到 AI x BDD 兩權分立 — 讓 Agent 去監督另一個 Agent 把 BDD 的紅燈 → 綠燈 → 重構做到扎實。
