让 AI 替你翻书LLM Wiki 知识管理实战指南作者科技界的一粒微尘一位工程师用 Obsidian AI Agent 搭建嵌入式 Linux 知识库的完整实践本文概览当知识从文档堆变成一张关联网络搜索就不再是唯一的入口。本文以鸿鸥派 Hi3519DV500 开发板项目为实例完整展示 LLM Wiki 的搭建思路、三层架构、三种使用方式以及与 RAG 互补配合的最佳实践。全文包含 3 张架构图解和 5 张实操截图。老规矩先看预览一、痛点工程师的知识困境每一个硬件工程师或嵌入式开发者都面对过同一个问题项目资料越来越多但真正想用的时候找不到。以鸿鸥派 Hi3519DV500 开发板项目为例一个典型的嵌入式项目会积累这些资料原厂资料SDK 开发指南、硬件设计手册、数据手册PDF 版本随便一份就几百页自建文档编译环境搭建记录、操作命令手册、问题排查日志学习笔记芯片架构分析、外设接口梳理、AI 推理参数速查工具与脚本烧录工具、驱动包、测试脚本这些资料分散在几十个目录中格式有 PDF、Word、Markdown、Excel甚至还有图片和压缩包。你需要查一个 RTSP 推流地址时可能要打开七八个文件才能找到。传统的解决方案有两种一种是「堆文件夹」—— 把所有资料按目录存好你需要什么自己去翻。结果往往是翻了一下午找到了三年前的版本发现参数已经改了。另一种是「用 RAG」—— 把所有文档扔给大模型每次问问题都重新搜索一遍。听起来很美好但每次问同样的问题都要消耗 Token而且模型不理解「这个参数从哪来的」。那么有没有第三种方案有就是LLM Wiki。二、什么是 LLM WikiLLM WikiLarge Language Model Wiki是 Andrej Karpathy 提出的一种知识管理理念。核心思想很简单把知识写下来而不是存起来。传统的知识库是「仓储式」的——把一堆文档丢进去需要时再翻出来。LLM Wiki 是「蒸馏式」的——让 AI Agent 把原始资料提炼成互相关联的知识页面形成一张知识网络。核心区别传统知识库存的是「文件」LLM Wiki 存的是「知识」。一张图说明它的三层架构图中可见三个层次底层 raw/ 存放原始文章和数据手册不可修改中间层 entities concepts 是 AI 蒸馏后的知识页面顶层 SCHEMA.md index.md log.md 控制规则。箭头方向代表数据流向——来源不可变知识不断生长。第一层 —— 原始来源raw/所有原始资料包括文章、论文、会议纪要、图片。这一层的原则是「不可变」——一旦摄入就不再修改只做追加。如果将来来源文件有更新通过 SHA256 哈希值比对来判断是否需要重新摄入。第二层 —— 蒸馏知识这是 Wiki 的核心。AI Agent 把第一层的原材料提炼成结构化的知识页面分为三种类型实体页entities/描述真实存在的事物比如Hi3519DV500 芯片、鸿鸥派 HongOU PI、OS04A10 图像传感器概念页concepts/描述抽象的知识主题比如NPU AI 推理、MPP 媒体处理流水线、RTSP 视频推流对比页comparisons/和查询归档queries/记录有价值的对比分析和查询结果每个页面都通过[[wikilinks]]双向链接在一起。打开任意一页都可以顺着链接跳到相关页面就像 Wikipedia 一样。第三层 —— 规则定义Schema控制整个 Wiki 的「宪法」。SCHEMA.md定义领域范围、命名规范、标签体系、页面创建阈值。index.md是内容目录。log.md记录所有操作历史。三、以鸿鸥派项目为例Wiki 长什么样我把鸿鸥派 Hi3519DV500 项目中的全部知识蒸馏成了一个嵌入式 Linux LLM Wiki包含14 个页面3 个实体页Hi3519DV500 芯片、鸿鸥派 HongOU PI、OS04A10 图像传感器11 个概念页交叉编译工具链、BSP 编译系统、NPU AI 推理、AI ISP 智能图像处理、MPP 媒体处理流水线、RTSP 视频推流、启动配置、电源管理、DDR4 接口设计、传感器时钟配置、外设接口总览这些页面覆盖了从硬件设计到软件开发的完整知识链。为了方便理解可以想象一个三层同心圆外圈 —— 芯片级知识Hi3519DV500 芯片是什么架构、OS04A10 摄像头怎么接、鸿鸥派开发板的硬件资源有哪些。这些是「物」的知识定义了你手上有哪些东西。中圈 —— 系统级知识交叉编译工具链怎么配、BSP 怎么编译、启动配置要烧写哪些分区。这些是「怎么搭环境」的知识决定了你能不能把代码跑起来。内圈 —— 应用级知识NPU 怎么跑 YOLOv8 模型、RTSP 怎么推流、AI ISP 怎么调参。这些是「怎么用」的知识直接驱动业务功能。Wiki 的美妙之处在于这三圈知识通过[[wikilinks]]互相链接从外到内或从内到外都可以顺着连接探索。比如你从「NPU AI 推理」出发可以往回找到「Hi3519DV500 芯片」了解算力规格往前找到「RTSP 视频推流」了解怎么看结果横向找到「AI ISP 智能图像处理」了解它和 NPU 推理的关系。左侧文件树清晰展示了 Wiki 的完整结构entities/下有 3 个实体芯片、开发板、传感器concepts/下有 11 个概念页面NPU 推理、RTSP 推流、电源管理等raw/目录存放原始来源。右侧是电源管理.md页面包含 YAML 头部、标签体系和结构化表格。Obsidian 中打开这个目录左侧文件树一目了然。entities/目录下是芯片、开发板、传感器三个实体concepts/目录下是 11 个概念页面。每一页都有完整的 YAML 头部信息创建日期、更新日期、类型、标签、来源引用和严谨的页面结构。最惊艳的是 Graph View——所有[[wikilinks]]连接在一起形成一张知识网络。你可以看到「Hi3519DV500 芯片」链接到「NPU AI 推理」后者又链接到「RTSP 视频推流」和「MPP 媒体处理流水线」。「启动配置」链接到「传感器时钟配置」和「电源管理」。每一页至少链接 2 个其他页面没有孤立的知识点。限于本文格式Graph View 的动态交互效果无法在静态截图中完整展示建议在 Obsidian 中亲自打开体验终端中直接cat index.md即可看到全部 14 个页面的完整目录。Entities 分类下列出了芯片、开发板、传感器三个实体Concepts 分类下列出了 11 个概念页面每个条目都有一句话摘要。如果你不喜欢图形界面终端里也能看# 查看总目录cat/home/ros2/obsidian/embedded-linux-wiki/index.md# 查看具体页面cat/home/ros2/obsidian/embedded-linux-wiki/concepts/NPU AI 推理.md# 查看最近操作记录cat/home/ros2/obsidian/embedded-linux-wiki/log.mdWiki 本质上就是一个目录下的 markdown 文件没有任何特殊的数据格式依赖。VSCode、vi、Notepad任何一个文本编辑器都能打开和修改。四、三种使用方式图中展示了 LLM Wiki 的三种使用方式左边「自己翻阅」适合系统学习中间「问我查」适合日常快速获取信息右边「扩展 Wiki」适合知识补充。底部是鸿鸥派项目中查询 YOLOv8 参数的完整流程示例。方式一自己翻阅这是最传统的方式——打开 Obsidian 或文本编辑器像看书一样浏览。适合你想系统学习某个知识领域的时候。比如你想了解 NPU 推理的完整流程可以打开index.md找到NPU AI 推理点击进入页面。看完后顺着底部的[[wikilinks]]点击RTSP 视频推流了解怎么看推理结果再点击MPP 媒体处理流水线了解视频数据是怎么从摄像头流向 NPU 的。这种链式阅读让你不知不觉间建立起完整的知识框架。方式二问我查这是最方便的方式——直接通过对话问 AIAI 去 Wiki 里找答案。比如我AI Agent正在通过飞书与工程师沟通。工程师问「NPU 跑 YOLOv8 的参数是多少」我只需要三步第一步打开index.md找到涉及 NPU 和 AI 推理的相关页面第二步打开NPU AI 推理页面找到如下内容YOLOv8:参数 8 8 0 3RTSP 地址 /live264HRNet:参数 a 0 3RTSP 地址 /live264MOTR:参数 b 0 0 3RTSP 地址 /live264第三步回复工程师「YOLOv8 的调用参数是 8 8 0 3推理结果通过 RTSP 在 live264 查看拉流命令是 ffplay -vf “vflip,hflip” rtsp://192.168.1.168/live264」整个过程不超过 30 秒工程师不需要自己打开任何一个文件。这就是 LLM Wiki 的核心优势——Agent 替你翻书你只管问。方式三扩展 Wiki当发现 Wiki 缺少某块知识时告诉 AI 来补充。比如工程师说「把 OpenCV 在海思平台上的交叉编译移植步骤加到 Wiki 里。」AI 会这样做第一步从提供的资料中提取关键信息OpenCV 版本、cmake 参数、依赖库、IVE 硬件加速适配第二步创建一个新的概念页OpenCV 交叉编译与移植.md包含完整的 YAML 头部和页面结构第三步建立[[wikilinks]]链接到现有页面——链接到交叉编译工具链因为要用到 aarch64-linux-gnu-gcc、链接到BSP 编译系统因为放在 BSP 编译流程中、链接到NPU AI 推理因为 OpenCV 处理后的数据可能送入 NPU第四步更新index.md在 concepts 分类下加上新页面链接第五步在log.md中追加操作记录这样下次任何人问「怎么在鸿鸥派上部署 OpenCV」Wiki 里已经有答案了。而且是结构化的、与其它知识关联的。五、LLM Wiki vs RAG有人会问既然已经有了 RAGRetrieval-Augmented Generation检索增强生成为什么还需要 LLM Wiki回答这个问题最好的方式是对比两张「考试卷」。左右对比 LLM Wiki 和传统 RAG 的原理、适合场景、优缺点。底部给出最佳实践两者互补不是互斥——RAG 做快速检索LLM Wiki 做深度理解。RAG 的模式是「开卷考试」每次遇到问题大模型都在海量文档中现场翻找答案。好处是灵活——加一份新文档重建索引就行。坏处是每次考试都翻书同样的知识点每次都要重新算一次 Token。LLM Wiki 的模式是「做笔记」平时把知识点整理成结构化的笔记考试时直接翻笔记。好处是高效——知识点提炼过一次就能反复用而且笔记之间有关联关系能看到知识的全貌。坏处是需要有人花时间做笔记。在实际项目中两者是互补的不是互斥的什么时候用 RAG查精确的参数值、命令、数字。比如「OS04A10 的 MIPI 数据通道数是多少」——这种问题在原始数据手册里就有精确答案RAG 检索出来直接给就行。什么时候用 LLM Wiki理解概念之间的关系、构建知识体系、长期积累。比如「NPU 推理和 AI ISP 有什么区别数据流是怎么走的」——这种问题需要把多个概念串联起来Wiki 的链接结构天然适合。鸿鸥派项目的最佳实践两套同时用。日常问题先用 LLM Wiki 回答速度快、无 Token 消耗如果 Wiki 里没有精确数据再 fallback 到 RAG 检索原始文档。这样做的好处是70% 的常见问题从 Wiki 直接回答零 Token 开销30% 的精确参数从 RAG 检索但 RAG 的索引覆盖了全量文档随着 Wiki 不断扩展那 30% 会逐渐变成 20%、10%六、如何开始使用 LLM Wiki如果你也想建立自己的 LLM Wiki这里是最简洁的入门路径第一步确定领域和范围Wiki 不是越大越好。一个 Wiki 最好只覆盖一个领域比如「嵌入式 Linux」、「深度视觉算法」或「机械设计」。范围一旦确定SCHEMA.md 里的标签体系、页面创建阈值和命名规范才有了依据。不要试图用一个 Wiki 装下所有知识——那是项目文档库的职责不是 Wiki 的。第二步准备原始资料把你手头所有相关的原始文档集中到raw/目录中。不需要整理格式PDF 数据手册、Markdown 笔记、网页摘录、PPT 都可以。AI Agent 会处理格式转换。关键原则是原始资料不可修改。如果发现资料有错不要在 raw/ 里改而是在 Wiki 页面中标注更正。这样将来重新摄入时可以比对 SHA256 哈希值来判断是否需要更新。第三步让 AI 摄入并蒸馏这是最关键的一步。AI 会按以下流程自动处理内容筛选读取所有原始资料根据 SCHEMA.md 的领域规则判断哪些内容值得提取实体识别识别核心实体芯片型号、开发板、传感器、工具和核心概念协议、架构、流程、设计模式页面创建创建结构化的 Wiki 页面每页包含 YAML 头部创建日期、标签、来源引用和结构化正文链接建立建立[[wikilinks]]交叉链接确保每页至少链接到 2 个相关页面索引更新更新 index.md内容目录和 log.md操作记录以鸿鸥派项目为例AI 从 17 个原始文档中提取了 3 个实体页和 11 个概念页共 14 页。整个过程花了不到 5 分钟。第四步日常使用和维护使用有三种方式翻阅、问答、扩展前面已经详细说了。维护的关键原则是每次有新的知识来源就摄入一次。好比给 Wiki 施肥让它不断生长。比如工程师发现了一个新的编译坑写了一份排查记录把这个文档扔给 AIAI 会自动判断是新建一个「踩坑记录」页面还是追加到现有页面中。另外定期运行 lint 检查也很重要。AI 可以自动检查有没有孤立的页面没有被任何其他页面链接、有没有断裂的 wikilinks链接到了不存在的页面、有没有页面超过 200 行需要拆分、有没有冲突的知识两个页面说法矛盾、有没有超过 90 天没更新的陈旧内容。这些检查让 Wiki 保持健康和活跃。七、总结LLM Wiki 不是一个产品而是一种思维方式。它从「存文件」转向「存知识」从「每次重新搜索」转向「一次提炼、反复使用」。对于嵌入式开发者来说项目周期长、资料种类多、知识折旧慢这种知识管理方式特别适合。你不需要记住每一个参数和命令——把知识交给 Wiki把精力留给创造。来看看 Wiki 中一页的完整内容。打开NPU AI 推理.md这一页包含了 YAML 头部类型、标签、来源引用、SVP 支持的模型表格YOLOv8/HRNet/MOTR、运行命令、模型调用参数、拉流查看方式等完整信息。底部通过[[wikilinks]]链接到相关页面。每一页都是这样结构化的前端元数据让机器可读正文让工程师可读底部的链接让知识可发现。这样一来无论是直接翻阅还是通过 AI 问答知识都以一致的格式呈现。Wiki 的知识是「一次提炼、百次复用」的。在 RAG 模式下每次问「NPU 算力是多少」都要重新搜索、重新生成答案浪费 Token。而在 Wiki 模式下这句话已经写在了Hi3519DV500 芯片.md页面里每次回答都是直接从 Wiki 读出不消耗任何 Token。日积月累这种差距非常可观。作者科技界的一粒微尘一位在嵌入式 Linux 和 AI 视觉领域摸爬滚打的工程师。关注「AI的探索之旅」一起探索技术与工程的交叉点。 文章中的示意图本文共包含 6 张示意图编号文件名内容图1wiki-architecture.pngLLM Wiki 三层架构图图2usage-flow.png三种使用方式与实例流程图3wiki-vs-rag.pngLLM Wiki 与 RAG 对比图图4obsidian-screenshot.jpgObsidian 文件树电源管理页面截图图5terminal-index.jpg终端 cat index.md 截图图6npu-page.jpg终端 cat NPU AI 推理.md 截图