跨模型监测应从买家的使用场景出发：他们在哪个入口、用什么语言、带着什么限制条件提问？先记录这些差异，再决定问题集、内容和复测范围，才能避免把不同条件下的回答放在一起比较。
公开的 CN 相关模型（摘自完整名单）
旧稿列出的公开名单：DeepSeek · Kimi · Qwen · GLM · Doubao · MiniMax · ERNIE Bot。
完整名单（含 Global）见 /zh/facts/models-monitored/。
范围边界：官网列出的监测对象不表示每个项目都已接通全部 API。具体模型、版本、联网能力与采样方式，以实际配置和项目约定为准；API 采样也不等同于消费端界面的全部用户体验。采购时应要求对方逐项说明「名单上有」与「本项目实际接通」的区别。
运营注意点
沿用旧稿的五条运营注意点，并补充事实治理重点：
- 语言与题面：中文品类题与英文题分开建基线；不要混用后声称同比。
- 事实源一致性：中英文站点、电商主图价、旗舰参数必须有 canonical 对齐；否则更容易走到「错述」结局。
- 渠道页：经销商价与平台价冲突时，先做事实治理，再改内容。
- 复测分组：CN 组与 Global 组分别报告提及 / 入选 / 准确推荐三层结果。
- 爬虫可读：内容对公开爬虫可访问（按站点自身政策）；品牌站应自查，而不是照抄别人 robots。
事实源清单（示例）
- 中文 canonical 事实页：品牌定义、旗舰规格、价格有效期、售后边界。
- 电商主站与旗舰店价格对齐，并记录负责人与更新日期。
- 对比/选型中文 FAQ，理由可核验、不夸大。
- 对公开爬虫保持可抓取（按你站政策）。
- CN 模型组按周期复测，与 Global 分表。
示例（示例，非真实案例）：某品牌中文站写「旗舰款 4999 元」，电商主图写「到手 4599 元」，旗舰参数页又写「上一代芯片」。此时三类页面同时被检索，模型更可能给出错述。采购时应检查供应商是否有专门处理这类冲突的流程，而不是承诺「一定说对」。
选型时怎么问供应商
沿用旧稿的选型问题，并补充：
- 是否明确列出 Doubao / DeepSeek / Kimi / Qwen / GLM / MiniMax / ERNIE Bot？
- 原始答案是否存档，能否按「问题 × 模型 × 时间」下钻？
- 是否支持同条件复测与审批后执行？
- 报告是否区分「被抓取 / 被索引 / 被引用 / 被推荐」四层？
- 中文与英文事实冲突时，是否有事实治理流程？
品类页参考：/zh/compare/geo-tools/。
本文不主张什么
沿用旧稿的边界，并补充三点：
- 不声称某一中国模型「更好」，也不给出未公开的市场份额。
- 不发明名单外的模型，不把 UA 名称当作模型身份。
- 不保证进入任一模型的候选名单或推荐位。
- 不宣称某渠道一定引用了你的品牌，除非有可核对的监测记录。
- 不把「放行爬虫」等同于「会被推荐」。
FAQ
Q: 只做豆包够不够？ A: 取决于客户实际使用的助手集合；建议按业务地区建立模型组，而不是只覆盖一个。
Q: 中文事实页是否必须？ A: 对中文提问场景强烈建议；并与英文事实互链、避免矛盾。
Q: API 采样能不能代表消费端体验？ A: 不能完全代表。API 采样与消费端界面可能不同，报告应注明采样方式与模型版本。
Q: 供应商名单上有某模型，是否等于本项目已覆盖？ A: 不等于。要求对方逐项说明实际接通情况，写进项目约定。
结语
若团队只盯 ChatGPT，却在 Doubao、DeepSeek 上持续错价或缺席，管理层会看到「海外好像还行、国内完全失控」的割裂。用 /zh/facts/models-monitored/ 作为监测范围的单一事实源，可以避免口头加减模型。更重要的是，把范围与事实治理流程写进采购需求，而不是只买一份名单。
方法论与业务有关的一段说明：本文的模型范围核对表与事实源清单，来自团队在国内模型监测项目中反复使用的检查结构，用于把「覆盖哪些模型」从口头承诺变成可核对的条目。是否适用你的场景，仍应用你自己的问题集实测判断。
抓取配置的具体步骤见 AI 爬虫配置指南。