一份生成式引擎优化服务合同，怎么判断它到底交付了什么？问「AI 里能不能搜到我们」，得到的答案几乎永远是能；问「在哪些平台、哪些问题、多长时间内、用什么口径统计」，才可能问出可复核的结果。截至 11 月 12 日的公开信息，已经有服务商把合同条款写成四项明确约定：目标平台、问题范围、统计口径与复测周期，并采用结果即服务的模式交付。这套写法值得拿来当验收模板。
验收难，难在交付物不是一个文件
这组关于 GEO 交付的说明把验收难点摆得很直白：GEO 的交付物不是一份报告，而是一组持续变化的答案。报告可以验收页数与结论，答案不行——今天回答了，明天模型更新可能就变了。所以真正要约定的是过程与口径，而不是某一次截图。行业内有人把这件事总结成三句话：过程可查看、结果可比对、动作可追溯。三句话都不是形容词，每一句都对应合同里的具体条款。
为什么截图不能当证据
截图至少有三个问题。第一是时点不可复现，同一问题在不同时间问，答案可能不同，事后无法证明当时是不是这样。第二是问法不可比，同一意图换个措辞，结果可能完全不同，截图里看不到完整提问。第三是范围不可界定，一张截图只说明某平台某一次的表现，无法推断整体。要解决这三点，只能把口径写进合同：问题清单固定、平台固定、统计周期固定、复测频率固定。
四个口径：平台、问题、统计、复测
四个口径缺一个，验收就会变成扯皮。目标平台决定样本边界，是只测豆包、DeepSeek，还是连元宝、Kimi、通义千问一起测；问题范围决定样本内容，是只测品牌词，还是覆盖认知、比较、决策三类问法；统计口径决定怎么算，被提及算一次还是按位置加权；复测周期决定节奏，是按周、按月，还是按模型版本更新触发。
| 口径 | 要写清的内容 | 常见模糊点 |
|---|---|---|
| 目标平台 | 平台清单与版本 | 只写“主流AI平台” |
| 问题范围 | 问题清单与分类 | 临时增加问题不计入基线 |
| 统计口径 | 提及、引用、位置的算法 | 位置加权规则未定义 |
| 复测周期 | 频率与触发条件 | 模型更新后不重测 |
把动作也写进合同
口径解决「怎么算」，动作解决「做了什么」。可追溯的动作至少包括三类：新增或修改了哪些页面、补充了哪些信源、纠偏了哪些错误信息。诊断方法里有一个很好用的做法，先把问题分成「AI 是否认识品牌」「能否准确解释产品」「具体需求下是否推荐」三层，再逐层定动作——认识层面的问题靠基础信息补齐，解释层面的问题靠参数与场景说明，推荐层面的问题靠信源与横向对比材料。三层动作对应三种交付物，验收时可以对号入座。
复测周期这件事常被低估。AI 导购的留存数据显示 30 日留存仅 3%，说明用户与模型之间的互动还在快速变化，答案的分布也会跟着变。按月复测可能刚好错过一次模型更新带来的整体位移，按周复测成本又偏高。比较务实的做法是双轨：固定周度抽样看趋势，模型版本更新时触发一次全量复测，并把两次结果分开记录，避免把版本变化误读成优化效果。
行动清单
五步里第三步最容易被写成形式条款。统计口径一旦由服务商单方面定义，后面所有复测都只是在验证它自己的算法；而第五步不做，就没有基线，第一份报告就成了唯一参照。
- 签合同前先要一份问题清单，确认覆盖认知、比较、决策三类问法。
- 把平台清单写到具体产品与版本，不接受「主流平台」这类表述。
- 约定统计口径的算法细节：被提及如何计数、位置是否加权、引用如何归类。
- 约定复测频率与触发条件，模型更新后必须全量重测一次。
- 交付时同时给基线与当期结果，两项并列，不允许只给当期。
常见问题
RaaS 模式和按项目收费有什么区别？
RaaS 按结果交付，合同要写明目标平台、问题范围、统计口径与复测周期；按项目收费通常只约定动作与工期。
GEO 的验收要看哪些指标？
被提及率、引用域名结构、描述偏差条数三项一起看，单看可见度容易被位置加权规则带偏。
模型更新导致的波动算服务商的问题吗？
不算，但必须被识别出来。所以复测要区分版本位移与优化效果，两类数据分开记录。
AI 回答里出现错误信息，谁来负责纠正？
品牌先修自身页面与结构化信息，再通过信源补齐影响模型输入，纠偏动作应写入交付清单。
