API 回答能代表 App 里的品牌表现吗？
先确认报告测的是哪个入口。平台名称一样，不足以证明 API、网页和 App 的回答条件相同。
更新于
报告要把入口写出来
API 监测便于按固定题库重复采样。它记录的是那次 API 请求的回答，结论的范围也应写到 API。网页与 App 里的观察单独记录，不能换成一个平台名就合并。
不同入口可能使用不同模型、系统设置、检索方式或账号上下文。实际采用什么，要依据配置与观测记录核查，不能仅凭同一个品牌名称推断。
比较之前，对齐能确认的条件
| 检查项 | 需要留下的记录 |
|---|---|
| 问题 | 完整问题文本，是否带品牌名，是否新建对话。 |
| 模型与入口 | 可见模型信息、API/网页/App；不可见的条件标为未知。 |
| 联网与来源 | 联网开关或请求参数，返回的原生引用与回答中的 URL。 |
| 账号与地区 | 与采样相关的账号状态、地区和上下文，不保存无关个人资料。 |
| 回答证据 | 回答全文、采样日期、截图或可复核的记录。 |
打开联网开关，还要看返回了什么
请求带了联网参数，可以说明请求条件；是否返回来源，需要看实际响应。回答正文出现一个链接，也不能直接当作检索已发生的完整证明。
保留平台原生引用和原始响应信息。重要来源实际打开核查。没有来源证据时，按已知条件记录，不把“配置了联网”写成“官网已被检索引用”。
两类记录可以互相补充
固定 API 题库适合持续比较同条件结果；网页和 App 观察能补充客户常用入口的现象。两者各自说明范围。
当 API 没提品牌、App 提了品牌，先核对问题、日期、模型、联网和上下文。差异本身值得记录，还需要更多同条件采样来解释原因。
采购监测服务前，确认套餐测量的入口和频率。展示几个平台名称，不代表已经验证了这些平台所有入口。
先看 AI 现在怎么说你。
提供品牌和官网，从 10 个客户会问的问题开始。