epic-hypothesis

epic-hypothesis 概览

epic-hypothesis 的作用

epic-hypothesis skill 可以帮你把一个宽泛的 epic 转成可验证的 hypothesis，而不是一句模糊的交付表述。它适合在进入 roadmap 承诺、调研或开发之前，先把 initiative 定义清楚：它帮助谁、会带来什么变化，以及你将如何判断它是否有效。

最适合谁使用

这个 epic-hypothesis skill 很适合产品经理、技术写作者、设计负责人，以及需要更清晰地界定 initiative 的跨职能团队。它尤其适合 epic-hypothesis for Technical Writing，因为它能给写作者提供一个具体结构，把混乱的业务意图转成可读、可决策的产物。

它的不同之处

它的核心价值不在于措辞模板本身，而在于它强制建立的思考纪律：目标人群、预期结果和验证方案。相比普通 prompt，epic-hypothesis 更适合用来辅助决策，因为它会在任何人开始写需求之前，就把假设和成功标准摊开。

如何使用 epic-hypothesis skill

安装并打开源文件

使用仓库路径 deanpeters/Product-Manager-Skills，通过你的 skill manager 安装 epic-hypothesis skill，或者直接读取 skills/epic-hypothesis。先打开 SKILL.md，再看 template.md 和 examples/sample.md，这样你能看到完整的 hypothesis 模式，以及什么算“好”、什么算“不好”。

给 skill 一个真实的 epic，而不是一个主题

要获得更好的 epic-hypothesis usage，输入时请提供一个粗略但有上下文的 initiative，至少能识别用户、问题和预期变化。高质量输入通常会提到 persona、业务目标、约束条件，以及成功的样子。

示例提示词结构：
Use epic-hypothesis to frame an epic for trial users who churn after onboarding. The initiative is a calendar integration. We need a hypothesis, 2-3 discovery experiments, and measurable validation criteria.

弱输入：
Write an epic hypothesis for dashboards.

按照仓库工作流来走

epic-hypothesis guide 的结构分成三部分：If/Then Hypothesis、Tiny Acts of Discovery Experiments 和 Validation Measures。起草时就按这个顺序来。如果你的团队已经有产品语言，不要推倒重写，而是把现有内容翻译进这个模板；这个 skill 最擅长的，就是把已有思考转成可测试的形式。

提升输出质量的技巧

把受众写得足够具体，避免空泛的“无方案”表达，并加入一个有时间边界的验证窗口。如果你还不知道指标，可以让 skill 帮你提议一个，但要先给出业务背景，这样指标才有相关性。用于 Technical Writing 流程时，最好要求输出足够简洁，能直接放进 planning docs 和 review notes，而不只是 strategy decks。

epic-hypothesis skill 常见问题

epic-hypothesis 只适合产品经理吗？

不是。只要团队在正式投入工作前需要减少歧义，epic-hypothesis skill 都很有用。技术写作者可以用它来框定与文档相关的 initiative，交付团队也可以用它在实施前先对齐结果。

它和普通 prompt 有什么不同？

普通 prompt 可能只会生成一段好看的文字，但 epic-hypothesis 会给你一个可复用的决策结构。当你需要的是可追踪的假设、明确的实验和可衡量的验证，而不是一次性的头脑风暴时，这个 skill 更有价值。

什么情况下不该用它？

当工作已经非常明确、范围已经固定，或者你只需要一个简单的状态更新时，就不要用 epic-hypothesis。它最有价值的场景，是不确定性很高、你需要判断一个 epic 值不值得推进的时候。

新手能直接上手吗？

可以，只要你能用朴素语言把 initiative 说清楚。这个模板本身并不复杂，但质量取决于你把目标用户、结果和验证方式定义得有多清楚。如果这些信息本身就模糊，第一版输出也会很模糊。

如何改进 epic-hypothesis skill

先把输入写得更锋利

提升 epic-hypothesis 结果最快的方法，是提供一个具体 persona、一个明确痛点，以及一个最小可衡量结果，用来证明价值。比如，“在第 2 步就放弃设置的新管理员”要比“使用有困难的用户”好得多。

注意常见失败模式

最常见的错误，是把 feature spec 包装成 hypothesis。另一个常见问题，是验证指标过于宽泛，比如“用户喜欢它”。好的 epic-hypothesis 输出应该让人一眼看出：什么证据会让你改变想法。

在第一版之后继续迭代

第一轮输出后，继续通过收紧受众、用更贴近业务的结果替换泛化结果、降低实验成本来打磨 hypothesis。如果输出显得抽象，可以让 skill 改写成 epic-hypothesis for Technical Writing 的风格，或者把验证标准改得更具体、更加可观察。