中台战略实施的三笔账：复用、摩擦与退出

9月23日，南京，一场产学研闭门会。桌上摊着三张架构图，都是中台。有人问：为什么服务目录越写越厚，业务交付反而更慢？这问题不玄。它把中台从PPT拉回了账本。

我的判断很直接：中台战略实施的第一性问题，不是建多少共享服务，而是共享服务的边际收益何时转负。 超过那个点，平台越努力，组织越排队。说实话，这比选微服务还是单体要紧得多。

架构图之前，先看负债端

中台常被描述成能力复用。复用当然好。可复用有成本：抽象成本、协调成本、版本兼容成本。业务域越复杂，抽象越容易失真。一个订单中心被五个业务线共用，接口字段会膨胀，权限模型会打结，到头来谁都不敢改。

所以先看负债端。共享服务一旦进入核心交易链路，它就变成带SLA的内部供应商。供应商要有服务目录、计量口径、变更窗口、故障赔付。没有这些，中台只是把分散的系统耦合成集中式瓶颈。

技术上，至少要做三件事：领域边界先于服务拆分；API契约先于代码复用；数据所有权先于数据汇聚。反例不少。某零售企业把会员、积分、营销打包成一个大中台，结果营销规则一周三变，会员核心模型被拖进频繁发版。这不是中台能力，这是把变化引进了稳定域。

共享服务不是免费午餐

共享层要收费。不是真收钱，是算清资源账。计算、存储、接口调用、支持人力，都要回到业务线。否则需求会无限涌入。平台团队变成许愿池，业务线变成提需求的人。双方都委屈。

更麻烦的是KPI错配。业务线看GMV和上线速度，平台看复用率和稳定性。前者要快，后者要稳。没有联合指标，中台就会陷入需求排队与质量衰减的循环。怎么破？把复用率拆成有效复用和被动复用。有效复用是业务线主动接入并承担SLA；被动复用是行政命令下的接入。后者好看，不好用。

组织接口比技术接口更难改

技术接口可以写OpenAPI，组织接口写不了。中台团队归谁管？预算谁出？需求优先级谁定？这三个问题不解决，架构图就是装饰。南京这场会上，一位制造企业架构师说得很直白：中台不是技术部的中台，是业务能力的中台。嗯，问题就在这。

可行做法是设产品委员会加平台工程小组。委员会管准入和退出，工程小组管契约、可观测性和发布流水线。委员会里必须有业务负责人，不能只有架构师。否则共享服务会按技术偏好生长，不按业务价值生长。

还有一条常被忽略：中台团队要保留拒绝权。拒绝低复用、强耦合、长尾定制的需求。拒绝不是傲慢，是治理。没有拒绝权，中台战略实施会退化成外包池。

退出机制：中台也会失败

中台不是终身制。服务目录要能退役。判断条件可以很具体：连续两个季度复用方少于阈值；变更频率与业务域严重不匹配；维护成本高于各业务自建成本；监管或数据隔离要求无法满足。满足两条，进入退役评估。

退役不是拆掉一切。是回到业务域，或下沉为通用组件，或转为独立产品。没有退出机制，中台只进不出，负债越滚越大。这个道理不复杂，执行很难。因为它动预算、动人头、动面子。

边界也要说清。高频变化的前台创新，不适合强行共享；低频长尾的内部工具，不值得建中台；强监管的数据域，先做隔离和审计，别急着汇聚。中台适合什么？跨业务线重复出现、规则相对稳定、接口可契约化、失败影响可隔离的能力。 四个条件缺一个，都要谨慎。

趋势上，中台正在和平台工程合流。内部开发者平台、服务目录、FinOps、可观测性，这些不是新包装，是把中台的账算细。再往前走，可组合架构会比大一统中台更常见。模块化、按需组装、清楚边界。这不浪漫，但耐用。

回到南京那张桌子。三张架构图没形成结论。正常。中台战略实施从来不是一次画图，而是一连串带条件的取舍。复用要有收益，摩擦要可计量，退出要能执行。三笔账算不清，架构图越漂亮，越危险。