DSBTAI 開發神功

DSBTAI 時代的實用開發神功

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

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

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

THE PROBLEM 01 / 08

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

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

Prompt-first:直接叫 AI 寫

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

Idea→Prompt→AI→?

DSBT:先把意圖變成約束

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

Intent→Spec→Behavior→Test→AI

THE FOUR DISCIPLINES 02 / 08

四套成熟思想,不是硬排成四個 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 / 08

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

主線是 SDD → BDD → TDD → AI Implementation,而 DDD 是貫穿整個過程的 Modeling Discipline。真正拉開差距的是右邊那個分頁 — 當需求改變時,你從哪一層開始改。

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

    需求

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

  2. 02
    BDD

    情境

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

  3. 03
    TDD

    驗證

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

  4. 04
    AI

    實作

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

SHARED SOURCE OF TRUTH 04 / 08

同一份需求,每個角色只需要停在對他有意義的那一層。

DSBT 不是要所有人讀完所有東西。它把需求拆成四層,讓 PO、設計、QA、前端與後端讀同一個來源,但不必讀同一份細節。

同一份需求,每個角色只需要停在對他有意義的那一層。 Spec 範圍、非目標、成功條件 Scenario 每一種情況下該有什麼行為 Test 彼此的契約、邊界值與例外 Code 實作細節 PO UI/UX QA 前端 後端

如果測試是自動跑的,同步就不需要開會。

當 Spec 與 Feature 檔隨著 PR 一起進來,CI 亮的紅燈本身就是一份「這次改動會影響到誰」的通知。UI/UX 調了一個情境,後端會在 CI 上看到自己的測試紅了 — 不需要有人記得去講。

需求變更→ 修改文件→ PR→ CI→ RED→ 相關角色收到通知→ GREEN→ 變更成功

ONE FEATURE, END TO END 05 / 08

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

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

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

那 DDD 呢?為什麼這個範例裡看不到?

因為 DDD 是「按產品複雜度出場」的,不是每個功能都要跑一次。登入鎖定這種需求,名詞只有 User、Session 與失敗次數,邊界清楚、規則歸屬也沒有爭議 — 這時候硬跑一輪 DDD,只會製造儀式感。

  • 同一個名詞,各部門講的不是同一件事「訂單」對業務、倉儲、財務來說根本是三種東西 — 這時候不先統一語言,後面每一份 Spec 都會各寫各的。
  • 規則不知道該放哪這條折扣邏輯屬於訂單、促銷、還是會員?只要開始出現這種爭論,就代表邊界該被畫清楚了。
  • Spec 越寫越長,因為每句都要先解釋前提需求文件裡開始塞滿背景說明,通常不是文件寫太少,是共同語言還沒建立起來。

簡單說:DDD 修的是「我們對世界的理解」,SDD / BDD / TDD 修的是「這次要做什麼、怎麼證明」。前者不常變,所以不必每次都跑。

MAKE IT REAL 06 / 08

禮拜一早上,你的專案該長這樣。

DSBT 不需要新工具、也不需要新平台。它需要的,只是讓四層各自有一個固定的家 — 這樣人與 AI 才知道該去哪裡找答案、該去哪裡改。

project structure
project/
├── specs/                 # SDD · 需求、非目標
│   └── login-lockout.md
├── features/              # BDD · Given / When / Then
│   └── login-lockout.feature
├── tests/                 # TDD · 可執行的約束
│   └── login-lockout.test.ts
└── src/                   # 實作 · AI 的工作區

這個結構怎麼用

01

新需求:從 specs/ 開始

不要從 src/ 開始想。先讓需求有一個檔案可以被討論、被 review、被指出哪裡沒講清楚。

02

改需求:從 specs/ 一路往下改

spec → feature → test → code。順序反過來的時候,文件就會開始說謊。

03

Review:先看 features/ 的 diff

看 src/ 的 diff 只知道「改了什麼程式」;看 features/ 的 diff 才知道「行為變成什麼樣」。後者才是要被同意的東西。

NOTE檔名、副檔名、目錄名都可以換成你團隊習慣的樣子。重要的只有一件事:這四層各自有固定的位置,任何人(或任何 Agent)走進這個專案,都能在三十秒內知道需求寫在哪裡。

WORKING PRINCIPLES 07 / 08

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

01

需求先於實作

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

02

用例子消除模糊

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

03

測試是可執行的約束

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

04

需要時才做領域建模

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

05

不要讓 AI 改掉題目

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

06

從意圖一路追到證據

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

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

Make intent explicit before AI makes code.

FAQ 08 / 08

幾個最容易誤解的地方。

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。你需要的是一條能把模糊意圖逐步轉成明確需求、具體情境與可執行驗證的開發流程。