史诗假设框架技能：把"想做的大功能"变成 2 周内可验证的 If/Then 假设
- 一句话定位：它不是需求规格书，而是一个用 If/Then 结构把"史诗级功能"改写成可测试假设的组件型技能，帮你在投入研发之前先验证想法靠不靠谱。
- 核心结构：If/Then 假设 + 微小发现行为实验 + 验证指标，三段式强制你把"信念"写出来、把"实验"设计出来、把"成功标准"量化出来。
- 关键价值：让团队在全面构建前用几天到几周的低成本实验证伪坏想法，把"史诗"当作赌注而非承诺来管理。
- 适合谁用：产品经理、产品负责人、创业团队、需要向利益相关者解释"为什么要先验证"的一线研发与设计同学。
- 上手难度：低。技能本身提供模板与质量检查清单，难的不是工具，而是诚实面对假设可能被推翻。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 史诗假设框架技能（Skill） |
| 技能英文名 | epic-hypothesis |
| 技能ID | 11373 |
| 技能类型 | 组件（Component） |
| 建议放置位置 | /skills/components/ 目录下，文件名为 epic-hypothesis.md |
| 技能依赖 | 参考 problem-statement、proto-persona、jobs-to-be-done 三个前置技能 |
| 使用方 | 被 user-story、user-story-splitting 等下游技能调用 |
它到底解决什么问题？
产品团队最常见的失误，不是"做得不好"，而是"做了不该做的东西"。一份写得很漂亮的功能需求文档，本质是在说"我们要交付这些功能"，却很少有人回答：这个功能假设了什么？如果假设错了会怎样？多久能知道错了？
史诗假设框架技能就是来补这一环的。它把一句"我们下个季度要做批量删除功能"，强制翻译成：
如果我们 为管理 1000 个以上项目的重度用户提供批量删除功能，那么我们将 把他们的清理时间减少 70%。
翻译完成之后，你手上拿到的不再是一个待排期的功能，而是一个带有实验设计和成功标准的假设——可以被验证，也可以被淘汰。
一键安装思路与步骤
- 确认安装前提：你的 AI 助手需要支持"技能（Skill）"机制，也就是可以把一组结构化的提示词与方法论作为可复用组件加载。同时确认本地或云端已有
/skills/components/这类技能目录结构。 - 定位技能入口：在技能市场、技能库或技能管理面板中，使用技能名称「史诗假设框架」或技能英文名
epic-hypothesis检索（具体检索入口与安装方式以官方说明为准）。 - 执行安装：按官方提供的安装方式把技能加载到技能目录中，建议文件命名为
epic-hypothesis.md，放置在/skills/components/下，便于其他技能引用。 - 补全依赖技能：该技能依赖
problem-statement（问题陈述）、proto-persona（原型用户角色）、jobs-to-be-done（待完成任务）三个前置技能。安装时建议一并准备，否则起草假设时会缺少上下文。 - 验证是否生效：对话中直接说"帮我把这个功能想法写成史诗假设"，观察输出是否包含 If/Then 假设、微小发现行为实验、验证指标三个部分，并可要求它引用
template.md模板结构。能稳定产出三段式结构，即说明技能已生效。
如果你不想单独安装，也可以直接把它当作一套方法论手工使用——本文后面的模板与检查清单，就是它的核心内容。
该技能的主要功能和特点
- If/Then 假设生成：把"行动或解决方案 → 目标用户角色 → 期望成果"三要素结构化，强制区分"输出"与"成果"。技能内置质量检查，会拦截"如果我们构建仪表板，那么用户将使用它"这类模糊且不可衡量的表述。
- 微小发现行为实验设计：提供原型测试、管家测试（Concierge Test）、落地页测试、绿野仙踪测试（Wizard of Oz）、A/B 测试等多种低成本实验类型，并附带"快速、廉价、可证伪"三条检查标准。
- 验证指标定义：要求同时给出时间窗（通常 2—4 周）与定量、定性两类可衡量成果，例如"激活率从 40% 提升到 50%"+“10 名用户中有 8 名表示愿意为该功能付费”。
- 反模式校验：技能明确列出"这不是什么"——不是功能规格书、不是承诺、不是输出导向、不是无实验直接构建。AI 在生成时会主动指出你写的到底是假设还是伪装成假设的功能清单。
- 使用边界判断：内置"何时使用 / 何时不使用"的判别逻辑。已验证需求、微小功能、实验不可行的场景会被建议跳过，避免方法论过度工程化。
- 验证后转用户故事：假设一旦被验证，技能可以把史诗拆解为用户故事，衔接下游的
user-story与user-story-splitting技能，形成"假设 → 验证 → 交付"的完整链路。 - 理论溯源清晰：结构受 Tim Herbig 的 Lean UX 假设声明启发，并关联《Lean UX》《Pretotype It》《精益创业》等外部框架，方便你在团队内解释方法论出处。
和普通工具比强在哪？ 普通的需求模板让你"写得更完整"，而这个技能让你"写得更可证伪"。同样一段输入，普通 AI 会帮你补全 PRD 章节，它会反问你：这个假设如果错了，你打算多久、用什么数据发现它错了？
如何使用该技能？
下面按技能内置的六步流程展开，每一步都给出可直接参考的输入输出。
步骤 1：收集上下文
在起草假设前，先备齐四件事：用户问题是什么、目标用户角色是谁、他们想完成什么任务、他们今天用什么替代方案（竞品、变通办法或干脆什么都不做）。对应可参考 problem-statement、proto-persona、jobs-to-be-done 三个前置技能。上下文缺失时，先做发现访谈或问题验证，不要急着写假设。
步骤 2：起草 If/Then 假设
按模板填写：
如果我们〔代表目标用户角色的具体行动或解决方案〕 为〔清晰的目标用户角色〕 那么我们将〔为用户实现的期望成果或待完成任务〕
质量检查三连问：
- “如果我们"是否具体？不是"改进产品”，而是"在任务被分配时增加一键 Slack 通知"。
- “为"是否是清晰角色？不是"用户”，而是"管理 3 个以上分布式团队的远程项目经理"。
- “那么我们将"是否是成果？不是"用户将收到通知”，而是"用户响应任务分配的速度提升 50%"。
步骤 3：设计微小发现行为实验
写出 1—3 个轻量实验，例如"制作批量删除流程的 Figma 原型，与 5 名重度用户测试"、“手动给 10 名试用用户发送 Slack 通知并记录响应时间”、“在界面上增加’我想要这个功能’按钮并统计点击率”。判断标准只有三条：几天或几周内能跑完、不需要完整工程投入、实验设计有可能证明你错了。
步骤 4：定义验证指标
写明"我们知道假设有效，如果在〔时间窗〕内观察到：〔定量指标〕+〔定性指标〕“。时间窗建议 2—4 周；定量指标要具体到百分比或时长；定性指标要可观察，比如"10 名用户中有 8 名表示愿意付费”。
步骤 5：运行实验并评估
执行实验、收集数据、对照指标，然后进入三选一的决策点：
- ✅ 假设验证 → 进入用户故事拆解并纳入路线图；
- ❌ 假设无效 → 淘汰该史诗，或转向另一个假设；
- ⚠️ 无定论 → 追加实验或收紧验证指标。
步骤 6：转换为用户故事
验证通过后，把史诗拆成 3—5 条用户故事，交给 user-story 技能继续细化，或用 user-story-splitting 处理拆分问题。
一次完整调用的示例
你：帮我为"项目管理工具里的批量删除功能"写一个史诗假设。 技能：先确认目标角色——是普通用户还是管理上千项目的重度用户？他们今天的替代方案是什么？ 你：重度用户，目前靠逐个删除或写脚本。 技能：输出 If/Then 假设、2 个实验（Figma 原型测试 + 手动代操作管家测试）、2—4 周内的定量与定性指标，并附上质量检查结论与潜在反模式提示。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 史诗假设框架技能（epic-hypothesis） | 组件型 AI 技能，把史诗改写成可测试假设 | If/Then 假设、微小发现实验、验证指标、反模式校验、转用户故事 | 低，需支持技能机制的 AI 助手并具备相关目录；具体安装以官方说明为准 | 早期功能探索、新能力市场验证、积压工作排序 | 优势：结构化强、内置质量检查、可证伪；不足：依赖前置上下文技能，缺少可视化协作界面 |
| 传统 PRD / 需求规格说明书 | 交付导向的文档规范 | 功能描述、交互说明、验收标准 | 低，但写好需要经验 | 需求已明确、进入研发交付阶段 | 优势：团队熟悉、便于验收；不足：默认需求为真，不包含假设与证伪机制，容易"做完才发现没人用" |
| Lean UX 假设画布（人工填写模板） | 方法论模板 | If/Then 假设、成果指标 | 中，需要团队培训与引导 | 工作坊、跨职能对齐 | 优势：可视化、适合集体讨论；不足：全靠人工判断质量，缺少即时反馈与反模式拦截 |
| 通用 A/B 测试或实验平台 | 数据侧实验工具 | 分流实验、显著性检验、指标看板 | 中高，需要埋点与流量 | 已有一定用户量、可做线上分流的功能 | 优势：数据严谨；不足：只解决"怎么测"，不解决"该测什么假设"，且早期想法往往没有足够流量 |
怎么选？ 如果你连"要验证什么"都还没想清楚，先用史诗假设框架技能把问题定义清楚；如果你已经有一个明确的线上分流实验需求，直接用实验平台更高效。两者是上下游关系，不是替代关系。
该技能的典型应用场景与实际体验情况
场景一：产品经理面对一个"看起来很大"的新功能
痛点：老板说"我们要做一个数据看板"，但没人说得清做出来要解决什么问题，排期一拖再拖。使用方式：让技能把"做看板"改写成"如果我们为项目经理提供实时任务状态看板，那么他们将减少 50% 的状态问询时间"，再配一个"手动每周发状态汇总邮件"的管家测试。实际体验：改写过程往往在第 3 分钟就暴露"其实我们并不知道用户现在怎么获取状态"这个真问题，比排期评审更有价值。注意事项：如果团队已经把这个功能对外承诺，需要先处理承诺问题，否则实验会变成走过场。
场景二：创业团队验证新能力的市场契合度
痛点：资源有限，任何一个大功能做错都伤筋动骨。使用方式：用落地页测试或"请求此功能"按钮，先测兴趣再投入研发。实际体验：这类轻量实验通常 1—2 周能出结论，对早期团队性价比极高。注意事项：定性样本小，结论要明确写清"这是信号，不是定论"，避免把 8 个人的反馈当成市场结论。
场景三：产品负责人做积压工作排序
痛点：需求池里几十个史诗，全靠拍脑袋排优先级。使用方式：对每个候选史诗写出假设与验证状态，已验证的优先，未验证的先安排实验，被证伪的直接淘汰。实际体验：排序讨论从"我觉得这个重要"变成"这个假设有数据支撑吗"，会议时长明显缩短。注意事项：初版假设容易写得过于笼统，需要反复用技能的检查清单自检。
场景四：向利益相关者管理期望
痛点：一旦对外说"我们要交付 X"，团队就被绑住，明知方向不对也只能硬着头皮做。使用方式：把史诗框架化为实验，向管理层说明"我们在 4 周内验证 X 是否有价值，届时决定是否全面构建"。实际体验：这是该技能最被低估的用法——它改变的是沟通语言，而不只是文档格式。注意事项：需要提前与管理层对齐"假设可能被证伪"这件事，否则会被理解为"团队不敢承诺"。
整体上手难度：低。技能自带模板、示例与质量检查，第一次使用就能产出结构完整的假设。真正的门槛在组织文化——是否允许一个被认真写出的假设，最后被判定为无效并体面地终止。
该技能能为用户带来的价值
- 把决策提前：从"做完再验证"变成"验证后再做"，把最贵的成本（完整研发投入）放到最后一步。按照技能建议的 2—4 周验证周期，一个错误方向最多消耗几周，而不是一个季度。
- 降低沟通成本：If/Then 结构天然适合在会上念出来，一句话就能让所有人对齐"我们在赌什么、赌赢了长什么样"。
- 提升需求质量：内置的质量检查与反模式清单，能系统性拦截"输出导向"“指标模糊”“跳过实验”"时间窗不现实"五类高频陷阱。
- 建立可复用的资产：每个被验证或证伪的假设都是组织记忆。半年后回看，你能知道当初为什么做、为什么不做，而不是只留下一堆已完成的工单。
- 衔接完整链路：向上对接问题陈述、用户角色、待完成任务，向下对接用户故事与故事拆分，让方法论不是孤立的模板，而是可执行的工作流。
- 降低方法门槛：Lean UX 假设方法本身不复杂，难在坚持。把它做成技能后，团队不需要专门培训就能产出达标的假设文档。
常见问题 FAQ
Q1：这个技能怎么安装？需要什么前提？
A：需要在支持技能机制的 AI 助手中安装，建议文件命名为 epic-hypothesis.md 并放入 /skills/components/ 目录，同时准备 problem-statement、proto-persona、jobs-to-be-done 三个前置技能。具体安装入口、命令与操作步骤以官方说明为准。安装后可用"帮我把这个功能写成史诗假设"来验证是否生效。
Q2：使用这个技能收费吗？
A：技能详情中未涉及定价信息。是否收费取决于你使用的 AI 助手平台与技能分发渠道，请以官方说明为准。
Q3：它和写 PRD 有什么区别？我是不是还得再写一份需求文档？
A：定位不同。PRD 回答"要做成什么样"，史诗假设回答"值不值得做、怎么证明"。推荐顺序是先写假设、跑实验，验证通过后再拆用户故事并进入正常的需求与研发流程。已验证的功能不需要再走假设流程，技能本身也明确建议跳过。
Q4：什么样的团队不适合用？
A：三类情况建议谨慎：需求已被充分验证、只需直接拆用户故事的功能；改动极小的微调；以及实验确实不可行的少数场景（此时只能在测试前先承诺）。技能内置了"何时不使用"的判断，避免方法论过度工程化。
Q5：如果假设被证伪了，前面的工作是不是白做了？
A：恰恰相反。技能把史诗定义为"正在测试的假设，而不是承诺交付的功能"，证伪意味你用几周时间避免了一个季度的无效投入，这是正向收益。真正的风险是"无论实验结果如何都要构建"——技能把这种情况列为反模式并明确提示。