easy-vibe 产品方法课用 Double Diamond 双钻模型把拍脑袋的 AI 点子收敛成值得做的产品【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe本文是 Datawhale easy-vibe 项目 Stage 1 产品思维系列中的核心方法课。它以英国 Design Council 提出的 Double Diamond双钻模型为主线讲解如何用两次发散、两次收敛把需求调研与用户访谈积累的混乱素材拆解为 Discover、Define、Develop、Deliver 四个可执行的阶段从而避免在问题尚未澄清时就急着画原型、接模型、写 PRD。读完本文你将掌握一套可直接套用的四阶段工作流模板、一张贯穿各阶段的可执行检查清单以及一组让 AI 作为流程加速器而非决策替代者的具体提示词能直接应用于你正在酝酿的任何 AI 产品想法。双钻模型把产品开发拆成两个钻石第一个钻石解决做正确的事先搞清楚该解决什么问题第二个钻石解决把事情做正确再决定用什么方案去解决。easy-vibe 的完整学习路径中该章节位于 Stage 1 需求分析与产品思维阶段见 学习地图 中附录Double-Diamond 模型条目是连接 发现好想法、产品思维基础、用户访谈Mom Test 与 原型搭建、完整项目实战 的枢纽章节。本文档全文位于 docs/de-de/stage-1/appendix-double-diamond/index.md。1. 两次发散与两次收敛为什么是双钻经过需求分析和用户访谈后你手上通常已经有大量素材不同用户的经历、现有工具的短板、若干个可行的改进方向。素材越多选择反而越难。如果理解问题和设计方案不做区分人很容易在访谈过程中就下意识地为自己的心头好功能寻找论据。双钻模型正是用**两次发散Divergieren和两次收敛Konvergieren**把这两类工作强行分开。它源自英国 Design Council 的传播与推广把问题空间与解决方案空间表示为两个首尾相接的菱形发散先扩大视野考察更多可能性收敛再收窄范围做出决策、设定优先级。整个流程由四个步骤组成Discover发现全面理解用户、问题、环境与市场Define定义从大量信息中过滤出真正值得解决的核心问题Develop开发围绕核心问题发散出多个解决方案Deliver交付选定方案制作原型、测试并交付最合适的解。把四步压缩成一句好记的话第一个钻石先搞清楚到底要解决什么问题第二个钻石再决定用什么方案去解决。前两个阶段处理的是问题空间后两个阶段处理的是解决方案空间。需要特别说明的是Design Council 同时强调这不是一条只走一次的线性流程。如果测试暴露了问题团队完全可以退回到更早的阶段重来——这一点对用 AI 快速迭代的 vibe coding 场景尤其重要。2. 为什么必须把问题与方案分开初学者做产品时的典型节奏往往是这样的冒出一个想法觉得方向很妙立刻开始画原型画着画着功能越加越多最后自己都不清楚到底在解决什么问题。双钻模型的价值不在于把流程变复杂而在于把理解问题与设计方案分离。这句话听起来平淡实践中却极其重要很多失败的产品并不是因为投入不够而是因为——选错了问题误解了用户过早锁定了方案在没有验证方向的情况下把大量时间花在了细节打磨上。双钻模型时刻提醒你三条反直觉的戒律不要因为想法看起来合理就默认问题已经清楚了不要因为方案技术上可行就默认它值得做不要因为原型看起来很完整就默认用户真的需要它。3. 第一个钻石问题空间Discover Define第一个钻石聚焦于问题本身而不是方案。它可以概括为一句话别急着开工先确认这件事值不值得做。3.1 Discover先打开问题空间Discover 阶段的核心任务是做全面研究而不是快速下结论。典型的动作包括观察用户在真实场景中的行为访谈潜在用户追问他们上一次遇到这个问题是什么时候观察他们现在是如何凑合应对的分析竞品与替代方案收集市场、流程、约束与价值链相关信息。很多人误以为 Discover 就是多读点资料但更重要的是你要理解的是人和场景而不只是收集信息。文档中给出了一个具体案例假如你想做一个用 AI 辅助生成会议纪要的工具Discover 阶段应优先澄清的是用户开完会后最累的是哪一环痛点到底在录音、总结还是分发用户是自己写、让实习生写、回听录音还是干脆不做纪要哪些会议场景最需要纪要哪些场景根本不需要。这个阶段最重要的目标不是找到答案而是不要过早相信自己已经找到了答案。3.2 Define从信息中蒸馏出核心问题如果 Discover 是打开视野那么 Define 就是收窄聚焦。Define 阶段不是要保留所有观察而是要追问哪个问题最重要、值得优先解决哪个问题发生频率最高、最痛、能带来最大价值第一版应该聚焦在哪个场景上。这一步骤的本质是把一个宽泛话题压缩成一条清晰的问题定义。比如你最初可能会说我想做一个提升会议效率的 AI 工具。经过 Define 阶段更优的表述可能是我们先解决项目团队开完 3060 分钟的协作会议后无法在 10 分钟内产出一份包含任务、负责人和截止时间的纪要这个问题。此时问题变得具体了用户是谁、场景是什么、瓶颈在哪、成功标准是什么。Define 的本质就是从问题很多收敛到这一次先解决哪个问题。4. 第二个钻石解决方案空间Develop Deliver只有完成第一个钻石后才应进入第二个钻石。因为这时你要解决的已经不是一个模糊的方向而是一个被明确圈定的具体问题。4.1 Develop围绕核心问题发散方案Develop 阶段的核心是针对同一个问题探索多种可能的解法。注意这种发散和 Discover 的发散不同Discover 的发散探索的是问题空间Develop 的发散探索的是解决方案空间。回到会议纪要的例子Develop 阶段你可以考虑做 Web 工具还是会议插件事后上传录音处理还是实时转写只做摘要还是聚焦任务抽取主打个人效率还是团队协同让用户自由编辑还是直接输出结构化模板。这一步骤非常适合头脑风暴和团队共创。但它有一个前提所有方案必须服务于同一个已定义的问题。如果问题没有定义清楚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 不意味着交付品必须完整。很多时候一个可测试的原型或一次小规模用户试用就已经是很好的交付物了。7. 双钻模型在 AI 产品中的落地方式AI 产品尤其容易掉进能力优先的陷阱因为模型能力实在太诱人了。你很容易直接开始想要不要做多模态要不要做 Agent要不要加 Workflow要不要接入语音、图片或联网搜索。但双钻模型强迫你先回答用户到底卡在哪一步这个问题是否必须用 AI 解决如果不用 AI现有做法最糟糕的地方是什么加上 AI 之后核心的进步到底是什么。这能帮你避免一种常见局面能力很强价值很弱。一套可操作的做法是Discover观察用户当前如何完成任务Define把最痛的场景写成清晰的问题定义Develop比较哪些 AI 能力最匹配这个问题Deliver做一版最小实现交给真实用户测试。8. 可直接套用的双钻模板如果你正在打磨自己的产品可以按下面的顺序逐项自问Discover我要观察的用户是谁他们上一次遇到这个问题是什么时候他们现在是怎么解决的什么最让他们烦躁、最慢、最不安心Define这些问题里哪个最有价值、应该先解决哪个场景出现最频繁或最关键第一版我们只服务谁、只做什么问题被成功解决后用户的状态会发生什么变化Develop针对这个问题有哪些可能的解法哪些方案最轻、最快、最容易验证哪些必须现在做哪些可以以后再做Deliver为了验证这个方向我们能交付的最小东西是什么它是流程图、原型还是 MVP我们要邀请谁来测试测试后我们如何决定继续 / 调整 / 放弃9. 一个零基础也能看懂的完整示例假设你想做一个帮助高校毕业生准备求职简历的 AI 工具。很多人会立刻跳进第二个钻石想的是一键美化智能改写自动 JD 匹配生成自我介绍。按照双钻模型更好的流程是这样的第一个钻石Discover和应届毕业生聊聊上次改简历是什么时候观察他们如何把旧简历改造成新版本弄清他们最困扰的到底是不知道写什么、不知道怎么改还是无法判断够不够好。Define收敛到更具体的问题定义不是学生不会做简历而是第一次申请实习的学生无法把自己已有的经历改写成贴合职位描述的表达因而迟迟不敢投递简历。第二个钻石Develop考虑多种方案模板库、AI 改写、职位对比、简历评分、案例参考等。Deliver第一版只做一件事基于职位描述改写经历要点交给 5 名学生试用观察他们是否更快提交第一版简历。你会发现当第一个钻石打磨充分后第二个钻石会变得异常清晰。这个示例的思路与 easy-vibe 中 完整的项目实战章节 采用的先验证方向、再做最小实现的节奏完全一致。10. 如何借助 AI 跑完整个双钻流程双钻模型本身不是 AI 工具但 AI 非常适合作为四个阶段的加速器。关键不在于让 AI 替你做决策而在于用它来拓宽视野、整理信息、对比方案、生成验证素材。以下是文档提供的、可直接复制的提示词Prompt与预期输出。10.1 Discover 阶段用 AI 搭建第一版信息地基在正式访谈和调研之前可以让 AI 先做一次轻量的问题澄清扫描市场上常见有哪些替代方案用户在公开社区里抱怨最多的是什么该问题会出现在哪些场景、哪些人群现有产品忽略了什么。这一步不能替代真实调研但很适合快速绘制一张问题地图。一个面向初学者的简单 Prompt我想做一个帮助学生改写简历的工具。 请不要急着给功能建议先告诉我这个问题里最常见的困难有哪些。AI 可能输出第一版问题地图 1. 不知道该写哪些经历 2. 不知道如何把简历匹配到具体职位 3. 改了很多遍仍不确定是否够好 4. 需要有人帮忙校对又不想总欠人情 5. 因为不确定而一拖再拖投递这种输出不是替你拍板而是让你更快进入 Discover。10.2 Define 阶段让 AI 帮你收敛问题定义信息收集完成后最难的往往是把问题压缩成一句真正清晰的话。你可以把调研笔记交给 AI请它压缩出多条问题定义以下是我在 Discover 阶段收集到的用户反馈和调研笔记 [粘贴内容] 请帮我做三件事 1. 归纳最常见的几类问题模式 2. 按发生频率、痛苦程度、可验证性找出 3 个优先问题 3. 把每个问题写成一条具体的问题定义这样更容易从问题太多了的泥潭中进入 Define 阶段。也可以说得非常简单我目前收集到的问题 1. 不知道简历里写什么 2. 不知道怎么匹配调整 3. 总觉得不够好不敢投出去 请告诉我哪个问题最适合做成第一版。AI 可能输出推荐的优先问题 第一次申请实习的学生不确定自己的简历是否达到投递标准反复修改、无限拖延投递。 理由 1. 这个问题更具体 2. 它解释了拖延行为 3. 更容易设计一版小方案去验证这类输出非常有用它帮你从一堆模糊问题里蒸馏出一条可以作为 MVP 起点的定义。10.3 Develop 阶段用 AI 强制发散多套方案很多人定义完问题后就死盯着脑中冒出的第一个方案。AI 很适合逼你发散我已经定义好核心问题[你的问题定义] 请先不要给我一个最终方案而是从以下角度各给 23 个方案方向 1. 最轻量的 MVP 2. 最适合验证需求的方案 3. 体验增强型方案 4. 不用 AI 的方案 5. 使用 AI 的方案 最后对比每个方案的优点、风险与验证成本。这样你就不会过早锁定单一方案。更简单的 Prompt我当前的问题定义是 学生不确定简历是否达到可投递标准因此不断拖延。 请给我 4 个不同的方案方向不要只给一个。AI 可能输出方案 1可投递简历检查清单 方案 2基于职位描述做针对性改写 方案 3上传简历并给出风险提示 方案 4展示优秀范本供对照此时你更容易对比方案而不是从一开始只盯着 AI 改写。10.4 Deliver 阶段用 AI 生成原型文案与测试材料进入 Deliver 阶段后AI 特别擅长加速这些任务为低保真原型生成页面文案撰写用户测试脚本生成多版可对比的标题、按钮和描述文案测试后汇总反馈与问题清单。例如你可以让 AI 生成一份 20 分钟的用户测试脚本或把 5 条用户反馈归类为继续 / 调整方向 / 暂停。一个最小的 Prompt我做了个简单原型 用户上传简历系统提示哪些地方还不具备投递条件。 请生成一份 15 分钟的用户测试脚本。AI 可能输出15 分钟测试脚本 1. 先请用户描述最近一次写简历的经历 2. 让用户自己上传简历 3. 观察他是否理解反馈结果 4. 提问哪些提示最有帮助、哪些令人困惑 5. 提问下次投递前你还会再用这个工具吗这类输出非常实用它帮你从原型做完了直接过渡到接下来该怎么测。10.5 让 AI 担任阶段守门员双钻模型最常见的问题是人们会跳过阶段。你可以直接让 AI 扮演守门员提醒你当前身处何处请扮演一名产品流程教练。 以下是我当前的项目状态[你的描述] 请判断我目前更接近 Discover、Define、Develop 还是 Deliver。 并告诉我 1. 我是否过早跳进了下一阶段 2. 当前阶段最该补上的一个动作是什么 3. 现在哪些事情我还不需要做这对初学者尤其有帮助因为它能有效抑制问题还没想透就急着画原型的冲动。11. 总结先做正确的事再把事做正确双钻模型最大的价值在于把一个混沌过程拆解成四个更清晰的动作先发散理解问题再收敛定义问题再发散探索方案最后收敛交付方案。它不会让你变慢反而能帮你避开大量看起来很忙、方向却错了的弯路。在 AI 时代构建的速度越来越快双钻模型反而变得更加重要——当造东西越来越便宜时真正稀缺的能力是解决一个值得解决的问题并用恰当的方式把它做出来。只需要记住这一句话先做正确的事再把事情做正确。12. 章节练习结合以上内容建议完成以下四项任务对应原文档 附录任务卡片 中的 StageAssignmentCard 组件选一个你最近在琢磨的产品想法为 Discover、Define、Develop、Deliver 四个步骤各写一份草稿在 Define 阶段强迫自己把问题压缩成一句具体的话在 Develop 阶段至少列出 3 种不同的方案方向而不是只追第一个念头在 Deliver 阶段描述一个你可以在一周内交付的最小可验证版本。完成后可以继续学习 如何搭建可验证的原型把定义好的问题与选定的方案真正落地为可运行的 MVP并在 完整项目实战 中跑通定义问题 → 设计方案 → 原型验证 → 迭代交付的完整闭环。【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 easy-vibe 产品方法课：用 Double Diamond 双钻模型把“拍脑袋的 AI 点子“收敛成值得做的产品
easy-vibe 产品方法课用 Double Diamond 双钻模型把拍脑袋的 AI 点子收敛成值得做的产品【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe本文是 Datawhale easy-vibe 项目 Stage 1 产品思维系列中的核心方法课。它以英国 Design Council 提出的 Double Diamond双钻模型为主线讲解如何用两次发散、两次收敛把需求调研与用户访谈积累的混乱素材拆解为 Discover、Define、Develop、Deliver 四个可执行的阶段从而避免在问题尚未澄清时就急着画原型、接模型、写 PRD。读完本文你将掌握一套可直接套用的四阶段工作流模板、一张贯穿各阶段的可执行检查清单以及一组让 AI 作为流程加速器而非决策替代者的具体提示词能直接应用于你正在酝酿的任何 AI 产品想法。双钻模型把产品开发拆成两个钻石第一个钻石解决做正确的事先搞清楚该解决什么问题第二个钻石解决把事情做正确再决定用什么方案去解决。easy-vibe 的完整学习路径中该章节位于 Stage 1 需求分析与产品思维阶段见 学习地图 中附录Double-Diamond 模型条目是连接 发现好想法、产品思维基础、用户访谈Mom Test 与 原型搭建、完整项目实战 的枢纽章节。本文档全文位于 docs/de-de/stage-1/appendix-double-diamond/index.md。1. 两次发散与两次收敛为什么是双钻经过需求分析和用户访谈后你手上通常已经有大量素材不同用户的经历、现有工具的短板、若干个可行的改进方向。素材越多选择反而越难。如果理解问题和设计方案不做区分人很容易在访谈过程中就下意识地为自己的心头好功能寻找论据。双钻模型正是用**两次发散Divergieren和两次收敛Konvergieren**把这两类工作强行分开。它源自英国 Design Council 的传播与推广把问题空间与解决方案空间表示为两个首尾相接的菱形发散先扩大视野考察更多可能性收敛再收窄范围做出决策、设定优先级。整个流程由四个步骤组成Discover发现全面理解用户、问题、环境与市场Define定义从大量信息中过滤出真正值得解决的核心问题Develop开发围绕核心问题发散出多个解决方案Deliver交付选定方案制作原型、测试并交付最合适的解。把四步压缩成一句好记的话第一个钻石先搞清楚到底要解决什么问题第二个钻石再决定用什么方案去解决。前两个阶段处理的是问题空间后两个阶段处理的是解决方案空间。需要特别说明的是Design Council 同时强调这不是一条只走一次的线性流程。如果测试暴露了问题团队完全可以退回到更早的阶段重来——这一点对用 AI 快速迭代的 vibe coding 场景尤其重要。2. 为什么必须把问题与方案分开初学者做产品时的典型节奏往往是这样的冒出一个想法觉得方向很妙立刻开始画原型画着画着功能越加越多最后自己都不清楚到底在解决什么问题。双钻模型的价值不在于把流程变复杂而在于把理解问题与设计方案分离。这句话听起来平淡实践中却极其重要很多失败的产品并不是因为投入不够而是因为——选错了问题误解了用户过早锁定了方案在没有验证方向的情况下把大量时间花在了细节打磨上。双钻模型时刻提醒你三条反直觉的戒律不要因为想法看起来合理就默认问题已经清楚了不要因为方案技术上可行就默认它值得做不要因为原型看起来很完整就默认用户真的需要它。3. 第一个钻石问题空间Discover Define第一个钻石聚焦于问题本身而不是方案。它可以概括为一句话别急着开工先确认这件事值不值得做。3.1 Discover先打开问题空间Discover 阶段的核心任务是做全面研究而不是快速下结论。典型的动作包括观察用户在真实场景中的行为访谈潜在用户追问他们上一次遇到这个问题是什么时候观察他们现在是如何凑合应对的分析竞品与替代方案收集市场、流程、约束与价值链相关信息。很多人误以为 Discover 就是多读点资料但更重要的是你要理解的是人和场景而不只是收集信息。文档中给出了一个具体案例假如你想做一个用 AI 辅助生成会议纪要的工具Discover 阶段应优先澄清的是用户开完会后最累的是哪一环痛点到底在录音、总结还是分发用户是自己写、让实习生写、回听录音还是干脆不做纪要哪些会议场景最需要纪要哪些场景根本不需要。这个阶段最重要的目标不是找到答案而是不要过早相信自己已经找到了答案。3.2 Define从信息中蒸馏出核心问题如果 Discover 是打开视野那么 Define 就是收窄聚焦。Define 阶段不是要保留所有观察而是要追问哪个问题最重要、值得优先解决哪个问题发生频率最高、最痛、能带来最大价值第一版应该聚焦在哪个场景上。这一步骤的本质是把一个宽泛话题压缩成一条清晰的问题定义。比如你最初可能会说我想做一个提升会议效率的 AI 工具。经过 Define 阶段更优的表述可能是我们先解决项目团队开完 3060 分钟的协作会议后无法在 10 分钟内产出一份包含任务、负责人和截止时间的纪要这个问题。此时问题变得具体了用户是谁、场景是什么、瓶颈在哪、成功标准是什么。Define 的本质就是从问题很多收敛到这一次先解决哪个问题。4. 第二个钻石解决方案空间Develop Deliver只有完成第一个钻石后才应进入第二个钻石。因为这时你要解决的已经不是一个模糊的方向而是一个被明确圈定的具体问题。4.1 Develop围绕核心问题发散方案Develop 阶段的核心是针对同一个问题探索多种可能的解法。注意这种发散和 Discover 的发散不同Discover 的发散探索的是问题空间Develop 的发散探索的是解决方案空间。回到会议纪要的例子Develop 阶段你可以考虑做 Web 工具还是会议插件事后上传录音处理还是实时转写只做摘要还是聚焦任务抽取主打个人效率还是团队协同让用户自由编辑还是直接输出结构化模板。这一步骤非常适合头脑风暴和团队共创。但它有一个前提所有方案必须服务于同一个已定义的问题。如果问题没有定义清楚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 不意味着交付品必须完整。很多时候一个可测试的原型或一次小规模用户试用就已经是很好的交付物了。7. 双钻模型在 AI 产品中的落地方式AI 产品尤其容易掉进能力优先的陷阱因为模型能力实在太诱人了。你很容易直接开始想要不要做多模态要不要做 Agent要不要加 Workflow要不要接入语音、图片或联网搜索。但双钻模型强迫你先回答用户到底卡在哪一步这个问题是否必须用 AI 解决如果不用 AI现有做法最糟糕的地方是什么加上 AI 之后核心的进步到底是什么。这能帮你避免一种常见局面能力很强价值很弱。一套可操作的做法是Discover观察用户当前如何完成任务Define把最痛的场景写成清晰的问题定义Develop比较哪些 AI 能力最匹配这个问题Deliver做一版最小实现交给真实用户测试。8. 可直接套用的双钻模板如果你正在打磨自己的产品可以按下面的顺序逐项自问Discover我要观察的用户是谁他们上一次遇到这个问题是什么时候他们现在是怎么解决的什么最让他们烦躁、最慢、最不安心Define这些问题里哪个最有价值、应该先解决哪个场景出现最频繁或最关键第一版我们只服务谁、只做什么问题被成功解决后用户的状态会发生什么变化Develop针对这个问题有哪些可能的解法哪些方案最轻、最快、最容易验证哪些必须现在做哪些可以以后再做Deliver为了验证这个方向我们能交付的最小东西是什么它是流程图、原型还是 MVP我们要邀请谁来测试测试后我们如何决定继续 / 调整 / 放弃9. 一个零基础也能看懂的完整示例假设你想做一个帮助高校毕业生准备求职简历的 AI 工具。很多人会立刻跳进第二个钻石想的是一键美化智能改写自动 JD 匹配生成自我介绍。按照双钻模型更好的流程是这样的第一个钻石Discover和应届毕业生聊聊上次改简历是什么时候观察他们如何把旧简历改造成新版本弄清他们最困扰的到底是不知道写什么、不知道怎么改还是无法判断够不够好。Define收敛到更具体的问题定义不是学生不会做简历而是第一次申请实习的学生无法把自己已有的经历改写成贴合职位描述的表达因而迟迟不敢投递简历。第二个钻石Develop考虑多种方案模板库、AI 改写、职位对比、简历评分、案例参考等。Deliver第一版只做一件事基于职位描述改写经历要点交给 5 名学生试用观察他们是否更快提交第一版简历。你会发现当第一个钻石打磨充分后第二个钻石会变得异常清晰。这个示例的思路与 easy-vibe 中 完整的项目实战章节 采用的先验证方向、再做最小实现的节奏完全一致。10. 如何借助 AI 跑完整个双钻流程双钻模型本身不是 AI 工具但 AI 非常适合作为四个阶段的加速器。关键不在于让 AI 替你做决策而在于用它来拓宽视野、整理信息、对比方案、生成验证素材。以下是文档提供的、可直接复制的提示词Prompt与预期输出。10.1 Discover 阶段用 AI 搭建第一版信息地基在正式访谈和调研之前可以让 AI 先做一次轻量的问题澄清扫描市场上常见有哪些替代方案用户在公开社区里抱怨最多的是什么该问题会出现在哪些场景、哪些人群现有产品忽略了什么。这一步不能替代真实调研但很适合快速绘制一张问题地图。一个面向初学者的简单 Prompt我想做一个帮助学生改写简历的工具。 请不要急着给功能建议先告诉我这个问题里最常见的困难有哪些。AI 可能输出第一版问题地图 1. 不知道该写哪些经历 2. 不知道如何把简历匹配到具体职位 3. 改了很多遍仍不确定是否够好 4. 需要有人帮忙校对又不想总欠人情 5. 因为不确定而一拖再拖投递这种输出不是替你拍板而是让你更快进入 Discover。10.2 Define 阶段让 AI 帮你收敛问题定义信息收集完成后最难的往往是把问题压缩成一句真正清晰的话。你可以把调研笔记交给 AI请它压缩出多条问题定义以下是我在 Discover 阶段收集到的用户反馈和调研笔记 [粘贴内容] 请帮我做三件事 1. 归纳最常见的几类问题模式 2. 按发生频率、痛苦程度、可验证性找出 3 个优先问题 3. 把每个问题写成一条具体的问题定义这样更容易从问题太多了的泥潭中进入 Define 阶段。也可以说得非常简单我目前收集到的问题 1. 不知道简历里写什么 2. 不知道怎么匹配调整 3. 总觉得不够好不敢投出去 请告诉我哪个问题最适合做成第一版。AI 可能输出推荐的优先问题 第一次申请实习的学生不确定自己的简历是否达到投递标准反复修改、无限拖延投递。 理由 1. 这个问题更具体 2. 它解释了拖延行为 3. 更容易设计一版小方案去验证这类输出非常有用它帮你从一堆模糊问题里蒸馏出一条可以作为 MVP 起点的定义。10.3 Develop 阶段用 AI 强制发散多套方案很多人定义完问题后就死盯着脑中冒出的第一个方案。AI 很适合逼你发散我已经定义好核心问题[你的问题定义] 请先不要给我一个最终方案而是从以下角度各给 23 个方案方向 1. 最轻量的 MVP 2. 最适合验证需求的方案 3. 体验增强型方案 4. 不用 AI 的方案 5. 使用 AI 的方案 最后对比每个方案的优点、风险与验证成本。这样你就不会过早锁定单一方案。更简单的 Prompt我当前的问题定义是 学生不确定简历是否达到可投递标准因此不断拖延。 请给我 4 个不同的方案方向不要只给一个。AI 可能输出方案 1可投递简历检查清单 方案 2基于职位描述做针对性改写 方案 3上传简历并给出风险提示 方案 4展示优秀范本供对照此时你更容易对比方案而不是从一开始只盯着 AI 改写。10.4 Deliver 阶段用 AI 生成原型文案与测试材料进入 Deliver 阶段后AI 特别擅长加速这些任务为低保真原型生成页面文案撰写用户测试脚本生成多版可对比的标题、按钮和描述文案测试后汇总反馈与问题清单。例如你可以让 AI 生成一份 20 分钟的用户测试脚本或把 5 条用户反馈归类为继续 / 调整方向 / 暂停。一个最小的 Prompt我做了个简单原型 用户上传简历系统提示哪些地方还不具备投递条件。 请生成一份 15 分钟的用户测试脚本。AI 可能输出15 分钟测试脚本 1. 先请用户描述最近一次写简历的经历 2. 让用户自己上传简历 3. 观察他是否理解反馈结果 4. 提问哪些提示最有帮助、哪些令人困惑 5. 提问下次投递前你还会再用这个工具吗这类输出非常实用它帮你从原型做完了直接过渡到接下来该怎么测。10.5 让 AI 担任阶段守门员双钻模型最常见的问题是人们会跳过阶段。你可以直接让 AI 扮演守门员提醒你当前身处何处请扮演一名产品流程教练。 以下是我当前的项目状态[你的描述] 请判断我目前更接近 Discover、Define、Develop 还是 Deliver。 并告诉我 1. 我是否过早跳进了下一阶段 2. 当前阶段最该补上的一个动作是什么 3. 现在哪些事情我还不需要做这对初学者尤其有帮助因为它能有效抑制问题还没想透就急着画原型的冲动。11. 总结先做正确的事再把事做正确双钻模型最大的价值在于把一个混沌过程拆解成四个更清晰的动作先发散理解问题再收敛定义问题再发散探索方案最后收敛交付方案。它不会让你变慢反而能帮你避开大量看起来很忙、方向却错了的弯路。在 AI 时代构建的速度越来越快双钻模型反而变得更加重要——当造东西越来越便宜时真正稀缺的能力是解决一个值得解决的问题并用恰当的方式把它做出来。只需要记住这一句话先做正确的事再把事情做正确。12. 章节练习结合以上内容建议完成以下四项任务对应原文档 附录任务卡片 中的 StageAssignmentCard 组件选一个你最近在琢磨的产品想法为 Discover、Define、Develop、Deliver 四个步骤各写一份草稿在 Define 阶段强迫自己把问题压缩成一句具体的话在 Develop 阶段至少列出 3 种不同的方案方向而不是只追第一个念头在 Deliver 阶段描述一个你可以在一周内交付的最小可验证版本。完成后可以继续学习 如何搭建可验证的原型把定义好的问题与选定的方案真正落地为可运行的 MVP并在 完整项目实战 中跑通定义问题 → 设计方案 → 原型验证 → 迭代交付的完整闭环。【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址: https://gitcode.com/datawhalechina/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考