活动文案修改一次竟要惊动产品、研发、测试全流程？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　明确最小范围，可以让团队更早验证内容流程。

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

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

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

原型也要包含关键状态。空列表、字段填写错误、审核退回和发布失败都会影响用户下一步怎样操作。只画正常页面，研发和测试仍然需要在项目后期补齐这些规则。

产品经理还要和研发确认内容怎样到达前台。

传统 CMS 通常把内容管理和网站展示放在同一套系统中，适合渠道较少、页面形态比较固定的项目。Headless CMS 将内容管理与展示层分开，通过接口把结构化内容提供给网站或 App。Contentful 的官方说明将这类架构描述为内容后台与展示层分离，并通过 API 将内容提供给不同终端。

图 16　技术架构会改变内容发布方式和维护成本。

Headless 架构给前台留下了更多技术选择，也会增加接口、预览和发布过程中的协作工作。同一条内容提供给多个渠道时，产品经理需要定义各渠道读取哪些字段。预览功能还要能访问尚未公开的内容，同时限制链接的访问范围。

产品经理理解到这些技术选择怎样影响产品就够了。内容最终存在哪里，前台通过什么方式读取，更新以后是否经过缓存，发布失败怎样反馈，这些问题都需要在方案阶段确认。具体数据库结构和服务器配置可以交给研发决定。

建设方式通常也有几种选择。

业务流程比较标准，团队希望尽快投入使用，可以评估成熟 CMS 服务。它能减少基础功能开发，采购费用和可定制范围需要提前确认。开源 CMS 提供了更多改造空间，团队仍要负责升级、备份和安全维护。自研方案适合流程高度特殊、CMS 与核心业务联系紧密的项目，长期开发与维护成本也会更高。

开源不等于没有成本。插件兼容、版本升级和安全修复都需要人负责。产品经理无需编写部署方案，但要确认谁维护生产环境，数据怎样备份，系统故障后由谁响应。团队没有稳定的技术资源时，高度自由的方案可能很快变成维护负担。

开发过程中，产品经理还要持续用真实内容走查。

字段和页面完成以后，可以先录入几篇长度、图片数量和引用关系不同的文章。审核人员实际退回一次，运营再次修改并提交。随后测试立即发布和定时发布，再模拟图片失效、发布失败和内容撤回。

CMS 页面显示“已发布”只是一个检查点。产品经理还要继续确认接口返回了正确内容，缓存已经更新，网站或 App 展示符合预期。后台状态和前台结果一致，这次发布才算完成。

上线后可以记录运营完成一次发布所需的时间，以及发布失败和人工协助的情况。运营开始频繁申请新字段，说明内容模型可能需要调整。大量流程仍在聊天工具中完成，也说明系统没有接住对应的协作规则。

第一版 CMS 应优先跑通一类高频内容。团队从真实操作中发现问题，再逐步增加新的内容类型和配置能力。这样形成的通用能力有使用依据，也更容易控制系统复杂度。

六、CMS 最容易踩的坑

一套 CMS 可以顺利通过功能测试，上线后仍被运营绕开。内容继续记在表格里，发布前仍要在群里确认，系统只负责最后一步录入。

用户绕开系统，通常说明某个真实步骤没有被接住。页面数量和按钮数量无法弥补这些缺口。

第一个常见问题，是直接照着前台页面设计字段。

产品经理看到详情页上有标题、图片和正文，就在后台建立对应输入框。内容只在一个页面使用时，这套设计能够运行。内容开始出现在首页、App 或客服帮助页以后，原来的字段很快就不够用了。

例如，首页只需要文章标题和封面图，详情页还要展示作者与正文。产品经理如果把首页卡片当成一个完整内容保存，详情页又保存一份，运营每次修改都要维护两个版本。更合适的做法是先定义文章对象，再让不同页面读取所需字段。

字段也不能完全照搬数据库。数据库里的内部编号和技术状态可能对研发有用，运营更关心这条内容会出现在哪里，什么时候上线，以及当前由谁处理。后台页面需要按照使用任务重新组织信息。

第二个问题，是内容状态只够覆盖正常流程。

一些 CMS 只有草稿和已发布。文章审核被退回以后，运营只能把它继续留在草稿里，再通过聊天消息说明原因。定时发布失败也没有单独状态，后台显示内容尚未发布，却无法告诉用户系统是否执行过任务。

状态太少，异常过程会回到线下。状态过多也会增加理解成本。产品经理可以从真实动作出发，只保留会改变责任人、可执行操作或前台结果的状态。审核退回需要编辑重新处理，值得单独记录。某个内部步骤没有改变任何操作，就未必需要成为新状态。

第三个问题，是权限只有管理员和普通用户。

普通用户权限太少，日常工作无法完成。团队为了赶进度，会把更多人设为管理员。发布、删除和权限调整随之集中在同一个角色上，误操作风险也会增加。

权限设计应当拆到具体能力和内容范围。运营可以编辑自己负责的栏目，审核人员能够处理待审核文章，发布权限则根据内容风险单独控制。小团队可以让一个人承担多个角色，系统仍要知道他正在执行哪类操作。

图 17　运营绕开 CMS，通常意味着系统漏掉了真实工作步骤。

第四个问题，是预览、版本和回滚被放到后续。

运营看不到前台效果，只能发布后再检查。内容写错或图片比例不合适时，错误已经到达用户。系统没有版本记录，团队只能从旧文档或聊天记录里寻找上一版。

这类功能不会增加内容数量，却会影响运营敢不敢使用 CMS。修改已发布内容时，如果用户无法确认新版本的效果，也不知道能否恢复，他会倾向于先截图找人确认。CMS 只剩录入功能，风险仍由人工承担。

预览要尽量接近实际前台。版本记录需要说明修改人和修改时间，回滚还要明确恢复范围。一篇文章引用了作者和图片，恢复正文时是否同时恢复引用内容，系统应当给出清楚反馈。

第五个问题，是第一版就追求万能配置。

字段可以随意新增，页面能够自由组合，审核流程也允许用户自己搭建，这类方案听起来适用于所有内容。开发时却要处理更多配置规则，运营每次新建内容也要面对更多选择。

通用能力需要从重复出现的需求中产生。团队已经验证多类内容共享一套字段规则，再把它提取为配置能力，使用者会知道该怎样设置。第一版缺少这些证据时，固定的文章模型和简单审核流程更容易投入使用。

配置功能还会改变维护责任。运营人员调整字段以后，前台接口是否兼容，历史内容怎样迁移，错误配置由谁恢复，都需要对应规则。一个“新增字段”按钮背后可能牵动多个系统，产品经理要把这些影响一起算进去。

图 18　通用配置应当来自已经反复出现的业务需求。

最后一个问题，是验收只检查后台页面。

测试人员确认新建按钮可以点击，字段可以保存，发布状态能够改变，这些检查只能说明 CMS 页面运行正常。内容还要经过接口、缓存和前台展示，发布才算完成。

真实验收应当准备一条接近正式使用的内容。运营录入文章，审核人员退回一次，再重新提交和发布。产品经理继续检查网站是否及时更新，随后模拟内容撤回和版本恢复。发布失败时，系统还要给负责人留下可以理解的结果。

批量操作也需要单独测试。批量下线十条内容时，其中一条仍被首页引用，系统是全部终止，还是完成其余九条并报告失败项。不同处理方式都会影响运营怎样补救，产品经理需要提前确定。

图 19　CMS 验收需要检查内容是否准确到达用户看到的页面。

CMS 上线以后，表格和聊天工具仍然可以存在。它们适合处理临时沟通，系统负责保存稳定规则。运营每次都要回到表格确认字段，说明内容模型可能漏了信息。管理员账号持续增加，则要重新检查权限是否过窄。

CMS 的复杂度应当由真实业务决定。抽象过早会增加使用和维护成本，规则缺失又会让异常过程回到线下。产品经理需要持续观察运营在哪一步离开系统，再判断应该增加功能、调整流程，还是删掉多余配置。

结尾｜用一条真实内容走完系统

CMS 方案完成后，可以暂时放下功能清单，选一条真实内容走完整个流程。比如新建一篇帮助中心文章，由编辑填写内容，交给审核人员确认，再按照设定的时间发布，最后去前台找到它。沿途记录参与角色、内容状态和展示结果，很多遗漏会在这个过程中出现。

图 20　一条真实内容可以直接检验角色、状态与前台结果。

内容成功发布还不够。可以故意改错一个字段，看看谁能修改，修改后是否需要重新审核，前台什么时候更新。随后撤回这条内容，再尝试恢复历史版本，检查操作记录能否说明发生了什么。

如果后台已经显示发布成功，前台仍然没有变化，还要继续检查接口、缓存和客户端展示。产品经理验收 CMS 时，需要关注内容是否真正到达用户，不能停在后台按钮已经点击这一步。

图 21　异常恢复演练可以检验系统能否把内容带回稳定状态。

一条内容能够在多人协作中正常流转，也能在误操作和发布异常后恢复，CMS 的核心设计才算成立。对产品经理来说，这条真实内容就是最直接的验收用例。