先问对问题：怎样设计能覆盖真实买家需求的 GEO 测试集

GEO 测试最容易在发出请求以前就失真：题目先介绍产品的独特卖点，再问谁最合适，结果自然围绕这段介绍展开。更可靠的问题集从买家的任务出发，保留必要限制，分清是否点名品牌，并记录每道题为什么入选。问题质量不取决于数量，而取决于它能否检验一个真实决策。

1. 从买家说过的话提取需求

可以从经过授权的售前咨询、产品演示反馈、帮助中心搜索和采用障碍中收集问题。收集时先去掉个人信息，保留原本的角色、任务、限制和犹豫点。例如“我们已有三套内部系统，离职人员的访问如何统一撤销”，比“权限管理最佳软件”提供了更具体的决策背景。

不要把客户每句话原封不动发给外部模型。内部系统名称、个人资料和未公开预算未必是必要条件，可以改为功能等价的公开表达，同时记录改写原因。也不要只采用销售希望客户提的问题；真实需求常常包括实施成本、现有方案能否继续用、产品不适合谁，这些题目对判断商业价值尤其重要。

2. 四种问题应单独标记

认知题直接点名公司、域名或产品，用于检查身份、功能和版本描述。发现题不提供品牌，观察解决某个任务时出现哪些方案。比较题给出已知候选，检查比较维度和事实。采用确认题询问迁移、集成或验证方法，回答可能完全不需要出现任何品牌。

这四类题的合格答案不同。“部署前应该如何核查权限继承”即使没有推荐产品，也可能非常有用。不能把所有方法题的无品牌回答算作营销失败；同样，比较题中复述了两个候选也不能算自然发现。报告应在题目旁保留类型，让读者先理解分母，再看提及或推荐次数。

3. 约束要必要，不要变成产品暗号

预算、部署、地区、规模和角色都能提高题目相关性，但组合过于独特时，可能间接指向唯一品牌。审核者可以问：这是买家真正无法放宽的条件，还是我们产品刚好拥有的功能？如果删去一个条件不会改变采购决定，却显著降低题目对目标的提示，应考虑移除或作为探索版本保留。

例如模拟的“跨三个系统撤销离职权限”可以合理加入“已有身份服务、不准备整体替换”的约束；加入某个厂商自创的模块名称就会污染中性测试。专业类别词并非一律禁止，但要承认样本是特定类别的意向用户，不能把结果推广为所有搜索市场的发现概率。

4. 一句话背后可能有多个子需求

Google 公开说明提到，其部分 AI 搜索体验可能围绕子主题发出多次相关搜索。这不意味着每个测试请求都能看见这些查询，也不意味着其他平台使用完全相同的路径。对于选题者，可借鉴的是把角色、比较条件和验证需求分别列清，而不是猜测隐藏搜索日志。

把“适合我们团队的权限工具”拆成身份接入、授权策略、撤销时效、审计证据和迁移安排，有助于发现现有问题集只覆盖了哪一部分。一个问题不必包含所有条件；当两个限制对应不同购买任务时，可以拆为两题。拆题后仍需避免把仅有措辞差异的版本误认为多个独立需求。

5. 模拟三问如何各司其职

以下方案完全是教学设计，没有调用模型。对象是一家虚构的身份协作产品，目标用户为保留现有身份系统的内部 IT 团队。问题一：“已有多套业务系统的团队，应该比较哪些统一管理权限的方案？”它观察类别与候选。问题二：“员工离职后，怎样验证各系统的访问已经撤销？”它观察证据要求。问题三：“采用权限平台前，需要核查哪些集成和回退条件？”它观察实施判断。

三题不要求都推荐产品。如果需要检查品牌事实，另加一个点名题，并标为认知样本。若目标客户其实是外部开发者而非内部 IT，上述题目就需要重新立项，而不是换几个名词继续计算同一趋势。题目与受众的匹配比总样本数更基础。

6. NiubiGEO 的不同协议怎样选择

域名认知协议传入规范化域名，适合观察点名后的解释；关键词发现协议围绕冻结关键词请求选型信息，不把监测对象名单提供给回答模型。两者的公开说明可见 NiubiGEO 工作原理。直接提问入口保存完整原题，更适合上述含任务和限制的自然语言问题。这些路径不能互相冒充，也不能把域名检测次数当作中性发现次数。

系统对中性关键词有名称、别名和域名的排除规则，但这不是通用的语义泄露检测。人工仍应检查缩写、旧名、独特口号和过度特定的功能组合。模型建议的关联词也只是候选，不能因为它会提高目标出现次数就自动纳入。应保留来源、入选理由和不采用的原因。

7. 给每道题一个可追溯身份

题目记录至少包含编号、原文、语言、类型、目标角色、必要限制、来源类别、选入理由和版本。出站请求应与已确认版本一致；人工执行时复制原文，不能为了“让 AI 更懂”临场补充产品介绍。确实需要澄清时，保存新增轮次，并单独标注它与首轮的差别。

一个简单的变更例子是：Q02 的第一版只问“撤销权限”，第二版加上“离职当天”。这个约束可能改变候选和验证方式，因而不能覆盖旧题而继续显示一条连续趋势。可以保留旧版作基线，把新版作为新的场景系列。只换标点与改变任务边界也应分别记载，不用一个模糊的“已优化提示词”掩盖全部变化。

8. 扩展测试靠新增决策，不靠同义改写

初始三问适合沟通范围，却不是市场代表性样本。扩展时可检查缺失角色、地区、采用阶段和风险条件。若增加的是同一题的多次采样，它提供波动信息；若增加另一种措辞，它提供表达敏感性；若增加新的业务任务，才扩展需求覆盖。三种工作必须分别计数。

可建立一个小矩阵，把候选题放进角色与决策阶段交叉格，再挑出空缺。某个格子没有可靠问题来源，可以暂留空白。不要为了矩阵好看凭空制造需求，也不要复制几十条低价值变体占满所有位置。覆盖解释应呈现我们知道测试了什么，以及哪些用户仍未被覆盖。

9. 运行失败与不利答案也属于设计

运行前约定模型范围、联网模式、重复次数、失败分类与恢复规则。超时、服务商拒绝、输出截断和完整但未提及目标，是不同情况。恢复请求若改写了原题，必须形成新版本；若使用完全相同的请求重试，也要留下原尝试和时间，不只保留较好的一次回答。

验收时检查计划题目是否全部有终态、每次回答是否对应正确版本、哪些样本被排除以及原因。题目设计者不应在看到结果后随意把难题降级成“不重要”，或者把有利题突然升级为核心指标。确有业务变化时可以调整，但说明变化发生在观察前还是观察后。

10. 可交付的问题设计表怎么验收

最终交付不是一列句子，而是逐题解释：哪类买家在何时会问、答案需要支持什么决定、品牌是否已提供、哪些事实不能放进请求、结果如何分类。由一位熟悉产品的人和一位没有参与命题的人分别复核，前者确认业务真实性，后者检查问题是否暗示答案。意见不一致时保留分歧，修改后重新确认版本。

可填写的一行示例为：“编号 Q02；角色为内部 IT；阶段为采用前验证；来源为已去身份的售前障碍；必要约束为现有身份系统；禁止内容为产品名和宣传介绍；合格答案需解释撤销范围与证据；未点名不直接判失败。”这不是预置正确答案，而是预先定义阅读结果的规则。记录中还应留下确认日期和审核角色，使另一位执行者不依赖口头背景也能复现命题意图。

将通过审核的问题与 可追溯报告的证据结构连接，才有可持续的测量基础。NiubiGEO 可协助组织采集与人工复核，具体次数和界面范围另行确认。开始的最好材料是目标受众及三个实际问题，而不是一串希望排名第一的关键词。