用低代码做 MVP 验证：两周一个原型的节奏

创业公司最贵的成本是验证错方向的时间。我们团队用低代码平台跑 MVP 验证两年多了，节奏稳定在两周一个可用原型——业务假设、原型上线、真实用户试用、数据回收、决策去留，一个闭环十四天。这篇把这套节奏完整拆开。结论先说：MVP 的目的不是做出小一号的产品，是回答一个业务问题——两周节奏的本质是给验证设置倒计时，逼着团队砍掉一切与回答问题无关的东西。

一、为什么是两周

1.1 验证的经济学

创业公司的生死线是试错速度。同样一笔钱，一年验证四个方向和一年验证十二个方向，存活率差三倍。我们算过自己的账：传统开发做一个像样的原型，需求一周、开发三四周、修修补补一周，六周起步——这还是一切顺利。六周一个验证，一年八个；两周一个，一年二十四个。方向正确的概率不变的前提下，试错次数就是概率的放大器。两周不是拍脑袋定的，是验证经济学的最优解。

1.2 两周倒逼聚焦

两周的时间盒有个妙处：它逼你说清这次到底验证什么。我们的规则：每个 MVP 立项必须写成一句话——我们想验证用户是否会用手机提交设备报修并拍照，而不是我们想做个报修系统。一句话验证目标定了，功能范围自动收窄：提交、拍照、有人看到——三件事够用；工单流转、派单调度、统计报表——和验证目标无关，全砍。没有时间盒压力，范围就会悄悄膨胀，最后做出来的是个四不像：既不是能验证假设的实验，又不是能用的产品。

二、两周节奏的完整拆解

2.1 头两天：假设细化与范围冻结

冲刺头两天做三件事。假设细化：把一句话假设拆成可度量的验证指标——用户会不会提交：目标三十天内二十个真实提交；提交质量如何：照片齐全率过半；有没有二次使用：同一用户提交两次以上占比三成。指标定量，验证才有裁判。范围冻结：列出原型必含的功能清单，逐项和验证指标挂钩——挂不上钩的进下期，本期不做。冻结后变更走特批：只有一种情况允许加需求——发现少了它验证目标无法达成。

2.2 第三到第九天：平台搭建期

七天的搭建期，低代码平台是主角。我们的分工：业务合伙人主搭——表单、流程、页面在平台上配置，他不写代码但最懂业务，配置的过程就是业务思路的落地过程；我做补件——平台覆盖不了的边角，比如一个定制的数据看板、一个外部接口对接，用少量代码补齐。七天的节奏：头两天主流程跑通——能提交、能看到；中间三天补真实感——真实的数据字段、真实的界面文案、真实的消息通知，糙可以，但要糙得可信；末两天内部试用加修错——团队五个人每人当一天用户，把明显反直觉的地方修掉。

2.3 第十到第十四天：投放与回收

末五天投放真实用户。投放渠道按业务定：设备报修那个原型，我们找了三家友好客户的车间，请维修工试用。回收两路数据：系统数据——提交量、照片齐全率、复用率，指标自动统计；访谈数据——每位试用者十五分钟，问三个问题：你会用它吗、哪里别扭、缺了什么你会放弃使用。两周截止日开复盘会：指标达标，假设成立，进入下一个验证循环或立项做正式版；指标不达标，假设证伪，归档复盘，团队转向。证伪不是失败——一次证伪省下的，可能是六个月的错误投入。

三、跑了两年的经验清单

3.1 原型的诚实原则

MVP 原型最大的伦理风险：演得太像正式品。有个教训：早期一个原型我们把界面做得太精致，用户以为是成品，试用后抱怨功能不全——验证没做成，倒惹了一肚子期待落差。从此立下诚实原则：投放时明说这是测试版，我们想验证什么、请帮什么忙——用户知道是实验，反馈反而更坦率：他们会说这个思路我不用，而不是客套地说挺好的。诚实的实验才有诚实的结论。

3.2 数据与访谈缺一不可

只看数据会误判：提交量达标，但访谈发现用户是为了帮我们忙才提交的——人情数据不是市场数据。只听访谈也会误判：用户嘴上说会用，实际打开率惨淡——意愿和行为是两回事。我们的规则：指标和访谈互为佐证，两边矛盾时，行为数据优先——嘴会客气，手很诚实。两路证据一起看，结论的含金量才够。

3.3 原型的报废预期

心态上最难的坎：接受原型是要报废的。团队辛苦七天搭的东西，验证完就归档，心疼是人之常情。我们定了两条消化心疼的规矩：验证通过的原型，配置资产入库——表单结构、流程设计沉淀为组件库，正式版复用率高；验证失败的原型，复盘文档入库——死在哪、为什么死，写清楚。两年下来，组件库攒了四十多个可复用配置，失败复盘文档三十多篇——前者加速未来，后者避坑未来，没有一个原型真的白做。

3.4 两周之外的节奏保护

节奏的敌人是打断。保护节奏的三条军规：冲刺期内需求冻结——老板自己提的想法也排队等下期，两周都等不了的想法多半不值得做；每日十分钟站会——只说进度和卡点，不展开讨论；复盘会限时一小时——结论清晰的事项不重议。军规护住的不是日历，是团队对节奏的信任——节奏一旦被随意打破，两周就成了橡皮筋，越拉越长。

四、这套节奏的适用边界

两周节奏不是万能钥匙，它的适用条件：验证对象是业务模式——用户会不会用、愿不愿意付钱、流程跑不跑得通；实现载体以信息流转为主——表单、流程、通知、统计，平台的甜区。不适用的场景：硬件结合的产品——设备采购调试的周期就超两周；核心算法的验证——算法的打磨周期长，先把算法外围跑通再单独迭代；强合规行业——审批周期不受你控制。认清边界，节奏才是加速器；越界硬套，节奏就变成绞索。

五、总结

两周一个 MVP 的节奏设计：一句话假设开头，验证指标定量，范围冻结砍掉一切无关；平台搭建七天，业务主搭技术补件，糙得可信是标准；投放五天，系统数据加用户访谈双路回收；复盘决策，成立则进，证伪则归档——配置入组件库，教训入复盘库。创业维艰，方向比努力金贵，两周节奏就是用工程化的纪律，把找方向的成本压到极低——试错快人一步，活得久人一分。

常见问题

问:两周做不完怎么办,延期还是砍范围?

答:一律砍范围，不延期。延期破坏的是节奏信誉——延期一次，下次大家就不信倒计时了。砍范围的方法：回到验证指标，问哪个功能是回答验证问题不可缺的——通常砍到只剩主流程都能达成验证;实在砍无可砍说明假设太大，把它拆成两个 MVP 分两期验证。两年里我们延期过零次，砍范围砍过十几次，回头看每次砍对的——砍掉的功能后来大多被证明不需要。

问:低代码搭的原型,转正式版要推倒重来吗?

答:不需要推倒，但要有心理预期：正式版不是原型的续集，是重写。我们的做法:配置资产复用——表单结构、字段设计、流程骨架直接搬;实现推倒重做——原型期的配置为了快,细节糙,正式版按生产标准重新配置,加上权限、审计、性能考量。经验数据:正式版从零做六周,基于原型资产做四周——省三分之一,不省一半。原型是实验品,转正是精装修,期待推倒或期待全留,都不对。

问:怎么找到愿意试用的种子用户?

答:三渠道轮着来:存量客户里挑关系好的——成本低,但要警惕人情数据,访谈时反复强调要真话;行业社群投放——给小激励,试用加十五分钟访谈,换一张购物卡;地推最笨但最真——维修工那个原型就是我们去车间蹲了三天现场拉的。种子用户的量不用大,二十个真实使用足够出结论——关键是真实,在真实场景里用,不是给你的朋友演示五分钟。

问:验证通过的判断标准,怎么定才不虚?

答:标准在立项时定死,写进文档,复盘时对着算,这是铁律。定标准的心法:用行为不用意愿——提交次数、复用率,别用满意吗这类态度题;用绝对数不用相对数——三十天二十个提交,而不是用户反馈良好;预设保底线和惊喜线——保底线达标算假设弱成立,继续小步验证,惊喜线达标才算强成立直接立项。标准前置,复盘时就吵不起来——数字对着预设线,达标与否一目了然,谁也别想事后圆场。