AI CMS搭建：从短剧生产链拆解对象、状态与审核机制

AI生成内容爆发后，CMS不再只是网站后台，而是AI产品经理必须掌握的核心能力。本文从AI短剧语言学习产品实战出发，拆解CMS如何管理内容身份、版本、审核与数据回流，帮你理清从0到1搭建AI时代CMS的完整思路。

最近在测试市场，在面试的时候，我发现CMS几乎总会被问到。

有时候对方会直接问：你有没有搭建CMS的经验？

有时候不会提CMS这个词，但只要继续聊AI内容生产，很快就会碰到相同的问题：大量内容生成以后怎么管理，版本怎么追踪，谁来审核，某个结果出了问题怎么找到原因，用户数据又怎样回到下一轮生产？

CMS这个词早就有了。

很早之前就已经出现了用于网站内容创建、管理和发布的系统。

1997年的StoryServer已经被称为Web内容管理系统，Drupal也在2001年发布。后来无论是新闻网站、电商、音乐平台还是短视频平台，都有自己的内容管理系统。

现在模型可以写文章、做图片、生成视频，内容生产门槛已经比过去低了很多。按理说，内容应该更容易做了，为什么企业反而又要花力气做CMS？

CMS到底是什么？它是一套具体的技术框架，是一种产品方法，还是一类企业软件？如果一个AI产品经理要从0到1搭建CMS，应该从哪里开始，这个项目又要怎样一路推进到上线？

CMS是一类管理数字内容的软件系统。它给内容建立结构和身份，管理内容从创建、修改、审核、发布到数据回流的全过程。产品方法和技术框架都是实现CMS的手段。

产品经理梳理业务、拆对象、画状态机，是设计CMS的方法；数据库、对象存储、工作流引擎和后台界面，是实现CMS的技术；WordPress、Headless CMS、企业内部内容中台，则是不同形态的CMS产品。

AI改变了内容生产的规模，也改变了参与生产的角色。原来系统主要接住人工编辑后的内容，现在还要接住Agent任务、批量候选、模型与Prompt版本、人工接管、自动检查和多轮返工。生成变快以后，内容能不能被管理、审核、组装和追溯，开始比“能不能生成”更早成为问题。

前段时间梳理一套AI短剧语言学习产品的项目时，难点落在怎么把剧本、分级改写、知识点、题目、视频和课程接到同一条生产线上。把这条链拆开以后，CMS该管什么、人与AI怎样协作、内容如何安全发布，也就具体了。

如果你只是想知道什么是CMS，差不多看到这就可以了。因为光这个项目的CMS需求文档就又臭又长，所以相对来说还是很复杂的。

我一口气都看不下去，断断续续拆解的，如果你对CMS感兴趣，或者你要做的话，我建议这边直接把这篇文章扔给AI就行了！

CMS管理的是内容背后的业务规则

CMS，Content Management System，内容管理系统。

Contentful把CMS定义为一种让内容创作者通过界面管理、编辑和发布数字内容的软件应用；

Drupal强调用户可以通过浏览器添加、发布、编辑和删除网站内容；WordPress里的草稿、定时发布、历史修订、公开与私密、用户与权限，则是这些能力落到产品里的样子。

这些定义都没有规定CMS必须用哪种语言、数据库或者前端框架。

它可以是前后台放在一起的网站系统，也可以是通过API向App、小程序、电视等不同终端供给内容的Headless CMS，还可以是企业围绕自己业务独立建设的内容中台。

技术实现可以变，一套CMS始终要回答六个问题：

• 系统管理什么内容；
• 内容现在进行到哪一步；
• 谁可以对它做什么；
• 它为什么成为现在这一版；
• 它怎样交付给用户；
• 上线结果又怎样回到下一轮生产。

对象、字段、状态、权限、版本、审核、发布和数据回流，都是从这些问题里挖出来的。

一个网盘能保存文件，但它通常不知道文件处于候选、待审核还是已发布，也不知道谁有发布权；一个AI生成工具可以输出内容，却未必保存生成结果与人工修改之间的关系；一个任务系统可以派单，但它不一定理解任务里流转的是哪份剧本、哪个语言版本、哪道题和哪次发布。

CMS做的事情，是把内容、动作和责任绑定到同一个内容身份上。系统不只保存“一个文件”，还要知道它是什么、属于哪个项目、当前是哪一版、引用了什么、为什么进入这个状态、谁确认过，以及发布以后影响哪些用户端内容。

CMS不能靠功能数量来判断。最小的CMS只管理一种内容，也可以成立，只要它能给内容建立稳定ID和结构，保存版本，推进一条状态链，限制关键操作，并完成一次可追溯的交付。一个后台即使有几十个菜单，如果所有人仍靠文件名辨认版本、靠群聊确认谁审核过，它也没有接住内容生产。

AI让CMS开始管理生成过程

传统CMS并不落后。成熟CMS很早就有结构化字段、多人协作、版本管理、权限和跨渠道发布。企业原来的系统如果能承接新的内容对象和生产流程，完全可以在上面扩展AI能力，不需要为了“AI Native”这个名字重做一遍。

变化主要发生在CMS要管理的范围。

过去很多内容系统围绕一个边界清楚的主对象运转。电商CMS围绕商品和SKU管理标题、主图、详情、价格与上下架；视频平台围绕视频管理源文件、封面、转码、审核和发布；音乐平台围绕歌曲、专辑、歌手和版权完成入库。

AI把大量生产过程变成了需要管理的业务记录。

一条最终视频背后，可能有源剧本、分镜、参考素材、Prompt、模型参数、多个生成批次、人工挑选、局部重做、不同语言版本和派生课程。一道题可能由Agent根据知识点生成，先经过系统校验，再被教研修改，之后由负责人审核并冻结成发布版本。

如果CMS只保存最终视频和最终题目，团队会失去关键上下文。

线上发现字幕错误时，无法确认它来自哪份剧本；某批题目通过率很低时，无法比较是知识点定义有问题、Prompt变了，还是模型版本变了；想复用表现好的内容时，也只能复制成品，无法复用已经验证过的生产配置。

AI CMS需要把AI生成当作生产链上的正式任务：任务读取哪个内容版本，使用哪个Agent、Prompt和模型，生成了多少候选，哪些被自动规则拦截，哪些被人修改、退回或采用，失败以后重试还是交给人。只给旧CMS加一个聊天框，接不住这条生产链。

CMS不需要保存所有日志、Token和中间结果，只需保留足以支持业务解释、审核、复用与追溯的信息；纯技术调试日志可以留在模型网关和日志系统里。一条记录是否进入CMS，要看它以后会不会影响内容身份、质量责任、版本关系或者再次生产。

从一部AI短剧，到一门语言课程

AI短剧这套产品从中文剧本出发，生产不同语言等级的短剧内容，再从正式台词中提取知识点、生成题目、制作剧情与互动视频，最后把这些内容组装成可以在App里学习的课程。短剧生产和题库只是其中的两个环节。

对用户来说，看到的是一集短剧、片中互动题和剧后练习。对内容团队来说，背后却是一条跨编导、本土化、教研、设计、视频制作、产品和技术的生产线，其中还有多个Skill和Agent参与翻译、分级改写、审核与出题。

这条业务先把生产拆成四个板块、18个步骤，再决定CMS需要哪些模块：

第一段负责把中文源剧本变成经过专家和人工确认的各等级正式剧本；

第二段从正式台词里匹配知识点，由Agent生成候选题，再交给系统和教研审核；

第三段生产剧情视频、字幕、互动题和文本练习题；

第四段把这些原子内容组装成课程，完成自动检查、人工确认和版本发布。

这样拆分以后，每个团队都能看到自己拿到什么、交付什么，不会出现“我这边已经完成”，下游却无法使用的情况。CMS需要接住哪些节点也随之明确：哪些内容必须入库，哪些只是过程稿；哪些环节由系统自动检查，哪些必须人工确认；某一步失败以后应该退回到哪里。

例如，专家审核剧本需要交付改写后的基准级剧本、带修改原因的标注稿、问题汇总报告和审核状态。随后其他语言等级的Agent只能以专家基准稿为剧情基准，调整词汇、句长和语法复杂度，不能顺手改掉人物关系和关键信息。

到了出题环节，Agent需要读取已经确认的知识点ID、语言等级、学习方式和正式题型规范，输出题干、选项、唯一答案、反馈与素材信息。

系统先检查字段、题型结构和资源，教研再检查知识点对应、难度、答案唯一性、题干与剧情语境，不通过时可以直接编辑，也可以带着问题原因返回再生成。

课程发布前，系统要确认短剧至少有一集且集序连续，每集正片与字幕有效，每集至少关联一个合法知识点，片中题已经发布且时间点合法，每个知识点至少有一道可用文本练习题，媒体、语言等级和关联关系全部有效。任何一项失败，都要退回对应的内容负责人，不能带病发布。

CMS最终管理的是一组存在依赖关系、审核责任和发布条件的内容资产。

先有端到端生产链，才有产品架构

很多CMS项目一开始就画产品架构：左侧一个导航，下面放内容管理、素材管理、标签管理、用户管理和数据看板。这样的图很快能画出来，但它没有回答为什么需要这些模块，也无法判断哪个模块应该先做。

产品架构不能从后台菜单里猜，它要从生产链里长出来。在这套流程里，每一步都要写清输入、负责人、执行动作、完成规则、输出和失败后的退回位置。

同样是一份“剧本”，在不同节点的业务含义并不相同。中文源剧本审核通过后，才允许进入分级翻译；专家基准稿确认后，才允许生成其他等级；各等级正式剧本确认后，才允许提取知识点和生成题目。只在文件夹里保存几份Word文档，无法表达这些进入条件和依赖关系。

端到端流程还决定了系统边界。入库环节有一条很关键的规则：

只有经过人工确认、最终会被用户看到或使用的内容进入核心CMS；专家标注稿、过程报告和其他中间文件，可以继续留在生产工具里。

“全都存进CMS”并不等于完整。过程文件过多，反而会让核心内容库难以辨认正式资产。CMS需要保存正式内容、必要版本、审核结论和足够的来源信息；生产工具负责承载高频创作和临时过程；日志系统保存技术运行细节。三者通过稳定ID建立联系，不必物理上塞进同一套数据库。

生产工具负责创作、翻译、改写、出题和视频制作，CMS负责管理正式内容的身份、版本、状态、审核、关系和发布，App服务端与数据系统负责分发内容并把学习结果传回来。CMS不需要取代全部生产工具，它要保证这些工具处理的是同一套内容身份。生产工具写入候选内容，CMS保存生成批次和原始输出；审核通过后形成正式版本；App只读取已发布内容；正确率、耗时、跳过和反馈再根据内容ID回到题目与知识点。

产品架构说明用户通过哪些模块完成业务，系统架构说明这些模块与Agent、媒体处理、App和数据平台怎样协同，端到端流程说明一份内容怎样穿过它们。三者讲的是同一件事的不同侧面，彼此不能替代。

CMS到底要管理哪些对象

对象是CMS最基础也最容易返工的部分。后台页面可以改，字段也可以补，但如果一开始把两个应该独立管理的东西塞进同一条记录，后面的版本、权限、接口和数据回流都会变得别扭。

落到CMS里，第一批需要独立管理的对象有六个：知识点、题目、标签、生成批次、审核记录和发布版本。

知识点是Agent出题和人工审核的上游标准，有自己的等级、状态、版本和引用关系。题目有题型、答案、解析、素材、审核和发布生命周期，需要被课程与复习系统调用。标签既用于展示和筛选，也会约束生成和批量操作。生成批次保存一次Agent任务的参数、版本和结果集合，审核记录保存质量判断与修改责任，发布版本则是线上系统实际调用、可以替换和回滚的冻结快照。

端到端生产链里还存在剧本、剧集、短剧、视频、字幕、人物、角色、视觉资产、片中互动题包、文本练习题库和课程。它们不一定全部放在同一个模块里，但都需要稳定ID和清楚的关系。

每个对象里要放什么，也只能从业务倒推。这个项目里的知识点要约束Agent生成和教研审核，题目要能回到知识点、正式台词、生成批次和发布版本，所以两者的数据结构会比普通题库复杂。

判断它要不要成为独立对象，主要看它有没有自己的生命周期、是否会被多处引用、能不能独立审核或复用，以及变化后会不会影响其他内容。这些关系比字段数量更重要。

之前在昆仑还接触过一个内容生产社区项目，叫SkyReels Community。

用户可以分享成片、可查看的画布项目、Prompt、Agent和模板；其他用户可以在权限允许时复制某个生产要素，或者复制整个项目继续创作。

这个社区后来没有上线，它能提供的主要是产品设计阶段暴露出的CMS问题。

如果社区只保存最终视频，它只是内容展示；一旦Prompt、Agent、模板和项目副本可以独立复用，就必须处理源项目与发布快照、复制与继承、查看与下载、源内容删除后派生项目是否继续有效等问题。

它和短剧课程业务不同，遇到的CMS问题相同：

只要生产过程里的某个元素拥有独立生命周期和复用价值，它就开始成为CMS要理解的对象。

任何方案都没有统一标准

PRD没有通用模板。不同行业、不同公司，甚至同一家公司里的不同产品组，写法都会差很多。新闻CMS、电商CMS、游戏内容后台和AI短剧CMS管理的对象、角色、风险、上下游都不一样，最后落进文档里的章节当然也不会一样。

这篇文章只是用我正在梳理的AI短剧CMS项目做一次拆解。它能说明一条内容生产线怎样变成CMS里的对象、状态、权限、Agent任务和发布规则，但不能说明“做CMS就该写这十二章”。

即便你也在做CMS，也不要照着目录、字段和模块直接套。先看自己的业务怎样生产内容，谁在使用系统，哪里最容易出错，再决定CMS如何设计，对应的CMS-PRD文档里需要写什么。

这类内部PRD还会带着很多项目自己的痕迹。有些内容是专门写给教研、研发或者某个上下游团队看的，有些规则是评审以后补进去的，还有些模块只是为了接住公司现有系统。它更像一份持续生长的项目记录，会有补充，也会有补丁，不是什么标准答案。

这套项目需要先确定系统要接住哪段生产链，再确认哪些内容需要独立管理、谁能推动它、AI在哪些环节参与、什么条件下可以发布。页面和模块只是这些业务决定最后在产品里的落点。

业务定位决定CMS会被做成什么

在项目定位里，CMS被定义为教研资产生产、审核、发布和追踪的中台。题目主要由Agent批量生成，教研负责维护知识库和标准，审核、修改与再生成候选题，控制发布并追踪质量。

这两句话直接改变产品重点。如果把它当普通题库，首页很可能是“新建题目”；如果把它当AI出题生产系统，高频入口应该是候选池、审核队列、批次筛选、原始生成与人工版本对比、问题标签和再生成。

这套业务当前先把完整目标态写清楚，没有直接按一期、二期拆分。这也是项目自己的选择，不代表PRD都要这样写。进入排期时仍然要单独切MVP，否则完整目标很容易被误解成第一版范围。

权限来自责任和风险

“管理员、普通用户”支撑不了这条业务。

教研要维护候选内容和发起再生成，审校负责通过或退回，负责人掌握发布、下架和高风险变更，内容团队与产品技术主要读取正式内容和运行记录。这组角色直接对应生产线里的责任分工。

权限也不能只看角色名称，还要看它正在操作什么内容、内容处于什么状态、操作会影响多大范围。已发布题目不能直接覆盖，批量下架和知识点废弃需要确认并留下记录，这些都是从业务风险里长出来的。

状态决定系统允许发生什么

题目会经过候选、草稿、待审核、退回修改、审核通过、已发布、已下架和已归档。Agent生成的内容先进入候选，提交后才进入待审核，审核通过以后才能发布；被退回的内容重新进入修改，已发布内容退出线上时先下架，最后才归档。

这些状态会直接控制后台操作。“候选”代表Agent刚生成、还没有人确认；“审核通过”代表质量已经确认，但还没有上线；“已发布”代表用户端正在调用，不能直接覆盖。每个状态都会改变谁能操作、能做什么、失败后退到哪里。

AI生成必须成为可追踪的生产任务

Agent出题在系统里是一项可以追踪的生成任务：Agent读了哪些知识点和正式台词，用了哪版Prompt，生成了哪一批候选题，哪些被系统拦住，哪些被教研修改、退回或者采用。

这个项目会保留原始生成结果、人工修改版本和再生成关系。以后某一批题目的通过率突然下降，团队才能继续往回找：是知识点变了、Prompt变了、模型变了，还是审核标准变了。这里保存哪些参数、哪些字段，完全由这条追溯需求决定，换一个业务就会有不同的选择。

人工审核接管AI的质量判断

Agent产出的题目先进入候选池，系统检查结构、必填信息和资源，教研再判断知识点是否匹配、难度是否合适、答案是否唯一、题干是否符合剧情语境。审核工作台把原始内容、当前版本、生成来源和问题原因放在同一个操作现场里，让教研能够修改、退回、弃用或者带着问题重新生成。AI无法稳定判断的质量问题，由教研负责。

发布会生成一份正式版本

题目通过审核后，还要确认它依赖的知识点、媒体资源和关联关系全部有效，才能成为线上内容；发布后，当前版本被冻结，修改只能创建新草稿，重新审核以后再替换线上版本。出了严重问题，可以下架或者回滚到上一版。

团队需要明确哪一版正在被用户使用，以及谁有权替换它。页面不让编辑还不够，前端、组卷、缓存和服务端都要认同同一个发布版本。

CMS不能停在内容入库

Agent系统从CMS读取可用知识点和规则，再写回候选题与生成记录；App、复习和组卷系统只读取已发布版本；数据系统把正确率、耗时、跳过和用户反馈传回来。

CMS处在这几套系统中间，靠稳定的内容ID和版本把它们接起来。

数据回来以后还要能推动下一步动作。知识点覆盖不足就补题，某个Agent版本的退回率突然升高就检查生成策略，线上正确率异常就重新审核或者下架。如果指标只能看，不能回到具体内容和负责人，生产闭环仍然是断的。

验收标准要能跑一条真实内容

验收要拿一条真实内容跑完生成、系统校验、人工修改、审核和发布，再从用户端读到正确版本；还要故意制造一次驳回、一次再生成和一次发布后回滚，看看内容能不能回到正确的人和正确的状态。只检查知识库页面、题目页面和审核工作台是否开发完成，验证不了这条链。

再从用户端往回追：这道题来自哪个知识点和生成任务，AI最初给了什么，人改了什么，谁审核过，现在上线的是哪一版，用户表现异常后又会回到哪里。能顺着同一个内容ID把这条链查清楚，说明CMS已经接住了业务。

0-1搭建CMS的流程

CMS项目没有固定的文档组合，但推进顺序有迹可循。流程比模板重要，因为后一项决定总是在使用前一项已经确认的业务事实。

先跟着一条真实内容跑完全程

不要先讨论后台有几个菜单。选一条真实内容，从原始输入开始，跟着它经过生成、修改、审核、制作、发布和数据回流。每一次交接都问清楚：上一步交什么，下一步拿什么，谁确认完成，失败后退回哪里。

这一步可以画流程图，也可以先用表格或者文字记录，形式并不重要。“生成、审核、发布”三个词还构不成完整流程。AI短剧项目拆成18步，是因为每一步的产物和责任人都不一样。

再决定CMS接住哪一段