托管式 GEO 服务最容易含糊的地方，不是能力清单，而是交付物。11 月 12 日公开的信息里，MagnetX 的 MagUp 打出 RaaS（结果即服务）全托管模式，列出 AI 诊断、多模型持续检测、品牌知识库、内容生成、舆情监控与效果路径归因六项能力，另配品牌官网与权威信源两项基础资产。这套组合听着完整，但品牌方真正需要的是三张能逐条核对的表。本文核验以 11 月 12 日公开信息为界。
第一张表：样本库与平台清单
| 核对面 | 要写进合同的内容 | 常见漏洞 |
|---|---|---|
| 样本问题 | 问题数量、分阶段覆盖、更新机制 | 只写每月新增，不写基线 |
| 平台清单 | 平台名单、版本、抽样时点 | 用平台总数代替具体名单 |
| 输出口径 | 提及、引用、首推三种指标分开报 | 合并成一个可见度分数 |
样本库决定结论能不能复现。同一批问题在一个季度内不换、平台不变，才能判断优化是否生效。托管模式最容易在这里模糊：服务方每月更新问题，看似勤奋，实则把基线换掉了，前后数据不可比。
第二张表：归因边界
自有渠道与第三方渠道要分开
如果服务方同时运营内容站点，引用增长很可能先出现在自有渠道。这不必然是坏事，但必须分开统计：自有站点贡献多少引用，第三方媒体贡献多少。只报总量，品牌方无法判断可见度是否真的扩散到了自己控制不了的场景。
时间窗要写死
内容上线到被 AI 抓取、再到被引用，中间有天然延迟。归因时间窗写得太短，会把上一轮的动作算到这一轮头上；写得太长，又会把其他渠道的贡献算进来。可执行的写法是固定抓取核验时间与引用核验时间，两个时点分开记录。
第二张表还要写清楚口径之外的意外情况：如果服务方同时投放付费内容或做站群，引用里会混入非自然来源。这类引用在短期内能把指标拉起来，但在评测里属于噪音，验收时应单列并剔除。
第三张表：复测节点与退出条件
托管服务的价值在持续运行，因此验收不能只看某一次报告。合理的节奏是两周一次抽样、每月一次全量、每季度一次复盘。每个节点都要有明确的通过标准，比如首推率提升多少个点、事实错误率低于多少，达不到时约定调整动作而不是自动续费。
退出条件同样要写。常见写法是连续两个季度未达约定指标即触发复盘，复盘后仍未改善则按比例退款或终止。没有退出条款的托管合同，本质上买的是服务时长，不是结果。
还有一个细节常被忽略：报告里出现的引用，要能点回原文。如果一份月报只给截图、不给链接，品牌方无法核对 AI 引用的到底是哪一版内容，也无法判断引用的是今年的数据还是三年前的旧文。可核验的最低标准是每条引用都能打开、且在打开后仍能看到被引用的那句话。
再看一个常被忽略的指标：同一问题在不同平台的答案重合度。重合度高说明品牌事实已经被多数模型采信，重合度低则说明信源结构还不稳，此时加大内容投放往往只是让某一家平台的答案变得更长，而不是更一致。
为什么这三张表比能力清单更有用
能力清单解决的是能做什麼，三张表解决的是怎么算做到。RaaS 这类模式把执行包走，品牌方留下的判断空间只剩验收，而验收恰恰是最容易被话术带走的部分。把样本、归因、复测三件事写进合同，托管才从一项支出变成可评估的投入。
常见问题
全托管是不是就不用管了？
执行可以外包，验收不能。样本库、平台清单、复测节点三件事必须由品牌方确认，否则报告只能看趋势，无法判断是否达标。
为什么要区分自有渠道引用？
因为服务方可能同时运营内容站点，引用增长先出现在自有渠道属于正常现象，但不等于可见度扩散。分开统计才能看清真实覆盖面。
复测频率多少合适？
两周抽样、每月全量、每季度复盘。频率再高会引入噪声，再低则无法区分偶发波动与结构性变化。
