自建AI监测指企业自己写脚本或搭系统，定期向 AI 助手提问并采集答案，统计品牌提及率与引用来源。 技术上完全可行，但成本重心不在写爬虫，而在三件事：账号与风控的持续消耗、各平台没有稳定官方接口带来的长期维护量、模型静默更新造成的历史数据不可比。前两项烧钱和人力，第三项更贵——它让你已经积累的指标失去决策价值。
这篇文章按工时和统计口径把这笔账算清楚，也会明确指出哪些场景下自己动手反而是更优解。
先给结论：什么时候该自建，什么时候不该
判断线只有一条：你需要的是一个数字，还是一条能对比的曲线。 需要数字，脚本够用；需要曲线，你要维护的是一套观测系统。
| 场景 | 更合适的选择 | 关键原因 |
|---|---|---|
| 只跑 1 个平台、验证某类 Prompt 假设 | 自建 | 工程量小，口径无需跨平台对齐 |
| 内部算法/内容实验，数据不外发 | 自建 | 保密要求高于稳定性要求 |
| 一次性调研，2–4 周内出结论 | 自建 | 不涉及长期可比性 |
| 4 个以上平台、周度更新 | 采购 | 账号池与解析维护量随平台数近似线性增长 |
| 需要季度/年度趋势对比 | 采购 | 需要模型版本断点标记和口径冻结能力 |
| 需要竞品对照、引用来源归因 | 采购 | 归因逻辑本身是长期工程，不是抓取问题 |
| 数据要进管理层汇报或对客交付 | 采购 | 需要可复现的采样口径与审计留痕 |
| 多语言、多国家市场同时监测 | 采购 | 平台清单、Prompt 语种、本地信源三重叠加 |
最后一行常被漏掉。国内团队默认监测对象是 DeepSeek、豆包、Kimi、通义千问；一旦业务出海，Perplexity、Le Chat、Naver、Yandex 各有独立的检索栈和引用偏好，同一个品牌可能在英文答案里稳定出现、在德语答案里完全消失（见多语言 AI 可见度差异）。自建的账号池要按国家再乘一遍。
自建AI监测到底要建什么：四层工作量拆解
很多团队评估自建时只算了第一层。完整的自建AI监测至少有四层，每层的维护频率不同。
- 采集层：模拟浏览器发起提问、等待流式输出结束、抓取完整答案与引用块。一次性投入，约 3–5 人周出可用版本。
- 账号与网络层：账号池、登录态保活、代理出口、验证码处理、并发调度。持续消耗，不随时间下降。
- 解析层：从答案里抽出品牌提及、位置、情感倾向、被引用的来源域名与链接。同样持续消耗。
- 口径层：定义 Prompt 集、采样次数、聚合规则、模型版本标记、异常剔除规则。几乎没人在立项时算过，但它决定前三层产出的数据能不能用。
账号与风控：最容易被低估的一项
自建方案第一个撞墙的地方。国内主流 AI 助手对高频、规律化的自动提问都有风控，触发后不是直接封号，而是先降速、加验证、再限制会话。
我们在 2026 年 5—6 月做了一次持续 42 天的实测：在 DeepSeek、豆包、Kimi、通义千问四个平台的网页端，每平台 6 个独立账号、独立出口 IP、提问间隔随机化 20–90 秒，人工复核每次异常类型。观察到的规律：
- 单账号日提问量超过 40–60 次后，普遍开始出现验证挑战或响应延迟明显拉长。
- 同账号并发会话超过 3 个时，风控触发概率显著上升，恢复期从数小时到一天不等。
- 固定间隔提问比随机间隔更容易被识别，规律性本身就是特征。
- 42 天内共有 5 个账号进入不可用状态，其中 3 个在人工申诉后恢复，账号自然损耗率约每月 8%–15%。
这组数字是我们自己环境下的观测，不同地区、不同账号来源会有偏差，请当量级参考而非常数。但量级足以说明问题：假设覆盖 4 个平台、每平台 50 个 Prompt、每个 Prompt 每周采样 5 次，就是每周 1000 次提问。按单账号日上限 50 次、留 50% 安全余量计算，你需要维持一个 20 个以上活跃账号的池子，并按月补充损耗。
账号获取、实名、保活、异常处置，这部分工作没有技术含量，但不能停。它是自建AI监测里最没有成就感、也最难自动化掉的固定支出。
合规边界：先看清你在踩哪条线
工时之外还有一项自建方总是跳过的成本：自动化提问基本都写在平台用户协议的禁止条款里。多数中文 AI 助手的服务条款包含"不得使用自动化手段批量访问"类表述，OpenAI 的使用政策同样禁止绕过速率限制与保护措施。这意味着三件事：
- 账号被封时你没有申诉理由，损耗率就是硬成本。
- 用真实员工手机号养账号，风险落在个人身上。
- 数据一旦对外交付或写进公开报告，采集方式本身可能成为问题。
不是说不能做，而是这条线要在立项时由法务而不是工程师来划。
没有稳定官方接口，意味着你维护的是"页面结构"而不是"数据接口"
关键区别：官方 API 变更会有版本号和公告，网页结构变更不会。 你的解析逻辑写给 DOM，而 DOM 随时可能变。
同一个 42 天窗口里，四个平台合计发生 9 次需要改代码的变更，平均每个平台约每 18 天一次。类型分布：
- 流式输出的结束判定条件变化（3 次）：脚本以为答案没写完，抓到半截。
- 引用来源区块的结构调整（3 次）：这类最危险，因为它不报错，只是引用列表突然变成空数组，指标悄悄归零。
- 登录态或会话初始化流程变化（2 次）：直接全线中断，反而容易发现。
- 答案区加入折叠/展开交互（1 次）：抓取到的正文被截断。
"静默失败"占了三分之一。脚本不抛异常、任务正常结束、数据表照常写入——只是数值错了。等你在月度复盘时发现引用来源数据断了两周，那两周的数据已经无法回补，因为 AI 答案不可回溯采集。
这也是为什么引用来源解析比提及率更难自建。判断"品牌名有没有出现"是字符串匹配；判断"AI 引用了哪个来源、这个来源属于谁、它为什么被选中"是归因工程。不同平台的引用形态差异很大，有的给完整链接，有的只给站点名，有的干脆不显示来源。
还有一类归因坑：AI 引用的常常不是你的官网，而是百科、垂类媒体、评测站等第三方来源。自建脚本抓到域名容易，判断"这个域名算不算我方阵地"需要人工维护映射表——各市场常被引用的本地信源清单可参考按市场拆解的信源盘点，中文场景下百科条目的权重问题见百科对 AI 推荐的实际影响。
一个更隐蔽的解析坑：品牌名在别的语言里不是同一个词
监测中文之外的市场时，字符串匹配会直接失效。品牌名被音译、被本地化、被拆成两个词，脚本按拉丁字母匹配就统计不到，读数偏低但看起来"数据正常"。自建方案里的品牌名匹配必须是一张别名表，不是一个常量。 别名维护的复杂度参见品牌名转写与实体混淆。
模型静默更新：为什么上季度的 AI 提及率不能和这季度比
这是自建方案最贵的一项成本，且不体现在任何账单上。 大模型平台持续上线新版本、下线旧版本，网页端用户通常拿不到版本号。阿里云百炼的模型上下架与更新说明和百度千帆的模型版本升级及退役机制都公开写明了滚动升级与旧版本退役规则——API 用户至少能看到版本标识，网页端用户只能看到"答案变了"。
后果很直接：你 3 月测到某品牌 AI 提及率 32%，6 月测到 41%，中间模型换过一次版本。这 9 个百分点里有多少是内容优化的功劳，有多少是模型换了检索策略或语料，你没有任何办法拆开。趋势图还在，因果关系断了。
我们的应对办法是金丝雀 Prompt 集，可以直接复用到自建AI监测里：
- 挑 15–20 个与你品牌无关、答案高度稳定的问题（如"新能源汽车电池的主要技术路线有哪些"）作为对照组。
- 每天固定时间跑一遍，记录答案长度分布、引用来源数量、结构模板（是否分点、是否带表格）。
- 当这些指标在同一天出现跨 Prompt 的同向突变——例如平均引用数从 4.2 掉到 1.1、答案普遍变短——判定为疑似模型更新。
- 在时间序列上打断点标记，断点前后默认不做直接同比，只做断点内趋势比较。
- 断点后重跑一次基线，重建对照基准。
42 天里，我们用这套方法在四个平台上共识别出 6 次疑似版本变更，其中 2 次伴随事后官方公告可交叉验证，另外 4 次没有任何公开说明。没有断点标记的历史曲线，本质上是把几条不同尺子量出来的数据画在了一起。
金丝雀集还能顺带发现另一类漂移：模型开始引用你的旧版文档。检索侧一变，被召回的常常是历史版本页面，AI 引用过期文档的成因与信号里的版本信号做法值得一并纳入监测项。
采样次数不够，你看到的就是噪声
这是自建AI监测最常见的统计错误。AI 提及率是一个二项分布的比例估计：同一个问题问 10 次可能被提及 3 次，问 100 次可能被提及 34 次，真值不变，读数会跳。
95% 置信区间半宽为 1.96 × √(p(1-p)/n)。取真实提及率 p=30%：
| 单 Prompt 采样次数 n | 95% 置信区间半宽 | 你实际看到的读数范围 |
|---|---|---|
| 10 | ±28.4pp | 2% – 58% |
| 30 | ±16.4pp | 14% – 46% |
| 50 | ±12.7pp | 17% – 43% |
| 100 | ±9.0pp | 21% – 39% |
| 200 | ±6.4pp | 24% – 36% |
| 400 | ±4.5pp | 26% – 34% |
再往前一步。要判断"这个月比上个月提升了 5 个百分点"是不是真的，需检验两个独立比例之差，所需样本量约 n > 2p(1-p) × (1.96/0.05)²，代入 p=30% 得到 每个时间点约需 650 次采样；想可靠识别 10pp 的变化，门槛降到约 165 次。
对照现实：很多自建脚本的默认配置是"30 个 Prompt，每个跑 1 次，每周一次"。这个配置连 15pp 的变化都识别不了，但它产出的折线图看上去波澜起伏，非常像有洞察。
三个把统计口径搞坏的常见做法
- 把 30 个不同 Prompt 各跑 1 次，当成同一个 Prompt 跑 30 次。 不同问题的真实提及率本就不同，混在一起聚合，方差比理论值更大（统计上称设计效应）。正确做法：先在 Prompt 层重复采样、算出各自比例，再按业务权重聚合，同时保留每个 Prompt 的置信区间。
- 把新会话和续聊混采。 带上下文的追问会显著改变答案分布，两种模式必须分开建指标。
- 只采购买决策类 Prompt。 客户成交后仍会拿产品问题去问 AI，售后与使用类问题的答案质量同样影响品牌口碑，却几乎不在标准 Prompt 集里（见成交之后 AI 怎么回答老客户的问题）。
口径设计才是自建和采购的真正分水岭——它不是工程能力问题。口径一旦定错，采集得再稳定也救不回来。
一份诚实的 12 个月工时对照
下表按 4 平台 × 50 Prompt × 周度采样的规模估算，单位人日。用工时而非报价，因为人力成本各家差异太大，工时量级相对稳定。
| 成本项 | 自建（首年） | 自建（次年起） | 采购 |
|---|---|---|---|
| 采集链路初版开发 | 15–25 | — | 0 |
| 解析与指标层开发 | 10–20 | — | 0 |
| 结构变更修复（按每平台 18 天一次） | 20–30 | 20–30 | 0 |
| 账号池建设与月度补充 | 8–12 | 8–12 | 0 |
| 代理与网络运维 | 5–10 | 5–10 | 0 |
| 口径设计与模型断点维护 | 10–15 | 6–10 | 0–2 |
| 报表与可视化 | 8–15 | 3–5 | 0 |
| 数据返工（口径错误导致重采） | 5–15 | 3–8 | 0 |
| 合计（人日/年） | 81–142 | 45–75 | 约 2–5 |
首年 81–142 人日，相当于 0.4–0.7 个全职工程师，且是持续占用而非项目制投入。次年不会归零，因为结构变更和账号损耗是常态成本。
表外还有两项没法折算成人日的成本：代理与账号的现金支出（按 20 个账号池加住宅代理出口估，量级在每月数千元），以及排队等待成本——采集脚本坏在周五，数据缺口就是整整一周，而这一周的答案再也拿不回来。
最后一行"数据返工"最容易被忽略：口径错误往往三个月后才被发现，而 AI 答案不可回溯，这部分数据是永久损失的，不是加班能补回来。
哪些场景下自建确实更划算
不必把自建AI监测一棍子打死。以下四类场景，自己写脚本明显更优：
- 单平台深度实验。比如只想知道"改了产品页的结构化描述后，DeepSeek 的回答里我们的参数有没有被引用正确"，只需一个平台、一组 Prompt、两周对比。上工具是杀鸡用牛刀。
- 高保密内容测试。未发布的产品命名、定价策略、公关口径预演，不适合经过第三方系统。
- 极窄垂直的自定义指标。例如统计"AI 答案里提到我们时，是否同时提到某项资质认证"——医疗、金融、法律类品牌尤其需要这类自定义判定，因为这些行业的 AI 答案大量带免责声明和拒答（见受监管行业的 AI 答案形态），标准工具的"是否提及"字段根本不够用。
- 技术团队本来就有采集基础设施。已有成熟代理池、反检测框架和调度系统，边际成本确实低——但注意，口径层的成本一分不少。
务实的组合是：长期趋势和多平台对比用工具，短周期定向实验用脚本。 两者的数据不要混在一张图上，因为口径不同。
如果决定自建：8 条最低验收标准
无论最终选哪条路，这 8 条都值得当自查清单。任何一条不满足，你的数据在汇报场合都站不住。
- 采样次数写进指标定义。每个数字旁边必须标注 n 和置信区间，不允许出现裸比例。
- 静默失败必须报警。引用来源数为 0、答案长度低于阈值、字段缺失，都要触发告警而不是静静入库。
- 金丝雀 Prompt 集常驻运行。识别模型变更，成本很低但作用最大。
- 模型断点在时间序列上可见。断点前后禁止直接同比，图表上要有标记。
- 原始答案全文留存。只存解析结果，口径一改就得重采，而重采拿不回历史。
- Prompt 集版本化。改一个字也要记版本，混用不同版本会污染趋势。
- 账号与出口 IP 分离记录。哪批数据来自哪个账号/出口要可追溯，便于排查异常样本。
- 口径文档随数据交付。谁、在什么时间、用什么频率、在哪个平台、用哪版 Prompt 采的——缺一项，这份数据就不能对外。
顺带一提，如果发现某个平台的答案里几乎从不出现你的站点内容，问题可能不在监测端而在抓取端：先确认 AI 的爬虫真能抓到你的页面，再讨论提及率高低。
常见问题
自建AI监测最大的风险是封号吗？
不是。封号可以靠账号池和频控缓解，属于可管理的运维成本。真正不可逆的风险是模型静默更新导致的历史数据不可比——账号没了可以补，历史数据的口径断层补不回来，因为 AI 答案无法回溯采集。
一个 Prompt 到底要跑多少次才算数？
看你要识别多大的变化。想可靠识别 10 个百分点的变化，单个 Prompt 每个时间点约需 165 次采样；想识别 5 个百分点，需约 650 次（按真实提及率 30% 估算）。跑 1 次得到的数字只能说明"这次被提了"，不能说明任何趋势。
怎么判断 AI 平台是不是偷偷换了模型？
用金丝雀 Prompt 集：选 15–20 个与品牌无关、答案稳定的问题每天跑，监控答案长度、引用来源数量和回答结构。当这些指标在同一天跨多个 Prompt 同向突变，基本可判定为版本变更，此时应在数据上打断点。
用官方 API 做监测，是不是就没这些问题了？
会少一部分，但解决不了核心问题。API 能拿到版本号、避开网页风控，但API 返回的答案和用户在 App 里看到的答案不是同一个东西——网页端通常带联网检索、个性化和产品层的重排逻辑，而这正是品牌可见度真正发生的地方。用 API 监测，测的是模型，不是搜索体验。
自建AI监测会违反平台规则吗？
多数平台的用户协议禁止自动化批量访问。技术上能跑通不等于合规，尤其当采集数据要对客交付或写进公开报告时。立项前让法务过一遍条款，并明确账号来源；用员工个人实名账号跑批量脚本，风险落在个人身上。
自建方案能覆盖海外市场吗？
能，但成本要按国家再乘一遍。每个市场的答案引擎清单不同、Prompt 要用当地语言写、品牌名可能被音译成另一个词、被引用的本地媒体也完全不同。国内四平台的账号池经验无法平移到 Perplexity、Naver 或 Yandex。
我们已经自建了半年，要迁移吗？
先做数据体检，按上面 8 条验收标准逐条打分。如果原始答案全文有留存、Prompt 集有版本、模型断点有标记，历史数据仍有价值，迁移时可并行运行 4–6 周做口径对齐。如果这三样都没有，坦率说，历史数据参考价值有限，不如把重点放在把新口径一次定对。