validated-learning-loop

name	validated-learning-loop
description	当用户需要设计 MVP、验证创业假设、判断是否转向或坚持时调用。重点把项目拆成假设、最小产品、真实行为指标、开发-测量-认知循环和判停条件。不适用于已经完全确定需求的常规交付管理。
source_book	02_创业思维 多书分类
source_chapter	《精益创业》验证式学习、MVP、开发-测量-认知循环；《精益创业实战》问题/方案匹配与实验章节；《小米创业思考》MIUI 迭代案例
tags	["startup","lean-startup","mvp","validation","pivot"]
related_skills	[{"slug":"nonconsensus-monopoly-thesis","relation":"depends-on"},{"slug":"lean-business-model-risk-map","relation":"composes-with"},{"slug":"user-frontline-flywheel","relation":"composes-with"}]

有效学习和 MVP 反馈循环

R — 原文 (Reading)

“成功的创业过程是加速这个反馈循环的过程。”

“MVP 的目标是用最少的力气完成一次完整反馈循环。”

“如果没人想要，我们是否按时按预算完成就没有意义。”

来源：《精益创业》。

I — 方法论骨架 (Interpretation)

这个 skill 把“先做个版本看看”改写成一套可验证学习循环。

第一，创业项目是高不确定性系统，早期最重要产出不是功能数量，而是经过验证的认知。 第二，MVP 不是粗糙产品，而是为了验证最危险假设而设计的最小学习装置。 第三，指标必须反映真实行为，不是下载量、点赞或口头称赞这类容易自我安慰的数字。 第四，每一轮实验都要预先定义判停条件：坚持、调整、转向或放弃。

它适合把非共识机会和破坏式入口转成实验，避免团队用“努力开发”替代“学习真相”。

A1 — 书中的应用 (Past Application)

案例 1：《精益创业》的开发-测量-认知

• 问题：新创企业如何知道自己是否真的在进步。
• 方法论的使用：先定义要学习的问题，再倒推出要测量什么、要开发什么。
• 结论：学习速度比功能堆积更能说明创业进度。
• 结果：项目管理从进度表转向假设验证。

案例 2：《精益创业实战》的风险优先

• 问题：早期团队有很多想法，不知道先验证什么。
• 方法论的使用：把商业模式拆成关键假设，优先测试最可能导致失败的部分。
• 结论：最危险假设优先于最容易开发的功能。
• 结果：实验顺序服务于降低失败风险。

案例 3：MIUI 的社区迭代

• 问题：系统体验如何在早期形成真实反馈。
• 方法论的使用：围绕核心用户反馈快速迭代，缩短产品与用户之间的距离。
• 结论：早期用户不是流量，而是学习回路的一部分。
• 结果：用户反馈进入产品节奏。

A2 — 触发场景 (Future Trigger)

用户会在什么情境下需要这个 skill?

1. 用户想做 MVP，但不清楚要验证哪条假设。
2. 用户已经开发很久，却没有真实用户行为证据。
3. 用户问“什么时候该转向、坚持或放弃”。
4. 用户拿虚荣指标证明项目进展。

语言信号

• “MVP 应该做到什么程度？”
• “先做完整 App 还是先做验证？”
• “怎么知道用户真的要？”
• “现在该 pivot 吗？”

与相邻 skill 的区分

• 与 lean-business-model-risk-map 的区别：本 skill 设计单轮学习循环；后者排序整张商业模式风险。
• 与 user-frontline-flywheel 的区别：本 skill 用于验证假设；后者用于经营后持续建立用户反馈飞轮。
• 与 nonconsensus-monopoly-thesis 的关系：后者给出机会假说，本 skill 检验它。

E — 可执行步骤 (Execution)

当 skill 被激活后，agent 应按以下步骤执行：

1. 列出关键假设

   • 完成标准：把问题拆成客户、问题、价值主张、渠道、收入或留存等可验证假设。

2. 选择最危险假设

   • 完成标准：说明哪个假设一旦为假，项目就不成立。

3. 设计 MVP

   • 完成标准：用最小成本产生真实行为数据，不把“低质量版本”当 MVP。

4. 定义指标和判停条件

   • 完成标准：指标必须可观察、可行动；提前写出坚持、调整、转向或放弃条件。

5. 输出学习结论

   • 完成标准：区分事实、推断和下一轮实验，不用单次反馈做过度结论。

B — 边界 (Boundary)

不要在以下情况使用此 skill

• 问题是成熟产品的常规需求排期或工程交付。
• 行业实验成本极高或涉及人身、金融、医疗等高风险，需要先做合规和安全评估。
• 用户只想做市场宣传，而不是验证假设。

作者在书中警告的失败模式

• 用粗糙产品冒充 MVP，却没有学习目标。
• 用虚荣指标证明进展。
• 在没有判停条件时无限试错。

作者的盲点 / 时代局限

• 并非所有业务都能快速低成本实验。
• 强品牌、硬件供应链和监管场景需要更严格质量门。
• 过度实验可能损害早期信任。

容易混淆的邻近方法论

• “敏捷开发”：本 skill 不只是迭代交付，而是验证创业假设。
• “用户访谈”：访谈可以作为输入，但必须尽量转为行为验证。

相关 skills

• depends-on: nonconsensus-monopoly-thesis
• composes-with: lean-business-model-risk-map
• composes-with: user-frontline-flywheel

审计信息

• 验证通过：V1 ✓ / V2 ✓ / V3 ✓
• 测试通过率：机械校验待运行
• 蒸馏时间：2026-06-18