pm-assumption-rigor-audit

假设严谨性审计技能

此技能与默认行为的区别

默认情况下，Claude 会直接接受验证结果——“我们做了调查，用户很喜欢，所以这已经得到验证了”这种说法通常不会受到质疑。它很少会追问：测试的是否是风险最高的假设；方法是否足以支撑它要支持的决策；是否把“你会用这个吗？”的回答误当成了证据；是否在测试之前就定义了成功；或者样本量是否足以说明任何问题。此审计会强制做到四点：每项发现都指出被违反的原则；以测试要支持的决策作为判断单位（严谨程度与风险相匹配）；检验证据主张中的信号与噪声；并按决策损害程度评定发现的严重性，同时给出具体的改进方案。

这是一项评估型技能：每当有人审查验证计划、实验、探索方法或“我们已经验证了……”这类主张时，它都会自动运行；在 pm-assumption-testing 生成测试计划后，它也会作为验证步骤运行。

范围约束。 直接调用时（用户明确要求进行此审计），只审查这一项关注点，不要引入相关的其他审计。只有在 pm-product-review 编排器或生成型技能依据 docs/orchestration-policy.md 调用它时，它才会与其他视角一同运行；在这种情况下，它属于始终相关的 PM 视角——自动运行。明确指定的范围始终优先。

---

框架——检查内容与违规情形

1. 测试的是风险最高的假设，而不是容易下手的假设

应按重要性 × 确定性对假设进行梳理；高重要性／低确定性的假设（即需要飞跃相信的判断）风险最高，应优先测试。不加区分地测试所有假设，或只测试容易测试的内容，都是徒劳。

以下情况应标记： 从未提出或测试关键假设（“用户愿意为此付费”“这确实是个问题”），却先测试了容易或安全的假设；声称“我们要测试所有内容”，却没有优先级排序；测试了想法，却没有测试这个想法所依赖的信念。

• ❌ 开发一款送餐应用，却只调查“你喜欢健康餐吗？”（每个人都会说喜欢），从未测试“用户愿意支付溢价吗？”或“用户会选择搭配好的套餐，而不是单点吗？”
• ✅ 梳理各项假设；优先测试重要性最高、确定性最低的假设（“用户愿意为搭配好的健康餐多付 20%”）。

2. 将假设表述为可证伪的具体陈述

可测试的假设应采用以下假设格式——“我们相信，[针对某类用户的某项改变]会带来[某种结果]；当[某项指标]变化[某个幅度]时，我们就知道判断正确。” 表述应为肯定句（说明用户会做什么），并且足够具体，从而有明确的失败条件。

以下情况应标记： 含糊的信念（“用户会喜欢”“这会提升参与度”）没有指标或阈值；采用否定表述（“用户不会流失”——比测试他们会做什么更难）；把一个想法（“缩短结账流程”）当作可测试的假设。

• ❌ “用户会觉得新手引导很直观。”
• ✅ “我们相信，精简新用户的新手引导流程会提高激活率；当至少 80% 的用户在 2 分钟内完成该流程时，我们就知道判断正确。”

3. 方法的保真度与决策风险相匹配（真实性曲线）

选择能回答问题的成本最低、速度最快的方法——但不能再省。低保真方法（问卷、访谈、纸面原型）测试问题；中保真方法（可点击的模型、落地页／虚设入口、礼宾式服务／绿野仙踪法）测试解决方案；高保真方法（线上 Beta 版、生产环境中的 A/B 测试、完整构建）测试可行性和规模化能力。判断标准是“对这个决策有足够把握”，而不是“尽可能严谨”。

**以下情况应标记：**为了回答一个原型或虚设入口测试就能解决的问题而编写生产代码（投资过度）；或仅凭一天的落地页测试或走廊问卷，就做出重大、昂贵且难以撤销的赌注（对于风险而言，证据不足）；采用的方法从结构上就无法回答所提问题（用点击测试来声称功能满足了需求）。

• ❌ 花六个工程师周开发一项功能，只为“看看有没有人想要”。
• ✅ 先用虚设入口测试衡量点击率；只有确认确有需求后才编写代码。

4. 行为胜过口头意愿

询问“你会用这个吗？”或“你愿意花 20 美元买吗？”会产生假阳性——人们想提供帮助。相信过去的行为，而不是对未来意愿的假设（Mom Test：询问他们的生活和过去的具体经历，而不是你的创意）。

**以下情况应标记：**仅凭假设性的访谈／问卷回答就“验证”了用户需求或付费意愿；测试要求用户预测自己的未来行为或设计解决方案；把口头偏好视同真实行动（购买、点击、注册）。

• ❌ “10 位受访者中有 8 位说他们肯定会用 → 已验证。”
• ✅ “告诉我你上次遇到这个问题是什么时候”＋通过虚设入口的点击率衡量用户真实的主动尝试行为。

5. 在测试前定义成功标准

团队必须在运行测试之前达成一致，明确什么结果能证明假设正确——设定具体、可衡量的门槛。

**以下情况应标记：**事先没有设定通过／不通过的门槛；只有在结果出来后才描述“成功”；有指标却没有目标（“看看注册情况如何”）。

• ❌ 先上线落地页，再决定 30 个注册“感觉差不多够了”。
• ✅ “成功 = ≥10% 的访客预购”，并在发布前达成一致。

6. 将结果视为证据，而非一厢情愿

遵守预先设定的标准；不要转移目标。尊重数据的基本要求——样本量（n=10 可发现可用性问题，但无法说明受众整体的转化率／偏好）、时长（一天的测试可能遇到非典型流量），以及比较中的统计显著性。区分模式（在多个来源中反复出现）和个例（声音最大的一条意见），并交叉核对定性与定量结果——两者一致是绿灯，冲突则表明应再进行一次测试，而不是挑选更合心意的结果。

以下情况应标记：“60% 对比我们的 70% 目标——够接近了”；根据少数用户的反馈声称转化率／偏好；将一天或极短时间段的结果推广到更广泛的情况；由单个声音很大的客户／高管要求推动决策；定量结果与定性结果相悖，团队却仍然继续推进；带着确认偏误解读模糊数据。

• ❌ “只有 55% 的人完成了，但反馈很积极，所以我们就发布吧。”
• ✅ “55% 未达到 70% 的门槛 → 我们修改后重新测试；不重新解释门槛。”

7. 证伪结果确实改变了计划

测试是学习的机会，证伪很有价值——它能避免错误的构建。假设被证伪后，必须改变决策（修订、转向或放弃），并记录结果（假设、方法、标准、发现、下一步）。如果测试只是为已做出的决策盖章，那就不算测试。

**以下情况应标记：**假设被证伪后却毫无改变；测试只是为早已确定的结论走过场；结果未记录，导致团队无法学习或重新审视；验证安排在构建之后，只是为了打勾，而不是尽早开展、以便还有机会改变方向。

• ❌ 可用性测试失败，却「因为我们已经投入」而原样发布原设计。
• ✅ 失败会触发有记录的修订，并在作出承诺前重新测试。

**张力提示：**严谨程度应与风险相匹配——小而廉价、可逆的决策不需要统计显著的实验，强求这类实验本身就是一种失误。不要把适用于低风险决策的快速低保真测试标记为问题。应标记两个方向上的不匹配：对微不足道的决策采用繁重的方法，或对代价高昂、不可逆的决策仅凭薄弱证据。

---

严重性评级

根据决策损害评定每项发现——照原样依据这项验证采取行动会付出什么代价：

严重性	含义
严重	一个关键假设驱动着重大或难以逆转的投入，却没有有效测试——未经测试、只测试了口头意愿、事后移动目标，或样本量远不足以支撑结论。该决策实际上缺乏依据。
重大	关注到了正确的假设，但证据不足以支撑相应风险——方法的保真度不合适、没有预先设定成功标准、由轶事或单一观点主导，或忽视了定性与定量结果之间的冲突。
轻微	影响学习可信度的基本规范问题——结果未记录、测试断断续续而非持续开展，或次要假设仍含糊不清。
表面	对原本合理的计划润色措辞；不要用这类问题充数。

问题重叠时——转交处理，不要重复：成功指标本身是否有效（虚荣指标、可被操纵、不可证伪）属于 pm-okr-metric-validity-audit——本审查检查假设是否经过严格测试，该审查检查的是指标是否值得追求。规格文档是否将假设明确列为风险属于 pm-spec-quality-audit——本审查检查的是测试方法和证据。对相互竞争的押注进行排序的纪律属于 pm-prioritization-rigor-audit。

---

输出格式

## Assumption Rigor Audit — [Plan / Experiment / Claim]
Context: [decision it informs · reversibility/stakes · discovery stage, if known]

### Critical
- [Issue] — what's wrong → fix. (Principle)
### Major
- …
### Minor
- …
### Working well ✓
- …

**Top 3 priorities:** the highest decision-damage fixes.

结尾务必列出按优先级排序的首要问题——平铺罗列毫无助益。

---

如何做好审查

1. 先了解背景——这项验证支持什么决策，决策代价多高、是否可逆？严谨程度应与之相匹配。可逆的 $0 文案调整与为期六个月的平台押注，不应采用同一标准。
2. 找出关键假设——指出整个计划所依赖的信念，并检查是否真正测试了这个假设。
3. 只标记真正的成本——对低风险决策采用恰当的轻量测试是正确做法，不是缺陷。
4. 审视证据，而不只是活动——开展测试 ≠ 学到了东西；检查样本、时长、预设标准，以及信号与轶事之间的区别。
5. 提出具体改进——指出应先测试的假设、更合适的方法、缺失的成功门槛，而不是泛泛地说「要更严谨」。
6. 确定优先级，不要罗列——三个影响决策的发现，胜过十五条吹毛求疵的意见。

---

常见的应做与不应做模式

❌ 不应做	✅ 应做
接受“我们测试过了，用户很喜欢”这种说法	询问测试的是哪项假设、采用了什么方法，以及预先设定的标准是什么
把想法本身当作测试对象	测试该想法所依赖的信念（吸引力、可行性、可实现性、易用性、伦理性）
让团队测试他们觉得舒适的假设	确认优先测试的是重要性高、确定性低的假设
把“你会用这个吗？”当作验证	要求提供过去的行为或实际行动，而非假设性的意愿
接受来自 n=10 的转化率结论	根据所作结论调整样本量、时长和显著性要求
事后接受“差不多就行”	坚守预先商定的成功标准；未达标 → 修订并重新测试
忽略已证伪的假设并未带来任何改变	证伪必须推动决策调整；记录所得经验
重新审查指标本身是否有效	将指标有效性审计交由 pm-okr-metric-validity-audit 处理
对影响轻微且可逆的决策要求严谨实验	根据决策的重要程度调整严谨性
提交未排序的问题清单	按对决策的损害程度评定严重性 + 列出前 3 项优先事项

---

来源课程（Uxcel）

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