← 知识整理
商业与创业 / 知识整理 · 中英版本

精益创业 / MVP / 关键假设(跨作者主题综合)

3 视角的精益创业融合。yitang Truman 精益实验(浪费六宗"最" + 4 原则 + 剥离假设 + MVP 设计 + 系统测试)+ 关键假设 Ω 模型 + 业务里程碑 / 王凯踩坑(11 个亲历项目 + 出海 PMF 验证)/ 王慧文清华课(精益创业 5 必读书之一 + 迭代周期巨大优势)。覆盖关键假设思维、MVP 4 类型、Ω 模型、系统测试纪律

资料来源:跨来源主题整理 · 本站发布:2026-09-26 · 笔记更新:2026-10-18

精益创业MVP关键假设

何时打开:你要做 MVP / 验证关键假设 / 找业务里程碑 / 想用精益方法低成本验证。本 wiki 融合 3 派视角。

一句话核心:Truman:"没有'关键假设'的精益创业,就很难低成本"。王慧文(清华):"迭代周期比别人短,就获得巨大竞争优势"。关键假设三板斧:加法(列全)+ 减法(优先级)+ 快验证(低成本)。

0. 核心定义

  • 关键假设 = 业务成败背后的具体客观假设(替代"我认为")
  • MVP = Minimum Viable Product 最小可行产品
  • 业务里程碑 = 下一个最该被验证的关键假设
  • Ω 模型 = 提假设 → 验证假设 → 迭代/淘汰

1. 跨作者共识(4 条)

1.1 关键假设是精益创业的灵魂

一堂 / 五步法完整体系(关键假设 + 业务里程碑 + 五步法 5 进阶 + 落地) §三 Truman:

"没有'关键假设'的一堂五步法,就是个空壳;没有'关键假设'的精益创业,就很难低成本;没有'关键假设'的新业务讨论,就很难科学高效。"

"在商业和管理领域,真正的高手,都是关键假设高手。"

沟通替换:

❌ 旧 ✅ 新
"我认为..." "我的假设是..."
"我的观点是..." "我假设..."
"做什么"的讨论 "假设什么"的讨论

1.2 Ω 模型(关键假设工作 3 步)

        提假设(Hypothesize)
            ↓
        验证假设(Verify)
            ↓
        迭代/淘汰(Iterate)

3 个维度的关键建议:

维度 重点
思维 用"假设"替代"主观观点" / 给每个假设打标签:成立/不成立/待验证
沟通 团队习惯"我的假设是 X / 验证方式 Y / 现状 Z"
工具 关键假设清单 + 优先级排序 + 验证 ROI

1.3 迭代周期巨大优势(王慧文经典)

一堂 / 王慧文清华产品课 66 页完整笔记 5 必读书:

"《精益创业》: 把验证速度搞快、成本搞低。如果迭代周期比别人短,就获得巨大竞争优势。"

1.4 假设 5 问灵魂拷问

  1. 你的"我认为"背后,实际的客观假设是什么?
  2. 这个假设你打算怎么验证?
  3. 如果假设不成立,你的业务会怎样?
  4. 验证这个假设需要多少成本?
  5. 这个假设是 60% 把握 还是 80%?

2. yitang 精益实验 4 大模块

一堂 / 情报调研 + 精益实验完整体系 Part B:

2.1 浪费六宗"最"

浪费 表现
1. 最忙的浪费 团队天天加班但没核心进展
2. 最贵的浪费 大投入做了没验证的事
3. 最快的浪费 跑得快但跑错方向
4. 最久的浪费 一个错误项目拖几年
5. 最远的浪费 早期方向错,后期纠正成本极大
6. 最深的浪费 习惯于"忙"代替"成果"

2.2 精益创业 4 原则

  1. 构建-测量-学习(Build-Measure-Learn)反馈环
  2. 最小可行产品(MVP)
  3. 真实可执行的目标(Validated Learning)
  4. 创新核算 + 转向(Pivot)

2.3 关键假设三板斧

板斧 动作
加法 列全所有假设(2/5/9 分法)+ 7 渠道获取
减法 排序(3 优先级:最致命 / 最不确定 / 最低成本验证)
快验证 3 手段(用户访谈 / MVP / 数据测试)

2.4 MVP 4 类型

MVP 适用
草图 / 视频 MVP 概念验证(Dropbox 早期)
门面 MVP(Wizard of Oz) 手工提供伪自动化服务
单功能 MVP 1 个核心功能,其他全砍
关键模块 MVP 复杂产品的单模块独立验证

2.5 系统测试纪律

  • 一次只测试一个变量
  • 提前定义"成功指标"
  • 不要修改假设以匹配数据
  • 失败的假设要及时淘汰

3. 业务里程碑(yitang 独家)

一堂 / 五步法完整体系(关键假设 + 业务里程碑 + 五步法 5 进阶 + 落地) §二 业务里程碑(Truman 7 版迭代 / 11 万人上过):

3.1 4 个核心问题

# 问题 答案核心
1 创业究竟在创什么? 创建一个可持续创造价值的商业体
2 如何拆解项目背后的逻辑? 一堂五步法
3 如何抓住商业模式的关键? 关键假设 + 单元模型
4 如何低成本验证业务? 精益创业 + 关键假设排序

3.2 业务里程碑 ≠ 时间节点

"里程碑"= 下一个最该被验证的关键假设,而非"6 月发产品""8 月融 A 轮"这种时间锚。

3.3 85% 业务一号位的姿势是歪的

调研发现(100 个项目 + 700+ 案例 + 11 万学员):

  • 关注资源和外部机会
  • 但不理解业务成败背后的底层逻辑
  • 不同 CEO 看同一个项目深度差距巨大

4. 一堂五步法 1-100 版迭代(独家)

一堂 / 五步法完整体系(关键假设 + 业务里程碑 + 五步法 5 进阶 + 落地) §四:

版本 主题 重点
V1-V10 起盘探索 大胆假设 + 快速调研验证
V10-V30 内核打磨 找到精准产品内核 + 单元模型成立
V30-V50 商业模式 单元模型基准值 + 动态预测
V50-V100 增长 + 壁垒 增长引擎 + 长期壁垒构建

L1-L5 段位:

  • L1:知道五步法
  • L2:能用五步法解读别人的项目
  • L3:能用五步法拆自己的项目 1-3 版
  • L4:能用五步法迭代 10-30 版 + 用关键假设驱动(及格线)
  • L5:能用五步法迭代 50-100 版 + 教别人

5. 王凯踩坑印证(11 个亲历项目)

王凯 AI 时代创业方法论与商业判断框架 §12 + 王凯产品失败复盘合集:

项目 关键教训
AI 电商导购站 早期 token 成本算不平(没验证)
FastFacts 承载金 30 万天花板 + 量化 team 比我们快 5 秒(没做对手分析)
AiPathly(AI 求职) 创新品做 SEO 错配(没验证流量假设)
Quanta Quest 数据权限被卡(没验证基础设施假设)
WhatsApp 推送机器人 海外推送有 IM 直接覆盖(没验证赛道假设)

共同教训:算账没算对(多数) + 死在启动后的 3 个月内 + 鸵鸟心态。

王凯 4 句话:

  • "做产品比喻造椅子:世界上还没椅子时,造第一把不要管舒适度"
  • "大企业 1 年耐心、独立开发 3 个月断生死"
  • "验证完'椅子有人要',再加把手"
  • "项目大概率是要死的,90% 不咋赚钱"

6. Candy:多抓鱼起盘 + 陈先敏选品(yitang 独家)

一堂 / 五步法完整体系(关键假设 + 业务里程碑 + 五步法 5 进阶 + 落地) candy:

6.1 多抓鱼起盘复盘

  • 二手书电商
  • 早期假设:用户愿意收/卖闲置书 + 价格合理 + 物流跑通
  • 验证方式:从微信群手工接单开始(Wizard of Oz MVP)
  • 关键转折:验证后才上线 APP

6.2 陈先敏中式汉堡选品

  • 50+ 家店从 0 到 1
  • 多轮假设迭代:产品 / 用户 / 选址 / 单店模型
  • 用精益验证 + 系统测试

7. 怎么选 —— 按身份的精益创业路径

你是谁 主用方法 起点
业务一号位 / 创业者 yitang 精益 4 模块 浪费六宗最 + 4 原则 + 三板斧 + 4 类 MVP
想用关键假设思维 Truman Ω 模型 提 → 验 → 迭 + 5 问灵魂拷问
想找业务里程碑 yitang 五步法 五步法 5 cell + 关键假设排序 + 当前最不确定的
要避免踩坑 王凯 11 个项目教训 算账先于动手 + 3 个月断生死 + 不鸵鸟
想训练快速迭代 1-100 版迭代路径 V1-V10 起盘 / L4 及格线

通用纪律:

  1. 用"假设"替代"我认为"(Truman)
  2. 迭代周期比别人短 = 巨大竞争优势(王慧文)
  3. 算账先于动手(王凯)
  4. 关键假设三板斧:加法 + 减法 + 快验证
  5. 3 个月断生死(独立开发)
  6. 5 问灵魂拷问每条假设

8. 引用清单

相关 skill:

  • yitang-evaluate-business-milestone —— 业务里程碑判断
  • yitang-extract-validation-assumption —— 抽取验证假设
  • yitang-master-key-hypothesis —— 关键假设大师
  • yitang-design-mvp —— MVP 设计
  • yitang-systematic-validation-testing —— 系统验证测试
  • yitang-master-lean-validation —— 精益验证大师

来源与关联资料

Read in English ↓

2026-10-18 增补:AI产品从原型、交付到PMF的分层验证

本节将42章经2023–2026年的多期访谈,与上文关键假设方法相接。节目中的收入和留存属于当期团队陈述,未独立审计;下文提炼的是可检查的问题及机制,不能据此宣布自己的产品已有PMF。主线来自Albert的PMF反思、Hidecloud的产品实践、三家产品的不同证据、Answer.AI及Albert两年后的创作者社区探索。

先把五个假设拆开,选择最可能使业务失败的一项

假设 需要的证据 容易误当作证据的东西
当前技术能做 真实输入下,稳定得到可检查的结果,错误边界已知 精选演示、最佳一次输出、模型榜单
产品能交付 用户自己能完成任务,坏结果可改、可恢复,等待和成本可接受 团队内部跑通或工程师代操作
用户确实需要 目标用户主动使用、在需求发生时回来,能说清替代方案 创始人喜欢、行业朋友说“很酷”
用户愿意付费 实际付款、退款、复购与续费,明确人群和观察期 免费留存、口头表示愿付费、加候补名单
生意能持续 对应队列的收入覆盖获客、推理、内容和服务成本 总收入上涨、短期买量打平、预计模型会降价

五项不是所有业务都按同一顺序排队。已有客户的企业可先检验交付与付费;全新娱乐社区可能先做供给与回访;确定任务的工具可以更早收费。关键在于一次试验回答哪项,不能让一份好看的结果代替整条链。

高途案例进一步说明:AI覆盖率、节省时间、转化率和单条线索产出是不同指标。官方章节写“成单率3–4倍”,正文却明确三四倍是单效,并承认只接小部分流量。业务报告应保留这种口径差异,不能选最大数字当成果。

从用户预期与当前交付能力选择起点

Albert在2024年提出两个轴:用户的交付预期是否明确、现有模型能否满足它。对资源有限的团队,预期明确且当前能交付的任务更容易积累反馈;开放愿景或依赖未来技术的任务,需要不同耐心与资源。这个框架帮助决定试验,并不意味着企业集成、安全工程或前沿研究不值得做。

Hidecloud的儿童绘画案例给出另一面:即使技术可用,要求5–10岁儿童写提示也可能不符合使用能力。输入方式、响应速度改变的不只是效率,还会改变互动是否连续。模型产品匹配要问“目标用户怎样表达、何时看到反馈、看到后怎样继续”,再决定模型、界面和工程;不是先挑最强模型再寻找按钮位置。

把它落成一次可执行试验时,先写一个具体用户、一个真实场景、一份可接受交付,再记录可失败的输入。给用户自己用,观察失败在哪里:不会输入、结果不对、不会修改、没有下一步、还是根本没有需求。不同失败应改不同层,不能都归为“模型不够强”。

最后一步可控,往往比第一次惊艳更重要

三家PMF访谈中的ACE Studio指出,一键生成音乐可能85%满意,最后一小段却使整首不能用;重新生成又改坏了原先好的部分。它的产品选择是允许逐音符、歌词与唱法修改,而非无限抽取整曲。85%是说明问题的例子,不能当测量精度。可迁移的问题是:用户能否保留满意部分,只改不满意部分,并进入原有工作流?

早期Dify则把提示、知识资料、模型与工具调试放到持续运营中,帮助懂业务的人参与迭代。两者的共同点是交付包含可修改与维护;差别在于音乐作品的局部控制和企业应用运营不是同一套界面,不能机械复制。

Wanaka又提供反例:3D物体位置与摆放,用手直接操作可能比自然语言描述容易。让AI做逻辑、人直接调空间与细节,可以比“所有任务都进聊天框”更合适。AI占工作量多少是设计选择,验收仍是用户能否完成想要的作品。

留存要问“谁因为什么回来”,不要只拿一个行业阈值

FlowGPT把单应用留存、内容品类留存和平台留存区分开:用户可能换娱乐Bot,仍每周回来找同类内容;而关系型陪伴又可能依赖同一角色。三层应分别测,不能仅因换角色认定平台失败,也不能把平台回访当稳定关系成立。FlowGPT精读没有给出全部分母与周期,因此这里保留其观察而非通用基准。

三PMF访谈也不能混为一谈:AiPPT关心低频任务的实际付费和获客成本;ACE Studio看专业用户工作流和付费;捏Ta先看有线索的角色创作是否提高回访、消耗和分享,再以广告、小额付费、复购确认商业意愿。节目引用的“421”留存经验线,没有统一 cohort(同批进入用户)定义,不能直接作为其他产品的合格线。

对订阅产品应另看新客和续费队列。Albert提到续费累积可能改善后续毛利,但续费率、服务成本、退款与获客价格都会变化;“第三年一定更赚钱”不是这个逻辑的必然结论。预算扩大应由自己的真实队列证明。

创作者、消费者与关系网络需要分别验证

捏Ta原先从“用户愿意生成角色壁纸”推到“用户愿意编漫画”,后来发现中间缺了一层愿意构思故事的人。它改为专业创作者给剧情线索,普通用户把个人角色带入、生成片段并积累记忆。需要检验的是线索是否同时足够容易套用、又保留个人表达,而非只给更多自由输入框。

Wanaka关于熟人分发的观察与此相补充:同学、学校地图、朋友形象对全网未必好看,对特定关系有价值。FlowGPT平台与创作者相互成就,则依赖生产、曝光、消费、再次创作。不能从“生成能力便宜”直接推导推荐流、熟人社交或创作社区中任意一种必然成立。

AI音乐访谈进一步提醒:会生成不等于愿创作,用户仍需要灵感和精选供给,审美更好的作品也可能胜过“完全是我的”内容。评估应采用普通消费标准,避免因作品是AI做的就降低要求。

保留分歧与时间变化,选择适合自己阶段的成功标准

2024年Albert强调现金流、持续需要与可验证的交付,2026年探索merging.live时更强调回应、回响和回报三个层次。两者不是可以无缝合成的“永远先赚钱”或“只需影响力”;个人创作、融资公司、不同阶段的目标和成本责任不同。其团队两个月做几十个工具但当时收入为零,说明创造速度与商业结果也应分开记录。

本节给出的操作选择是:先明确当前任务究竟验证可用性、用户价值、关系/供给、付费还是单位经济,再找一项足以推翻自己判断的证据。没有足够证据的设想保留待验证;与预期不符的数据用于修正归因,而不是改写成成功故事。

把产品市场匹配与产品模型匹配并列检查

张海龙2024年Coding访谈将Product Market Fit(交互、场景、定价是否被市场接受)与Product Model Fit(当前模型能否支撑体验)分开。Cursor的跨位置编辑示例说明,想要的交互可以先被定义,但要等能力、延迟与上下文工程同时达到可用;相反,代码能生成也不证明有人想用这个软件。用这两份记录检查新功能,能避免把需求问题误归技术,或把演示热度误认市场验证。关于当时Agent尚无清晰PMF的判断保留2024年语境,不用来覆盖后续产品进展。

English version

October 18, 2026 addition: Validate AI products in layers, from prototype and delivery to product-market fit

This section connects several 2023–2026 interviews from the 42 Zhangjing podcast with the critical-assumption method above. Revenue and retention figures are statements made by the teams at the time, without independent audit. The aim is to extract questions and mechanisms that can be checked, rather than declare that your own product already has product-market fit (PMF). The main sources are Albert's reflections on PMF, Hidecloud's product work, the different evidence used by three products, Answer.AI, and Albert's exploration of a creator community two years later.

Separate five assumptions, then choose the one most likely to break the business

Assumption Evidence needed What can be mistaken for evidence
The technology can do it today Real inputs consistently produce inspectable results, with known failure boundaries A curated demonstration, a single best-case output, or a model leaderboard
The product can deliver Users can complete the task themselves, correct and recover from poor results, and accept the wait and cost An internal success or an engineer operating it for the user
Users actually need it Target users choose to use it, return when the need arises, and can identify their alternatives The founder likes it, or industry friends call it “cool”
Users will pay Actual payments, refunds, repeat purchases, and renewals, with a defined audience and observation period Retention among free users, stated willingness to pay, or joining a waiting list
The business is sustainable Revenue from the relevant cohort covers acquisition, inference, content, and service costs Rising total revenue, a short period of acquisition breaking even, or an expected fall in model prices

These assumptions do not have to be tested in the same order for every business. An enterprise with existing customers may start with delivery and payment. A new entertainment community may first need content supply and returning users. A tool for a well-defined task may charge earlier. The key is to state which assumption an experiment answers, rather than let one attractive result stand in for the entire chain.

The Gaotu case makes the distinction more concrete: AI coverage, time saved, conversion rate, and output per lead are different metrics. The official chapter title says “3–4 times the closing rate,” but the discussion identifies the three- to fourfold figure as output per lead and acknowledges that the experiment handled only a small portion of traffic. A business report should preserve that difference in definitions instead of choosing the largest number as its headline result.

Start with user expectations and what can actually be delivered today

In 2024, Albert proposed two axes: whether users have clear expectations for the deliverable, and whether existing models can meet them. For a team with limited resources, a clearly expected result that can already be delivered makes feedback easier to accumulate. An open-ended vision or a task that depends on future technology requires different resources and patience. This framework helps select experiments; it does not imply that enterprise integration, security engineering, or frontier research is unworthy of investment.

Hidecloud's example of a drawing product for children shows another constraint. Even when the technology works, asking children aged five to ten to write prompts may exceed their ability to use the product. Input methods and response speed affect more than efficiency: they can determine whether an interaction remains continuous. Product-model fit requires asking how target users express themselves, when they see feedback, and what they can do next, before selecting the model, interface, and engineering approach. It is not a matter of choosing the strongest model first and then deciding where to put the buttons.

For a concrete experiment, specify one user, one real situation, and one acceptable deliverable, then record inputs that could cause failure. Let users operate the product themselves and observe where it breaks: they cannot enter their intent, the result is wrong, they cannot edit it, there is no useful next step, or they never needed it in the first place. Different failures require changes at different layers. They cannot all be explained away as “the model is not strong enough.”

Control over the final step often matters more than the initial surprise

In the interview about three products and PMF, ACE Studio explains that a one-click music generation result might be 85% satisfactory, yet one small remaining section can make the whole song unusable. Generating the song again may ruin the parts that were already good. Its product response is to let users edit individual notes, lyrics, and singing techniques, rather than repeatedly regenerate entire songs. The 85% figure illustrates the problem; it is not a measured accuracy score. The transferable question is whether users can preserve the parts they like, change only what they dislike, and use the result in their existing workflow.

Early Dify places prompts, knowledge materials, models, and tool debugging within ongoing operations so that people who understand the business can participate in iteration. Both approaches treat editing and maintenance as part of delivery. Their differences matter too: local control over a music work and enterprise application operations do not call for the same interface, so one cannot simply copy the other.

Wanaka provides a counterexample to making natural language the universal interface. Directly moving and placing a 3D object may be easier than describing its location in words. Letting AI handle logic while people adjust space and details can work better than putting every task into a chat box. How much of the work AI performs is a design choice; acceptance still depends on whether users can make the work they intended.

Retention asks who returns and why, rather than whether a product clears one industry threshold

FlowGPT distinguishes retention for an individual application, a content category, and the platform. A user may change entertainment bots while continuing to return each week for that kind of content. Relationship-based companionship, by contrast, may depend on returning to the same character. These three levels should be measured separately. Switching characters does not by itself establish platform failure, and returning to the platform does not establish a stable relationship. The FlowGPT interview does not provide all denominators and observation periods, so its observations are retained here without being turned into universal benchmarks.

The three PMF cases also use different evidence. AiPPT focuses on actual payment and acquisition costs for a low-frequency task. ACE Studio examines professional workflows and payment. NieTa first checks whether guided character creation increases returns, usage, and sharing, then uses advertising, small payments, and repeat purchases to test commercial willingness. The interview's “421” retention rule of thumb does not specify a consistent cohort definition—a group of users who enter during the same period—and should not be adopted directly as a pass mark for another product.

Subscription products should also distinguish new-customer and renewal cohorts. Albert suggests that accumulated renewals may improve later margins, but renewal rates, service costs, refunds, and acquisition prices all change. The logic does not guarantee that “the third year will be more profitable.” A team's own observed cohorts must justify expanding its budget.

Validate creators, consumers, and relationship networks separately

NieTa initially moved from “users want to generate character wallpapers” to “users want to create comics,” then discovered a missing layer: people willing to invent stories. It shifted toward professional creators supplying plot prompts, while ordinary users bring their own characters into those situations, generate scenes, and accumulate memories. The question is whether those prompts are easy enough to use while retaining room for personal expression, rather than whether users have been given more blank input boxes.

Wanaka's observations about distribution among friends complement this finding. Classmates, school maps, and representations of friends may not interest the whole internet, but can have value within a particular relationship. FlowGPT's platform and creators depend on a cycle of production, exposure, consumption, and further creation. Cheap generation does not by itself establish that a recommendation feed, a friends-based social product, or a creator community will necessarily work.

The AI music interview adds another warning: being able to generate content does not mean people want to create it. Users still need inspiration and curated supply. A work with stronger aesthetic quality may also beat one that feels “entirely mine.” Evaluation should use ordinary consumption standards, rather than lower expectations because the work was made with AI.

Preserve disagreement and changes over time, and choose success criteria that fit the current stage

In 2024, Albert emphasized cash flow, enduring need, and verifiable delivery. In his 2026 exploration of merging.live, he placed more weight on response, resonance, and return as three distinct levels. These views cannot be seamlessly reduced to either “always earn money first” or “influence is all that matters.” Individual creation, venture-funded companies, and different business stages have different objectives and cost responsibilities. His team built dozens of tools in two months while reporting zero revenue at the time, illustrating why creation speed and commercial results should be recorded separately.

The operating choice proposed here is to identify what the current task is testing: usability, user value, relationships and supply, payment, or unit economics. Then find evidence capable of disproving the team's judgment. Ideas without enough evidence remain hypotheses. Unexpected data should correct the explanation, rather than be rewritten into a success story.

Check product-market fit and product-model fit side by side

Zhang Hailong's (张海龙) 2024 coding interview separates Product Market Fit—whether the market accepts the interaction, scenario, and pricing—from Product Model Fit—whether the current model can support the experience. Cursor's example of editing across multiple code locations shows that a desired interaction can be defined before model capability, latency, and context engineering jointly make it practical. Conversely, generating code does not prove that anyone wants the resulting software. Keeping these two records for each new feature helps prevent demand problems from being mislabeled as technical failures, or demonstration excitement from being mistaken for market validation. The interview's judgment that agents had not yet found clear PMF remains a 2024 observation; it does not override subsequent product developments.