企业官网建设流程全解析

这几年做CMS相关的项目，最明显的一个感觉是：传统的内容管理思路在企业建站场景里越来越吃力。客户问的不再是"你们有多少套模板"，而是"能不能把我们的业务资料丢进去，直接生成一个能用的官网"。我们内部代号为Hantu的这套系统，本来是给中小站点做内容管理的老牌CMS，功能齐全但思维很传统。这次我们把Hantu AI-Gen CMS做了次大重构，瞄准的就是"生成式官网"这个方向，核心变化不是多加几个AI按钮，而是把整个内容管理链路换成了一套以AI生成为中心的企业应用模型。这篇文章就聊聊这次重构背后的设计思路、落地过程中踩过的坑，以及给同样想做AI-Gen CMS或正在做企业数字化官网的朋友一些可参考的经验。

这次重构涉及的面很广：数据建模、生成任务编排、渲染层改造、多租户隔离、安全加固，每一项都值得单独拿出来讲。我会按我们实际推进的顺序来写，先讲为什么选了这个方向，再讲核心设计，然后落到代码和模块实现，最后是问题排查和上线后的数据。如果你正打算把AI能力接入到现有的CMS系统里，或者想从零做一个企业官网生成平台，这篇应该能帮你少走不少弯路。

1. 为什么把Hantu往企业应用方向重构

1.1 老版Hantu的痛点

老版Hantu本质上是一个传统的内容管理系统，它的核心模型是"栏目-目录-文章"这三板斧。技术上说这套模型没有错，但放到企业官网上就特别别扭。企业官网不是博客，它需要产品中心、案例展示、资质证书、新闻动态、招聘入口、多语言站点这些东西，每个模块的结构都不一样。老版CMS要撑起这种复杂度，只能靠自定义字段，结果就是运营人员在建站时要面对几十个字段表单，非技术人员根本玩不转。

另一个痛点是改版成本。企业官网改版频率不低，改版就要动模板。老版模板机制是整体渲染的，也就是说页面是"一整坨"，想换掉首屏的Hero区域，可能要动整个模板文件。我们服务过的一家制造业客户，产品线分成三个事业部，每个事业部的展示逻辑差异很大，用老版做三个子站，光模板就复制了三份。后续改一个公共模块，三份模板都要同步改，维护成本直线上升。

还有SEO这块，企业客户非常看重。老版虽然支持自定义TDK（Title、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生成类业务系统都适用。