企业官网建设流程全解析

最近一直在做一件很有意思的事：盯着豆包、DeepSeek 这类 AI APP，看它们在回答用户问题时，到底会不会主动提起我们的品牌词。你可能觉得这不就是“舆情监控”嘛，但实际做下来才发现，它和传统舆情完全不是一回事——用户不会把自己的对话内容发到网上，AI 也不会给你一份“推荐了哪些品牌”的报表。想拿到这个数据，只能靠我们自己去“问”它。

这篇文章就聊聊我们如何把这件事做成一套自动化运维系统，覆盖整体思路、数据采集、判定逻辑、定时调度、可视化展示和踩坑实录。如果你在品牌团队、增长团队或者自动化运维岗位，需要量化“AI 应用里有多少比例的回答提到了自己的品牌”，那这套方案可以直接抄作业。

1. 品牌词采纳率监控，到底在监控什么

1.1 从一次“AI 推荐翻车”说起

事情起因是某公司发现一个奇怪现象：用户在 AI 应用里问“有什么好用的在线文档工具”，AI 一口气推荐了好几款产品，唯独没提该公司自家产品。一线销售反馈说，用户现在做购买决策前都会先去问一遍 AI，如果 AI 始终不推荐自家品牌，销售聊得再多也白搭。

这个现象背后藏着一个量化指标：品牌词采纳率。定义很简单，一段时间内，AI 应用在回答中主动提及目标品牌词的次数，除以有效的提问样本总数。比如我们设计了 20 个模拟用户问题，如果 AI 回答里有 8 次提到了目标品牌词，那当天采纳率就是 40%。

但问题来了：这个指标不像网页搜索排名那样有现成工具可查，AI 应用没有提供“品牌曝光报告”，也不会告诉你它内部的推荐逻辑。唯一的办法就是我们主动去提问、去触发、去记录，再用一套自动化流程把散落的对话数据处理成可阅读的趋势图表。这就是整个项目的出发点。

1.2 为什么传统舆情监控不够用

传统舆情监控干的是另一件事：抓取新闻、社媒帖子、评论区的内容，看用户怎么说你。这套体系对公开内容有效，但对 AI 对话场景基本失效，原因有三个：

第一，AI 对话是私密的一对一交互，不会被搜索引擎收录，也不会被爬虫抓取。第二，即使你能抓到部分对话内容，也拿不到完整上下文，很难判断品牌词是“被推荐了”还是“被吐槽了”。第三，用户问法千差万别，同一个品牌词在不同对话里可能被缩写、被同义替代，甚至被翻译成英文，传统关键词监控根本覆盖不全。

所以我们需要的是一套“主动探测系统”：自己设计问题、自己发起对话、自己解析回答，把 AI 应用当作一个黑盒来反复测试，最后把测试结果汇总成监控报表。这和接口监控、拨测监控的思路非常相似，只是被探测的对象从服务器变成了 AI 应用。

1.3 监控指标怎么定义才科学

很多团队上来就只统计一个“有没有提到品牌词”，实测下来会漏掉大量信息。我在落地时把指标拆成了三层：

第一层是基础采纳率，就是命中品牌词的样本数除以总样本数，这个指标用于看大盘趋势。

第二层是表现形式差异，记录品牌词是以什么形态出现的。有的 AI 回答用全称，有的用简称，有的用“某家的产品”这种模糊指代。不同的表述方式会影响用户感知，需要单独跟踪。比如某产品全称叫“某某智能助手”，但 AI 回复里只出现“某某助手”，这类简称命中也要算一种形态，至少说明模型对品牌有记忆。

第三层是推荐倾向，光“提到”还不够，还要判断是被正面推荐、负面评价，还是中性提及。一个回答里写着“某品牌不太好用但是生态完善”，你把它算作采纳就会失真。所以在判定环节，我会先把回答分成“明确推荐”“折中提及”“负面评价”三个类型，分类统计，最后再合成一个加权采纳率。

这三层指标设计是整个监控体系的底层逻辑。后面所有代码、流程、可视化都是围绕这些口径展开的。

2. 整体方案设计：一条从探测到展示的数据链路

2.1 技术选型背后的取舍逻辑

选型前先明确了几个约束：团队里主要用 Python，数据量每天几千条对话记录，不想为了一个监控项目专门搭大数据平台，且需要一个方便业务方每天看的可视化看板。

基于这些约束，技术栈定为：Python 作为主力开发语言，负责所有采集和判定逻辑；存储先用 SQLite，单表几万条记录完全没问题，后续数据量上来再平滑迁移到 PostgreSQL；可视化直接用 Grafana，接 SQLite 数据源，画趋势图和告警规则都够用。

有同学可能会问，为什么不直接上 Elasticsearch 或者 ClickHouse？因为品牌词采纳率监控本质上是低基数的小数据量场景，每天几千条记录，Elasticsearch 反而增加了运维复杂度。SQLite 单文件部署，定时任务写库后 Grafana 直接读取，整条链路三个组件就能跑通，出了问题也好排查。

另外一个核心选择是采集方式。目前主流 AI 应用有两类接口：一类提供了公开 API，你可以直接调用对话接口，返回结构化数据，解析成本最低；另一类没有开放 API，只有 Web 端聊天界面，这时候只能用自动化浏览器模拟用户输入，从页面上抓取回答。两种方式我都实测过，后面会分别说明适用场景和坑点。

2.2 数据采集的两种方式及选型建议

先讲 API 直连模式。优点是稳定、速度快、响应内容是纯文本，不需要处理页面 DOM；缺点是部分产品不开放 API，或者免费额度有限。我在对接某款 AI 应用时，官方 API 文档写得还算清楚，但接口地址、鉴权方式各不相同，需要花半天时间逐个适配。这个阶段最大的成本不是写代码，而是读文档和处理各家鉴权差异。

再讲自动化浏览器模式。我用的是 Playwright，它能模拟完整浏览器行为，打开网页、输入问题、点击发送、等待回答、然后截取页面文本。这套方案的通用性很强，任何有 Web 界面的 AI 应用都能接入，不用等官方开放 API；缺点是速度慢、资源占用高，而且一旦页面改版，selector 就全失效了。

实际选型时我的建议是先查官方 API，有就直接用；没有 API 再用 Playwright 兜底。千万不要一上来就全量做浏览器自动化，维护成本会拖垮整个项目。

2.3 提问模板与探测策略

探测效果好不好，一半取决于问题怎么设计。我们不会只用一句“你推荐什么产品”反复问，那样模型会记住你的固定模式，结果越跑越失真。

我设计了四类问题模板，覆盖不同类型用户的真实问法：

• 直接推荐型：“推荐几个好用的在线协作工具，要求支持多人实时编辑。”
• 对比选择型：“A 产品和 B 产品哪个更适合初创团队？请从价格和功能两方面对比。”
• 功能寻找型：“我想找一个能自动生成会议纪要的工具，最好还能和日历联动。”
• 负面排除型：“有哪些文字识别工具是比较坑的？我想避开它们。”

每一类下面准备了 5 到 8 个具体问题，全部存入一个问题池。每次运行时，从问题池里随机抽取 6 到 8 个问题，分别发给各 AI 应用。这样做有两个原因：一是避免同一批问题反复出现导致模型输出记忆偏移，二是尽量模拟真实用户多样化的提问方式，让采纳率统计更有代表性。

提问过程中还要保留完整上下文。AI 回答是流式的，有些品牌词可能在中间段落出现，有些在最后总结里才出现。我要求采集模块把每次回答的全文都存下来，不截断、不预处理，方便后面判定模块做二次分析。

3. 实操过程与核心环节实现

3.1 搭建基础采集框架

整个项目我按模块拆成四层：probe（探测）、judge（判定）、store（存储）、scheduler（调度）。目录结构大致是这样：

brand_monitor/ ├── probe/ │ ├── api_probe.py # API 直连模式采集 │ └── browser_probe.py # Playwright 浏览器模式采集 ├── judge/ │ ├── text_clean.py # 文本清洗 │ ├── rule_match.py # 规则匹配 │ └── semantic_judge.py # 语义判定兜底 ├── store/ │ ├── sqlite_store.py # 入库逻辑 │ └── migrate.py # 建表与迁移 ├── scheduler.py # 定时调度 ├── config.yaml # 品牌词表、问题池、API 配置 └── main.py # 入口

probe 模块是整个系统的输入源头。先定义统一的数据结构，每次探测返回一个包含时间、AI 应用名、问题、原始回答的字典，后续所有模块只认这个结构，无论你用的是 API 模式还是浏览器模式。

# probe/probe_result.py @dataclass class ProbeResult: app_name: str # 豆包/DeepSeek/其他 question: str # 本次提问原文 answer: str # AI 回答全文 raw_metadata: dict # 扩展字段，如请求耗时、token 数 probe_time: str # 探测时间

抓到的原始回答绝不直接入库，先经过 judge 模块判定，再连同判定结果一起写库。这样后面如果判定规则调整，可以从库里捞出原始文本重新跑一遍，不用重新探测。

3.2 判定逻辑：从“提到了”到“真的推荐了”

判定模块是准确率的关键。我们走了三步：清洗、规则匹配、语义兜底。

第一步是文本清洗。AI 回答里经常带 Markdown 标记、列表符号、多余空行，还有“根据我的了解”“目前市面上”这类套话。清洗阶段把这些信息去掉，保留下纯粹的品牌相关表述。

第二步是规则匹配。这里要建一个品牌词表，除了品牌名本身，还要包含常见的简称、英文缩写和易错写法。比如品牌名是“星光笔记”，那词表里要加“星光”“xingguang”“星光笔记app”等形式。匹配时先做大小写归一化、全半角归一化，再用 Python 的正则或者简单的子串匹配。

# judge/rule_match.py import re BRAND_TERMS = [ r"星光笔记", r"星光助手", r"xingguang", r"星光" ] def clean_text(raw: str) -> str: text = raw.lower() text = re.sub(r"#{1,6}\s*", "", text) # 去掉 markdown 标题 text = re.sub(r"\*{1,2}([^*]+)\*{1,2}", r"\1", text) # 去掉加粗 text = re.sub(r"`([^`]+)`", r"\1", text) # 去掉行内代码 text = re.sub(r"\s+", " ", text) return text.strip() def match_brand(text: str) -> dict: hits = [] for term in BRAND_TERMS: if re.search(term, text): hits.append(term) return { "hit": len(hits) > 0, "hit_terms": list(set(hits)) }

规则匹配速度最快，能覆盖 80% 以上的场景。但它的局限也很明显：品牌词可能被改写成“一个叫星光的工具”“最近很火的那款笔记软件”，规则就失效了。所以第三步用语义相似度做兜底。

这里我用了一个轻量方案：把品牌名和回答文本分别做向量化，计算余弦相似度，超过阈值就判定为“疑似提及”。向量化模型没有用太大的，一个本地跑得动的中文 embedding 模型就够。判断不了的就打标签“need_review”，人工复核一批之后，把结果回流到规则库，不断增补词表。

三段式判定下来，准确率能到 95% 以上，偶尔有误判也会集中在模糊指代上，不影响大盘趋势。

3.3 统计口径与置信度计算

采集和判定都跑通之后，下一个问题就是如何从一批样本算出可信的采纳率。

当天采纳率的公式是：采纳率 = 命中品牌词的样本数 / 有效样本数。但这里有个坑：如果当天只跑了 5 个问题，中了 2 个，你能说采纳率是 40% 吗？样本量太小，这个数字没有统计意义。

为了回答“至少跑多少个问题才算数”，我用二项分布的置信区间来算。假设真实采纳率是 20%，要让它和 25% 区分开，需要多少样本？按 95% 置信度推算，公式为 n = (z^2 * p * (1-p)) / d^2，其中 z=1.96，p=0.2，d=0.05。代入后是 n = (1.96^2 * 0.2 * 0.8) / 0.05^2，大约等于 245.86，所以最少要采集 250 个有效样本。

实际操作中我就按这个逻辑配置每天的探测量。单家 AI 应用每天至少 300 个问题，周六日也不停，这样算出的采纳率才敢拿到周会上讲。

需要补充一句，这里所说的“有效样本”，指的是 AI 成功返回了完整回答的样本。遇到超时、空回复、内容审核拦截的情况，一律剔除出统计，不计入分母。

3.4 定时调度与数据可视化

调度层面用了 APScheduler，每天凌晨 2 点启动当天的探测任务，这个时间点 API 压力小，而且不会影响业务高峰。

# scheduler.py from apscheduler.schedulers.blocking import BlockingScheduler def run_daily(): # 1. 随机抽取当日问题池 # 2. 调用 probe 采集 # 3. 调用 judge 判定 # 4. 落库 pass scheduler = BlockingScheduler(timezone="Asia/Shanghai") scheduler.add_job(run_daily, "cron", hour=2, minute=0, id="brand_probe") scheduler.start()

这里有一个很容易踩的坑：任务堆叠。默认 APScheduler 在任务执行时间超过调度间隔时，不会重复触发，但如果你手动触发补跑，就可能和定时任务撞车。我的解决办法是在任务开头用 SQLite 建一个 job_lock 表，记录当天是否已跑过，已跑过就跳过，保证一天最多跑一次。

数据入库后，可视化就简单了。Grafana 接 SQLite 数据源，建一个趋势图，横轴是日期，纵轴是采纳率，按 AI 应用分系列展示。再建一个表格图，展示最近 7 天各品牌词命中率排名。SQL 大致长这样：

SELECT date(probe_time) AS day, app_name, ROUND(100.0 * SUM(hit) / COUNT(*), 2) AS adoption_rate FROM probe_records WHERE date(probe_time) >= date('now', '-7 day') GROUP BY day, app_name ORDER BY day ASC;

看板配好之后，我把地址丢给品牌团队，他们每天自己点开看，不需要我出一份 PPT。这套东西之所以能跑起来，核心就是降低了使用门槛，业务方不用看 Python 代码，打开浏览器就知道趋势怎么样。

3.5 告警规则设计

只看趋势还不够，异常要及时感知。我们在 Grafana 里配了两条告警规则。

第一条是掉零告警：如果某家 AI 应用连续三天采纳率为 0，触发 alert，说明 AI 可能把你的品牌词彻底遗忘了，需要人工介入排查。第二条是突降告警：当日采纳率比前 7 天均值下降超过 30% 时触发，这种情况通常意味着 AI 应用更新了模型或调整了推荐策略。

告警渠道用了企业 IM 机器人，直接把消息推到品牌群里，相关同事第一时间能看到。实测下来，掉零告警最有价值。因为采纳率突变大概率有真实原因——要么品牌词表该更新了，要么模型版本换了，两条原因背后的处理逻辑完全不同，人工介入越早越好。

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

4.1 多次采样结果不一致怎么办

AI 生成本身有随机性。同一个问题问十次，可能八次提到品牌词，两次不提，所以单个样本的命中与否没有绝对意义。我们不去追求单次判定百分百准确，而是用多次采样均值加置信区间来判断整体趋势。在周会上展示数据时，我会把样本量和置信区间一起展示，让决策者明白 40% 的采纳率背后有 400 个有效样本支撑，而不是靠 10 个样本猜出来的。

4.2 API 限流和并发冲突

不同 AI 应用的 API 限流策略差别很大。有的按分钟限制 60 次请求，有的按并发数限制 5 个。一上来就把并发开到 10 个线程，很容易触发 429 限流，导致大面积采集失败。

我的做法是：先在配置里给每个应用单独设置 max_concurrency 和 retry 参数。请求失败时用指数退避重试，第一次等 2 秒，第二次 4 秒，第三次 8 秒，最多重试 3 次。对面有 429 响应头的，严格按照 Retry-After 字段等待。

import time import random def request_with_retry(func, retries=3): delay = 2 for attempt in range(retries): try: return func() except RateLimitError: time.sleep(delay + random.uniform(0, 1)) delay *= 2 raise ProbeFailedError("retries exhausted")

4.3 判定误报和漏报

误报往往出在“品牌词也是通用词”的场景。举例来说，如果你的品牌词带“云”字，那 AI 回答里大量出现“云端”“多云”也会被匹配命中，采纳率直接虚高。后来我在规则匹配里加了一层上下文窗口：品牌词前后各取 10 个字符，如果上下文窗口出现“不是”“不建议”“缺点是”等负面词，就把这条标为负面提及，单独统计，不进采纳数。

漏报则主要因为品牌词写法太多样。AI 有时会直接说“一款笔记应用”而不点名，这属于逻辑上无法靠文本规则识别的类别。我的处理是把这类漏报记录到 unreviewed 表里，每周人工抽查，把确认是品牌指代的表达方式补充进词表。

4.4 定时任务堆叠导致数据延迟

这是一个典型的运维问题。某天凌晨探测脚本因为 AI 应用 API 超时多跑了一个小时，早晨 8 点同事补跑，结果和当天凌晨任务叠加，数据库里出现重复记录，当天的采纳率分母直接翻倍，图表上出现一个明显异常的凹陷。

排查后发现，问题不在数据格式，而在调度设计。后来加了两层防护：第一层在 scheduler 入口检查任务锁，同一个日期只允许一个任务运行；第二层在 SQLite 表里对 (probe_time, app_name, question) 加唯一索引，重复写入直接插入失败。

CREATE UNIQUE INDEX idx_probe_unique ON probe_records (probe_time, app_name, question);

加上唯一索引之后，重复问题再也没出现过。

4.5 浏览器模式卡死

用 Playwright 跑浏览器自动化时，经常遇到页面加载超时、弹窗遮挡、点击无响应这类问题。最麻烦的是无头模式跑久了容易内存泄漏，任务跑第 50 个问题就开始崩溃。

一般的处理思路是设置每个步骤的显式等待时长，不要依赖隐式等待。还有一个很有效的技巧：每处理完 20 个问题就重启一次浏览器上下文，释放内存。实测把任务吞吐量从 200 条提升到 800 条不崩溃。如果后续还要处理更大量的浏览器采集，建议把采集任务做成横向扩展，多开几个容器分摊压力。

5. 我踩过坑之后的一些体会

整个项目从立项到第一条可用看板上线，大概花了两周时间。真正耗时的不是写代码，而是和几家 AI 应用逐一适配采集方式，以及不断调整问题池让数据波动变小。回过头看，有三件事如果再来一次我会更早做。

第一，问题池要提前设计好并冻结。我们前期频繁修改问题池，导致前后两批数据口径不一致，采纳率对比没有参考价值。建议第一次建池后就定一个“冻结日期”，之后只增不删，新增问题单独标记，这样历史趋势才是对齐的。

第二，原始回答必须留痕。之前为了省数据库空间，只存判定结果不存原文，后来要调整判定规则时发现无据可查。现在我的表结构里一定保留 answer 字段，哪怕看起来很占空间，它换来的是你随时能回溯、能复核、能重新判定的能力。

第三，把异常当常态来设计。API 超时、限流、页面改版都不是偶发事件，而是必然事件。代码里每个外部依赖都要有兜底逻辑，调度任务要支持失败重跑且不产生重复数据。这套系统能稳定跑几个月，靠的不是某个聪明的算法，而是这些不起眼的防御性设计。

如果你也想搭一套 AI 品牌词采纳率监控，别一上来就铺大而全的平台，先用 SQLite 加 Python 脚本跑通单日流程，再慢慢加可视化。跑出第一张趋势图的那一天，你会觉得这活儿从一开始就没白折腾。