60 分原型原则
Builder 的执行标准：目标不是做完美产品，是亲手把东西跑到 60 分——能点击、能跑通主流程、能让人真实地用一下。
简介
60 分原型原则是 原型思维 的执行层方法论。它回答的是”原型做到什么程度就够了”这个具体问题。
很多 PM 卡在”自己做产品”这一步，脑子里浮现的是上线级别的工程量，于是直接劝退。60 分原型原则破除这个误解：Builder 的目标不是做完美产品，是亲手把东西跑到 60 分。
60 分的定义很具体：能点击、能跑通主流程、能让人真实地用一下。它的全部价值在于把”这个想法能不能成立”从你的想象里拽进现实里。不是为了上线，是为了验证。
这个原则之所以在 2026 年变得可行，是因为 Vibe Coding 和 AI 原型工具把”做出一个能点击的 demo”的门槛大幅降低。Karpathy 在 YC 演讲中描述的 partial autonomy 和 vibe coding，本质都是降低了这个门槛——让一个不写代码的人也能产出一个能验证的 demo。
关键信息
| 维度 | 内容 |
|---|---|
| 类型 | 产品验证执行标准 |
| 核心定义 | 能点击 + 能跑通主流程 + 能让人真实用一下 |
| 两条原则 | Fast（亲手快速跑通）+ Autonomous（不依赖排期） |
| 适用场景 | PM 验证新功能、独立开发者做 MVP、团队解决方案争论 |
| 相关方法论 | 原型思维、Vibe Coding、MVP |
核心特性
一、60 分 = 能点击 + 能跑通主流程 + 能让人真实用
不是做完美产品，是把想法从想象拽进现实。具体标准：
- 能点击：有真实的 UI 界面，不是文档描述
- 能跑通主流程：核心用户路径可以走完，不是只有首页
- 能让人真实用一下：给真人体验时能产生真实反应（卡在哪、皱眉在哪）
二、Fast + Autonomous 双原则
Fast：亲手快速跑通，不用等任何人。不用等排期、不用等设计、不用等开发。
Autonomous：不依赖排期、不依赖别人有没有空。PM 自己就能走完从想法到可点击 demo 的全过程。
当你能 Fast 且 Autonomous 地把想法跑到 60 分，你和那些只能停留在脑内构想的人之间，会拉开一条很难追的差距。差距不在谁想得多，在谁验证得快。
三、验证快，省的是整个团队空转的时间
一个晚上的原型可以省掉整个团队两周的空转。真实案例：团队为”新用户引导用分步弹窗还是常驻进度条”吵了两周、开了三次会、改了五版文档。PM 花一晚做两个可点击 demo，第二天六人各点一遍——五个人在第二步就想关分步弹窗。两周会议吵不出的事实，一晚原型问出来了。
四、60 分原型 ≠ 可交付产品
两个边界：
- “一个人做产品”在 demo 层成立，在商业层不成立。规模化、可靠性、合规、增长依然需要团队。
- Vibe coding 出来的代码有质量和可维护性陷阱。“能跑”和”能上线”是两回事。
60 分原型的真正意义是拿回验证主动权，不是取消专业分工。
不同素材中的观点
来自 2026-06-12-pm-as-builder-prototyping：
- 60 分 = 能点击 + 能跑通主流程 + 能让人真实用：目标不是完美产品，是把想法从想象拽进现实。两条核心原则 Fast + Autonomous 拉开验证速度差距。
- 一晚原型胜过两周会议空转：分步弹窗 vs 常驻进度条争论案例——六个同事各点一遍，五人第二步就想关分步弹窗。验证快省的是整个团队的时间。
- 差距不在谁想得多，在谁验证得快：当你能 Fast 且 Autonomous 地把想法跑到 60 分，和那些只能停留在脑内构想的人之间会拉开很难追的差距。
- demo ≠ 产品：Builder 化的真正意义是拿回验证主动权，不是取消专业分工。
实用信息
快速上手
- 选一个极小的想法：不要上来就做复杂产品。小，才跑得动。
- 唯一目标：能点击 + 能跑通一条主路径：丑没关系，缺功能没关系，跑不通的分支直接删掉。
- 做完立刻拿给至少三个真人点：不是给 PM 看，是给真实用户看。手指卡在哪、眉头皱在哪——这才是答案。
常见误区
- 一动手就想把边界情况全考虑进去：结果 demo 做成了项目，最后放弃
- 追求视觉完美：60 分是功能验证标准，不是设计标准
- 只给自己看：PM 自己会偏，真人反应才是答案
- 把 demo 当成可交付产品：原型验证想法，上线需要工程团队