这几年做CMS相关的项目最明显的一个感觉是传统的内容管理思路在企业建站场景里越来越吃力。客户问的不再是你们有多少套模板而是能不能把我们的业务资料丢进去直接生成一个能用的官网。我们内部代号为Hantu的这套系统本来是给中小站点做内容管理的老牌CMS功能齐全但思维很传统。这次我们把Hantu AI-Gen CMS做了次大重构瞄准的就是生成式官网这个方向核心变化不是多加几个AI按钮而是把整个内容管理链路换成了一套以AI生成为中心的企业应用模型。这篇文章就聊聊这次重构背后的设计思路、落地过程中踩过的坑以及给同样想做AI-Gen CMS或正在做企业数字化官网的朋友一些可参考的经验。这次重构涉及的面很广数据建模、生成任务编排、渲染层改造、多租户隔离、安全加固每一项都值得单独拿出来讲。我会按我们实际推进的顺序来写先讲为什么选了这个方向再讲核心设计然后落到代码和模块实现最后是问题排查和上线后的数据。如果你正打算把AI能力接入到现有的CMS系统里或者想从零做一个企业官网生成平台这篇应该能帮你少走不少弯路。1. 为什么把Hantu往企业应用方向重构1.1 老版Hantu的痛点老版Hantu本质上是一个传统的内容管理系统它的核心模型是栏目-目录-文章这三板斧。技术上说这套模型没有错但放到企业官网上就特别别扭。企业官网不是博客它需要产品中心、案例展示、资质证书、新闻动态、招聘入口、多语言站点这些东西每个模块的结构都不一样。老版CMS要撑起这种复杂度只能靠自定义字段结果就是运营人员在建站时要面对几十个字段表单非技术人员根本玩不转。另一个痛点是改版成本。企业官网改版频率不低改版就要动模板。老版模板机制是整体渲染的也就是说页面是一整坨想换掉首屏的Hero区域可能要动整个模板文件。我们服务过的一家制造业客户产品线分成三个事业部每个事业部的展示逻辑差异很大用老版做三个子站光模板就复制了三份。后续改一个公共模块三份模板都要同步改维护成本直线上升。还有SEO这块企业客户非常看重。老版虽然支持自定义TDKTitle、Description、Keywords但内容架构混乱的时候栏目规划不合理关键词布局就没法体系化。客户自己说不清楚我们应该做哪几个关键词我们做技术的也不能替他们做内容策略。这其实不是CMS工具的问题是传统建站流程里缺了一个能帮客户梳理信息架构的角色。1.2 AI-Gen带来的机会转折点出现在大模型能力成熟之后。我们当时测试了一些通用对话产品发现它有一个特别适合企业官网的场景你给它一段公司介绍它能把公司的主营业务、目标客户、核心优势拆得清清楚楚。这正好解决了我们上面的痛点——企业建站最难的其实就是从一堆原始资料里提炼出信息架构和文案体系。传统做法是客户提供资料包项目经理整理需求策划出栏目树再让编辑填内容一套下来两三个星期。AI-Gen想做的就是把这套流程压缩到一个平台上用生成式AI辅助甚至自动完成架构和内容的生成再由人来审核把关。我们把企业应用方向确定为重构的大前提意思是Hantu不再追求做成全能型CMS而是深耕企业官网这个具体场景。企业官网的共性需求是明确的品牌形象统一、产品信息准确、内容更新可管控、SEO可持续优化。AI生成在这个场景下的职责不是做一张花里胡哨的营销页而是输出结构正确、事实准确、可运营的内容骨架。所以重构的核心不是堆AI功能而是设计一个围绕生成-审核-发布-迭代闭环的内容管理系统。2. 生成式官网的核心设计思路2.1 从内容管理到生成管理老版Hantu的核心对象是内容系统做的事是录入、编辑、发布、下线。新系统里我们加了一个更上层的对象叫生成任务整个链路变成了品牌资料上传、意图解析、信息架构生成、页面区块生成、文案生成、审核发布。这不是在原有CMS外面套一层AI壳而是把内容在系统里的生命周期重新定义了一遍。具体来说我们建了三层模型。最顶层是企业实体对应一个真实的企业客户包含企业基本信息、品牌规范、资质文件等。中间层是站点结构由栏目树和页面组成每个页面由若干区块构成。最底层是素材包括文本、图片、产品参数这类实际呈现的内容。AI-Gen引擎主要作用在前两层它能根据企业资料自动建议栏目结构自动生成区块内容建议但最终落到页面上的一定是要有明确类型的结构化数据不是一段自由文本。这套分层最大的好处是AI生成的产物从第一秒开始就是可管理、可局部替换的而不是一次性生成一个不可拆解的HTML。2.2 企业官网场景的字段模型重构这里要展开讲讲字段模型。我们参考了一些成熟建站方案的做法设计了一套面向企业官网的标准区块Schema。每个区块都有明确的字段定义比如Hero区块包含主标题、副标题、背景图、主CTA文案、主CTA链接这五个字段产品列表区块包含产品分类、排序规则、显示条数、是否展示参数Tab等字段。为什么一定要结构化因为生成式AI输出不稳定如果让模型直接输出HTML片段前端渲染是爽了但后续的编辑、换肤、SEO关键词调整就全废了。用结构化Schema约束输出AI-Gen引擎生成的是符合Schema的JSON数据前端用对应的区块组件消费这些JSON。这样有几个直接好处运营可以在后台单独改某个区块的标题而不是整块替换设计师改视觉样式时只动组件模板SEO优化时可以把每个字段的权重纳入TDK生成规则。当然结构化也带来了模型构建上的复杂度。我们为每个区块类型维护了JSON Schema定义和对应的UI配置表单Block Schema注册中心负责统一管理。AI-Gen在生成内容时prompt里会携带目标区块的完整Schema描述强制模型按字段输出并且服务端会做二次校验字段缺失或者类型不对就直接判负让模型重新生成。实测下来字段级校验能把内容格式正确率从初期的不到70%提升到95%以上。2.3 生成任务的Pipeline设计生成式官网不是调一次大模型就完事。我们把生成过程拆成五个阶段每个阶段都有独立的输入输出和人工确认点第一个阶段是品牌理解。客户上传企业简介、产品手册、资质文件后系统先做文本抽取和摘要生成一份品牌事实清单列出公司全称、成立年份、主营业务、核心产品、资质证号这些关键事实。第二个阶段是信息架构生成基于事实清单生成推荐的栏目树比如首页、产品中心、解决方案、关于我们、新闻动态、联系我们每个栏目附带建议的页面结构和SEO关键词。第三个阶段是区块规划把每个页面的内容拆成区块序列。第四个阶段是内容生成针对每个区块生成文案和配图建议。第五阶段是视觉建议给出配色、字体、风格关键词对接给前端模板选型。这个Pipeline有一个关键原则每个阶段完成后都生成一个草稿版本但不会自动发布。运营人员可以在后台看到AI生成的栏目树手动增删改确认之后才会进入下一阶段。为什么要加这么多人工确认点因为企业官网的内容准确性比效率重要得多。AI可以把三天的工作压缩到三小时但如果生成的解决方案内容里把客户的产品参数搞错了上线后对企业形象的影响是灾难性的。人工确认点就是给这套系统上的安全阀。3. 核心模块实现与实操细节3.1 AI-Gen容器与渲染层在技术选型上我们没有把AI逻辑直接塞进PHP后台。老版Hantu的后端是PHP做内容管理很成熟但AI生成逻辑涉及到大模型API对接、prompt管理、流式输出、限流重试这些事业务形态完全不一样放在PHP里硬做会非常别扭。所以我们拆了一个独立的AI-Gen服务用Node.js编写专门负责跟模型API通信。后台PHP只做两件事发起生成任务、接收生成结果。AI-Gen服务内部我们抽象了一个容器的概念。每一个生成任务就是一个容器容器里装载了任务类型、目标Schema、企业事实清单、历史生成记录和prompt模板。容器的执行流程是固定的校验输入、构造prompt、调用模型、解析输出、Schema校验、存储结果。这套容器机制最大的价值是可观测性。我们给每个容器分配了一个唯一TaskId从创建到完成的每个步骤都记录日志。有一次线上反馈生成结果里企业资质信息错误我们很快排查到一个字段来自某次历史调用的缓存数据当时就是通过TaskId串联出来的。渲染层我们没有另起炉灶还是用老版Hantu的PHP模板引擎做服务端渲染前端通过Vue做交互增强。页面内容不是运行时调用AI生成的而是发布时把区块JSON渲染成HTML后落到静态文件里。这样兼顾了SEO和访问性能也为后面的CDN加速留了空间。3.2 动态组件与区块机制前面提到的区块机制不只是一个数据模型它同时也是前端组件体系。我们的Block Store里注册了目前企业官网常用的二十多个区块组件包括Hero区、Logo墙、产品网格、按需折叠的Tabs、案例时间线、数据大屏、表单组件、地图组件等等。每个区块组件都有三个文件Schema定义、前端Vue组件、后端渲染模板。这类机制的实际收益非常明显。客户之前那个三个事业部的案例重构后每个事业部的子站点只需要选择不同的区块组合即可不需要复制模板。而且AI-Gen引擎的可控性也提高了因为它输出的区块一定是注册过的组件不会出现模型自己创造了一个不存在的样式结构。对于AI-Gen提示词的构造来说我们会在每个区块的prompt里附带组件支持的能力说明比如某个区块可以显示1到12个产品卡片超过12个就翻页模型在填充数据时会自动遵守这个上限。这里分享一个细节区块组件的Schema一定要和前端组件的props强绑定最好用同一个JSON文件生成两端的类型定义避免后台配置项和前端渲染不一致。我们初期没做这个约束出现过后台能选一个高级布局前端组件却不支持的情况后来改成由Schema统一驱动两端配置这类问题就消失了。3.3 内容审核与人工回滚AI生成内容必须有人工审核这个我们内部定了铁律。为了让人工审核的效率高一点我们做了一个专用的内容比对工作台。在审核页面上左边是AI生成的草稿右边是正在线上运行的旧版本两个版本做逐字段diff差异部分高亮标出。运营人员可以直接在AI草稿上修改字段改完后点击确认发布系统把新版本写入发布表同时把旧版本完整留存。这个功能看起来简单但实际上是我们整个系统里使用频率最高的模块。企业客户的内容运营人员普遍对AI生成的内容抱有怀疑他们审核时最想搞清楚的是AI在哪些地方改了我的旧内容。diff高亮能让他们30秒内完成一次审核不再需要通读全文找不同。回滚机制也一样每次发布的版本都带完整快照不止有内容字段还包含当时区块Schema的版本号避免旧版本在新Schema下渲染出问题。另外我们做了一个细节优化AI草稿在生成后不会覆盖原来的内容而是以待审核版本的独立状态存在。运营确认前的所有操作只影响草稿不影响线上页面。这点特别重要——我们见过不少系统直接把AI生成结果写回内容表导致运营还没审核完线上页面已经在变化这在企业场景里是绝对不能接受的。3.4 性能优化与缓存策略生成式官网听起来很智能但在性能上要比普通CMS更敏感。我们让AI生成的页面在发布时静态化访问路径上完全无AI调用所以线上性能取决于静态缓存和CDN。我们做了三层缓存第一层是页面静态化。发布任务触发时后台把最终渲染结果写为静态HTML。企业官网里新闻、案例这种低频更新页面静态化后几乎零查询。第二层是在PHP层加Redis缓存主要缓存区块JSON和导航树方便做动态数据注入比如联系方式、模板配置这些。第三层是CDN用来加速静态HTML和图片资源。有一个容易被忽视的性能问题AI生成任务本身如果处理不好会拖垮正常的后台使用。我们把生成任务放进消息队列由独立的Workers异步执行不占用PHP后台进程。队列里还要做好优先级调度——如果客户正在前台编辑尝鲜版页面他发的重新生成某区块文案任务应该比批量生成全部页面优先级高。我们在队列消费端对任务按企业ID做隔离避免某家企业一次提交20个生成任务把队列资源占满影响其他客户。实测下来这个隔离还是挺重要的初期没做的时候一个大企业的批量生成任务进来整个后台的生成接口都要排队等交互体验很差。4. 企业应用落地中的问题排查与避坑4.1 生成内容重复及事实幻觉落地过程中最让人头疼的问题之一就是生成内容重复。我们遇到过客户导入了20个产品数据AI生成的20段产品描述看起来似乎不太一样但仔细对比会发现大量句式是重复的只有产品名称不同这种内容对SEO很不友好搜索引擎会把它们当成低质重复页。排查下来问题出在两个地方。一是prompt里对差异化要求的描述过于笼统模型自动走了最省力的句式模板二是背景上下文太长模型在适应长上下文时倾向于复用前半段已经生成的句式。我们后来在生成任务里增加了参考例句和禁止词汇两个控制项。从已有内容里选几段风格差异很大的文案作为参考例句让模型模仿其结构同时把常见的高频模板句加入禁止列表比如我们致力于……作为行业领先……这类出现一次就重新生成。事实幻觉的问题我们也遇到过生成的公司简介里把客户的成立年份写错了一两年。后来我们在品牌理解阶段生成的事实清单变成了硬性约束prompt里明确要求事实清单里没有的信息一律留空严禁推断或补全。就这一条规则线上事实性错误降低了80%以上。4.2 SEO跳转异常与收录问题生成式官网上线后碰到过一个典型问题页面被搜索引擎收录后通过搜索结果点进来的用户会被跳转到另外一个奇怪地址直接导致收录失效、排名下降。排查过程很有意思不是安全入侵也不是恶意代码而是CMS自身的历史重定向逻辑和新的AI生成预览路由冲突了。老版本CMS为了用友好URL管理详情页写了一套301跳转规则。新系统为了做AI生成任务的预览路由规则里加了一条带/preview/{taskId}的路径。问题出在SEO动态URL规则里有些旧链接匹配到了preview路由系统就顺手做了301到预览地址。预览地址虽然内容正常但带着TaskId这类参数搜索引擎认为这是不稳定页面收录之后就掉权。解决办法有两步第一给所有preview路由统一加了X-Robots-Tag: noindex响应头并且在robots.txt里明确禁止爬取/preview/目录第二检查了所有重定向规则把旧URL到新页面的跳转从301改成带Canonical标签的200页面避免中间链路过长。上线后两周收录恢复正常。这里要提醒的是生成式CMS会动态创建大量临时页面如果不从根上把预览页和正式页的抓取策略分开很容易出现这种索引到临时页的问题。建议在开发阶段就给所有预览临时路由打好noindex标记不要等到SEO出问题再改。4.3 多站点数据隔离与权限控制企业应用方向意味着一个Hantu实例会承载多个客户站点多租户隔离是必须做的。最基础的是数据库层面的隔离每张业务表都要带tenant_id字段并且所有的查询强制走租户过滤器不能靠开发人员自觉。我们写了一个统一的Repository基类查询前自动拼接租户条件把这个约束固定在了代码框架层。谁要是绕过基类自己写了原生SQL直接查表code review的时候直接打回。除了数据隔离权限控制也很关键。企业客户那边的用户角色不仅是管理员和编辑还可能要细分到只能维护产品中心只能查看内容统计这种程度。我们基于RBAC模型做客制化但特别增加了数据范围这个概念。同一个角色可以配置成只能管理本租户站点也可以配置成跨站点管理。这个功能在服务商场景下特别实用——我们自己也用Hantu给多个服务商开子账号服务商运营人员只能看到自己名下的那批企业站点不能越权看别的服务商。还有一个容易忽视的细节企业内容里经常包含客户联系方式、资质证号、真实人员姓名这类个人敏感信息。在AI-Gen生成任务的过程中日志和任务上下文中会携带这些信息。我们对日志链路做了脱敏数据库存储时证件号、手机号采用加密字段生产环境下日志工具里只显示脱敏后的前几位。这块合规要求不能糊弄企业客户非常在意。4.4 安全加固SQL注入与上传接口异常生成式CMS因为引入了AI服务攻击面比传统CMS更大。首当其冲的是SQL注入老版Hantu早期代码里有些统计报表功能是用字符串拼SQL写的重构的时候我们专门做了全量SQL审计。光靠框架的参数绑定还不够一些老模块的高级搜索功能直接把前端传来的排序字段拼进了order by子句这种位置参数绑定处理不了必须做白名单过滤。我们整理了一张排序字段白名单表跟业务字段一一对应前端传来的参数只当key用真正的SQL列名从白名单映射里取。上传接口异常也是企业应用里容易踩的坑。具体表现是用户上传产品图片偶发提示请求上传接口出现异常前端是同一套代码但有的站点稳定有的站点频繁报错。排查下来的原因有三类一类是服务器临时目录权限问题图片上传组件依赖系统临时目录做分片权限不对就失败第二类是上传插件配置了单文件大小限制但企业客户经常上传拍的照片单张轻松超过10MB直接撞到限制第三类是一个比较隐蔽的问题上传请求经过CDN时CDN对请求体大小和Content-Type有默认限制大文件会被CDN端拦下来而这个错误信息没有原样透传给前端导致前端提示让人摸不着头脑。解决的思路是统一定义上传接口的异常返回格式把错误码细分到具体环节前端拿到错误码后给出准确的用户提示。另外所有上传文件都做扩展名白名单和MIME校验图片文件还要二次读取文件头判断真实类型防止伪装成图片的木马文件上传成功。5. 上线后的实测效果与后续扩展5.1 实测数据与客户反馈重构后的Hantu AI-Gen CMS目前在内部和签约客户中测试了三个多月把过程中的数据分享给大家做个参考。建站交付周期方面传统方式做一家企业官网从需求梳理到上线通常要两到三周现在通过AI-Gen生成初版内容加人工审核修正大部分项目能在三到五个工作日内完成效率提升明显。内容采纳率大概在70%左右也就是说AI生成的文案里大约七成经过小幅度修改或直接通过审核就发布了。这个数据说不上惊艳但对内容生产和运营团队来说已经能节省大量基础工作量了。有一个数据值得单独说就是人工审核返工率。第一批测试的时候客户对AI生成内容的修改率特别高主要集中在产品参数和品牌宣传口径上。后来我们把事实清单机制做强了又把品牌风格指南加入了prompt返工率才明显降下来。所以如果让我给其他做AI生成内容产品的团队一个建议我会说别把大模型的即兴发挥当特色在2B场景里严谨、准确、可复用才是第一位的。客户侧的反馈也是很好的改进方向。有的客户提出想用AI直接生成英文版页面因为他们有出海业务以前还要花几千块钱找人翻译。有的客户希望在内容管理后台加入热力图报表看哪些区块的点击率低然后让AI给出优化建议。这些需求都指向同一个趋势AI-Gen CMS不只是建站工具它未来可能要承担企业官网持续运营优化的角色。5.2 还能扩展的方向这次重构解决了从无到有的问题但后面的空间还很大。第一个要做的就是多语言生成。企业出海的场景不是简单把中文翻译成英文而是要基于本地化关键词优化和表达习惯重新生成。我们正在做的方案是给AI-Gen容器加入目标市场上下文让它生成英文文案时自动调整内容策略而不是逐句翻译。第二个是跟业务系统打通。企业产品参数如果来自ERP或CRM应该通过接口自动同步到CMS的数据表AI再基于真实业务数据生成内容这样能彻底解决事实准确性问题避免人工维护两份数据源。还有一个我认为很有价值的方向是智能迭代。现在生成式官网是一次性生成上线后内容和栏目结构就基本固定了。理想状态是系统能结合访问数据和转化数据定期分析哪些页面访客流失率比较高自动生成建议文案或者结构优化方案由运营确认后一键应用。这等于把官网从交付物变成了持续生长的产品也是我把Hantu重构往企业应用方向推进的最终目标。写在最后这次重构让我收获最大的一点是把AI接入CMS技术上的难点远没有业务设计上的难点大。难的是你不能再用内容录入工具的思维来做系统而是要搭建一个AI生成、人工把关、实时回滚、持续迭代的新工作流。老Hantu的底子如果说是一个Excel表格管理工具那么新的Hantu AI-Gen CMS更像一个有主编的编辑部AI是执笔助理运营编辑是主编主编可以改稿、退稿、撤稿所有决策权都在人手上。最后分享一个我们踩过的比较深的坑做AI内容生成功能千万别把生成结果直接往线上内容表里写一定要走草稿-审核-版本发布-历史回滚这一套流程。没有这套护栏AI越强大线上出事故的概率就越高。这个原则以后做任何AI生成类业务系统都适用。