89份芯片手册扔给AI，吐出来的不是摘要而是结构化知识库-LLM Wiki

一个真实的需求摆在那里：拿到了一批海思原厂 SDK 文档，164 份中文 PDF，分散在 hardware / software / reference 三个文件夹里。哪份讲了 DDR 参数配置？哪份写了安全启动？哪份提到传感器时钟寄存器 0x11018440？

没有索引。没有全文搜索。没有跨文件链接。

这不是一个"缺工具"的问题。这是 PDF 这种格式本身和"知识"之间的结构性矛盾 —— 而很多人还没意识到这个矛盾的严重性。

老规矩先看效果

先看输入和输出两端的对比。用一句话概括：89 份 PDF 丢进去，25 页结构化 Wiki 吐出来。

输入端：89 份原厂中文 PDF，分散在 3 个大类 10 个子目录中。随便打开一份 —— 30 页起步，表格和寄存器描述混排，关键参数埋在正文第七页第三段。想搜"DDR 时钟频率"只能靠操作系统自带的全文件搜索，还不支持中文分词。

输出端：一个 25 页的结构化 LLM Wiki。每一页有 YAML 元数据、标签、来源追踪、双向链接。搜"时钟配置"直接定位到 传感器时钟配置.md，里面不仅有寄存器地址 0x11018440，还标记了"掉电丢失，每次上电需重设"这条实战知识 —— 而这句话在原始 PDF 里只是某页正文的一个自然段，没有任何标记说它"重要"。

Wiki 目录全景 —— 6 个实体页 + 18 个概念页 + 1 个对比页，全部互相链接：

entities/
Hi3519DV500 芯片.md ← 双核 A55，NPU 2.5TOPS
Hi3516DV500 芯片.md ← 无 NPU 的降级版
鸿鸥派 HongOU PI.md ← 实际使用的开发板
OS04A10 图像传感器.md ← 4MP MIPI 传感器
ToolPlatform.md ← 海思官方烧录工具
SVP NPU 工具链.md ← 模型转换+量化+推理
concepts/
AI ISP 智能图像处理.md ← NPU 辅助 ISP 降噪
MPP 媒体处理流水线.md ← VI→VPSS→VENC→VO
BSP 编译系统.md ← 完整编译流水线（8394字）
交叉编译工具链.md ← aarch64-linux-gnu-gcc 10.3.0
DDR4 接口设计.md ← 走线规则/ODT/ZQ 校准
NPU AI 推理.md ← YOLOv8/HRNet/MOTR
传感器时钟配置.md ← 寄存器 0x11018440，掉电丢失
SDK 安装升级.md ← 原厂 SDK 目录结构
U-Boot 移植.md ← DDR参数/时钟/存储
安全启动与安全子系统.md ← Secure Boot 逐级签名
DDR 参数配置 U-Boot Table.md ← DDR 初始化参数生成
SVB 动态调压.md ← Core 电压 0.85~0.95V
外设驱动开发.md ← UART/SPI/I2C/GPIO/PWM/ETH
裸烧与非裸烧升级.md ← 量产 vs 在线升级对比
电源管理.md ← 多电压域+上下电时序
启动配置.md ← Boot ROM→SPL→U-Boot→Kernel
外设接口总览.md ← MIPI/USB/SPI/I2C/UART
RTSP 视频推流.md ← live0/live265/live264
硬件排除.md ← 12 类故障排查链
OpenCV 交叉编译与移植.md ← 海鸥派板端 OpenCV
comparisons/
Hi3519DV500 vs Hi3516DV500 对比.md ← 选型决策参考

Obsidian 里打开这个 vault，Graph View 里是 27 个节点和 100+ 条边组成的知识网络。每一条边都有来历 —— 点击任意 wikilink，能看到是从哪份 PDF 的哪一页提炼出来的。

这就是从"89 份死 PDF"到"活的知识网络"的完整转变。

问题的本质：PDF 是"材料"不是"知识"

你拿到一个 PDF，表面上你"有"一份文档。但你真的"有"里面的知识吗？

一个 PDF 文件包含什么？文本、表格、图片、页眉页脚、页码、水印。所有这些以视觉排版的方式混在一起。一段"DDR4 走线要求 50Ω 单端阻抗"可能分散在三页里 —— 第 1 页给参数表，第 2 页给 PCB 叠层建议，第 3 页给实际测量数据。

对 AI 来说，这不是"一本书"，而是"一叠按页码排列的视觉区块"。把 PDF 转成可检索的知识，至少需要解决三个问题：

提取层 —— 把像素和排版指令变成有结构的文本。这包括识别标题层级、提取表格数据、跳过页眉页脚和水印。如果 PDF 是扫描版（图片型），还得先跑 OCR。

理解层 —— 识别文本中的实体和概念。什么是一个值得单独建页的"东西"（芯片型号、工具名称），什么是一个值得单独建页的"概念"（SDK 安装流程、U-Boot 移植方法）。

关联层 —— 理解不同 PDF 之间的引用关系。两份 PDF 都提到了"安全启动"，但角度不同 —— 一份讲原理，一份讲配置步骤。这两份应该链接到同一页，而不是分别建两个"安全启动"页面。

现在对比一下：如果这 89 份文档是 Markdown 格式呢？

直接用 grep 就能搜、# 号就是标题层级、Obsidian 的 [[双向链接]] 可以直接复用、目录结构本身就是分类体系。导入 Markdown，AI 的 90% 工作是在"归纳和链接"。导入 PDF，AI 的 60% 工作是在"提取和结构恢复"。

这就是为什么 PDF 导入是一个独立的话题，而不是"导入 Markdown 加一步 PDF 转文字"那么简单。

第一步：文件分类 —— 不是照搬原厂目录

原厂 SDK 的文件结构是这样的：

加起来 164 份 PDF。如果直接把这 10 个子目录原封不动抄进 Wiki 的 raw/ 目录 —— 那只是换了个地方存 PDF，什么都没变。

文件分类的目的是"让后续检索更高效"，而不是"给来源拍个照"。

第一步是筛选：从 164 份里选出 89 份真正包含"可提炼知识"的。被排除的是什么？

单元测试报告里的 8 份 DDR eye diagram 测试报告 —— 那是数据，不是知识。MIPI TX 的 10 份 lane 测试报告 —— 这是验证记录，每次测试结果不同。pc-tools 下的 16 份工具说明里，有 10 份是安装向导和截图，信息密度极低。

筛选的标准只有一个：这份 PDF 里有没有"你以后会反复用到"的内容？ 有 → 保留。没有 → 不导入。

第二步是重分类：原厂的 01.software/board/BSP 和 01.software/board/MPP 中间夹了一个 board/ 层级，对检索毫无意义。扁平化为 01.software/BSP 和 01.software/MPP，路径从 4 层缩短到 3 层。

最终结果：

这样，当你想查"U-Boot 移植"时，路径很清晰：01.software/BSP/。

第二步：逐份"读"—— PDF 提取的三个技术坑

这是 PDF 导入和 Markdown 导入最大的技术区别。如果是 Markdown，直接 read_file() 就能拿到结构和内容。PDF 不一样 —— 用 pymupdf（fitz）提取文本只是第一步，后面还有三个坑等着你。

坑一：标题识别

海思的 PDF 文档里，一级标题是"加粗宋体 16pt 居中"，二级标题是"加粗宋体 14pt 左对齐"。这些字号信息在提取时能拿到，但不同 PDF 的模板不完全统一 —— A 文档用 16pt 加粗做章标题，B 文档用 18pt。

硬编码字号阈值行不通。实际做法是用文本块的视觉特征相对于文档内中位数的偏离程度来判断层级：字体大小相对于文档内中位数的偏离、是否加粗、前后间距、是否居中。同一个文档内部的一致性其实很高 —— 一旦识别出第一份标题的模式，同一文档内其余标题直接用同一套规则。跨文档才有不一致。

坑二：表格提取

海思的 PDF 大量使用表格 —— 管脚定义表、寄存器映射表、DDR 参数表。pymupdf 能提取表格为 Python list，但 PDF 里的合并单元格会导致列错位。

比如一个 4 列的管脚定义表，"备注"列在第 3 行合并了后两列。pymupdf 提取出来时，第 3 行变成 3 列，后面所有行的 4 列数据全部错位 —— 第 4 列的值跑到了第 5 个位子上（不存在），直接丢失。

解决办法是先按行提取文字位置，再按 X 坐标聚类分组。这是一种"从排版反推结构"的思路 —— 既然 PDF 不告诉我表格有几列，我就自己看每个文字块的 X 坐标分布。哪个 X 坐标上出现了密度峰值，那里大概率就是一列的左边界。虽然比直接读 HTML <table> 慢得多，但在没有结构标记的 PDF 里是唯一靠谱的方法。

坑三：页眉页脚污染

几乎每份海思 PDF 的每一页顶部都有"Hi3519DV500 硬件设计用户指南"，底部有"版权所有 © 海思半导体"。如果不去掉，AI 会把这段文字当成真实内容，反复出现在多个 chunk 里，严重干扰检索和相关度排序。

去页眉页脚的逻辑：找到每一页顶部和底部固定位置（Y 坐标 < 页面高度 10% 或 > 90%）的文本块，如果连续 N 页都出现编辑距离 < 阈值的相似文本，就标记为页眉/页脚并剔除。这需要一次"预扫描"—— 先把所有页的文字位置扫一遍，找到重复模式，再正式提取。

实际跑下来，这三个坑的处理代码加起来只有 200 行 Python，但缺了任何一步，后续的"概念提炼"质量就会大打折扣。

第三步：去重 —— 同样的概念出现在多份 PDF 里

89 份 PDF，每份 30-80 页，信息密度完全不同。同一个概念可能在 3-5 份 PDF 里反复出现。

举例：关于"安全启动"，至少出现了 5 次 ——

01.software/BSP/ 的《安全启动使用指南》有完整流程

00.hardware/chip/ 的《芯片 Datasheet》提到了 OTP 区域和密钥存储

02.reference/software/ 的《BSP FAQ》里写了一条"安全启动失败如何排查"

02.reference/hardware/ 的《硬件设计检查清单》提到 Boot 模式拨码开关

如果给每份 PDF 单独建一个"安全启动"页面，你会得到 4 个内容不完整但互相重复的页面。这不是知识库，这是噪音。

去重的核心逻辑：先按文件名和目录位置判断文档的主题倾向，再在提取内容中做"概念聚合"。

具体操作分三轮：

第一轮 —— 聚类发现。 对 89 份 PDF 分别提取摘要（每份 PDF 的前 3-5 页），用 TF-IDF 聚类找出所有被 2 份以上文档交叉提到的概念。

第二轮 —— 合并判断。 对每个候选概念，合并所有提到它的 PDF 片段，然后判断：建一个综合页面？还是拆成多个子页面？判断标准是"用户搜一次能不能看到完整答案"。能 → 一个页面。不能 → 说明概念太大，需要拆。

第三轮 —— 同义词匹配。 对已建页面做交叉验证 —— 新来的概念跟已有页面标题做同义词匹配。“启动验证” = “安全启动” → 合并。"镜像签名"和"安全启动"有关联但不相等 → 建新页，但加一条 wikilink 指过去。

以"安全启动"为例 —— 第一轮聚类发现 4 份 PDF 都涉及相关关键词。第二轮判断后决定建一个综合页面 安全启动与安全子系统.md，囊括原理、配置方法、常见问题和排查步骤。用户搜一次就能看到完整图景。第三轮的交叉验证确认了没有其他页面已经在讲同一个东西。

第四步：建页 —— 三种页面的归类决策

Wiki 里的每一页都属于三种类型之一：

Entity（实体） —— 它是一个"东西"。芯片型号、开发板型号、传感器型号、工具软件。特征是"你可以指着它说 ‘这是 XXX’"。

Concept（概念） —— 它是一种"理解"。编译流程、启动时序、走线规则。特征是"你解释给同事听需要 10 分钟"。

Comparison（对比） —— 它是两个东西的"区别"。特征是回答了"选 A 还是选 B"。

这 89 份 PDF 导入后产生了：

这里有一个关键决策：建页的门槛不是"它出现了"，而是"2 份来源以上，或是某份来源的核心主题"。

出现一次、不值一页的内容怎么处理？追加到已有页面的一段里，加个来源标注。

比如 02.reference/hardware/ 里的一份《散热设计建议》，只有 4 页。它不配建一个独立概念页。但里面提到"Hi3519DV500 满载 NPU+ISP 同时工作时功耗约 4.5W"这个数据值得保留。怎么处理？追加到已有的 电源管理.md 里，在前面加一句"根据原厂散热设计建议文档描述…"，文末用出处标记^[raw/docs/02.reference/hardware/散热设计建议.pdf]。

这就是 Wiki 的"增量更新"模式 —— 每份新来源不是必然建新页，而是找到它在知识网络里的位置，然后精准插入。

第五步：关联 —— 新页面怎么连入已有知识网

单页建得再好，没有双向链接就是孤岛。LLM Wiki 的硬性规则：每页至少 2 个出站链接，index.md 必须注册。

新页面的链接策略分三步：

第一步 —— 出站链接。 新概念引用哪些实体？用 [[wikilink]] 指过去。以 DDR 参数配置 U-Boot Table.md 为例 —— 它自然要链接到 [[Hi3519DV500 芯片]]、[[DDR4 接口设计]]、[[U-Boot 移植]]。三个出站链接，一次全搞定。

第二步 —— 反向链接。 建完新页面后，必须回头扫描已有页面 —— 有没有提到"U-Boot Table"但用的是纯文本而不是 wikilink？找到就改。不然后续 Obsidian 的 Graph View 里新节点没有入站链接，永远隐身。这是一步容易忘但极其关键的收尾工作。

第三步 —— index.md 注册。 每一页都要出现在 index.md 的对应分类下，附带一句话摘要。index 是所有查询的入口 —— 索引不全等于 wiki 残废。

一次 89 份 PDF 的导入，最终产生了：

10 个新建页面（3 entity + 7 concept）

4 个已有页面被更新（补充了新的内容来源）

大约 80-100 条 wikilink 被新建或更新

index.md 新增 10 行索引条目

整套操作如果靠人工做，每个 PDF 阅读 20 分钟、每页归纳 15 分钟、每条链接查找 5 分钟 —— 保守估计 60-80 小时。AI Agent 用 4-6 小时全流程跑通，而且 log.md 记录下了每一步操作，完全可追溯。

踩坑实录

坑一：PDF 加密 / 图片型 PDF

01.software/pc-tools 下有几份 PDF 是扫描版 —— 没有文字层，全是图片。pymupdf 提取出来是空字符串。这种 PDF 本质上是一堆 TIFF/JPG 的容器，需要先跑 OCR。那次导入里这类 PDF 被直接跳过，在 log 里标记为"无文字层，跳过"。

坑二：命名冲突

两份 PDF 都叫"快速入门指南"，但一份在 BSP 目录下（讲 SDK 安装），一份在 MPP 目录下（讲媒体处理），内容完全不同。如果按 PDF 文件名存 raw/，必定冲突。解决办法是用来源路径做前缀：BSP-快速入门指南.md vs MPP-快速入门指南.md。

坑三：术语混乱

同一份芯片，原厂在不同文档里叫过三种名字：Hi3519DV500、hi3519dv500、HI3519D。这不是错别字，是文档版本迭代不一致。如果让 AI 按字面匹配，它会以为这是三个不同的芯片，建三个实体页。解决办法是建一个"同义词表"：所有变体统一映射到 [[Hi3519DV500 芯片]]。

坑四：信息密度极度不均

BSP 目录下的编译指导手册 68 页，干货满满。pc-tools 下的 AQTools 使用说明只有 8 页，其中 6 页是截图。这两份 PDF 用同一套流程显然不合理 —— 后者不需要建页，追加一句话做来源标注就够了。判断标准：内容能支撑 200 字以上的独立体量 + 跟至少 2 个已有概念有交叉 → 建页。不到这个标准 → 追加到已有页面。

产物展示

导入完成后，Wiki 从 14 页扩展到 25 页。log.md 记录了完整链路：

## [2026-06-19] ingest | Hi3519DV500 原厂 SDK 文档批量收录
– 来源：Hi3519DV500R001C01SPC020
– 归档 raw/docs/：89 份中文 PDF，分 3 大类 10 个子目录
– 新建实体页 3：Hi3516DV500 芯片、ToolPlatform、SVP NPU 工具链
– 新建概念页 7：SDK安装升级、U-Boot移植、裸烧升级、外设驱动开发、
安全启动与安全子系统、DDR参数配置U-Boot Table、SVB动态调压
– 新建对比页 1：Hi3519DV500 vs Hi3516DV500
– 更新已有页 4：AI ISP、MPP流水线、NPU推理、启动配置
– 总页面数：14→25

最终 Wiki 结构（后续又加了硬件排除和 OpenCV 移植，达到 27 页）：

用 Obsidian 打开这个 Wiki，Graph View 展示的是一张真正的知识网 —— 27 个节点，100+ 条边。任意一个页面点进去，不仅能看到内容本身，还能看到来源（sources 字段指向 raw/ 下的 PDF），看到置信度（high/medium/low），看到跟其他页面的链接。

而这一切的原材料，只是 89 份原本"死"在那里的 PDF。

PDF 导入 vs 普通文本导入：本质区别一览

回到标题的问题 —— PDF 导入到底跟 Markdown/纯文本导入有什么不同？

文本文件导入的瓶颈在"写"：内容已经有了，结构在 MD 语法里，AI 要做的是归纳、链接、建页。这是"从结构化到更结构化"。

PDF 导入的瓶颈在"读"：你得先把它变成文本，再恢复它的结构，然后才能归纳。这是"从非结构化到结构化"。前两步 —— 提取和结构恢复 —— 占了整个工作量的 60% 以上，而且是纯文本导入完全不需要的步骤。

这个差距不在 AI 的能力，在输入的格式。 格式越结构化（JSON > YAML > Markdown > Word > PDF > 图片），AI 提取的成本越低，结果越准确。如果你能控制上游，尽量把文档存成 Markdown。如果上游就是 PDF（比如原厂 SDK 只给 PDF），那你需要的方法论就是这个六步流程：筛选 → 分类 → 提取 → 去重 → 建页 → 关联。

最后说一句实在话：知识管理最大的成本从来不是"存储"，而是"找不到"。 89 份 PDF 存在硬盘里，占不到 500MB。但每当你需要找一个参数、查一组寄存器、确认一条走线规则的时候，翻 89 份 PDF 花掉的时间，够你从头建 3 个 Wiki 了。

往期相关文章：

→ 我的嵌入式 AI 开发工具链 2026——用 AI Agent 辅助搭建海思 Hi3519DV500 完整编译环境

→ 5 天 0→1：用 LLM Wiki 建立嵌入式 Linux 知识体系

用 AI 把原料变成武器，而不是把 PDF 存进硬盘吃灰。

👇 长按识别关注，不错过每一篇干货

📌 版权所有 © AI的探索之旅 | 转载请联系作者