表格较宽时，可以用键盘方向键或触控手势横向滚动查看完整内容。
直接答案
建立固定问题集，在相同条件下定期测试豆包、DeepSeek、Kimi、通义、元宝等平台，保存日期、模型或模式、完整回答、引用 URL、事实错误和人工评分。
一次提问或一张品牌截图不能代表稳定可见性。生成式回答存在波动，必须保留可复查上下文。
问题集怎样设计
至少包含四类：
- 实体问题：公司全称、品牌、官网和所在地；
- 服务问题：企业做什么、适合什么客户；
- 场景问题：在具体地区或行业中寻找解决方案；
- 对比与验证：案例、资质、联系方式和信息来源。
不要全部使用带明显引导的品牌问题。加入真实客户会问的非品牌问题，才能观察是否在相关场景中被识别。
每次记录哪些字段
| 字段 | 说明 |
|---|---|
| 平台与模式 | 普通对话、联网搜索或其他模式 |
| 日期与账号状态 | 登录与否、测试时间 |
| 完整问题 | 保留原始标点和限制条件 |
| 回答与引用 | 保存全文和实际 URL |
| 品牌状态 | 未提及、提及、推荐或混淆 |
| 事实准确性 | 主体、服务、地域、联系方式是否正确 |
| 证据质量 | 是否有可访问、相关、真实来源 |
怎样评分
将“有没有出现”与“是否正确”分开。可以按实体识别、服务准确、来源质量、边界表达和事实错误分别评分。错误推荐通常比没有出现更值得优先修复。
测试频率
基础修复前做一次基线；重要页面发布或外部信息修正后等待合理抓取周期再复测；日常按月或季度记录。频繁重复提问会增加噪声，不代表平台已稳定更新。
怎样解释变化
同一问题偶尔出现或消失，可能来自模型版本、检索结果和生成随机性。只有多个周期、多个相关问题都出现一致变化，才适合形成趋势判断。所有结论都注明测试范围，不外推到全部用户。
测试前可先统一企业实体事实链，并参考AHAX 公开 GEO 基线了解怎样区分已验证事实和暂不能证明的结果。
把问题放进真实业务里
以下情境用于决策演练，不是虚构客户成果：建立固定问题集，分别覆盖公司识别、服务能力、地区和对比场景。在豆包、DeepSeek 等模型的新会话中使用同样措辞，记录日期、模型、答案、引用链接和事实错误；不要只截取最满意的一次。
开会时不要只谈观点
把下面五项填完，再决定采购、开发或优化动作：
- 固定问题和意图：__________
- 模型与访问方式：__________
- 是否开启联网：__________
- 提及与引用来源：__________
- 事实错误和波动：__________
最容易踩的坑
用品牌全称提问后宣称可见。真实用户往往问“成都哪家公司能做某类项目”，需要同时测试无品牌和有品牌问题。
什么时候才适合进入下一步
至少完成两轮间隔复测，原始答案与引用可追溯，能区分未提及、提及错误、无引用提及和有依据引用。
如果这些信息还无法写清，合理动作不是马上采购工具或签开发合同，而是先补一轮访谈、样本和责任确认。这样做看起来慢半步，通常能减少后面的返工，也让供应商给出的范围、报价和验收更可比较。
复盘时再追问一层
不要在会议结束时只留下“原则同意”。请指定一名负责人，用最近发生的一笔业务验证“固定问题和意图”和“模型与访问方式”是否有记录，再让另一名实际执行者检查“是否开启联网”是否符合现场情况。最后，把“提及与引用来源”与“事实错误和波动”写成可以在下一次评审中核对的证据，而不是写成“后续优化”。如果两个人对同一项的答案不同，应先解决定义和责任分歧；这类分歧进入系统后，只会变成更难修改的权限、数据或流程问题。