精益验证

运用构建-测量-学习循环，以最小代价验证想法。

为什么

大多数想法失败不是因为技术不对，而是因为没人想要结果。精益验证迫使你先测试最危险的假设——通常是"有人在乎吗？"——再投入数周去构建。跳过这步的团队常常做出只拿到 50 个注册就停滞的产品。这个循环很便宜：一个落地页只需半天，一周的测量不花一分钱，而学到的东西要么快速毙掉想法，要么为下一步降低风险。

何时使用

新想法的第一天，在任何代码之前。跑 2-3 个循环（共 1-2 周）。当你得到明确的"毙掉"信号或连续验证 3+ 个假设时停止。

如何做

1. 找出最危险的假设
   - 写下所有假设，按"如果这个错了，一切全完"排序
   - 排第一的通常是需求类："人们会付费 / 切换 / 使用"

2. 为该假设构建最小测试
   - 需求测试：带邮箱收集的落地页 + "工作原理"说明
   - 可用性测试：给 5 个目标用户看可点击的 Figma 原型
   - 价值测试：人工交付服务的礼宾式 MVP

3. 用真实数字测量
   - 落地页：访客→邮箱注册转化率（目标 > 5%）
   - 原型：任务完成率 + 定性反馈
   - 礼宾式：首次交付后有多少人要求继续 / 付费

4. 学习并决策
   - 已验证 → 转向下一个最危险假设，重复
   - 已证伪 → 毙掉或转型，不要为弱信号找借口
   - 模糊 → 收紧测试（更精准的受众、更清晰的价值主张）

示例

想法："从 git 提交自动生成发布说明的工具。"
最危险假设：开发者会放弃手写发布说明。

循环 1 — 落地页（2 天）：
  - 用 Carrd 搭建，标题"别再手写发布说明"
  - 发到 r/programming 和 2 个开发者 Discord
  - 结果：340 访客，28 邮箱（8.2% 转化）✓

循环 2 — 礼宾式 MVP（1 周）：
  - 给 28 人发邮件："把仓库发我，我免费写你下一条发布说明"
  - 6 人回复。为每人手写了优质说明。
  - 6 人中 4 人问"每次发布都能做吗？我愿付 $20/月"✓

决策：需求 + 付费意愿已验证 → 进入 MVP。

常见问题

⚠测试最容易的假设而非最危险的——你验证了从没被怀疑过的东西，却忽略了真正的威胁。
⚠测量虚荣指标（页面浏览、点赞）而非行动指标（注册、预购、留存意向）。
⚠为弱信号找借口：来自朋友的 2 个注册不是验证，是客气。
⚠循环跑得太慢——每轮 3 周意味着你比 1 周一轮的竞争者慢 3 倍。

最佳实践

✓在测试前写下毙掉标准："如果转化 < 3%，我就毙掉这个想法"——预先承诺防止事后找借口。
✓用陌生人测试，而非你的人脉——朋友和同事偏向鼓励。
✓每个循环限时最多 1 周；如果一周内测不了，说明测试太复杂。
✓保留验证日志：假设、测试、结果、决策——跨循环的模式是单次测试看不到的。