雙鑽模型：先做對的事，再把事做對
本章導讀
最小 SOP
目的：看完後，你會更清楚做產品時什麼時候該先想問題，什麼時候才該開始想方案和原型，避免一上來就在錯誤方向上做得很認真。
行動項：按 Discover → Define → Develop → Deliver 四步往下走，每一步只做當前階段該做的事。
結果：你會得到一個更清楚的問題定義、幾種可比較的方案，以及一個可驗證的最小版本。
你將學到以下內容
- 雙鑽模型是什麼，為什麼它適合零基礎做產品時使用
- Discover、Define、Develop、Deliver 四個階段分別在做什麼
- 怎樣區分“現在應該繼續發散”還是“現在應該開始收斂”
- 如何把雙鑽模型用在 AI 產品、原型設計和需求驗證裡
1. 雙鑽模型到底是什麼
雙鑽模型是英國 Design Council 推廣的一套經典設計流程框架。它把一個完整的設計與創新過程，畫成兩個連續的鑽石形狀。
之所以是“鑽石”，是因為每個鑽石都包含兩種相反但都很重要的動作：
- 發散：先把視野開啟，看更多可能性
- 收斂：再把範圍縮小，做出判斷和取捨
整個過程一共四步：
- Discover：廣泛瞭解使用者、問題、環境和市場
- Define：從大量資訊裡提煉出真正值得解決的核心問題
- Develop：圍繞核心問題發散多種解決方案
- Deliver：篩選、原型、測試並交付更合適的方案
如果把這四步壓縮成一句最容易記住的話，就是：
- 第一個鑽石：先搞清楚到底要解決什麼問題
- 第二個鑽石：再決定用什麼方案去解決它
這也是你剛才說得很準確的那句話：
- 第一個鑽石：做對的事情
- 第二個鑽石：把事情做對
2. 為什麼雙鑽模型特別適合新手
新手做產品最常見的節奏，往往是這樣的：
- 想到一個點子
- 覺得這個方向很酷
- 馬上開始畫原型
- 做著做著發現功能越來越多
- 最後不知道自己到底在解決什麼問題
雙鑽模型的價值，不在於讓流程變複雜，而在於 強迫你把“理解問題”和“設計方案”拆開 。
這件事聽起來很普通，但實際非常重要。因為很多失敗的產品，不是執行不認真，而是：
- 選錯了問題
- 誤解了使用者
- 過早鎖定了解決方案
- 把大量時間花在細節打磨上，卻沒有驗證方向
雙鑽模型就是在不斷提醒你：
- 不要因為想法順手，就預設問題已經成立
- 不要因為方案能做出來，就預設它值得做
- 不要因為原型看起來完整，就預設使用者會真的需要
3. 第一個鑽石：做對的事情
第一個鑽石關注的是 問題本身 ，而不是解決方案。
你可以把它理解成一句話：先別急著做，先搞清楚到底值不值得做。
3.1 Discover：先把問題空間開啟
Discover 階段的核心任務，是 廣泛調研，而不是快速下結論。
這一步通常會做的事情包括：
- 看使用者在真實場景裡怎麼做
- 訪談潛在使用者，瞭解他們最近一次遇到問題是什麼時候
- 觀察他們現在怎麼湊合解決
- 看競品和替代方案都在怎麼處理
- 收集市場、流程、約束、上下游資訊
很多人會誤以為 Discover 就是“多看點資料”。其實更關鍵的是：你要理解人和場景，而不只是搜一堆資訊。
比如你想做一個“AI 幫忙整理會議紀要”的工具，在 Discover 階段更應該關注的是：
- 使用者開完會後到底哪裡最痛苦
- 是記錄難，還是整理難，還是同步難
- 他們現在是自己寫、讓實習生寫、錄音回聽，還是乾脆不整理
- 哪些會議場景最需要紀要，哪些根本不需要
這一步最重要的目標不是得出答案，而是 別太早以為自己已經知道答案。
3.2 Define：從一堆資訊裡提煉出核心問題
如果 Discover 是開啟視野，Define 就是開始收束。
Define 階段要做的，不是把所有觀察都保留下來，而是問：
- 真正最值得優先解決的問題是哪一個
- 哪個問題最常出現、最痛、最有價值
- 我們第一版到底只盯住哪一個場景
這一步的核心，是把一個寬泛話題，收斂成一個清晰問題定義。
比如你一開始說：
我想做一個提高開會效率的 AI 工具。
到了 Define 階段，更好的表達可能會變成：
我們先解決專案型團隊在 30 到 60 分鐘協作會議結束後，無法在 10 分鐘內輸出帶待辦、責任人和截止時間的紀要這個問題。
這時候問題就開始變清楚了：
- 使用者是誰
- 場景是什麼
- 卡點是什麼
- 成功標準是什麼
Define 的本質，就是 從“問題很多”收斂到“這次先解決哪一個問題”。
4. 第二個鑽石：把事情做對
當你完成第一個鑽石後，才真正適合進入第二個鑽石。因為這時你解決的不是一個模糊方向，而是一個被收斂過的具體問題。
4.1 Develop：圍繞核心問題發散方案
Develop 階段的重點，是 圍繞同一個問題，探索多種可能方案。
注意，這裡的發散和 Discover 階段不一樣。
- Discover 的發散，是在探索問題空間
- Develop 的發散，是在探索解決方案空間
比如還是會議紀要這個例子，到了 Develop 階段，你可以開始想：
- 是做網頁工具，還是會議外掛
- 是上傳錄音後處理，還是實時記錄
- 是隻做摘要，還是重點做待辦提取
- 是強調個人效率，還是強調團隊同步
- 是給使用者自由編輯，還是直接輸出結構化模板
這一步很適合腦暴，也很適合和團隊一起把方案拉開。
但這裡有一個前提：所有方案都必須服務同一個已定義的問題。
如果問題沒定義清楚，Develop 很容易又重新變成功能亂飛。
4.2 Deliver：選擇方案、做原型、測試和交付
Deliver 階段是第二個鑽石裡的收斂階段。
這時你要做的不是繼續想更多，而是開始判斷：
- 哪個方案最適合當前階段
- 哪個版本最小但最有用
- 哪些功能必須先做，哪些可以以後再說
- 怎麼做原型、測試和小範圍驗證
很多人以為 Deliver 就等於“上線”。其實它更準確的意思是：把一個方案變成可測試、可驗證、可迭代的東西。
它可能是：
- 一張低保真流程圖
- 一個 Figma 原型
- 一個可執行的 MVP
- 一次小規模使用者測試
- 一輪真實反饋後的迭代版本
Deliver 的重點不是“完美交付”，而是 儘快把方案放進真實環境裡驗證。
5. 一個最容易記住的對照表
如果你總是分不清四個階段，可以直接記下面這個版本：
| 階段 | 你在做什麼 | 關鍵詞 | 常見產出 |
|---|---|---|---|
| Discover | 理解問題 | 調研、觀察、訪談、收集資訊 | 使用者洞察、場景筆記、問題清單 |
| Define | 定義問題 | 提煉、聚焦、取捨、重寫問題 | 問題定義、優先順序、MVP 切口 |
| Develop | 探索方案 | 腦暴、比較、共創、原型設想 | 方案列表、流程草圖、原型方向 |
| Deliver | 驗證方案 | 原型、測試、迭代、交付 | 原型、測試反饋、最佳化版本 |
再壓縮一點，就是這樣：
- Discover / Define：解決“做對的事情”
- Develop / Deliver：解決“把事情做對”
6. 雙鑽模型最常見的誤區
6.1 還沒 Discover，就直接 Deliver
這是最常見的一種。很多人剛有想法就開畫原型、寫 PRD、接模型、做頁面。
問題不是你做得不認真，而是你可能根本還沒確認問題值不值得解決。
6.2 Discover 很久，但始終不 Define
另一種極端是一直調研、一直看資料、一直訪談，卻遲遲不敢收斂。
雙鑽不是讓你無限發散，而是提醒你：發散之後必須進入判斷和取捨。
6.3 Define 之後，又偷偷改問題
很多團隊會在 Develop 時因為某個方案更容易做，就反過來修改問題定義，讓它適配現有方案。
這很危險。因為你可能不是在解決問題，而是在為自己偏愛的方案找理由。
6.4 把 Deliver 誤解成“大而全上線”
Deliver 不是說必須把完整產品都做完纔算結束。很多時候，一個可以測試的原型、一輪真實使用者試用，已經是很好的 deliver。
7. 在 AI 產品裡，雙鑽模型怎麼用
AI 產品特別容易掉進“能力先行”的坑裡，因為模型能力看起來太誘人了。你會很想直接去想：
- 要不要接多模態
- 要不要做 Agent
- 要不要加工作流
- 要不要接語音、影象、聯網搜尋
但雙鑽模型會逼你先問：
- 使用者到底在哪個環節真的卡住了
- 這個卡點是不是非 AI 不可
- 如果不用 AI，現有辦法到底哪裡最差
- AI 加進去之後，最核心的進展是什麼
這能幫你避免一種常見情況：能力很強，價值很弱。
一個實用的順序是：
- 在 Discover 階段觀察使用者現在怎麼處理任務
- 在 Define 階段把最痛的一個場景寫成一句清晰的問題定義
- 在 Develop 階段再去比較哪些 AI 能力最適合服務這個問題
- 在 Deliver 階段做一個最小版本，讓真實使用者測試
8. 可以直接套用的雙鑽模板
如果你正在做自己的產品，可以先按這個順序往下寫：
Discover
- 我觀察到的使用者是誰？
- 他們最近一次遇到這個問題是什麼時候？
- 他們現在怎麼解決？
- 他們最煩、最慢、最不放心的地方是什麼？
Define
- 這堆問題裡，最值得優先解決的是哪一個？
- 哪個場景最高頻，或者最關鍵？
- 我們第一版先只服務誰、只解決什麼？
- 成功解決後，使用者狀態會發生什麼變化？
Develop
- 針對這個問題，有哪些可能方案？
- 哪些方案最輕、最快、最容易驗證？
- 哪些是必須做，哪些是以後再說？
Deliver
- 我們最小可以交付什麼來驗證這個方向？
- 是流程圖、原型，還是 MVP？
- 需要找誰測試？
- 測試後怎樣判斷要繼續、修改還是放棄？
9. 一個從零基礎也能看懂的例子
假設你想做一個“幫大學生準備求職簡歷”的 AI 工具。
很多人一開始就會直接進入第二個鑽石，開始想：
- 要不要一鍵美化
- 要不要智慧改寫
- 要不要自動匹配 JD
- 要不要生成自我介紹
但按雙鑽模型，更好的過程會是這樣：
第一個鑽石
Discover
- 去聊應屆生最近一次改簡歷是什麼時候
- 看他們怎麼從舊簡歷改成新版本
- 瞭解他們最困擾的是“不會寫”“不會改”，還是“不會判斷好不好”
Define
- 最後收斂出一個更具體的問題：
- 不是“大學生不會做簡歷”
- 而是“第一次投遞實習的學生，很難把已有經歷改寫成貼合崗位的表達，因此拖延投遞”
第二個鑽石
Develop
- 想幾種方案：模板庫、AI 改寫、崗位對照、簡歷評分、案例參考
Deliver
- 第一版只做“根據崗位描述改寫經歷 bullet points”
- 給 5 個學生試用，看他們會不會更快投出第一版簡歷
你會發現，一旦第一個鑽石做紮實，第二個鑽石會清楚很多。
10. 小結
雙鑽模型最有力量的地方，是它幫你把一整團混亂拆成了四個更清楚的動作：
- 先發散理解問題
- 再收斂定義問題
- 再發散探索方案
- 最後收斂交付方案
它不是讓你變慢，而是讓你 少走很多看起來很忙、其實方向不對的彎路。
尤其在 AI 時代，做東西變得越來越快，雙鑽模型反而更重要。因為當“做出來”越來越容易時，真正稀缺的能力會變成：你有沒有在解決一個值得解決的問題，以及你有沒有用合適的方式去解決它。
記住這一句就夠了：
先做對的事情，再把事情做對。
11. 如何利用 AI 幫你跑雙鑽流程
雙鑽模型本身不是 AI 工具，但 AI 很適合在四個階段裡充當“加速器”。關鍵不是讓 AI 替你決策，而是讓它幫你擴充套件視野、整理資訊、比較方案和生成驗證材料。
11.1 在 Discover 階段，用 AI 先做一輪資訊鋪墊
在正式訪談和調研前，你可以先讓 AI 幫你做一些輕量級問題掃描，比如：
- 市面上常見替代方案有哪些
- 使用者在公開社羣裡最常抱怨什麼
- 這個問題常見於哪些場景和人羣
- 現有產品通常忽略了什麼
這一步不能代替真實調研，但很適合幫你快速搭一個問題地圖。
一個很簡單的小白輸入可以是：
我想做一個幫大學生改簡歷的工具。
你先別幫我想功能，先幫我看看大家在這個問題上最常遇到什麼麻煩。AI 可能輸出：
初步問題地圖：
1. 不知道該寫什麼經歷
2. 不知道怎麼針對崗位修改
3. 改了很多版還是不確定是否夠好
4. 需要別人幫看，但不方便總麻煩別人
5. 因為不確定，所以一直拖著不投這種輸出的作用不是替你下結論，而是讓你更快進入 Discover。
11.2 在 Define 階段，讓 AI 幫你收斂問題定義
很多人收集了一堆資料之後，最難的是把問題收成一句真正清楚的話。你可以把調研筆記交給 AI，讓它幫你壓縮成幾個候選問題定義：
下面是我在 Discover 階段收集到的使用者反饋和調研筆記：
[貼上內容]
請你幫我做三件事：
1. 歸納最常出現的問題模式
2. 按問題頻率、痛感和可驗證性，整理出 3 個值得優先解決的問題
3. 把每個問題寫成一句具體的問題定義這樣你會更容易進入 Define，而不是一直停留在“問題好多”的狀態裡。
你甚至可以把輸入寫得非常簡單：
我現在收集到的問題有：
1. 大家不知道簡歷寫什麼
2. 大家不知道怎麼改
3. 大家總覺得沒改好，不敢投
你幫我看看，第一版最適合先解決哪個問題。AI 可能輸出：
建議優先解決的問題：
“第一次投遞實習的學生，不確定簡歷是否已經達到可投遞水平，因此會反覆修改並拖延投遞。”
原因：
1. 這個問題更具體
2. 它能解釋拖延行為
3. 更容易設計一個小版本去驗證這類輸出很有用，因為它幫你從一堆模糊問題裡收出一個更像 MVP 起點的定義。
11.3 在 Develop 階段，用 AI 發散多個方案
很多人一定義完問題，就只盯著腦子裡第一個想到的方案。AI 在這一步很適合幫你強制發散：
我已經定義了一個核心問題：[你的問題定義]
請你不要直接給我一個最終答案，而是從以下角度各提出 2-3 種解決方向：
1. 最輕量的 MVP
2. 最適合驗證需求的方案
3. 最適合提高體驗的方案
4. 不依賴 AI 的方案
5. 依賴 AI 的方案
最後請對比每種方案的優點、風險和驗證成本。這樣你就不會太早被單一方案綁住。
一個簡單輸入可以是：
我現在的問題定義是：
“大學生不確定簡歷是否已經可以投，所以一直拖著不投。”
請你幫我想 4 種不同解決方案，不要只給我一種。AI 可能輸出：
方案 1：簡歷可投遞檢查清單
方案 2：根據崗位描述做針對性改寫
方案 3：讓使用者上傳簡歷後給出風險提示
方案 4：提供優秀案例對照，幫助使用者判斷差距這時你就更容易進入“比較方案”，而不是一上來只盯著 AI 改寫一個方向。
11.4 在 Deliver 階段，用 AI 幫你生成原型文案和測試材料
當你進入 Deliver 階段，AI 非常適合幫你加快這些工作：
- 生成低保真原型裡的頁面文案
- 整理使用者測試指令碼
- 生成可對比的多個版本標題、按鈕、說明語
- 整理測試後的反饋和問題列表
比如你可以讓 AI 幫你生成一個 20 分鐘使用者測試指令碼，或者幫你把 5 個使用者反饋歸納成“繼續做 / 修改方向 / 暫停”的判斷依據。
比如一個最小輸入可以是：
我做了一個很簡單的原型：
使用者上傳簡歷，系統告訴他哪些地方還不適合投遞。
請幫我生成一份 15 分鐘的使用者測試指令碼。AI 可能輸出：
15 分鐘測試指令碼：
1. 先請使用者描述最近一次投簡歷經歷
2. 讓使用者獨立完成上傳簡歷
3. 觀察他是否看得懂反饋結果
4. 詢問：這些提示裡哪些最有幫助，哪些讓你困惑
5. 詢問：如果下次投遞前，你會不會想再用一次這種輸出很實用，因為它能幫你從“我做完原型了”走到“我接下來怎麼測”。
11.5 讓 AI 扮演“階段守門員”
雙鑽模型最常見的問題，是人會跳階段。你可以直接讓 AI 充當一個守門員，提醒你現在到底在哪一步：
請你扮演產品流程教練。
下面是我當前的專案狀態：[你的描述]
請你判斷我現在更像處於 Discover、Define、Develop 還是 Deliver。
並告訴我：
1. 我是不是過早跳到了下一階段
2. 當前階段最該補的動作是什麼
3. 哪些事情現在先別做這對新手特別有幫助，因為你很容易在“還沒想清楚問題時就開始畫原型”。
📚 Assignments
請你根據上文內容，完成下列作業：
- 選一個你最近想做的產品點子，寫出它的 Discover、Define、Develop、Deliver 四步草稿
- 在 Define 階段，強迫自己把問題縮成一句具體的話
- 在 Develop 階段，至少列出 3 種不同方案，而不是隻盯著第一個想到的做法
- 在 Deliver 階段，寫出一個一週內能交付的最小驗證版本
延伸閱讀
這篇文章主要參考了 Design Council 關於 Double Diamond 的官方資料，適合繼續往下看：