一个常见的误判
过去几年，"中台"这个词被使用得过于宽泛。我们在客户现场看到最多的一类系统，本质上是接口平台——它把订单、库存、会员的读写操作统一收口，对外提供 REST API。技术上无可挑剔，但业务侧的评价往往是"没什么感觉"。
原因在于，接口统一解决的是连通性问题，而中台真正要解决的是复用性问题。这两件事的差距，比多数人预期的要大。
连通性 vs 复用性
连通性的判断标准是：A 系统能不能拿到 B 系统的数据。 复用性的判断标准是：新开一条业务线，需要重写多少代码。
举一个具体的例子。某客户先后上线了自营商城、经销商订货平台和门店小程序。三套系统都通过接口平台读取同一个商品库——连通性是满足的。但当业务提出"给经销商单独设置阶梯价"时，需要在三套系统里分别改代码，因为价格计算逻辑散落在各个前台应用中。
这说明商品域只被复用了数据，没有被复用能力。
能力复用的三个层次
我们通常把复用分为三层，成熟度依次递进：
第一层：数据复用。 统一数据源，避免一物多码。这是入场券，不是护城河。
第二层：逻辑复用。 价格计算、库存预占、优惠叠加这类业务规则下沉到中台，前台只负责表达。判断标准很朴素——新增一个渠道，能不能不写业务逻辑。
第三层：编排复用。 交易链路本身成为可配置资产。B2B 需要审批后锁库，B2C 需要下单即锁库，两者共用一套状态机，差异通过配置表达。
绝大多数"中台项目"止步于第一层，少数走到第二层，第三层需要业务模式足够稳定才有价值。
什么时候不该建中台
这一点比"如何建"更重要。以下三种情况，我们通常建议客户不要启动中台项目：
- 只有一条业务线，且短期内不会增加。 复用的前提是有多个消费方，单一业务线做中台，收益为负。
- 业务模式尚未跑通。 中台沉淀的是稳定能力，把还在快速试错的逻辑固化下来，只会增加变更成本。
- 组织上没有明确的中台责任方。 中台是长期资产，需要持续投入与owner，项目制交付完就散伙的团队，做出来的中台三个月后就会腐化。
一个务实的路径
对大多数中型企业，我们更推荐"从最痛的那个域切入"：
- 如果超卖频发，先做库存域；
- 如果价格混乱，先做商品与定价域；
- 如果会员数据割裂，先做会员域。
单域打透之后，能力边界与团队协作方式都会清晰很多，再横向扩展的成功率远高于一次性铺开。
中台不是一个项目，而是一种持续的组织能力。把它当项目做，多半会失败；把它当资产养，才可能真正产生复利。