企业官网建设流程全解析

• AI 技能
• AI 插件

本篇技术指南围绕 Product-Manager-Skills 开源仓库中的 epic-hypothesis 模板 展开，讲解如何把一个模糊的"大需求（epic）"改写为具备行动对象、目标人群、预期结果与验证方式的 If/Then 假设，并配套"轻量发现实验（Tiny Acts of Discovery）"与"验证指标（Validation Measures）"两段式结构。读完本文，你将掌握模板的逐字段填写方法、质量检查清单、五种典型反模式，以及如何把验证后的 epic 拆解为用户故事，直接可复制到实际产品工作中。

模板速览：三段落式可证伪假设

skills/epic-hypothesis/template.md是技能epic-hypothesis（SKILL.md）要求使用的填充式结构。它把一次史诗级投入压缩成三块、总共可在一张卡片里写完的内容：

### If/Then Hypothesis **If we** [action or solution on behalf of the target persona] **for** [target persona] **Then we will** [desirable outcome or job-to-be-done] ### Tiny Acts of Discovery Experiments **We will test our assumption by:** - [Experiment 1] - [Experiment 2] - [Add more as necessary] ### Validation Measures **We know our hypothesis is valid if within** [timeframe] **we observe:** - [Quantitative measurable outcome] - [Qualitative measurable outcome] - [Add more as necessary]

模板的源头信息在文件尾部 Provenance 一节有明确标注：改编自prompts/backlog-epic-hypothesis.md（来自 deanpeters 的 product-manager-prompts 仓库），If/Then 句式灵感来自 Tim Herbig 的 Lean UX hypothesis format。需要特别强调的是，这个模板不是需求规格书，而是一条"你正在验证、而非承诺交付"的假设——这是使用它的第一原则。

核心框架拆解：三段各解决什么问题

根据 SKILL.md 的 Key Concepts 部分，框架的每一段都对应一个关键的产品管理动作：

• If/Then Hypothesis（假设声明）：用一句话说清楚"我们为谁做什么、期望得到什么结果"。模板字段即If we [行动/方案]+for [目标人群]+Then we will [理想结果或待办任务]。
• Tiny Acts of Discovery Experiments（轻量发现实验）：在正式开工前，用低成本、快周期的手段去验证假设，而不是直接进入完整构建。
• Validation Measures（验证指标）：定义"在多长时间内观察到什么量化/质性结果"就算假设成立，使整条假设可证伪（falsifiable）。

这套结构之所以有效，SKILL.md 归纳了五条理由：假设驱动（迫使你说出自己相信什么、可能错在哪）、结果导向（"Then we will" 强调用户收益而非功能产出）、实验优先（在完整构建前先做轻量验证）、可证伪（明确的成功标准让你能尽早杀掉坏主意）、风险管理（把 epic 当作下注而非承诺）。

六个步骤：从上下文收集到用户故事拆解

SKILL.md 给出了完整应用流程，模板是其中第 2 至 4 步的直接载体。

第 1 步：收集上下文

动笔前确认你拥有四类输入：问题理解（可参考 problem-statement/SKILL.md）、目标人群（参考 proto-persona/SKILL.md）、待办任务（参考 jobs-to-be-done/SKILL.md）、以及用户当前替代方案（竞品、变通做法、什么都不做）。缺上下文时，先跑发现访谈或问题验证工作再回来。这一点与仓库中的 discovery-process 技能直接衔接——该技能把epic-hypothesis列为发现通过（GO）后的组件，并给出"每条 epic 约 60 分钟"的耗时预算（discovery-process/SKILL.md）。

第 2 步：起草 If/Then 假设

直接按模板填充，并对照三条质量检查：

• "If we" 必须具体：不是"improve the product"，而是"add one-click Slack notifications when tasks are assigned"。
• "For" 必须是清晰的人群：不是"users"，而是"remote project managers juggling 3+ distributed teams"（人群定义可交给 proto-persona）。
• "Then we will" 必须是结果：不是"users will have notifications"，而是"users will respond to task assignments 50% faster"。

SKILL.md 给出的正反例对照：

• ✅ "If we add one-click Google Calendar integration for trial users, then we will increase activation rates by 20% within 30 days"
• ✅ "If we provide bulk delete functionality for power users managing 1000+ items, then we will reduce time spent on cleanup tasks by 70%"
• ❌ "If we build a dashboard, then users will use it"（模糊、不可测量）

第 3 步：设计轻量发现实验

模板第二段要求列出多条低成本、快周期的实验。SKILL.md 推荐五种实验类型：

• 原型 + 用户测试：用可点击原型伪装功能，找 5–10 名用户测试；
• 礼宾测试（Concierge test）：人工为少数用户手动执行该功能，观察他们是否觉得有价值；
• 着陆页测试：只描述功能，测量注册或兴趣信号；
• 幕后操纵测试（Wizard of Oz）：对外表现自动化，后台仍由人工完成；
• A/B 测试（条件允许时）：轻量版本与对照组对比。

三条质量检查：快（几天到几周而非数月）、便宜（用原型/人工流程/现有工具，避免完整工程构建）、可证伪（实验要能证明你错）。例如："Create a Figma prototype of the bulk delete flow and test with 5 power users"、"Manually send Slack notifications to 10 trial users and track response time"。

第 4 步：定义验证指标

模板第三段要求给出时间窗与可观察结果。质量检查包括：时间窗要现实（"within 6 months" 太慢、"within 3 days" 太快）、量化指标要具体（不是"more users"而是"20% increase in activation rate"）、质性指标要可观察（不是"users like it"而是"8 out of 10 users say they'd pay for this feature"）。推荐 2–4 周的验证周期；若周期内无法直接测量，改用领先指标（如激活率，而非年度收入）。

第 5 步：运行实验并评估

执行实验、比对验证指标，然后进入决策点：假设成立（✅）则继续拆用户故事并入路线图；假设不成立（❌）则杀掉 epic 或转向另一条假设；结果不明确（⚠️）则补充实验或收紧指标。

第 6 步：验证通过后转为用户故事

### Epic: [Epic Name] **Stories:** 1. [User Story 1 - reference `skills/user-story/SKILL.md`] 2. [User Story 2] 3. [User Story 3]

这与 user-story 技能形成闭环：epic 拆解为用户故事，而 user-story-splitting 负责把大故事继续切小。

实战示例：好假设、坏假设与"被杀死的好下注"

examples/sample.md 提供了三组完整示例，可直接对照模板理解。

示例 1：好的 epic 假设（Google Calendar 集成）

### Epic Hypothesis: Google Calendar Integration for Trial Users #### If/Then Hypothesis **If we** provide one-click Google Calendar integration during onboarding **for** trial users who manage multiple meetings and tasks daily **Then we will** increase activation rate (defined as completing setup + creating first task) from 40% to 50% #### Tiny Acts of Discovery Experiments **We will test our assumption by:** 1. Creating a clickable Figma prototype of the integration flow and testing with 10 trial users 2. Adding a "Connect Google Calendar" CTA to the onboarding flow (but it's non-functional) and measuring click-through rate 3. Manually syncing Google Calendar for 5 trial users and surveying them after 1 week on perceived value #### Validation Measures **We know our hypothesis is valid if within 4 weeks we observe:** - Click-through rate on the CTA is > 60% (quantitative) - 8 out of 10 prototype testers say they'd use this feature regularly (qualitative) - Manually synced users report saving 10+ minutes per day on task entry (qualitative)

示例 2：坏的 epic 假设（模糊）——"Improve the dashboard / for users / make the product better"，实验写"Building the dashboard"，验证写"Users like it"。失败原因逐条被点名：行动不具体、人群不是 persona、结果不可测量、实验不是轻量测试、验证不可证伪。

示例 3：被证伪的假设（过程正确）——Slack 通知集成假设"把任务响应时间从 4 小时降到 1 小时"，2 周实验后实际只降到 3.5 小时，用户反馈"我已有太多 Slack 通知，大多数都被忽略"，结论是假设不成立，转向应用内通知或邮件摘要。这个例子的价值在于：假设被真正测试而非直接构建、实验够轻量（人工发 Slack 消息）、团队在浪费工程资源前杀掉了 epic。

工业场景扩展：硬件产品如何用同一模板

examples/sample-industrial.md 展示了模板在工业硬件（Northfield Automation 的 NFA-500 控制器）上的应用，其核心洞察是：无法对控制面板做 A/B 测试、反馈回路以季度计时，假设纪律反而更有价值——因为真实实验昂贵且缓慢，发现实验就必须便宜且物理化。该示例中"板载故障隔离"假设把基准明确标注为"未测量的 52 分钟"，并用四项轻量实验（笔记本审计、纸质面板测试、手套与光照检查、停机归因拉取）逐步验证；更值得注意的是"被杀死的好下注"案例——预测性故障告警通过 3 周、近乎零工程成本的历史数据实验发现 50 例故障中仅 9 例有前兆模式，随即杀掉 epic，避免了两个季度构建一个 80% 概率错误的特性。

五种常见陷阱与修复方法

SKILL.md 的 Common Pitfalls 部分是自查清单：

1. 假设写成功能而非结果：症状是"If we build a dashboard, then we will have a dashboard"；修复为聚焦用户结果，如"If we build a dashboard showing real-time task status, then PMs will spend 50% less time asking for status updates."
2. 跳过实验：症状是"We'll test our assumption by building the full feature"；修复为设计几天到几周的原型、礼宾测试、着陆页等轻量实验。
3. 验证指标模糊：症状是"We know it's valid if users are happy"；修复为具体可证伪的指标，如"80% of surveyed users rate the feature 4+ out of 5"或"Response time drops by 50%."
4. 时间窗不现实：症状是"within 6 months revenue increases"；修复为 2–4 周验证周期，不可直接测量时改用领先指标。
5. 把 epic 当承诺：症状是"我们已告诉 CEO 要交付，所以必须验证它"；修复为在做出承诺之前把 epic 框定为假设，并向需要确定性的干系人解释未验证构建的风险。

在技能库中的位置与使用方式

从仓库的 skills-index.yaml 可以看到，epic-hypothesis是 77 个技能之一，类型为 component、主题归入 pm-artifacts，推荐使用场景包括"领导已批准大项目但没人能说出什么能证明它错了"和"需要把 epic 框定为带真实验证方法的下注而非交付计划"，预估耗时 15–20 分钟，元数据中给出调用提示[initiative or epic idea]，典型调用示例为Frame as an epic hypothesis: adding usage-based alerts so account admins catch overages before invoice shock.

它在技能链中的位置明确：上游依赖 problem-statement（假设应对已验证的问题）、proto-persona（定义"for [persona]"段）、jobs-to-be-done（支撑"then we will"结果）；下游被 user-story 与 user-story-splitting 使用（验证后的 epic 拆成故事）。同时它还被 lean-ux-canvas（Box 6 写可测试假设）、opportunity-solution-tree（把已验证方案变成可测试 epic）、pol-probe（测试前框定假设）等技能引用，并出现在 plan-roadmap 命令（把 initiative 转为 epic-hypothesis 语句）与 CHANGELOG（"把模糊 initiative 变成带成功指标的可测试假设"）中。

使用限制与适用边界

模板并非万能。SKILL.md 明确列出不适用的场景：功能已被充分验证（需求已被证明，直接写用户故事）、琐碎小功能（避免过度设计）、实验不可行（少数情况必须在测试前投入）。同时注意模板中的时间窗、基准值与指标都需结合你所在行业校准——工业示例中"52 分钟基准"被明确定义为"尚未测量、需要实验确认"，这正是模板要求诚实排序的体现；而软件领域推荐的 2–4 周验证周期在硬件场景下通常不成立，应像工业示例那样按季度思维设计轻量发现实验。模板只定义结构与质量标准，不替你做实验设计或指标决策。

• AI 技能
• AI 插件