企业官网建设流程全解析

PM Skills 的 /discover 命令：从发散头脑风暴到聚焦验证的端到端产品发现工作流

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills

PM Skills Marketplace 的pm-product-discovery插件提供了一个将发散思维收敛为可验证假设的完整产品发现循环命令/discover。本文以 pm-product-discovery/commands/discover.md 为核心，逐阶段拆解其 7 步工作流，并结合仓库内brainstorm-ideas-*、identify-assumptions-*、prioritize-assumptions、brainstorm-experiments-*等底层技能源码，说明每一步在 Agent 内部是如何被编排与执行的。读完本文，你将掌握一条 15～30 分钟即可跑完的结构化发现流程，能直接产出包含创意清单、关键假设、验证实验与决策框架的发现计划文档。

命令概览：一条命令串联四种技能

/discover是一条由用户主动触发的命令（command），它在 README.md 中被定义为 "Full discovery cycle: ideation → assumption mapping → prioritization → experiment design"。与单点技能（skill）不同，命令的价值在于链式编排：它把发散、批判、聚焦、验证四个阶段无缝衔接，让用户不必记住每一步该调用哪个技能。

从仓库根目录的 README.md 可以看到其编排结构：

/discoverchains four skills together: brainstorm-ideas → identify-assumptions → prioritize-assumptions → brainstorm-experiments.

也就是说，一条命令背后实际挂载了四条技能链路，每条链路又根据"现有产品 / 新产品"分叉出两个版本。从 validate_plugins.py 的校验逻辑（validate_command会解析命令文件中的**skill-name** skill引用并做交叉校验，见validate_cross_references）可以看出，这种"命令引用技能"的写法是仓库内所有命令的标准契约，任何引用了本插件内不存在的技能的命令都会在构建期被标记为 warning。

/discover命令文件自身的 YAML frontmatter 也很能说明它的定位：

--- description: Run a full product discovery cycle — from ideation through assumption mapping to experiment design argument-hint: "<product or feature idea>" ---

其中argument-hint提示调用者需要提供"产品想法或功能想法"作为入参；description则是 Agent 理解该命令何时适用的元数据。

调用方式：三条等价入口

/discover支持两种参数形式，也支持无参数交互模式：

/discover Smart notification system for our project management tool /discover New product: AI writing assistant for non-native speakers /discover # asks what you're discovering

• 直接传入想法：如第一条命令，适用于"已有明确功能想法、想验证其价值"的场景；
• 标注新产品：如第二条命令，New product:前缀让 Agent 从一开始就按"初始发现（initial discovery）"模式组织流程；
• 不带参数：Agent 会先询问"你正在发现什么"，再进入正式流程。

工作流 Step 1：澄清发现上下文

流程的第一步不是直接头脑风暴，而是先判断发现类型。/discover要求 Agent 区分两种截然不同的场景：

• 现有产品（Existing product）——在已知产品上做持续发现（continuous discovery），拥有真实用户与使用数据；
• 新产品（New product）——针对尚无验证需求的概念做初始发现（initial discovery）。

随后需要向用户确认三个问题：

1. 你在探索什么？（产品想法、功能领域、机会空间）
2. 你已经知道了什么？（既往研究、客户反馈、数据）
3. 这次发现将支撑什么决策？（做/砍、排优先级、转向）

同时，命令明确要求 Agent 接受来自上传文件（研究报告、PRD、访谈记录、数据）、链接或对话的上下文。这与底层技能的行为一致——例如identify-assumptions-new技能要求"若用户提供了商业计划或研究文件，先阅读它们"。

工作流 Step 2：发散阶段——多视角头脑风暴

确认上下文后，Agent 会应用 brainstorm-ideas-existing 或 brainstorm-ideas-new 技能，进入发散阶段。

三视角并行产出

两个版本的技能都要求从PM、设计师、工程师三个视角各生成 5 个想法（共 15 个），随后跨视角选出 top 5。这一方法论的源头在技能的 Domain Context 中明确标注为Product Trio（Teresa Torres,Continuous Discovery Habits）——PM 与设计师、工程师共同参与发现，且"最好的想法往往来自工程师"。

各视角的关注点差异如下：

从 15 个想法收敛到 3～5 个

/discover在技能输出的 top 5 基础上做了一层"展示 10 个、带走 3～5 个"的处理：向用户展示top 10 想法并附简要理由，由用户挑选 3～5 个继续推进，也可以全盘接受。每一步都设有检查点（checkpoint），原文档给出了标准的检查点话术：

"Here are 10 ideas. Which ones should we stress-test? Pick 3-5, or I can carry all forward."

值得注意的细节是：new 版技能在选择 top 5 时会对三个标准做加权——核心价值交付（是否解决首要问题）、验证速度（能否快速测试）、差异化潜力——这对应了初始发现阶段"先验证需求渴望度（desirability），再谈可行性（feasibility）"的原则。

工作流 Step 3：批判阶段——假设识别

选定的每个想法都要经受 identify-assumptions-existing 或 identify-assumptions-new 技能的"魔鬼代言人"式拷问。

两类风险框架：4 类 vs 8 类

existing 版技能覆盖 Teresa Torres 提出的4 类核心产品风险：

• Value（价值）：用户会想要它吗？它是否解决真实问题？
• Usability（可用性）：用户能搞懂怎么用吗？学习曲线可接受吗？
• Viability（商业可行性）：市场、销售、财务、法务能支持它吗？
• Feasibility（技术可行性）：现有技术能构建吗？存在集成风险吗？

new 版技能则将风险扩展为8 类，在 4 类核心风险之外新增了初始发现阶段尤为关键的 4 类：

• Ethics（伦理）：我们是否应该做这件事？是否会对客户构成风险？
• Go-to-Market（上市）：能否触达并转化用户？渠道、信息、时机是否恰当？（对新产品尤其关键）
• Strategy & Objectives（战略与目标）：战略是否易被复制？PESTEL 因素是否已考虑？
• Team（团队）：团队协作、人员、工具是否到位？团队能否长期保持？

identify-assumptions-new技能中有一句值得反复咀嚼的提醒："好的团队应假设其至少四分之三的想法不会达到预期表现（Good teams assume at least three-quarters of their ideas won't perform as they hope）"——这正是假设识别阶段存在的意义。

每条假设的三要素

无论哪个版本，技能都要求对每条假设标注：具体可能出错的地方、自信程度（High/Medium/Low）、建议的验证方式。/discover会在这一步把所有想法的假设汇总成主清单（master list），供下一步统一排序。

工作流 Step 4：聚焦阶段——假设优先级排序

有了主清单，下一步交给 prioritize-assumptions 技能，用Impact × Risk 矩阵（影响 × 风险矩阵）做取舍。

矩阵的四个象限

技能为每条假设计算两个维度后落入四象限：

其中Impact与Risk的计算公式在技能的 Domain Context 中给出：Impact = Opportunity Score × #Customers，Risk = (1 − Confidence) × Effort。这里的 Opportunity Score（机会分数，源自 Dan OlsenThe Lean Product Playbook）定义为Importance × (1 − Satisfaction)，两者都归一化到 0～1。技能同时提示，若读者需要 ICE / RICE 等更多排序框架的完整公式与模板，可查阅仓库内的prioritization-frameworks技能。

分组测试与检查点

优先级排序后，/discover要求将可以一起测试的相关假设分组，以降低实验轮次。随后给出第二个检查点：

"Here are your riskiest assumptions. Which ones feel most critical to validate first?"

用户可以在这一步重定向、跳过或深入任何一条假设——这是整个流程中"人机协同"的关键设计。

工作流 Step 5：验证阶段——实验设计

针对最高优先级的假设，Agent 应用 brainstorm-experiments-existing 或 brainstorm-experiments-new 技能，为每条关键假设设计 1～2 个实验。

现有产品：低成本的验证工具箱

existing 版技能提供的方法库包括：

• 首击测试 / 原型任务完成测试（first-click testing / task completion with a prototype）
• 假门测试（fake door tests）——功能桩（feature stubs），观察用户是否真的点击
• 技术探针（technical spikes）
• 生产环境 A/B 测试（需说明风险缓解策略）
• 幕后人员模拟（Wizard of Oz）
• 行为导向调研（behavioral surveys，而非观点导向）

技能的实验设计三原则同样值得牢记：测量真实行为而非用户观点；负责任地测试——不把用户或业务置于风险中；用最小努力换取最大验证学习。

新产品：XYZ 假设与假原型

new 版技能遵循 Alberto Savoia（The Right It）的精益创业实验法。首先是XYZ 假设模板：

At leastX%ofYwill doZ

其中 X% 是预期参与的目标市场比例，Y 是特定目标市场，Z 是他们的具体行为。随后建议 2～3 个**假原型（pretotype）**实验：

• 落地页（Landing Page）：用注册数/点击数测兴趣
• 解说视频（Explainer Video）：用参与度指标测理解与吸引力
• 邮件营销（Email Campaign）：用响应率与点击率测需求
• 预购 / 候补名单（Pre-Order / Waitlist）：用真金白银的承诺测付费意愿
• 礼宾式 / 手动 MVP（Concierge / Manual MVP）：手动交付服务来测价值

该技能还强调两条核心原则：Skin-in-the-Game——用时间、金钱、声誉这类真实投入测试付费意愿，兴趣不等于承诺；Your Own Data (YODA)——通过自己的实验收集数据，而不是依赖市场报告这类"他人数据"，因为"你的想法所处的市场并不关心别人的想法所处的市场"。

统一的实验要素

无论哪种模式，每个实验都必须明确四项内容：验证的假设、实验方法、度量指标、成功阈值（success threshold）。/discover还会要求按依赖关系与工作量为实验排定顺序。

工作流 Step 6：产出发现计划文档

所有阶段的产出会在最后被汇编为一份发现计划（Discovery Plan）Markdown 文档，保存到用户的工作区。原文档给出了完整模板，本文完整保留如下：

## Discovery Plan: [Topic] **Date**: [today] **Product Stage**: [existing/new] **Discovery Question**: [what we're trying to learn] ### Ideas Explored [Summary of brainstormed ideas with brief descriptions] ### Selected Ideas for Validation [3-5 ideas carried forward with rationale] ### Critical Assumptions | # | Assumption | Category | Impact | Uncertainty | Priority | |---|-----------|----------|--------|-------------|----------| ### Validation Experiments | # | Tests Assumption | Method | Success Criteria | Effort | Timeline | |---|-----------------|--------|-----------------|--------|----------| ### Experiment Details [For each experiment: hypothesis, setup, measurement, decision criteria] ### Discovery Timeline Week 1: [experiments] Week 2: [experiments] Week 3: [analysis and decision] ### Decision Framework - If [experiment] succeeds → proceed to [next step] - If [experiment] fails → [pivot/kill/investigate further]

这份模板的设计非常讲究：

• 两张表格分别沉淀了"关键假设"（含类别、影响、不确定性、优先级）与"验证实验"（含方法、成功标准、工作量、时间线），是后续追踪的直接输入；
• 决策框架（Decision Framework）以"若成功则继续、若失败则转向/砍掉/深挖"的 if-then 结构，把验证结果转化为可执行的下一步；
• 文档被要求作为**活文档（living document）**维护——命令明确提示在实验运行期间主动提出更新它。

工作流 Step 7：衔接下一步

发现计划产出后，/discover会主动提供四条衔接建议，把流程导向仓库中的其他命令与技能：

• "Want me tocreate a PRDfor the top idea?"（衔接pm-execution插件的write-prd命令）
• "Should Idesign an interview scriptto supplement these experiments?"（衔接 interview-script 技能与interview命令）
• "Want me toset up metricsto track the experiments?"（衔接 metrics-dashboard 技能与setup-metrics命令）
• "Should Iestimate effortand create user stories for the MVP?"（衔接pm-execution插件的write-stories命令）

这种"命令流式衔接"是 PM Skills Marketplace 的设计哲学——README 中明确写道："Commands are designed to flow into each other, matching the PM workflow. After any command completes, it suggests relevant next commands——just follow the prompts." 发现不是终点，它只是产品工作流的第一环。

与同插件其他命令、技能的关系

/discover不是孤岛，它是pm-product-discovery插件（13 个技能、5 个命令，见 pm-product-discovery/README.md）中最长的一条链路。理解它与相邻组件的关系，有助于按需裁剪流程：

• brainstorm.md（/brainstorm）：/discover的发散阶段被拆出来单独成命令，支持ideas|experiments × existing|new四种组合模式，适合只想做单点头脑风暴的场景；
• opportunity-solution-tree技能：提供"期望结果 → 机会 → 解决方案 → 实验"四层可视化框架，是identify-assumptions与prioritize-assumptions的上游思考工具，也遵循"每次为每个机会生成至少 3 个解决方案、避免首个想法陷阱"的原则；
• prioritize-features技能：在发现完成后，对 backlog 中的功能想法按影响、工作量、风险、战略一致性排序，输出 top 5 推荐；
• triage-requests命令：处理客户/利益相关者批量功能请求的轻量路径，适合不想跑完整发现循环的场景。

使用注意事项

原文档在 Notes 一节给出了六条实操纪律，完整保留如下：

• 这是一条15～30 分钟的结构化流程——开始时就要让用户知晓这一预期；
• 每个检查点用户都可以重定向、跳过或深入；
• 如果用户带有研究数据，在头脑风暴之前先从中提炼洞见；
• 发现计划应是活文档——实验运行期间主动提出更新；
• 对新产品，先强调需求渴望度验证，再做可行性验证；
• 对现有产品，检查是否有可支撑假设的使用数据。

前两条定义了节奏与人机分工：固定时长约束保证流程高效，检查点设计保证用户始终掌握方向盘。后四条则是方法论层面的判断准则——尤其是"现有产品先用数据说话"这条，与identify-assumptions-existing技能"基于真实用户行为而非观点"的实验原则一脉相承。

小结

/discover的价值在于把分散在 6 个技能文件里的方法论——Product Trio 多视角头脑风暴、Teresa Torres 的四类产品风险与机会分数、Alberto Savoia 的假原型与 XYZ 假设、Dan Olsen 的 Impact × Risk 矩阵——压缩成一条带检查点、带模板、带后续衔接建议的可执行命令。对 PM 而言，它是"从灵光一现到可验证假设"的最短路径；对 Agent 开发者而言，discover.md 本身就是一个优秀的命令编排范本——清晰的 frontmatter、分步指令、可复用的检查点话术、结构化的产出模板，以及指向底层技能的可追溯引用，值得在构建自己的链式命令时直接借鉴。

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills