同一个品牌名称，在不同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回答由平台自身的检索、模型与产品机制决定；公开证据建设能够降低事实缺口和实体混淆风险，但不能控制最终答案。
