精選
Vibe Coding SDD SpecKit 工作流程 最佳實踐
SDD x VibeCoding：當結構遇見直覺
探索如何結合規格驅動開發與 Vibe Coding，獲得兩者的優勢：創意自由與系統化實作。
2026年1月19日 • 20 min read • 作者：Claude World
如果你能用自然語言描述願景，同時又以規格驅動開發的嚴謹度來實作呢？
這就是結合 Vibe Coding 與 SDD（規格驅動開發）的承諾。
兩個極端
純 Vibe Coding
你："幫我做一個任務管理 app，氛圍要極簡禪風，
像紙本筆記本那樣。"
Claude：[建立 app]
你："加入子任務"
Claude：[加入子任務]
你："其實，讓它可以無限嵌套"
Claude：[重構為無限嵌套]
你："然後加截止日期... 還有標籤... 還有..."結果： 開始很快，但範圍蔓延。沒有文檔。難以維護。六個月後，你不記得為什麼任何東西會這樣運作。
純 SDD
你：/speckit-specify 任務管理功能
[撰寫 5 頁規格書]
[釐清 12 個模糊點]
[建立技術計劃]
[定義 20 個任務]
[終於開始寫程式]結果： 嚴謹且可追溯，但前期投入大。有時候你只是想探索一個想法，而不是寫一篇論文。
甜蜜點：VibeSDD
VibeSDD 結合了 vibe coding 的創意自由與 SDD 的結構嚴謹：
┌─────────────────────────────────────────────────────┐
│ VibeSDD 流程 │
│ │
│ ┌──────────┐ │
│ │ VIBE │ 用自然語言自由描述 │
│ │ 輸入 │ "我想要 X，感覺像 Y" │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ 規格 │ Claude 結構化為規格格式 │
│ │ 捕捉 │ 你審閱並精煉 │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ VIBE │ 用 vibe 語言迭代規格 │
│ │ 精煉 │ "這個多一點，那個少一點" │
│ └────┬─────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ SDD │ 結構化實作 │
│ │ 執行 │ 完整可追溯 │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────┘為什麼這有效
Vibe Coding 捕捉意圖
當你說「讓它感覺像 Notion 但更簡單」，你傳達了：
- 心智模型（區塊、彈性）
- 美學（乾淨、現代）
- 使用者體驗（快速、直覺）
- 複雜度層級（更簡單 = 更少功能）
這些寶貴的資訊如果用正式規格來寫，需要好幾頁。
SDD 提供護欄
規格防止：
- 範圍蔓延（「再加一個東西…」）
- 遺忘需求（「等等，我們需要那個？」）
- 實作偏離（「這不是我的意思」）
- 文檔債務（「這是怎麼運作的？」）
結合：創意嚴謹
| Vibe Coding | + | SDD | = | VibeSDD |
|---|---|---|---|---|
| 快速探索 | 結構化輸出 | 快速規格化 | ||
| 直覺輸入 | 清晰需求 | 願景到規格 | ||
| 迭代友善 | 可追溯變更 | 受控演進 |
VibeSDD 工作流程
階段 1：Vibe 規格化
不寫正式規格，而是描述你的願景：
## The Vibe
「我想建立一個給自由工作者的支出追蹤器。
它應該感覺像個人財務日記，不是企業會計工具。
關鍵感受：
- 快速新增支出（5 秒內）
- 分類很滿足（也許可以滑動？）
- 月度概覽清晰（不壓迫）
- 處理金錢數據感覺可信
想像：極簡如 Things 3，色彩如 Notion，
但用於金錢。」Claude 將此捕捉為規格結構：
# 規格：自由工作者支出追蹤器
## 概述
為自由工作者設計的個人支出追蹤應用程式，
強調速度、簡潔和類似日記的體驗。
## 使用者故事
- 作為自由工作者，我想快速新增支出，
這樣不會打斷我的工作流程
- 作為自由工作者，我想清楚看到月度支出，
這樣我可以管理預算
- 作為自由工作者，我想讓分類感覺自然，
這樣我會真的使用它
## UX 需求
- 支出輸入：< 5 秒
- 互動風格：手勢友善（滑動分類）
- 視覺密度：低（留白空間）
- 數據顯示：月度導向，非交易式
## 設計參考
- Things 3：極簡、留白、細膩動畫
- Notion：彩色點綴、俏皮但不幼稚
- 強調：「日記」而非「帳本」
## [需要釐清]
- 幣別支援：單一或多幣別？
- 數據儲存：本地優先或雲端同步？
- 匯出格式：PDF？CSV？報稅軟體？階段 2：Vibe 精煉
現在用 vibe 語言迭代規格：
你："分類區塊感覺太企業化了。
更像選擇一種心情，而不是報稅。"
Claude：更新規格...
## 分類系統
- 心情式分類：「工作相關」、「生活瑣事」、
「創意工作」、「無聊事務」
- 每個分類可自訂 emoji
- 色彩編碼，非圖標編碼
- 無層級結構——扁平且簡單你："月度概覽——我不想要圖表。
我想要真的會看的東西。像月度回顧，
不是儀表板。"
Claude：更新規格...
## 月度概覽
- 敘事格式：「2026 年 3 月：你花了...」
- 標出與上個月的驚人變化
- 用白話顯示趨勢，不是百分比
- 每月一個「洞察」，不是二十個指標階段 3：實作前的 Vibe 檢查
開始寫程式前，做個 vibe check：
你："讀一下規格。感覺還對嗎？"
Claude：這是我們要建立的精髓...
「給自由工作者的個人支出日記。
快速新增（< 5 秒），分類滿足
（心情式、手勢友善），提供月度敘事
而非企業儀表板。
感覺像 Things 3 遇見 Notion，但用於金錢。」
這符合你的願景嗎？如果不對，調整。如果對了，繼續。
階段 4：結構化實作
現在 Claude 用完整 SDD 嚴謹度實作：
/speckit-implement SPEC-001
Claude:
→ 從規格建立技術計劃
→ 分解為可追溯任務
→ 實作時參照規格
→ 維護文檔程式碼參照規格：
/**
* 快速支出輸入元件
*
* @spec SPEC-001
* @requirement "支出輸入 < 5 秒"
* @ux "快速新增支出，不打斷工作流程"
*/
export function QuickExpenseInput() {
// 根據 UX 需求優化速度
// ...
}VibeSDD 實戰
範例：建立習慣追蹤器
傳統方法：
/speckit-specify 習慣追蹤功能
[花 30 分鐘撰寫正式需求]VibeSDD 方法：
你："我想要一個習慣追蹤器，當我漏掉幾天時
不會讓我感覺糟糕。大多數習慣 app 感覺像在懲罰。
這個應該像溫柔的朋友提醒我照顧自己。
靈感：Headspace 的平靜氛圍，但用於習慣。
絕對不是 Streaks 那種激進的連續計數。"Claude 捕捉：
# 規格：有同理心的習慣追蹤器
## 核心理念
非懲罰性追蹤。漏掉幾天是預期且 OK 的。
專注於模式而非連續紀錄。
## UX 原則
- 沒有斷掉的鏈條或失去的連續紀錄
- 沒有紅色 X 或失敗指標
- 顯示「嘗試的天數」而非「漏掉的天數」
- 慶祝任何進步，無論多小
## 視覺語言
- 柔和色彩、圓潤形狀
- 自然隱喻（成長、季節）
- 用語：「休息日」而非「跳過日」
- 首頁沒有數字——只有氛圍
## 反需求（要避免的）
- 禁止連續計數器
- 禁止懲罰性遊戲化
- 禁止比較功能
- 禁止羞辱式通知你精煉：
你："『沒有數字』這件事——我還是想看到
某種進度。只是不要太激進。"
Claude：更新規格...
## 進度視覺化
- 熱力圖用柔和漸層（非鮮明二元）
- 「季節」視圖：春天 vs 冬天看起來如何？
- 可選統計，預設隱藏
- 用語：「你出現了 X 次」而非「X 天連續紀錄」然後用完整可追溯性實作。
VibeSDD 提示指南
開始 VibeSDD 專案
## 高 Vibe 規格起手式
「我想建立 [東西]，感覺像 [參考]。
關鍵感受是 [情緒]。對象是 [受眾]。」
「想像 [靈感 A] 遇見 [靈感 B]，
但專注於 [特定面向]。」
「大多數 [類別] app 感覺 [負面]。
這個應該感覺 [正面]。」精煉規格
## Vibe 精煉句型
「這個區塊感覺太 [形容詞]。讓它更 [形容詞]。」
「當我想像使用這個，我感覺 [情緒]。我想感覺 [情緒]。」
「[區塊] 的調性應該符合 [參考]。」
「這捕捉了『什麼』但沒有『為什麼』。為什麼是 [原因]。」檢查對齊
## Vibe 檢查問題
「用 3 句話總結規格。還有共鳴嗎？」
「如果這存在，我會興奮地使用嗎？為什麼？」
「什麼會讓使用者在使用時微笑？」
「6 個月後，這會有什麼感覺不對？」何時使用 VibeSDD
非常適合
| 情境 | 為什麼 VibeSDD 有效 |
|---|---|
| 新產品探索 | 先 vibe，精煉，然後正確建立 |
| UX 關鍵功能 | 規格中捕捉感受 |
| 創辦人主導專案 | 願景到執行不失靈魂 |
| 重新設計 | 捕捉期望的感受，不只是功能 |
較不理想
| 情境 | 更好的方法 |
|---|---|
| 純基礎設施 | 傳統 SDD |
| API 整合 | 標準規格 |
| 合規功能 | 正式需求 |
| Bug 修復 | 直接修 |
常見錯誤
錯誤 1：Vibe 了但沒捕捉
❌ 錯誤：
Session 1："讓它感覺像 Notion"
Session 2："為什麼它不像 Notion？"✅ 正確：
Session 1："讓它感覺像 Notion" → 捕捉進規格
Session 2：[讀規格] 繼續實作 Notion 風格永遠將 vibes 捕捉進規格。 Vibes 會消退；規格會持續。
錯誤 2：過度規格化 Vibes
❌ 錯誤：
「按鈕應該正好 44px，背景 #3B82F6，
圓角 4px，字體 'Inter' 14px weight 500...」✅ 正確：
「按鈕應該感覺友善且可點擊。
不企業化，不玩具感。恰到好處。」規格化感受，不是像素。 Claude 懂 CSS。
錯誤 3：跳過 Vibe 檢查
❌ 錯誤：
[寫規格] → [立即實作]✅ 正確：
[寫規格] → [讀回來] → [感受對不對] → [實作]永遠暫停做 vibe-check。 現在 5 分鐘省下之後幾小時。
VibeSDD 速查表
## VibeSDD 快速參考
### 開始一個功能
1. 描述 vibe（2-3 段落，感受和參考）
2. 讓 Claude 結構化為規格
3. Vibe-精煉感覺不對的區塊
4. Vibe-check 整個規格
5. SDD 實作並追溯
### Vibe 詞彙
- 感受：平靜、有活力、俏皮、嚴肅、可信
- 比較：「像 X 但 Y」、「X 遇見 Y」
- 否定：「不像 X」、「避免 Y 的感覺」
- 方向：更多/更少、更簡單/更豐富、更溫暖/更冷
### 要 Vibe 的規格區塊
- 使用者故事 → 「作為感覺...的人」
- UX 需求 → 「它應該感覺...」
- 設計參考 → 「像 X 遇見 Y」
- 反需求 → 「不像...」
### 品質檢查
- 我會興奮地使用這個嗎？
- 我能用一句話解釋它的靈魂嗎？
- 讀規格會給我那種感覺嗎？用 Skills & Agents 實現 VibeSDD
社群模式聲明： 以下的 skills 和 agents 來自 Claude Bootstrap Kit，這是一個社群開發的 Claude Code 擴展。它們不是 Anthropic 官方功能。
VibeSDD 不只是概念——它是一個你今天就能用 Claude Code 的自訂 skills 和 agents 執行的工作流程。
VibeSDD Skill 管道
┌─────────────────────────────────────────────────────────────────┐
│ VibeSDD Skill 管道 │
│ │
│ VIBE 輸入 結構化捕捉 實作 │
│ ───────── ────────── ──── │
│ │
│ 你的自然語言 → /spec-writer → /tech-planner │
│ vibe 描述 (捕捉為規格) (架構設計) │
│ │ │ │
│ ▼ ▼ │
│ /spec-clarifier /task-decomposer │
│ (解決 [?]) (分解任務) │
│ │ │ │
│ ▼ ▼ │
│ specification- /speckit-implement │
│ validator agent (TDD 執行) │
│ (品質檢查) │
│ │
└─────────────────────────────────────────────────────────────────┘階段 1：Vibe → 規格
使用 /spec-writer 將你的 vibe 轉換為結構化規格：
你："我想建立一個給自由工作者的支出追蹤器。
它應該感覺像個人財務日記，不是企業會計工具。
快速新增、分類滿足、極簡但可信。"
/spec-writer 自由工作者支出追蹤器spec-writer skill：
- 將你的 vibe 結構化為使用者故事
- 提取驗收標準
- 從感受中識別 UX 需求
- 用
[需要釐清]標記模糊點 - 保持純產品——還沒有技術細節
階段 2：釐清 Vibes
使用 /spec-clarifier 解決 [需要釐清] 標記：
/spec-clarifier SPEC-001spec-clarifier skill：
- 掃描所有模糊區塊
- 生成帶選項的結構化問題
- 使用
AskUserQuestion進行互動決策 - 用你的選擇更新規格
- 記錄決策理由
互動範例：
Claude：找到 3 個需要釐清的項目：
1. 幣別支援？
a) 單一幣別（更簡單）[推薦]
b) 多幣別（複雜）
你的 vibe 說「極簡」——單一幣別更符合。
2. 數據儲存？
a) 本地優先（隱私、離線）
b) 雲端同步（隨處存取）
你的 vibe 說「可信」——哪種對你來說更可信？
你：單一幣別，本地優先對金錢數據感覺更可信。
Claude：[用決策和理由更新規格]階段 3：驗證 Vibe-Spec
使用 specification-validator agent 確保品質：
Claude 使用 Task 工具與 specification-validator agent驗證器檢查：
- 結構完整性（所有必要區塊）
- SDD 合規性（沒有過早的技術細節）
- 清晰度分數（剩餘
[需要釐清]數量） - Vibe 一致性（是否仍符合原始感受？）
評分：
- 90-100：優秀，可以實作
- 75-89：良好，需要小幅精煉
- 60-74：需要改進，缺少區塊
- <60：失敗，根本問題
階段 4：技術規劃
規格驗證後，使用 /tech-planner：
/tech-planner SPEC-001tech-planner skill：
- 徹底分析規格
- 探索現有程式碼架構
- 生成 2-3 個實作方案
- 評估權衡（複雜度、效能、風險）
- 輸出詳細技術計劃
保留 vibe：
# 技術計劃：支出追蹤器
## 架構決策
基於規格強調的「快速」(< 5 秒) 和
「可信」(本地優先)，我們推薦：
- **方案 A：SQLite + React Native** ✓ 推薦
- 符合「極簡」vibe（簡單技術棧）
- 透過本地優先架構支援「快速」
- 透過設備端加密實現「可信」階段 5：任務分解
使用 /task-decomposer 將計劃分解為可執行任務：
/task-decomposer SPEC-001task-decomposer skill：
- 建立帶依賴關係的大小任務
- 將每個任務連結到規格需求
- 估算相對複雜度
- 生成 TodoWrite 相容的任務列表
輸出：
## 實作任務
| ID | 任務 | 規格參照 | 大小 |
|----|------|----------|------|
| T1 | 建立 SQLite schema | UX-001 | S |
| T2 | 建立支出輸入元件 | UX-002 | M |
| T3 | 實作滑動分類 | UX-003 | M |
| T4 | 建立月度敘事視圖 | UX-004 | L |
| T5 | 加入柔和漸層熱力圖 | UX-005 | S |階段 6：TDD 實作
使用 /speckit-implement 執行完整可追溯的實作：
/speckit-implement SPEC-001speckit-implement skill：
- 遵循嚴格的 Red-Green-Refactor TDD 循環
- 在每個程式碼檔案中參照規格
- 檢查 9 條憲法合規性
- 生成實作報告
憲法合規性（9 原則）：
- Library-First - 可重用邏輯放在 library
- CLI Interface - 功能可透過 CLI 存取
- Test-First - 測試先於實作
- Research-Driven - 基於證據的決策
- Specification Consistency - 完全符合規格
- Simplicity - 選擇最簡單的方案
- Anti-Abstraction - 不要過早抽象
- Minimal Scope - 只做規格要求的
- Integration-First - 優先整合測試
完整 VibeSDD 指令序列
# 1. 將 vibe 轉換為規格
/spec-writer "你的 vibe 描述"
# 2. 互動式釐清模糊點
/spec-clarifier SPEC-001
# 3. 驗證規格品質
# (自動觸發或使用 specification-validator agent)
# 4. 建立技術計劃
/tech-planner SPEC-001
# 5. 分解為任務
/task-decomposer SPEC-001
# 6. TDD 實作
/speckit-implement SPEC-001
# 或執行完整管道：
/speckit "你的 vibe 描述"複雜 Vibes 的 Agent 編排
對於複雜功能，平行使用多個 agents：
Terminal 1: spec-writer agent
→ 將 vibe 捕捉為規格
Terminal 2: tech-planner agent
→ 探索架構選項
Terminal 3: specification-validator agent
→ 驗證 SDD 合規性
Terminal 4: implementer agent
→ 完整可追溯的執行Multi-CLI 委派：
大型 context 分析 → Gemini CLI（1M tokens）
批量程式碼格式化 → Codex CLI（效率）
互動式決策 → Claude CLI（對話）VibeSDD 的 CLAUDE.md 配置
在你的專案 CLAUDE.md 加入：
## VibeSDD 工作流程
### Vibe 捕捉
- 新功能一律使用 /spec-writer
- 在規格中明確標記 vibes："Vibe: [描述]"
- 包含設計參考和反模式
### 規格標準
- 純產品規格（tech-planner 前沒有技術細節）
- 所有模糊點用 [需要釐清] 標記
- 實作前必須 vibe-check
### 實作規則
- 必須符合憲法合規性
- 所有新功能用 TDD
- 程式碼註解中參照規格哲學：為什麼 VibeSDD 重要
軟體開發一直有一個張力：
藝術家想自由表達和創造。 工程師想正確且可維護地建立。
VibeSDD 透過認知以下事實來解決這個問題：
-
Vibes 也是需求。「它應該感覺 X」跟「它應該做 Y」一樣有效。
-
結構放大創意。 規格不是限制；是創意承諾。
-
AI 橋接差距。 Claude 可以將感受翻譯成正式規格。
結果：正確運作且感覺對的軟體。
關鍵重點
- Vibe coding 捕捉意圖——正式規格常遺漏的
- SDD 提供護欄——vibe coding 缺乏的
- VibeSDD = 創意自由 + 系統嚴謹
- 永遠將 vibes 捕捉進規格
- 實作前做 vibe-check
從感受開始。以嚴謹結束。建立有靈魂的軟體。