同厂商 AI 网页端与 API，为何不能当成同一个监测入口？
简短结论：在这次 1 条问题、2 家厂商、12 次运行的配对样本中，品牌集合部分相近， 但来源域名重合很低。因此，本样本不支持用 API 的来源与回答替代网页端观测。 它不能证明所有问题都会出现同样差异，也不是 GEO 优化前后的效果实验。
若要复用这类对比，请先阅读GEO 监测的条件记录、失败处理与复测方法， 再按AI 引用核验清单核对具体来源。 下文保留原始研究日期、样本范围、聚合数据和质量失败记录。
用一个真实研究案例，读懂“为什么要分开测”
一位品牌负责人可能会问：“API 已经提到我的品牌，消费者打开同厂商的 AI App，也会看到 相同推荐和出处吗？”下面用已公开的能量饮料问题配对研究解释判断过程。研究只覆盖一条 问题，不是新做的客户案例，也没有验证某次官网修改带来的效果。
- 先明确要判断的事：同一个问题，在网页端与 API 中提到的品牌和参考来源是否相近。
- 再看实际观测：豆包、千问分别进行三组网页端与 API 配对，共12次运行；品牌集合部分相近，来源域名重合很低。
- 指出决策风险：只看 API 的回答，不能据此认为消费者会看到相同的推荐顺序、表达或来源卡。
- 给出下一步：如果目标是消费者视角，就在获准访问的 AI 应用中保存回答和来源，再核对具体说法；API 结果仍单独保留。
本案例支持调整的是观测和核验方式，不是立即要求品牌发稿或购买外链。 要判断该改哪一页，还需要找出具体错误、核实产品事实，并确认官网是否已经表达清楚。
同厂商，不等于同一个可复现系统
API 由调用者选择模型、参数和工具；消费端网页或 App 还可能包含未公开的检索、系统指令、会话状态、账号与地区配置、安全策略和产品后处理。哪些环节真实存在，只有厂商公开说明或专门证据才能确认，不能从一次回答反推。
本页只报告 2026 年 8 月 9 日的 G0 稳定性样本。问题、语言、地区和时间窗口尽量固定，消费端与 API 原始证据分开保存、分开计算。
| 问题与范围 | DP01，1 条能量饮料品牌发现与场景选择问题 |
|---|---|
| 平台与入口 | 豆包网页端 / 火山方舟 API；千问网页端 / 百炼 API |
| 重复与总量 | 每个平台、每种模式 3 次；共 12 次运行 |
| 时间窗口 | 2026-08-09 18:30:13–18:42:58，约 13 分钟 |
| 证据口径 | 消费端 E3、模型 API E1；不合并为统一排名 |
品牌集合部分相近，来源域名差异明显
集合相似度使用 Jaccard 系数：越接近 1 表示两个集合重合越高，越接近 0 表示重合越低。
| 指标 | 豆包网页端 / 火山方舟 API | 千问网页端 / 百炼 API |
|---|---|---|
| 有效完成率 | 100% | 100% |
| 证据完整率 | 100% | 100% |
| 目标品牌提及状态一致率 | 100% | 100% |
| 品牌集合平均 Jaccard | 0.607 | 0.732 |
| 来源域名平均 Jaccard | 0.051 | 0.024 |
本轮只支持“样本内品牌集合部分或较一致、来源池差异明显”。不能把 0.607 或 0.732 写成平台总体准确性、稳定性或质量得分。
来源差异本身，就是需要保留的结果
两个入口可以提到相似的常见品牌，同时检索到不同网页、引用不同域名，或采用不同的来源卡和链接呈现方式。本轮没有取得足以确认具体内部机制的官方资料，因此检索池、工具配置、系统指令、产品后处理、会话状态和时间漂移都只能列为待验证解释。
- 豆包三组来源域名 Jaccard 为 0.047、0.029、0.077；精确 URL 重合数为 1、0、1。
- 千问三组来源域名 Jaccard 为 0.009、0.029、0.033；精确 URL 均没有重合。
- API 可以继续研究为内部预筛选工具，但不能代表消费端的来源卡、推荐顺序或用户体验。
结果一致，不等于证据已经足以交付
后续 G1-A 又完成 12 次运行。核心事实在 6 组配对中一致，并通过一手资料核对；但严格证据完整率只有 66.7%，因为 4 条消费端记录缺少完整回答与来源分段截图并被降级为 E2。
该轮状态因此是 execution_complete / quality_gate_failed。它不能用于宣称平台已完成严格验证，也不能用看起来漂亮的一致率掩盖证据缺口。
品牌团队应该怎样使用两种入口
- 把消费端网页/App 作为目标用户体验的直接观测，不用 API 数据补齐其失败。
- 把 API 用于可控参数研究、问题预筛选和差异定位，并单独显示模型与工具配置。
- 冻结同一问题、语言、地区和时间窗口，使用独立新会话重复。
- 分开报告提及、推荐位置、官网引用、事实准确性、失败率和证据完整率。
- 当结果不一致时保留差异，不挑选对品牌更有利的一边作为“真实答案”。
拿到回答后，接下来具体查什么？
下列是从本研究方法延伸的操作建议，不是本次已发现的客户官网问题，也不是已完成的优化结果。 先核实再决定是否改页；每次保留原回答、依据和修改版本。
如果两个入口答案不同：先补目标入口的证据
保存消费者实际使用的平台、问题、运行条件、完整回答和可点击来源。不要把 API 答案换进 消费端报告，也不要仅选更有利的结果。验收看证据是否完整、两种模式是否清楚分开。
如果回答把产品说错：先查事实与对应官网页面
逐条核对型号、规格、兼容条件或售后说明。若已确认事实正确、官网却缺失或表述含糊， 再由页面负责人补充对应产品页或帮助页，并附适用型号、依据和更新时间；如果官网原本正确， 则继续核查来源或实体混淆，不能先假定“改官网就能解决”。
如果只有未提及：暂不直接下发发稿任务
先区分问题是否相关、回答是否完成、来源是否可查、目标页是否已收录。确认可改进之处后， 记录页面修改前后版本，再用同一问题和可比条件复查；同时记录未改善、失败和无法判断。 收录、品牌提及与正文引用分别判断，单次出现不能证明稳定提升。
适用限制与公开数据
- 只覆盖 1 条问题、2 家厂商和约 13 分钟时间窗口。
- 消费端与模型 API 分组计算，不合并为统一排名。
- 本快照不包含完整回答、账号、请求标识、密钥或原始截图。
- 结果不能外推为平台总体准确性、稳定性或质量排名。
- G0 未完成健康、成分和驾驶建议的声明级事实复核，这些回答不进入客户正式报告。
公开 JSON 只包含脱敏聚合结果、规则版本和内部证据哈希承诺，不包含完整回答、账号、密钥、请求标识或原始截图。