从一句想法到一款产品：GEO 的第一版定义
“让品牌进入 AI 的答案。”
这句话可以解释我为什么想做 GEO，却还不足以定义一款产品。
一句想法通常没有边界。它可以向任何方向生长：做监测工具、内容生成器、品牌知识库、自媒体发布平台、报告系统，甚至做成一套完整的营销软件。每个方向听起来都有道理，但把所有正确的方向放在一起，并不会自动变成一款正确的产品。
真正困难的，是从这些可能性里做选择：第一版先服务谁？先解决哪个问题？哪些环节必须连起来？哪些看起来很重要的能力，暂时不做？
回头看，豆见 BeanInsight 的第一版定义，并不是从功能列表开始的，而是从一次范围收缩开始的。
01 第一版先服务谁
一开始，我没有把它定义成一个面向所有企业、开箱即用的 GEO SaaS。
第一版更具体：它首先是一个面向内部 GEO 交付团队的工作平台。
这个决定很重要。因为”给所有企业使用”和”帮助一支交付团队完成真实项目”，看起来只差一个用户范围，实际会产生两套完全不同的产品优先级。
如果一开始就做通用 SaaS，产品很快会被账号体系、套餐计费、权限组合、模板市场和大量配置项占满。它们迟早可能需要，但无法证明 GEO 的核心工作是否真的成立。
内部交付团队面对的问题更直接：今天要监测哪些问题？哪些 AI 回答暴露了品牌缺口？应该补什么内容？文章由谁审核？发布之后如何验证？
所以，第一版的目标不是先拥有最多用户，而是先让一支真实团队能够用它完成一次完整交付。先验证工作流，再决定它是否应该长成 SaaS。
这是我做的第一个收缩：先服务一个清楚的人，而不是想象中的所有人。
02 第一版到底要跑通什么
确定用户之后，第二个问题是：这款产品完成什么，才算真的有用？
如果只用页面数量来衡量，很容易得到一个错误答案。品牌管理能打开、文章能生成、监测有图表，并不代表产品已经成立。各个功能都能使用，也可能只是几座彼此没有连接的孤岛。
第一版规格里，我给产品写下了一条最小闭环：
品牌与问题 → 真实监测 → GEO 机会 → 内容 → 公众号草稿 → 人工发布 → 复测与归因
这条链路成为了产品最早的骨架。
品牌与问题，定义我们在为谁、围绕什么用户需求工作；真实监测，告诉我们 AI 实际说了什么；GEO 机会，把观察到的差距变成可以讨论的改善方向；内容和发布，把方向转成行动；复测与归因，则负责回答行动之后发生了什么。
缺少任何一段，闭环都会断掉。
只有内容，没有监测，团队不知道为什么写，也不知道写完是否改变了什么。只有监测，没有行动，产品就会退化成一块不断提醒问题的仪表盘。只有发布，没有复测，“已完成”就只是任务状态，而不是品牌认知真的有所改善。
所以第一版的成功标准，不是做出一个 GEO 概念演示，而是让一个新品牌可以从问题出发，获得一条可回溯的监测证据，形成内容，进入公众号草稿，在人工发布后回到同一组问题上复测。
这是第二个收缩：第一版只证明一条闭环，而不是证明所有功能都能做。
03 为什么从问题开始，而不是从文章开始
在所有入口里，文章生成最容易让人立刻感受到产品能力。输入几段资料，很快得到一篇完整文章，演示效果很好。
但我没有把”生成一篇文章”当成第一版的核心任务。因为脱离用户问题之后，文章很容易变成没有方向的内容库存。
GEO 面对的不是抽象的”品牌曝光”，而是一个个具体问题：用户在比较什么，担心什么，准备做什么决定。只有把问题固定下来，我们才知道该监测什么、内容要回答什么，后面的结果又应该怎样比较。
因此，第一版要求先建立品牌画像和问题库，再启动基线监测。问题不是生成文章时临时输入的一句话，而是贯穿监测、机会、内容和复测的业务对象。
同一个问题会留下完整路径：它曾经得到怎样的 AI 回答，品牌有没有被提到，形成了什么 GEO 机会，后来关联了哪篇内容，发布后又出现了什么变化。
这也是为什么，随着产品继续演进，我仍然把问题库看作起点。它不是关键词表的另一种叫法，而是整个 GEO 工作流保持上下文的锚点。
这是第三个收缩：不从最吸引眼球的功能开始，而从能连接全流程的对象开始。
04 为什么一定要保留真实回答
第一版还做了一个并不轻松的选择：监测不能只依赖模型 API 返回的答案，而要尽可能观察用户真正使用的 AI 产品页面。
API 更容易接入，也更容易做成稳定的演示。但 API 返回的内容，不必然等于用户在真实网页、真实账号和实际搜索能力下看到的答案。平台是否启用了联网搜索、页面展示了哪些引用、登录状态带来了什么差异，这些都会影响结果。
如果产品想回答”品牌在 AI 答案里表现怎样”，就不能把另一种环境里的结果悄悄当成真实页面证据。
所以，第一版把 Chrome 浏览器扩展纳入了产品。它负责在用户已经登录的 AI 平台上执行监测，保存回答和引用；模型 API 可以用于分析、生成和明确标记的降级场景，但不能冒充真实网页观测。
这个决定提高了实现难度，却保护了产品最重要的东西：证据边界。
一次失败的真实监测，不能记成品牌”未被提及”；一次 API 降级结果，也不能和真实网页结果混在同一条趋势里。只有知道数据是怎样得到的，后面的机会、内容和验证才有可信基础。
这是第四个收缩：宁愿承认暂时不可用，也不把不同来源的结果包装成同一种成功。
05 为什么产品只做到公众号草稿箱
在发布环节，第一版也刻意停在了微信公众号草稿箱。
从自动化角度看，直接完成最终发布似乎更完整。但文章真正对外出现之前，还涉及事实、表达、配图、账号权限和品牌风险。尤其在产品早期，我不认为模型生成完成就等于内容已经具备公开发布条件。
所以这条工作流里一直保留人工审核：内容经过事实检查和审核后，系统把它同步到指定公众号草稿箱；运营人员在公众号后台进行最后检查，再决定是否发布。
只有正式 URL、发布时间等信息得到确认，产品才会把它当成一次真实发布，并安排后续复测。
这个边界让流程没有那么”全自动”，却让责任更加清楚。产品可以辅助生成、整理和同步，但不能替人完成最后的品牌判断。草稿创建成功也不等于已经发布，更不等于内容已经被 AI 看见。
这是第五个收缩：自动化到适合自动化的位置，把最终决定留给人。
06 第一版明确不做什么
产品定义不仅要写”做什么”，还要写”不做什么”。后者往往更难，因为被暂缓的每个方向，都能讲出一套合理的价值。
第一版没有把付费媒体商城、供应商库存和交易结算放进范围；没有先做复杂的套餐计费；没有同时覆盖所有内容平台；没有做无人值守的最终发布；也没有先做复杂舆情、销售型诊断报告和白标报告中心。
这些并不代表它们永远没有价值，而是它们无法回答当时最关键的问题：
我们能不能用可信证据，从一个用户问题出发，完成一次可执行、可复测的 GEO 改善？
如果这个核心问题还没有答案，外围能力越多，产品反而越难看清。
第一版的边界因此非常克制：少量真实项目、有限平台、清楚的问题库、一条内容与发布路径，以及可以回到基线的验证机制。
07 第一版没有被完整照搬，但核心问题留下来了
产品后来当然发生了很多变化。
技术结构调整过，页面和领域对象也不断重构；监测需要区分不同目标，GEO 机会需要从简单异常变成可验证的改善假设，发布需要连接更多渠道和证据，知识库也不再只是上传资料的地方。
第一版的很多具体方案并没有原样保留。这很正常。产品定义不是一张不能修改的施工图，而是对当前阶段最重要问题的回答。
但那条最小闭环一直没有消失：问题、监测、机会、行动、发布、验证。
今天的豆见 BeanInsight 已经比第一版设想覆盖更多能力，但我判断一项新功能是否值得做时，仍然会回到同一个标准：它有没有让这条闭环更清楚、更可信、更容易执行？还是只让菜单里多了一个入口？
08 我从第一版定义里学到的事
从一句想法到一款产品，中间并不是补上一份功能列表，而是连续做出几次取舍。
先服务一支真实交付团队，而不是所有想象中的用户；先跑通一个可验证闭环，而不是铺满所有模块；先固定用户问题，而不是先追求内容数量；先守住真实证据边界，而不是追求漂亮数据；先进入草稿箱并接受人工审核，而不是把自动化当成目标本身。
这些决定共同构成了 GEO 产品的第一版定义。
现在回头看，它当然不完美，但它让我确认了一件事：产品的第一版不需要解释整个未来，它只需要把最关键的假设变成一个能够真实运行、能够暴露问题的流程。
而下一步，就是继续追问这条流程真正服务的需求。
用户说”我想被 AI 看见”时，他想要的究竟是一次提及、一张好看的报表，还是被理解、被信任，最终进入用户的选择？这会是下一篇要讨论的问题。