標籤: Spec Driven Development

「Claude Design」這個名字其實沒有官方定義，它是 Claude Code 裡一組設計驅動的工作流程技能（superpowers:brainstorming / writing-plans / subagent-driven-development）的總和。我最近用它做了一個失智症陪伴 APP 的重大功能迭代，這篇文章把它在實戰中「什麼時候救了我」跟「什麼時候反而拖慢我」完整拆給你看。

Claude Design 是什麼？三層流程一次看懂

Claude Design 是一套讓 AI 助手在動手寫 code 前先「想清楚 → 寫規格 → 拆任務」的結構化流程。它不是任何新工具，而是 Claude Code 內建的三個技能組合使用：

階段	技能名稱	產出	目的
1. 發想	brainstorming	設計 spec（Markdown）	用多輪一問一答釐清需求、砍掉不該做的、浮出設計原則
2. 規劃	writing-plans	實作計畫（含驗證步驟）	把 spec 拆成 10-20 個可個別 commit 的小任務
3. 執行	subagent-driven-development	每個 task 一個 commit	派 subagent 做、派 subagent 審 spec、派 subagent 審 code quality

重點不是「三個步驟」這個形式本身，而是每一步強迫你跟 AI 在不同粒度上達成共識：brainstorming 達成「做什麼」、spec 達成「做成什麼樣」、plan 達成「怎麼拆」、subagent 執行時還能雙重審查。

沒用 Claude Design vs 用 Claude Design 的實際差異

同樣是「加一個照顧者支援功能」的需求，兩種做法的差別在哪？這是我實測後的對照：

面向	直接叫 AI 寫	走 Claude Design 流程
需求釐清	憑 AI 猜，常常做錯方向	多輪問答，需求明確後才動手
功能範圍	容易做太多（AI 傾向加功能）	在 brainstorming 階段就砍掉不必要項目
一致性	做到一半風格會漂移	spec 用表格固定內容模板
可追蹤	一個大 commit 或多個散亂 commit	每 task 一個 commit，可個別 revert
重工成本	常常寫完才發現方向錯	方向錯在 spec 階段就發現
速度	單點快、整體容易重工	前期慢、後期穩；不適合微任務

實戰案例一：砍功能，省下 3-4 小時重工

Claude Design 最值錢的貢獻不是寫 code，是阻止你寫不該寫的 code。在我的失智症陪伴 APP 迭代過程中，brainstorming 流程實際上幫我砍掉了三個功能：

砍掉案例 1：背景音樂

我一開始提議加背景音樂（失智症音樂療法有根據），brainstorming 過程中討論到「單檔 HTML 沒辦法帶 MP3、base64 嵌入會讓檔案爆到 30MB、用 File API 每次要重選」三個技術方案的取捨後，使用者自己說「先不要」。如果沒經過討論直接開寫，我大概會先做 File API + ducking 邏輯寫個兩小時，結果做完發現整個方向不對。

砍掉案例 2：獨立話題卡

原本規劃「話題卡」+「遊戲中陪伴提示」是兩個獨立功能。討論到一半，使用者界定：「這個 APP 是玩樂的時候用，真的要純聊天另外開 APP」。這句話直接把「獨立話題卡」功能從 spec 刪除，只保留遊戲情境下的提示。沒有這個界定，我會把話題卡塞進首頁，未來做下一個 APP 會有功能衝突。

砍掉案例 3：每日心情打卡

我在 brainstorming 時列過 5 個功能候選，其中「每日狀態簡記」（3 秒打卡心情/精神/食慾）看起來很有價值。使用者沒選這個，理由是「會把 v2 從『打開就用』變成『每天要記得打卡』，失智照顧者已經很累了」——這是使用者比我更懂他的使用情境的典型例子。AI 單獨設計是想不到這層的。

這三個砍掉的功能合計估計省了 3-4 小時的 coding + 之後的 code review + git 回改。這才是 Claude Design 最值錢的部分——它讓「沒寫到 code 就砍掉」變成可能。

實戰案例二：「可預期」這個原則如何救了 45 條提示語

brainstorming 過程中，使用者往往會不經意說出一句話，變成整個系統的設計支柱。這次是這一句：

「我希望對於照顧者而言，他是腦子清晰的，他可以有期待的方式知道，我可以看到該說什麼。」

這句話裡面的「可預期」被提煉成整個功能的設計原則，寫進了 spec。然後這個原則驅動了三個具體決策：

1. 提示固定模板：15 個遊戲 × 3 個時機（開場/答對/完成）= 45 條提示，全部用「情境 → 可以直接說的話」這個同一個格式，照顧者看一次就學會。
2. 摘要強制預覽：不是一按就複製，而是開 modal 預覽、確認內容，才複製。照顧者對輸出「可預期」。
3. 按鈕只在完成活動後才出現：有資料才有按鈕，避免使用者按下去才發現「沒東西可傳」。

沒有 brainstorming 把這個原則浮出來、沒有 spec 把它寫下來，我會寫 45 條有個性的不同句型（AI 本能會追求多樣性）。結果照顧者每次要重新解讀 UI，反而更累。「可預期」這個字沒有出現在原始需求，是對話中自然生成的，但它比任何功能清單更重要。

實戰案例三：Spec 表格讓語氣不漂移

Spec 文件裡有一張表格，把 15 個遊戲 × 3 個時機 × 實際內容全部列出來：

遊戲	開場	答對時	完成時
顏色辨識	哇，好多顏色，你以前最愛穿什麼顏色？	對！你好厲害	今天陪你看顏色，我也覺得很漂亮
認字遊戲	這個字你以前就認得吧	對啦，這個字你小時候就會了	今天還認這麼多字，真棒
呼吸練習	我們一起慢慢呼吸	（改成中段顯示）吸氣…吐氣…不急	輕輕摸摸他的手，這樣就好

如果不是在 spec 階段一次寫完這張表，而是「做到顏色遊戲時寫顏色的 3 條 → 做到形狀遊戲時寫形狀的 3 條」這樣推進，語氣一定會漂移。寫到第 10 個遊戲的時候我會忘記前面的語氣，變成有些句子很溫暖、有些很乾。表格逼我一次寫完，才有辦法保持「你年輕時、你很厲害」這類一致的溫度。

這是表格化內容的威力——它讓「一致性」不是靠意志力維持，而是靠資料結構強制。

反例：Claude Design 不適合的時候

這次實戰也讓我踩到一個很明顯的坑：subagent-driven-development 對單檔 HTML 原型是殺雞用牛刀。

我一開始對 13 個 task 全部套用標準流程：每個 task 派 1 個 implementer subagent + 1 個 spec reviewer + 1 個 code reviewer，總共 39 次 subagent dispatch，每次 20-130 秒。前幾個 task 都只是「加一個 const、改一個函式」這種改動，triple review 完全是過殺。

使用者實測後直接問我：「你寫程式變慢很多你用什麼模型」——這是一個誠實的信號。我當下檢討並切換到 inline 執行模式（我自己在 session 裡直接做），後半段 8 個 task 的速度回到正常的 3-5 倍。

這個教訓很值：流程的 overhead 必須跟 task 粒度匹配。如果你的 task 只是改 20 行 code、不會影響其他模組，triple review 沒有價值，還會讓每個 task 多花 3-5 分鐘在 subagent 啟動/總結上。

更重要的反省：Claude Design 是「菜譜」，不是基本功

讀到這裡，你可能會問：「Claude Design 其實不就是 Spec-Driven Development（SDD）嗎？」 沒錯。brainstorming + spec + plan + implement 這四步是 SDD 老方法，不是 Claude Code 發明的。Claude Design 做的事其實是把 SDD 從「一千個人有一千種做法」方法化成「人人可以順暢工具化」的標準流程。

這是好事，也是很危險的事。

菜譜出現前、出現後

想像一下麻婆豆腐這道菜：

• 菜譜出現前：只有師傅會做。每個師傅的麻婆豆腐都不一樣，因為他們從「為什麼要用豆瓣醬、為什麼花椒要後下」這種基本功思考過。客人要求「少辣多麻、加竹筍」這種變化，師傅能即時調整。
• 菜譜出現後：人人可以照做，麻婆豆腐變得普及。但只會照菜譜的人，遇到「客人對豆瓣醬過敏，要用別的替代」這種問題就卡住了——因為他從來沒問過「為什麼要用豆瓣醬」。

Claude Design 就是出現了菜譜。它把 SDD 的步驟變成 Skill、把「設計審批」變成 <HARD-GATE>、把 subagent 審查變成標準流程。你不需要知道為什麼要分離「設計」和「實作」，照著 skill 走就有規範的輸出。

為什麼 AI 時代這件事特別危險

菜譜時代的廚師，至少還能從菜譜回推原理——多做幾次就知道花椒晚下是為了香氣不揮發。但 AI 時代：

1. 你問 AI「怎麼做需求分析」→ AI 給你 Claude Design 流程
2. 你照流程做，產出看起來很漂亮的 spec 和 plan
3. 你以為你會做需求分析了
4. 遇到「這個需求太模糊、brainstorming 走 10 輪還是卡住」這種菜譜沒涵蓋的情況
5. 你再問 AI → AI 給你另一個菜譜
6. 你永遠繞著菜譜轉，沒有真的建立「為什麼需求會模糊、要怎麼引出使用者的隱藏前提」這種基本功

最可怕的結果：你的能力上限永遠等於 AI 提供的菜譜深度。菜譜涵蓋不了的變化，你就做不到。而且因為你沒痛過傳統 SDD 的坑，你連「現在這個情境是菜譜解不了的」都判斷不出來——你不知道自己不知道。

SDD 真正的基本功是什麼

Claude Design 的 skill 不會教你這些，但這些才是真正讓你能判斷、變通、甚至挑戰流程的基本功：

菜譜只教你「做什麼」	基本功讓你懂「為什麼」
brainstorming 要一次問一個問題	人的認知頻寬有限，多問題並排會讓使用者選擇癱瘓而隨便回答
spec 要寫 45 條提示的表格	分批生成會有語氣漂移，但為什麼會漂移？因為 LLM 每次 context 都重新「感覺」一次
實作前要設計審批	因為修改 code 的成本遠高於修改文字，越晚發現方向錯越貴
subagent 要 triple review	多視角審查降低單一 agent 的盲點，但前提是 task 複雜到值得這個 overhead
每 task 一個 commit	Git bisect 的粒度等於 debug 速度，太粗的 commit 追 bug 要多花 10 倍時間

懂了「為什麼」，你才能在菜譜斷裂的地方自己接住。例如：brainstorming 走不下去，你會知道這是因為使用者自己也沒想清楚，你要換一個方式（給他看 mockup 而不是繼續問字）而不是換另一個菜譜。

給讀者的反省題

每次用 Claude Design 之前，自問一句：「如果沒有這個菜譜，我會怎麼做這件事？」

• 如果你答得出來 → 你用 Claude Design 是省時間
• 如果你答不出來 → 你該先花時間讀 SDD 的原理，而不是依賴 skill 的自動化

這不是反對 Claude Design。菜譜是好事，讓一道菜普及化。我想提醒的是：Claude Design 方便到你可能永遠不會問「為什麼」。而一個工程師的上限，取決於他問過多少個「為什麼」。

什麼時候用、什麼時候跳過？判斷決策表

情境	建議流程	理由
有多個可能方向、還在猶豫	brainstorming	避免選錯方向重工
要改 15+ 個相似位置、要寫一致的內容	brainstorming + spec	用表格強制一致性
多檔複雜後端、有 test framework、多人協作	完整三層 + subagent	triple review 能防止衝突跟回歸 bug
單檔 HTML、改一個函式、加一個按鈕	直接 inline，跳過流程	overhead 大於價值
修 bug 已經知道怎麼修	直接改，不派流程	問題明確時流程是拖累
重構一個模組的架構	brainstorming + spec（可能跳過 subagent）	要想清楚新架構但執行可以快

3 個給讀者的實作建議

1. 開工前先問自己一句話：「這個 task 的粒度適不適合走流程？」如果是「修一個 bug」「改一個顏色」，直接做；如果是「加一個新功能」「重構一個模組」，走 brainstorming。
2. brainstorming 時刻意引導 AI 砍東西，不是加東西。AI 本能傾向加功能，你要主動問「這個是不是另一個 APP 的事？」「這個能不能先不要做？」。砍掉的功能是最值錢的產出。
3. Spec 一定要用表格呈現重複性內容。如果你有 10+ 個相似的東西（15 個遊戲的 3 條提示、20 個 API 端點的 error message、12 個表單欄位的 placeholder），強制用表格一次寫完，不要分批生成。

中華一番案例：AI 結構上做不到的創新

講到這裡都還是抽象論述。讓我用一個具體案例把「AI 為什麼結構上做不到某些創新」講清楚——1997 年日本動畫《中華一番》第 43 集「大魔術熊貓豆腐」。

劇情背景：小當家與黑暗料理界的邵安，在樓麟艦上進行豆腐對決。評委要求不能用現成豆腐，必須從黃豆開始做。比賽中：

1. 對手下黑手：黑暗料理界的向恩把稻草偷偷放進小當家的大豆裡
2. 意外發生：稻草上的納豆菌讓大豆發酵，大豆變成了納豆（日本傳統發酵食品）
3. 認知翻轉：小當家看到黏糊牽絲的納豆，不是當成「比賽被破壞」丟掉，而是把這個意外當成靈感起點
4. 創新誕生：從納豆的特性衍生出做法與工具，最終做出「大魔術熊貓麻婆豆腐」擊敗邵安

（資料來源：萌娘百科納豆條目，ACGN 中的納豆相關劇情段落）

這故事裡有三個 AI 結構上做不到的元素

劇情元素	AI 為什麼做不到
對手下黑手破壞材料	AI 的 brainstorming 永遠假設「正常情境」，不會模擬「比賽中有人陷害你」這種社會性干擾
辨識大豆已變納豆	需要跨文化背景知識在當下湧現。一個四川廚師要有人把日本發酵食品的視角帶進來，AI 知道但不會主動從「邊緣」冒出來
把失敗當靈感起點	AI 被訓練避免失敗、給成功解。被汙染的食材應該丟掉重做——這是 AI 的強勢模式。把 contamination 翻轉成創新起點是訓練資料裡的反模式

我把這個對比叫做「紹安路 vs 小當家路」：

• 紹安路：精修技術、重組既有元素、走正統菜譜 → AI 擅長
• 小當家路：個人記憶 + 意外事件 + 跨文化知識 + 重新定義失敗 → AI 做不到

紹安在豆腐三重奏對決中輸得更深：他自以為原創的料理，其實 7 年前師父陳邦鈴就做過一樣的。他切斷了有意識的傳承，但無意識的傳承切不斷——他走遍中國、投奔黑暗料理界研發的「自創」菜，結構上還是師承的重組。

用 Claude Design 久了的人可能遇到比紹安更慘的處境：紹安至少還是在複刻真實的師父，你在複刻 AI 訓練資料——但你不會知道，因為沒人會告訴你「這個東西 AI 在 2023 年就生成過一模一樣的了」。

7 個對抗紹安化的具體做法（可以從下個 task 開始）

如果你接受「菜譜化是現實、不會回頭」這個前提，那問題就不是「要不要用 Claude Design」，而是「怎麼用但不被它吃掉」。以下是我經過這次專案後整理的 7 個具體做法：

1. 先離線想 10 分鐘，再開 AI

用紙筆或純文字檔，在沒有 AI 的狀態下先寫下你對這題的想法——即使亂七八糟、半句話、只有關鍵字。寫完才來找 AI。這 10 分鐘的差別，是你有沒有在對話開始前建立自己的立場。

2. 刻意加入 AI 絕對不會建議的約束

AI 傾向推薦「平均來說最好的解」。你主動加怪條件逼自己走不一樣的路。例：做失智症陪伴工具時，不要說「做陪伴 APP」，說「做一個只能給老花眼、色盲、聽障照護者用的工具」——限制是創新的助產士。

3. 每週跟一個「四郎」講一次話

不是讓他們給你解決方案，是把他們的「意外知識」放進你生活。失智照護協會的阿姨、你媽或阿嬤（上一代的照護記憶）、會日文的朋友、幼稚園老師（他們跟認知差異的小孩互動方式跟失智照顧很像）⋯⋯讓他們隨口說的話在你腦裡發酵，像稻草丟進黃豆。

4. 把「bug / 意外 / 失敗」當創作材料，不是要避免的事

開一個 inspirations-from-failures.md，每次遇到意外事件，先不要問怎麼解，先寫三句話：這個意外讓我看到什麼我原本沒看到的？這個限制如果我接受它，會變成什麼新東西？如果我把這個「bug」當成功能，會是什麼？AI 的訓練資料裡「bug 要修」是強勢模式，你要刻意反抗這個傾向。

5. 對 AI 使用「反向問法」

每次 AI 給你答案，下一句問：「這答案的相反是什麼？」「80 歲阿嬤會怎麼想這件事？」「如果這是錯的，錯在哪？」「這答案看起來合理，可是我錯過了什麼？」——這會強迫 AI 跳出訓練資料的中心，去邊緣抓東西。AI 不會主動做這件事，你得逼它。

6. 保留一塊「AI 絕不介入」的創作領域

不是「少用 AI」，是完全禁止。具體例子：照顧長輩的手寫日記（絕不給任何 AI 看）、一個嗜好（煮菜、種花、學樂器）、每週一天完全不開 Claude / ChatGPT。這塊領地是你保持「能產生小當家型靈感」的保護區。失去這塊，你永遠只能是紹安。

7. 跟 AI 約定「小當家模式」信號詞

當你要創新、不要優化時，直接跟 AI 說：「這次我要小當家模式，不要 Claude Design」。你的 AI 應該立刻做三件事：關閉所有 brainstorming/spec/plan 流程建議、不給業界做法、反過來問你的個人史跟身邊的人。這是你跟 AI 之間的信號詞。沒有它，AI 會把菜譜當成預設。

優先順序：如果只能選一個開始

選第 6（AI 禁區）。沒有這個，其他六個遲早會被 Claude 侵蝕回去。禁區是你維持「小當家能力」的物理基礎。

結論：不是流程多就好，是流程跟 task 匹配才好

Claude Design 不是一個「你該永遠用」的聖杯，也不是一個「多此一舉」的噱頭。它是一套當你面對真正需要思考的問題時，把你跟 AI 之間的對話規則化的工具。

我這次失智症陪伴 APP 專案裡，Claude Design 救了我的前半段（brainstorming 砍功能 + spec 寫一致的 45 條提示），拖慢了我的後半段（subagent-driven-development 對單檔 HTML 過殺）。能分清這條線，是下次用它用得更好的關鍵。

如果你的下一個 task 真的很簡單、你已經知道怎麼做——直接做。但如果你正在「想不清楚這功能該不該做」或「要做 15 個相似的東西怕語氣不一致」，那就值得花 20 分鐘先走 brainstorming。這 20 分鐘會幫你省下 3-4 小時。

延伸閱讀

• Claude 4.7 Memory 與 Agent Team 實戰：自建 Brain 系統的真正價值 — 講的是跨專案知識累積，Claude Design 是單專案的對應
• 你的 AI Agent Team 為什麼越做越小？視角驅動的編制方法論 — subagent 怎麼編隊，跟本文的「task 粒度匹配」互補