企业官网建设流程全解析

搞 llm_wiki 这个项目的起因挺朴素——我的书签、收藏夹和会议视频链接越来越多，但真正要用的时候一个都找不到。与其叫知识管理，不如叫知识失踪。直到我把 Obsidian 里零散的双链笔记逐渐做成了一套围绕大语言模型（LLM）的个人 wiki，才发现问题根本不在工具，而在结构和检索。这个项目的核心就一句话：把学习 LLM 过程中遇到的论文、框架、实战案例、经验教训，用 wiki 的方式沉淀下来，并且让 LLM 本身参与知识库的整理和检索。

如果你正在学大模型，或者已经在做 RAG、Agent 相关的开发，但总觉得知识碎成一地，那这篇文章值得看完。我不打算给你一套“标准答案”，而是分享我从零搭 llm_wiki 的真实过程，包括内容架构怎么定、Obsidian 怎么配、为什么后来非得上语义检索不可，以及踩过的几个坑。

1. 为什么“收藏夹式学习”注定走不远：知识库的定位比工具更重要

很多人的知识库失败，不是因为没用 Obsidian，也不是因为没用 Notion，而是从第一天起就没想清楚一个问题：这个库是给谁用的，解决什么问题。llm_wiki 从一开始就定死了两个目标：第一，让我能在 30 秒内找到“某个概念我当时是怎么理解的”；第二，让所有内容最终能串成一个体系，而不是一座孤岛。

1.1 从“收藏”到“理解”的四个阶段

我把自己过 LLM 相关资料的过程分成四层，llm_wiki 的内容组织也完全照这个逻辑来：

• 收集层：原始链接、论文 PDF、视频回放、Github 仓库。这一层只做一件事——暂存，不做整理。
• 拆解层：把一篇文章拆成“核心结论”“关键图”“我的疑问”“可复现的代码”四个字段。这个动作强制我读进去，而不是只点收藏。
• 关联层：通过双链把概念和概念连接起来，比如“Transformer”链接到“多头注意力”和“位置编码”，再把“位置编码”链接到“RoPE”和“ALiBi”。
• 输出层：把一个主题下的所有笔记串成一篇汇总文档，比如“LLM 推理优化全景图”，这其实就是 wiki 里的“索引页”。

绝大多数人停在第一层，然后抱怨工具不好用。llm_wiki 真正花时间的不是搭 Obsidian，而是强迫自己走到第二层和第三层。

1.2 为什么是 wiki 而不是“笔记”

笔记和 wiki 的区别在于：笔记是给自己看的流水账，wiki 是给别人（包括未来的自己）看的说明书。我见过太多人的“知识库”其实就是一堆带标题的文档堆在一起，没有任何交叉引用，也没有目录页，更谈不上结构。

wiki 的核心特征是“页面之间互相链接、可以从任何一个页面跳到相邻概念”。Obsidian 的双链机制天然适合这个场景，但它不会自动帮你把笔记变成 wiki——你必须主动去建“索引页”。我的做法是每个主题领域都有一个导航页，比如“推理优化导航页”下面列出所有相关笔记的链接和一句话摘要。这样整个知识库就不是树状目录，而是一张网。

1.3 给 wiki 定下边界

还有一个很容易被忽略的问题：知识库需要边界。llm_wiki 只覆盖“大语言模型本身”的内容，包括原理、训练、推理、微调、评估、Agent、RAG、多模态扩展，不包含 Python 语法教程，不包含 Linux 命令大全，不包含公司内部业务文档。一旦边界清晰，做内容归类的时候就再也不会纠结一篇笔记该放哪。

提示：项目叫 llm_wiki，目标读者是“想系统理解 LLM 的开发者”，而不是“所有对 AI 感兴趣的人”。这个定位决定了内容密度和深度，也决定了 wiki 的目录结构。

2. 用“学习路线”倒推内容架构：llm_wiki 的目录怎么设计才不散架

搭建 llm_wiki 的第一步不是打开 Obsidian 建文件夹，而是先画一张 LLM 知识地图。我当时把市面上的学习路线翻了个遍，结合自己带团队做 LLM 应用的经验，把整个领域拆成六个主干模块，然后让每个模块都对应一个 Obsidian 文件夹。

2.1 六模块内容骨架

这个架构的好处是：任何一篇新笔记都有一个“应该待的位置”，不会因为找不到地方而被随便丢进“未分类”。它也不是死板不变——学得越深，越需要往里加新模块，但主干骨架足够稳定，后面调整只是微调。

2.2 索引页是 wiki 的“导航台”

每个模块的文件夹里，第一份笔记永远是“导航页”，也就是_README.md或者_Index.md。我当时在包管理器里对_前缀的页面做了排序置顶，这样打开任何一个文件夹，第一眼看到的就是导航页，而不是一大堆散落的文件名。

导航页的内容很简单：本模块覆盖哪些子主题、每个子主题对应哪几篇笔记、哪些笔记是核心必读、哪些是选读扩展。这就叫“wiki 的感觉”——你永远知道下一步该往哪走。后面我还会在每个导航页里加一个“待补充列表”，记录我暂时没看懂但想搞清楚的概念，这样知识库会自然长出一个“TODO 分支”。

2.3 双链不等于乱链：链接节制的艺术

Obsidian 让人最容易上头的是双链，但双链滥用会让知识库变成一团乱麻。llm_wiki 里我给自己定了三条链接纪律：

• 每个页面最多 5 个核心出链，只链接直接相关的概念；
• 必须链接到“粒度匹配”的页面。比如在“RLHF”笔记里，链接到“奖励模型”而不是“机器学习总纲”；
• 关键是反向链接。每篇笔记底部我都会扫一眼“反向链接面板”，看看有哪些页面引用了它。如果一篇笔记没有任何反向链接，说明它是个孤儿页，需要被挂接到某个导航页上。

这样坚持半年之后，Obsidian 的图谱视图看起来非常舒服：有一团“银河系”而不是一个“毛线球”。但图谱只是结果，不是目标——目标是每个概念都能从两个以上入口被找到。

3. Obsidian 搭建实操：模板、命名规范与“卡片盒”工作流

理论说了很多，这章讲实际配置。我用的是 Obsidian 加 Git 同步的方案，所有 markdown 文件都放在一个仓库里，换电脑直接 clone 就能继续写。这个选择带来的安全感，是任何云笔记软件都给不了的。

3.1 命名规范决定检索效率

llm_wiki 里每篇笔记的命名遵循一个简单模式：主题-视角.md。比如：

• transformer-结构拆解.md
• tokenizer-从BPE到SentencePiece.md
• rag-向量检索优化实战.md
• llm-推理量化对比.md

对比一下“未命名笔记”、“新建文档 42”这种名字，你就知道命名的价值了。我用英文连字符加中文后缀的方式，既保证了文件名在 Git 和跨平台环境下的兼容性，又保留了中文语义的直观性。

3.2 三个模板覆盖 90% 的笔记场景

我不为每类笔记建一大堆花哨模板，只做三个核心模板：

概念卡模板：用于解释一个概念，比如“KV Cache”“LoRA”“困惑度”。

--- tags: [概念, 推理优化/训练] 来源: {原始链接} 相关: [[前一个概念]], [[后一个概念]] --- # 概念：{名称} 一句话定义： {用一句话说清楚这个概念} 详细解释： {展开说明，图文并茂} 为什么重要： {对理解 LLM 的意义} 我的理解： {用自己的话写一遍，避免抄原文}

论文/文章卡模板：用于拆解一篇外部资料。

--- tags: [论文/文章, 微调] 作者: 链接: --- # {标题} 核心问题： {这篇论文解决了什么问题} 方法： {怎么解决的} 关键结论： {实验结果 / 结论} 对 llm_wiki 的价值： {这篇资料补全了知识库的哪块拼图}

实战卡模板：用于记录代码实验和排错过程。

--- tags: [实战, RAG] 环境: vLLM 0.6, BGE-M3 --- # {实验名称} 目标： {我想验证什么} 方案： {用了什么工具和参数} 结果： {成功/失败，数据说话} 坑与心得： {值得记住的教训}

这几个模板看起来简单，但真正用起来之后，我发现“我的理解”和“坑与心得”这两个字段是最值钱的。它们强制我在收集资料之后做一次思考加工，而不是把 wiki 变成收藏夹的豪华版。

3.3 卡片盒工作流：输入、加工、输出三步走

Obsidian 只是一个工具，真正改变效率的是工作流。我是按“闪念卡片 → 文献卡片 → 永久卡片”的流程来写的：

• 闪念卡片：看到一段有价值的信息，随手用 3 分钟建一个临时笔记，只写“这是什么、来源、为什么值得记”。
• 文献卡片：每周花 1-2 小时，把闪念卡片结合原文做扩展，补全背景、原理、我的理解，挂上链接。
• 永久卡片：当一个主题下的文献卡片超过 5 张，我就把它们合并成一张导航页加若干子页，形成真正的 wiki 页面。

这个流程最大的作用是防止知识库变成“一次性垃圾桶”。每次往 wiki 里写东西，都在做一次整理和筛选，而不是简单搬运。

4. 让 LLM 参与 wiki 建设：从手动整理到半自动化知识管线

项目叫 llm_wiki，如果里面完全没有 LLM 参与，那就太讽刺了。我的目标是让大模型帮我把“原始资料”变成“结构化笔记”，再帮我把“结构化笔记”变成“可检索的知识库”。

4.1 自动摘要与内容补全：先粗后细的信息漏斗

我现在用 Claude 和国内的一些大模型 API 做资料预处理，流程是：

1. 把一篇 PDF 或网页正文丢给 LLM，让它输出“核心观点、关键数据、适用场景、潜在盲区”四个字段；
2. 把输出结果放进 wiki 的“草稿区”，人工审核一遍之后转成正式笔记；
3. 对已有笔记，定期用 LLM 做“补全检查”——找出缺少“为什么”的部分，并生成问题引导我去补齐。

这里有一个我踩过的坑：LLM 生成的笔记质量高得让人容易放松警惕，但幻觉永远存在。特别是技术细节、参数数值和论文标题，必须人工核对原文件才能进 wiki。后来我干脆在模板里加了一个字段叫“核验状态”，只有标记为“已核对”的笔记才会进入知识库的正式检索范围。

4.2 嵌入与语义检索：标签不够用的终极方案

内容超过几百篇之后，靠标签和文件名检索已经完全不够用了。我试过两三次搜索“推理优化”却找不到自己写过的 vLLM 笔记，因为当时我把它命名成“部署问题记录”了。这正是传统关键词检索的绝望之处。

解决方案是给 wiki 加一层语义检索。我的做法是：

• 用嵌入模型（比如 BGE-M3 系列）把每篇笔记的内容向量化；
• 向量存到一个本地向量数据库（我用的是 Chroma，部署简单，适合个人项目）；
• 写一个检索脚本，输入自然语言问题，返回最相关的 5-10 篇笔记；
• 继续用 LLM 做“检索增强生成”（RAG），把相关笔记内容拼接起来，生成一个综合答案。

这个方案本质上就是个小号 RAG 系统。不同的是，知识源不是一堆乱七八糟的 PDF，而是我已经整理好的 wiki 笔记——质量高了一截，检索出来的答案自然靠谱得多。

4.3 用 LLM 发现知识盲区：wiki 的反向输出

知识库不应该只是被动接受内容，它应该反过来逼我去学新东西。我定期会跑一个脚本：把 wiki 里所有“待补充列表”收集起来，用 LLM 生成一个“学习路线建议”，告诉我这几个待补充概念之间的依赖关系，以及哪几个掌握了之后能解锁一大片新知识。

比如当我发现“KV Cache”和“PagedAttention”都停留在“知道名字”的状态时，LLM 给出的建议是先从“KV Cache”入手，因为它是 PagedAttention 的前置概念。这个建议本身不惊艳，但问题在于——如果知识库没有记录这些盲区，我根本不会想到去补它们。

提示：与其追求“笔记数量”的增长，不如追求“死角”的减少。llm_wiki 最值钱的部分不是那些成熟的笔记，而是“待补充列表”——它们就是个人知识版图的盲区地图。

5. 从原理到实践的认知校准：几个容易踩的概念陷阱

做 llm_wiki 期间，我反复整理了几组概念，发现很多初学者都卡在同一个地方。这些内容我都单独建了页面，称为“辨析卡”，作用是避免概念的混淆。

5.1 预训练、微调、RLHF 到底谁负责什么

很多入门文章把这三个词混着讲，导致新手总觉得“微调”是万能的。我在 wiki 里画了一张类比图：预训练是“把人培养成大学生”，微调是“让大学生去某家公司实习”，RLHF 是“让实习生在真实反馈里学会为人处事”。

• 预训练负责“语言能力”——语法、知识、推理基础；
• 微调负责“行为对齐”——学会按用户指令输出；
• RLHF 负责“偏好对齐”——输出的东西更符合人类喜好。

理解这个层次，你才能明白为什么“模型笨”不一定需要微调，也许改改提示词，或者换个更大的基础模型更有效。这个认知在项目选型时极其重要。

5.2 训练端与推理端：两套完全不同的关注点

另一个我在 wiki 里反复强调的区别是“训练端”和“推理端”。这两个场景对硬件的需求、对框架的选择、对优化的目标都不一样：

很多场景下，同样的硬件做推理优化获得的速度提升，比重新训练一个微调模型获得的收益大得多。llm_wiki 里专门有一整个文件夹是“推理与部署”，因为这是从“技术玩家”走向“工程落地”的关键一环。

5.3 TextCNN、BERT 和 LLM 做意图识别：为什么不能盲目选 LLM

“文本分类”任务我整理过一组对比：传统 TextCNN、BERT 类模型、LLM 做意图识别，它们的适用边界差别很大。很多人做项目一上来就上大模型，其实可能是在用大炮打蚊子。

• TextCNN：速度快、部署成本低，适合样本量少、类别固定的简单短文本分类；
• BERT 系列：需要标注数据做微调，效果通常比 TextCNN 好一截，适合意图类别比较多、语义边界模糊的场景；
• LLM：适合零样本场景、类别经常变动、需要复杂推理才能理解意图的情况。

我的建议是：如果用户意图固定且数据标注成本可控，先别急着上 LLM。对中小团队来说，TextCNN 或 BERT 微调的性价比远高于调用大模型 API。这个判断在避免项目成本失控上非常关键。

6. 检索增强生成（RAG）接入 wiki 之后：从个人笔记到“第二大脑”

RAG 是 llm_wiki 让我收获最大的一个模块，因为它在改造个人知识管理这件事上几乎是量身定做。但很多人的 RAG 效果不好，不是模型不行，而是前面的数据质量不行。

6.1 RAG 的完整链路：切分、向量化、召回、重排、生成

我在 wiki 里把 RAG 拆成了五个环节，每个环节都单独建了一个页面：

1. 文档切分：按语义块而不是固定字数切，避免把一个完整段落切开导致检索语义丢失；
2. 向量化：用中文场景下效果好的嵌入模型（BGE-M3 或同类），把文本块变成向量；
3. 召回：用向量相似度召回 Top-K；
4. 重排：用 Rerank 模型（比如 BGE-Reranker）对召回结果重新排序，把最相关的排到前面；
5. 生成：把重排后的文本块和用户问题拼进提示词，交给 LLM 生成回答。

很多教程会跳过“重排”这一步。但实践中，向量召回 Top-K 的结果前几名经常只有一两条是真正有用的。加入重排模型之后，回答质量提升非常明显，强烈建议不要省。

6.2 接入 wiki 笔记的细节教训

我给 llm_wiki 做 RAG 时踩过很多次坑，说几个影响最大的：

教训一：不要直接向量化整篇笔记，先切块再入库。比如一篇“Transformer 结构拆解”笔记有 5000 字，整篇向量化之后，检索“什么是位置编码”返回的可能是整篇内容，生成器会被大量无关信息干扰。正确做法是按 Markdown 标题和段落切块，每块 300-500 字左右，保留来源链接。

教训二：把元数据一起存进去。每个文本块保留所属笔记的路径、标签、来源链接。这样生成答案时可以附上“参考来源”，方便回溯核对。很多 RAG 项目只存了向量和文本，丢了元数据，最后无法溯源，等于给自己埋雷。

教训三：定期重建索引。笔记改了内容之后，向量库不会自动更新。我开始时完全没意识到这个问题，导致 Retriever 老是返回旧版本笔记内容。后来加了一个简单方案：每次更新笔记时自动触发该块重新向量化入库。

6.3 让 wiki 具备“对话式检索”能力

语义检索做得差不多了，我给它套了一个极简的交互层：在终端里输入一个问题，脚本去向量库召回，然后调用 LLM 生成综合回答，并把参考笔记的链接列出来。

这个“对话式 wiki”本质上就是一个本地部署的 RAG 应用。实际体验下来，它的价值不在于回答得有多准确，而在于它改变了我查资料的方式——以前我需要先想起来“这篇笔记可能在哪个文件夹下”，再打开 Obsidian 去翻；现在直接输入问题，得到答案，答案下面带着原始笔记链接，极大地降低了“回访知识库”的心理门槛。

7. 走向 Agentic Wiki：让 LLM Agent 自动维护知识库

llm_wiki 最近半年在做一件更激进的事：让 Agent 自动维护知识库。如果说 RAG 是“被动检索”，那 Agentic Wiki 就是“主动整理”。这一步走下来，知识库才真正开始有“生命感”。

7.1 Agent 的四个核心能力设计

我设计的知识库 Agent 包含四个工具：

• 检索工具：从向量库召回相关笔记；
• 更新工具：往指定路径写入新卡片，或修改已有笔记；
• 链接工具：扫描某个新笔记，自动找出知识库中相关的旧笔记并添加双向链接；
• 导航工具：维护导航页，当新主题出现时把它挂到正确的模块下。

实现上并没有多高深——就是 Function Calling 加一个状态机。但真正把四个工具串起来之后，我可以直接把一篇长文链接丢给 Agent，它自己完成“提取要点 → 建卡片 → 挂链接 → 更新导航页”的过程，最后只给我一份结果摘要。

7.2 坑：全自动维护的边界在哪里

全自动维护一开始非常美好，直到有一天我发现 Agent 把两篇标题相似但内容方向相反的笔记链接到了一起，并且修改了导航页让结构看起来没什么问题。虽然改动不大，但让我警惕起来。

最终我采取的方案是“半自动”：Agent 只负责建议和草稿，任何写操作都走 Git 分支，合并之前必须人工 review。这个流程听起来没那么酷，但知识库的准确性比自动化程度更重要。维护知识库这件事，百分之五十的自动化已经能省掉大量重复劳动，剩下的百分之五十留给人工判断刚刚好。

7.3 一个有趣的效果：知识库开始“长出新想法”

Agent 定期扫描所有笔记的“待补充列表”和“我的理解”，把这些碎片汇总给 LLM 做联想。有时候它会把两个本来互相独立的概念结合起来，提出一个我没想到的延伸方向。这个概念还挺有意思——当知识积累到一定规模，结构化让连接变得容易，LLM 又能基于显式连接做组合，就很容易产生新的理解。

当然，这类输出我也只是当作“参考线索”，不会直接进正式笔记。但 wiki 的价值已经不只是“记录”，而是“激发”。

8. 一些给后来者的建议：如果你也想搭一个 llm_wiki

最后分享几条实操层面的建议。这些东西是我踩了半年坑才总结出来的，希望对打算动手搭个人 LLM 知识库的人有用。

8.1 先别折腾工具，先写一个月笔记

很多人搭知识库的第一步是研究 Obsidian 插件、装修主题、买 NAS、配同步，最后发现笔记没写几篇。我的建议是：先用最简单的纯文本 Markdown 写一个月笔记，了解自己的笔记习惯，再逐步加上双链、模板、语义检索。工具永远应该服务于工作流，而不是反过来。

8.2 每周固定“整理时间”，否则 wiki 会腐烂

知识库最大的敌人是“只进不出”。信息不断进入草稿区，但经年累月没有被整理成正式卡片，最后整个库变成一堆僵尸笔记。我给自己定的规矩是：每周两小时整理，只做三件事——把草稿转成正式笔记、给新笔记挂链接、更新导航页。这个节奏基本能保证知识库健康成长。

8.3 用 Git 做版本管理，容量焦虑会消失

Obsidian 的所有东西都是 Markdown 文件，天然适合 Git 管理。我把整个 llm_wiki 仓库放在 Git 远程，每次整理完提交一次，历史版本随时可回溯。想改结构就大胆改，反正随时可以回滚。向量库不在 Git 里，因为内容可以基于笔记随时重建。这种“内容与索引分离”的模式，让我彻底摆脱了“改坏了怎么办”的焦虑。

8.4 对初学者：从这六个模块的第一步开始就够了

如果你想复刻 llm_wiki，不要像我一样一开始就想做全套。先把“基础原理”模块做出来——每篇概念卡写 300 字就好，重要的是坚持。等写完十个概念卡之后再做下一个模块。知识库是长出来的，不是规划出来的。骨架可以提前定，但内容需要时间去填。

我在实际维护 llm_wiki 的过程中最大的体会是：真正让知识库产生价值的，不是知识库本身，而是整理和检索这个过程倒逼出来的思考。你每写一篇概念卡，都会被迫发现自己哪里有理解漏洞；你每做一次语义问答，都会发现哪篇笔记其实没写透。当你把“学什么”和“怎么记”这两件事统一起来，知识库就不再是负担，而是你思考的外置延伸。