Prompt-first:直接叫 AI 寫
速度快,但需求、邊界、例外情境與驗收標準都藏在聊天上下文裡。Agent 很容易把沒說清楚的地方自行補完。
THE PROBLEM 01 / 06
一句「幫我做登入」對人類已經模糊,對沒有完整上下文的 Agent 更危險。DSBT 的目的,是在 AI 動手之前,把意圖逐步收斂成可理解、可討論、可驗證的形式。
速度快,但需求、邊界、例外情境與驗收標準都藏在聊天上下文裡。Agent 很容易把沒說清楚的地方自行補完。
先定義需求,再展開情境,最後把重要行為變成測試。AI 仍然負責高速實作,但不能輕易改掉題目。
THE FOUR DISCIPLINES 02 / 06
DSBT 不重新發明 DDD、SDD、BDD、TDD,而是把它們放進 AI Coding 最實用的位置。主線是 Spec → Behavior → Test;DDD 在 Domain 複雜時持續校正大家對世界的理解。
讓大家對 Domain 使用同一套語言,釐清邊界、概念與規則歸屬。
把模糊意圖整理成需求、範圍、限制、非目標與成功條件。
把抽象需求展開成具體情境,讓產品、工程與 AI 都知道什麼時候該怎麼表現。
先把預期行為寫成會失敗的測試,再讓實作逐步通過並持續重構。
THE FLOW 03 / 06
DDD 不是一定要先跑完的第一步,而是貫穿整個開發過程的 Modeling Discipline。真正線性的部分,是 SDD → BDD → TDD → AI Implementation。
五次登入失敗後,帳號鎖定 15 分鐘。
已失敗 4 次,再錯一次 → 鎖定 15 分鐘。
先寫會失敗的測試,明確期待 lockedUntil。
AI 在既定 Spec、Scenario 與 Test 內完成程式。
ONE FEATURE, END TO END 04 / 06
同一條需求會一路變得更具體,但每一層回答不同問題。人可以討論 Spec,團隊可以確認 Scenario,AI 則被 Test 約束。
# Login Lockout Goal 降低暴力嘗試密碼的風險。 Requirements - 連續登入失敗五次後,帳號鎖定 15 分鐘。 - 登入成功後,失敗次數歸零。 - 鎖定期間不得建立 Session。 Non-goals - MFA - OAuth - Password reset
# Login Lockout Goal Reduce password brute-force risk. Requirements - After 5 consecutive failures, lock for 15 minutes. - A successful login resets the failure count. - No Session may be created while locked. Non-goals - MFA - OAuth - Password reset
Scenario: 第五次登入失敗 Given 使用者已連續登入失敗 4 次 And 帳號目前沒有被鎖定 When 使用者再次輸入錯誤密碼 Then 登入失敗 And failedAttempts 應變成 5 And 帳號應被鎖定 15 分鐘 And 不應建立 Session
Scenario: Fifth failed login Given the user has failed login 4 times And the account is not locked When the user enters a wrong password again Then login fails And failedAttempts becomes 5 And the account is locked for 15 minutes And no Session is created
it("locks account after fifth failed login", async () => {
const now = new Date("2026-08-19T10:00:00Z")
const user = createUser({ failedAttempts: 4 })
await expect(
login(user, "wrong-password", now)
).rejects.toThrow()
expect(user.failedAttempts).toBe(5)
expect(user.lockedUntil).toEqual(addMinutes(now, 15))
expect(sessionCreated()).toBe(false)
})
// AI implements only after the contract is clear. recordLoginFailure(now: Date) { this.failedAttempts += 1 if (this.failedAttempts >= 5) { this.lockedUntil = addMinutes(now, 15) } } // 不要自行修改 Spec。若實作與 Spec 衝突,回報衝突,而不是改題目。
WORKING PRINCIPLES 05 / 06
需求規格要先於技術實作。不是需求的 API、框架、資料庫選擇,不要過早寫死。
一條抽象需求通常不夠。BDD 用具體例子把「我以為你懂」變成大家真的懂。
測試不是最後補上的品質報告,而是 AI 實作時最硬的可執行邊界。
DDD 不必為簡單 CRUD 製造儀式感;當名詞、邊界、規則歸屬開始混亂時再讓它出場。
實作遇到衝突時,AI 應該回報 Spec 問題,而不是偷偷改行為讓測試好過。
重要需求應能一路追到 Scenario 與 Test;也要能從測試反查它到底保護哪條需求。
Make intent explicit before AI makes code.
先把人的意圖說明白,再讓 AI 動手。
FAQ 06 / 06