Product-Manager-Skills 工业场景下的 Epic Hypothesis 实战指南：以 NFA-500 故障诊断史诗为例

• AI 技能
• AI 插件

本文基于开源仓库 Product-Manager-Skills 中的 epic-hypothesis 技能及其工业示例文档 sample-industrial.md，系统拆解"把史诗（Epic）写成可证伪假设"这一方法在工业硬件产品（控制面板、产线设备）上的落地打法。读完你将掌握：如何写出 If/Then 三段式假设、如何设计"微小发现实验"（Tiny Acts of Discovery）、如何预设 Kill Criteria 在错误方向上及时止损，以及如何识别一份看起来正确、实则无法证伪的坏史诗。

为什么工业场景反而更需要假设纪律

示例文档开头给出了一个关键判断：工业环境的反馈回路以季度而非天为单位，且控制面板这类硬件无法做 A/B 测试——这两点让假设纪律的价值不降反升。因为真正的实验（装机、产线试运行）昂贵且缓慢，所以发现阶段的实验必须廉价且"物理化"：打印纸面板、秒表、笔记本盘点、车间照明下的可读性测试，都是可以用天来计量的手段。

这正是 epic-hypothesis 技能的适用前提：它是你正在验证的假设，而不是你承诺交付的功能规格（"This is not a requirements spec—it's a hypothesis you're testing"）。在工业场景下，这条边界尤其重要——一次错误的整机设计迭代成本可能是 SaaS 功能的数十倍。

方法骨架：If/Then 假设 + 微小发现实验 + 验证指标

在阅读工业示例前，先回顾该技能的核心结构（完整填空模板见 template.md）：

### If/Then Hypothesis **If we** [代表目标人物画像采取的行动或方案] **for** [目标人物画像] **Then we will** [达成可欲的结果或用户待办事项] ### Tiny Acts of Discovery Experiments **We will test our assumption by:** - [实验 1] - [实验 2] - [按需继续添加] ### Validation Measures **We know our hypothesis is valid if within** [时间窗] **we observe:** - [可量化的结果] - [可定性的结果] - [按需继续添加]

该格式源自 Tim Herbig 的 Lean UX 假设表述（见 SKILL.md 的 Key Concepts 一节），其设计意图是四条：

• 假设驱动：迫使你陈述自己相信且可能出错的东西；
• 结果导向："Then we will" 强调用户收益，而非功能产出；
• 实验优先：在完整构建之前先做轻量验证；
• 可证伪：清晰的成败标准使坏点子能在早期被枪毙，把史诗当作"赌注"而非"承诺"来管理风险。

三个工业示例正是这套骨架在"你无法 A/B 测试控制面板、反馈周期以季度计"约束下的完整演练。

示例一：一份优秀的工业史诗假设——On-Unit Fault Isolation

Northfield Automation 在 NFA-500 开发期间，将"机载故障隔离"史诗写成如下假设（原文完整保留）：

### Epic Hypothesis: On-Unit Fault Isolation for the NFA-500 #### If/Then Hypothesis **If we** display fault information down to the individual I/O slot on the controller's front panel, readable without a laptop or network connection **for** maintenance technicians diagnosing a stopped line at the panel **Then we will** reduce median time-from-stop-to-first-corrective-action from 52 minutes to under 15 minutes across pilot sites #### Tiny Acts of Discovery Experiments 1. **Notebook audit** (1 week, ~0 cost) — collect the personal fault-code notebooks technicians keep. If most techs maintain one, the information gap is real and we can see exactly which codes matter. If few do, our premise is wrong. 2. **Paper-panel test** (2 weeks) — mock the front panel on printed card at three pilot sites. Give techs a simulated fault and time how long to correct diagnosis. No hardware required. 3. **Glove-and-lighting check** (3 days) — verify legibility at panel height, in plant lighting, with work gloves on. Kills or confirms the touchscreen option before tooling. 4. **Downtime attribution pull** (2 weeks) — get three plants to split logged downtime into diagnosis versus repair. Establishes the 52-minute baseline, which we currently believe but have not measured. #### Success Metrics - **Primary:** median stop-to-first-corrective-action under 15 min at pilot sites (baseline 52) - **Secondary:** controller swaps per 100 faults drops below 10 (baseline 34) — techs stop replacing the whole unit when they can see which module failed - **Guardrail:** no increase in incorrect module replacements. Faster wrong answers are worse than slower right ones. #### Kill Criteria - If the notebook audit shows fewer than a third of techs track codes themselves, the information gap isn't what we think — stop and re-frame - If the paper-panel test doesn't beat 25 minutes, the panel UI isn't the lever; the constraint is somewhere else - If guardrail rises above baseline, stop regardless of the primary metric

这份假设为什么成立

原文档总结了五个要点，每一条都对应 SKILL.md 中的质量检查项：

• 基线被如实标注为"未测量"。"52 分钟"同时出现在假设与实验 4 中，而实验 4 的存在就是为了验证这个数字。先承认数字未经验证、再设计实验去确认它，是诚实的排序——对应 SKILL.md 的检查项"If we 要具体、Then we will 要是可度量的结果"。注意这里的"52 → 15 分钟"是一个带明确目标值和基线的可证伪声明，而示例二中的"improved"则不是。
• 实验是物理且廉价的。打印卡片加秒表，没有固件、没有工装、没有资本支出——这是硬件时间线上唯一可行的发现实验方式。对照 SKILL.md 的 Step 3：实验要"快（天/周而非月）、便宜（避免完整工程构建）、可证伪（能证明你错了）"，paper-panel test 与 notebook audit 是这三条在工业语境下的完美翻译。
• 实验 3 可以在三天内枪毙一个设计方案。手套 + 车间照明 vs 触摸屏，是一个五分钟就能回答的问题，却省下整整一轮工装周期——这是"cheap and physical"发现实验的直接收益。
• Guardrail 点明了真正的风险。"诊断更快但更常出错"是更差的产品——这正是"把故障灯做得更醒目"若被草率执行可能造成的后果。原文档用 Primary / Secondary / Guardrail 三层指标把 SKILL.md 中"验证指标要定量、可观察"的要求升级为工业场景的护栏机制。
• Kill Criteria 预先承诺。在团队爱上面板设计之前就把止损线写下来。这一条对应 SKILL.md 的核心理念"可证伪：清晰的成败标准使坏点子能在早期被枪毙"——工业场景中，发现实验周期以周计，Kill Criteria 是防止"沉没成本式"继续推进的唯一刹车。

示例二：一份失败的工业史诗假设——"Improve NFA-500 Diagnostics"

同一文档给出了反面教材（原文完整保留）：

### Epic: Improve NFA-500 Diagnostics **Goal:** Deliver best-in-class diagnostics for the NFA-500 platform to improve customer satisfaction and differentiate from competitors. **Success:** Positive customer feedback, improved NPS, competitive win rate. **Approach:** Work with engineering to scope and deliver enhanced diagnostic capabilities in H2.

它坏在哪

原文档的剖析与 SKILL.md 的 Anti-Patterns（这不是什么）一一对应：

• 这里没有任何东西可能出错。"Improve diagnostics" 不存在任何让团队停下、转向或承认前提失败的触发条件——这就是不可测试史诗的定义。对照 SKILL.md："Ship feature X by Q2" 这种输出导向表述错失了重点——它达成结果了吗？
• 没有用户。技术员、控制工程师、运营经理需要完全不同的诊断能力，史诗不指明是哪一个，工程团队就会自己挑——通常是最好实现的那个。这直接对应 SKILL.md 的质量检查"If we 要具体、For 要是清晰的人物画像（可参考 proto-persona 技能）"。
• "Positive customer feedback" 与 "improved NPS" 落后了数个季度，并且会被发布包里的其他一切因素混淆，二者都无法在构建途中指导任何决策。这与 SKILL.md 的 Pitfall 4 一致：验证周期若长达数月，等你测出来时东西已经建完了。
• 没有基线，于是事后连"improved"都无法度量。
• "Best-in-class" 邀请的是无上限的范围。对比"under 15 minutes"——后者精确告诉你何时停止构建。这是 SKILL.md 的 Pitfall 1（假设是特性而非结果）在工业措辞上的变体。

示例三：一份被枪毙的好假设——Predictive Failure Alerts

原文档特意展示了"被枪毙的史诗"：这恰恰是纪律兑现的时刻。

### Epic Hypothesis: Predictive Failure Alerts **If we** analyze I/O signal patterns to predict module failures before they occur **for** plant operations managers planning maintenance windows **Then we will** convert at least 30% of unplanned line stops into planned maintenance at pilot sites #### Tiny Acts of Discovery Experiments 1. **Historical data pull** (3 weeks) — collect signal logs preceding 50 known module failures. Do failures show a detectable precursor pattern at all? 2. **Blind classification** (1 week) — have an engineer attempt to identify pre-failure windows from logs without knowing the outcomes. #### Kill Criteria - If fewer than half of failures show any precursor signal, prediction isn't feasible with the data we have — stop.

结果：实验 1 在 50 次故障中仅发现 9 次存在前兆模式，史诗在约三周、近乎零工程成本的情况下被枪毙。

为什么这是成功：替代方案是一次两个季度的构建，落地在一个 80% 时间里都会判断错误的特性上——而在"你的产线即将停机"这类场景中，一次错误的预警比没有预警更快摧毁信任。假设格式让廉价测试变得显而易见，也让枪毙决定毫无争议。

这对应 SKILL.md 的 Step 5 决策点中的"❌ 假设被证伪：枪毙史诗或转向另一个假设"——注意它是与"✅ 假设被验证：继续构建用户故事并加入路线图"并列的正当结果，而非失败。工业示例用"9/50"这个具体数字证明：好的假设必须包含失败的可能性，而证明失败本身就是成功。

工业示例与 SaaS 示例的对照：方法一致，实验形态不同

仓库同时提供了通用示例 examples/sample.md（Google Calendar 集成、Slack 通知等 SaaS 场景）与本文的工业示例。两者共享同一套 If/Then 骨架，差异集中在"微小发现实验"的形态上：

工业示例还引入了 SaaS 示例中不存在的Guardrail（护栏指标）与Kill Criteria（止损线）两个结构要素——因为硬件场景下"方向错了再回头"的代价是工装周期与资本支出，必须在出发前写清刹车条件。若要在自己的工业项目中使用，可直接从 template.md 起步，并参照本示例补上 Primary / Secondary / Guardrail 三层指标与显式 Kill Criteria。

在仓库中的定位：从"一句话想法"到路线图的第一步

epic-hypothesis 在仓库中被归类为component型技能（见 catalog/skills-index.yaml），描述为"以可测试假设的形式框定史诗，含目标用户、预期结果与验证方法；在路线图、发现或交付规划之前定义重大举措时使用"。它的上下游链条清晰：

• 上游依赖：problem-statement 技能（假设应对已验证的问题）、proto-persona 技能（定义"For [画像]"）、jobs-to-be-done 技能（支撑"Then we will"的结果）；
• 下游出口：user-story 技能 与 user-story-splitting 技能——假设被验证后，史诗拆解为用户故事（SKILL.md 的 Step 6）。

在实操工作流中，/plan-roadmap命令将本技能置于明确的位置（见 commands/plan-roadmap.md）：第 1 步用roadmap-planning构建路线图上下文，第 2 步把举措转换为epic-hypothesis声明，随后才进入优先级排序与交付切片。也就是说，本文工业示例中的三份假设产物，正是路线图规划环节的标准化中间产物——它把"领导批准了重大项目但没人说得清什么能证明它错了"这种场景（SKILL.md 的 scenarios）转化为可执行的赌注。

可复用的检查清单

综合工业示例的成败案例与 SKILL.md 的 Common Pitfalls 一节，在提交一份史诗假设前逐条核对：

1. If we 具体到动作：不是"improve diagnostics"，而是"在控制器前面板把故障信息下钻到单个 I/O 槽位，无需笔记本或网络即可读取"。
2. For 是单一清晰画像：不是"users"，而是"在面板前诊断停机产线的维护技术员"。
3. Then we will 是可测结果：带基线（52 分钟）与目标值（15 分钟），而不是"improved NPS"。
4. 基线标注测量状态：数字若尚未实测，须有配套实验去确认（实验 4 的 downtime attribution pull）。
5. 实验满足快/便宜/可证伪：打印卡 + 秒表；绝不允许"实验 = 构建完整功能"。
6. Guardrail 覆盖真实风险：速度提升不得以正确率下降为代价；预警类功能须把"假阳性破坏信任"显式列为护栏。
7. Kill Criteria 预先写下：在团队爱上方案之前完成；触发即停，无论主指标表现如何。
8. 验证时间窗现实：2-4 周为佳（SKILL.md Pitfall 4）；若该周期内无法度量，改用领先指标。

对照 示例二 可见，违反上述任何一条，史诗就会退回"输出导向的交付计划"；对照 示例三，全部满足则即便被证伪，团队也能在三周内以近乎零成本全身而退——这正是假设纪律在工业时间线上的最大价值。

• AI 技能
• AI 插件