为什么我把问题库放在产品的起点
如果要演示一款 GEO 产品，最容易让人立刻感受到价值的，往往是文章生成。
输入品牌资料，选择一个主题，等一会儿，一篇结构完整的文章就出来了。它很直观，也很像一个已经完成的结果。
问题是：这篇文章为什么要写？
它在回答谁的问题？这个问题离用户的真实选择有多远？AI 现在怎样回答？品牌缺席在哪里？文章发布之后，又应该回到什么地方验证？
如果这些问题没有答案，内容生成得再快，也可能只是更快地增加内容库存。
我一开始也被“先把文章做出来”吸引过。做得越往后，我越确定，文章不应该是 GEO 工作流的起点。真正能把品牌、监测、内容和结果连接起来的，不是文章，也不只是关键词，而是用户会提出的具体问题。
这也是为什么，我后来把问题库放在了豆见 BeanInsight 的产品起点。
01 关键词能告诉我方向，却不能替用户把问题问完
“GEO”“AI 搜索”“品牌增长”，都可以是关键词。
它们能帮助团队确定一个大致范围，却没有交代用户此刻想完成什么任务。
同样围绕“GEO 服务”，用户可能在问：GEO 是什么？它和 SEO 有什么区别？制造企业适不适合做？不同方案应该怎样比较？选择服务商之前要看什么？某个品牌支持哪些 AI 平台？
这些问题共享一部分关键词，背后的意图却完全不同。
有人只是建立认知，有人在比较路径，有人已经接近选择，还有人在核对一个具体事实。如果把它们都压缩成“GEO”这个词，内容团队看到了主题，却看不到用户要解决的事情；监测团队知道要观察一个领域，却不知道什么结果才算有意义。
所以我后来不再把问题看成关键词的长尾版本。
关键词更像一块路牌，告诉我大致往哪里走；问题则带着对象、场景和任务，告诉我这一次为什么出发。
这个区别也改变了内容生产的顺序。过去常见的动作是先定关键词，再围绕关键词铺很多文章。现在我更愿意先把关键词展开成用户问题，再判断其中哪些值得回答、哪些值得监测、哪些已经有证据支撑，最后才决定要不要写内容。
内容不再只是“覆盖了某个词”，而是承担一个明确的回答任务。
02 问题库不是一张等着全部执行的监测清单
把问题放进产品之后，我很快遇到另一个容易混淆的概念：问题库和监测任务是不是同一件事？
如果把问题导入问题库，就自动开始对所有问题持续监测，听起来很省事。但问题一多，这种设计马上暴露出矛盾。
问题库需要尽可能保留品牌会长期关心的用户需求。它可以包含认知、比较、决策，也可以包含获客、口碑、事实核验和引用观察。它是一组可以持续补充、整理和复用的资产。
监测任务则必须回答一个更具体的问题：这一次为什么测？
在当前产品里，我把监测目标分成自然排名、品牌口碑、引用表现、事实准确性和改善验证。不同目标需要的问题并不相同。
观察自然排名时，问题通常不能直接点名品牌，否则很难判断 AI 是否自然把品牌放进候选范围；观察品牌口碑时，问题反而需要明确指向品牌和评价维度；核对事实准确性时，问题要能落到功能、价格、资质或服务范围等可以人工核验的事实上；做改善验证时，则需要边界清楚、能够固定下来反复比较的问题。
这意味着，同一个问题可能不适合某次监测，却完全适合另一个目标。
因此，问题进入问题库，不等于它已经进入所有监测。每个监测任务都要根据目标，从问题库里显式选择一组题。问题库负责积累可能性，监测任务负责作出当次取舍。
这个分离看起来只是一个产品结构，背后保护的是结果口径。如果把所有问题混在一起跑，再汇总成一个总分，团队很难知道数字变化究竟来自自然推荐、品牌词提示、主观评价，还是事实问答。问题选错了，后面的图表再精致，也只是在精确地回答另一个问题。
03 用户意图不是标签，而是产品决定下一步的依据
为了让问题可以被使用，我开始给它们补充意图和阶段。
认知阶段的问题通常在帮助用户理解概念、建立基本判断；比较阶段的问题开始关注差异、替代、风险和选择标准；决策阶段的问题更接近价格、适用条件、服务细节与事实核验。
我并不认为用户一定会沿着一条整齐的漏斗，从认知一步步走到决策。真实提问经常跳跃，同一个人也可能在不同场景里反复往返。
阶段的价值，不是给用户贴标签，而是帮助产品理解问题离行动有多远。
“什么是 GEO”值得回答，它承担的是认知任务；“制造企业选择 GEO 服务商要看哪些能力”更接近比较；“某个方案是否支持当前团队使用的 AI 平台”则已经落到具体条件。三类问题都可能重要，但它们需要的内容、证据和验证方式不同。
如果产品只追求出现次数，很容易优先选择宽泛、容易生成答案的问题。它们通常覆盖面大，却未必能帮助品牌进入真实选择。加入意图和阶段之后，我才能继续追问：这道题对业务是否重要？它适合当前监测目标吗？结果是否容易观察？答案出现差距后，团队能不能采取行动？
这时，问题才从一句文本，变成了可以支持产品决策的对象。
04 不是问题越多，产品就越有价值
问题生成能力越强，越容易产生一种数量上的满足感。
几十道、几百道问题很快铺满列表，看起来像是已经覆盖了市场。但 AI 能生成一个问题，不等于真实用户一定会问；两个写法不同的问题，也可能在表达同一个意图；包含“最新”“今年”的问题适合观察当下，却未必适合长期比较。
所以我逐渐把重点从“还能生成多少”转向“为什么保留这一个”。
在当前产品里，一道题是否适合某个监测目标，会同时考虑业务价值、目标匹配度、可监测性、离决策的距离、能否转成行动，以及长期稳定性。如果有搜索、销售咨询或其他真实需求观察，也应该被记录；如果只有 AI 生成，产品需要提醒团队继续验证，而不是把它包装成已经存在的需求。
筛选之后，问题会被放进核心监测、探索轮换、储备观察或不适合当前目标等不同位置。
这里最重要的一点是：这不是给问题盖一个永久印章。
一道点名品牌的口碑题，对自然排名监测可能不合适，对品牌口碑却可能非常关键；一道宽泛的认知题可以用来规划基础内容，却不一定适合作为一次改善行动的验收标准。分层必须和目标一起看，不能脱离上下文谈“高分问题”。
我也不希望系统替人做最后决定。评分可以提供一致的初筛和理由，业务团队仍然要判断品牌当前最需要解决什么，以及手里是否有能力回答。产品要减少盲选，不是取消判断。
05 一个稳定的问题，怎样串起一条完整路径
当问题被当成长期对象，而不是生成文章时的一次性输入，整个工作流才开始真正连起来。
品牌画像先界定品牌是谁、服务谁、能够证明什么；关键词和用户场景帮助团队发现可能的问题；确认后的问题进入问题库；监测任务再按目标选择合适的问题，保存 AI 的实际回答和引用。
如果回答暴露出品牌缺席、事实错误、引用不足或场景不匹配，产品可以把这条证据转成 GEO 机会。团队再决定是补品牌资料、修正公开页面、写一篇内容，还是寻找更合适的外部来源。
内容发布后，产品回到同一个问题，在尽可能一致的条件下复测。
这条路径可以写成：
品牌画像 → 关键词与用户问题 → 问题库 → 监测 → GEO 机会 → 内容 → 发布 → 复测
问题在这里像一根贯穿全程的线。
团队可以追溯一篇文章为什么被写出来，也可以知道一次复测在验证哪个动作。即使结果没有变化，这条链路仍然留下了判断依据：当时看到了什么，做了什么，后来观察到什么。
没有问题这个锚点，监测和内容很容易各自成立。监测团队交付报表，内容团队交付文章，发布团队完成任务，最后却没有人能把它们放进同一个因果假设里。
有了问题，也不代表因果关系自动成立。AI 平台、外部内容和提问环境都可能变化。但至少我们知道自己在比较什么，也知道哪些变化暂时不能解释。
06 问题库真正难的，不是“生成”
今天回头看，问题库最容易做的是生成，最难做的是维护。
第一类难题是重复。两道问题可能字面不同、意图相同；也可能只差一个场景词，却值得分别保留。仅靠字符串去重会误删，仅靠语义相似度也不一定理解业务边界。
第二类难题是变化。品牌能力会调整，用户说法会变化，一个旧问题可能需要改写。但直接修改原问题，又可能破坏历史监测的可比性。什么时候应该修订，什么时候应该新建一个问题，并保留它们之间的关系，目前仍需要更清楚的规则。
第三类难题是需求证据。AI 可以快速给出候选问题，产品也可以根据结构做初筛，但“用户真的在问”仍需要来自搜索、销售咨询、客服记录或其他可核验观察。需求会过时，过去出现过也不代表现在仍然重要。
第四类难题是长期比较。一个问题文字没有变化，不代表外部环境没有变化。模型版本、联网能力、账号状态、地区和来源更新，都可能影响回答。稳定问题是比较的必要条件，却不是充分条件。
这些问题让我越来越谨慎地看待“全自动问题库”。自动生成可以帮助团队打开视野，自动评分可以减少第一轮筛选成本，但问题最终为什么留下、用于什么目标、什么时候失效，仍然需要产品和人一起维护。
07 问题定义了要回答什么，证据决定品牌能回答什么
把问题库放在起点之后，我对内容生产的理解也发生了变化。
一篇内容不应该先追求写得完整，而应该先判断它是否回答了一个值得回答的问题。随后还要继续问：品牌有没有足够的事实、案例、规则或公开来源支撑这个回答？哪些可以确定地说，哪些只能写成判断，哪些现在还不能说？
问题库解决的是方向：用户在关心什么，我们准备在哪些问题里建立认知、参与比较或接受核验。
但方向清楚，并不代表品牌已经具备回答能力。
如果问题已经进入决策阶段，知识库里却只有一段模糊的公司介绍，模型就只能用通用话术填补空白；如果产品事实没有版本和来源，再流畅的内容也可能把不确定信息写成结论。
所以，问题库是起点，却不能单独完成 GEO。
它告诉产品“应该回答什么”，下一步还需要一个能管理品牌事实和证据的地方，回答“我们凭什么这样说”。
下一篇，我会写我为什么不把知识库当成资料仓库，以及品牌资料怎样从一堆文件，变成 AI 能够正确使用、团队也能够回头核验的证据。