从「中台玄学」到 AI Coding

我们又在重复同一个剧本

————

前几年技术圈有个玄学，叫 中台 。

这个故事很多老架构师都听过：2015 年，马云带着一众高管跑到芬兰赫尔辛基，拜访手游公司 Supercell，就是做出《部落冲突》《海岛奇兵》那家。

这家公司非常魔幻，全公司不到 200 人，一个开发小组也就 2-7 个人，他们叫 Cell，细胞小组。靠着一套沉淀好的素材、引擎、算法中台，小团队几周就能搓出一款游戏上线公测；玩家不买账，直接砍项目，失败了甚至开香槟庆祝踩坑。试错极快，爆品频出，人效高到吓人。

不到 200 人 · 2-7 人一个 Cell

几周搓出一款游戏上线公测，玩家不买账就砍

失败了开香槟庆祝踩坑 —— 试错极快，爆品频出

一行人看完大受震撼。回来之后阿里正式启动「大中台、小前台」战略，张勇牵头落地。

PART 01

中台从出生起，就自带一层朦胧滤镜

圈内还流传一个名场面：团队把中台方案汇报给马云，听完之后马云说，你们做出来的东西，大概只理解了我想法里的 80%。

「你们做出来的东西，大概只理解了我想法里的 80%。」

这句话后来就成了中台玄学的经典注脚：老板脑子里有个感觉，下面人努力落地，最后出来的版本，和初心还差一截。

所以你看，中台从出生那一刻起，就自带一层朦胧滤镜。滤镜一旦传开，国内的跟风潮就刹不住车了。

中台的初衷本来很简单： 沉淀通用能力，避免重复造轮子，给前台小团队提速试错。

但大家只看见「阿里做中台火了」，看不见 Supercell 的业务底色，于是一股脑开始抄作业。

PART 02

抄作业，抄出了一地分布式事务

很多企业，原本好好一个数据库，为了微服务，硬生生拆成十个库；为了中台，强行按表属性拆分，跨库调用满天飞，依赖缠成乱麻。

拆完之后，敏捷没等来，等来的是：

✕ 一堆分布式事务

✕ 一致性问题

✕ 联调的坑

人家是 轻业务、高频试错 的场景，你是 重业务、长周期、强合规 的传统企业，照样照猫画虎。

还有一个词， 敏捷开发 。

好像不知道从什么时候开始，敏捷成了政治正确，仿佛不敏捷就是技术落后。但这个世界不是所有业务都适合两周一个迭代。

有些 ToB 业务、工业、供应链、核心系统，本身业务评审、需求确认、验收流程摆在那里，天然就是两个月甚至更久一个版本。你硬套敏捷，最后只会变成形式主义的站会、看板，徒增内耗，效率反而往下掉。

PART 03

历史总是押韵：AI Coding 是同一个剧本

AI 写代码，对单个程序员来说，确实提效了。CRUD、样板代码、简单查询，敲字速度肉眼可见变快。

但是放大到整个团队、整个企业呢？

大量团队的真实现状： 编码快了，需求扯皮、方案评审、联调、测试、线上故障一点没少。

整体交付效率并没有质变，更谈不上帮企业多赚钱。

翻来覆去看下来，目前 AI Coding 真正跑出正向营收红利的，居然还是 游戏行业 。

评判标准极度简单直接

玩家用脚投票。不用讨好一堆内部干系人，不用层层审批对齐。好玩就是爆款，不好玩直接砍掉重来。

周期被压缩到极 致

以前两个月磨一款，现在借助 AI 素材、AI 生成逻辑，一周就能出版本去市场验证。这种高频试错、快速淘汰的模式，刚好踩中 AI 的优势。

道理和当年 Supercell 中台能跑通一模一样。

PART 04

扎心的结论：它们都不是普适解药

不管是中台，还是现在火热的 AI 生成代码，它们都不是普适解药。它们的舒适区，高度集中在泛游戏这类场景：

轻资产　·　短周期　·　强市场反馈　·　允许快速失败

换到别的赛道，AI 最多帮程序员省一点敲代码的时间；想靠它直接拉动业务营收、降本增效，大概率要失望。

没有互联网的命

得了互联网的病

看见别人微服务、中台、AI 提效，就焦虑，就上马。

架构和工具永远是服务场景的，而不是用来追赶潮流、装点 PPT 的。适合别人的加速器，拿到你这里，说不定就是个沉重的包袱。

中台浪潮退去之后我们已经看到，不少公司把大中台拆回、业务回归前台； AI 这一波，未来大概率也会是同样的剧本。

工具很好，但别神化

先想清楚：你的业务，配不配高频试错？能不能接受失败？

想不明白这点，盲目跟风，最后所有的架构改造、AI 投入

都只会变成一场热闹又昂贵的自我感动