pm-assumption-testing

假设测试技能

此技能的工作方式（请先阅读）

这是一项生成式技能，而“验证我们的想法”是一个常见的默认陷阱。人们本能地会直接跳到某种方法——构建 MVP、开展问卷调查、发布 A/B 测试——或者测试想法本身（“你喜欢这个吗？”，每个人都会说喜欢），而不是测试这个想法所依赖的假设。另一个问题是投入与问题不匹配：为一个一天的测试就能解决的问题编写代码，或者凭一次走廊问询就押上整个季度。因此，这项技能设置了以下关卡：

1. 明确决策及其利害关系——这会影响什么选择？该选择有多容易撤回、成本有多高？这决定了需要多严谨。
2. 应用始终适用的核心原则——分解出可测试的假设，优先处理风险最高的假设，以可证伪的方式表述，并预先设定成功标准。
3. 审慎选择方法——明确呈现测试保真度与方法的选择及其权衡；不要默认选择“先做出来再看”。

接着，它会将计划交给 pm-assumption-rigor-audit 进行验证（并交给 pm-okr-metric-validity-audit 验证成功指标）。对每个假设都应用所有测试类型，是一种失败做法——应为每个高风险判断匹配一种合适的方法。

---

步骤 0 — 规划测试前明确背景

如果信息未知，请提问；如果没有答案仍要继续，请说明所采用的假设：

• 这会影响什么决策？该决策有多容易撤回？ 低成本、可撤回的小改动，适合快速、低保真的检查；成本高、难以撤回的押注，则需要更有力的证据。严谨程度应与利害关系相称——对无关紧要的决定测试过度，与对重大决策测试不足一样不妥。
• 我们处于哪个阶段？ 测试问题（有人在意吗？），还是测试解决方案（用户能否使用或参与？），还是测试可行性／规模化（用户会付费吗？它能经受住考验吗？）。每个阶段对应不同层级的方法。
• 最关键的信念是什么？ 哪个假设一旦不成立，就会让整个想法失败？先明确它。
• 资源与时间安排——现在现实可行的测试有哪些？能回答问题的最便宜方法，就是最佳选择。

---

始终适用的核心原则（适用于任何假设测试）

• 测试假设，而非想法。 将想法拆解为成功所必需的信念。“你喜欢这个概念吗？”通常会得到礼貌的肯定；“用户愿意为精选餐食支付溢价”则是一个可以实际验证的信念。
• 涵盖五种假设类型；找出哪些存在风险。 需求性（他们想要吗？）、可行性（对业务有利吗？）、技术可行性（我们能构建出来吗？）、易用性（他们会用吗？）、伦理性（可能造成伤害吗？）。通过故事地图、机会—解决方案树或理想客户画像来生成假设。
• 按重要性 × 确定性排序——先测试风险最高的假设。 将假设绘制在网格上；重要性高、确定性低的假设风险最大。先测试这些，再处理那些让人安心的假设。（一种实用的替代排序方式：优先测试影响大 且 易于验证的假设，以快速取得成果。）
• 将每个假设表述为可证伪的假说。 使用 “我们相信，为 [用户] 带来 [变化] 会产生 [结果]；当 [指标] 变化 [幅度] 时，我们就知道判断正确。” 采用正向表述（用户 会 做什么），并且具体明确——这样能明确真正的失败条件，并避免确认偏误。
• 在测试前定义成功标准。 事先与团队商定通过／失败的阈值，避免事后重新解读结果。
• 从能回答问题的最低成本方法开始。 原型能解决问题时，就不要写代码；文字描述能解决问题时，就不要做原型。根据所需的确定性来匹配投入。
• 询问过去的行为，而非假设性的意图。 “说说你上次遇到这种情况时是怎么处理的”，胜过“你会用这个吗？”。口头表达的意愿可能产生假阳性；实际行动（点击、注册、预购、购买）才是有效信号。
• 做好判断错误的准备。 把每次测试都视为学习；假设不成立时，要有备用方案。证伪也是一种胜利——它能避免错误地投入构建。
• 记录并决定下一步。 记录假设、方法、预设标准、结果和所学内容 → 确认、调整或转向。尽早并且持续测试，不要把测试当作一个会逐渐过时的一次性阶段。

---

因情境而定的决策（呈现出来，不要自动套用）

根据你需要了解的内容和决策利害，为每个高风险假设匹配一种方法。不要对每个假设都跑一遍所有测试。

决策	适用时机	避免／调整的情况	默认建议
低保真：问卷、访谈、纸面原型	测试问题／需求意愿——有人在意吗？适用于最早期、成本最低的阶段	把“你会不会？”这类口头意愿当作需求证明	从这里开始；访谈时结合 Mom Test（关注过去的行为，而非假设性问题）
引流页／落地页／烟雾测试	在构建之前，用行为信号（点击、注册）衡量真实需求	把点击当作功能满足需求或能留住用户的证明	用来决定是否构建；高 CTR 只能验证兴趣
中保真：可点击模型、礼宾式 MVP、绿野仙踪法	测试解决方案——用户能否理解／参与；在自动化之前手动交付价值	花数周打磨原型，而草图就能回答问题	在编写代码之前，用它验证价值主张
高保真：A/B 测试、功能标记、公开测试版	优化或扩展已验证的想法；验证可行性和真实条件下的行为	用它来发现是否有人需要这个东西（成本太高、时机太晚）	需求验证后再使用；需要足够的样本量／测试时长。若要保证 A/B 测试的统计严谨性（样本量、显著性、护栏指标、窥视数据），请交由 pm-experimentation-ab 处理
定性与定量	定性（访谈、开放式回答）用于了解原因；定量（分析、大样本问卷、A/B 测试）用于了解结果	只依赖其中一种——纯定量无法揭示原因，纯定性则容易追着声音最大的人跑	交叉核对两者；结果一致＝绿灯，结果冲突＝再做一次测试
样本量／时长／显著性	根据结论的范围调整——可用性问题约需 5 名用户；转化率／偏好则需要更多用户和足够的运行时间	根据 n=10 或一天的数据窗口做泛化；在 A/B 测试中忽略显著性	让测试规模与决策相匹配；对于可逆的决策，不要过度设计

---

验证结果（编排）

交接时用各个审查视角所对应的可安装技能 name。只有安装了该技能时才调用；若未安装，本技能的核心已涵盖这些规则——继续执行，不要因此受阻。

产出或修订后，应交由审计视角审查，而不是直接宣告完成。这些都是候选视角——按照 docs/orchestration-policy.md 中的要求处理，或将整个产物交由 pm-product-review 审查。这里的 assumption-rigor 是始终适用的视角（自动运行）；其他视角则是可选的，取决于产物实际包含的内容。如果用户调用此技能是为了处理某个特定事项，请尊重这一范围。

• pm-assumption-rigor-audit（自动运行）——核心检查：是否针对了风险最高的假设，是否将其表述为可证伪的命题，是否匹配了保真度恰当的方法，是否预先设定了成功标准，以及是否如实解读了证据（样本、时长、模式与轶事）？
• pm-okr-metric-validity-audit（可选——若假设中提到了成功指标）——检查每个假设中的成功指标：它是否代表真实结果、可证伪，且不是虚荣指标或可被操纵的数字？

**组合方式（依据 docs/orchestration-policy.md §9）：**此技能产出测试计划；广泛的探索方法（pm-discovery）是上游输入，而规格假设（pm-product-spec）是负责该子部分的同级技能（交由其处理）。如果审计发现冲突（例如，低成本方法实际上无法回答高风险问题），应根据当前决策来解决：**只为决策所需的确定性买单——不多不少。**若要从想法到计划完整构建，pm-idea-to-plan 是组合流程的入口，它会将此测试安排在规格编写之前，并将其明确作为构建门槛，而不是埋在 PRD 中。

---

常见的正确与错误做法

❌ 错误做法	✅ 正确做法
通过询问人们是否喜欢来“验证想法”	将想法拆解为多个信念；测试想法所依赖的假设
测试容易或让人感到舒适的假设	按重要性 × 确定性进行梳理；优先测试风险最高的假设（重要性高、确定性低）
“用户会喜欢它”	“我们相信，[变更]会为[用户]带来[结果]；具体体现在[指标]恰好变化[幅度]时”
将其表述为用户不会做什么	用正向方式表述——用户会做什么更容易测试
看过结果后再决定成功与否	在开展测试前设定通过/失败阈值
编写代码来确认是否有人需要它	先采用成本最低的方法——先做引导页面 / 原型，再进行开发
在访谈中问“你愿意为此付费吗？”	询问过往行为；衡量真实行动
只做一次测试，然后继续下一步	尽早并持续测试；做好记录并重新测试
将被证伪的假设视为可以忽略的挫折	做好判断错误的准备；让测试结果影响决策
将计划作为最终方案交付	移交给 assumption-rigor + okr-metric-validity

---

参考课程（Uxcel）

• 假设测试
• 假设测试最佳实践
• 基于证据的产品探索
• 将问题转化为假设