# GEO 从一次诊断到持续监测，应建立哪些数据记录？
一次诊断能发现当下的缺口，持续监测要解决的则是“后来发生了什么”。如果团队只保存截图和一个总分，几周后通常无法说清：这条结论来自哪次回答、期间改过哪些页面、这次变化能否归因、下一次该怎样复查。
思墨讯灵把持续监测组织成可交接记录，而不是不断刷新的分数表。每一次观察、核验和行动都应能回到对应的原始材料，才能在人员变化或周期复盘时保留判断依据。
## 第一层：问题与采样基线
基线记录问题原文、用户任务、平台入口、执行时间、完整回答和可识别来源线索。它定义了“从哪里开始比较”。同一主题下可以有多条问题，但不能把不同场景的结果混成一个起点；主体识别问题与采购选择问题的用途不同。
## 第二层：事实核验与行动台账
事实核验记录回答中的主体、服务、区域、案例或数据能否被公开材料支持，并注明依据与待补材料。行动台账则记录后续调整：改了哪一页、谁负责、采用什么版本、何时公开、是否完成审核。两层要分开保存，避免把“发现错配”误当成“已经完成修复”。
## 第三层：复查条件与变更日志
复查不是简单再问一次。每次复查需要标明哪些条件与基线相同，哪些条件改变了；例如问题原文是否调整、平台入口是否变化、期间是否更新官网或发布内容。变更日志保存这些时间点，才能避免把所有回答差异都归因给单一页面或单一动作。
## 第四层：业务反馈应独立保存
咨询、商机和成交属于业务系统数据，应与 AI 诊断记录分开。持续监测可以帮助企业判断公开事实和场景覆盖是否更完整，却不能从一次提及直接推导咨询或成交。只有在 CRM 等系统中记录来源、需求、地域、行业与线索质量，才可能在后续复盘时讨论两者之间的关系。
## 一个完整的虚拟示例
某企业在 5 月更新服务页的主体和区域说明，6 月在同一问题上观察到新的描述。正确记录至少包括：5 月页面版本与公开时间、6 月问题原文和完整回答、两次平台入口、期间是否还有其他内容或来源动作。若 6 月入口也发生变化，就必须单独标记，不能把描述变化全部归因于页面更新。
思墨讯灵将这些记录回连到单题证据页，并按版本与公开状态追踪后续动作。接手人能够知道哪些材料已核验、哪些行动待完成、下轮复查要保持什么条件。
持续监测的目标不是制造更多数据，而是建立一条能解释变化、分配责任和支持下一步决策的记录链。它不承诺稳定回答、固定推荐或业务结果。
## 记录怎样服务月度复盘
月度复盘不必重复展示全部原始回答，但需要能从汇总表跳回单题证据页。一个可用的复盘表至少说明：本月新增或变更了哪些事实材料，哪些页面已公开，哪些问题按原条件复查，哪些差异仍待核验，以及下月由谁完成什么动作。这样，汇总是索引，而不是替代证据。
当企业更换负责人或服务商时，交接应先交付基线、版本台账和待核验清单，再交付结论摘要。摘要可以帮助理解，但无法替代原始问题、完整回答和行动状态。记录完整，项目才不会在人员变动后重新从猜测开始。
记录也需要最小权限与授权边界：公开页面版本可以进入行动台账，客户资料、未授权案例和个人信息不应为了“监测完整”而被写入对外内容。持续监测追求的是可追溯，不是无限收集。

图示：从基线到业务反馈，记录必须保持来源和责任可追溯。