第 14 章 · 平台架构

引言#

业务里稳定存在的对象被看见以后，重复出现的动作会被进一步抽成能力。可当这些能力真正被抽出来，开始在同一块业务里一起工作时，新的问题也会随之出现。商品、库存、交易、履约这些能力，没有一个是孤立存在的，它们各自成立还不够，还要在同一套业务里相互解释、相互约束、相互支撑。到了这个阶段，产品经理面对的已经不只是某一个能力该怎么设计，而是这些能力放到一起以后，怎样才能真正支撑业务继续往前走。

很多产品经理走到这一层，很容易把答案直接落到“平台”上：业务要变化，就建一个平台；前台要快，就建一个中台；系统之间总要反复对接，就建一个开放平台。这些想法听起来都很合理，也符合组织里常见的语言，好像只要后台能力整理得更完整、接口开放得更多、配置做得更灵活，前台业务自然就会轻起来。真正做过以后会发现，事情没有这么顺。平台如果只是把已有系统包一层入口，前台业务不会因此变轻；如果只是把所有能力收进一个后台，系统可能越来越完整，业务反而越来越难理解；如果为了适配所有未来场景，把还没有稳定的变化提前做成配置，团队也不过是把原来散落在不同项目里的复杂度，搬进了一个更大的系统。

真正麻烦的是，当前台业务开始不断变化，越来越多能力又彼此牵动时，为什么原来各自都能工作的系统，放到一起却越来越难用？为什么一个新业务进来，总要重新拼一次链路？为什么系统明明都在，人却还要不断在中间搬数据、补关系、解释同一件事情？这一章要讨论的，不是中台怎么搭、开放平台怎么设计，而是这些问题出现以后，产品经理该从哪里开始看。平台很少是从一张蓝图开始的，更多时候，是一个具体的业务问题把旧方式逼到极限，平台才在那一刻被真正需要。

14.1 看见依赖——前台变化会不断拉动底层能力#

2022年底，我们服务的一条创新业务线发生战略调整，原来相对成熟的食品类工作逐步交回常规行业团队，团队把更多精力转向生鲜、水果、产地溯源和农村品牌等新方向。这条业务线过去比较擅长食品精品挖掘、社群爆品打造，也长期为主站提供商品和增长支持，所以调整之后，一部分业务仍然沿着过去熟悉的方式，通过社群、内容和运营能力继续面向消费者卖货；另一部分则开始尝试过去没有真正做过的事情：向大型连锁餐饮、茶饮品牌批量供应鲜果。这条路当时看起来并不冒进，鲜果本身就是茶饮和餐饮行业的大宗原料，采购频率高，头部品牌又有大量门店。如果能够稳定进入几个核心品类，理论上就有机会形成持续规模。公司过去也积累了供应商、基地和商品组织能力，仓储和供应链体系并不是从零开始，当时看起来，真正缺少的更多是适合连锁门店的履约能力。普通消费者买一箱水果，货从中心仓发出，通过快递送到个人手里，这条链路可以成立；连锁门店却需要每天或者隔天稳定补货，货晚了、规格错了、品质不稳，影响的不是一次收货体验，而可能是门店当天某款商品还能不能正常售卖。为了补上这一段，公司找到了一家在餐饮供应链领域经营多年的合作方，对方已经具备采购、仓储、区域分仓和城市配送能力。我们则更多提供上游货源、基地、商品和部分大客户资源，双方看起来刚好能够互补。

我当时负责公司的前台产品团队，也参与了这个项目早期的产品方案和模式搭建。项目一开始并没有“建设开放平台”这样的目标，摆在团队面前的问题其实很朴素：先找一家真正的大客户跑起来，看这门生意到底能不能做。第一家进入试跑的是一家全国性连锁茶饮品牌。选择这类客户的原因也很直接，茶饮品牌对鲜果需求量大、频率高，对品质和时效又足够敏感。如果这条链路能成立，既能比较快地验证我们的供应能力，也能帮助团队判断这条业务有没有继续拓展的空间。所以第一阶段我们做得很克制，没有一开始就追求完整的系统对接。货仍然先进入我们原有的区域中心仓，再根据品牌订单调拨到合作方的区域仓，之后进入各地前置仓，最后由合作方的城配网络送到门店。双方仓储系统只做了基础的货品映射和订单对接，库存还没有真正共享。单看这条流程，并没有明显走不通的地方：我们的系统知道货存在哪里，合作方的仓储和配送体系也能够完成后续分拨，订单最后确实可以送到门店。对于第一阶段来说，这已经足够，因为当时最需要验证的是业务模式，而不是先把系统做得多完整。

但真正开始跑货以后，原来在C端业务里并不明显的差异，很快被放大了。公司过去的供应链更接近面向消费者的“中心仓 + 快递”模式，而连锁餐饮需要的是持续、稳定的门店补货。第一版方案里，货要先进入我们的区域仓，再转到合作方区域仓，如果双方仓网不能完全重合，就会多出一段仓间运输。初期业务量又没有起来，这类运输很难形成稳定满载，成本自然被拉高。原本希望做到相对稳定的次日补货，实际往往需要更早下单。普通耐储商品可能只是晚一点到，鲜果却会把这一天甚至半天的差异迅速放大。草莓、浆果这类水果对成熟度和时效非常敏感，不同品类对温度、湿度、堆放方式也有不同要求。部分甚至需要催熟等专业处理，而我们原有仓储体系主要服务标准包装的电商品类，本身并不是围绕这些要求建立的。额外运输、仓间周转和仓储条件叠在一起以后，损耗开始上升，门店反馈也很快出现差异：一些耐储品类相对稳定，对时效和存储条件更敏感的水果，品质反馈明显更差。原来看起来只是多走了一段仓储和运输，放到鲜果业务里，却直接变成了品质和成本问题。

供应链这一侧开始暴露问题，品牌订货这一侧也没有想象中那么简单。合作方原本已经有一套支持多门店经营的SaaS商城，中小客户直接登录商城，按照里面的商品规格下单，这套方式一直可以正常运转。但大型连锁品牌本来就有自己的门店订货系统，不会因为增加一个供应商，就要求大量门店重新换一套订货工具。第一阶段又没有做双方系统的完整对接，中间缺掉的那一段只能先由人补上：品牌门店仍然在自己的系统里正常下单，总部再把订单明细导出来，大客户团队拿到以后，进入合作方对应的门店账号逐笔录入，订单才真正进入后面的仓储和配送体系。表面上看，这只是多了一道人工录单，真正做起来却远不止复制几个订单字段。品牌和合作方各有自己的商品编码和规格体系，同一种水果在双方系统里未必对应同一个SKU。品牌要的某种草莓，可能明确要求品种、等级、单果重量区间和整板重量，而合作方商城里可能同时存在几个看起来很接近、实际规格却不同的商品。大客户同学每次录单之前，都要先判断品牌订单里的商品到底应该对应内部的哪一个商品。一旦映射错了，系统甚至不会报错：订单可以正常创建，仓库可以正常出库，配送也可以正常完成，最后门店收到的却不是自己真正需要的原料。这类错误放到普通电商里，可能只是一次“货和预期不太一样”；放到连锁餐饮门店里，影响完全不同。门店做一杯标准化饮品，需要的不是“差不多的草莓”，而是符合品牌标准的原料。货送到了，不代表这张订单真的履约成功；系统里的流程全部走通，也不代表业务真的成立。

第一家客户试跑一个多月以后，这些问题开始集中出现。门店不断反馈货不对板、部分鲜果品质下降。取消订货、临时退货和改单也缺少稳定的线上链路，需要品牌、大客户团队、仓库和合作方在线下反复协调。这段时间，团队重新核算了仓储、仓间运输和鲜果损耗等成本，结果更加直接：按照第一版方式继续做，整体经济模型明显不成立。最开始，我们看到人工录单，会想到把订单接进来；看到鲜果周转时间太长，会想到优化仓间运输；看到商品容易选错，会想到把映射关系维护得更准确。这些都是真问题，但把它们放在一起以后，会发现它们并不是几个彼此独立的局部问题。前台只是增加了一种“大客户供货”的业务，背后却同时拉动了商品、库存、仓储、订单和履约。原有系统并不是不能用，而是它们原本就不是为了这一套新的业务关系组织在一起的。当新的业务把这些能力真正拉到同一条链路上，过去藏在系统边界里的依赖，也就全部浮了出来。

14.2 组织对象——先让业务对象稳定下来#

第一轮试跑里，最容易被看见的是人工导单、反复转仓和门店反馈，但继续往下看，会发现还有一个更底层的问题，藏在双方对“同一个商品”的不同理解里。品牌说的某个鲜果原料、合作方商城里的某个SKU、仓库实际管理的那一份货，在当时的业务里经常被当成同一件事情。规模不大、品类不多的时候，这种差异还可以靠人记、靠表格维护；一旦客户、区域和规格越来越多，人就很难继续兜住。合作方原来的体系里，“商品”和“货品”基本是绑在一起的，前台以什么规格卖，后台就按什么规格采购、入库和管理库存。这套方式在过去的自营业务里没有明显问题，因为卖什么、采什么、存什么，大多数时候是一致的。大客户业务进来以后，这个原本默认成立的前提开始失效。同一种水果，不同品牌可能有不同的销售标准，即使是同一个品牌，不同区域也可能有自己的规格要求。前台面对的是客户怎么购买，仓库真正管理的却始终是实际采购、存放和流转的那批货。

如果品牌每多一种规格，仓库就跟着拆出一份库存；每进入一个新区域，供应链又跟着维护一套新的实物规格，前台越灵活，后台反而会越来越乱。所以我们开始重新区分过去一直混在一起的两个对象：商品和货品。货品对应的是供应链里真正被采购、储存和流转的实物，采购了什么、仓库里有什么、库存有多少、成本是多少，以及后面的入库、出库、调拨、盘点和报损，都围绕货品发生；商品则是销售侧的表达，卖给谁、以什么规格卖、什么价格、怎么展示，可以随着客户、渠道和区域变化。这样一来，同一个货品可以对应多个商品SKU，不同品牌可以保留自己的销售规格，不同区域也可以有不同的商品表达。但仓储和库存不用跟着每一种销售方式反复拆分。销售怎么表达可以变，供应链真正管理的实物要尽量稳定。

这件事听起来只是把两个概念拆开，真正推动起来却没有那么容易，因为动的并不是一个页面或者一张表，而是一家运行多年的供应链公司一直以来理解商品、采购和库存的方式。我当时也不是合作方内部的产品负责人，如果只是站在项目角度告诉对方“为了以后平台化，我们应该做商货分离”，这件事大概率推不动。它最后能够真正往前走，是因为这个矛盾本来就不只存在于大客户项目里。合作方自己的运营团队希望前台可以根据不同城市和销售需要调整商品规格，供应链团队却希望仓库里的实物尽量稳定。过去商品和货品绑在一起，两边只能不断互相迁就。随着业务进入更多城市，前台商品规格越来越多，仓库要维护的规格也跟着膨胀，库存被拆得更碎，仓储复杂度和损耗都在上升。大客户业务只是把这个矛盾进一步放大：不同品牌有自己的商品标准，甚至同一种水果的等级和规格定义都可能不同。如果还要求品牌商品和仓库货品一一对应，客户接得越多，底层就会拆得越碎。

商货分离以后，另一个过去很少被认真讨论的前提也很快失效了。为了改善鲜果的新鲜度，同时降低仓间运输和损耗，最直接的做法是让供应商或者基地的货直接进入合作方区域仓，不再先进我们的仓库，再转到合作方仓库。业务上只是少走了一段路，系统里却多出了一个过去几乎不用考虑的问题：货进了我的仓，但这批货不一定属于我。这种货存放在合作方仓里、货权却仍然属于我们的模式，就是后来所说的代仓。合作方过去主要做自营采购，货进自己的仓以后，默认就是自己的库存，所以原来的库存可以简单理解成“仓库 + 货品”。但现在，同一个仓、同一个货品下面，既可能有合作方自己采购的货，也可能有属于我们的货，未来还可能有其他外部客户委托存放的货。仓库一样、货品一样，业务归属却不一样，原来的模型已经解释不了这件事了。于是系统里必须再出现一个对象：货主。库存也随之从“仓库 + 货品”，变成了“仓库 + 货品 + 货主 = 一份独立库存”。“货主”看起来只是多了一个维度，真正落到业务里，却绝不是库存表里增加一个字段那么简单。一旦系统承认“仓里的货不一定属于仓库经营方”，后面的入库、出库、退货、调拨、盘点、报损，甚至仓库现场的扫码作业，都必须知道自己正在操作的是谁的货。否则线上虽然写着这是某个货主的库存，到了仓库真正收货、出货和盘点时，实物和系统仍然会混在一起。那样的“货主”，只是系统里多了一个名字，并没有真正进入业务。

商品、货品和货主这些问题会接连出现，并不是因为我们突然想把系统做得更复杂，而是新的业务不断打破过去默认成立的前提。商品和货品没有分开时，销售规格一变，库存就要跟着变；货主不存在时，系统默认仓里的货都属于同一个主体。旧业务里，这些假设长期成立，所以很难感觉到它们的存在，一旦业务发生变化，对象之间原来模糊的边界才真正暴露出来。对象一旦说不清楚，前台每多一种变化，底层就只能跟着重新解释一次。

14.3 处理关系——不同系统要围绕同一套事实运转#

对象稳定下来以后，团队很快发现，这只解决了问题的一半。商品、货品、货主、库存各自有了边界，但真实业务从来不是一个对象一个对象单独发生的。一批货从基地进入仓库，再从仓库送到门店，中间会经历采购、入库、销售、调拨、盘点、报损等一连串动作。每一个动作都在改变对象的状态，而这些动作又不可能全部发生在同一个系统里。代仓模式真正跑起来以后，我们和合作方开始进入更深的协同，一个之前并不明显的问题也随之出现：同一个业务动作，指令可能从一个系统发出，真正的作业却在另一个系统完成，最终到底应该以谁为准？

最先暴露这个问题的是采购。上游货源、基地和采购计划更多在我们这一侧，所以采购指令会先从我们的系统发起，再同步到合作方；但货最终直接进入合作方的区域仓，真正的收货也在那里完成。计划采购100箱，仓库最后可能只实际收到98箱，如果还把采购单里的计划数量直接当成库存变化，系统里的账很快就会和仓库里的实物对不上。真正能够确认“这批货到底进来了多少”的，不是发出采购计划的系统，而是实际完成收货的仓库。计划可以从上游来，但库存事实必须回到收货现场确认。

类似的情况很快出现在更多业务动作里。采购退货可以由上游发起，但最终退走了多少，要看仓库实际出了多少；销售订单可以从前台产生，但最后真正出了多少货，也要回到仓库的实际作业结果；调拨可能由两边提出，但库存真正从一个仓转到另一个仓，只有两边的出入库都完成以后才算成立。盘点也是一样，任务可以由货主提出，也可以由仓库日常作业发起，但最后决定账实差异的，始终是现场盘出来的结果。鲜果退货还会更复杂一些，货退回仓库以后，品质可能已经发生变化，原来的等级甚至原来的SKU都未必还能继续使用。所以退回来的不只是一个数量，还可能伴随着品级和库存状态的变化。这些事情放到一起以后，一条原则慢慢清楚起来：业务指令可以来自不同系统，但真正的业务事实，要回到实际发生作业的地方确认。合作方之所以成为仓储和库存事实确认的一侧，不是因为它在架构图上的位置更核心，而是因为货真实存放在那里，收货、出库、盘点、报损这些动作也真实发生在那里。系统可以发计划、下指令，但计划不能替代已经发生的事实。

这看起来像是在讨论系统怎么分工，真正麻烦的其实不是“哪个字段归哪个系统”，而是一个事实到底在哪里发生，又由谁来确认。库存不是因为某个接口返回了一个数字才存在，它来自货真正进入仓库、被出库、被盘点或者被报损；配送状态也不是某个系统把“配送中”改成“已送达”就自然成立，而是货真的完成了配送并交到门店；退货也不是客户提交一次申请就结束了，还要看实物有没有回来，回来以后是什么状态，还能不能重新进入库存。如果只是把这些事情理解成数据同步，很容易出现一种情况：接口都通了，不同系统里也都有数据，但它们记录的已经不是同一件事情。

货主进入库存以后，这种关系会变得更加具体。过去仓里的货默认都是合作方自己的，一张单据通常只需要回答什么货、多少数量、在哪个仓；现在同一个仓库里可能同时存着不同货主的同一种货，每一次入库、出库、调拨、盘点和报损，都必须再回答一个问题：这次变化发生在谁的库存上。盘点少了两箱，少的是谁的库存；一批货从一个区域仓调到另一个区域仓，转移的又是谁名下的库存；退回来的鲜果发生降级，又应该从哪一份库存扣掉，再进入什么状态。对象虽然已经定义清楚，但只有这些动作都按照同一套规则去改变它们，系统里的库存、货权和仓库里的实物才可能一直对得上。对象之间的关系，不是架构图上的一根连线，而是在一次次真实业务动作里，谁发起、谁执行、谁确认，最后哪一个结果才算事实。

关系很多，也不意味着第一天就要全部做完。这个项目里，我们最先处理的是那些已经直接影响业务能不能稳定运行的部分：采购以后怎么确认实际入库，库存怎么变化，不同仓之间怎么调拨，盘点和报损怎么反馈，销售以后实际出了多少货，配送最终到了什么状态。至于一些低频，或者上游本身还没有稳定下来的动作，并没有一开始就全部系统化。比如采购逆向频率不高，初期通过线下单据仍然能够承接；品牌侧的售后当时也有不少动作发生在线下，上游连稳定的退货入口都还没有形成，供应链一侧提前把整套逆向流程做完，也未必真正用得起来。有些关系如果还需要不同团队反复核对，业务量一大，错误就会被迅速放大；而那些低频、人工仍然能够稳定承接的动作，没有必要第一时间全部搬进系统。系统可以承担不同的职责，但同一件业务事实，不能在不同系统里各有一个答案。

14.4 守住边界——统一的不是所有业务做法#

供应链这一侧逐渐稳定以后，品牌侧的人工对接也到了必须改变的时候。第一家客户刚开始试跑时，订单量还不算大，大客户团队还能靠人工把品牌订单录进合作方的系统；但随着门店订货频率提高、品类增加，这种方式很快就撑不住了。后面接触的一些连锁品牌，本身也已经有成熟的门店经营和订货系统，对系统对接有明确要求。到了这个阶段，如果还继续靠人在两个系统之间搬数据，业务很难真正扩大。真正开始做对接以后我们才发现，所谓“把订单接进来”，其实只是最表面的一步。品牌有自己的商品、门店、供应商和订单体系，供应链内部也有自己的商品、库存、订单和履约规则。一张订单要真正从品牌系统走到仓库和配送，中间还要解决商品怎么对应、门店怎么对应、库存能不能满足、这张订单能不能履约，以及后面的状态怎么返回。表面上接进来的是一张订单，真正需要接起来的，却是两套已经运行多年的业务体系。

这时候最容易想到的办法，是让品牌尽量按照我们的规则来。既然要接系统，商品就使用我们的编码，门店换成我们的编码，供应商、订单号甚至一些状态定义也尽量向内部靠。站在自己这一侧看，这当然最省事，接口也最容易做得整齐。但真正和大型品牌合作以后，这条路基本走不通。它们有的使用自研系统，有的使用成熟的第三方系统。商品编码、门店编码、供应商编码和订货规则早已经嵌进日常经营，不可能因为增加一家供应商，就把原来的体系重新改一遍。如果每接一家客户，都要求对方先适应我们的规则，看起来很“统一”，实际上只是把原本应该由我们处理的复杂度推给了客户。

后来我们的选择，是让品牌继续使用自己的业务语言。品牌传过来的仍然是自己的商品编码、门店编码、供应商编码和订单编号，我们在中间维护这些信息和内部对象之间的对应关系。品牌的一种商品进来以后，要知道内部对应的是哪个商品、最终落到哪个货品；品牌自己的门店编号，要能够找到真正负责履约的内部门店；外部订单号也要一直保留下来，这样出了异常以后，双方才能确认说的是不是同一张订单。品牌不用为了合作改变自己已经稳定运行的系统，内部的订单、仓储和配送体系，也不用因为每来一家客户就重新改一遍。真正需要统一的，是双方发生连接时的规则，而不是所有人的业务做法。

也是从这个时候开始，后来那一层真正意义上的开放平台才逐渐有了形状。我们没有因为要服务大型品牌，就重新做一套订单、仓储和配送系统，那些系统本来就在真实业务里长期运行。真正需要补的，是外部业务怎样进入它们。品牌的请求进来以后，先确认是谁、有没有相应权限，再把外部的商品、门店等信息转换成内部能够识别的对象。按照已有规则判断库存和履约条件，符合要求以后，再进入后面的订单、仓储和配送体系。不同客户需要的东西也不完全一样，有的只是直供，有的还涉及代仓，有的会进一步牵动采购和调拨。它们不需要走完全相同的业务流程，开放平台做的，是让这些不同场景能够接入已经稳定下来的能力，而不是每接一家客户就再造一套后台。

同样，也不是所有能做成接口、能搬到线上的事情，都要马上做进去。品牌商品的创建和修改并不高频，早期由业务人员维护就能承接；报价仍然可以通过线下商务流程确认；品牌侧的逆向退货和售后还有不少动作发生在线下，上游流程本身都没有稳定下来，供应链一侧提前把接口做得再完整，也不会让业务自然变顺。真正需要优先线上化的，是那些已经反复发生、继续靠人处理就会限制客户接入的部分。边界不是把所有事情都挡在外面，而是知道什么已经必须由系统接住，什么暂时留在人手里反而更合适。

14.5 支撑前台——让业务变轻，而不是让系统变大#

第一家客户试跑的时候，大客户团队大量时间花在人工录单、核对商品、改单和异常协调上。随着原来需要人反复确认的关系逐渐进入系统，大客户团队才慢慢从这些工作里退出来，把更多精力放回客户经营：最近的履约是不是稳定，哪些品类还有机会，门店反馈集中在哪里，合作还有没有继续扩大的空间。平台真正让业务变轻，不只是少了几次人工操作，而是人不再长期站在系统之间维持业务。

这种变化到了后面接入新的客户时更加明显。第一家品牌进来的时候，很多事情几乎都要从头讨论：商品怎么对应，门店怎么识别，货放在哪里，库存算谁的，订单怎么进入供应链，仓库怎么履约，配送结果怎么返回。等这些问题逐渐稳定下来以后，后面的客户再进来，产品团队面对的已经不再是一张白纸。更多时候，我们是在判断它属于哪一种业务场景：只需要直供，还是还涉及代仓；采购由谁负责，要不要发生调拨；现有能力里哪些可以直接使用，真正新增的差异又在哪里。后续客户的接入周期因此明显缩短，但比少花多少时间更重要的是，产品工作从“重新设计一条业务链路”，逐渐变成了“在已有能力上组合新的方案”。

不过，前台变轻并不意味着前台提出什么，平台都应该答应。随着客户类型越来越多，我们也开始遇到一些看起来很自然的新需求。有客户希望在代仓之外进一步提供代采，既然已经有供应商、基地和采购系统，看起来似乎只要把采购能力再往外开放一步。但真正往下拆，会发现这里涉及采购主体、供应商关系、价格、结算、品控和采购责任。这已经是在建立一种新的供应链业务，而不是多做几个接口能够解决的问题。

代配又是另一种情况。有些品牌自己有仓库，只希望直接使用合作方已经成熟的城市配送能力。从技术上看，这件事并非做不到，配送系统和运力也已经存在，可司机有多少、线路怎么排、车次怎么安排，都有自己的承载上限。如果大量外部订单直接进入，配送区域、时间和订单峰谷又由客户决定，就可能反过来挤占原有业务的运力。这个时候真正要判断的，已经不是系统能不能支持，而是这项能力交出去以后，业务愿不愿意承担随之而来的代价。能力存在，不代表能力就应该开放。

截单时间也是类似的问题。品牌自己的订货系统可以允许门店更晚下单，接口也完全可以继续接收订单，但供应链为了保证第二天完成分拣和配送，会有自己的作业节奏。订单到了系统里，不代表仓库还有时间准备；接口返回成功，也不等于第二天一定能把货送到。第一阶段，这类订单只能返回失败。后来随着预测、补货和仓内作业能力逐渐改善，可以承接的范围自然会扩大，但那是底层能力真的发生了变化。平台可以连接能力，但不能替能力本身完成进化。

如果只看这个项目最后形成的架构，会看到客户接入、开放治理、订单、库存、仓储、配送等能力逐渐被组织到一起，也会看到一套相对完整的开放平台。但对前台来说，真正重要的不是后台最后画成了什么样，而是新的客户和新的业务进来以后，很多已经解决过的问题不需要再重新讨论。平台最终要证明的，不是后台是不是越来越完整，而是下一次业务再变化的时候，我们是不是已经不需要再从头来一次。

闲言碎语#

做产品这些年，我发现“平台化”是一个很容易让人兴奋的词。它听起来比做一个功能更大，也更有长期价值。尤其是业务越来越复杂、系统越来越多的时候，我们很容易觉得，只要把问题再往上抽一层，做成一个平台，很多事情就会被一次解决。我自己以前也挺容易被这种感觉吸引：看到几个系统之间反复对接，会想是不是应该统一起来；看到同一件事情做了几遍，也会很快想到要不要抽成公共能力。经验越多，这种答案往往来得越快，因为脑子里已经见过很多类似的系统，甚至业务刚讲到一半，一张架构图就已经差不多出来了。

后来我不断提醒自己在项目刚开始的时候要少说“我们要做个平台”。不是这个词有问题，而是名字一旦先立住，团队很容易开始反过来补一个“平台应该有的东西”：统一入口要不要有，权限是不是要一次设计完整，接口是不是应该全部开放，未来可能出现的场景是不是现在就要留好位置。慢慢地，原本要解决的业务问题反而退到了后面。这些年行业里对中台和平台化的很多反思，说到底绕不开的也是同一个问题：先立了平台的名，再去找它解决的问题。现在再碰到类似的事情，我更愿意先把那个大词放一放。先看原来的方式到底哪里撑不住，再看眼前的改变有没有解决它。最后长出来的是一套平台，还是只改清楚了一个对象、接通了一段关系，其实没有那么重要。