27 个页面，131 个 wikilinks，3.6 个平均出站链接，0 个真正意义上的孤岛页面。
这是我的嵌入式 Linux Wiki 运行一个月后的交叉引用数据。如果你打开 Obsidian Graph View，看到的不是 27 个散点，而是一张连通图------每个节点至少有两条线连着其他节点。
这不是自然形成的。在没有规则约束的情况下，一个 AI Agent 写出来的 Wiki 天然倾向于"每个页面自成一体"------Agent 把当前页面写得再完整，也不会主动去想你现有的其他页面跟它有什么关系。
交叉引用是 LLM Wiki 区别于传统笔记的最核心机制。 这篇文章拆解它的四个层面：引用策略、同步机制、孤岛检测、以及背后的设计哲学。
老规矩先看数据
用 Python 扫一遍 Wiki 目录，得到这张交叉引用热力图：
被引用最多的页面（入站链接 Top 5）：
| 页面 | 入站链接数 | 被谁链接（摘选） |
|---|---|---|
| Hi3519DV500 芯片 | 15 | 外设接口、鸿鸥派、BSP编译、AI ISP、NPU推理... |
| 鸿鸥派 HongOU PI | 10 | SDK安装、传感器时钟、RTSP推流、电源管理... |
| 硬件排除 | 10 | 传感器时钟、外设接口、电源管理、DDR4接口... |
| 启动配置 | 8 | 裸烧升级、ToolPlatform、BSP编译、U-Boot移植... |
| BSP 编译系统 | 8 | SDK安装、裸烧升级、交叉编译工具链... |
出站链接最多的页面：
| 页面 | 出站链接数 | 链向了谁 |
|---|---|---|
| 硬件排除 | 6 | 外设接口、电源管理、RTSP推流、DDR4接口... |
| 鸿鸥派 HongOU PI | 5 | 传感器时钟、Hi3519DV500、BSP编译系统... |
| AI ISP | 4 | NPU推理、Hi3519DV500、RTSP推流... |
孤岛页面： 27 个内容页面中，3 个入站链接为 0------但每页都有出站链接，说明是"没被引用"而不是"完全孤立"。
第一层：引用策略------什么时候链，链向谁
SCHEMA.md 定了一条硬规则：每页至少 2 个出站 wikilinks。
这看起来像形式主义------"为了有链接而加链接"。但实际操作中，这条规则倒逼 Agent 做了一个非常有价值的动作：在写完一个页面后，搜索同主题的已有页面。
Agent 写"NPU AI 推理"页面时，它必须找出至少 2 个已有页面来链接。它搜索了 tags:ai、tags:hisi、tags:soc，找到了 Hi3519DV500 芯片（NPU 所在平台）和 AI ISP（NPU 的上游处理链路），然后加上 \[Hi3519DV500 芯片] 和 \[AI ISP 智能图像处理]。
这个搜索动作产生了两种价值：
- 它发现了"NPU 推理的输出是 AI ISP 的输入"这个上下游关系------如果不搜索，这个关系不会被显式表达。
- 它让已有页面获得了回链------Hi3519DV500 芯片页面本来就有 14 个入站链接，新增一个后变成 15。
链接方向选择： 不是随便链两个页面凑数。Agent 的判断逻辑是：
- 优先链"上游/下游"关系------NPU → AI ISP（处理流水线），传感器时钟 → 鸿鸥派（硬件依赖）
- 其次链"用到同一个硬件平台"------任何 hisi tagged 页面都应该链 Hi3519DV500
- 最后链"概念相关"------两个页面共享 3 个以上标签
反面案例： 早期没有这条规则时，OpenCV 交叉编译页面写出来后没有任何出站链接。它是 Wiki 的一个孤岛------内容正确，但读者永远无法从其他页面导航到它。
第二层：同步机制------新页面建好了，老页面谁来回链
这是交叉引用最容易被忽略的环节。
Agent 建完一个新页面后，新页面链了 3 个已有页面。但反过来------那 3 个已有页面有没有链回新页面？ 如果没有，Graph View 里的连线是单向的，读者从已有页面出发永远找不到新页面。
我的同步策略：
批量 backlink 扫描。 每次 ingest 完成后，Agent 执行一步额外操作：扫描新页面涉及的主题词和标签，在已有页面中搜索相关关键词，找到后添加回链。
实例： 2026-06-23，Agent 新建了"硬件排除"页面（量产故障排查总纲）。页面本身链了 6 个已有页面：电源管理、DDR4接口、RTSP推流等。然后 Agent 执行 backlink 扫描------搜索 tags:debug、关键词"排查""故障""失败"------在已有页面中找到了 8 个位置需要加回链，包括传感器时钟配置（时钟异常是常见故障）、外设接口（接口不通的排查入口）等。
同步效果： 一次新建 → 6 个出站 + 8 个入站（回链）= 14 条新链接。不执行 backlink 同步就只有 6 条出站，入站永远为 0。
批量 ingest 场景下的同步： 如果一次加了 10 个新页面，Agent 不需要为每个新页面做一次独立扫描。它合并为一次全 Wiki 扫描------把所有新页面涉及的标签和关键词做去重，然后一次搜索所有已有页面。这个优化把扫描次数从 10 次降为 1 次。
第三层：孤岛检测------发现被遗忘的页面
SCHEMA.md 没有直接定义孤岛检测规则，但 lint 系统里有。
检测逻辑很简单： 扫描 Wiki 所有页面（排除 index/log/SCHEMA 三个元页面），统计每个页面的入站链接数。入站为 0 的就是孤岛。
我的 Wiki 孤岛报告：
三个内容页入站为 0：
- HI3519DV500_硬件原理分析与排查指南 --- 这是一篇硬件参考文档，内容偏独立
- Hi3519DV500_硬件设计知识提炼 --- 同上，内容提炼类
- 这两个页面的共同特点：内容高度自包含，不太需要其他页面引用它们
检测到孤岛不是"判死刑"------是"问问题"。Agent 发现孤岛后不会自动删除，而是标记出来让我判断：这个页面是应该被引用但没人引用（需要加回链）？还是天然独立（保留但标记）？
孤岛不是 bug------是信号。 一个 Wiki 有 0 个孤岛说明交叉引用过度------每页跟每页都链在一起，失去了信息分层。3/27 ≈ 11% 的孤岛率对于一个工程类 Wiki 来说是健康的------既保证了核心页面之间的连通，又允许了高度专业化的独立页面存在。
第四层：链接的"经济学"------不加链接比加错链接更糟
做交叉引用有一个反直觉的发现：不链比链错好。
举个例子：BSP 编译系统页面有 9 条踩坑记录，其中一条是关于"make 并行编译导致依赖乱序"。如果我让 Agent 在"make 并行编译"这个词上链到"DDR4 接口设计"（因为 DDR4 U-Boot Table 也用 make）------这个链接就是错的。DDR4 的 make 是 U-Boot 的 make，跟 BSP 的 make 不是同一个上下文。读者点过去发现文不对题，对整个 Wiki 的链接质量失去信任。
Agent 的链接质量策略：
- 出站链接不是越多越好。我的 Wiki 平均 3.6 个出站链接------够用，不过度。
- 链接优先用显式语义关系（BSP 编译→交叉编译工具链），回避弱关联（BSP 编译用到了 make→所有用 make 的页面）。
- 如果 Agent 找不到 2 个有足够语义关联的已有页面，它有两个选择：①标记该页为"pending backlinks"暂不强制，②只链 1 个最相关的。
设计哲学：交叉引用不是"做目录"
传统笔记的双向链接（Obsidian、Roam、Logseq）是用来做"关联笔记"的------看到 A 想到 B，就链一下。
LLM Wiki 的交叉引用目的完全不同------它是让 Agent 能"理解"知识网络的。
Agent 读 Wiki 时不是从头到尾逐页读，而是从 index 出发，按标签和入站链接的指引，找到相关页面，合成答案。如果入站链接稀疏，Agent 会漏掉关键页面。如果出站链接虚假，Agent 会被误导。
一个好的交叉引用网络 = 一张 Agent 能导航的语义地图。
验证方法：打开 Obsidian Graph View，看节点之间的连线。如果你能在 3 次点击内从任意一个页面到达任意另一个页面，交叉引用是成功的。如果某些节点要 5 步以上才能到达------你的 Wiki 有断层。
我的 Wiki 测试结果：从"OS04A10 图像传感器"到"安全启动"------2 步（OS04A10 → Hi3519DV500 → 启动配置 → 安全启动）。从"OpenCV 交叉编译"到"AI ISP"------3 步。全图直径不超过 4 步。
代码实现：Agent 的 backlink 同步算法
Agent 执行 backlink 同步的核心逻辑可以用以下伪代码描述：
输入： 新建页面的标签集合 T，正文关键词集合 K
输出： 需要加回链的已有页面列表
流程：全 Wiki 搜索 tags:T 的所有页面 → 全 Wiki 搜索正文含 K 的页面 → 合并去重 → 排除新页面自身 → 对每个候选页面，读取内容确认语义关联 → 通过审查的页面加 [[新页面]] 回链。
优化： 不是简单匹配关键词就加回链。Agent 读候选页面的上下文------如果只是偶然提到而不构成实质关联，不加。如果确实在讲同一主题，加。
这个算法在 27 页 Wiki 上的执行时间约 15 秒。在 500 页 Wiki 上预计 2 分钟------仍然可接受。关键优化是用 search_files 的 tags 模式做第一轮过滤，避免逐页读取全文。## 实战：一次 backlink 同步的全过程
让我用 2026-06-23 的真实操作演示一次完整的 backlink 同步。
场景： Agent 刚新建了"硬件排除"页面，链了 6 个已有页面。现在需要执行 backlink 扫描。
Agent 的操作步骤：
步骤一：提取新页面的关键信号。 Agent 从"硬件排除"页面的 frontmatter 提取 tags: debug, boot, peripheral, memory-hw, power，从正文提取关键术语：烧录失败、启动失败、功能异常、排查。
步骤二：全 Wiki 搜索。 Agent 用这些标签和术语在全 Wiki 搜索。结果：
- tags:boot → 匹配启动配置、U-Boot 移植、裸烧升级
- tags:power → 匹配电源管理、SVB 动态调压
- tags:peripheral → 匹配外设接口总览
- "启动失败" → 匹配 DDR 参数配置（DDR 参数错误导致启动失败）
- "排查" → 匹配传感器时钟配置（时钟异常排查）
步骤三：逐页审查并加回链。 不是搜索到就加------Agent 检查每页上下文，确认"硬件排除"确实和该页相关。8 个候选中有 8 个通过审查，全部加回链。
步骤四：记录到 log。 Agent 在 log.md 写入："更新现有页 8：电源管理、DDR4接口设计、启动配置、外设接口总览、RTSP视频推流、SVB动态调压、传感器时钟配置、DDR参数配置（加\[硬件排除]链接）"。
结果： "硬件排除"从一个刚建、入站为 0 的新页面，变成了入站 10 的核心页面------仅次于 Hi3519DV500 芯片（15）。
wikilinks 的三种链接模式
分析我这 27 页 Wiki 的 131 条链接，可以归纳出三种基本模式：
模式一：硬件依赖链。
Hi3519DV500 → OS04A10（传感器）→ 传感器时钟 → 鸿鸥派（开发板）。这种链是物理上的依赖关系：传感器挂在芯片上，芯片在开发板上。断了任何一环，读者就找不到"这个传感器配什么芯片"。
模式二：流水线链。
AI ISP → MPP 媒体处理 → NPU AI 推理 → RTSP 视频推流。这种链是数据流的方向：原始图像 → ISP 处理 → NPU 推理 → 编码推流。Wiki 的 Graph View 里能看到一条完整的数据流线。
模式三：知识聚类链。
硬件排除 ← 电源管理、DDR4接口、传感器时钟、外设接口、RTSP推流、SVB、DDR 参数配置、启动配置。这是 8 个独立的技术主题，但它们有一个共同点------出问题时都需要排查。硬件排除页面就像聚类中心，把 8 个分散的排障知识汇聚到一个入口。
三种模式分别解决不同问题：
- 硬件依赖链 → "这个组件在哪"
- 流水线链 → "数据怎么流"
- 知识聚类链 → "出问题时从哪开始"
设计交叉引用时，三种模式都应该出现在你的 Wiki 里。只有流水线链的 Wiki 像一本教材------线性、可预测、但缺乏深度。只有聚类链的 Wiki 像一个 FAQ------解决问题快，但看不到整体架构。
避免"链接膨胀"
131 条链接对 27 页 Wiki 来说看起来很充裕，但这里面有一个坑：链接膨胀。
当 Agent 不加选择地给每页加 5+ 个出站链接时，会发生什么？
- 读者打开任何一页，看到 5 个蓝链，不知道该点哪个
- Graph View 里密密麻麻全是线，失去视觉导航意义
- 入站链接失去区分度------每页都有 10+ 入站，你分不清哪个页面是真正的"核心"
我的对策：
每页出站链接上限 6 个。 SCHEMA.md 虽然没写这条，但 Agent 在实践中会自然收敛。如果一页需要链 7 个页面才能说清楚，那这页本身就太广了------应该拆分。
链接优先级排序。 Agent 在决定链哪个页面时，不是"能找到几个链几个"，而是按优先级：上游下游 > 同平台 > 同标签 > 概念相关。只有前两个优先级找不到时才往下走。
定期审查。 lint 系统里有一项检查：出站链接超过 6 个的页面标黄。目前我的 Wiki 全部在 6 以下。