先给答案：有来源，不等于声明被完整支持

GEO 内容的证据审计，检查的不是页面末尾有没有一串链接，而是“这条声明想让读者相信什么”与“关联来源实际支持到哪里”是否一致。一个来源可以真实存在、页面也能打开，但它可能只解释一个状态码、一个平台规则或一段历史观察，不能顺便证明整句话里的收录、排名、流量、因果和 AI 引用。

本文把 2026 年 11 月 4 日冻结快照中的 183 条声明级映射作为总体，从 direct、context、inference、first-party 四种关系中各抽 3 条，合计 12 条做分层复核。结果是：8 条来源在本次环境中取得响应；其中 4 条能支持一个明确的窄范围判断，4 条虽然可访问但需要拆句或补来源，另有 4 条因本次核验环境网络超时而保持未知。这不是 183 条映射的准确率。

先记住四个状态

来源可访问、来源支持窄结论、复合声明需要拆分、当前环境无法复核，是四个不同状态。审计时不把“有 URL”直接变成“准确”，也不把“这次超时”直接变成“来源失效”。

这次抽样究竟检查了什么

11 月 4 日的原创研究只检查了摘要字符串与声明映射是否精确对应；它明确没有检查来源可达性、摘录准确性和语义支持。因此这篇文章是下一层检查，问题也要重新定义：已存在一条声明级映射时，来源能否在当前核验条件下支持声明中的某个明确部分？声明是否把多个需要不同证据的判断写在了一起？

项目本次口径不能推出什么
总体2026-11-04 快照中的 183 条映射记录。不能把总体直接当成 183 条都已做语义审计。
抽样四种 relation 各 3 条，按固定 SHA-256 顺序选取，共 12 条。不能把分层小样本当成总体准确率估计。
访问检查2026-11-06 由本次核验环境发起 GET，保存最终 URL、响应或超时。一次网络超时不等于全球来源失效。
语义检查对照来源摘录、定位、声明对象、时间、条件和结论强度。不能仅用关键词相似度判定事实正确。
公开材料审计 JSON保留选择规则、每条判断与限制；README与复算脚本可核对抽样。脚本只能复算抽样选择，不会自动判定语义支持。

抽样单位是“一条已有映射记录”，不是一条经过人工拆解的原子事实。一个 summary 或 claimText 可能仍然含有多个判断。因此本次把“窄范围支持”作为审计结果，而不是把整句话盖成“准确”。如果要得到更细的结果，下一轮要先拆分声明，再为每个原子判断单独建立记录。

三道检查：能打开、能支持、没有扩大

审计顺序很重要。先看访问状态，再看内容关系，最后看结论有没有越过来源范围。把三道检查合成一个开关，会让 404、超时、来源不相关和来源只支持部分条件都被混成“失败”或“通过”。

层次需要问的问题记录方式
可达性当前环境能否取得来源，最终 URL 是否发生跳转，是否需要登录？HTTP 状态、最终 URL、访问时间、超时或登录限制。
语义支持来源原文是否谈论同一个对象、动作、时间和指标？章节、段落或字段定位，以及支持的最小范围。
结论边界声明有没有从“已接收”扩大到“已收录”，从“相关”扩大到“导致”，从局部样本扩大到全站？把支持部分与待补部分拆开，保留限制。

例如 IndexNow 文档可以支持“HTTP 200 表示搜索引擎收到 URL”这一窄判断，但不能凭这一个响应给页面颁发“已经收录”的结论。MDN 对 429 的说明可以支持“请求过多时触发限流”，却没有讨论百度收录或 AI 引用。W3C PROV 说明来源信息可以帮助评估数据质量和可靠性，但没有替站点证明 AI 内部使用了哪一段内容。

12 条抽样的结果：缺口主要在声明范围

下表只汇总本轮样本。4 条被标为“窄范围支持”，表示来源与记录中的一个明确判断相符；4 条被标为“需要拆句”，表示来源可访问，但不能单独支撑声明里的所有要素；4 条被标为“当前环境无法复核”，暂不判断来源和结论。

判定数量含义处理动作
窄范围支持4来源可以支撑一个边界清楚的判断。保留来源定位，同时写清不支持的延伸。
需要拆句4来源能打开，但声明包含多个对象、条件或结果。拆成原子声明，分别匹配来源或改成未知。
当前环境无法复核4本次请求超时，没有取得来源页面。保留未知，换核验环境或恢复访问后重查。
样本合计12四个关系层各 3 条。不计算总体准确率，不替换原冻结快照。

这个结果最有用的地方不是 4、5、3 这三个数字，而是它提醒我们：声明级证据表如果只统计“是否有映射”，会漏掉声明过长和来源范围过窄的问题。证据系统需要同时保存映射存在、来源可达、支持范围和待核原因。

四个具体例子：同一个链接为什么不能覆盖整句话

例一：接口响应与搜索收录是两个状态

“IndexNow 返回 HTTP 200 或 202，最多说明 URL 通知已经被接口接收或接受处理；它不能单独证明页面已经抓取、建立索引、获得排名或进入 AI 答案。”这句话的前半段可以直接对照 IndexNow 文档，但后半段包含多个系统状态。审计结果把它标为“需要拆句”，不是因为来源错误，而是因为一个来源的证明范围没有自动覆盖整句话。

更稳妥的写法是拆成两条：第一条只描述接口响应；第二条说明“提交响应不等于后续索引或答案状态”，并分别给出对应系统的记录方法。随后保存提交时间、响应体和目标 URL，再去做搜索状态或 AI 观察，不能用接口日志代替后续核验。

例二：429 只说明本次请求受到限流

MDN 将 HTTP 429 定义为一段时间内请求过多，并说明服务端可能通过 Retry-After 告知等待时间。它支持“这次请求触发了限流”这一层。它不告诉我们请求者是不是百度蜘蛛，也不告诉搜索平台会不会收录页面。身份需要 DNS、IP 和平台公开规则等额外材料，索引需要另一套观察记录。

因此，日志审计表至少应该有“HTTP 状态”“User-Agent 候选”“身份核验”“索引状态”四列。四列都填了，不代表四列指向同一个事实；但只填一列，也不能把空白自动补成结论。

例三：来源溯源能提高可追查性，但不是因果证明

W3C PROV-Overview 介绍了实体、活动和参与者之间的来源关系，以及这些信息如何帮助评估数据质量、可靠性或可信度。它能支持“保留来源链有助于检查材料”的方法原则。它并没有说：只要某个访问带有来源字段，就能证明模型内部读取了某段内容，更没有证明来源访问带来了转化。

写 AI 流量归因时，应把可见来源、引荐访问、页面停留和转化分别记下来。时间先后可以作为观察线索，不能直接写成因果。要做因果判断，还需要预先定义指标、比较条件和替代解释，并且不能把模型不可见的内部过程写成已经观测到的事实。

例四：第一方页面能证明自己的记录，不代表外部效果

本次抽到的第一方记录中，站内版本管理页面能够证明 ZenLeak 已经公开了版本、变更摘要、声明级证据和复测条件；复测报告页面能够核对 28/28、14/14、73/73、13/73 的对象与分母。这些页面可以作为站内方法和历史快照的来源。

但它们不能据此证明页面已被某个搜索引擎收录、某个 AI 平台稳定引用或某次改版带来流量增长。第一方来源的价值在于把自己的行为和数据说清楚，边界也要一起公开。

哪些可以自动化，哪些必须人工看

证据审计适合做成半自动流程。自动化应该先把可重复的结构工作做稳，把真正需要语义判断的部分留给人。这样后台显示的“已检查”才不会让人误以为系统已经理解了每个结论。

自动完成人工复核为什么不能合并
检查 JSON 字段、重复 ID、关系枚举和日期格式。声明中的对象、条件、数字和结论强度是否与来源一致。字段合法不代表语义正确。
请求来源、记录状态码、最终 URL、跳转和超时。来源正文是否支持关联声明，以及支持到哪一部分。页面可达不代表内容相关。
按声明、关系、来源域名和状态汇总分母。是否因来源权威而放宽判断，是否把推断写成事实。统计准确不等于解释有效。
检测声明文本、来源摘录或版本哈希发生变化。变化是否需要重写结论、补来源或重新发布。变化提醒不等于变化原因。

当前快照专门记录了“网络超时”这一状态，防止程序把没有响应的来源写成 404 或“来源不存在”。正式系统还应区分 DNS 失败、TLS 失败、超时、登录墙、robots 限制和 HTTP 错误；这些状态的后续动作不同。

一套可以落地的证据审计流程

  1. 冻结总体。保存当前教程表、声明映射表和文件哈希，先确定本轮审计不回写哪个历史样本。
  2. 确定抽样层。按事实来源、编辑推断、第一方观察和背景资料分层；每层固定数量和选择规则。
  3. 拆分声明。圈出实体、动作、时间、条件、数字和因果词，把一句复合句拆成可单独检查的单元。
  4. 访问来源。记录核验时间、请求方式、User-Agent、HTTP 状态、最终 URL、访问失败原因和是否需要登录。
  5. 复制必要摘录。保存章节或字段位置，摘录要足够支持判断，但不要把整页内容当作证据定位。
  6. 判定支持范围。分别写“来源支持的部分”“没有被支持的部分”和“当前无法判断的部分”。
  7. 记录限制。说明日期、版本、样本、地区和适用平台；第一方来源加上“不能推出外部效果”的边界。
  8. 发布统计。同时公开样本数量、分母、状态数量、选择方法和审计未覆盖的范围。
  9. 安排复核。来源更新、页面实质修改、平台规则变化和来源连续不可达时，触发下一次检查。

这套流程和页面版本管理、复测报告、声明级证据库相连。它们各自解决版本、观察和来源关系，不应该再被压成一个“GEO 分数”。

指标怎么报，才不会让缺失消失

本次只报告样本状态，不报告总体“支持率”。如果未来扩大到 183 条，也要先把分母写清楚。推荐至少同时报告以下四项：

指标分母用途
来源取得响应比例计划核验的映射记录说明访问层完成度，不说明语义支持。
窄范围支持数量取得响应的记录说明有明确支持边界的记录数量。
需要拆句数量取得响应的记录暴露复合声明或来源范围不匹配。
当前环境无法复核数量计划核验的映射记录保留缺失原因，避免把不可访问当成否。

不建议把“部分支持”换算成 0.5 分后只显示平均分。平均分会掩盖哪些条件没有来源、哪些页面无法打开，也会让一次严重的范围扩大与多个简单字段通过互相抵消。需要汇总时，保留原始类别数量，并让审阅者可以打开逐条材料。

发现问题后，页面怎么修

问题修复动作重新检查
来源只支持一句话的一半拆分摘要和正文声明，分别关联来源；无法补齐的部分改为未知或方法判断。每条声明是否只有一个主要对象和明确范围。
来源能打开但不相关删除错误映射，寻找同对象、同时间、同指标的原始材料。来源摘录能否直接回答“为什么支持这句话”。
当前环境无法访问记录超时、登录或权限原因，改用有权限的核验环境或合法历史材料。不要因为恢复访问就沿用旧摘录，重新确认版本和定位。
第一方观察被写成外部规律加上对象、日期、样本、版本和限制，把“本站观察”放回原位置。结论是否越过样本与平台范围。
数字没有分母在同一段或表头写清样本范围、单位和未完成数量。读者能否从明细加总得到汇总。

修复证据关系时，不要为了让表格看起来更完整而给每条声明补同一个链接。重复来源可以是合理的，但必须说明它在每条声明中承担什么作用。链接数量增加而支持范围没有变，不能称为证据质量改善。

常见问题

来源返回 200，是否可以标记为“支持”？

不能。200 只说明当前请求取得了响应。还需要核对来源对象、时间、条件、数字和结论强度；页面可达性与语义支持是两列。

来源超时是不是就应该删除这条证据？

不应该立即删除。先记录核验环境、时间和失败原因。超时可能来自网络、DNS、临时服务故障或访问权限；它说明本轮无法复核，不直接说明历史摘录错误。

一条声明有两个来源，支持程度能加起来吗？

不能简单相加。两个来源可能分别支持对象和时间，也可能重复支持同一部分。逐条写清每个来源的贡献，再判断来源集合是否覆盖完整声明。

第一方材料是不是不可信？

第一方材料适合证明“这个站点在某个时间做了什么、记录了什么、公开了什么”。它不能自动证明外部平台效果。关键是同时公开原始材料、时间、版本、样本和限制。

审计完成后是不是就能说明 AI 会引用页面？

不能。审计提高的是内容和证据关系的可检查性。AI 是否抓取、采用、显示来源和准确引用，还要在固定平台、问题、环境和页面版本下单独观察。

发布前清单

  • 冻结总体文件、版本和抽样规则。
  • 按来源关系分层，公开样本量与选择方法。
  • 先记录可达性，再进行语义支持判断。
  • 拆出对象、动作、数字、时间、条件和因果关系。
  • 为每个判断保存来源 URL、最终 URL、章节、摘录与核验日期。
  • 把来源支持范围和不能外推的限制写在同一条记录里。
  • 单列 404、超时、登录墙、版本未知和不适用，不把它们都填成否。
  • 第一方材料标出对象、时间、样本和不能推出的外部效果。
  • 汇总时保留计划分母和缺失数量，避免只报告通过项。
  • 页面实质修改或来源变化后，按同一方法建立新快照。

本次结果的边界

12 条样本只能帮助我们发现审核方法和记录结构的问题，不能代表 183 条映射，更不能代表 ZenLeak 全站正文。4 条窄范围支持不是“正确率”，4 条需要拆句不是“错误率”，4 条网络超时也不是“来源失效率”。审计没有测量搜索收录、排名、访问、AI 提及、页面引用、引用准确或转化。

下一轮如果要扩大范围，应先把复合声明拆成原子记录，随后逐条检查来源的版本和原文定位，再决定是否汇总。比起尽快得到一个百分比，保留样本、失败原因和未知状态，更能让后来的复测与今天的结果真正可比。