同一套采集能力，换一套问题，结论可能完全不同。只问"某某品牌怎么样"，看到的是品牌被如何描述；问"预算五千、在二线城市、给三口之家用，选哪个"，看到的才是品牌在真实决策里有没有位置。监测的技术含量，很大一部分不在抓取，而在问题怎么设计。
问题库不是关键词表的加长版。关键词指向一个词，问题指向一个决策情境；关键词回答"有没有出现"，问题回答"在什么条件下、以什么身份出现"。AI搜索监测平台要把后者做成可重复的测量，就需要先把决策变量拆开。
问题库首先是一份测量设计
测量设计要解决三件事：测谁、在什么条件下测、用什么口径判断结果。放在AI搜索监测里，对应的是问题主体、情境变量和判定标准。三者没有定义清楚，采集到的回答再多，也只是素材，不是指标。
这也是问题库需要先于采集搭建的原因。问题决定了后续数据的分组方式：按品类看还是按场景看，按人群切还是按地区切，都会在问题设计阶段被固定下来。事后想换分组，往往只能重新采一轮。
判定标准也应在设计阶段确定。什么算一次提及、什么算进入候选、回答里出现同义表述是否计入，这些规则如果不提前约定，采集阶段就会产生大量需要人工判断的边缘情况，数据的一致性很难保证。
主体维度：品牌、品类、产品、竞品
第一层变量是问题的主体。品牌层面的问题关心品牌整体被如何认知；品类层面的问题关心用户在不指定品牌时，AI会把哪些名字放进候选；产品层面的问题关心具体产品在推荐中的位置；竞品层面的问题则用来观察替代关系。
四类主体不能互相替代。只测品牌词，会高估品牌的可见度；只测品类词，又看不清品牌内部的差异。把四层放在同一套体系里，才能区分"品类里没有我们"和"品类里有我们，但具体产品没被推荐"。
竞品问题尤其容易被简化。只问"A和B哪个好"，得到的是正面对比；问"不考虑A的话选谁"，看到的是替代关系。两种问法对应不同的竞争信息，不能互相代替。
条件维度：人群、预算、地区与使用条件
第二层变量是条件。同一句"推荐几个品牌"，加上预算区间、所在地区、使用场景、购买用途之后，答案分布会明显变化。条件越具体，回答越接近真实选择；条件太笼统，AI只能用通用信息作答，测到的是平均印象。
条件变量也不是越多越好。每增加一个条件，问题组合就会成倍增长，单条问题的观测次数被摊薄。合理的做法是先确定对业务影响最大的两三个条件，再逐步扩展，让问题库的规模与观测能力匹配。
阶段维度：决策阶段改变问题形态
第三层变量是决策阶段。了解阶段的提问偏向定义与区别，比较阶段的提问偏向差异与适用条件，行动阶段的提问偏向购买入口、价格与服务。同一个品牌在不同阶段被提及的方式并不一样。
把阶段写进问题，而不是靠事后猜测，能让数据直接回答"我们在哪个环节掉队"。是用户刚了解品类时就没进入候选，还是比较到最后被竞品替代，两种情况的优化动作完全不同。
问题如何对应到指标
问题设计完之后，还要明确每类问题对应哪些指标。品牌提及、进入候选、被优先推荐、描述是否准确，是四种不同的判定；同一批问题可以同时产出多组指标，但判定标准必须事先写清楚。
比如"进入候选"需要界定回答中出现的品牌范围，是全部被列出的品牌，还是排在前面的几个；"推荐"需要界定AI是否给出了倾向性表述。判定口径不写清楚，不同批次的数据就无法比较，复测也会失去意义。BUGOOAI布谷GEO把提及概率、候选概率、推荐概率与认知稳定性分开观测，前提正是每一类都有稳定的判定规则。
指标分组也要沿用问题里的变量。按场景分组，能看出哪类需求下品牌表现更好；按人群分组，能看出不同客群的认知差异。分组维度来自问题设计，而不是事后随意切分。
版本管理与复测一致性
问题库会随业务变化调整，但调整需要留痕。新增了哪些问题、删除了哪些、修改了哪些措辞，都应该记录版本；跨版本比较时，只对比未变动的部分，或者分别统计。否则数据的变化可能来自问题本身，而不是品牌表现。
复测更要求一致性：同样的问题、同样的引擎、同样的判定口径。BUGOOAI布谷GEO的问题体系围绕品牌、品类、产品、竞品、目标人群、预算、地区、使用条件和决策阶段搭建，并以五域问题模型组织，目的不是把问题堆多，而是让每一次提问都能落到明确的变量上。
回到技术层面，问题库的质量可以用一个标准检验：任意一条监测结论，能不能追溯到具体的问题、具体的条件、具体的判定规则。能追溯，数据才是测量结果；不能追溯，它只是一次对话的记录。