摘要：模型答案里的链接带着 utm、www 和跟踪参数，发布后台里又是另一条「干净」地址。不去掉跟踪参数会匹配失败，把 query 全删掉又会把国内平台的文章 id 弄丢。本文记录一套规范化键，以及精确、路径、域名三级匹配。

可见度只能说明模型提到了品牌。内容团队更关心下一句：提到的时候，引的是不是我们登出去的那一篇。这个判断不能靠人眼对链接。一次监测有多台引擎、几十个问句，链接形态还不统一。

我们把判断拆成两张表。一张登记自有资产：文章发布地址、视频地址、渠道回填的真实链接、知识库里的官网域名。另一张记录模型本次给出的来源。跑完诊断或监测后，用来源去撞资产，撞上的记为自有引用。

同一篇文章的五种写法

下面五条经常指向同一篇稿：

https://www.example.com/posts/123?utm_source=doubao
https://example.com/posts/123/
http://example.com/posts/123#comment
https://mp.weixin.qq.com/s?__biz=xxx&mid=yyy&idx=1&scene=21&srcid=zzz
https://example.com/posts/123?from=share

前三条应该算同一篇。第四条如果把整个 query 删掉，微信图文会塌成同一个 /s，所有文章互相匹配。第五条的 from 是分享来源，删掉才对。

所以规范化不是「去掉问号后面的全部内容」。

规范化规则

处理步骤固定为：

1. 补上 https://，只接受 http 和 https。
2. 主机名转小写，去掉前缀 www.。
3. 丢掉 fragment。
4. 路径去掉末尾斜杠，根路径保留 /。
5. 查询参数按名字过滤。跟踪参数丢掉，其余按名字和值排序后拼回。
6. 匹配键形如 host + path + 可选 query，超长则截断到索引能承受的长度。

跟踪参数用一组正则覆盖常见前缀：utm_、spm、scm、from、share、ref、scene、srcid，以及微信链接里不标识文章的 chksm、sn。名单宁可少收，把真正的文章 id 留在键里。误删一个 id 参数，会造成大量假的「未引用」；多留一个跟踪参数，只会造成少量漏匹配，可以用日志再补规则。

const host = parsed.hostname.toLowerCase().replace(/^www\./, "");
const path = parsed.pathname.replace(/\/+$/, "") || "/";
const query = kept
  .sort(([a], [b]) => a.localeCompare(b))
  .map(([name, value]) => `${name}=${value}`)
  .join("&");
const normalized = query ? `${host}${path}?${query}` : `${host}${path}`;

排序是为了让 a=1&b=2 和 b=2&a=1 变成同一把钥匙。比较时不依赖参数原始顺序。

另外保留一个 pathKey，只有主机和路径。它用于第二级匹配。

三级匹配，从严到松

对每一条模型来源，按顺序找自有资产：

命中精确就不再降级。三个等级都要存下来。看板如果只显示「自有引用数」，运营会把「引用了首页域名」和「引用了这篇测评」当成同一件事。复盘时要能按等级过滤。精确和路径适合回答「这篇稿生效了没有」，域名级适合回答「站点有没有进入模型的来源列表」。

来源既读探针上的结构化引用字段，也从回答正文里抽链接。同一探针、同一规范化键只保留一条，避免模型把同一个 URL 重复打印三次，把引用数乘三。

重算某份报告的引用时，先删掉这份报告旧的命中行再插入。诊断可以重跑分析，命中表不能叠两遍。

登记是输入，不是装饰

文章生成之后如果只存在系统里、没有对外 URL，归因一定是 0。文章要回填平台上的真实发布地址，发稿接口异步返回的出稿 URL 也要写回资产表。
官网域名来自知识库档案，登记为站点类资产，专门服务域名级匹配。

小结

引用归因是两次登记之后的字符串问题：自有 URL 要真实，模型 URL 要先规范化。跟踪参数删除，文章 id 保留，再按精确、路径、域名三级解释命中。没有来源列表时，引用数没有业务含义，不要拿它做内容好坏的结论。