GEO 产品真正困难的部分，不只是模型和代码，而是定义指标、保存证据、守住权限与责任边界，并让失败可以恢复。
GEO 产品最难的部分，可能不是模型和代码
开始做 GEO 产品时，我最担心的是模型能力不够。
它能不能读懂品牌资料？能不能从一段回答里识别品牌、竞品和引用？能不能写出一篇结构完整的文章？遇到几十个问题、多个 AI 平台和不同采集环境时，系统又能不能稳定跑下去？
这些问题当然都难。模型会波动，外部平台会变化，浏览器页面会改版，代码也会不断出现新的边界情况。
但把产品一路做下来，我越来越清楚地看到：最难的部分，往往不是让模型给出一个结果，而是决定这个结果究竟代表什么，团队可以据此做什么，以及出了错以后怎样回到当时的证据。
模型和代码解决的是“能不能做出来”。
产品还要回答另一组问题：什么叫品牌被看见？什么叫说对了？一次行动完成以后，凭什么说它有效？哪些信息可以公开，哪些只能留在内部？系统不知道的时候，是继续猜，还是诚实地留下“不知道”？
这些问题没有一个能靠换更强的模型自动消失。
01 做出结果不算难，让结果可以负责才难
一个 GEO 产品的演示版本很容易让人兴奋。
输入品牌资料，生成一批问题；调用 AI 得到回答；识别品牌有没有出现；再根据差距生成文章和建议。页面一连起来，产品已经像是一个完整闭环。
可一旦它开始承担真实判断，问题就来了。
回答里出现了品牌名，就一定算提及吗？用户的问题里本来就带着品牌名，模型只是复述问题，这和在一个自然的品类问题里主动推荐品牌，能放进同一个指标吗？回答写了“适合部分场景”，情绪规则可能把限制词判成负面，但这句话也可能恰好是在准确说明产品边界。
代码可以很快返回一个布尔值，模型也可以给出一个看似完整的解释。
真正困难的是，产品是否愿意为这个判断规定适用范围，并且让后来的人能看见它是怎样得出的。
我现在会把“系统给出了答案”和“系统形成了可使用的结论”分开。前者可以自动发生，后者必须带着问题、原始回答、引用、采集环境、判断规则和必要的人工复核。
多出这些信息以后，页面会更复杂，流程也不会像演示时那么顺滑。但没有它们，所谓智能只是把判断过程藏了起来。
02 每一个简单数字，背后都有一组产品定义
监测页面上最容易理解的数字，是提及率。
问了多少个问题，品牌出现了多少次，两者相除，看起来没有太多争议。
真正开始做，我才发现分母和分子都需要定义。
采集失败的问题要不要进入分母？登录失效、页面验证或网络中断时，系统并没有拿到有效回答。如果仍然按“未提及”计算，产品是在把采集故障写成品牌表现。
品牌词出现在问题里，要不要算模型主动提及？事实核验、声誉评价和自然品类问题，能不能混在同一组统计里？同一个问题重复采集多次，是每次都计数，还是先形成一个问题层面的结论？人工复核修改了判断后，历史指标应该读原始结果还是当前有效结果？
这些不是数据库字段怎么设计的问题，而是产品准备怎样解释世界。
我曾经觉得，只要在指标旁边补一段说明就够了。后来才明白，定义必须进入整个数据流：创建任务时限制范围，采集时保存上下文，统计时使用一致口径，报告里冻结当时样本，后续复测时仍然按照同一条件比较。
如果不同页面各自理解“提及率”，再漂亮的图表也只是在展示几套互不相认的数字。
03 证据不是结果旁边的一张截图
做内容产品时，人很容易把证据理解成来源链接。
有链接，似乎就能证明文章可靠；有一张回答截图，似乎就能证明监测发生过。
GEO 场景里的证据要更完整一些。
一次监测观察至少需要保留原始问题、完整回答、页面呈现的引用、平台、账号范围、会话方式、模型、联网状态、语言和采集时间。少了这些信息，同一句回答换一个环境，可能已经不是同一件事。
品牌事实也不能只保存一句“正确答案”。它需要有来源、所有权和时间边界。产品资料已经进入知识库，只能说明系统可以检索；真正写成公开内容，还要确认这条事实是否获准发布，以及生成时实际使用的是哪个版本。
后来我越来越在意快照。
监测报告不能随着数据库里的最新结果悄悄变化，已发布文章也不能因为品牌资料更新，就失去当时为什么这样写的依据。历史不是用来占存储空间的，它让团队可以回答：“在那个时间点，我们看到了什么，又依据什么做了这个决定？”
这条链一旦断掉，复盘就会变成凭印象争论。
04 边界比能力列表更能定义产品
产品介绍里通常会写能做什么，很少写不能做什么。
但 GEO 产品是否可信，很多时候取决于它有没有守住那些“不自动做”的地方。
内部知识不能自动变成公开事实；一次监测异常不能自动变成内容任务；文章发布成功不能自动变成 GEO 效果改善；用户手动完成外部发布，不等于系统已经验证公开链接；模型给出一个高置信判断，也不能覆盖原始回答和人工修正历史。
这些边界看起来都在减慢流程。
如果全部拿掉，产品会非常流畅：上传资料，点击生成，自动发布，自动判定成功，最后给出一张持续上升的图。但这条路径把几个完全不同的状态压成了一个状态，也把外部平台的不确定性包装成了系统自己的确定性。
我现在更愿意把边界写进产品，而不是只写进使用说明。
需要人工确认的地方，就让状态停下来；外部结果无法确定，就保留待核实；缺少公开事实，就回到资料归属的位置补充；没有达到预先写下的验证标准，就不能因为任务已经完成而宣布改善。
可靠不是产品永远给出答案，而是它知道哪些答案暂时不能给。
05 工作流不是把几个页面用箭头连起来
我最初理解工作流，比较接近一条功能路径：问题库之后是内容，内容之后是发布，发布之后是监测。
后来我发现，页面顺序只是最表面的一层。
真正的工作流要带着上下文往前走。为什么创建这篇文章？它来自哪个用户问题和哪条 GEO 机会？写作使用了哪些已经确认的事实？发布到了哪里？外部链接有没有拿到？什么时候应该回到哪个平台做同口径复测？
如果上下文在每个环节都丢一次，团队只是在多个工具之间搬运任务。
工作流还要容纳失败。
采集可能因为登录或验证中断，发布请求可能超时但外部平台其实已经收到，报告可能只有一部分样本可用。系统不能把所有失败都变成“重试”，因为对外部副作用盲目重发，可能创建重复内容；也不能把部分成功悄悄抹平，否则报告会显得完整，证据却是不完整的。
因此，状态机、幂等、恢复路径和人工处理，并不是工程团队的内部细节。它们会直接决定用户看到的是一个可以继续推进的流程，还是一个失败后只能从头再来的按钮集合。
06 人工复核不是自动化失败
产品越强调 AI，越容易把人工步骤理解成一种退步。
我也有过这种倾向：如果一项判断最后还要人确认，是不是模型能力还不够？是不是应该继续优化提示词，让系统直接给出最终答案？
但提及、情绪、事实准确性和行动优先级，承担的责任并不相同。
模型很适合从大量回答中找到候选问题，标记可能的负面表述，整理引用，提示某条品牌事实可能存在冲突。它能大幅缩小人工需要阅读的范围。
可事实是否可以公开、一个限制条件是否属于准确边界、某条机会是否值得投入业务资源，仍然需要有人承担判断责任。
所以我后来不再追求把人完全移出流程，而是思考怎样让人的判断成本更低、依据更清楚、结果可以被后续系统统一使用。
人工修正也不能覆盖历史。原始观察留在原处，新的结论以追加记录进入系统。这样做并不是不相信人，而是承认人的判断也会变化，也需要被解释。
07 最难改变的，可能是团队的工作习惯
功能做完以后，产品并不会自动成为工作方式。
团队可能仍然习惯从一个热门词开始写文章，而不是先确认用户问题；习惯在群里口头说“这条有问题”，却不补充标准事实和来源；习惯把发布完成当成项目完成，很少回到原问题复测；也可能看到一张总分，就跳过下面的样本和证据。
如果产品只要求大家“以后按新流程做”，通常很难持续。
每增加一个字段、一个审核步骤或一个状态，都应该回答它帮用户减少了哪一种重复判断。能从项目和上一步推导的信息，系统应该自动带入；需要补资料时，应该回到资料原本的归属位置；报告给出问题时，应该能直接看到对应回答和来源，而不是让用户在几个页面之间重新搜索。
产品既不能为了省一步，把重要责任交给模型，也不能为了严谨，把所有证据整理工作都甩给用户。
这个平衡没有一个永久答案。它只能在真实操作里不断调整：哪里让人看不懂，哪里容易跳过，哪里重复填写，哪里失败后找不到恢复入口。
模型升级可能一夜之间发生，工作习惯很少会。
08 模型仍然重要，只是它不应该拥有最后一个定义
写到这里，并不是说模型和代码不重要。
没有稳定的采集、解析、生成和任务系统，所有产品判断都只能停留在文档里。模型能力变强以后，内容理解、异常识别和建议生成也会明显改善。
但我不再把更强模型当成产品问题的通用答案。
如果指标口径没有定义清楚，更强的模型只会更流畅地解释一个含义模糊的数字；如果公开边界没有建立，它会更自然地把内部资料写成确定事实；如果流程没有冻结证据，它会给出更像结论的回顾，却仍然无法证明当时发生过什么。
我现在更愿意把模型放在它擅长的位置：阅读大量材料、发现候选线索、生成可供审阅的内容、帮助用户减少机械操作。
而产品要守住定义、权限、证据、状态和责任。
这大概是我做 GEO 产品以来，认知变化最大的一点。最初我想证明 AI 能完成多少工作；现在我更关心，当 AI 参与越来越多工作时，产品怎样让每个结论仍然可理解、可追溯，也允许被推翻。
下一篇，我会把这些抽象判断放进一次真实迭代里。那次迭代没有换模型，也没有增加一个炫目的生成按钮，却因为一组看起来很简单的诊断问题，让我重新做了数据归属、指标口径、失败恢复和报告证据。
它让我看到，产品真正的重做，常常不是把页面换一种样子，而是承认第一版回答错了问题。