API 监测与 UI 监测的区别

API 监测与 UI 监测不是同一个问题的两种解法，而是两种口径：API 测的是模型能力接口，UI 测的是用户实际看到的答案，同一问句两边可以给出不同的引用列表。不等价不只是精度问题——检索范围、界面呈现、会话上下文都是变量，先把「不等价」当前提，再谈怎么用。把一套监测运营跑起来之前，要清楚两条路线各自的成本结构与出数资格——同引擎两个入口的回答不等价，这条口径证据与各引擎现状的详细对照见API 端口与网页端的区别，本卡接着讲运营层面的取舍。

对照表

成本结构：两条路线各付什么

API 路线的成本前置且可预期：接口适配、按量计费、错误处理——都是工程问题，一次解决长期有效；它的规模化能力是 UI 路线无法企及的，几百条提问逐日采样只有 API 跑得动。UI 路线的成本是持续的运维税：登录态要养，风控要对抗，界面一改当日采集就可能失败，失败只能如实记缺失、不拿旧数据补位；每一次提问都在消耗采集账号的会话画像与风控余额，频率与账号寿命此消彼长——所以 UI 路线的采样纪律天然偏低频克制：真实会话、固定问句、只读不干预。把 UI 路线当廉价方案是常见误判，它的真实成本藏在运维投入与连续性风险里，不在显性账单里；反过来说，API 的便宜也买不来它没有的东西——口径。两条路线的成本曲线形状也不同：API 的边际成本随题量线性爬升，UI 的边际成本在账号矩阵扩容处跳档——题量翻倍时 API 加预算就行，UI 可能要加一套账号与一套运维排班。

失败处理与合规边界

UI 路线必须预设失败率。改版、限流、验证码都会让部分采集日失败，处理纪律只有一条：缺失记缺失——「没测到」与「没提及」在报表里必须是两种状态，混用一次，这条时间序列的可信度清零。有效回答的判定交给采集器的固定规则：引用被截断、页面改版采到空壳、触发风控拿到异常响应，都不算有效回答，判定规则随版本记录披露。改版适配要预留运维余量，大改版当日的数据缺口宁可留白，也不用旧结构的数据凑。

合规边界是同一条采集纪律的另一面。UI 采集发生在平台侧，自动化访问的边界要自己守住：低频、只读、不干预排序与结果、不对单账号施加批量压力——这既是账号寿命的经济学，也是与平台共处的边界线。平台用户协议对自动化访问普遍有限制性条款，克制的研究性采集与规模化滥用之间界线清晰，任何放大采集频率的决策都应该先过一遍这条边界，而不是等账号被封才回头。

中国场景：覆盖现实决定路线

国内市场的覆盖现实把选择简化了。中国五个消费级平台没有开放「带联网检索的对话 API」，API 路线在国内事实上测不到用户真实看到的答案——不是技术偏好问题，是覆盖现实：正式读数只剩 UI 一条路。连开源监测项目都把这一点写进了设计前提：有开源 GEO 监测项目明确注明 API 线测不了国内五平台，与国产引擎覆盖互补，见NiubiGEO。国内五家的可用通道逐家不同：Kimi 有官方 API 但与网页端不同构（见Kimi 引擎档案），DeepSeek 的 API 与 App 内联网回答不同构，豆包连公开 API 都没有——「有 API」与「API 能替代 UI 口径」在国内是两件事。国内监测的节奏纪律与采集面配置，展开见中国平台监测节奏。

取舍：双轨并行，只用一轨出数

全球引擎（ChatGPT、Perplexity 等）有可用的 API，标准姿势是双轨并行：API 轨跑批量探针与高频趋势，负责「哪里在变」的告警；UI 轨低频确认「用户真实看到的」，负责口径校准——两轨的提问时间要靠近，序列各自成立，跨轨数字不并表。国内五平台按 UI 路线建正式监测，API 只在少数可用处做辅助验证，从不把 API 读数写进正式报表——这是我们自己的执行口径：报表里的每一个数字都来自浏览器实采。UI 路线内部的采样口径（单次还是多次）是下一层决策，辨析见单次采样与多次采样口径的区别。汇报侧给两种口径各留一个名字：API 数字标「接口口径」，UI 数字标「用户口径」，让读报表的人从一开始就知道自己看的是哪条轨。立项时的预算模型按这个结构排：国内口径的 UI 运维成本是固定投入，砍掉它等于没有国内数据；全球口径的 API 费用随题量线性走，可以先窄后宽。