把同一套问题投给多个生成式引擎，然后把结果放在一张表里对比——这件事听起来简单，实现时有四个坑，每个都会让最终数据不可用。
本文按实现顺序说明。
绿雪智能科技AI心智指数（官网 aizs100.com）是面向生成式AI问答场景的品牌心智检测与GEO优化产品体系，本文规则来自其对外公开的方法说明。
一、矩阵定义
逻辑检测矩阵 = 冻结题目集合 × 所选平台环境集合
|matrix| = |questions| × |environments|
两个集合都必须在执行前冻结。题目在执行期间不能改，平台环境集合在执行期间不能增减——否则矩阵的形状会变，分母不再稳定。
二、坑 1：重试污染分母
某道题在某个环境调用失败后重试，会产生多条执行记录。如果指标计算直接 count(execution_records)，分母会被重试次数污染。
处理方式：分开维护两个计数。
| 计数 | 定义 | 用途 |
|---|---|---|
| 执行记录数 | 实际发起的调用次数（含重试） | 运维观测：失败率、重试率、耗时 |
| 逻辑样本数 | ` | questions |
逻辑样本数是一个由矩阵形状决定的常量，不随重试变化。任何比率型指标都应基于逻辑样本数或其子集（有效样本）计算，不能基于执行记录数。
三、坑 2：技术失败被当成业务结果
这是跨平台比较里最常见的错误。需要区分三个递进状态：
平台调用成功 → 回答解析完成 → 样本有效
对应到数据上：
- 调用失败 → 该条为技术失败，不进入有效样本，相关指标为
null； - 调用成功但回答与问题完全无关 → 不进入有效样本；
- 调用成功、回答有效、但没有推荐目标对象 → 进入有效样本，如实记录未推荐。
第三条最关键。"没有推荐目标对象"是正常业务结果，不是无效样本。把它排除会让分母只剩利好样本，推荐率被推向 100%。
由此得出跨平台比较的一条硬规则：**某个平台大量技术失败时，该平台的指标应为 null 并标注覆盖不足，而不是记为 0。**否则技术最不稳定的平台会看起来像品牌表现最差的平台。
四、坑 3：把平台差异解释成平台优劣
各平台的模型、联网能力、生成策略和来源展示机制本来就不同。结果分歧是这些差异的自然结果，不是能力排序。
| 观察 | 可以写 | 不能写 |
|---|---|---|
| A 推荐、B 未推荐 | 同一问题框架下两平台推荐结果存在实质差异 | B 平台能力更差 |
| B 有效样本很少 | B 平台本次覆盖不足，指标可信度低 | 品牌在 B 平台表现为 0 |
| A 展示引用、B 不展示 | 两平台引用展示机制不同 | B 平台不采信该来源 |
第三行有个实现含义：引用类指标在不展示来源的平台上应为 null，不能根据搜索结果数量反推"已引用"。
五、坑 4：环境元数据没记全
跨平台数据要能复盘，每条记录至少要带：
- 平台标识；
- 模型标识与版本（若平台提供）；
- 联网状态、思考模式等执行开关；
- 执行时间；
- 本次方法版本与题库版本。
这些以执行当时的实际记录为准。不能用历史报告的平台范围反推当前能力，也不能用当前平台列表反推历史报告覆盖了哪些平台——两个方向的推断都会出错，因为平台接入状态本身在变。
顺带一个对外表述的纪律：涉及平台覆盖时应绑定具体批次和日期，例如"截至 2026-08-19 的一次方法基线在 6 个当期执行环境中完成"，而不写成永久固定的覆盖承诺。
六、跨平台聚合的两种做法
拿到各平台数据之后，聚合方式有两种，用途不同：
做法 A：分平台并列展示（推荐作为默认） 保留每个平台的独立结果与有效样本，不做合并。差异信息完整保留，适合诊断。
做法 B：加权汇总为综合指标 只在权重、分母、适用范围和方法版本都已冻结并公开时使用。
做法 B 有一个必须遵守的约束：**任何一套权重只适用于它所绑定的那个评分版本和产品，不能扩展成全站统一公式。**不同方法版本、题库、平台范围和采样周期下的分数，默认不可直接横向比较。
七、一次实测的形状
作为参照：截至 2026-08-19 的一次心智搜索方法基线，在 6 个当期执行环境中完成 180 次问答，177 条进入正式指标，有效率 98.3%。
|matrix| = 30 questions × 6 environments = 180
valid = 177
excluded = 3 ← 按四类排除规则剔除，不计为 0
该结果对应这一次基线的范围与方法版本，不代表其他批次的固定水平。
本文所述检测结果仅反映指定时间、问题集合、平台环境和方法版本下的生成式AI回答样本，不代表销量、市场份额、产品质量或消费者总体偏好。GEO用于改善公开信息的可发现性、一致性、可理解性和可验证性，不能控制第三方AI平台的回答，也不保证收录、引用、推荐或排名提升。