截至 11 月 6 日的公开信息，QuestMobile《2026 中国移动互联网秋季大报告》给出的 AI 原生应用月活格局是：豆包 4.19 亿、千问 1.58 亿、DeepSeek 1.2 亿，从第四名元宝起直接落到 3000 万级。同期千问接入苹果智能国行版本，用户不主动开启时系统不会自动转接。对做 AI 搜索可见度监测的团队，这两条信息指向同一个问题：品牌被 AI 提到的机会，正在从 App 内提问扩散到系统级唤起，采样入口如果还停在几个 App，测出来的可见度就会偏。
入口变了，采样清单也得变
可见度的分母是提问机会。用户在一个入口提问十次，和在一百个入口各提问一次，对品牌曝光的价值完全不同。按月活排序分配采样预算，隐含的假设是用户规模等于提问规模，但公开数据恰好相反：千问月活 1.58 亿，人均月使用 17.8 次；豆包月活 4.19 亿，人均 72 次。规模差 2.6 倍，提问量差接近 10 倍。按用户数分配预算，会把资源压在提问最少的那个平台上。
系统级入口把这件事变得更复杂。接入系统之后，用户不需要打开 App 就能唤起，提问被拆成更短、更碎的场景指令，比如查天气时顺带问一句附近的店。这类提问对本地零售与连锁品牌的可见度影响很大，但在 App 内采样根本抓不到，因为会话根本不经过 App 界面。问题库如果只覆盖完整问句，就会系统性漏掉这一层。
| 入口类型 | 提问特征 | 采样难点 | 权重依据 |
|---|---|---|---|
| 独立 App | 主动、长问题、多轮追问 | 平台之间不可直接比较 | 月活乘以人均使用次数 |
| 系统级助手 | 短指令、场景触发 | 会话不落在 App 内 | 启用率与系统份额 |
| 浏览器与搜索框 | 搜索式提问、带比价意图 | 与 AI 摘要混合呈现 | 搜索份额与摘要覆盖率 |
| 站内 AI 助手 | 商品页内问答 | 封闭环境、难复现 | 站内搜索量与转化数据 |
提问频次比月活更接近曝光机会
用提问量而不是用户量做权重
一个可执行的换算是把月活乘以人均使用次数，得到月度提问量级。按公开数据，豆包约 301 亿次量级，DeepSeek 约 79 亿次，千问约 28 亿次。这个排序与月活排序一致，但差距被明显放大，用它分配采样配额，能避免把资源过度投在有用户但不常提问的平台上。换算本身是估算，但比直接按月活分配更接近真实的曝光机会。
时长差异说明用途不同
千问月均使用时长 22.7 分钟，低于 DeepSeek、豆包、元宝、Kimi 与文心。时长短不等于价值低，它往往意味着任务更集中：用户来办事，办完就走。对品牌来说，办事型入口的曝光更靠近交易决策，购物、订票、找店的场景里被推荐，转化链路更短。监测时应把任务型提问和闲聊型提问分开统计，否则两类场景的可见度会互相稀释，看起来都一样，实际含义完全不同。
可见度报告要加一行入口说明
现在多数可见度报告只写品牌在主流 AI 平台上的提及率，读者无法判断这个数字覆盖了哪些入口。加一行入口说明的成本很低：列出采样的平台、每个平台的采样问题数、是否包含系统级唤起场景。这一行决定了报告能不能被复核，也决定了结论能被用到什么范围。当客户问为什么这个月和上个月差这么多，入口清单就是第一层解释。
| 报告字段 | 填写要求 | 常见缺口 |
|---|---|---|
| 采样平台 | 列出全部平台与版本 | 只写平台名不写版本 |
| 问题库规模 | 每平台问题数与更新日期 | 问题库长期未更新 |
| 入口类型覆盖 | 是否含系统级与站内助手 | 默认只采独立 App |
| 提问类型分布 | 任务型与闲聊型占比 | 未做区分，混在一起算 |
品牌该先做什么
先做的事不是加预算，而是把问题库补上系统级入口的场景。系统级唤起的提问更碎、更本地，问题库需要加入附近、最近的、现在去这类限定词，并对应到具体城市。其次是给每个平台标注提问类型，把任务型问题单独建一组，观察品牌在办事场景里的被推荐情况。最后是把竞品放在同一组问题下跑，否则单独看自己的提及率，无法判断是变好还是别人变差。可见度是相对量，没有竞品对照就没有结论。
常见问题
GEO 监测要不要把系统级入口算进去？
要算，但要先看启用率。系统级唤起占比高时，漏采会让本地场景的可见度被严重低估；启用率低时可以先用较低权重覆盖，逐步补齐。
月活高的平台一定更值得采样吗？
不一定。提问频次决定曝光机会，月活高但人均使用低的平台，实际提问量可能远低于预期。用月活乘人均次数做权重更接近真实。
提问量该怎么估才算合理？
用月活乘人均月使用次数做量级估算即可，不必追求精确。关键是排序与相对比例，而不是绝对数字，因为采样配额是按比例分配的。
可见度报告怎么写才可复核？
写清入口清单、问题库版本与提问类型分布，三项缺一，读者无法判断数字覆盖了什么。可复核的报告才能被当成决策依据。
