| name | f01-four-stage-evolution |
| description | 用户有一个产品想法但在犹豫是否要开始写代码时；或用户问"我应该如何验证我的想法"时。
用户处于"想创业但不知道从哪开始"的迷茫期，试图找技术合伙人或购买SaaS工具跳过验证阶段。
不适用于：已有成熟产品需要迭代的情况；用户已有明确PMF（产品-市场契合）证明需要规模化。
关键trigger信号："我有一个App想法"、"要不要先做个原型"、"不确定有没有市场"
|
| source_book | 《极简主义创业》 Sahil Lavignena |
| source_chapter | 第三章「越少越好」 |
| tags | ["product-development","automation","process"] |
| related_skills | ["p03-less-is-more","p07-software-not-labor"] |
极简主义创业四阶段演进框架
R — 原文 (Reading)
"你需要按照正确的顺序完成这些阶段，否则你会陷入永无止境的产品开发地狱。你的客户不是在为你将要构建的产品付费——他们在为你今天能解决的问题付费。"
— Sahil Lavignena, 第三章
I — 方法论骨架 (Interpretation)
这个框架揭示了产品开发的正确顺序不是"创意→代码→发布"，而是人工→流程化→产品化→自动化。
第一阶段"人工"是最被低估的起点：创始人自己充当服务者，用时间和技能直接解决客户问题，同时记录每一个步骤。这个阶段的核心不是"做得慢"，而是"学得快"——没有任何软件能替代真实客户互动中的信息密度。
当人工服务积累了足够的重复性操作，就进入第二阶段"流程化"：把记录下来的步骤整理成文档或清单。流程化的标志是：一个新员工能否在文档指导下独立完成这项服务？
第三阶段"产品化"是把流程变成可销售的软件或服务。此时开发者介入才有意义，因为产品需求已经被真实数据定义清楚了。
第四阶段"自动化"是让产品自行运转，创始人可以退出日常操作，转向更大的问题。
核心洞察：产品不是起点，流程才是。产品是流程的最终形态，而非起点。
A1 — 书中的应用 (Past Application)
案例 1: Gumroad 的起步
- 问题: Sahil 想验证"帮设计师卖数字产品"这个想法是否有市场需求
- 方法论的使用: 他没有先开发软件，而是手工帮每个客户处理 PayPal 付款——手动收集信息、月底手动转账
- 结论: 有人在付钱，这个需求是真实的
- 结果: 手工服务持续了数月后才开发软件，验证了需求才投入技术资源
案例 2: Endcrawl 的片尾字幕服务
- 问题: 影视公司需要快速处理片尾字幕，但市场上没有现成工具
- 方法论的使用: Endcrawl 创始团队用 Google 表格和 Perl 脚本手动处理，完全不用软件 UI
- 结论: 15分钟可以完成原来24小时的工作，市场存在
- 结果: 手工流程跑通后才开发产品，避免了"没人用的完美软件"
A2 — 触发场景 (Future Trigger) ★
用户会在什么情境下需要这个 skill？
- 用户有一个产品想法，但不确定有没有市场，正在考虑"要不要先做个原型"
- 用户试图找技术合伙人或购买 SaaS 工具来"跳过"前期验证
- 用户在讨论"MVP 应该包含哪些功能"，而不是"MVP 之前应该做什么"
- 用户说"我担心自己的想法太小众，不值得做"
- 用户在构建产品时遇到瓶颈，迭代了很多版本但没有人用
语言信号 (用户的话里出现这些就应激活)
- "我有一个 App 想法，但不确定市场"
- "要不要先找个技术合伙人"
- "我的 MVP 应该有几个功能"
- "我在做一个 SaaS 产品"
- "我已经做了 6 个月产品，但还是没用户"
与相邻 skill 的区分
- 与
p03-less-is-more 的区别: p03 是"克制做产品的冲动"，f01 是"按顺序经过四个阶段的框架"；p03 关注"不要做什么"，f01 关注"按什么顺序做"
- 与
f02-community-driven 的区别: f02 关注"从社区发现问题"，f01 关注"验证后如何演进"；f02 是起点，f01 是全程地图
E — 可执行步骤 (Execution)
当 skill 被激活后，agent 应按以下步骤执行:
-
识别当前阶段
- 完成标准: 确认用户处于哪个阶段（人工/流程化/产品化/自动化），通过问"你现在是怎么服务客户的？"来判断
-
倒推到前一个阶段
- 完成标准: 如果用户在做软件，问"你手工服务过多少客户？"如果答案是0，跳回阶段1；如果答案是几个，评估流程是否固化
- 判停条件: 若用户从未手工验证过，直接跳到步骤 2.1（重新开始人工阶段）
-
完成当前阶段的核心任务
- 阶段1: 用人工服务10个客户，记录每个步骤
- 阶段2: 把步骤整理成文档，让非创始人也能执行
- 阶段3: 用代码实现文档中的流程
- 阶段4: 消除创始人参与，建立监控和异常处理机制
B — 边界 (Boundary) ★
不要在以下情况使用此 skill
- 用户已经有了明确的产品-市场契合信号（100+付费回头客），正在考虑规模化——此时应该用 f06-growth-stages
- 用户的问题是"如何融资"而非"如何验证"——这个框架不解决资本问题
- 用户在做 B2B 企业销售，需要定制化交付而非标准化产品——流程化可能不适用
作者在书中警告的失败模式
- "跳过人工阶段直接做产品，就像在黑暗中射击——你可能在做没人要的东西"
- "很多创始人把'忙碌'和'进展'混淆。手工服务客户是忙碌，建立流程是进展，写代码只是记录进展"
作者的盲点 / 时代局限
- 框架假设所有服务都可以最终自动化，但某些服务（如高定制化咨询）本质上不可自动化
- 框架对"速度"的要求可能过高——对于需要快速抢占市场的竞争性行业，跳跃式发展可能是必要选择
容易混淆的邻近方法论
- 精益创业 MVP: 精益用软件做最小化产品，这个框架更进一步——用人工做最小化服务；精益是"减少功能"，这个框架是"替换工具"
- Y Combinator 的"做人们想要的东西": 两者都强调验证，但 YC 更强调速度，这个框架更强调顺序
相关 skills (阶段 3 填充)
- depends-on: [p03-less-is-more]
- contrasts-with: [lean-startup-mvp]
- composes-with: [f02-community-driven, p14-100customers]
审计信息
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 测试通过率: 待测试
- 蒸馏时间: 2026-04-17
相关链接
