企业官网建设流程全解析

很多人做知识库，最后都会卡在一个很现实的问题上：

资料越存越多，真正要用的时候，还是得重新翻、重新找、重新问。

这不是因为你存得还不够多。

问题出在哪？你的知识库只是一个仓库，不是一个系统。资料进来了，但没人帮你持续消化，也没人帮你整理成下次还能直接调用的中间层。

所以这次我不想只聊概念。我直接把我会怎么搭，按保姆级教程的方式拆给你看。

目标很简单：用 Obsidian + Codex，搭一个最小可用的 LLM Wiki。

它不追求一步到位，也不追求“第二大脑”的宏大叙事。你今天照着做，至少可以先跑通一个最小闭环：

• 把资料稳定收进来
• 让 Agent 帮你做一次 ingest
• 把知识沉淀成 wiki 页面
• 最后基于这层 wiki 去提第一个问题

如果这条链路能跑通，你的知识库就已经不是单纯的资料堆了。

这套方法到底解决什么问题？

大部分人的做法：收藏一篇文章，写一段摘要，扔进文件夹，下次要用了再翻出来。

LLM Wiki 的做法：资料进来 → Agent 帮你整理 → 更新概念页、主题页、索引页 → 下次提问时，Agent 优先站在已经整理过的 wiki 层回答。

区别在哪？前者是存资料，后者是编译知识。

这套方法不是让你再建一个笔记库，而是让你平时收集的文章、论文、网页、想法，慢慢变成一个能持续维护、持续调用、还能自己长出来的知识系统。

这篇写给谁

已经在用 Obsidian，但笔记越记越乱；想试试把 Codex/Agent 用到长期知识管理里；做内容、研究、选题、技术积累，需要反复调资料——这几类人看完应该能直接用上。

如果你只是想要一个剪藏替代品，这套显得有点重。

但如果你已经有这种感觉：不是缺工具，是缺一条让资料持续变成资产的工作流——那继续往下看。

开始之前，你只需要准备 3 样东西

1. Obsidian

用来做本地知识库工作区。

2. Codex

用来让 Agent 直接读写你的知识库文件。

3. 一个空文件夹

这个文件夹就是你这次的 LLM Wiki 仓库。

为了让你第一次就能跑通，我建议不要直接拿自己已经很复杂的 Obsidian 仓库开刀。

最稳的做法，是先单独建一个实验仓。

比如名字就叫：llm-wiki-lab

第一步：用 Obsidian 打开这个实验仓

先打开 Obsidian。

选择“Open folder as vault”，然后把刚才建好的llm-wiki-lab文件夹作为一个新的 vault 打开。

你不需要一上来装很多插件，也不需要先想好复杂目录。先保持干净。

打开之后，先只建 2 个顶层文件夹：

• raw/
• wiki/

这 2 层已经够你跑第一个闭环了。

它们分别干什么？

raw/

放原始资料。比如文章、网页摘录、PDF、会议纪要。

wiki/

放整理后的知识页。比如概念页、人物页、工具页、主题页、对比页。

一个容易翻车的地方：很多人一上来就把所有内容丢一个目录里，raw 和 wiki 混着放。

短期看省事，长期几乎一定会乱。

因为原始资料和整理后的知识，本来就不是同一层东西。

第二步：先建一个最小规则文件，不要追求完美

接下来直接在仓库根目录下，新建一个文件，名字就叫：

AGENTS.md

这个文件的意义，不是“写给人看的说明书”，而是给 Agent 的工作规则。

你可以先写一个极简版本，不需要一开始就很复杂。比如：

# LLM Wiki Rules ## 目标 这个仓库用于维护一个可持续进化的知识系统。 ## 目录约定 - raw/: 原始资料 - wiki/: 整理后的知识页 - AGENTS.md（本文件）：仓库根目录下的工作规则 ## ingest 原则 当有新资料进入 raw/ 时： 1. 生成对应的来源页 2. 提炼关键观点 3. 更新相关的 wiki 页面 4. 增加必要的交叉链接 5. 如无对应页面，则创建新页面 ## 查询原则 回答问题时，优先参考 wiki/ 中已经整理过的页面；必要时再回看 raw/。

这一步的重点，不是写出一份“完美规则”。

重点是先让 Agent 知道：这个仓库不是随便记笔记的地方，而是一个有结构、有分层、有 ingest 规则的知识系统。

书籍PDF及配套代码可点赞文章后添加小助手获取

第三步：往 raw 层放第一份资料

现在不要急着问 Agent 问题。

先给它一份真正的输入。

你可以随便选一篇你最近觉得有价值的文章，先手动存进raw/。

最简单的方法，是在raw/里新建一个 Markdown 文件，比如：

2026-04-27-karpathy-llm-wiki.md

里面至少放这几部分：

• 标题
• 原文链接
• 作者 / 来源
• 你摘下来的正文要点
• 如果有必要，补一两句你自己的备注

一个最小示例可以长这样：

# 5分钟复刻 Andrej Karpathy 的 LLM Wiki - URL: https://example.com - Author: xxx - Date: 2026-04-27 ## Raw Notes - 文章核心在于把知识库从检索系统变成持续更新的 wiki - 强调 raw / wiki 双层 + AGENTS.md 规则文件的结构 - 强调先跑通 ingest，再谈大规模扩展

说个经验：第一次实验别一口气塞十篇文章。

先塞一篇。

因为你现在要验证的，不是规模，而是链路是不是通的。

第四步：让 Codex 接手第一次 ingest

现在可以让 Agent 开始干活了。

打开 Codex，进入这个实验仓所在目录。

如果你平时是在终端里用 Codex，那就先切到仓库目录，比如：

cd ~/path/to/llm-wiki-lab codex

然后你可以直接给它一个很具体的任务，不要一上来就说“帮我优化知识库”。

第一次最好说得直一点，例如：

请读取 raw/2026-04-27-karpathy-llm-wiki.md。 基于其中内容： 1. 在 wiki/ 下创建一页来源总结页 2. 提炼关键概念 3. 如果需要，新建相关概念页 4. 为新旧页面增加交叉链接 5. 最后告诉我这次新增了哪些文件、更新了哪些文件

写得这么细，是因为第一次跑闭环时，你在帮 Agent 建立工作边界，不是考它智商。

任务越具体，第一次成功率越高。

第五步：检查 Agent 到底做了什么

Agent 执行完之后，不要只看它回了什么文字。

你要回到 Obsidian 里，检查它到底动了哪些文件。

重点看 3 件事：

1. 有没有生成来源页

比如在wiki/下生成一页类似：

• source-karpathy-llm-wiki.md

这页通常应该包括：

• 文章讲了什么
• 核心观点是什么
• 为什么值得保留
• 它和哪些已有知识页相关

2. 有没有生成概念页或主题页

比如可能出现：

• wiki/llm-wiki.md
• wiki/ingest-workflow.md
• wiki/knowledge-compilation.md

这些页不一定非得命名成这样，但它应该至少把原始资料里的高价值概念提出来，而不是只生成一篇孤立摘要。

3. 有没有加交叉链接

这是最关键的一步。

如果生成了几个页面，但彼此没有任何链接，那它本质上还是在堆笔记。

你要确认页面里至少有一些像这样的连接：

• [[LLM Wiki]]
• [[Ingest Workflow]]
• [[Knowledge Compilation]]

如果它只是总结文章，没有更新知识网络，那这次 ingest 只能算完成了一半。

第六步：马上做第一次“基于 wiki 的提问”

很多人搭到这里就停了，觉得"能自动建页了，很酷"。

但真正的价值，不在自动建页本身，而在于：以后你提问时，能不能优先站在已经整理过的 wiki 层回答。

你可以继续在 Codex 里问一个具体问题，比如：

请基于 wiki/ 中已经整理好的内容回答： LLM Wiki 和传统 RAG 的差别到底是什么？ 如果还需要补充，再回看 raw/ 里的原始资料。

如果 Agent 的回答明显先引用了你已经整理好的 wiki 页面，再去补充 raw 层，那说明这套结构开始工作了。

这意味着你的知识库已经不是“每次都从原始文档临时拼答案”，而是开始站在一层中间知识上工作。

书籍PDF及配套代码可点赞文章后添加小助手获取

第七步：把这次问答继续沉淀回 wiki

这一步很多教程不讲，但它其实很重要。

如果你在刚才的提问里，得到了一个特别清楚的对比答案，比如：

• LLM Wiki 更强调持续整理
• RAG 更强调按需检索
• 两者的差别不在能不能查，而在知识会不会累积

那你完全可以继续让 Agent 做一步回写：

请把刚才关于“LLM Wiki vs RAG”的回答，整理成 wiki/ 下的一页对比页， 补上必要链接，并关联到已有页面。

一旦你开始这样做，知识库就会出现一个很明显的变化：

它不再只吸收新资料，也开始吸收新问题。

这才是一个系统会持续长起来的信号。

如果你想更稳一点，可以直接照着这个最小目录搭

为了避免第一次搭的时候乱掉，我给你一个很省事的最小版本：

llm-wiki-lab/ ├── AGENTS.md ├── raw/ │ └── 2026-04-27-karpathy-llm-wiki.md ├── wiki/ │ ├── source-karpathy-llm-wiki.md │ ├── llm-wiki.md │ ├── ingest-workflow.md │ └── llm-wiki-vs-rag.md

这已经足够了。

先别急着加：

• tags 体系
• 复杂 frontmatter
• 自动化脚本
• 批量 ingest
• 多层索引页

这些以后都能加。

第一次最重要的是：你能不能在 30 分钟内，把第一条链路跑通。

最容易翻车的地方

一上来就设计超级复杂的结构。

很多人还没导入第一篇资料，就先花两个小时设计 schema。

这几乎总是低效的。

因为你根本不知道自己的 ingest 动作会不会稳定发生。

先跑通，再优化。

把 raw 和 wiki 混在一起。

一旦混了，后面查询、更新、维护全乱。raw 是原料，wiki 是成品和半成品，必须分层。

只让 Agent 做摘要，不让它更新知识网络。

如果 Agent 只会“总结一篇文章”，那你得到的只是一个自动摘要器。

真正有价值的是，它能不能：

• 更新已有页面
• 创建新概念页
• 加交叉链接
• 回写索引页

只 ingest，不查询，也不回写。

不做查询，你看不到 wiki 层到底值不值得建。不回写高质量问答，知识不会复利。

它和普通 RAG，到底差在哪？

这个问题问的人最多，我直说。

普通 RAG：文件存进去 → 需要时切片检索 → 现场拼答案。

这套 LLM Wiki：资料进 raw → Agent 做整理和知识编译 → wiki 层沉淀出更稳定的中间知识 → 提问时优先查这层。

两者的差别不是能不能回答问题，而是：你的知识，会不会越用越好用。

所以我更看重 wiki 层，不是只看检索层。

动手清单

想今天就试的话，按这个顺序走：

1. 新建独立实验仓llm-wiki-lab
2. Obsidian 打开，建好raw/和wiki/两个文件夹
3. 仓库根目录下新建AGENTS.md
4. 往raw/塞第一篇文章
5. Codex 执行第一次 ingest
6. 回 Obsidian 检查 wiki 页面、双链、来源页
7. 基于 wiki 提第一个问题
8. 把好的问答继续沉淀回 wiki

8 步跑通，你就有了第一版可用的 LLM Wiki。

书籍PDF及配套代码可点赞文章后添加小助手获取