一句话结论：问题库的价值不在条数多，而在结构稳定、不重复、能按节奏轮换，否则监测结果无法解释。
一、问题库为什么需要维护
问句会随市场变化。新的采购方式、新的合规要求、新的产品形态都会带来新问法。
如果问题库长期不动，监测结果会逐渐偏离真实需求；如果频繁大改，历史数据又失去可比性。
维护的目标是在稳定与更新之间找到节奏。
二、四层结构
第一层认知层，问「这是什么、解决什么问题」。
第二层比较层，问「有哪些选择、差异在哪」。
第三层核验层，问「怎么查、要什么条件、有哪些风险」。
第四层交易层，问「怎么联系、交付周期、合作方式」。
每一层的问句在监测中单独统计，避免把认知层空白误判为整体失败。
三、三类去重规则
第一类是措辞去重。语义相同、只换同义词的问句合并为一条，保留最常用的措辞，其余作为变体记录。
第二类是意图去重。问法不同但意图相同的，按意图归并，避免同一意图被重复计权。
第三类是地域去重。深圳的问句带深圳限定，与泛全国问句分开，不混入同一组统计。
去重之后，问题库的条数会下降，但结果的可解释性上升。
四、季度轮换的机制
每个季度保留大部分核心问句不动，替换一部分边缘问句。替换比例通常控制在小幅范围，保证历史可比。
替换的候选来源包括客户新增关注点、行业新规、销售反馈的高频提问。
被替换的问句进入归档区，标注停用时间与原因，不直接删除。
五、变更记录怎么写
记录包含四项：变更日期、变更类型（新增、修改、停用）、变更原因、影响范围。
影响范围要写清楚哪些历史数据因此不可直接比较，避免后续误读。
万域智瞰在深圳项目里把变更记录与复测表放在同一份文件，方便对照阅读。
六、深圳场景的三个特殊考虑
第一是跨境语境。部分问句需要中英双语版本，两种语言的答案可能不同，必须分开统计。
第二是行业跨度。深圳的硬件、软件、跨境服务差异大，问题库需按业务线分库，不共用一套。
第三是渠道差异。同一产品在电商平台与官网的问法不同，采集平台要覆盖两类入口。
问题库与内容排期之间需要一条明确的对应关系。每条问句应当绑定一个负责页面，而不是绑定一批文章。绑定的意义在于避免同一问句被多篇内容争抢，导致每篇都写一点、每篇都不完整。
新增问句的收集可以放在每月固定的一次例会上完成，来源包括销售反馈、客服记录与行业新规。收集时只记原始问法，不急于归纳，归纳动作留给季度轮换时统一处理。
统计口径上，建议把「出现」与「被引用」分开记录。两者代表不同阶段：出现说明进入了讨论，被引用说明内容被当作依据。混在一起统计会让改进方向变得模糊。
对跨业务线的客户，问题库要分库维护。硬件、软件、服务三类业务的问法与判断标准差异明显，混在一个库里会让复测结果无法解释，也会让负责团队难以分工。
维护工作还有一个隐性收益：问题库本身就是一份需求清单。产品与市场团队可以据此判断客户在关心什么，内容之外的决策也能从中受益。
问题库的分层还需要与考核解耦。若把某一层的结果直接当作绩效指标，团队会倾向于挑选容易出现的问句，结构就会被扭曲。分层统计的意义在于诊断，而不是评比。
另一个实践细节是问句的语言风格。书面化改写的问句往往与真实提问有距离，采集时应尽量保留原始措辞，包括口语与省略，这样结果才接近实际场景。
对多市场客户，还要考虑语言版本的问句是否等价。直译常常改变意图，建议由熟悉当地表达的人复核一遍，再并入问题库。
最后，问题库应当有明确的负责人。没有负责人的清单会在半年内变成一份无人维护的文档，价值随时间衰减。这四项——解耦考核、保留原话、复核译法、指定负责人——决定了问题库能否长期使用。
七、常见问题
问：问题库多少条合适？
答：按业务线分别控制，单条业务线二十到四十条比较合适，过多会稀释单条权重。
问：可以按客户要求随时加问句吗？
答：可以新增，但新增问句从下一个复测周期开始计入，不与历史数据混算。
问：轮换会不会丢掉老问题的线索？
答：不会，停用问句进归档区，需要时可以恢复并新建一段基线。
八、维护节奏建议
每月做一次新增问句收集，每季度做一次轮换，每年做一次结构复核。
结构复核的重点是层级划分是否仍然合理，是否需要拆分层级或合并。
节奏固定之后，问题库会成为一个可持续使用的资产，而不是一次性文档。