在承诺方案或设计实验前，定义可证伪假设，明确目标用户…

适用于团队需要把对用户行为或业务结果的信念转成可测试、可对齐成功标准的假设时。

适用场景

解决思路

1. 陈述信念：用结构化句式写出你相信会发生什么——“我们相信，针对[目标用户]的[行动/变更]将带来[预期结果]。”确保干预具体，模糊假设不可测试。
2. 识别目标用户：定义该假设适用于谁；不要写“用户”这种过宽对象，要指定细分，如首周新用户、10+ 次会话的重度用户、回流的流失用户等。
3. 定义预期结果：明确期望的行为变化或结果；尽可能用用户行为（完成新手引导、购买、7 天内回访）而非内部指标来表述。
4. 设定成功指标：选择直接衡量预期结果的主指标；加入提供背景的次要指标；加入防止在其他方面造成损害的护栏指标。
5. 描述验证方法：说明如何测试该假设——A/B 测试、用户访谈、原型测试、队列分析？具体到样本量、时长和统计要求。
6. 记录风险与假设：列出除测试结果外还可能使假设失效的因素；列出你假定为真但尚未验证的内容。
7. 使用 references/TEMPLATE.md 模板组织输出；完整填写每个模板部分：Hypothesis Statement；Background & Rationale；Target User Segment；Success Metrics；Validation Approach；Risks & Assumptions；Timeline。
8. 定稿前检查：假设可证伪（有可能被证明为错）。
9. 定稿前检查：成功指标有具体数字目标。
10. 定稿前检查：目标用户细分定义清晰。
11. 定稿前检查：验证方法实际可执行且有期限。
12. 定稿前检查：通过/失败标准明确无歧义。
13. 定稿前检查：假设不假定解决方案一定有效。

适用边界 · 注意事项

• 已准备设计具体 A/B 测试（变体、样本量、时长）时，不要用本技能做实验设计；改用 measure-experiment-design，因为本技能只定义要测什么，不定义怎么测。
• 问题本身尚未框定时，不要先写假设；先用 define-problem-statement。
• 需要整理多个假设/想法为发现结构，或需要完整商业模式图而不是单个可测试主张时，不要用本技能；分别用 define-opportunity-tree 或 foundation-lean-canvas。