今天下午和老板吃饭，聊到一个我最近一直在反复想的问题：AI 时代，中台到底应该怎么给前台做产品？
这个问题对我来说不是一个抽象命题。我自己就在大厂做中后台团队，也在金融集团的数据部门里做面向业务的产品。过去我写过一篇文章，说 AI 时代来了以后，中台给前台做产品会越来越难。原因是，过去中台最大的优势之一是规模化，前台重复造轮子的成本太高，所以中台把共性能力沉淀下来，做成统一产品，提供给多个业务使用。
但 AI 让这件事发生了变化。做一个东西变容易了，前台业务可以自己上手做一些过去本应由中台提供的类 SaaS 产品，而且做得很快，和自己的业务上下文贴得很近。所以我当时的判断是：中台做产品会越来越难。后来我又补了一句：AI 时代，做东西越来越容易，但做出能给别人用的东西越来越难。
今天和老板聊完，我觉得这个问题还可以再往前走一步。
一个真实的例子
我们最近做广告投放平台时，遇到了这个问题。平台里有一个模块叫智能回传，一开始是给证券业务做的。证券做完以后，理财平台团队也需要。
按照传统中台思路，接下来会进入一套很熟悉的讨论：要不要做成公共产品？证券和理财怎么隔离？未来信用卡来了怎么办？哪些字段可以抽象，哪些规则可以配置，哪些流程可以统一？
这些问题看起来都很专业，也很中台。但它们会把事情带进另一种复杂度里。因为只要开始追求统一产品，就一定要提前考虑未来，未来有哪些业务会接入，未来有哪些差异会出现，未来哪些字段要兼容。问题是，很多未来根本没有发生。为了一个还没发生的业务差异，我们在今天增加一层抽象；为了一个可能出现的场景，我们在今天增加一套配置；为了让所有人都能用，我们让当下真正要用的人先忍一忍。
于是排期变长了，方案变重了，体验变远了。
我们在智能回传这个模块上摸索了一两个月，走了不少弯路。后来我发现，问题可能不在于设计得不够好，而在于一开始就问错了问题，我们默认了一个前提：既然多个业务都要，中台就应该做一个统一产品。
但为什么一定要这样？为什么不能中台给证券做一个，理财来了再给理财做一个，信用卡来了再给信用卡做一个？这些产品可以长得很像，也可以共享底层能力和建设经验，但不一定非要被塞进同一个抽象产品里。
业务不是想自建，是被逼的
表面上看，越来越多业务方开始自己造轮子，是因为 AI 降低了工程化代价。业务方可以用 AI 写代码、搭页面、做原型，把过去需要中台才能做的工具自己做出来。这个判断当然成立。但我觉得更深的原因，是很多中台还在恪守传统的大一统形式：因为要抽象，所以不能只为一个业务设计；因为要共性，所以不能完全贴合某个场景；因为要复用，所以要让不同业务排队等待统一方案。
很多业务方并不真的想自己做。他们不懂底层系统，也不想长期维护这些工具，真正想要的是一个能解决自己问题、能快速上线、能贴近业务的产品。但如果中台给不了，业务就会被迫自己做。
这是个反讽：中台越想避免重复造轮子，越容易把业务推向重复造轮子；中台越执着于大一统，业务越觉得等不起、用不好、离自己太远。最后组织里出现一堆散落的小工具、小系统，看起来是业务太喜欢自建，实际上可能是中台的供给方式出了问题。
复用的东西变了
这里的关键，不是让业务方自己去造轮子。恰恰相反，我现在更倾向于认为，很多轮子仍然应该由中台来造，因为业务方不一定了解底层系统，也未必有意愿长期维护。更重要的是，很多事情看起来只是"做一个工具"，背后其实有大量经验、判断和治理。
一个智能回传模块，表面上只是把转化数据回传给广告平台。真正做起来，会涉及事件定义、数据质量、渠道 API、归因口径、回传延迟、去重、异常监控、合规边界。业务方可以用 AI 快速做出一个原型，但不一定知道什么样的回传才是好的，也不一定愿意为它承担长期维护。
所以，AI 时代真正变化的不是"业务自己造轮子"，而是"中台自己重复造轮子的成本下降了"。过去每造一个轮子都很贵，产品设计贵，研发贵，测试贵，联调贵，维护也贵，所以我们只能努力抽象，把差异变成配置。现在，中间那层业务产品的建设成本正在下降，一个业务化模块、一个定制流程、一个专属看板，不再像过去那么沉重。既然造一个业务版本的成本变低了，就不一定要把所有业务都压进同一个统一产品里。
更何况，很多所谓共性，本来就是表面共性。证券和理财都需要智能回传，但业务目标不同，用户旅程不同，转化定义不同，效果解释方式也不同。表面上都叫"回传"，落到业务里，语义并不一样。过去中台最容易犯的错误，就是看到两个业务长得像，就急着抽象。公共产品里开始出现越来越多开关、白名单、例外流程。最后产品确实统一了，但每个业务都觉得不好用；系统确实复用了，但复杂度被转移到了中台内部。这不是复用，这是把差异压扁。
我现在更愿意用这个方式理解中台：中台不一定要复用同一个产品，而是要复用造产品的能力。 产品本身可以不完全复用，但中台团队的经验、方法、数据理解、接口能力、治理能力、踩坑记录、交付流程可以复用。中台给证券做了一个智能回传，接下来给理财做时，不是从零开始，它知道哪些地方会踩坑，哪些指标要提前定义，哪些渠道规则要注意，什么样的看板业务真的会用。
过去我们复用的是一个公共产品，现在我们复用的是一套生产能力。
边界怎么划
这也意味着，中台提供的东西，共性上应该变薄，个性化上应该变厚。但"哪些能个性化，哪些不能"不能只是一句口号，还是得有具体的判断标准。以智能回传为例，我倾向于这样划：
必须统一、不能个性化的，是那些一旦不统一，就会造成数据失真、合规风险或跨业务协同成本的部分。事件定义和埋点规范、归因口径、数据质量和去重逻辑、监控和告警标准、权限和合规边界。这些东西如果证券一套、理财一套，未来想做跨业务分析或者审计的时候，会付出更大的代价。
可以且应该个性化的，是那些只影响单一业务体验和效果、不产生外部性的部分。回传时机和触发策略、看板的展示方式和指标口径解释、和业务系统的对接方式、运营侧的规则配置。证券的智能回传应该贴着开户转化、资产入金、用户分层来设计；理财的应该贴着申购、持仓、复购、风险偏好来设计；信用卡未来如果接入，也应该有自己的申请、激活、首刷、额度逻辑。这些差异，就不该被压进一个统一配置项里，而应该是产品设计时认真对待的对象。
一句话概括：看这件事是否会外溢到其他业务或者产生系统性风险，会外溢的统一，不会外溢的个性化。
这个边界如果不清楚，个性化就会变成失控的项目制；如果定得太死，个性化又会退回大一统。
这需要什么样的组织
这套模式对组织也提出了新的要求，而且不只是"中台人员要更懂业务"这么简单。即使造一个轮子的成本下降了，同时给证券、理财、信用卡各造一个、各维护一个，人力和治理的复杂度依然是接近线性增长的。这意味着，要么中台团队要适度扩编，要么需要把人以更贴近业务的方式分布出去，而不是继续挤在一个中心化的排期队列里。
这也是为什么，新中台的人需要更像 FDE：不是单纯的研发，也不是传统意义上的产品经理，而是带着工程能力、产品判断和中台资产，深入到业务现场的人。他要能听懂业务在说什么，也要能判断哪些诉求是真问题；他要能快速做出一个业务可用的产品版本，也要能把现场经验反哺回中台的资产体系。他需要知道证券为什么要这样回传，理财为什么不能照搬证券；也需要知道哪些东西绝对不能为某个业务随便改，哪些可以为了业务效果快速定制。换句话说，他既要能进入业务，又要守住中台。
中台不再只是一个平台建设部门，而要变成一支能不断生产业务产品变体的团队。不是给所有业务一个统一答案，而是基于同一套能力，给不同业务做出不同答案。
难点不在于写代码，AI 已经让写代码、搭页面、做原型变得越来越快。真正的难点在于，中台团队有没有能力理解不同业务的差异，有没有能力把经验沉淀下来，有没有能力在重复造轮子的过程中保持质量和治理。
重复造轮子本身不可怕
可怕的是，每个业务都自己造，每个轮子都没人知道为什么这么造，也没人负责长期维护；更可怕的是，中台为了避免重复，做出一个过度抽象的统一产品，最后让所有业务都不舒服，反而把业务推向自己造轮子的困境。
更好的状态是：轮子可以重复造，但由中台主动来造；每个轮子可以贴近业务，但背后有同一批人、同一套经验、同一套治理要求。
过去，中台的价值是"我做一个，大家都用"。现在，中台的价值可能变成："我做过一个，所以我能更快、更好地给你做一个适合你的。"
这两句话看起来差别不大，背后的组织逻辑完全不同。前者要求业务适配中台，后者要求中台进入业务。
AI 时代，中台真正要复用的，可能不是轮子本身，而是造轮子的手艺。而中台真正要避免的，也不是重复造轮子，是让业务被迫自己造轮子。
今天聊完以后，我反而觉得中台没有消失，只是需要放下一个执念：不是所有复用都必须表现为同一个产品。