做 GEO（生成式引擎优化）时，最常见的做法是"发文章、看有没有被提到"。但在真实项目里，"被提到"这个单一指标几乎无法支持任何判断——它说不清 AI 是"偶尔提到"还是"当成候选"，也说不清答案依据的是官网还是第三方内容。
本文分享一种在真实项目里用过的、可复核的分析方法：怎么把 AI 的原始问答记录，拆成品牌、实体、来源、候选四个可核验的层次。方法本身与具体客户无关，重点在"可复核"。
一、把"提到"拆成四层（判定表）
· 被提及 Mentioned：判定依据=答案正文出现你的品牌实体；数据来源=回答全文（正则+实体匹配）。
· 被引用 Cited：判定依据=答案把官网/页面列为来源；数据来源=正文内联引用标记（非来源面板）。
· 进入候选 Candidate：判定依据=在"推荐名单"语境下列出你；数据来源=回答结构 + 问题意图。
· 真实询盘 RFQ：判定依据=买家据此来问；数据来源=站内/私信/表单（非 AI 侧）。
关键纪律：正文引用 ≠ 来源面板出现。有的平台只在来源面板列了页面，正文没引用；混算会严重高估"引用"。
二、问答结构化字段（每条回答提取）
以下是一条回答我们实际提取的字段结构（示例，非某客户原文）：
· platform：平台（如 deepseek）
· asked_at：提问时间
· query_rewritten：平台自主改写的检索式
· answer_text：回答全文
· inline_citations：正文内联引用（anchor + url）
· source_panel：来源面板列出的 URL（与正文引用分开）
· brand_mentioned：是否提及品牌
· brand_entity_matched：命中的品牌/别名/官网域
· other_brands：同回答出现的其它公司
· answer_valid：该回答是否有效
说明：以上为示意结构，用于说明"结构化解析"要提取哪些字段，不代表已对任何指定客户执行的程序输出。
三、平台引用能力矩阵（决定能不能测"正文引用"）
· DeepSeek：正文引用可测（唯一精确配对）；来源面板有；引用数可统计。
· 豆包：正文引用不可测；来源面板有；只能看来源面板，不记 0。
· 百度 AI：正文引用不可测；来源面板部分；抽取稳定性需单独验证。
· 腾讯元宝：正文引用不可测；来源面板有；同上。
纪律：不可测的字段记 NOT_MEASURED，绝不写 0；不同平台的引用数不可横向比较。
四、品牌提及 vs 正确候选，别混为一谈
"品牌名出现"和"被列为推荐候选"是两回事。判断是否进入候选，要看回答的结构：AI 是在"列举可选供应商"的语境下提到你，还是仅在"某类方案"里顺带提一句。实操上按问题意图分层读——含"选谁/推荐/找供应商"语义的问题才是候选场景。
修正一个常见推断："引用少"只能说明"被当作事实来源"这一环弱，不能单凭引用数推断"一定不会进入推荐"——候选还取决于名单竞争与平台机制，需分层观测，不能一句话下因果结论。
五、自然波动与对照
AI 回答会漂移。我们做零干预对照：同一批问题、同一平台，不发布任何内容、间隔数天重采，仍有少数格子的提及/引用变化。所以任何"优化后提升"的结论，差值必须先超过噪声底才成立（噪声底需按平台/批次单独估计，不可跨平台套用）。
六、这套方法产出什么
· 一份可复算的基线（每个数字带分母、口径公开）；
· 一张分层诊断（实体/证据/结构/问题覆盖）；
· 一份有优先级的整改清单；
· 一套同口径复测方法。
本文方法提炼自真实项目的工程实践（匿名、脱敏），属技术方法记录；文中示例为匿名/示意结构，不含任何客户身份、联系方式、购买渠道或站外导流信息。
说明：文中方法与结构来自真实项目的匿名实践；示意代码/字段不代表已对指定客户执行的程序；零干预对照仅用于量化平台自然波动，不作为优化效果证据；不构成对任何第三方平台的官方评价。
