产品经理如何搭建 CMS：从内容流转到模块设计

活动文案修改一次竟要惊动产品、研发、测试全流程？CMS 的价值远不止一个后台那么简单。本文从内容模型、权限设计到版本管理，拆解产品经理如何梳理内容流转路径，让运营真正掌握内容主动权，避免陷入排期与版本混乱的泥潭。

活动准备上线时，运营发现规则页少写了一项限制条件，可前台页面由研发写在代码里，运营没有修改入口，只能把新文案发给产品经理。产品经理确认展示位置和影响范围，研发排时间修改，测试人员检查页面，最后等待代码发布。

图 1 没有 CMS 时，一次内容修改往往会进入产品研发流程。

一句文案可能几分钟就能改完，时间主要花在沟通、确认和发布上，内容改得越频繁，这个问题出现得越多。产品经理还很难从零散的聊天记录中判断，当前线上使用的是哪一版，谁确认过这次修改，出了问题又该恢复到哪里。

如果网站一年只更新几次，这种处理方式未必会造成太大负担。活动、公告和帮助说明开始频繁变化以后，继续依赖研发改代码，团队很快就会遇到排期、权限和版本管理的问题。

CMS 为这些经常变化的内容提供统一的管理入口。运营可以创建和编辑内容，审核人员决定内容能否发布，系统负责记录状态与历史版本。前台读取已经发布的内容，每次调整文案时，无需重新修改前台代码。

图 2 CMS 为内容提供统一入口，并按照权限和状态控制发布。

有了编辑入口还不够。谁能改内容，谁能发布，改错以后怎样撤回，这些规则都需要提前设计。产品经理参与 CMS 搭建，要先把内容在团队中的流转过程整理清楚，再让系统按照这些规则运行。

理解 CMS，可以先追踪一条内容怎样被创建、确认、发布和撤回；这条路径走清楚以后，字段、页面和功能才有设计依据。

一、CMS 是什么，它解决了什么问题

前面的活动页面里，运营想修改的只是一段规则说明，页面结构和业务功能都没有变化。如果团队仍把这段文字写在前端代码里，每次修改都要进入研发流程。

CMS 的全称是 Content Management System，中文通常译作内容管理系统；IBM 将它概括为帮助用户创建、管理、存储和修改数字内容的软件。

这个定义很宽。产品经理理解 CMS，可以先抓住两个对象。一个是内容本身，另一个是内容所处的管理过程。

以常见的资讯文章为例，一篇文章会有标题、摘要、正文、封面图和作者，Banner 的结构又不一样，通常包含图片、跳转链接、展示位置和有效时间。帮助中心的内容还可能带有问题分类，并与其他说明互相引用。

这些字段组成了内容模型。它规定一类内容包含哪些信息，也决定系统能够怎样检索、展示和复用内容。

图 3 产品经理需要先识别内容类型，再为每类内容设计字段。

内容进入团队协作以后，还会经历不同阶段，编辑人员保存了一篇文章，此时它可能仍是草稿。提交给审核人员以后，状态变成待审核。审核通过并到达设定时间，前台才能展示。文章发布后发现错误，团队还需要找到之前的版本，决定修改、撤回或者恢复。

CMS 需要同时记录这些变化。内容模型规定系统管理什么，状态反映内容当前走到哪里，权限限制不同人员的操作范围。版本记录保留修改过程，帮助团队处理误操作和内容回退。

从产品结构来看，用户接触的是网站或 App 前台，运营和审核人员在 CMS 中维护内容，系统通过接口把已发布的内容交给前台。内容最后通常保存在数据库或文件存储中。数据库负责保存和查询数据，却不会主动提供适合运营人员使用的编辑、审核与发布流程。

图 4 CMS 连接内容维护人员、数据存储与前台产品。

CMS 和普通业务后台也有不同的关注对象。订单后台主要处理交易和履约，一笔订单的待付款、已发货等状态来自用户行为和业务规则。CMS 围绕内容生产展开，文章的草稿、待审核和已发布状态由编辑与发布过程产生。两类后台可以出现在同一套系统中，产品经理仍要分清它们各自在管理什么。

知识库与 CMS 的边界更接近。知识库重点帮助用户查找和阅读知识，CMS 可以为知识库提供内容编辑、分类、审核和发布能力。一个帮助中心既可以被称为知识库，也可以建立在 CMS 之上，具体名称取决于团队关注的是用户查找知识的体验，还是后台如何管理这些内容。

并非每个产品都需要单独搭建 CMS。如果内容长期不变，维护人员很少，修改一次也不会影响多个渠道，一套简单的后台配置就可能够用。涉及价格计算、库存扣减或支付结果等业务规则时，团队还需要依靠对应的业务系统处理，CMS 只适合管理其中的说明和展示内容。

内容开始频繁变化，多个人共同维护，团队还要求审核、定时发布和错误恢复，此时 CMS 的价值会逐渐显现。它管理文案，也管理文案周围的结构、状态、版本和使用位置。

二、产品经理为什么需要理解 CMS

CMS 上线以后，日常操作大多由运营人员完成。产品经理的工作主要发生在系统设计阶段，他要决定 CMS 管理哪些内容，内容怎样变化，以及不同角色能够执行哪些操作。

很多 CMS 需求最初只有一句话，给运营做一个能修改 Banner 的后台。

如果产品经理把需求直接画成图片上传框，研发很快就能做完。系统投入使用后，问题才会出现。电脑端和手机端是否使用同一张图片，点击以后跳到站内页面还是外部链接，Banner 应该出现在哪个位置，又该在什么时间自动下线，这些问题都会回到产品经理手里。

业务人员口中的“一个 Banner”，到了产品设计阶段，需要变成字段、规则和使用位置，文章、公告和帮助说明也要经过同样的整理。产品经理在这里做的是内容抽象。他要从多次修改和发布中找出稳定部分，再把它们设计成可以重复使用的内容模型。

图 5 一个简单的 Banner 需求，进入 CMS 后会被拆成多个字段。

内容模型还会影响产品的迭代方式。

设想同一份会员规则出现在官网、App 和客服帮助页，如果三个渠道各自保存一份，规则调整后，运营需要分别修改。某个渠道漏改，用户就会看到不同版本。CMS 可以让几个渠道引用同一份内容，也可以保留各渠道需要单独展示的字段。产品经理需要提前判断哪些内容可以共用，哪些差异必须保留。

图 6 内容复用需要提前区分共同信息与渠道差异。

权限是另一项需要产品经理处理的工作。

WordPress 的官方文档提供了一个直观案例。投稿者可以撰写和管理自己的文章，但没有发布权限。编辑可以发布文章，也能管理其他人的内容。系统通过角色组合不同的操作能力。

这种设计提醒产品经理，角色名称本身解决不了权限问题，团队需要先拆清具体动作，再决定怎样组合角色。同一个运营团队里，有人负责录入内容，有人负责审核。临时活动可能还需要指定人员下线内容。如果系统只设置管理员和普通用户，管理员的权限容易过大，普通用户又可能什么都做不了。

内容发布后的问题同样需要提前处理。

运营误改了一段活动规则，系统应当保留修改记录，已经发布的内容需要紧急撤回时，相关人员也要有明确入口。定时发布失败以后，系统还应提示失败原因，并让负责人知道当前前台展示的是哪个版本。

图 7 权限、审核和版本记录共同支持多人协作。

运营效率要连同这些异常情况一起看。编辑页面即使操作很快，发布出错后仍要在聊天记录里寻找旧文案，CMS 省下的时间也很有限。

CMS 也适合帮助产品经理理解后台产品，产品经理先识别文章、Banner 等业务对象，随后观察它们怎样改变状态。参与角色增加以后，系统还要限制操作范围并留下记录。这套分析方法也可以用于订单后台、工单系统等产品，只是管理对象和业务规则会发生变化。

小团队可以采用更简单的流程。一个人同时负责编辑和发布时，两级审核没有必要。内容很少变化时，复杂的版本管理也可能增加操作负担。产品经理仍然需要主动做出取舍，并明确简化流程可能带来的风险。

产品经理设计 CMS，最终要回答两个问题，团队中的谁可以处理哪些内容，这些内容又按照什么规则流转。答案足够清楚，后面的页面、按钮和权限才有依据。

三、搭建 CMS 之前，先梳理内容怎样流转

接到“做一个 CMS”的需求以后，最容易开始的工作是画页面，左侧放菜单，中间放内容列表，右上角再加一个新建按钮，一套后台很快就有了样子。

页面画得快，通常意味着很多业务问题还没有被问出来。内容由谁创建，经过谁确认，什么时候出现在前台，发布错误以后怎样处理，这些规则会决定页面需要哪些字段和按钮。流程没有理清，原型只能把问题往后推。

可以先选一类最常见的内容，把它从创建一直走到下线。

以资讯类产品的文章为例。运营人员收到选题以后创建文章，填写标题、正文和封面图。文章完成后交给审核人员检查，审核通过才能发布。活动类文章可能还要等待指定时间，内容过期以后再由系统或运营人员下线。

这条流程看起来简单，继续往下问就会出现更多情况，审核人员退回文章后，它回到哪个状态，原编辑能否继续修改。文章已经进入定时发布，临时修改是否需要重新审核。内容发布后发现错误，应该直接改线上版本，还是先撤回再处理。

产品经理可以先整理一张角色表。表中记录每个角色负责的内容范围，以及他可以执行的操作。角色名称可以沿用团队现有叫法，权限仍要拆到创建、编辑、审核和发布等具体动作。这样才能发现同一个人是否承担了冲突职责，也能判断小团队可以在哪些地方简化。

接下来盘点内容。

内容清单需要记录内容类型、关键字段和前台展示位置，还要知道谁负责维护。文章可能出现在首页推荐位和栏目列表中，封面图比例与摘要长度会影响两个位置的展示效果。运营修改文章时，CMS 应当告诉他这条内容正在被哪些页面使用，避免一次调整影响其他位置。

图 8 一条内容会经过不同角色，也可能出现在多个前台位置。

内容清单还可以暴露重复建设。同一份活动规则分别存放在 Banner、活动页和帮助中心时，产品经理要判断它们应该引用同一条内容，还是保留三份独立版本。这个决定会影响后续修改成本，也会影响不同渠道能否保持一致。

角色与内容清楚以后，就可以画状态流转图。

WordPress 官方文档列出了草稿、待审核、定时发布和已发布等内容状态。拥有编辑权限但没有发布权限的用户提交文章后，内容会进入待审核状态，再由具备发布能力的角色处理。

产品经理可以参考这种思路，根据自己的业务设计状态；状态名称只是表面，关键在于每次变化需要满足什么条件。文章从草稿进入待审核，系统要检查必填字段。审核通过以后进入待发布，系统还要确认发布时间。审核被拒绝，内容需要回到可编辑状态，并保留退回意见。

图 9 内容状态决定每一步可以由谁执行，以及失败后回到哪里。

发布方式也会改变流程。

立即发布适合已经完成审核、需要马上展示的内容。定时发布需要系统记录执行时间和时区，并在执行失败后提示负责人。Contentful 的官方文档显示，它的定时发布功能支持在指定时间发布或下线内容，也能查看计划、已完成和未来的操作。

从产品设计角度看，定时发布不能只增加一个日期选择框。运营需要看到未来有哪些内容等待发布，也要能修改或取消计划。执行时间到了，系统还要检查相关图片和引用内容是否可用，并把最终结果反馈给负责人。

灰度发布的要求更高。它会让一部分用户先看到新内容，其他用户继续看到旧版本。CMS 可以管理目标人群、渠道和内容版本，前台或内容分发系统还需要具备识别人群并返回对应内容的能力。团队缺少这部分技术条件时，在 CMS 里增加“灰度发布”按钮并不能完成灰度。

图 10 发布按钮背后对应着不同的执行规则和技术条件。

正常流程确定以后，还要把异常放进去。

审核退回需要返回编辑环节。定时发布失败时，线上旧内容应继续保留，并通知相关人员。已经发布的内容出现错误，系统要支持撤回或恢复版本。删除仍被前台引用的内容时，也要给出提示，避免页面留下空白。

角色表、内容清单和状态流转图可以组成搭建 CMS 前的基础材料，产品经理用它们确认谁在操作、系统管理什么，以及内容怎样前进或返回。三份材料能够互相检查。流程里出现了审核角色，角色表中就应当有对应权限。内容需要定时下线，内容清单里也应当有有效时间或下线规则。

当一条真实内容能够从创建走到发布，并在出错后顺利撤回，CMS 的主要流程才算清楚；流程中的每个动作都能找到对应页面和权限，后面的功能设计才有依据。

四、一个基础 CMS 应该包含哪些模块

CMS 的菜单可以拆得很细。产品经理如果从菜单名称开始整理，很容易得到一张功能清单，却看不出模块之间怎样配合。

更容易理解的方法，是让一条内容再走一遍系统，运营先找到或创建内容，完成编辑后提交审核，审核通过再发布。后续发生修改，系统继续记录版本和操作。CMS 的主要模块可以沿着这条使用路径展开。

图 11 CMS 各模块沿着一条内容的使用路径配合运作。

内容模型决定系统可以管理什么。

产品经理需要先定义内容类型，再为每种类型配置字段。字段除了名称，还要明确输入形式、校验规则和关联关系。Contentful 的官方说明中，内容模型由多个内容类型组成，每个内容类型包含自己的字段，不同内容还可以通过引用字段建立联系。

一篇文章可以包含标题、正文、作者和封面图。标题需要限制长度，封面图需要规定比例，作者则可以引用已有的作者信息。如果系统只提供任意文本框，运营很容易填入前台无法正确展示的内容。

字段规则也要考虑修改成本。把文章栏目写成普通文本以后，同一个栏目可能出现多个写法。改成可选择的栏目对象，系统才能统一筛选和展示。字段越灵活，运营填写时越自由，后续的数据混乱也会增加。产品经理需要根据真实使用频率决定哪些字段固定，哪些字段允许配置。

内容列表负责帮助运营找到待处理的内容。

列表里至少要让用户看见标题、内容类型、当前状态和最近修改情况。内容量增加以后，搜索与筛选会变得重要。运营可能按标题查找一篇文章，也可能筛出某位作者提交的待审核内容。活动结束时，他还要找到即将下线或已经过期的内容。

列表设计应当围绕这些任务安排信息。状态已经失效的内容需要明显提示，等待当前用户处理的内容应当容易找到。批量发布和批量下线可以减少重复操作，同时会放大误操作的影响。系统需要在执行前展示影响范围，并为高风险动作增加确认。

新建和编辑页面承担内容录入工作。

编辑页面应按照运营填写内容的顺序组织字段。数据库里的字段排列通常无法直接反映运营人员的工作方式。文章的标题、摘要和封面图适合放在相近区域，发布设置可以单独处理。很少使用的配置可以收起，必填项和错误提示要靠近对应字段。

保存草稿也需要明确反馈。网络中断或多人同时编辑时，系统要告诉用户内容是否保存成功，避免后一位编辑覆盖前一位的修改。多人协作频繁的项目，还需要考虑编辑锁定或冲突提醒。

预览帮助运营检查内容在前台的实际效果。同一篇文章在网站和 App 上可能使用不同布局，预览入口需要说明当前查看的是哪个渠道。定时内容还要预览未来版本，已经发布的内容则要区分线上效果与正在编辑的新版本。

图 12 结构化编辑与多端预览可以减少发布前的内容错误。

审核与发布模块接住编辑后的内容。

审核人员需要看到待审核内容，也要知道这次提交改了什么。审核退回时，意见应当与当前版本绑定，编辑人员修改以后可以重新提交。发布环节还要确认发布范围与执行时间，避免用户把测试内容直接送到正式前台。

版本记录负责保存内容变化。

WordPress 的版本功能会记录保存过的草稿和已发布更新，用户可以比较不同版本，并将内容恢复到选定版本。

产品经理还要明确系统恢复什么。一篇文章可能引用封面图、作者信息和活动规则。恢复文章正文时，关联内容是否一起恢复，会直接影响前台结果。第一版 CMS 可以采用较简单的版本方案，但恢复范围必须让用户看得明白。

用户、角色和权限模块控制操作范围。

权限通常包含两个部分。第一部分决定用户能执行哪些动作，第二部分限制他可以管理哪些内容。负责某个栏目的运营人员可以编辑该栏目文章，但未必能够修改其他栏目。审核人员可以通过内容，却不一定拥有删除权限。

角色配置越灵活，维护成本越高。团队人员和职责相对稳定时，预设几个角色就能满足需要。组织规模增加或内容风险较高以后，再考虑自定义角色和更细的内容范围。

操作日志用于追踪系统中发生过的动作。

版本记录关注内容发生了哪些变化。操作日志还要记录谁执行了发布、删除或权限调整，以及系统是否执行成功。线上出现异常时，团队可以从日志确认最近发生了什么，再决定恢复内容还是检查发布过程。

日志也要控制信息量。普通编辑无需阅读所有技术记录，产品页面可以先展示操作人、时间、动作和结果。更完整的接口响应和错误信息留给研发排查。

图 13 版本记录解决内容恢复，操作日志帮助团队找到问题经过。

一个基础 CMS 可以从内容模型、内容列表和编辑页面开始，再接上审核发布、权限和版本记录。操作日志为异常排查提供证据。第一版无需把每个模块都做成通用配置平台，至少要保证一条高频内容可以被创建、找到、审核并安全发布。

CMS 的成熟程度，会体现在多人同时参与时能否分清责任，内容变化以后能否追踪，发布出错以后能否恢复。

五、产品经理如何完成一套 CMS 方案

前面几章已经把内容、流程和功能拆开。进入项目以后，产品经理面对的材料往往没有这么整齐。部分内容写在代码里，运营用表格记录发布时间，审核意见散落在聊天记录中。第一步要把现有做法还原出来。

调研可以从最近一次内容修改开始。

让运营人员把操作过程走一遍。需求由谁提出，内容现在存在哪里，中间经过哪些人确认，最后又怎样出现在前台。产品经理还要记录他们使用的表格、文档和聊天消息，这些临时工具通常保存着系统尚未覆盖的规则。

内容生产者关心录入和修改是否方便，审核人员更在意风险与责任。前台内容的使用者也值得访谈。例如客服可能需要根据帮助文章回答用户，市场人员则会关注活动内容能否准时上线。不同角色描述的是同一条内容在不同阶段遇到的问题。

图 14 一套 CMS 方案需要经过调研、设计、协作和验收。

调研完成后，不必立刻把所有内容放进第一版。

假设要为资讯类产品搭建 CMS，文章通常是更适合先处理的内容类型。它更新频繁，字段和流程相对稳定，也能完整走过创建、审核、发布和下线。产品经理可以先让网站使用这套文章内容，App、多语言和复杂的渠道配置留到后续验证。

第一版需要跑通一条主要流程。编辑人员能够创建和修改文章，审核人员可以退回或通过，内容发布后可以找到历史版本。自定义字段、复杂的多级审核与灰度规则可以等到真实需求出现以后再扩展。

这样的范围更容易验收。团队可以用真实文章检查流程，运营也能较快开始使用。如果第一版同时支持文章、Banner、帮助中心和活动页面，产品经理需要一次处理多套字段与流程，项目会很快被通用配置拖慢。

图 15 明确最小范围，可以让团队更早验证内容流程。

范围确定以后，产品经理开始整理方案。

内容清单会逐步变成内容模型和字段说明。角色表可以继续细化为权限矩阵，状态流转图则要标明每次变化的触发条件。信息架构负责安排内容管理、审核任务和系统设置的位置，原型展示用户怎样完成关键操作。

字段说明需要写到研发可以实现、测试可以验收的程度。以封面图为例，要明确文件格式、尺寸限制和裁剪方式。文章引用作者信息时，还要说明作者被删除或停用以后，历史文章怎样展示。