我们帮一个零售客户把6个CMS合并成1个：8周内容中台搭建复盘
某零售品牌一次促销错价事故损失十几万后，CTO下决心把6套CMS合并成一个内容中台。本文完整复盘8周搭建过程：选型、迁移、AI管线、多端分发，以及三个差点翻车的时刻。
2025年11月的一个周二晚上，某零售品牌市场总监在群里发了一条消息：「小程序端的促销价格没改过来，有2000多单以错误价格成交了」。起因很简单——运营当天在6个后台里更新双十一预热价格，漏掉了小程序。这6个后台分别是：官网WordPress、小程序自研后台、App运营台、天猫商家后台、抖音企业号、小红书专业号。7个人的运营团队，每天约60%的时间花在「一个系统改完、另一个系统再改一遍」上。
事故第二天，CTO找到我们：「能不能把所有这些后台合并成一个？」这就是这个项目的起点。
项目背景：为什么6个CMS是必然的
先说说这家公司为什么会有6个CMS——这不是管理混乱，是业务发展的自然结果。
2019年起步时只有官网，一个WordPress就够了。2020年上线小程序，小程序有自己的后台体系，开发团队直接在小程序框架里搭了一套简易CMS。2021年做了App，为了追求上线速度复用了一部分小程序后台代码但fork出了一个独立版本。2022-2023年陆续入驻天猫、抖音、小红书，每个平台自带商家后台，运营不得不学三套新系统。
到2025年底，一个商品上新要操作6个后台，一次促销改价要改6个地方，任何一个漏掉都可能出事故。这不是任何人的错——每个阶段的选择在当时都是合理的。只是当系统数量越过某个阈值后，维护成本会非线性增长。
第一周：别急着写代码，先弄清楚内容的流向
客户一开始的想法是「把6个后台的数据导进一个系统，然后统一管理」。这个方向是对的，但跳过了最关键的一步：理解内容的真实流向。
我们花了一周做内容审计，画出了一张让运营团队自己都惊讶的图：
- 官网有5200篇文章，但其中1800篇和小程序的内容完全重复（只是格式不同）
- App和小程序共享了约70%的内容，但因为CMS不同，每次改动都要分别操作
- 天猫、抖音、小红书的商品描述被运营手动裁剪后粘贴——没有版本记录，改了什么、谁改的、什么时候改的，全是黑盒
- 运营团队最痛苦的操作不是「写内容」，而是「把A系统的内容改格式后贴到B系统」——日均耗时4.5小时/人
这张图改变了项目的方向。我们不再追求「把所有内容塞进一个系统」，而是先解决核心矛盾：同一个内容在多个渠道的重复生产和手动格式转换。
这一步的价值在于：项目范围从「迁移一切」缩减到「统一自有渠道（官网+小程序+App）的生产管线，天猫/抖音/小红书通过适配器接入」。范围缩小了约60%，周期从最初估算的6个月压缩到8周。
第二至四周：选型与架构决策
为什么选了 Payload CMS 而不是 Strapi
第一个技术决策是 Headless CMS 选型。我们当时在两个开源方案之间选：Strapi v4 和 Payload CMS 2.0。给客户做了一个2周的对比测试，用他们的实际内容模型（商品、文章、活动页、Banner）分别搭建。
Strapi 的问题是内容模型的版本化管理太弱。运营团队频繁需要调整内容结构——比如给「促销活动」类型加一个「适用门店」字段。Strapi 的 content-type builder 在管理界面操作很方便，但底层直接改数据库表，没有 migration 记录。开发环境和生产环境的模型很容易不同步。
Payload CMS 用了代码定义内容模型（TypeScript collections），模型变更走 Git 版本控制，配合它内置的 migration 系统，多环境同步不会丢。再加上它的 access control 粒度更细——这对于后面多角色权限设计很关键。
成本对比：两者都是开源免费，自部署。Payload 需要 MongoDB（我们用的 Atlas 托管版，约$57/月起步），Strapi 支持 PostgreSQL（客户已有）。最终选 Payload，MongoDB Atlas 的额外成本在可接受范围内。
为什么不直接用 Contentful 等商业方案
客户问过这个问题。商业方案的优势是开箱即用、运维零成本。但对于这个客户，两个因素让商业方案不适用：第一，他们有几万个 SKU，商业方案的 content entry 计费模式下月度成本会很高（Contentful 的 pricing 在超过一定条目数后按调用量计费）；第二，他们需要内容API部署在境内服务器以保证小程序接口响应延迟在100ms以内，而 Contentful/Storyblok 的境内节点覆盖有限。
关于更广义的技术选型——多租户路由、流式响应、向量检索等在 SaaS 场景下的架构考量，我们在Web SaaS 开发 2026 技术选型中做了更系统的对比。
第五至六周：存量内容迁移——项目最大的隐形工程
如果以为「把WordPress文章导出再导入Payload」就完事了，那你还没做过真正的内容迁移。
现实是这样的：官网5200篇文章用了8年，期间换过3个富文本编辑器，文章里的图片引用格式不下5种。小程序后台的数据结构完全自定义，没有标准导出格式。App后台的JSON里有大量废弃字段，因为三年前的一次重构没做数据清理。
我们的迁移策略分三步：
- 自动抓取 + LLM清洗：用 Playwright 脚本批量抓取三个后台的渲染后页面，投喂给 LLM 做结构化提取（标题、正文、图片URL、发布时间、作者、分类）。LLM在这一步的准确率约85%，主要是老旧文章里的表格和嵌套格式容易出错。
- 人工复核队列：LLM置信度低于0.8的条目自动进入人工复核列表。最终需要人工处理的约18%——1300多篇。
- 双写验证：新内容同时在旧CMS和新中台发布，运行2周后对比两端渲染结果。2周内发现了43处不一致，大部分是图片CDN路径差异和富文本空格处理差异。
最意外的发现：迁移过程中发现官网有约400篇「僵尸文章」——创建后从未被访问过、内容已完全过时、但一直留在系统里占着URL。这批文章我们在迁移前先归档处理，反而给新系统的索引瘦了身。
第七周：AI内容管线——不是锦上添花，是刚需
内容中台建好之后，一个自然延伸是把AI嵌入内容生产流程。客户的需求很明确：
- 自动标签：8000多篇文章靠人工打标签需要3个人月。我们用 BGE-M3 embedding 对全文做向量化，匹配企业的 taxonomy 树，自动化率做到88%。剩下12%低置信度的才人工判。
- 多端内容裁剪：同一篇商品介绍，App需要120字+3张图，小程序需要80字+1张图，天猫需要特定格式的图文详情。我们做了一套渠道级transform规则——中台存完整内容，分发时按规则动态裁剪。运营不用再手动改格式。
- 过期内容自动下架：限时促销、季节商品、有时效性的政策条款——自动标记过期时间，到期前7天/3天/当天三级预警，超期自动下架。这个功能上线第一个月就自动处理了200多篇过期促销文章，之前都是靠运营手动翻。
这些AI能力看起来「高级」，但在这个项目里它们解决的是运营团队最基础也最痛苦的重复劳动。关于AI在内容管线中更深入的落地实践——特别是RAG架构在企业知识管理中的应用，我们在企业知识库AI搭建实战中有更详细的拆解。
第八周：上线与三个差点翻车的时刻
上线策略是分渠道灰度——先切官网20%流量观察3天，再全量；再切小程序；最后App。
时刻一：富文本渲染差异。官网切到中台API后，运营发现部分老文章的排版乱了。排查发现WordPress的Gutenberg编辑器会在段落间插入额外的HTML注释标记，Payload的富文本渲染器把这些注释当成独立段落渲染。修了2天——给富文本输出加了一层清洗中间件。
时刻二：图片CDN断裂。迁移脚本把图片URL原样搬过来了，但旧CMS的图片CDN域名和中台不在同一个账号下，跨域请求被拦截。上线前2小时才发现——紧急做了图片迁移脚本，把存量图片从旧CDN拉到新CDN，同时把URL域名全局替换。
时刻三：权限太松。上线第一周，一个实习运营想改Banner文字，误操作把首页整个content block删了。页面空白了12分钟。事后我们给Payload加了细粒度权限：编辑角色只能改已分配的字段，删除操作需要管理员二次确认，任何发布操作保留最近10个版本支持一键回滚。这个小功能在后续3个月里救了7次急。
项目总结：花了多少钱，省了什么
| 阶段 | 周期 | 投入 | 产出 |
|---|---|---|---|
| 内容审计 + 架构设计 | 1周 | 1架构师 + 1后端 | 内容流向地图 + 系统边界定义 |
| Payload CMS 搭建 + 内容建模 | 3周 | 2全栈 | Headless CMS上线 + 3渠道内容模型 |
| 存量迁移 + 双写验证 | 2周 | 2后端 + 1运营对接人 | 5200篇文章迁移完成，准确率96% |
| AI管线 + 多端分发 | 1.5周 | 1算法 + 1后端 | 自动标签/内容裁剪/过期监控上线 |
| 灰度上线 + 修复 | 0.5周 | 全员 | 3渠道全量切换 |
一次性投入：约22万元。低于行业平均水平（通常30-50万），因为客户的技术团队接住了部分工作量，且我们在审计阶段就把范围从「迁移一切」压缩到「统一自有渠道」。
运营效率变化：上线后3个月的数据——运营团队日均「复制粘贴」时间从4.5小时降到20分钟；促销活动上线周期从半天缩短到30分钟；内容错误率（如价格不一致、过期活动仍在展示）从月均7次降到0次。
最大的意外收获：中台上线后，市场部终于有了内容数据仪表盘——哪些内容被看了、哪些渠道转化好、什么类型的内容生命周期长。之前6个CMS各自为政的时候，这些数据散落在各处，根本拼不起来。
常见问题
Q1：什么规模的企业才需要内容中台？
三个硬信号：同时在维护3个以上独立的内容渠道；运营反馈「在不同系统间复制粘贴」占工作时间超过30%；内容合规/审核流程复杂到需要专人协调。如果三个信号占了两个，就该开始评估了。只有一个信号或者都没有——一个带API的Headless CMS通常就够了。过度建设比不建设的成本更高。
Q2：这个项目的架构能不能复用？
Payload CMS + 渠道级transform规则 + AI管线（标签/裁剪/过期）的架构是可以复用的。但三个东西需要按客户定制：内容模型（每个企业的内容类型不同）、第三方渠道适配器（天猫/抖音的API年年变）、AI模型选型（合规要求决定云端API还是自部署）。我们的经验是第二个客户的项目周期缩短了约40%，因为大量基础组件可以直接复用。
Q3：AI自动生成的内容会被搜索引擎降权吗？
这里的关键区分：AI做「内容加工」（标签、格式转换、翻译辅助、合规扫描）不会被搜索引擎惩罚，因为这些不替代人类创作。AI做「内容生成并直接发布」会触发Google HCU和百度劲风的降权信号。在我们的方案里，AI管线只做提效，所有最终发布的内容都经过人工编辑确认。
参考资料
如果你也面临多CMS并存的困境，或者在评估是否该建内容中台，可以联系我们做一次免费的技术评估——通常半天内能给出「值不值得建、从哪个渠道先试点、大致预算和周期」的判断。
]]>