荒谬的中台逻辑

大中台，小前台，是前几年由阿里首创同时被业界纷纷效仿的架构理念。最近，由阿里一拆六开始，去中台运动又如火如荼的展开了。中台，or 去众台，到底哪种才是合理的架构？

要说清楚到底要不要构建中台战略，首先要追问一下到底什么是中台。其实，中台也没有一个明确的定义。就算是阿里这种搞了十几年中台的公司，中台的范围也是忽大忽小的，就犹如橡皮泥一样，随着一号位的变迁有着各种的解读。但是，中台概念的来源，似乎是有迹可循的。这里面有两个传说。第一就是美军的中台概念：将前线作战部队规模由师旅级别降低到营团级别，通过后台火力打击群的配合，提升作战的效率。另一个就是 Supercell 这家游戏公司，采用的就是大中台小前台的模式，后台大量沉淀通用素材和算法，让前台开发游戏的时候效率大大提升，同时在孙 XX 的牵头下，将这种成功的“模式”无缝的移植到了中国的互联网企业。

这两个例子似乎都体现出了中台模式的巨大魔力：通过构建成熟可靠的中台支撑能力，可以大大提升前台业务的构建速度，降低构建成本，同时提升灵活性。这简直就是各大互联网公司梦寐以求的场景。但是，这两个例子和互联网或者商业领域是否完全契合呢？

首先是军队的例子，这个是明显的行政命令式的中台模式，这个和各大厂推广中台的模式简直如出一辙。但是，命令式中台成立的条件，首先要满足非选择性。军队有什么样的火力可用，是一个国家的国力决定的，前台的战斗部无从选择的有什么用什么。但是，商业领域是这样的么？如果外部有更好的解决方案，为什么要用内部的行政命令式中台战略呢？

回到 Supercell 的例子，这个例子其实有两个制约条件：首先这个公司规模很小就几十人，业务也很小才推出几款游戏，恰巧有一个爆款所以成名而已。他的中台模式，说白了就是一个小作坊技术积累方案。大家在日常开发的过程中，C 语言时代会用 ACE，java 时代会用 spring，云原生时代会用 SpringCloud，AI 时代会用各种 GPT，道理都是一样的，都是一个类库复用的思想。但是要走到一种业务切割和系统委托模式，就没有这么简单了。

所以，两个例子并不能证明中台模式的必然合理性。只是中台的魔咒，让人欲罢不能而已。国内大厂因人推中台，强行推中台的模式，势必陷入计划经济的陷阱：

• 中台脱离业务：一个被行政命令必须使用的平台，有什么动力去了解市场了解前线的需求呢？自然是上面说做什么就做什么，说怎么做就怎么做。像极了五六十年代计划经济的模式，上面一个指挥棒，下面一堆王进喜。

• 中台拖慢业务：一个脱离业务闭门造车的中台，同时还需要服务多个方面的业务诉求，最终的结果一定是收集需求->PK 优先级->闭门开发->强行推广的死循环。前线的业务需求，传递到中台实施需要漫长的报告流程，中台实施完到满足前线需求又是一个漫长的沟通加汇报的流程。这个效率岂能不低？

• 中台阻碍竞争：所谓的破坏性创新，一个更好的解决方案，一定是跳出原有方案设计，通过零基思维得到的第二曲线。但是在中台的模式下，所有的破坏性创新，都会因为不符合中台的产品思维逻辑而胎死腹中。小而美的创新永远和大而笨的中台模式格格不入。

要脱离计划经济的陷阱，50 年前就已经有人给出答案了：就是市场经济。其实也就是进化论的观点，是骡子是马拉出来溜溜，能活就活下去，不行早死早超生。

• 破除行政命令的模式：哪里做得好，就把哪里的产品共享。将通过成分验证的好东西共享出来，而不是硬要造一些垃圾出来共享。如果共享之后退步了，那就不要在赖在现有的地位上。

• 引入竞争机制：一个产品，不是一个团队的专利。内部团队的重复建设，或者从外部的采购，都可以构成竞争。有了竞争机制，才能形成优胜劣汰的氛围，产生良性的进化机制，防止退化的发生。

• 用钱说话，用脚投票：更极致的，可以将中台组建推向市场，就犹如 Oceanbase 做的那样，让外部的客户用钱来投票，让内部的部门用脚来投票。好就是好，可以赚的盆满钵满；烂就是烂，该破产就破产，该离职就离职。

总之，中台不中台不是关键，有竞争优胜劣汰才是共享服务应有的模式。