| 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?
- 用户想做 MVP，但不清楚要验证哪条假设。
- 用户已经开发很久，却没有真实用户行为证据。
- 用户问“什么时候该转向、坚持或放弃”。
- 用户拿虚荣指标证明项目进展。
语言信号
- “MVP 应该做到什么程度？”
- “先做完整 App 还是先做验证？”
- “怎么知道用户真的要？”
- “现在该 pivot 吗？”
与相邻 skill 的区分
- 与
lean-business-model-risk-map 的区别：本 skill 设计单轮学习循环；后者排序整张商业模式风险。
- 与
user-frontline-flywheel 的区别：本 skill 用于验证假设；后者用于经营后持续建立用户反馈飞轮。
- 与
nonconsensus-monopoly-thesis 的关系：后者给出机会假说，本 skill 检验它。
E — 可执行步骤 (Execution)
当 skill 被激活后，agent 应按以下步骤执行：
-
列出关键假设
- 完成标准：把问题拆成客户、问题、价值主张、渠道、收入或留存等可验证假设。
-
选择最危险假设
-
设计 MVP
- 完成标准：用最小成本产生真实行为数据，不把“低质量版本”当 MVP。
-
定义指标和判停条件
- 完成标准：指标必须可观察、可行动；提前写出坚持、调整、转向或放弃条件。
-
输出学习结论
- 完成标准：区分事实、推断和下一轮实验，不用单次反馈做过度结论。
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
