双钻模型：先做对的事，再把事做对
本章导读
最小 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 的官方资料，适合继续往下看：