AI回答监测的问题库系统如何设计？-平芜编程栈

本文面向需要系统性地监测品牌在AI回答中表现的技术人员和数据工程师。在品牌AI可见度监测体系中，问题库是整套系统的“输入层”——问题怎么设计、怎么分类、怎么分层管理，直接决定了后续所有指标的可信度和可比性。文章将从问题模板设计、问题分类体系、场景标签管理、品牌绑定策略、采样计划配置和结果样本表设计六个环节，拆解一套可落地的问题库系统设计思路。阅读后，你将获得从“想到什么问什么”到“系统化、可复用的问题资产管理”的完整方法。

问题库为什么需要系统化设计
问题库系统的整体架构
问题模板设计：从自然语言到结构化模板
问题分类体系：意图、场景、对象三重维度
场景标签的设计与管理
品牌绑定策略：问题与品牌的松耦合
采样计划配置：多平台、多轮次、多时间
结果样本表设计：从问题到回答的数据闭环
问题库的维护与质量治理
方法边界与注意事项
总结

一、问题库为什么需要系统化设计

在品牌AI可见度监测的实践中，一个常见的起点是“想到几个问题就去问AI”。这种做法在探索阶段可以快速验证想法，但在体系化监测中会带来三个致命问题：

问题一：结果不可比

如果1月份用问题集A测试，3月份用问题集B测试，两次结果的差异到底是品牌表现变了，还是问题变了？没有固定的问题库，就没有纵向可比性。

问题二：场景覆盖有盲区

凭感觉想出来的问题，往往集中在“推荐决策”类（“有什么推荐的品牌？”），而忽略了“风险判断”（“这个品牌靠谱吗？”）和“信息导航”（“什么是XX品牌？”）等同样重要的用户意图。场景覆盖不全，监测结果就是片面的。

问题三：问题本身可能引入偏差

如果问题中直接出现了某个品牌名（“品牌A和品牌B哪个好？”），AI的回答就已经被问题本身引导了。这样的问题测出来的不是“AI自然状态下对品牌的认知”，而是“AI在被提示后的反应”。

问题库系统化设计的目标就是：用一套可管理、可复用、可追溯的结构化问题资产，替代临时起意的提问，确保监测结果的可靠性。

二、问题库系统的整体架构

问题库系统 ├── 问题模板管理 │ ├── 模板ID、模板文本（含占位符） │ ├── 占位符说明（场景变量、对象变量等） │ └── 模板来源与审核状态 ├── 问题分类体系 │ ├── 用户意图分类（推荐决策/对比分析/信息导航/风险判断...） │ ├── 消费场景分类（毕业旅行/日常通勤/节日送礼...） │ ├── 行业品类分类（运动鞋/智能穿戴/餐饮...） │ └── 对象类型分类（品牌/产品/服务/机构） ├── 场景标签库 │ ├── 场景标签ID、名称、关键词 │ ├── 标签层级（主场景→子场景） │ └── 适用品类关联 ├── 问题实例管理 │ ├── 问题ID、问题文本（占位符已填充） │ ├── 关联的分类标签 │ ├── 适用品牌范围（可为空=不限品牌） │ └── 状态（草稿/已审核/已归档） ├── 采样计划配置 │ ├── 计划ID、关联问题列表 │ ├── 平台配置、轮次配置 │ └── 执行时间窗口 └── 结果样本表 ├── 样本ID、关联问题ID、平台 ├── 原始回答、提取结果 └── 采样时间、有效性标记

三、问题模板设计：从自然语言到结构化模板

3.1 为什么需要模板

先看两个“问题”：

“毕业旅行穿什么运动鞋好？”
“端午节送长辈什么粽子礼盒合适？”

它们看起来是两个完全不同的问法，但结构是完全一样的：[消费场景] + [需求描述] + [品类词] + [推荐意图]。

如果不把这种结构抽象出来，每增加一个新品类就要从零开始想问题，问题库会迅速变成一堆无法管理的散乱文本。

3.2 问题模板的结构

# 问题模板记录结构question_template={"template_id":"TPL_RECOMMEND_001","template_name":"场景推荐-基础版","template_text":"【{scene}】{scene_desc}，有什么{category}推荐？","placeholders":{"scene":{"description":"消费场景名称","example":"毕业旅行","source":"场景标签库"},"scene_desc":{"description":"场景补充描述，增加真实感","example":"每天走很多路、预算有限","source":"场景标签库中的子场景描述"},"category":{"description":"消费品类","example":"运动鞋","source":"品类列表"}},"applicable_intents":["推荐决策","场景发现"],"template_source":"人工设计","review_status":"已审核","created_at":"2026-07-01","version":"1.0"}

3.3 常见问题模板类型

模板类型	模板文本示例	适用意图
场景推荐	“{scene}{scene_desc}，有什么{category}推荐？”	推荐决策
预算限定	“学生党{scene}，预算{budget}以内，买什么{category}划算？”	购买意图
对比分析	“{brand_a}和{brand_b}，{scene}场景下选哪个好？”	对比分析
风险判断	“最近听说{category}行业有些品牌品控不稳定，{scene}选什么比较靠谱？”	风险判断
信息导航	“什么是{category}？有哪些主流品牌值得关注？”	信息导航
场景发现	“{scene}需要准备什么{category}？有没有专门做这个的品牌？”	场景发现

3.4 模板实例化：从模板到可执行问题

definstantiate_question(template,placeholder_values):""" 将模板实例化为具体问题 参数: template: 问题模板 placeholder_values: 占位符填充值 {"scene": "毕业旅行", ...} 返回: 实例化后的问题文本和元信息 """question_text=template["template_text"]forkey,valueinplaceholder_values.items():placeholder="{"+key+"}"question_text=question_text.replace(placeholder,str(value))return{"question_id":generate_question_id(template["template_id"]),"template_id":template["template_id"],"question_text":question_text,"placeholder_values":placeholder_values,"intent_type":placeholder_values.get("intent_type",template["applicable_intents"][0]),"scene":placeholder_values.get("scene"),"category":placeholder_values.get("category"),"created_at":datetime.now().isoformat()}# 使用示例template=get_template("TPL_RECOMMEND_001")question=instantiate_question(template,{"scene":"毕业旅行","scene_desc":"每天走两万步","category":"运动鞋"})# 结果: "毕业旅行每天走两万步，有什么运动鞋推荐？"

四、问题分类体系：意图、场景、对象三重维度

4.1 为什么要多维分类

一道问题“毕业旅行穿什么运动鞋？”可以从三个维度同时分类：

意图维度：推荐决策（用户希望获得具体品牌/产品推荐）
场景维度：毕业旅行（特定的人生阶段和出行场景）
对象维度：运动鞋（品类）+ 品牌（监测对象）

单维分类会导致“只能在某一个维度上筛选”。多维分类允许在不同分析场景下灵活组合，例如：

只看“推荐决策”意图下所有品类、所有场景的表现
只看“毕业旅行”场景下所有意图、所有品类的表现
只看“运动鞋”品类下所有意图、所有场景的表现

4.2 三维分类的标签结构

# 问题分类标签结构question_classification={"question_id":"Q20260707_001","classifications":{# 维度一：用户意图"intent":{"primary":"推荐决策","secondary":None,# 可选，更细粒度的意图"intent_code":"INT_RECOMMEND_01"},# 维度二：消费场景"scene":{"primary":"毕业旅行","secondary":"长途步行",# 子场景"scene_code":"SCENE_GRADUATION_TRIP"},# 维度三：对象"target":{"category":"运动鞋",# 品类"category_code":"CAT_SPORTS_SHOES","object_type":"品牌",# 品牌/产品/服务/机构"related_brands":[],# 问题中不应包含品牌名，此字段留空表示不绑定品牌"brand_binding":"none"# none/primary_only/competitor_set}}}

4.3 分类体系的管理

建议用枚举表管理所有分类值，而不是在每条问题中自由填写文本：

# 用户意图枚举表intent_catalog={"INT_RECOMMEND_01":{"name":"推荐决策","description":"用户希望AI推荐品牌或产品"},"INT_COMPARE_01":{"name":"对比分析","description":"用户希望AI比较多个选项的差异"},"INT_PURCHASE_01":{"name":"购买意图","description":"用户接近购买阶段，带有预算或明确需求"},"INT_DISCOVERY_01":{"name":"场景发现","description":"用户从场景出发寻找解决方案"},"INT_INFO_01":{"name":"信息导航","description":"用户希望了解概念或行业概况"},"INT_RISK_01":{"name":"风险判断","description":"用户带有疑虑，希望AI给出风险提示"}}# 消费场景枚举表（以运动鞋行业为例）scene_catalog={"SCENE_GRADUATION_TRIP":{"name":"毕业旅行","category":"运动鞋"},"SCENE_DAILY_COMMUTE":{"name":"日常通勤","category":"运动鞋"},"SCENE_OUTDOOR_SPORTS":{"name":"户外运动","category":"运动鞋"},"SCENE_GYM_WORKOUT":{"name":"健身房训练","category":"运动鞋"},}

五、场景标签的设计与管理

5.1 场景标签的两层结构

场景标签建议设计为主场景+子场景两层：

主场景：用户面临的生活/工作情境（毕业旅行、日常通勤、节日送礼）
子场景：该情境下的具体约束或需求（预算有限、透气需求、送礼对象是长辈）

5.2 场景标签库设计

scene_tag_library={"tags":[{"tag_id":"SCENE_GRADUATION_TRIP","tag_name":"毕业旅行","tag_type":"主场景","keywords":["毕业","旅行","旅游","毕业季","出行"],"applicable_categories":["运动鞋","行李箱","防晒霜"],"sub_scenes":[{"sub_tag_id":"SUB_LONG_WALK","sub_tag_name":"长途步行","keywords":["走很多路","暴走","日行两万步","不累脚","持久舒适"],},{"sub_tag_id":"SUB_BUDGET_LIMITED","sub_tag_name":"预算有限","keywords":["学生党","预算","500以内","性价比","划算","不贵"],},{"sub_tag_id":"SUB_HOT_WEATHER","sub_tag_name":"炎热天气","keywords":["夏天","透气","闷热","凉爽","网面"],}]}]}

5.3 场景标签在问题实例化中的应用

当从模板生成具体问题时，场景标签用于填充模板占位符并自动标记问题的场景分类：

defapply_scene_tags(question,scene_tag):"""为问题实例自动关联场景标签"""question["scene_tags"]={"primary":scene_tag["tag_name"],"primary_id":scene_tag["tag_id"],"sub_tags":[]}# 根据问题文本中的关键词，自动匹配子场景标签forsubinscene_tag.get("sub_scenes",[]):forkwinsub["keywords"]:ifkwinquestion["question_text"]:question["scene_tags"]["sub_tags"].append({"sub_tag_id":sub["sub_tag_id"],"sub_tag_name":sub["sub_tag_name"],"matched_keyword":kw})breakreturnquestion

六、品牌绑定策略：问题与品牌的松耦合

6.1 核心原则：问题中不应包含品牌名

问题库的设计有一个铁律：用于监测品牌AI可见度的问题，文本中不能出现任何品牌名。

理由很简单：如果问题已经提到了“品牌A”，AI的回答中出现了“品牌A”就不能算作“AI主动提及”——那是被问题引导出来的。

6.2 品牌绑定的两种模式

问题本身不包含品牌名，但分析时需要知道“这条问题的结果应该用来评估哪个品牌的表现”。这就产生了“品牌绑定”的概念：

模式一：无品牌绑定

问题完全开放，AI回答中出现的所有品牌都被记录和分析。适用于行业榜单类监测（“这个品类里哪些品牌被AI推荐最多？”）。

模式二：品类级绑定

问题绑定到一个品类，该品类下的目标品牌在分析时被重点关注。问题本身仍不包含品牌名。

# 品牌绑定配置brand_binding_config={"question_id":"Q20260707_001","binding_mode":"category_level",# none / category_level"category":"运动鞋","target_brands":["品牌A","品牌B","品牌C"],# 本次监测关注的目标品牌"competitor_brands":["品牌D","品牌E"],# 竞品品牌（用于对比分析）"brand_inclusion_rule":"问题文本中不包含任何品牌名，AI自由选择提及对象"}

七、采样计划配置：多平台、多轮次、多时间

7.1 采样计划的结构

有了问题库之后，需要配置“什么时候、在哪些平台、用哪些问题、采多少轮”。这就是采样计划：

sampling_plan={"plan_id":"SP20260707_001","plan_name":"运动鞋品牌-2026年7月常规监测","question_selection":{"mode":"by_filter",# by_filter / by_id_list"filters":{"category":"运动鞋","intents":["推荐决策","对比分析","预算限定","风险判断"],"scenes":["毕业旅行","日常通勤","户外运动"],"status":"已审核"},"question_count":20# 筛选后的问题数量},"platform_config":{"platforms":["平台A","平台B","平台C"],"per_platform_rounds":3,# 每个平台每个问题的采样轮次"round_interval_hours":2# 轮次之间的最小间隔},"schedule":{"start_time":"2026-07-08 09:00:00","end_time":"2026-07-10 18:00:00","time_zone":"Asia/Shanghai"},"estimated_total_samples":180,# 20问题 × 3平台 × 3轮次"status":"待执行"}

7.2 采样计划的样本量估算

defestimate_sample_size(plan):""" 估算采样计划的总样本量 """question_count=plan["question_selection"]["question_count"]platform_count=len(plan["platform_config"]["platforms"])rounds_per_platform=plan["platform_config"]["per_platform_rounds"]total=question_count*platform_count*rounds_per_platform# 预留10%的无效样本余量estimated_invalid=total*0.1return{"total_planned":total,"estimated_valid":total-estimated_invalid,"estimated_invalid":estimated_invalid,"breakdown":f"{question_count}问题 ×{platform_count}平台 ×{rounds_per_platform}轮次"}

八、结果样本表设计：从问题到回答的数据闭环

8.1 结果样本表的核心字段

当采样计划执行后，每条AI回答都需要记录在结果样本表中，形成“问题→回答”的完整链路：

-- 结果样本表结构（简化版）CREATETABLEai_response_samples(-- 主键与关联sample_idVARCHAR(64)PRIMARYKEY,plan_idVARCHAR(32)NOTNULL,-- 关联采样计划question_idVARCHAR(32)NOTNULL,-- 关联问题-- 问题快照（采样时的问题状态，防止问题后续被修改导致历史数据不可追溯）question_text_snapshotTEXTNOTNULL,-- 采样时的实际问题文本scene_tag_snapshotVARCHAR(128),-- 采样时的场景标签intent_type_snapshotVARCHAR(32),-- 采样时的意图分类-- 平台与时间platformVARCHAR(32)NOTNULL,request_timeDATETIMENOTNULL,response_timeDATETIME,-- 回答内容raw_responseTEXT,-- 原始回答response_text_cleanTEXT,-- 归一化后的纯文本response_lengthINT,-- 有效性标记is_validBOOLEANDEFAULTTRUE,invalid_reasonVARCHAR(64),-- 品牌识别结果（JSON字段，方便扩展）brands_identified JSON,-- ["品牌A", "品牌B"]brand_details JSON,-- {品牌A: {mentioned: true, recommended: true, ...}}-- 元信息created_atDATETIMEDEFAULTCURRENT_TIMESTAMP,processed_atDATETIME-- 品牌识别处理完成时间);

8.2 问题快照的必要性

问题库中的问题可能会被修改（优化措辞、调整分类标签等），但历史采样数据必须保留“当时问了什么问题”。因此，结果样本表中存储的是问题的快照，而非外键关联到问题表的当前版本。

defcreate_sample_with_snapshot(question,platform,raw_response):"""创建采样记录时，同时保存问题快照"""return{"question_id":question["question_id"],"question_text_snapshot":question["question_text"],# 快照，不随问题更新而改变"scene_tag_snapshot":json.dumps(question.get("scene_tags",{})),"intent_type_snapshot":question.get("intent_type"),"platform":platform,"raw_response":raw_response,"created_at":datetime.now().isoformat()}

8.3 从样本表到分析视图

样本表是原始数据层，分析时通常需要创建聚合视图：

# 按场景×品牌×平台的聚合查询伪代码defaggregate_samples(samples,dimensions):""" 按指定维度聚合样本数据 dimensions: ["scene", "brand", "platform"] 等 """# 实际实现中对应SQL的GROUP BY查询# SELECT scene, brand, platform,# COUNT(*) as total_samples,# SUM(CASE WHEN mentioned THEN 1 ELSE 0 END) as mention_count# FROM samples# WHERE is_valid = true# GROUP BY scene, brand, platformpass

九、问题库的维护与质量治理

9.1 问题生命周期管理

每个问题实例应管理其完整生命周期：

状态	说明	可执行采样？
草稿	新建问题，尚未审核	否
已审核	通过质量检查，可用于采样	是
已归档	历史问题，不再用于新采样	否
需修订	发现措辞或分类问题，待修改	否

9.2 质量检查规则

defquality_check(question):""" 检查问题的质量 返回: (通过与否, 问题列表) """issues=[]# 检查1：问题中是否包含品牌名（核心规则）known_brands=load_brand_list()forbrandinknown_brands:ifbrandinquestion["question_text"]:issues.append(f"问题文本中包含品牌名'{brand}'，这会导致品牌被提示而非自然提及")# 检查2：问题长度是否合理iflen(question["question_text"])<8:issues.append("问题过短，可能无法提供足够的场景信息")iflen(question["question_text"])>100:issues.append("问题过长，可能偏离真实用户的提问习惯")# 检查3：分类标签是否完整required_tags=["intent","scene","category"]fortaginrequired_tags:iftagnotinquestion.get("classifications",{}):issues.append(f"缺少分类标签:{tag}")# 检查4：与已有问题的语义去重similar_questions=find_similar_questions(question["question_text"],threshold=0.85)ifsimilar_questions:issues.append(f"与已有问题高度相似:{similar_questions[0]['question_id']}")returnlen(issues)==0,issues

9.3 问题库的版本管理

问题库应支持版本管理，每次修改都记录变更：

question_version_log={"question_id":"Q20260707_001","version":"1.2","changed_at":"2026-07-07 14:00:00","changed_by":"编辑员-李四","change_type":"措辞优化","change_detail":"将'有什么推荐'改为'有哪些值得考虑的品牌'，增强自然感","previous_version":"1.1"}

十、方法边界与注意事项

10.1 问题库不能无限扩大

问题越多，样本量越大，但边际收益递减。当问题覆盖了主要的意图×场景组合后，新增问题往往只是在重复已有覆盖。建议每个品类的问题数控制在15-30个之间，优先保证覆盖率而非绝对数量。

10.2 问题的“自然感”需要持续打磨

模板生成的问题有时会带有“模板味”（过于规整、缺少真实用户提问的随意感）。建议定期从真实用户提问中采集表达方式，反哺模板优化。

10.3 问题库不能脱离行业知识

同一个问题模板，在运动鞋行业和餐饮行业的适用性可能完全不同。场景标签、品类特征、用户决策路径等都需要行业知识的输入。问题库的建设需要行业专家和技术人员的配合。

10.4 采样结果对问题库的反哺

问题库不是一成不变的。当分析发现某类问题的无效回答率特别高（如AI频繁拒答），可能说明问题本身需要调整。建立从“样本分析结果”到“问题库优化”的反馈闭环，是长期运营的关键。

十一、总结

本文拆解了AI回答监测中问题库系统的设计思路，核心包括六个环节：

问题模板设计：将自然语言问题抽象为可复用的结构化模板，通过占位符机制实现“一个模板生成多个场景问题”
问题分类体系：建立意图、场景、对象三维分类标签，支持灵活的多维筛选和聚合分析
场景标签管理：设计主场景+子场景两层标签库，在问题实例化时自动关联场景分类
品牌绑定策略：问题文本中不包含任何品牌名，通过品类级绑定实现“品牌不提示”的客观监测
采样计划配置：将问题库、平台、轮次、时间窗口组合成可执行、可复现的采样计划
结果样本表设计：用问题快照保证历史数据的可追溯性，形成从问题到回答的完整数据闭环

问题库是整个品牌AI可见度监测系统的“地基”。问题的质量、覆盖度和结构化程度，直接决定了后续所有指标、诊断、对比的可信度。投入足够的精力在问题库建设上，是整个系统长期可靠运行的保障。

目录