DSBT
AI-era practical development discipline

DSBTAI 時代的實用開發神功

AI 已經很會寫程式。真正困難的,變成如何把人的意圖說清楚、把重要情境補完整,並把它們轉成 AI 不容易擅自偏離的約束。

定義需求。明確情境。建立共識。讓 AI 遵守。

DSBTINTENT → PROOF
D · Understand統一語言與邊界
S · Specify把需求說清楚
B · Describe把情境講明白
T · Verify把行為變成測試
Domain → Spec → Behavior → Test → AI → Code

THE PROBLEM 01 / 06

AI Coding 的瓶頸,正在從「寫不出來」變成「理解錯了」。

一句「幫我做登入」對人類已經模糊,對沒有完整上下文的 Agent 更危險。DSBT 的目的,是在 AI 動手之前,把意圖逐步收斂成可理解、可討論、可驗證的形式。

Prompt-first:直接叫 AI 寫

速度快,但需求、邊界、例外情境與驗收標準都藏在聊天上下文裡。Agent 很容易把沒說清楚的地方自行補完。

IdeaPromptAI?

DSBT:先把意圖變成約束

先定義需求,再展開情境,最後把重要行為變成測試。AI 仍然負責高速實作,但不能輕易改掉題目。

IntentSpecBehaviorTestAI

THE FOUR DISCIPLINES 02 / 06

四套成熟思想,不是硬排成四個 ceremony。

DSBT 不重新發明 DDD、SDD、BDD、TDD,而是把它們放進 AI Coding 最實用的位置。主線是 Spec → Behavior → Test;DDD 在 Domain 複雜時持續校正大家對世界的理解。

D

DDD

Domain-Driven Development

讓大家對 Domain 使用同一套語言,釐清邊界、概念與規則歸屬。

核心問題我們講的是同一件事嗎?
S

SDD

Spec-Driven Development

把模糊意圖整理成需求、範圍、限制、非目標與成功條件。

核心問題到底要做什麼?
B

BDD

Behavior-Driven Development

把抽象需求展開成具體情境,讓產品、工程與 AI 都知道什麼時候該怎麼表現。

核心問題在每種情況下會發生什麼?
T

TDD

Test-Driven Development

先把預期行為寫成會失敗的測試,再讓實作逐步通過並持續重構。

核心問題怎麼證明程式真的做到?

THE FLOW 03 / 06

從人類意圖,收斂成 AI 可以遵守的工程約束。

DDD 不是一定要先跑完的第一步,而是貫穿整個開發過程的 Modeling Discipline。真正線性的部分,是 SDD → BDD → TDD → AI Implementation。

DDD · Domain Thinking統一語言 · 劃清邊界 · 確認規則屬於誰
01 · SDD

需求

五次登入失敗後,帳號鎖定 15 分鐘。

02 · BDD

情境

已失敗 4 次,再錯一次 → 鎖定 15 分鐘。

03 · TDD

驗證

先寫會失敗的測試,明確期待 lockedUntil。

04 · AI

實作

AI 在既定 Spec、Scenario 與 Test 內完成程式。

ONE FEATURE, END TO END 04 / 06

用登入系統,把 S → B → T 跑一次。

同一條需求會一路變得更具體,但每一層回答不同問題。人可以討論 Spec,團隊可以確認 Scenario,AI 則被 Test 約束。

login-lockout · DSBT trace
# Login Lockout
Goal
降低暴力嘗試密碼的風險。
Requirements
- 連續登入失敗五次後,帳號鎖定 15 分鐘。
- 登入成功後,失敗次數歸零。
- 鎖定期間不得建立 Session。
Non-goals
- MFA
- OAuth
- Password reset

WORKING PRINCIPLES 05 / 06

DSBT 的重點不是多寫文件,而是降低意圖失真。

01

Requirement before implementation

需求規格要先於技術實作。不是需求的 API、框架、資料庫選擇,不要過早寫死。

02

Examples remove ambiguity

一條抽象需求通常不夠。BDD 用具體例子把「我以為你懂」變成大家真的懂。

03

Tests are executable constraints

測試不是最後補上的品質報告,而是 AI 實作時最硬的可執行邊界。

04

Domain modeling when needed

DDD 不必為簡單 CRUD 製造儀式感;當名詞、邊界、規則歸屬開始混亂時再讓它出場。

05

Do not let AI rewrite the question

實作遇到衝突時,AI 應該回報 Spec 問題,而不是偷偷改行為讓測試好過。

06

Trace intent to proof

重要需求應能一路追到 Scenario 與 Test;也要能從測試反查它到底保護哪條需求。

Make intent explicit before AI makes code.

先把人的意圖說明白,再讓 AI 動手。

FAQ 06 / 06

幾個最容易誤解的地方。

DSBT 是一套全新的 DDD / SDD / BDD / TDD 嗎?
不是。DSBT 不重新定義這四套方法,而是把它們組合成一套面向 AI Coding 的實用心法:用 Domain 思維保持語意正確,用 Spec 定義需求,用 Behavior 明確化情境,用 Test 建立可執行約束。
一定要照 D → S → B → T 的順序嗎?
不用。真正較線性的主線是 SDD → BDD → TDD。DDD 更像貫穿式的 Modeling Discipline;當 Domain 很簡單時,它甚至可以非常輕量。
SDD 跟 BDD 不是很像嗎?
有重疊,而且這很正常。SDD 偏向「規則、範圍與需求是什麼」;BDD 則把這些規則轉成具體可討論的情境與例子。
為什麼不先把 API 規格寫完?
如果 API 本身就是外部契約,它可以是 Spec 的一部分;但如果只是實作選擇,就不應該過早固定。DSBT 刻意把需求規格和技術設計分開。
DSBT 只適合 AI 嗎?
不是。這些思想本來就對人類團隊有價值;只是 AI Coding 把「上下文遺失、意圖誤解、擅自補完」放大了,所以 DSBT 在 AI 時代尤其實用。

先說清楚,再讓 AI 寫。

你不需要更多神奇 Prompt。你需要的是一條能把模糊意圖逐步轉成明確需求、具體情境與可執行驗證的開發流程。