别搭积木了：聊聊技术中台构建的踩坑教训

说实话，上个月刚在南京江宁的产业园里，帮朋友收拾完技术中台的烂摊子。

朋友公司老板一年前听了一场行业峰会，拍板砸了两百万招团队搭中台，说要降本提效。现在钱花完了，原来的开发团队怨声载道，新业务上线速度反而比之前慢了一半。

这样的事，我见得真不少。中台火了快十年，搭成烂尾的，比搭成能用的多太多了。

为什么很多公司搭技术中台，搭着搭着就偏了

很多人从根上就理解错了技术中台是什么。一听「中台」两个字，就觉得是把所有分散在业务线的技术能力全部收上来，攒一个大而全的中央仓库，统一管理就是中台了。

我朋友他们公司就是这么干的。原来三条业务线，各自做用户体系，各自做支付接口，领导一声令下，全部打散重构，合并成一个统一的中台用户中心。结果合并完才发现，三条业务线的用户逻辑天差地别：To C的业务要openid授权，To B的业务要企业域账号登录，还有一条经销商业务要两层权限认证，为了兼容三套逻辑，中台的代码写得跟乱麻一样，改一个小需求，牵一发动全身，测试要测一周。

业务线的开发要改点东西，得给中台团队提需求排期，快则两周慢则一月，原来自己改两小时的事，现在等半个月。换谁谁不骂？

本质问题就是，为了中台而中台，把手段当成了目标。我们搭中台是为了省力气，不是为了搞统一KPI。

技术中台构建，核心其实是搭「共享插座」

我个人特别喜欢这个类比。技术中台从来不是建什么「中央集权大楼」，把所有水电都锁在楼里，要用什么都得上来申请。它其实是商场装修的时候提前铺好的统一标准化插座，你开奶茶店也好，开服装店也好，不用自己拉电线找变压器，插上去就能用，出了问题找物业修，省心。

之前认识南京一家做生鲜配送的技术负责人，他们中台搭得就舒服。一开始公司三个业务线：To C的配送到家APP，To B的食材批发，还有企业团餐，三个线都要做地址解析、骑手动态派单，每个线都重新写一遍逻辑，改一次需求三个团队一起改，光人力浪费就够头疼。

他们没搞大动作，就先把这两个能力抽出来，做成标准化的中台服务，封装好接口，权限给三个业务线开好，谁要用直接调用。改需求的时候中台改一次，三个线直接用更新，省了至少两个开发的人力，爽得很。后来慢慢又抽了用户标签、图片预处理这些重复度高的能力，一步步做大，从来没强行收过业务线的权。

说白了，技术中台的本质就是可复用技术能力的标准化服务集合，你哪里疼就先治哪里，哪块重复造轮子造得最多，就先抽哪块，别上来就想着一口吃成胖子。

技术中台构建不能碰的三个隐形红线

踩了这些，哪怕你架构画得再漂亮，最后也大概率成烂尾。

第一个红线，就是越界管不该管的事。中台是服务部门，不是管理部门，别把业务线的个性化逻辑强行往中台风塞。我见过最离谱的，把某个业务线专属的大促营销逻辑都塞进去，结果中台改一次，其他所有不相关的业务都得跟着回归测试，平白多出一堆工作量。记住了：通用能力放中台，个性化逻辑放业务线，边界清了，大家都舒服。

第二个红线，上来就追求完美大中台。不少公司中台团队招了二三十人，先画六个月架构图，做一年多基础设施，等第一个可复用服务上线的时候，公司业务方向都换了，之前的设计全白费。这不纯纯浪费钱吗？中台可以小步快跑，先解决最痛的那一个问题，上线跑通了，用得好了，再慢慢加能力，比啥都强。

第三个红线，搭完就不管，当成一锤子买卖。很多公司抽完代码，扔在git仓库就完事了，没人维护，没人更文档，接口不兼容了也没人管，出了bug找不到人背锅。用两次之后，业务线开发嫌坑，自然而然就回去自己造轮子了，中台慢慢就变成了没人碰的僵尸项目。中台既然是服务，就得有对应的维护团队，持续迭代更新，这才是能用的中台。

不过话说回来，技术中台也不是什么银弹，不是所有公司都得搭。如果你就一条业务线，几十个人开发，每天改需求都来不及，重复造轮子的地方没几个，凑这个热闹干嘛？老老实实把业务做好比啥都强。

我那个南京朋友最后怎么收拾烂摊子的？把原来大而全的中台拆了，只留了用户认证和支付两个所有人都要用的通用服务，其他乱七八糟的全都还给业务线，现在新业务上线速度直接提了三倍，开发们终于不吐槽了。

其实哪有那么多玄乎的方法论，技术中台构建本来就是解决自己公司的问题，不是搭给投资人看的PPT，也不是拿来吹牛的谈资。合适比完美重要，解决问题比赶风口重要。这就够了。