企业官网建设流程全解析

运营组的同事每天早上到工位，先手工刷一遍各渠道的报道、评论和话题数据，再复制进表格写日报。遇到品牌被热议，梳理来龙去脉就要大半天。我们做数字公关AI中台Infoseek（内部项目代号）的起因就是这么朴素：把这些高重复、强时效、吃数据的工作，交给一套系统自动化完成。这篇文章从技术视角复盘Infoseek的架构设计与落地实践，讲清楚我们为什么这么拆、哪些决策影响了全局、踩过哪些坑、哪些经验可以复用。

1. 先聊清楚：中台要解决的是公关侧的什么难题

在动手画架构图之前，团队花了两周做业务访谈。这步最容易被跳过，但恰恰最重要。中台项目最容易犯的错，是技术栈堆得很漂亮，最后发现业务方根本不买账。所以我们当时定的规矩是：先别聊AI，先聊痛。

1.1 公关业务流里的四大高频场景

把运营组、品牌组、高管沟通组的日常工作拉出来看，重复度最高的其实是四件事：

第一，舆情梳理。每天来自新闻网站、社交平台、行业论坛的公开内容少则几百篇、多则几千篇，需要判断哪些和品牌相关，情感是正向还是负面，热度是在涨还是在跌，然后整理成摘要。这个场景的特点是数据量大、时效要求高，但分析逻辑相对固定。

第二，内容生产。新闻稿、社交媒体文案、活动通稿、口径问答，每月产出量不小，而且每一篇都要符合品牌基调，引用准确的数据。过去靠资深文案逐字逐句写，速度慢，新人写出来风格又不统一。

第三，媒体关系支持。公关人员发稿前要查目标记者关注什么领域、某家媒体偏好的内容形态、我们和对方的历史互动情况。这些信息散落在不同人的笔记和表格里，找起来非常费劲。

第四，效果衡量。每一轮传播做完，需要看声量变化、情感有没有改观、话题在哪些渠道发酵、哪些稿子带来了实际讨论。这个环节过去大量依赖人工统计，数据滞后且不完整。

这四个场景共同的特点是：高重复、强时效、吃数据。它们天然适合被中台承接，但真正决定中台成败的，不是AI能力本身，而是它能不能把这四件事背后的数据打通。公关业务的链路是连续的：监测、分析、策划、写稿、审稿、发布、追踪，每一步都会产生数据，下一步又需要这些数据。如果数据在环节之间断掉，AI再强也只能是信息孤岛上的摆设。

1.2 为什么不能靠"买一个AI工具"解决

很多人问我，市面上现成的AI写作工具、舆情监测软件已经不少了，为什么还要自己做一个中台？我的回答是：单点工具解决不了链路问题。

拿写稿这个场景举例。一个AI写作工具能帮你把文字顺滑地生成出来，但它不知道你昨天监测到了什么热点，不知道你历史稿库里某种句式的使用习惯，也不知道你正在接触的媒体偏好什么风格。它只是把字写出来，不具备公关业务的前后文。换句话说，买来的AI工具只是一个"打字快一点的编辑器"，而不是懂公关业务的生产系统。

我们的第一版原型就是这么翻车的。当时还很天真地接了一个大模型就直接给运营组用，结果运营的同事一句话把我们都问住了："你生成的稿件里引用的产品参数是从哪来的？为什么和官网不一致？"那一刻我们才意识到，没有数据底座支撑的生成能力，在严肃的公关场景里基本不可用。所以最终选择了自建中台，把数据采集、知识库、AI能力、业务流程沉淀成一套平台，让多个业务方共同使用，而不是每个团队各买各的工具。

1.3 能力边界：做能力平台，不做业务替代

做中台，最怕的是权力边界不清楚。Infoseek从一开始就定了几条原则，整个生命周期里从没动摇过。

系统只做分析、生成、检索、评估这些能力输出。最终的对外发布、稿件签发、媒体沟通，全部由人完成。不做任何绕过审批的自动发布，不做未经验证就直接对外回复的功能，也不碰任何非公开数据的采集。这几条边界让系统上线审批变得顺利很多，也让业务团队敢于把数据接进来，因为他们知道系统不会替他们做决定，只会帮他们做得更快。

这个边界意识在后来的真实使用中起到了关键作用。业务方愿意每天打开系统看预警、看摘要、用草稿，是因为他们始终掌握着最终决定权。系统给出的永远是"建议"，而不是"结论"。

2. Infoseek的分层架构与核心模块

整体架构的构思从三个问题开始：数据从哪里来、能力给谁用、流程怎么走。而不是从"要上什么新技术"开始。这样想的好处是，技术选型始终服务于业务结构，而不是反过来被新技术绑架。

2.1 五层架构里，每一层都在挡什么复杂度

Infoseek整体分成五层，每层解决的复杂度各不相同。

接入与采集层。对接新闻、社交平台、行业论坛等多种公开数据源，负责定时抓取、去重、正文抽取、内容清洗。这一层解决的问题是"数据进得来"，脏数据、重复数据、广告噪声都要在这一层处理干净。

数据层。原始数据统一落对象存储，清洗后的结构化数据进数仓，供离线统计分析；热数据放在向量库和检索引擎里，供在线查询。这一层花的时间比预期多一倍，因为公关场景的数据质量参差不齐，很多源站页面结构经常改，定期就要修解析规则。

AI能力层。通过模型网关提供三类能力：理解类（实体识别、情感分类、主题聚类）、生成类（摘要、稿件、口径问答）、检索类（知识库检索、相似内容匹配）。业务层只调用能力编号，不直接调模型接口。

业务服务层。围绕四个核心场景封装成四个模块：舆情洞察、内容创作、媒体画像、效果评估。每个模块对外提供稳定的内部API。

应用层。对内是工作台Web界面，对外是一组API，供OA、CRM等周边系统集成。用我们自己的话说，前面四层是发动机，最后一层是方向盘。

这个分层的逻辑是：任何一层变动，不影响其他层。换了采集源，AI能力层不需要改；换了模型供应商，业务服务层不需要改。分层的代价是初期开发量会大一些，但它换来了后续半年内持续迭代的从容。

2.2 舆情洞察：从采集到预警的完整链路

舆情洞察是Infoseek最早落地的模块，也是整个中台的数据发动机。完整链路分五步：

数据接入。定时任务按源配置抓取公开文章，用URL指纹去重，对同一事件的多篇报道做归一化处理，避免一个热点被重复计数。

预处理。正文抽取去掉页眉页脚和广告噪声，长文按结构化规则切块，为后续的语义检索做准备。

分析。用领域词典加实体识别，抽出文中的品牌词、产品词、人物词；情感分类采用轻量模型，输出正面、负面、中性三种极性；主题分类覆盖产品、竞品、行业、消费场景等十几个维度。

聚类。把同一事件的多篇报道聚合到一张事件卡片上，卡片里展示发展脉络、主要情感倾向、参与媒体列表。这一步让业务方不再需要逐篇阅读几十篇相似报道。

预警。热度曲线和情感极性变化是预警的核心信号。初期阈值靠经验配置，误报率高；后来改成基于环比和同比的动态阈值，虚报率下降了不少。

这里有个很实用的经验：不要一上来就追求模型精度，先用领域词典加规则把结果跑通，让业务方看到效果，后面再迭代模型。最早的情感分类准确率只有八成左右，但已经比人手快得多。业务方愿意用，后面才有机会改进。

2.3 内容创作：让AI稿件"有据可查"而不是凭空生成

内容创作模块建立在检索增强生成（RAG）之上，核心逻辑是：生成之前，先查。

知识库的构成包括品牌基础资料、产品参数与FAQ、历史优秀稿件库、媒体风格偏好、行业术语表。每次生成任务发起，系统先把用户需求改写成检索query，同时做向量检索和关键词检索，用排序融合算法综合两路结果，召回最相关的内容片段。生成阶段，把召回片段作为上下文组装进提示词，由大模型生成初稿，每段末尾自动标注参考来源编号。

这样做最直接的好处是，业务方可以点开来源编号，核对内容是否有依据。虽然模型仍然可能犯错，但至少每一句话都能追溯，责任边界清晰。在实际使用中，生成初稿被采用的比率从最初的不到三成，提高到后来的七成左右。核心原因不是模型变聪明了，而是知识库丰富之后，模型"有东西可以引用"了，写得不再空洞。

2.4 媒体画像与效果评估：把传播结果变成可量化数据

媒体画像模块解决的是"找对人、说对话"的问题。我们从历史互动数据中沉淀媒体和记者的标签，包括关注领域、内容形态偏好、历史发稿记录、响应速度等。公关人员输入一个选题，系统会基于画像推荐一批可能感兴趣的媒体，并给出角度建议，比如某垂直媒体更关注技术细节，某大众媒体更关注品牌故事。

效果评估模块解决的是"钱花得值不值"的问题。它自动从各渠道回捞数据，计算声量变化、情感极性分布、话题覆盖度、传播层级等指标。这里的难点是归因，即哪些讨论是由我们发布的稿件引发的，哪些是自然形成的。目前的方案是用发布时间序列加内容相似度做近似归因，准确率在合理范围内，已经能满足业务复盘的核心需求。

3. 架构设计里最关键的三个技术决策

整个项目里，技术选型层面的讨论很多，但真正影响架构走向的，其实是三个决策。它们不是最炫的技术，却是让系统能长期演进的关键。

3.1 模型网关：业务层永远不直接面对大模型API

这个决策是我最坚持的一条。理由很简单：大模型市场变化太快，今天这家效果好，明天那家性价比更高；今天某个提示词调优有进展，明天可能就失效。如果业务代码里到处直接调用具体模型的API，每次切换都是一场灾难。

模型网关做了几件事。统一路由：业务方请求"生成一篇活动新闻稿初稿"，网关负责决定用哪个模型来执行。配额与限流：避免某个业务方把预算烧光影响其他人。账单统计：按业务方维度拆分成本，让每个团队看到自己的消耗。提示词版本管理：每次修改线上可回滚。降级策略：模型不可用时自动切换备用供应商或模板模式。

最关键的还是把"能力"和"模型"解耦。业务方只关心能力编号，不关心背后的模型。比如内容摘要这个能力，今天可以指向某个大模型，明天可以指向另一个，业务方无感。这个决策在后来一次供应商价格调整时帮了大忙，我们用了不到半天就完成了全量切换，业务方完全不知道发生了什么。

3.2 冷热分层的知识库与混合检索

知识库是我们踩坑最多的地方，最后沉淀下来的经验是冷热分层加混合检索。

热知识是高频使用的：近90天的舆情报告、最新的产品资料、正在推进的项目材料。这些放在向量库和检索引擎里，随增随查。冷知识是历史归档：过去的年报、老稿库、多年积累的行业资料。这些放在对象存储，离线建立索引，要查的时候再按需加载。冷热分离的核心原因是成本：向量检索索引建在内存里，存太多冷数据既烧钱又拖慢查询。

检索方面，纯向量检索有它的毛病，精确术语和特定写法容易找不到，比如产品型号、特定说法。我们的做法是关键词检索和向量检索并行，再用排序融合算法融合两路结果。改完之后，检索相关性明显提升，生成质量也跟着水涨船高。这一块往往是RAG系统里最容易被忽视却又最值得投入的部分。

3.3 工作流编排：把"监测→写稿→审批→发布→复盘"串起来

公关工作流不是一条直线，它会有分支、会退回、需要人工参与。比如预警触发的"事件简报"流程：先汇总多渠道数据，再自动生成简报草稿，推送给值班人，值班人编辑确认后归档，若有需要再触发下一步应对策略。

我们引入了一套轻量级工作流引擎，定义了几类节点：采集节点负责把外部数据拉进来，分析节点调用AI能力，生成节点产出内容，人工审批节点等待业务方确认，通知节点负责推送消息。每个流程实例有完整的执行记录，出问题可以直接定位到某个节点。

这个决策的价值在于：AI中台不能只提供零散的能力，还要把这些能力编排成业务方熟悉的流程。否则，系统只是给用户一堆API，业务方反而不知道怎么用。有了流程编排，操作入口简单了很多，非技术背景的运营也能顺畅使用。

4. 性能与成本的双重约束：调度和缓存实战

中台类项目经常被质疑"好看不实用"，性能和成本是最容易被打脸的地方。Infoseek在这方面的实战经验，可以总结成三句话：弹性扛突刺、小模型省成本、降级保底线。

4.1 舆情突发时流量涨十倍，架构怎么扛

公关系统的流量特征和一般C端应用很不一样：平时安安静静，一旦品牌出现热议话题，流量会在几小时内暴涨。采集任务增多、分析请求增加、运营组同时打开看板，所有压力挤在一起。

Infoseek做了三件事应对。第一，无状态服务全部支持水平扩容，业务高峰期自动加实例，低谷再释放。第二，所有重任务走消息队列削峰，抓取、分析、生成全部异步化，接口层只负责下发任务和查询结果，前端通过轮询或回调拿结果。第三，对高频查询做带短时TTL的缓存，比如舆情看板数据，几十秒内相同请求直接命中缓存，不重复计算。

最近一次品牌话题突发的实测：QPS峰值到了平时的10倍左右，接口延迟依然稳定在几百毫秒内。能做到这个水平，不是靠单机性能，而是靠架构上的削峰和缓存设计。异步化之后，用户看到的可能是任务状态从"排队中"到"已完成"，而不是页面一直转圈。

4.2 小模型过滤、大模型生成：Token费用这样省

大模型调用一次的成本不低，尤其在舆情分析这种需要批量处理文本的场景，如果每篇文章都丢给大模型做，费用根本扛不住。

我们的原则是：能用规则和小模型解决的，绝不动用大模型。情感分类、实体抽取、主题分类这些任务，用轻量模型在CPU上就能跑，速度快，成本几乎可以忽略。只有文本摘要、稿件生成、口径问答这类需要理解和创作的任务，才调用大模型。

另外做了两件省钱的事。提示词压缩：把系统提示词精简到必要的程度，减少每轮调用的token消耗。结果缓存：在网关层对相似的请求做语义缓存，同一波舆情事件的摘要请求，后续的直接复用前面的结果。

整体算下来，月度Token费用下降了六成以上，同时业务方的平均等待时间反而变短了，因为大量请求压根就没走到大模型那一步。这个结果印证了一个观点：AI中台的成本控制，问题往往不出在模型价格上，而是出在架构设计上——是否让每个任务都用最合适的模型去处理。

4.3 降级预案：大模型不可用时，业务不停摆

依赖大模型API的中台，最怕的就是供应商抖动。Infoseek设计了三层降级。

第一层，网关自动把请求切换到备用模型供应商，业务方无感知。第二层，如果备用也不可用，降级为模板生成，用规则模板填充关键事实，输出结构完整的简报。虽然文笔生硬，但关键信息不缺。第三层，系统告警通知运维，同时页面明示当前是"模板模式"，业务方可以选择人工整理。

这套降级机制上线后至少经历过两次真实故障，都在几分钟内完成了切换。业务方后来反馈，他们最信任我们的时刻，不是系统顺滑运行的时候，而是故障时系统明确告诉他们"现在降级了，请人工介入"的时候。透明比假装正常更重要。

5. 生成内容的可靠性：幻觉抑制与质量闭环

AI中台能不能被业务方长期使用，关键不在生成速度，而在可靠性。公关内容直接面向外部，如果出错，影响的是品牌信誉。所以Infoseek从第一天起，就在"机器生成"和"对外发布"之间建立了一道完整的人工闭环。

5.1 AI生成的公关稿为什么不能直接发

原因很直接：模型会一本正经地编造。比如写一篇产品新闻稿，它可能把发布日期写成去年的，把某个数据翻倍，甚至编造一个不存在的引用来源。这些错误在对话场景里可能无伤大雅，但在对外传播的公关稿里，任何一个都不能接受。

大模型本质上是概率预测，如果没有外部材料，它只能靠训练时的记忆来"猜"，猜的结果就是幻觉。所以Infoseek的模式从来不是"机器写稿、人转发"，而是"机器提供扎实的草稿、人完成最终签发"。所有生成内容只是辅助，责任始终在人。

5.2 四道质量防线

第一道，检索强约束。生成任务必须先查知识库，检索不到相关信息时，模型必须回答"没有找到相关材料"，而不是自由发挥。宁可输出空，也不能胡说。

第二道，引用标注。生成内容按段落标注来源编号，业务方点击可以看到原文片段。这项设计直接提升了业务方的信任感，核稿时间比过去大幅缩短。

第三道，事实校验。提取生成内容中的关键数字、日期、百分比，与知识库比对，不一致时标黄提醒。这个功能一开始做得比较粗糙，只比对产品参数，后面逐步把日期、数量、引文全部纳入校验范围。

第四道，审批流程。所有准备对外使用的内容，都进入统一审批节点，由有权限的人确认后才能使用。审批流和业务系统打通，操作留痕，满足内部合规要求。

5.3 评估体系：从"生成得好不好"到"业务有没有用"

质量评估不能只看生成文本漂不漂亮，要看业务结果。Infoseek的评估体系分三层。

离线评估：定期抽样生成结果，人工按准确性、完整性、风格匹配度、来源可靠性打分，反馈用于优化提示词和检索策略。在线指标：业务方使用数据，比如简报阅读率、稿件采用率、撰稿耗时变化、舆情响应时间。这些指标放在运营看板上，管理层看得懂，也愿意继续投入资源迭代。

反馈闭环：业务方对每条结果可以点"有用"或"没用"，反馈自动回流到评估数据集。三个月后，这个数据集成了我们优化提示词最重要的依据。

我最深的一个体会是：AI中台项目，评估体系要尽早搭，越晚搭，返工越贵。我们前期忽视了这块，后面补得非常痛苦。如果一开始就让业务方在使用中留痕，后面的优化效率能翻倍。

6. 从立项到落地：迭代节奏、踩坑与复盘

最后聊聊项目推进过程中的节奏控制和那些真实的坑。这套经验不只是数字公关领域适用，多数AI中台类项目都可以参考。

6.1 六个月的迭代节奏

整个项目按三个阶段推进。

第一阶段（前两个月），MVP。只做舆情摘要和稿件初稿两个场景，接了一个大模型，知识库先用最简单的关键词检索，目标是让业务方看到"AI真的能干活"。这个阶段不追求完美，追求跑通，哪怕结果粗糙也要让业务方先摸到系统。

第二阶段（中间两个月），补底座。把数据接入、清洗、知识库分层、模型网关搭起来，加入媒体画像与效果评估。这个阶段工作量最大，大部分时间花在数据上，而不是模型上。

第三阶段（最后两个月），提质量和稳定性。完善工作流编排、审批流、降级预案、评估体系，打通周边系统，开始做性能压测和成本优化。

事实证明这个顺序是对的。如果一开始就铺全场景，团队会被各种需求淹没，核心场景反而做不透。先用最痛的场景验证价值，再逐步补全底座，是比较稳妥的打法。

6.2 踩过的三个深坑

坑一：向量切块策略。最初把长文按固定长度切块，检索经常返回不相关内容，排查后发现是切块跨过了段落边界，语义被切断。改成结构化切块后，检索相关性明显改善。这个坑提醒我们，RAG的效果天花板不在模型，而在切块和检索这些工程细节上。

坑二：知识库数据同步延迟。生成内容引用了已经过期的产品参数，业务方发现问题时，我们已经基于脏数据跑了快一周。改成增量事件驱动同步后，源系统一变就实时推送，问题才根治。

坑三：提示词版本混乱。早期几个同事各自调提示词，线上效果时好时坏，还说不清是哪次改的。后来把提示词全部收进网关管理，每次修改带版本记录，线上可一键回滚。这个改动对稳定性的提升非常明显。

三个坑的共同教训是：AI中台项目里，工程细节和治理手段的重要性不亚于模型能力。

6.3 这套架构能迁移到哪些场景

Infoseek的方法论可以归纳成四个关键词：数据底座、模型网关、工作流编排、人工闭环。这套方法不只适用于数字公关，很多内容密集型的场景都能用上，比如企业内部知识问答、营销内容中台、智能客服的知识助手、行业研究报告辅助生成。

迁移时最需要拷问自己的问题不是"用哪个模型"，而是"数据有没有管好、流程有没有定清楚、人工兜底有没有到位"。模型可以换，底座和制度不能换。我们内部复盘时常说一句话：AI中台能不能站稳，看的不是模型排行榜，而是业务方第二天早上还愿不愿意打开系统。

如果让我重新做一遍Infoseek，我会把评估体系往前提两个月，在第一周就搭好反馈采集；还会把知识库的数据治理优先级提得更高。因为AI中台真正难的部分，从来不是模型调用，而是让每一句话都有据可查、让每一个流程都可回溯、让业务方一步步建立信任。模型会迭代，但体系和数据是长期资产。希望这篇复盘能帮正在做类似项目的团队少走几个坑。