多端内容平台开发

项目背景

这是一套自研的内容管理底座，以及基于它落地的多个内容型业务系统。业务覆盖文库内容与教育内容，形态包括 PC 门户站、移动端应用、微信小程序与管理后台。项目最有价值的部分不是单个系统做得多复杂，而是底座被复用了——同一套底层能力落到不同业务场景，新客户不需要从头再建一遍。

客户当时的状态

内容型业务有个共同的困境：不同客户的业务差异其实集中在展示层和运营规则上，底层的内容模型、权限、接口这些东西高度相似，但每做一个客户就要重来一遍。结果是交付周期拉长、成本下不来，而且每个项目各自演化，后续维护要同时看懂好几套代码。同时内容类业务对发布效率很敏感，如果运营改个栏目都要开发排期发版，业务节奏就被卡住了。

我们的做法与取舍

第一个取舍是把共性下沉、把差异上浮。内容模型、权限体系、接口层、通用能力这些所有客户都要用的东西，抽到统一底座；栏目结构、运营规则、业务逻辑这些真正有差异的部分，留在业务层。判断标准很简单：如果一件事在两个客户那里做法一样，它就该在底座；做法不同，它就该在上层。

第二个取舍是接口只定义一套。多端最容易出的问题是口径打架——PC 站一套字段、小程序又一套，内容要维护两份，改一处漏一处。我们把接口定义统一在底座，端之间只做展示差异。代价是接口要设计得足够通用，收益是内容永远只有一份。

第三个取舍是把发布权交给运营。内容录入、栏目组织、审核发布这些日常动作，运营在后台自己完成，不依赖开发。这一条决定了内容型系统上线后能不能真正跑起来。

系统怎么承载这条链路

底座按 system / base / api / backend / common 划分模块：系统与权限、基础能力、接口层、后端服务、公共组件各司其职。PC 站用 Nuxt 承载，移动端与小程序端共用一套业务接口，管理后台负责内容与栏目运营。同一套底座已经支撑了不同业务场景的多端上线。

交付状态与边界

系统处于持续维护状态，最近一次提交在 2026 年 9 月。边界需要说明：底座是我们自研的资产，不属于任何一个客户项目的交付范围，也不对外授权或开源——客户拿到的是基于底座构建的业务系统。内容合规责任在运营方，平台提供的是审核与发布的能力。如果业务涉及付费内容，支付通道以贵方实际签约为准，我们不代持资金。

另外坦白一点：底座本身没有对外发布的技术文档，公开页面也不展开内部设计。它是否适合你，看的应该是落地结果——同一套底座能不能撑住不同业务的多种端，这一点我们可以在面谈时按模块说明。