ReaderMX.
四海内皆兄弟

从「中台玄学」到 AI Coding我们又在重复同一个剧本

四薛晓刚约 3 分钟
前几年技术圈有个玄学，叫中台。
这个故事很多老架构师都听过：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 这一波，未来大概率也会是同样的剧本。
Image

KEEP THE THREAD GOING

更多来源文章