复盘一次品牌诊断重做：八道自然问题与三道品牌问题被当成同一批十一道题统计，数字都算对却回答了不同问题——重新划分数据归属、处理失败状态并冻结报告证据。
一次真实迭代复盘：需求、上线、反馈与重做
这次迭代开始时，需求并不复杂。
一个品牌在正式开始 GEO 运营之前，希望先知道 AI 怎样认识自己：在自然的品类和决策问题里，品牌会不会出现；当用户直接询问这个品牌时，AI 给出的评价和事实是否可靠。
把这些问题整理成一组诊断题，跑完几个 AI 平台，再生成一份报告。路径很短，也很容易讲明白。
第一版进入可运行流程以后，结果页面也能正常展示。直到我继续对照监测详情、提及率、声誉结果和报告快照，才发现一个更麻烦的问题：
每一个数字都算对了，但有些数字回答的不是同一个问题。
这篇不写一段漂亮的“上线成功”。我想按真实顺序复盘这次产品迭代：需求怎样被理解，第一版为什么看起来成立，系统给出了什么反馈，我又为什么决定重做。
01 最初的需求：先给品牌一张可以解释的快照
品牌诊断不是日常监测。
日常监测围绕一组长期问题持续运行，团队会看趋势、建立基线、发现 GEO 机会，再安排后续行动。诊断更像一次进入项目前的快照：用有限的问题快速理解品牌在 AI 答案里的当前状态，并把值得继续调查的方向说清楚。
我把诊断问题分成了两个维度。
一组是八道自然问题。它们不在问题里预先写入品牌名，主要观察用户在品类、场景或决策问题中提问时，AI 会不会自然提到这个品牌。
另一组是三道品牌相关问题。它们明确询问品牌本身，主要用来观察 AI 如何描述品牌、表达什么情绪，以及是否存在需要核验的事实。
两组问题都和品牌有关，也都会进入同一份诊断报告。当时最自然的实现方式，是把它们当成一次采集任务里的十一道题，跑完以后再按问题标签计算不同指标。
从交付一份报告的角度看，这个设计很顺。
问题只创建一次，任务只执行一次，报告也只等待一个结果。第一版因此很快形成了完整路径。
02 第一版为什么会让我觉得它已经成立
产品里最容易被误认为完成的时刻，是主路径第一次跑通。
用户提交品牌信息，系统生成并确认问题，创建采集任务，等待 AI 回答，然后输出诊断结果。报告里有提及情况、情绪观察、原始回答和建议，前后状态也能接起来。
从页面看，需求已经被满足。
从代码看，十一道题都属于同一个诊断，放在同一批次里并没有明显错误。只要每道题保留自己的维度，报告生成时再分别统计，就能得到八道自然问题的提及结果和三道品牌问题的声誉结果。
这个方案还有一个很现实的诱惑：复用。
产品已经有监测任务、运行批次、回答样本和指标查询。诊断只需要借用这套能力，再在报告层做一次筛选。相比重新设计两条采集链，它改动更小，也更快看到结果。
我当时低估了一件事：数据进入监测系统以后，不只会被诊断报告读取。
它还可能被任务详情、日常看板、趋势、监测报告、GEO 机会和基线读取。只在最终报告里拆开问题，并不能保证其他消费者理解这十一道题的特殊含义。
03 系统给出的反馈：数字正常，口径开始串线
这里说的“反馈”，不是一条我准备包装进文章的客户好评。
它来自第一版继续往下运行时暴露出的数据矛盾。
提及率本来要回答：在自然用户问题里，AI 主动提到了几次品牌。可是三道声誉问题本身就带有品牌名。如果它们混进普通提及统计，分母从八道自然问题变成十一道，分子也可能因为问题自带品牌而被推高。
计算公式没有错，样本归属错了。
另一个问题出现在日常运营数据里。诊断是一次性的前置观察，日常监测却要长期比较。如果诊断样本进入趋势、平台覆盖、监测报告或机会评估，系统就会把一次特意设计的品牌问题，当成品牌日常可见性的自然变化。
它会制造一种非常隐蔽的污染。
看板不会报错，曲线也会正常绘制，但团队可能把诊断发生的那一天理解成品牌表现突然变化。以后建立基线时，如果又选中了这批样本，比较对象从一开始就不再可比。
这类问题比页面崩溃更危险。页面崩溃会迫使人停下来，口径串线却会给出一个足够像真的答案。
04 我先尝试在读取端补过滤，后来决定重做归属
发现问题以后，最小改法是在每一个统计查询里排除那三道声誉问题。
诊断报告按维度筛选；提及率只看自然问题；日常看板排除诊断批次；机会和基线再各自增加判断。历史数据已经存在，这样做也比较容易保持兼容。
但列出所有读取方以后，我发现这个方案会让错误长期潜伏。
今天记得给看板加过滤，明天新增一份报告时也许会忘；某个页面按任务读取，另一个页面按样本读取，两边的排除条件还可能不同。诊断数据的特殊性只能靠每个调用方自行记住。
这不是真正的数据归属，只是一组不断扩散的补丁。
所以我把重做的重点从“怎样算对报告”改成了“这两类观察从创建时分别属于哪里”。
八道自然问题进入一次性的 AI 排名监测集合，三道品牌问题进入一次性的声誉监测集合。两个任务都明确标记用途是诊断，并通过诊断关联记录绑定各自的任务和那一次准确的运行批次。
报告仍然只有一份，但它不再依赖“十一道题碰巧在同一个任务里”。
先把数据放回正确的所有权边界，再谈怎样聚合展示。
05 拆成两组以后，用户仍然要看见一条完整流程
数据拆开不代表体验也要被拆碎。
如果用户提交一次诊断，却看到两个互不相关的后台任务，还要自己判断哪一个完成、哪一个失败，重做只是在把系统复杂度交给用户。
因此，两组监测在产品里保持可见，但都带着诊断用途和原始诊断的关联。排名监测展示八道自然问题，声誉监测展示三道品牌问题；用户可以分别进入任务查看采集进度、问题和原始回答，也能从任务回到同一份诊断。
诊断本身负责等待两个集合进入终态。
只有排名组完成，声誉组还在等待登录处理，报告不能提前假装完整；声誉组已经完成，排名组仍在采集，同样要继续等待。两组都结束以后，系统才根据实际可用证据生成一次报告。
这一步让我重新理解了“流程完整”。
它不是所有东西必须塞进一张表或一个任务，而是用户始终知道当前在做什么、还差什么、下一步去哪里处理。
06 失败路径迫使我重新定义“诊断完成”
第一版最顺的假设，是十一道题都会成功返回。
真实采集不会这么整齐。浏览器账号可能需要重新登录，页面可能要求验证，某个平台的一部分问题也可能采集失败。
如果两个集合里只要有一道题失败就拒绝生成报告，用户已经拿到的有效回答会被浪费；如果不管缺多少样本都给出完整结论，报告又会掩盖证据缺口。
重做以后，我把几种状态分开处理。
需要登录或验证的项目仍然停在可恢复状态，用户处理后可以继续原来的批次，而不是重新创建整份诊断。两个集合都进入最终状态后，只要仍有可用样本，报告就可以生成，但必须明确显示哪些问题缺失，提及率的分母也只使用成功取得回答的自然问题。
如果完全没有可用样本，诊断才进入失败，不生成一份空心报告。对应的诊断扣费只退款一次，即使后台再次检查完成状态，也不能重复入账。
这些规则不会让成功页面更好看，却决定了系统在不完整世界里是否诚实。
07 报告必须冻结当时的两批证据
诊断报告生成以后，两个监测任务仍然存在。
如果报告每次打开都去读取任务的最新结果，它会随着后续运行、人工修正或时间筛选发生变化。用户今天看到的结论，可能和几天后打开同一份报告时不同。
所以诊断关联的不只是任务，还包括每个维度当时那一次具体运行。
报告生成时，系统把两个绑定批次的原始回答、引用、采集环境、有效判断和缺失状态一起冻结。即使监测库里后来出现额外样本或数据维护，也不会回头改变已经生成的诊断指标和证据。
这里还有一个兼容问题。
早期已经存在把两类问题混在同一任务里的诊断数据。重做不能通过删除历史来获得干净结构。对于这些旧记录，系统仍然保留原始回答，只是在读取提及率时限定为当时冻结的八道自然问题，不让三道声誉问题进入排名口径。
一个真正可用的重做，很少能假设世界从今天才开始。
08 这次迭代没有增加模型能力，却改变了产品可信度
回头看，这次迭代最醒目的变化并不在报告视觉上。
模型没有更换，问题数量没有增加，AI 回答也不会因为数据拆成两组就自动变得更准确。用户最终仍然得到一份品牌诊断报告。
变化发生在下面几层：两类问题有了各自的监测归属；诊断样本不再进入日常趋势和机会；提及率只使用成功的自然问题；登录异常可以恢复；部分结果保留缺口；没有有效证据时停止生成；报告绑定准确批次；失败扣费只处理一次。
这些改动共同解决的，是“这份报告凭什么可以被解释”。
我过去容易把迭代价值放在新增能力上。多一个模型、多一个按钮、多一种图表，变化非常直观。像这次这样的重做，外表可能只多了两个入口和几条状态提示，工程和产品内部却重新划分了数据边界。
它让我更确信，GEO 产品不能只追求给出更多结论。
当不同问题被放进同一个数字，结论越快，误导也越快。把它们拆开以后，产品看起来多了一些复杂度，却让每个数字终于只回答它应该回答的问题。
09 我从这次重做里留下的几个判断
第一，报告的结构不能反过来决定数据模型。
一份报告可以把多个维度放在一起展示，但底层观察仍然要保留各自的用途、样本和口径。展示上的聚合，不等于数据上的混合。
第二，读取端不断增加过滤条件时，应该回头检查写入端的归属。
如果每个看板都要记住“排除某类特殊数据”，通常意味着这类数据没有在创建时被正确标记，或者不应该和普通数据共享同一个默认入口。
第三，异常状态也是产品的一部分。
可恢复、部分可用、无法确认、退款一次，这些状态不够漂亮，却比一个笼统的失败更接近用户真正需要的下一步。
第四，历史兼容不能靠假装旧数据不存在。
产品定义变了，旧记录仍然代表当时真实发生过的观察。可以调整读取口径，可以增加明确关联，但不能为了让新结构整齐而重写证据。
这次迭代从一个很简单的需求开始：给品牌做一次 AI 诊断。
最后真正被重做的，不是那份报告，而是我对“诊断”这个对象的理解。它不是十一道题跑完后生成的一张结果页，而是两组用途不同的观察，在同一时间点形成的一份可解释快照。
需求、实现、系统反馈和重做走完一遍以后，我也开始用另一种方式看品牌增长。
增长不只是把更多内容推向外部，也不是让某个数字短期变高。它首先要求品牌知道自己在回答谁的问题、依据什么表达、哪些变化值得投入，以及怎样确认外部世界真的发生了变化。
下一篇，我会写做 GEO 之后，我对品牌增长的理解具体变了什么。