1. 项目概述当你的AI成为产品探索副驾如果你是一名产品经理或者正在从零到一打造一款产品下面这个场景你一定不陌生你隐约觉得用户有个痛点团队里有人提议“我们做个XX功能吧”老板问你“这个需求有多大”而你手头只有一些零散的用户反馈和直觉。你深知应该先做用户探索但一想到要设计访谈提纲、招募用户、整理海量笔记、再从中提炼出能说服所有人的证据……算了还是先画个原型吧。这就是产品探索Product Discovery的经典困境人人都知道它重要但真正能系统化执行的人少之又少。原因无他过程太“重”了。你需要同时扮演研究员、策略师和沟通者而大多数团队并没有配备专职的UX研究员。discovery.md这个项目就是为了解决这个核心痛点而生的。它不是一个复杂的软件而是一套精心设计的“技能包”Skill或“系统提示词”System Prompt其核心思想是将成熟的产品探索方法论如机会方案树、妈妈测试编码进AI让你的AI助手无论是Claude、ChatGPT还是Cursor的内置AI变成一个经验丰富的探索副驾。简单来说它把一位拥有14年产品探索经验的资深PM的思考框架和提问技巧变成了你可以随时调用的AI指令。你不需要成为研究方法论的专家只需要对AI说“我想开始产品探索”它就会一步步引导你完成从问题定义、访谈设计、洞察合成到成果包装的全过程并输出可直接分享给团队的Markdown文档。这对于独立开发者、初创团队PM、或是没有研究资源的中小团队而言无异于获得了一位随时待命、永不疲倦的虚拟研究伙伴。2. 核心设计思路为何是“副驾”而非“模板”市面上不乏各种产品探索的模板和框架从Notion到Confluence到处都能找到“用户访谈提纲模板”或“洞察合成画布”。那discovery.md的独特价值在哪里关键在于它的设计哲学它是一个交互式的“副驾”Copilot而不是一个静态的“模板”Template。这其中的区别决定了它是“活”的方法论还是“死”的表格。2.1 从“混乱”开始而非从“结构”开始大多数模板给你的第一件事是一个结构完美的空表格标题是“问题陈述”、“目标用户”、“关键指标”。这反而会吓退很多人因为我们的思考往往是从一团乱麻开始的。discovery.md反其道而行之。它的第一个指令/product-discovery启动后问你的第一个问题是“把你还没理清的那些混乱想法先倒出来。” 它鼓励你先进行“思维倾倒”Brain Dump把所有的假设、疑惑、道听途说的反馈、甚至是不成熟的解决方案全部不加评判地写出来。这个设计极其重要。它降低了启动的心理门槛让你不必一开始就追求“正确”或“完整”。只有先把所有素材摊在桌面上副驾才能帮你一起整理。它会识别你描述中的“解决方案语言”例如“我们需要一个更快的数据库”并提醒你“你描述的是一个解决方案而不是一个问题。让我们退一步想想。” 这种即时的、基于经验的“推回”Pushback是静态模板永远无法提供的。2.2 内嵌方法论与“有主见的”引导这个副驾不是中立的。它被注入了Rob Fitzpatrick的《妈妈测试》The Mom Test和Teresa Torres的“机会方案树”Opportunity Solution Tree等经典方法论的精髓。这意味着它的引导是“有主见的”Opinionated。例如当它帮你设计访谈问题时它会自动生成符合《妈妈测试》原则的问题——聚焦用户过去的具体行为和事实而非他们对未来的空想或偏好。它会警告你“注意这个问题可能会引导用户给出你想要的答案。” 它还会内置一个“饱和度追踪器”建议你“采访5-7个用户如果连续3个没有新主题出现就可以考虑停止”。这种内化的专业知识让一个新手PM也能像资深研究员一样提问和思考避免了因提问方式不当而收集到无效甚至误导性数据。2.3 产出即资产可移植的Markdown工作流整个探索过程的产出物是四个核心的Markdown文件存放在discovery/{项目名称}/目录下。这种设计带来了几个关键优势零锁定Zero Lock-in文件是纯文本可以用任何编辑器打开可以轻松粘贴到GitHub Issue、Linear任务、Confluence页面、Notion数据库甚至直接作为邮件正文发送。你不依赖于某个特定平台。过程可视化这四个文件清晰地记录了探索的完整逻辑链从最初的假设到最终的决策建议。任何团队成员或未来的你都能追溯整个思考过程理解结论从何而来。迭代基础当需要后续验证或进入下一轮探索时这些文件就是最好的起点。你可以基于synthesis.md中的机会树直接规划下一批实验。这套工作流将探索从一个模糊的“阶段”变成了一个可重复、可追溯、可协作的清晰流程。3. 四步工作流深度解析与实操要点discovery.md的核心是四个交互式命令对应产品探索的四个关键阶段。下面我们拆解每个命令的具体工作、输出物以及实操中的注意事项。3.1 第一阶段问题界定与探索简报 (/product-discovery)目标将模糊的想法转化为一个结构化的探索假设和研究计划。输出discovery/{项目名称}/brief.md这个阶段副驾会通过一系列对话引导你澄清核心问题。典型流程如下混乱开场它首先会让你描述所有相关的、未结构化的想法。问题提炼它会从你的描述中识别出潜在的“问题陈述”并和你一起打磨确保这是一个真正的“问题”如“用户流失率高”而不是一个隐藏的“解决方案”如“我们需要一个新手教程”。假设具体化它会追问“关于这个问题你目前最核心的假设是什么” 例如“我们假设新用户在首次使用后的第3天流失是因为没有找到核心功能的‘啊哈时刻’。”研究问题生成基于假设它会帮你列出需要验证的具体研究问题。例如“用户在第3天前通常尝试了哪些操作成功和失败的比例如何”成功标准定义它会问“什么样的证据能让你确信这个假设被证实或证伪” 这有助于后续判断探索是否成功。实操心得如何写出有价值的“混乱想法”不要试图在第一步就写得很有条理。恰恰相反把你平时在便签、聊天记录里那些碎片化的念头都写出来。比如“销售说客户总抱怨报告生成慢”、“我看后台数据发现功能A的使用率很低”、“我猜用户可能不知道有这个入口”、“竞品X最近上线了一个类似功能我们是不是落后了” 把这些都扔给AI。它的价值就在于能从这片混沌中帮你识别出哪些是现象哪些是猜测哪些是解决方案。3.2 第二阶段访谈提纲设计 (/product-discovery interview)目标生成一份能揭示真相、而非迎合假设的用户访谈指南。输出discovery/{项目名称}/interview-guide.md这是最容易出错也是副驾价值最大的环节。它会基于你的brief.md自动生成一份访谈提纲。关键特性包括妈妈测试化问题所有问题都经过设计旨在挖掘用户过去的具体行为。例如不问“你会不会用这个功能”未来假设而是问“上次你遇到XX问题时实际是怎么解决的”过去事实。偏见警告对于每个可能带有引导性的问题副驾会标注警告并建议更中立的问法。结构化流程提纲通常包含暖场、背景了解、核心经历探索、痛点深挖、结束语等部分逻辑流畅。饱和度建议文档会注明建议访谈5-7名用户并关注新洞察何时停止出现。注意事项别把提纲当剧本副驾生成的提纲是“指南”不是“剧本”。在实际访谈中你必须保持灵活跟随用户的回答深入挖掘。如果用户提到一个提纲外但极其重要的点要果断跳脱提纲去追问。提纲的作用是确保你不遗漏关键假设的验证而不是限制对话。访谈结束后你可以将原始的、杂乱的笔记直接用于下一步。3.3 第三阶段洞察合成与机会挖掘 (/product-discovery synthesize)目标将零散的访谈笔记转化为清晰的模式、痛点优先级和商业机会。输出discovery/{项目名称}/synthesis.md这是从“数据”到“洞察”的魔法环节。你只需要将多份访谈的原始记录直接复制粘贴进去交给副驾。它会主题聚类自动阅读所有笔记识别并归纳出反复出现的主题Themes。例如“5/7的用户提到在跨部门协作时信息不同步”。引用关联为每个主题附上真实的用户原话Quotes让洞察有血有肉增强说服力。痛点排序根据提及的频率和情感的强烈程度对识别出的痛点进行初步排序。构建机会方案树这是核心产出。副驾会以你最初要解决的“问题”为树干将合成出的“用户痛点”作为主要树枝机会从而可视化地展现有哪些潜在的改进方向。这能有效防止团队直接跳转到讨论“解决方案”而是先对齐“要抓住哪些机会”。核心技巧如何准备用于合成的笔记合成效果的好坏很大程度上取决于你喂给AI的“原料”。建议在访谈后尽快整理笔记并遵循以下格式用户编号/代号如 User01 User02。关键引语逐字记录用户重要的原话用引号标明。你的观察记录用户的语气、情绪如“说到这里时显得很沮丧”、以及非语言信息。避免即时解读在笔记阶段尽量客观记录事实你的分析和解读可以放在另一个区域或之后再进行。 将这样整理过的笔记粘贴给AI它能更准确地进行跨用户的模式识别。3.4 第四阶段成果包装与决策建议 (/product-discovery package)目标制作一份面向利益相关者老板、团队、投资人的决策简报。输出discovery/{项目名称}/one-pager.md探索的最终目的是驱动决策。这个命令将synthesis.md中的洞察打包成一份精炼的、可行动的简报。它通常包含执行摘要TL;DR一段话总结核心发现和建议。证据摘要用简明的要点列出支持结论的关键发现和用户引语。机会评估基于“四风险模型”价值、可用性、可行性、商业可行性对主要机会进行快速评估。明确建议给出GO推进、PIVOT转向即解决另一个已发现的机会、或KILL终止的清晰建议并说明理由。这份一页纸的文档是你与工程、设计、市场等部门沟通以及向上汇报时最有力的武器。它用证据取代了猜测用结构化分析取代了个人感觉。4. 不同AI工具的集成与实战配置discovery.md 的灵活性体现在它能适配多种AI工作环境。以下是针对不同工具的具体配置方法和实战建议。4.1 聊天式AIClaude.ai / ChatGPT / 通义千问等这是最通用、门槛最低的方式。你不需要安装任何东西只需要复制粘贴。操作流程获取系统提示词打开项目中的system-prompt.md文件复制全部内容。配置AIClaude.ai进入“Projects”页面创建一个新项目Project。在项目设置中找到“Project Instructions”或“系统指令”将复制的提示词粘贴进去并保存。此后在该项目内的所有对话AI都会扮演你的探索副驾。ChatGPT创建或编辑一个“自定义GPT”Custom GPT。在配置Configure页面的“Instructions”框中粘贴提示词。或者在任意新对话的开头直接粘贴这段提示词然后开始对话。启动在配置好的对话中直接输入“I want to start product discovery”或中文“我想开始产品探索”副驾就会被激活。实战建议为不同探索项目创建独立对话强烈建议为每一个独立的产品探索课题创建一个全新的对话在Claude Project或单独的ChatGPT对话中。这样能保持上下文纯净避免不同项目的信息相互干扰。你可以在对话名称中注明项目例如“探索用户注册流程流失分析”。4.2 智能代码编辑器Cursor / Windsurf对于整天泡在代码编辑器里的技术型PM或开发者这是最无缝的体验。AI能力被深度集成到开发环境中。操作流程获取技能文件复制项目中的SKILL.md文件。放置到规则目录Cursor在你的项目根目录下创建或找到.cursor/rules文件夹将复制的文件粘贴进去可重命名为product-discovery.md。Windsurf类似地在项目根目录的.windsurfrules/文件夹内放置该文件。使用在编辑器内通过快捷键通常是CmdK或CtrlK唤起AI指令面板输入/product-discovery即可调用。优势与场景这种方式特别适合在技术上下文中进行探索。例如当你正在查看一段用户行为相关的代码或日志时可以直接唤出副驾结合代码上下文讨论用户可能遇到的问题。所有产出的Markdown文件也会直接生成在你的项目目录里与代码资产放在一起管理。4.3 命令行AI工具Claude Code适合喜欢终端操作、追求极致效率的用户。Claude Code是Anthropic推出的命令行AI工具。操作流程安装并配置Claude Code需API Key。将SKILL.md文件复制到你的项目目录下例如your-project/.claude/skills/product-discovery/SKILL.md。在终端中进入你的项目目录直接输入命令/product-discovery并回车Claude Code就会加载该技能并开始交互。4.4 无AI的纯手动模式即使没有AI项目中的templates/目录也提供了四个完整的Markdown模板文件。你可以直接打开它们根据指引手动填写。这相当于获得了一套经过验证的、结构化的探索文档框架其价值依然远超从空白页面开始。5. 从理论到实践一个完整的B2B SaaS案例推演让我们通过一个虚构但非常典型的案例看看discovery.md如何在实际中发挥作用。背景你是一款名为“TeamFlow”的团队协作SaaS产品的产品经理。数据显示有35%的团队在试用期的前90天内流失停止付费。销售团队反馈是“集成不够”工程团队提议“优先开发Jira导入器”。传统做法很可能陷入内部争论或直接开始开发Jira导入器。使用discovery.md的流程第一周问题界定你启动Claude.ai中配置好的探索项目输入“I want to start product discovery”。AI副驾问“关于90天流失你目前所有未整理的想法是什么”你写下“销售说集成差我猜新团队上手太难后台看到‘项目设置’页面跳出率高竞品有Slack深度集成……”经过几轮问答副驾帮你产出brief.md核心假设被提炼为“团队负责人Champion在试用第6-8周因精力耗尽而流失原因是TeamFlow未能无缝嵌入他们现有的Slack沟通工作流导致工具被边缘化。” 研究问题聚焦于用户实际的工作流、使用中的断点、放弃时的具体情境。第二周访谈执行输入/product-discovery interview。副驾生成一份7个问题的访谈指南问题如“回忆一下你上次为了同步项目状态不得不离开TeamFlow去其他应用如Slack、邮件的情景当时具体发生了什么”“在试用期间哪一刻你感觉使用TeamFlow变成了一个负担”你访谈了7位已流失团队的负责人。将原始笔记包含大量细节和引语保存下来。第三周洞察合成将7份访谈笔记粘贴运行/product-discovery synthesize。产出synthesis.md关键发现主题1Slack信息孤岛6/7人提及所有关键更新任务完成、文件评论都停留在TeamFlow内负责人不得不手动复制到Slack同步团队工作量倍增。主题2第6周负担峰值5/7人提及大约在第6周随着项目深入这种手动同步的频率和复杂度达到顶峰负责人感到“维护两个信息源太累了”。主题3自定义配置墙4/7人提及团队在第三周试图根据自身流程调整设置时遇到困难但未直接导致流失只是增加了挫败感。机会方案树清晰显示最大的机会枝干是“减少跨工具同步的摩擦”而非“增加更多集成功能”。第四周决策建议运行/product-discovery package。产出one-pager.md核心建议是GO但方向不是开发Jira导入器。而是“优先构建智能的Slack同步机器人将TeamFlow内的关键更新自动推送至对应Slack频道并支持在Slack内完成简单审批/评论。” 并附上强有力的用户引语作为证据。最终成果你拿着一页纸的one-pager.md去开会用真实的用户声音说服了团队和老板避免了在一个低优先级功能上浪费数月工期将资源投入到真正能降低流失的核心机会上。整个探索过程你没有一个UX研究员协助但产出的专业度和说服力丝毫不逊色。6. 常见陷阱、避坑指南与高阶技巧即使有了强大的副驾探索过程依然需要人的判断。以下是一些关键注意事项和提升效果的心得。6.1 访谈环节的典型陷阱陷阱把提纲当审讯稿。表现机械地逐个念问题不顾用户的回答逻辑。避坑将提纲视为“检查清单”。聆听用户回答时思考它回应了提纲中的哪个核心假设并自然过渡。多用“你刚才提到XX这很有意思能再多说说吗”进行深度挖掘。陷阱为自己辩护。表现当用户批评产品时下意识解释“其实我们这个功能是为了……”。避坑牢记探索的目的是“学习”不是“推销”。对批评要说“谢谢你指出这一点这对我改进产品太重要了”然后追问细节。陷阱样本同质化。表现只访谈最喜欢你产品的用户或同一类型的用户。避坑主动招募“边缘用户”快流失的、沉默用户用了但没反馈的、甚至竞品用户。他们的视角往往更有颠覆性。6.2 合成与决策阶段的误区误区过度依赖AI归纳放弃人的思考。表现对AI合成的主题照单全收不再审视。避坑AI是强大的模式识别助手但最终的洞察需要你结合业务背景来判断。亲自阅读原始引语问自己“这个主题背后用户未说出的深层需求是什么”误区将“用户说的”直接等同于“要做的”。表现用户说“想要一个仪表盘”就规划开发仪表盘。避坑运用“五个为什么”或“用户任务分析”深挖。用户想要仪表盘解决方案是为了完成什么任务可能是“快速了解项目健康度”。有没有更简单、更优雅的方式完成这个任务机会方案树的作用就是帮你停留在“机会”层面进行讨论。误区忽视可行性与商业价值。表现one-pager.md给出了GO的建议团队就立刻开干。避坑副驾基于“价值风险”给出了建议但技术可行性工程难度、商业可行性成本、营收影响需要你联合技术负责人和商业负责人进行快速评估。可以在建议部分手动补充这部分联署意见。6.3 让副驾更“懂你”的高阶技巧提供行业背景在开始探索前或是在brief.md中花几句话向AI描述你的行业、产品类型、用户画像。这能帮助它生成更贴切的访谈问题和进行更精准的合成分析。迭代优化提示词如果你发现副驾在某些环节的引导不符合你的习惯可以直接修改system-prompt.md或SKILL.md文件。例如你可以增加一条规则“在生成访谈问题时额外包含一个关于‘预算与采购流程’的问题因为我们是B2B企业级产品。”结合量化数据在synthesis阶段除了粘贴定性访谈笔记你也可以简要输入一些关键的量化数据如“后台数据显示60%的流失用户从未使用过X功能”。AI可以尝试将定性与定量发现结合起来形成更立体的洞察。7. 适用边界与何时需要“升级”discovery.md是一个强大的“最小化可行研究”工具但它并非万能。清楚它的边界能让你更好地使用它。它非常适合从0到1验证一个新想法或问题。对已有的用户反馈进行深度挖掘和模式识别。在资源有限的情况下快速启动并系统化探索流程。作为产品经理个人的思考辅助和文档工具。它可能不足你需要寻求更多支持大规模定量验证当定性探索发现了一个明确的机会需要估算市场规模或验证普遍性时你需要传统的A/B测试、问卷调查等定量方法。复杂的用户体验评估对于详细的界面可用性测试、交互流程走查仍需专业的可用性测试方法和眼动仪等工具。高度专业或敏感领域医疗、金融等强监管领域或涉及深度用户心理的研究仍需伦理审查和资深研究员主导。组织级研究知识库建设如果需要构建公司级、可搜索、可追溯的全量用户研究知识库则需要更专业的研究运营平台如Dovetail, EnjoyHQ。核心定位discovery.md是你的“探索瑞士军刀”和“虚拟研究合伙人”。它不能替代一个完整的研究团队但它能确保你在没有这个团队时依然能以专业、系统的方式开展工作避免在真空中造车。它降低了高质量产品探索的门槛让“持续与用户对话”成为一种可执行的日常习惯而不仅仅是一个挂在墙上的美好理念。