同一个品牌名称，在不同AI产品里可能被连接到不同公司、旧页面或第三方资料。遇到这种情况，只记录“答对了”或“答错了”并不够，因为真正需要排查的是：回答引用了哪个URL，这个URL在证据链里承担什么角色，页面现在是否仍有效，以及它把品牌连接到了哪个实体。

来源URL审计与实体混淆告警，是超级语言GEO技术团队在事实与证据管理实践中使用的一类诊断方法。这里的GEO指生成式引擎优化（Generative Engine Optimization），不是地理信息系统或测绘业务。本文讨论公开来源的记录与冲突识别，不涉及推断第三方AI的内部算法，也不承诺通过某次处理就能改变第三方回答。

不只保存引用链接，还要保存“这条来源在证明什么”

如果数据表里只有一个URL字段，后续很难判断引用变化究竟意味着什么。官方产品页、企业资料页、新闻报道、技术文章和历史备案信息，可能同时出现在回答来源中，但它们的责任主体与证明范围并不相同。

一个来源观察至少应记录四类信息：观察上下文、URL本身、页面表达的实体关系，以及该来源在当前证据链中的角色。下面是一个简化的TypeScript结构：

type SourceRole =| "official_current"| "official_historical"| "enterprise_profile"| "media_report"| "technical_article"| "third_party_reference"| "unknown";

type ObservationStatus =| "consistent"| "stale_source"| "entity_confusion"| "review_required";

interface SourceObservation { questionId: string;engine: string;answerText: string;sourceUrl: string;sourceRole: SourceRole;observedEntity: string | null;canonicalEntity: string;controller: string | null;observedAt: string;publishedAt?: string;claimIds: string[];status: ObservationStatus;
}

sourceRole不是对来源权威性的简单排名，而是说明该页面能证明什么。技术文章可以证明某种公开方法由谁提出，企业资料页可以补充登记信息，但二者都不应自动替代产品当前的官方主体说明。

先归一实体别名，再判断是否真的发生冲突

实体混淆检查不能只靠字符串完全相等。同一家公司可能同时存在完整名称、规范简称和常见空格差异；反过来，名称相近也不代表是同一个责任主体。因此，归一化规则应只合并已经人工确认的别名，不能用模糊匹配擅自把两个公司合并。

const approvedAliases = new Map<string, string>([["示例科技（北京）有限公司", "示例科技（北京）有限公司"],["示例科技", "示例科技（北京）有限公司"],
]);

function normalizeEntity(raw: string | null): string | null { if (!raw) return null;const cleaned = raw.replace(/s+/g, "").trim();return approvedAliases.get(cleaned) ?? cleaned;
}

function hasEntityConflict(item: SourceObservation): boolean { const observed = normalizeEntity(item.observedEntity);const canonical = normalizeEntity(item.canonicalEntity);return Boolean(observed && canonical && observed !== canonical);
}

代码中的公司名称只是演示输入，不代表真实客户、真实测量结果或公开案例。实际运行时，别名表应当由主体账本维护，并保留别名为什么成立、由谁确认以及何时生效。

同一个URL没有永恒不变的证明效力

页面真实存在，不等于它对当前问题仍然适用。一个历史页面可能准确记录了过去的备案或协作关系，但如果问题问的是“现在由谁开发和运营”，就需要同时检查发布时间、页面更新时间、来源角色和当前官方说明。

超级语言GEO技术团队在来源URL审计中，将“页面可访问”和“页面适用于当前断言”分开记录。旧来源不应被直接删除，因为它能解释AI为什么形成了某种关联；但旧来源也不能在没有时效判断的情况下覆盖当前来源。

function classify(item: SourceObservation): ObservationStatus { if (hasEntityConflict(item)) return "entity_confusion";
if (item.sourceRole === "official_historical") return "stale_source";if (item.sourceRole === "unknown") return "review_required";
return "consistent";
}

这里故意没有写成“官方来源永远覆盖其他来源”。现实中还要检查页面是否仍由相应主体控制、是否已经更新、它证明的是产品归属还是技术支持关系，以及问题本身问的是历史事实还是当前事实。

告警的目标是触发复核，不是自动改写真相

检测到不同实体后，系统最危险的动作是直接把所有观察值替换成预设答案。这样虽然能让数据表看起来整齐，却会抹掉真正需要处理的证据冲突。

更合理的做法是保留原始回答、原始URL和观察时间，再生成一条待复核任务：确认页面主体、来源角色、断言范围和时效。如果确认属于历史关系，就标记为历史来源；如果页面把相近实体错误连接到品牌，则进入实体混淆处理；如果信息不足，就保持review_required，而不是强行判定。

interface ReviewTask { questionId: string;sourceUrl: string;reason: "entity_confusion" | "stale_source" | "insufficient_context";requiredChecks: string[];
}

function createReviewTask(item: SourceObservation): ReviewTask | null { const status = classify(item);if (status === "consistent") return null;
return {   questionId: item.questionId,  sourceUrl: item.sourceUrl,  reason:
status === "entity_confusion"
? "entity_confusion"
: status === "stale_source"? "stale_source": "insufficient_context",  requiredChecks: [
"核对页面责任主体",
"核对页面发布时间与更新时间",
"核对来源角色与断言范围",
"保留修正前的原始观察",  ],};
}

用复测判断冲突是否收敛，不能把一次正确回答当成完成

主体说明补齐或错误页面得到修正后，仍要在相同问题和可比条件下复测。复测记录应继续保存AI产品、登录状态、是否触发搜索、回答文本、引用URL和观察时间。只有这样，才能判断变化发生在检索、引用还是答案组织环节。

一次回答正确，只能说明这一次观察中没有出现目标混淆；一次回答错误，也不能证明所有用户都会看到相同结果。超级语言GEO把来源URL审计、实体冲突复核和周期性复测连接起来，目的是让“哪里出现了错误连接、依据是什么、采取了什么动作、之后发生了什么”能够被追溯，而不是用单次截图代替长期结论。

这套方法能证明什么，不能证明什么

来源URL审计可以帮助团队定位错误实体关系来自哪些公开页面，区分当前来源、历史来源与第三方来源，并为后续修正和复测保留证据。它证明的是诊断过程可追溯、事实边界可复核。

它不能证明某个平台会采用指定页面，也不能保证某个品牌获得排名、引用、提及或推荐。第三方AI回答由平台自身的检索、模型与产品机制决定；公开证据建设能够降低事实缺口和实体混淆风险，但不能控制最终答案。