企业官网建设流程全解析

1. 项目概述：品牌公关为什么需要AI中台

品牌公关圈子里这些年一直在说“数智化”，但真正落地时，大多数团队还是每天早上打开舆情后台，人工刷一遍信息，再拉个Excel表，开会念一遍“负面舆情环比上升了几个点”，然后接着用通用大模型写新闻稿。问题恰恰出在这里：单个AI工具解决的是某个局部效率，比如“写稿更快”“摘要更短”，但解决不了品牌公关最核心的协同问题——舆情发现、态势判断、口径对齐、内容产出、渠道分发，这几件事在传统作业里是割裂的。

Infoseek这个名字是我们内部给一套AI中台起的代号，立项初衷很朴素：把散落在舆情系统、公众号后台、客服工单、销售反馈里的信息统一收口，再让AI在中间完成“理解—判断—生成—分发”的闭环。它不是某一个写稿机器人，也不是某一个舆情大屏，而是一个品牌公关团队可以反复调用的能力底座。这篇文章想做的，就是把Infoseek的技术架构拆开来讲清楚：每一层解决什么问题、核心组件怎么选、落地时有哪些坑，以及如果你也想搭一套类似的系统，第一步应该从哪里入手。

适合读这篇文章的人有两类：一类是正在做品牌公关数字化、想推动AI落地的业务负责人，你需要知道AI中台能帮你把哪些活接住；另一类是负责技术实现的工程师或产品经理，你需要知道舆情分析和内容生成这类能力，如何在一个中台架构里被组织起来，而不是东拼西凑一堆API。

2. 总体技术架构与设计思路

2.1 从单点工具到能力中台：架构逻辑的转变

Infoseek一开始也踩过“点工具”的坑。第一版我们只接了一个开源大模型，让公关同事在网页对话框里写稿，结果用了两周就停了：稿子写出来没有品牌知识支撑，数据口径和官网对不上，审核人还得自己去查资料，效率反而更低了。后来才明白，品牌公关需要的不是一个“更聪明的打字机”，而是一套能理解业务上下文的工作流。

Infoseek的架构分五层，从下往上依次是：数据接入层、知识构建层、智能分析层、生成服务层、业务应用层。数据接入层负责把外部公开信息、内部文档、工单、历史稿件等异构数据收进来；知识构建层做清洗、实体抽取、知识图谱和向量化，把非结构化内容变成机器可读的知识；智能分析层承担舆情识别、情感判断、事件聚类、危机预警；生成服务层基于检索增强生成来产出稿件、口径问答、汇报摘要；业务应用层则对应公关团队日常使用的舆情告警、写作助手、口径查询、周报自动生成等界面。

这个分层最核心的用意是隔离变化。舆情数据源会变，大模型也会迭代换版本，但只要中间的“知识”和“能力”沉淀在中台里，上层应用就不需要每次跟着重写。今天接一个新数据源，影响范围只在数据接入层；明天换一个更强的基座模型，影响的只是生成服务层，舆情分析、知识检索这些能力完全不受影响。

2.2 关键技术选型：为什么这样组合

关于技术选型，Infoseek有几条非常明确的原则。

第一，舆情文本处理不用单一模型硬扛全部任务。情感分析、实体识别、事件聚类这类基础NLP能力，用中等规模的专用模型或微调模型来承担，速度快、成本低、效果稳定；只有需要开放语义理解和长文本生成的场景，才调用大模型。原因是品牌公关场景里，舆情量级通常是每天几万到几十万条，如果全部走大模型接口，延迟和费用都是不可接受的。

第二，知识检索必须用混合检索而不是纯向量召回。品牌知识库里既有“产品成分”“创始人履历”这类词典式的精确信息，也有“历史危机事件处理口径”这类语义相似度为主的段落。纯向量检索对精确实体匹配并不友好，比如检索“某某成分”的化学名时，向量召回经常把同义词和相近概念混进来。Infoseek的做法是：先走ES类倒排索引做关键词召回，再做向量语义召回，最后在排序层把两路结果融合，保证“精确词不丢、语义相关能上位”。

第三，大模型层的接入必须统一网关。团队在跑POC阶段往往直接调各家模型API，到了生产环境就会发现，不同模型厂商的限流策略、返回格式、成本计价都不一样。Infoseek在生成服务层前面加了一个模型网关，统一封装接口，内部做路由、限流、降级和成本统计。公关同事完全不必关心这篇稿子是哪个模型写的，也不需要理解底层切换。

2.3 一套标准的调度链路

Infoseek处理一条典型舆情信息的链路是这样的：公开信息采集程序把数据送入消息队列，消息队列削峰后交给文本清洗服务，去掉广告、重复文、乱码；清洗后的内容进入实体识别和情感分析，打上品牌相关度标签；如果判定为“高风险”，进入事件聚类和预警打分流程，把相似事件聚集在一起，再按品牌受影响程度给出0到100的危机分；分数超过阈值就把事件摘要、传播路径、情绪占比一起推送给值班人员。

从这里就能看出，中台它不是一个大模型嵌套，而是像一个工厂流水线：每一道工序只做一件事，工序之间有标准的数据口径，哪一道出问题了就单独替换或加固，不会牵一发动全身。这也是“中台”和“工具集合”最本质的区别。

3. 核心模块拆解与实操要点

3.1 公开信息采集与清洗：数据进得来才算数

很多团队做AI中台，一上来就盯住大模型，反而忽略了数据接入。实际上，品牌公关AI中台对数据的要求非常高：舆情判断错了，后面所有生成内容都会跟着错。

Infoseek的数据接入分内外两条线。外部线主要覆盖新闻站点、社交平台公开信息、论坛、应用市场评论等渠道；内部线包括历史新闻稿、品牌口径文档、客服FAQ、过往危机复盘报告。外部信息通过合规授权的接口或公开页面采集后，不直接进入分析层，而是先做三层清洗：格式清洗去HTML标签和噪声字符，内容去重用SimHash算法识别转载和洗稿，垃圾过滤用规则加分类器去掉广告、抽奖、无关营销内容。

这块最容易被忽视的是“品牌相关度”判断。很多舆情系统会把所有提到品牌名的内容都拉进来，结果公关每天看大量“某某品牌仿品”“某某品牌抽奖”的无关信息。Infoseek在实体识别之后增加了一个相关度打分环节，综合判断：是否明确指向品牌、是否属于品牌产品范畴、是否来自可信媒体、是否有用户真实反馈。只有相关度达标的文本才进入后续分析，这个看似不起眼的环节，能把公关团队每天需要人工查看的信息量减少百分之六十以上。

3.2 情感分析与事件聚类：让机器先读一遍

情感分析在品牌公关场景里，不能简单分“正面、负面、中性”三类，还要考虑情绪类型和强度。Infoseek的情感模块输出六个维度：情绪极性（正负）、情绪类别（愤怒、失望、焦虑、期待、满意、中立）、强度等级（1到5）、主体对象（品牌、产品、服务、创始人、竞品）、地域来源、时间趋势。

这里有一个很关键的实操细节：通用情感模型对品牌文本往往不够用。比如“这手机发热可以当暖手宝”这句，通用模型会判成正面调侃，但在品牌语境里，它意味着产品散热有问题，是典型的负面信号。Infoseek的做法是：先用通用模型做初筛，再基于品牌历史标注数据做一个小模型修正，专门识别反讽、对比拉踩、隐性抱怨。这个修正模型不需要很大，几千条历史标注数据就能把准确率提上来。

事件聚类则是把零散的舆情变成可判断的“事件”。比如连续几天出现多条“某产品续航差”的内容，单看每一条都不严重，但聚到一起就是一个产品口碑事件。Infoseek用增量聚类算法，按品牌实体、产品线、问题类型、时间窗口四个维度做归并，同一事件下的内容自动聚合，并且在事件面板里展示传播趋势和关键博主。聚类参数里最重要的是时间窗口，窗口太短会把一个持续发酵的事件切成好几段，窗口太长又会把两个独立问题混在一起，我们最终按不同内容平台分别设置了24小时和72小时两套窗口，效果比较理想。

3.3 危机预警与分级：从“报警”到“给建议”

传统舆情系统的预警就是阈值触发的红黄灯，问题是有大量误报。Infoseek的预警模块做了两件事：一是把“热度”和“风险”分开看，二是给每个预警附上“处置建议”。

危机风险打分不是简单看负面数量，而是综合五个因子：负面声量增速、传播层级、关键账号影响力、话题可延展性、是否有实质性指控。每个因子按权重加权得到一个0到100的危机分。举例来说，一条负面内容转发达不到1000次，但来自一个百万粉的科技博主，而且内容里明确提到“安全隐患”，那么它要比一万条普通用户抱怨更危险。这套打分规则是和公关团队一起梳理出来的，不是从技术侧拍脑袋定的。

处置建议则是基于历史案例库的检索生成。系统从知识库里检索“同类型事件当时是怎么处理的”，再结合当前事件的传播规模生成建议，比如“建议24小时内官方回应”“建议先联系首发媒体核实信息”“建议准备产品说明口径，暂不公开回应”。我给这个模块定了一条规矩：AI可以给建议，但最终要不要回应、怎么回应，必须由人确认。预警系统做的是压缩信息差，不是替代决策。

3.4 品牌知识库与检索增强生成：让文案有据可依

品牌公关团队用大模型最大的痛点就是“一本正经地胡说八道”。Infoseek解决这个问题依靠品牌知识库加检索增强生成。

品牌知识库里沉淀了五类内容：品牌基础信息、产品技术参数、创始人及高管公开表达、历史新闻稿和媒体问答、危机事件处理复盘。这些文档全部切分成段落，既做向量化存入向量数据库，也保留原始结构化字段供精确匹配。生成服务在写任何文案之前，必须先走一步检索：系统根据用户输入和当前舆情事件，从知识库里召回五到十段相关材料，再要求模型严格基于材料回答。

实践中检索增强的关键在于“引用可见”。Infoseek生成的每一段文案都会标注引用了哪份材料，公关同事点开就能核对原文。比如AI建议在声明里写“该产品已通过某某认证”，系统会同时展示这句话的知识来源文档，如果没有对应依据，模型就不能输出这句表述。这个设计极大降低了审核成本，也让公关敢把AI产出直接当作初稿来用。

3.5 内容生成与多级审核：AI写的稿子怎么用

内容生成模块覆盖的品牌公关物料很多：官方声明、媒体新闻稿、社交媒体短文案、口径问答、内部汇报摘要。每种物料类型对应一套独立的提示词模板，模板里除了角色设定，还包括品牌语料示例、禁用词表、敏感点提示。

以官方声明为例，提示词模板会写入：声明结构（事件背景、立场表达、处置措施、后续安排）、品牌对外的固定称谓、不能出现的绝对化表述、历史同类事件的处理参考。生成后的文案不是直接发布，而是先过三道关：第一道是规则校验，检查禁用词、事实错误、预设敏感点；第二道是模型一致性检查，比对生成内容和检索材料是否有冲突；第三道才交给人工审核。

这里特别想提醒一点：同一条信息，对外稿和内部汇报稿的写法完全不一样。对外声明要克制、温和、有措施；内部汇报要讲清楚风险等级、传播路径、建议动作。Infoseek对不同场景做了严格的语料隔离，内部汇报模板不会调用对外口径里的“温情表达”，对外模板也不会引用内部对风险等级的评估。用中台的好处是，语料隔离一旦在底层做好，上层怎么切换都不会串内容。

4. 落地实操：从零搭建一套品牌公关AI中台

4.1 第一步：盘点内部数据与外部数据源

搭建AI中台不要先选模型，先盘点数据。把品牌公关日常依赖的数据分成四类：外部公开数据、内部业务数据、历史沉淀数据、人工经验数据。

外部公开数据看采购渠道和合规授权；内部业务数据看客服工单、销售反馈、售后评论、公众号后台留言，这些往往散落在不同系统里，需要接口打通；历史沉淀数据是过去两到三年的新闻稿、媒体采访、危机报告，这些是知识库最宝贵的种子；人工经验数据指的是公关团队内部流传的“口径文档”“敏感词表”“媒体分级名单”，看起来不正式，但信息密度极高。

我们当时盘点出来的结果是：外部数据占六成，内部数据占三成，剩下的一成是散落在几个人脑子里的经验。前两类好解决，最后一成最费功夫，需要公关负责人和技术一起做访谈，把经验梳理成可落地的规则和材料。这时候最忌“想让系统一步到位覆盖所有渠道”，宁可先接两三个核心渠道跑通，也比让所有渠道都在半成品状态下等着强。

4.2 第二步：明确Mvp边界与优先级

Infoseek的MVP阶段只做了三个能力：舆情预警、口径问答、声明初稿生成。这三个能力对应公关团队最痛的三件事：出事不知道、回应没口径、写稿没参考。

定义MVP边界有一条原则：每个能力必须能在一个完整业务闭环里被验证，而不是做一个半成品功能。比如舆情预警，不是说“能统计负面量”就算完，而是要做完“发现事件—评估风险—推送告警—附处理建议”的全流程。口径问答也不是简单做一个大模型聊天框，而是要能回答“我们产品降价了吗”“我们和某竞品对比怎么样”这类具体问题，并且每个答案都能溯源。

MVP阶段不要做多语言，不要做复杂可视化大屏，也不要追求情感分析模型的极高准确率。把链路跑通，让公关团队愿意每天打开用，比算法指标重要得多。

4.3 第三步：模型选型与部署方案

Infoseek的模型选型分三类。基础NLP能力，比如实体识别、情感分类、文本相似度，选择开源的轻量模型私有部署；知识检索和排序，使用开源向量数据库加自研的混合检索逻辑；生成能力，接入商用大模型API，同时通过模型网关做统一管理。

这里有一个务实建议：大模型不一定要私有化部署。品牌公关场景里对数据的敏感度，低于金融和医疗场景，商用API在合规前提下足够用。关键是不要让业务逻辑绑死在某一家的模型上。模型网关层把每家API的差异屏蔽掉，今天用这家，明天嫌贵换那家，一行配置就能切换。而私有部署的NLP小模型，虽然能力上限不如大模型，但胜在稳定和便宜，适合在流量最大的环节扛量。

部署方案采用混用：舆情清洗和情感分析跑在自建集群上，生成服务走云端API，知识库检索跑在独立中间件上。这样即使大模型API出现故障，舆情监测链路也不会中断，只影响生成类功能。

4.4 第四步：提示词模板与人机协同流程

提示词模板是AI中台里被低估的核心资产。Infoseek的提示词不是随便写的几段话，而是按“角色—任务—输入—约束—示例—输出格式”六要素结构化维护。每次和公关团队开会，都会收集新的表达偏好，比如“不要用互联网黑话”“不要说‘赋能’‘抓手’这类词”，这些都会被写进禁用词表，加入模板。

人机协同流程的设计原则是：AI先干，人后审。系统每天自动完成舆情扫描、事件聚类、摘要生成、热点追踪，公关人员只需要在系统生成的“每日公关态势简报”上做确认和补充。写稿场景下，AI产出第一版初稿，人负责把关策略方向和修改语气。这套流程跑顺之后，公关团队的角色从“每天在信息海里捞针”变成“每天审少数关键决策”，整体工作体验的提升非常明显。

5. 常见问题与排查技巧实录

5.1 舆情误报率居高不下

很多团队刚上线预警功能时都会遇到这个问题：一天推几十条警报，点开看一半是无关信息，结果真正出事的那条被淹没了。

排查思路分三步：先查数据源是否混入了大量擦边品牌名的内容，比如品牌名是常见词时，要把“品牌词加产品词组合”作为相关度判断条件；再查相关度模型阈值是否太低，Infoseek上线第一周阈值调到0.3，准确率惨不忍睹，后来实际调参到0.6左右才平衡；最后查事件聚类窗口是否合理，窗口太大容易把无关内容归进同一事件。

如果误报还是多，就去看负面判定逻辑。很多时候不是模型的问题，而是规则的锅。比如把“品牌客服回复慢”也当成负面舆情，但这其实只是服务体验反馈，公关并不需要紧急响应。负样本标注数据的积累很重要，每一条误报都应该被记录下来，回灌到分类模型里做增量微调。

5.2 大模型生成内容答非所问

品牌口径问答上线初期，经常出现用户问“你们产品安全性怎么样”，模型回答了一大段产品理念，但完全没有提到安全认证、检测标准这些关键信息。

这个问题基本都出在检索环节。我们定位后发现，知识库里关于安全认证的内容存在PDF文档里，而文档解析时表格被拆散了，导致向量化之后检索不到。解决方法是给知识库增加“结构化表格优先索引”的处理策略：表格内容单独解析并保存为键值对，同时创建表格标题的向量索引。检索时，如果用户问题里含“认证”“标准”“检测”这类词，系统会优先命中结构化字段。

另外，回答质量还取决于检索段落是否完整。段落切得太碎，模型只能看到局部信息，自然回答不全面。Infoseek的段落切分策略是：标题加首段加后续内容作为一个知识单元，单元内部再做重叠切分，既保证语义完整，又保证向量检索精度。

5.3 数据同步延迟导致预警滞后

品牌公关最怕预警慢。我们曾经遇到某平台数据延迟四个小时，等到系统发现问题，负面内容已经发酵了一整轮。

排查发现延迟有两个原因：一个是对方平台的接口调用频率限制，一个是采集程序本身出现了死锁。前者的解法是做优先级调度，把重点平台和高风险账号的采集频率提到最高，普通平台降低频率；后者的解法是给采集任务加上看门狗机制，超过预设时间没有新消息就自动重启任务并发告警。

还要做数据时间戳的校准。有些平台返回的是内容发布时间，有些是抓取时间，如果混用，时间趋势图就是歪的。Infoseek在清洗环节会统一把“数据产生时间”和“数据入库时间”分开存，做时间序列分析时只用前者。

5.4 向量检索结果不相关

向量检索失效是RAG系统里最常见也最难排查的问题。Infoseek有一次做产品知识问答，问“某某成分是否适合敏感肌”，向量检索召回的全是成分介绍，但没有一篇涉及适用人群。

后来发现问题出在知识库里“敏感肌”相关内容本身太少，再强的检索也召不回不存在的内容。解决思路是补知识源，而不是调参数。我们额外导入了皮肤科科普文章和产品测试报告，知识覆盖度上来之后，召回效果自然好了。所以排查向量检索问题，先问“库里有这个知识吗”，再问“召回策略对不对”，顺序不能反。

另一个技巧是给不同来源的知识打上标签，检索时支持按标签过滤。比如用户问题是产品功效类的，就过滤掉企业新闻类内容；用户问题是危机事件类的，就过滤掉营销活动类内容。标签过滤比单纯依赖向量相似度靠谱很多。

6. 这套系统还能扩展到哪里

6.1 从公关到品牌声誉资产管理

Infoseek目前的能力虽然是从公关场景出发，但底层架构完全可以直接扩展成品牌声誉资产管理系统。舆情监测的维度可以延伸到消费者产品评价、渠道反馈、竞品对比、行业监管动态，这些信息经过统一建模之后，对整个品牌团队都具备极高价值。

比如质量部门可以复用舆情数据里的产品故障信息，识别设计缺陷；客服部门可以复用口径问答能力，快速给出标准答复；产品部门可以复用用户需求聚类结果，作为需求池的输入。中台的价值就在这里，一次建设，多处复用。

6.2 与内部知识管理的打通

品牌公关产生的知识，比如危机复盘、媒体沟通纪要、活动传播总结，目前很多散落在个人网盘和聊天记录里。把“个人知识”沉淀成“组织知识”，是Infoseek下一个阶段的重点方向。

技术上并不复杂，知识构建层已经提供了文档解析、向量化、图谱化能力，只要把入口从“公关文档库”扩展到内部协同平台和邮件系统，组织知识库就能持续生长。真正难的是运营：要让团队愿意把经验录进去，并且保持定期更新。

6.3 多语言与海外舆情场景

Infoseek设计之初的语言能力只覆盖中文，但架构上预留了多语言扩展位。数据接入层和知识构建层的设计本身与语言无关，只需要在情感分析和实体识别环节增加多语言模型适配。

海外品牌公关场景还有一个额外的需求：跨时区的预警值班。系统需要按目标市场时区分别设置预警时段，并且把多语言舆情自动翻译成统一语言供总部团队查看。这个可以等到主场景跑稳定之后再做，不建议在初期就铺开。

我在实际搭建Infoseek的过程中最大的体会是：技术架构层面的难点其实都算不上真正的难点，真正难的是让公关团队愿意改变操作习惯。系统上线前，一定要让业务人员参与规则梳理和模板设计，而不是技术团队闷头做完再丢过去。AI中台本质上是一套“组织知识”的载体，没有人持续投喂业务经验，再漂亮的架构也是空转。最开始的那几个月会很难，数据不齐、误报不断、提示词来回改，但只要业务负责人和技术负责人能坐在一起咬住牙把第一版跑通，后面就是滚雪球式的正循环。如果你正在计划做类似的系统，我给你的建议很简单：缩小范围，跑通链路，然后让业务同事每天用起来。