原型法：被低估的"先做再说"哲学
发布于 2026-05-20
原型法为什么在AI时代反而更重要？Hightouch三人团队20个月赚7000万的教训告诉你：骂得越早，产品的命越长。
原型法：被低估的"先做再说"哲学
你以为产品经理的任务是写PRD？错了。他们的任务是——让用户骂你。
骂得越早，产品的命越长。
这不是抖机灵，这是原型法50年来最硬核的结论。
一个价值7000万美元的教训
2025年，Hightouch这家公司干了一件很反常识的事：没有庞大的设计团队，没有层层审批的流程，靠一个三人小团队，20个月搞出了7000万美元的年收入增长。
靠什么？靠AI agent快速生成广告创意、快速拿到市场反馈、快速迭代。
这个故事的底色，恰恰是原型法最经典的逻辑：先做出来给人看，比你写一百页PPT更有说服力。
广告圈的老人都懂这个痛：一个广告从创意简报到上线，4周算快的。4周之后，市场热点早就凉了。团队辛辛苦苦做出来的东西，用户看了一眼就滑走了。
问题出在哪？出在"需求不明确"这件事，在真实的商业世界是常态，不是意外。
你永远不可能在开发之前，把所有需求都想清楚。
原型法的核心洞察就在这里：既然想不清楚，那就别想了——先搞个能跑的东西出来，让人骂，骂完再改。
原型的两种分法，决定了你是在"演戏"还是在"解决问题"
原型法看似简单，门道全在分类上。考题里高频出现两类对比，必须分清楚。
第一种：水平原型 vs 垂直原型。
水平原型，就是只做界面，逻辑全空。你点个按钮，弹个框，但后台什么都不干。这东西拿来干嘛？给用户看"长什么样"，收集对UI的反馈。
垂直原型，恰好反过来。它实现的是某个功能的完整链路——界面有，逻辑也有，数据也跑通。用来验证关键技术是否可行。
一句话记法：水平=好看（界面），垂直=好用（功能）。
第二种：抛弃式原型 vs 演化式原型。
抛弃式原型，用完即弃。它的任务就是回答一个问题："我们做的东西方向对不对？"答案拿到，原型作古，系统重新按规范开发。
演化式原型，则是从一开始就注定成为产品的一部分。核心功能先跑起来，然后像滚雪球一样一点点演化壮大，最终形态就是产品本身。
很多人分不清这两种，做着做着就把"抛弃式"演成了"演化式"，或者反过来——导致文档缺失、架构混乱，项目失控。
瀑布模型的"计划控"，为什么总在创新项目上翻车
原型法和结构化方法（瀑布模型）是两个极端。
瀑布模型要求：需求明确 → 设计完整 → 开发依次进行 → 最终交付。
这套逻辑在什么场景有效？需求稳定的领域，比如政务系统、ERP、嵌入式硬件。干了20年的事情，套路清晰，照着走没问题。
但碰上创新项目呢？比如你要做一个AI驱动的产品，没人干过，用户也说不清自己要什么——你让他描述"想要什么"，他只能说"我想要快一点、准一点、好用一点"。
这种需求，你让产品经理怎么写PRD？
原型法给出的答案是：别写了，做出来。
让用户摸到、用到、骂到。骂完了，你才知道他真正要的是什么。
这不是偷懒，这是用最低成本把"需求理解偏差"这个软件工程最大的坑给填了。
AI时代，原型法便宜到可以随便用
说了半天原型法的好，也得承认它的软肋：无休止迭代、文档不完整、过程难控制。
这三条在以前是很要命的问题。原型的每一次重建都需要时间和资源，迭代太多就会深陷泥潭出不来。