先做个最小版本，跑通再扩大——这句话老板们都熟，但十个有九个理解跑偏：拿着功能清单砍到只剩商品列表加下单按钮，上线才发现收不了款、退不了货。这篇给三个判断条件，把做多小、保留什么、什么时候扩大讲清楚。

"先做个最小版本，跑通再扩大。"

这句话老板们都很熟，但理解经常跑偏。

跑偏的样子是这样的：拿着功能清单，砍砍砍，砍到只剩个商品列表加个下单按钮，觉得这就是最小版本了。上线当天发现收不了款，客户下单了钱没到账，后台连个退款入口都没有。所谓"先跑通"，压根没跑通。

错在哪？错在把"最小"理解成了"砍功能"。真正的做法是反过来——最小版本不是砍功能，是保留完整成交链路，只砍不必要功能。

一字之差，差在生死。

你到底要验证什么，先答这一句

做最小版本之前，先回答一个问题：你做它，是想验证什么？答案不同，版本大小完全不同。

一类是验证"有没有人买"。你想知道这个品、这个价、这个卖法，市场上有没有人掏钱。这种情况，一个能收款的轻量链路就够——商品页、下单、支付、订单，四件事，别的都可以不要。跑三个月，意义就是看成交数字，数字说话。

另一类是验证"交易流程稳不稳"。你要上的是长期生意，想知道支付会不会出错、对账对不对得上、售后扛不扛得住。这种情况，功能可以少，但流程一个不能省——支付回调、库存扣减、退款原路返回、每日对账，全都要真跑起来。你用一个月专门压这个，比上线后再出事故便宜得多。

还有一类是验证"某个功能有没有效果"，比如想试分销、试会员体系。这种更简单，版本就是"核心交易加这个功能"，其他照旧最小。

有个调查挺说明问题：一大半的店老板，一开始是用个人经验判断生意能不能做，而不是先做个产品去验证。这说明什么？说明很多人连"验证"这个动作都省了，直接奔着"做完整"去，一错错一年。想不清楚验证什么，就先别定版本大小，先做需求澄清。

成交链路里的节点，一个都不能砍

这是最小版本的分水岭。判断标准就一句：成交链路里的关键节点，一个都不能砍。

支付接入。没有支付，整个系统就是展示页。支付还牵扯资质——小程序要申请微信支付商户号，走注册认证、提交商户号、签约验证、绑定、配置参数、联调、上线这套流程，普通商家资料齐全一般三到七个工作日。个人主体还有支付限额，月支付额度十万封顶。这些前置条件，做版本规划时就要算进去，别等到上线才发现资质没办。

订单。订单是交易的主线。下单、支付成功、待发货、已发货、完成、售后，这些状态必须能流转。状态机要写死——从支付成功只能进待发货，不能直接跳完成。行业里支付状态有明确的终态定义：支付成功、已关闭、转入退款，三个终态定死，流程才有边界。

履约。客户付了钱，你得能发货、能交付。线下自提的要有自提核销，物流发货的要对接单号。履约断了，钱收了货不到，客诉直接爆炸。

退款售后。这个最容易砍，也最不能砍。退款是信任的底线——客户申请退款，你要有流程处理、有钱原路退回。没有退款入口的系统，客户不敢下单，转化率先死一半。退款还要跟支付对账联动，退了多少钱、在途多少、结算多少，账要清楚。待发货订单怎么取消退款、已发货订单怎么走退货、退款多久到账、失败怎么重试，每一条都要在设计阶段定死。

对账。每天的钱和单对不上，你都不知道自己亏在哪。最小版本可以没有花哨的数据看板，但每日对账不能少——拉支付平台账单，跟本地订单比对，差额标出来人工看。逻辑不复杂：当日支付成功的订单金额合计，应该等于支付平台账单的收款合计；当日退款合计，应该等于账单的退款合计。两边一比对，平了账就干净；不平，差额标红人工查。这事一天都不能断，断了三天，错在哪一笔就找不回来了。

有人问：这些都要，那还是最小版本吗？答案是：这就是最小版本。成交链路完整是"能跑通"的定义，不是"功能多"。砍了支付、退款、对账的版本，不是最小版本，是半成品。

哪些能砍，哪些不能，拿这把尺子量

链路保住了，剩下的才是砍的范畴。给你一份参考分法。

必须保留：商品展示（含库存）、购物车、下单、支付、订单中心、售后退款、每日对账、后台订单处理。这八样一个都不能少——它们是"跑通"的定义。

可以延后：会员体系的等级、积分、成长值，没有它生意照做，只是复购运营少了着力点；分销拼团涉及多级关系和资金分账，复杂度高，验证阶段先别碰；直播短视频重运营重投入，跟最小验证的初衷冲突；复杂营销先上一种最简单的新人券，验证够了再丰富；智能推荐需要数据积累，新平台没数据，上了也是摆设。

砍的原则就一条：砍掉的是"没有也能成交"的功能，保留的是"缺了就无法成交"的功能。拿这个尺子量，砍什么都清楚。再补一个辅助问法：把每个候选功能问一句"它直接帮助成交吗"。商品、购物车、支付——直接，保留；会员积分——间接，延后；直播带货——很远，延后。回答不了"直接帮助成交"的功能，一律进二期。这不是说它们没用，是说它们不构成"跑通"的一部分。体验是在成交跑通之后慢慢补的，顺序别搞反。

一期不返工，架构留三个口子

最小版本最容易踩的坑是：为了快，一期代码写得乱，二期加功能时全部推倒重来——省下的时间翻倍还回去。

不返工的关键，在架构设计时留三个口子。一是模块化拆分，商品、订单、支付、会员、营销按模块分开，一期只做前四个模块的完整版，会员和营销留接口不实现，二期加功能是新模块的事，不碰旧模块。二是数据模型留扩展位，商品表预留促销关联的字段位，订单表预留活动来源的字段位，用户表预留标签的字段位——字段不占多少空间，但二期要加促销、加分销时不用改表结构，改表结构是迁移里最贵的事。三是配置化优先，优惠、提醒、触达这些规则做成后台可配置，不写死在代码里。

选型太超前，一上来就上微服务、上分布式，一期成本翻倍，不值；选型太凑合，所有逻辑塞一个文件，二期全重写，更贵。中间那个度，就是"模块拆分加扩展位加配置化"。

什么时候扩大：看三个指标，不看时间

最小版本跑起来之后，老板最爱问：什么时候扩大？错误答案是三个月后。正确答法是看三个指标。

成单量。持续稳定地达成一个你预期的数字——比如连续四周每周成单量都在涨，或者稳定在某个能覆盖运营成本的量级。这说明"有人买"验证通过了。

复购率。买过的人里，有多少回来了。复购率开始稳定并往上走，说明生意有了黏性，这时候扩会员、扩营销，弹药才打得出去。复购率还是零的，先别扩，先想为什么客户不来第二次。

客诉率。退款率、投诉率是否可控。客诉率高，说明链路有问题，这时候不但不该扩，该回头修——拿不稳定的系统去扩大流量，等于把问题放大十倍。

三个指标的关系：成单量证明有市场，复购率证明有黏性，客诉率证明链路稳。三样齐了，扩大才安全。什么情况该暂缓？验证目标没定清、连最小成交链路的预算和资质都没有、指标没到就硬扩——这三样占一样，先别扩，把前面的功课补上。

扩大还有一个动作要做：每扩一步，做一个可验收的节点。扩会员，就盯会员转化率和复购率提升；扩分销，就盯分销贡献的订单占比。每步都能验收，扩大才是受控的，不是赌博。有人会问：指标达标了但预算不够怎么办？答案不是硬扩，是压缩扩大范围——复购率在涨但客诉多，先修售后而不是加营销；成单量在涨但新客占比低，先上拉新活动而不是加会员等级。扩大不是全上，是数据最需要哪个就补哪个。

落到行动，就四步

把这篇收成四步。

第一步，写下你的验证目标——到底验证"有人买"还是"流程稳"，一句话说清。第二步，对一对最小清单——商品、购物车、下单、支付、订单、售后、对账，八个节点一个不少；会员、分销、直播、复杂营销，全部延后。第三步，把支付接入资质、小程序认证这些前置条件先办了——它们卡着上线时间。第四步，设三个扩大信号——成单量持续达标、复购率稳定、客诉率可控，三样齐了再扩。

最小版本的本质，不是"做个小东西试试"，是"用最小的成本，验证最关键的假设"。关键假设就一个：这条成交链路，有没有人愿意走完。验证它，链路一个节点不能砍；砍功能，只砍链路之外的东西。想清楚这两句，最小版本就不会做歪，扩大也不会踩空。