做 AI 搜索可见度监测这段时间，我们踩过的最没技术含量、又最难跟人解释清楚的一个坑，是「覆盖了多少个引擎」这句话到底在数什么。
我们的配置里躺着 12 个 AI 引擎，每期定时任务会给这 12 个各下发一遍，跑批日志上 12 条记录整整齐齐。但拉报表算分母的时候，我们只敢用 11。
差的那一个是 Claude。原因跟模型能力无关、跟该引擎的服务本身也无关——我方账号的登录态失效了，在我们取数的这 5 期（期 4 至期 8，按 cycle_id 切期）里连续没有产出。这事说破了一文不值，但它把一个问题摆上了台面：「覆盖 N 个引擎」里的这个 N，是配置数、下发数，还是出数？
一、同一个 N，其实有三层含义
监测系统里至少存在三个不同的 N，它们平时长得很像，出问题的时候差别很大：
- N_config（配置层）：控制台里勾选、产品文档里声明支持的引擎数。这是对外口径，也是绝大多数官网上写的那个数。
- N_dispatch（下发层）：本期定时任务实际发出请求的引擎数。
- N_effective（产出层）：本期实际有返回、进入分母参与计算的引擎数。
以我方自监测为例（口径：题库 45 道，每期每个引擎每题下发 1 次，按 cycle_id 切期，数据核对于 2026-09-04 PDT）：N_config = 12（12 家均已接入，且每期真实下发，对外口径就是 12），N_dispatch = 12，N_effective = 11。
于是每期下发 540 = 12 × 45 次，而进分母的样本是 495 = 11 × 45。这两个数字一旦同时出现在同一份报告里，就必须把 495 = 11 × 45 写出来。否则读的人会默认 540 是分母，而这中间差的 45 次并不是「没被提及」，是根本没有回答。
但 495 本身还需要再标一次口径，否则我们就在犯自己要讲的那个错：495 是「接口返回成功」的样本数，不是「拿回了有效正文」的样本数。这 495 里含少量空答与拒答——以期 8 为例，其中真正带正文的回答约 472 条。我们把空答计入了分母（这是一个显式选择，理由见下一节），所以 495 只能读成「成功返回的样本数」；谁要是把它读成「有效回答数」，那是我们没写清楚，不是他理解错了。
11 和 12 只差一个数字，落到分母上就是 495 和 540 的差别：540 当分母，会把 45 次「没拿到数据」计入「没被提及」，可见度分数系统性偏低；只在正文里含糊写一句「覆盖 12 个引擎」，又会让人默认分母是 540。两种写法都不算撒谎，但都读不出真实情况。
二、把「没提及」和「没回答」混成一格，是最贵的一个错
我们自己的数据可以直接当反例。第 4 期到第 8 期，我方品牌在自己这套题面上被提及的次数是 24 / 18 / 4 / 0 / 3。第 7 期是 0。
先把这组数的口径写全，免得它也犯本文正在讲的毛病：被提及＝该期该引擎的回答正文中出现品牌名或官网域名即计一次，同一条回答内多次出现只计一次；按 cycle_id 切期，分母同为 495 = 11 × 45（接口返回成功口径，含空答）；数据核对于 2026-09-04 PDT。
还要补一句更扫兴的：**以上为 2026-09-04 PDT 的快照。**我们的跑批记录在重跑时会原地覆盖 outcome，同题重跑会改写当期结果，历史值不可回查——所以这组数只能当取数时点的快照报，不能当历史序列引用。
如果记账时把「引擎回答了但没提到你」和「引擎这期压根没回答」都写成 0，那这两种 0 在报表上完全无法区分。趋势线上的一个坑，你分不清是可见度掉了，还是采集断了。
所以样本状态至少要三态，不能布尔：
answered— 拿到带正文的回答。进分母，命中与否另算。empty— 请求成功但返回为空、拒答、或触发安全策略。进不进分母都可以，但必须显式决定并写进口径说明，不能让它默认落进某一边。我方目前的选择是计入分母，这也正是我方那个 495 是「接口返回成功」口径的原因；这个选择本身没有对错，但不写出来，读者就无从判断。not_produced— 没拿到回答：登录态失效、限流、超时、渠道结构变更导致解析失败。不进分母，且必须单独可查。
配套还有两条工程约束，我们是吃过亏才补上的：
第一，分母要能按期回算，切期不要用自然日窗口。 我们按 cycle_id（期次）切数。rerun、补跑、跨时区都会让日期窗口把相邻两期的数据混进来——尤其数据库时区和你算日期的时区不一致时，一次几小时的偏移就能让一整批数据落到隔壁期。
第二，跑批记录不要就地覆盖。 我们这套目前就是原地覆盖 outcome 的，代价上一节已经写了：历史值查不回来，当期值只能当快照报。要留历史就追加写，别 UPDATE——这条是我们写给自己的待办，不是已经做好的事。
三、公开信息里的覆盖数：本文核对到的例子
先把范围说清楚：本文核对了 8 家 GEO / AI 可见度监测产品的公开页面（含官网自有的、无需登录的公开接口），核对时间统一为 2026-09-04 PDT，每条引文挂它实际所在的页面地址。以下只摘录各家官网原文，不打分、不排名次、不评价优劣、不推测动机；同一家多处口径互相矛盾的，原样并列，本文不替对方裁决哪个对。列出来只有一个目的：说明「覆盖数」这个指标在这些公开表述里没有统一定义，读的人得自己做换算。我方同样如此——12 和 11 的差别也需要解释。
同一页面内多个数字并列。 AIDSO 爱搜首页同时出现三处表述：「支持主流 AI 引擎：豆包、DeepSeek、文心一言、通义千问、Kimi、腾讯元宝等国内TOP大模型」「实时监控豆包、DeepSeek、腾讯元宝、千问、Kimi、百度AI等10余个主流AI平台」「覆盖12个平台，并支持额外扩展」；同页另写「支持App端：豆包App、DeepSeek App已可监测，更接近移动端真实用户路径」；该页未给出与「12个」对应的完整具名清单（来源：https://www.aidso.com/ ，核对于 2026-09-04 PDT）。智推时代 GenOptima 首页同页出现三个数字：「全球 20+ AI 搜索平台全覆盖」（该处按海外／国内两栏具名列出海外 8 家、国内 12 家）、「14 个大模型深度适配：国内 6 + 海外 8」、「已服务 400+ 品牌、覆盖 6 大 AI 平台」；官网未就三者关系作说明（来源：https://zhituishidai.com/ ，同日核对）。
同一家产品在不同页面上的用词不同。 透镜 GEO 定价页写付费档「5 大主流 AI：豆包 · DeepSeek · 文心一言 · 通义千问 · 元宝」，并标注「AI 引擎监控能力：网页端 / APP 端 / 双端」，同页附免责句「以上为当前支持的 AI 模型，覆盖范围可能随各平台情况动态调整，以实际服务为准」，同页 FAQ 写免费版为「3 个网页端 AI 引擎」（来源：https://geo.timus.cn/pricing ，同日核对）；同站首页写「覆盖 8 大主流 AI 引擎端」（来源：https://geo.timus.cn/ ，同日核对）。两处用词分别是「AI 模型」与「AI 引擎端」，官网未说明两者关系。
覆盖数按档位变化。 Profound 定价页按档位列明：Starter 档「ChatGPT tracking only」，Growth 档「3 Answer Engines tracked」（对照表列 ChatGPT、Perplexity、Google AI Overviews），Enterprise 档「Up to 9 Answer Engines tracked」并在对照表中逐项列出 9 家；同一页还把抓取量写成两个单位——Starter「50 unique prompts / 1,500 responses monthly」，Growth「100 unique prompts / 9,000 responses monthly」（来源：https://www.tryprofound.com/pricing ，同日核对）。Dageno 定价页三个付费档均为「Platforms: 3」，对照表写「Choose any 3 platforms」，可选池逐项列出 7 家（ChatGPT、Grok、Gemini、Perplexity、Google AI Mode、Google AI Overview、Copilot），Enterprise 档为「Custom full coverage」；同页页脚的「AI Platform Monitoring」栏列出 6 项，未含 Copilot（来源：https://dageno.ai/pricing ，同日核对；该栏为全站通用页脚，此处按它实际出现的这一页标注）。ImpetaAI 慧辰的官网公开接口按档位下发具名清单：免费版 3 个（豆包、DeepSeek、文心一言），高级版与专业版各 6 个（豆包、DeepSeek、Kimi、元宝、千问、文心一言），企业版接口值 modelLimit = 5 并列出 5 家，而营销页对应位置的文案是「覆盖大模型：按需定制」（接口来源：https://impetaai.hcr.com.cn/api/plan/showList ；页面来源：https://impetaai.hcr.com.cn/marketing/intro ，同日核对）。也就是说，看到一个覆盖数，先得问清是哪一档的。
总数给了，逐项清单不一定齐。 新榜主站首页 GEO 版块写「已支持豆包/元宝/DeepSeek/Kimi等6大AI平台」，具名 4 个（来源：https://newrank.cn/ ，同日核对）；其产品站新榜智汇首屏为 6 张平台 logo 轮播，alt 属性为 img1–img6、无文字标注，第 5、6 家的名字在该页取不到，轮播旁标注「MORE PLATFORMS COMING SOON」（来源：https://geo.newrank.cn/ ，同日核对）。搜极星 FAQ 写「我们目前覆盖全网主流的12+大模型平台，包括国内的DeepSeek、文心一言、通义千问、Kimi、豆包、智谱清言、元宝，以及全球主流生成式AI平台」，国内具名 7 家，海外部分未逐项具名；这段 FAQ 是首页上的折叠区、没有独立页面地址，所以只能挂首页（来源：https://www.sougeo.com/ 首页 FAQ 折叠区，文案源文件 https://www.sougeo.com/assets/js/home-DGZA7ud8.js ，同日核对）。
这些差异本身很正常——引擎接入是动态的，档位与页面文案的更新节奏也不一样，上面就有官网自己写明「覆盖范围可能随各平台情况动态调整」的。对读者来说，可操作的结论只有一条：数字缺少定义的时候没法横向对齐，看到一个覆盖数，先问它数的是什么。
四、一张读官网用的核对清单
看到「覆盖 N 个 AI 引擎」，逐条问：
- N 数的是什么？ 模型、平台，还是「端」？网页端和 App 端算一个还是两个？
- 有没有逐项具名？ 总数和具名清单能对上吗？对不上的那几个是哪些？
- 哪一档的 N？ 免费档、入门档、顶档分别是多少？
- 是「支持」还是「本期实际产出」？ 有没有公布有效样本数或采集成功率？
- 分母是什么单位？ prompt 数还是 response 数？每个引擎每期跑几次？
- 失败样本怎么记账？ 重试几次？失败的算不算进分母？空答算哪一类？
- 口径变更怎么处理？ 增删引擎之后，历史数据是重算、断层，还是默默混在一起？这条我们自己一开始也没想到，但它直接决定趋势图能不能看。
第 4 条和第 7 条是我认为最值得问的两条。这两条在本文核对的这几家官网页面上，我都没有查到对应说明（核对页面与时间见上一节）。
五、如果你自己在搭这套东西
四条落地建议，都是我们补过的坑：
- 把 N_effective 做成一等指标，和业务指标一起印在每期报告的头部，而不是埋在日志里。分母变了却没人注意，是我们自己踩过的失真来源里最难事后追认的一种。
- 登录态类采集通道要有独立健康检查，与业务跑批解耦。否则登录态失效会以「这期数据怎么少了」的形式出现，非常容易被误读成「曝光下降」——我们那 5 期就是这么过来的。
- 建一张「期次 × 引擎」的对账矩阵，每格记
answered / empty / not_produced三态计数。这张表本身就是覆盖度的证据，比任何一句「覆盖 N 个引擎」都可核验。 - 口径变更要登记生效期次，趋势图上打断点。增删一个引擎就是换了分母，不打断点的曲线是两条曲线接在一起。
最后
覆盖数是个门槛指标，不是质量指标。它能告诉你一个工具最多可能看到哪些地方，不能告诉你它这期实际看到了多少。真正该被写进封面的，是那个更朴素的式子：本期进分母的样本 = 有效引擎数 × 题目数，以及它和上期是不是同一个分母、里头的空答算在哪一边。
也说清这套数据的边界：我方的监测只能说明「在这 45 道题面、11 个有效引擎里，谁被写进了回答」；它不能说明市场份额，不能说明产品优劣，也不能推导出任何人照做会得到什么结果。
我们把自己也放进了同一套测量里，数字不好看：第 4 到第 8 期被提及 24 / 18 / 4 / 0 / 3，第 7 期是 0，分母始终是 495 = 11 × 45（匹配规则、切期方式与快照声明同第二节）。写出来是因为，我方的数同样要按这套规矩记账——分母写清楚，难看的期次也照原样公布。
这套记账方式落在我们自己的产品上：本文中的自监测数据，出自我们自家的 GEO 监测产品（对外口径覆盖 12 个 AI 引擎，本次实测有效 11 个）。也就是说，我们自己也是这个品类里的一方，请据此判断本文的立场。
文中第三方信息均取自各家官网公开页面或其官网自有的公开接口，每条按它实际所在的页面地址标注，核对时间为 2026-09-04（PDT）；此后可能变化，以各官网实际展示为准。