这次实验下来，我对个人 LLM Wiki 的最小方案有了一个新判断：不一定要先搭 Obsidian。
之前我的思路一直是基于 Obsidian 的：raw / wiki / AGENTS.md / index.md / log.md。这套逻辑没问题，尤其适合本地知识库。但如果目标只是让一个普通用户先跑通完整链路，WorkBuddy + IMA 比 Obsidian 更轻。
IMA 只做一件事：稳定获取高质量公众号内容。WorkBuddy 做剩下的：把内容放进项目资产，做知识编译、查询、回写和治理。IMA 是数据入口，真正的 LLM Wiki 在 WorkBuddy 项目里长出来。
1. 为什么 IMA 只做入口
IMA 本身更像一个 RAG 知识库——文章放进去，查询时召回相关片段，再生成回答。方便，但离我想要的 LLM Wiki 还有距离。
LLM Wiki 的关键在"持续编译"。新文章进来之后，系统要更新来源页、概念页、主题页、对比页，还要维护索引和日志。下次提问时，模型优先站在已经整理过的 wiki 层回答，而不是每次从原文片段里临时拼答案。
所以 IMA 在这里解决的是一个很现实的问题：公众号好文章怎么稳定收集。公众号内容在移动端阅读频率很高，手动导入 Obsidian 路径太长。先收藏进 IMA，再由 WorkBuddy 同步到项目资产，是目前更顺的路径。
2. WorkBuddy 项目才是主体
这套方案跑在 WorkBuddy 的"项目"概念上。
一个项目下面有动态、计划、任务、资产。当前这套 LLM Wiki 主要用任务和资产。动态和计划可以留给后续团队协作，第一版不用碰。
在 WorkBuddy 新建一个项目，比如 llm-wiki，这就是你的云端知识库工作区。
项目里的"指令"相当于以前 Obsidian 方案里的 AGENTS.md，决定 WorkBuddy 在回答、编译、查询、回写时遵守什么规则。
3. 项目指令这样写
新建项目时把下面这段放进"指令"，按自己需求调整：
markdown# LLM Wiki 工作规则
## 角色
你是当前项目资产的知识编译器。请把 raw/ 中的原始资料，增量维护为 wiki/ 中可复用、可链接、可追溯的结构化知识。
## 目录
- raw/: 原始资料，只读为主
- wiki/sources/: 来源页
- wiki/concepts/: 概念页
- wiki/topics/: 主题页
- wiki/comparisons/: 对比页
- projects/: 当前项目
- workflows/: 工作流程
- index.md: 全局索引
- log.md: 操作日志
## ingest
1. 当前项目资产先读 index.md。
2. 再读 raw/ 新资料。
3. 创建或更新 sources / concepts / topics / comparisons。
4. 优先更新旧页面，避免重复建页。
5. 补充 wikilinks。
6. 更新 index.md 和 log.md。
## 查询
回答问题时，先读当前项目资产里的 index.md，再读相关 wiki 页面。wiki 不够时再回看 raw。形成新判断时，询问是否写回。技能选项里一定要选 IMA，后面要同步 IMA 里已经收藏的文章。专家和连接器可以先不选，除非你的流程确实需要。
4. 让 WorkBuddy 自动创建目录
项目指令写好后，不需要手动建目录。在项目对话框里输入：
text按照项目指令，在当前项目资产下，生成需要的目录结构。WorkBuddy 会读取项目指令，在项目资产根目录下创建 raw/、wiki/、projects/、workflows/、index.md、log.md 等结构。
检查一下资产目录，尤其确认 raw/ 和 wiki/ 有没有创建成功。后面所有同步和编译都依赖这两层。
5. 用自动化同步 IMA 数据
在 WorkBuddy 里创建一个自动化任务，调用 IMA 技能。这里需要你的 IMA 密钥，按引导操作即可。
自动化任务这样写：
text把 IMA 里"AI行业前沿"知识库，今天导入的文章，同步到 WorkBuddy "llm-wiki"项目资产的 /raw 目录下，保留标题、来源、平台、采集时间。不要写入 wiki，同步后更新 log.md。提示词里要明确引用 IMA 技能，写清楚 IMA 知识库名称和 WorkBuddy 项目名称。
第一次建议手动测试。确认 WorkBuddy 能从 IMA 指定知识库里读取文章，并在项目资产 /raw 下创建文件。测试通过后，再开每日自动同步。
第一次调用 IMA 技能时需要传入 IMA 密钥：
同步结果：
6. 编译 raw 里的新增资料
raw 里有资料后，就可以做第一次编译了。
别写成"帮我整理一下知识库"，太虚。直接这样：
text编译 raw 中今天新增的资料。执行前先列出计划：读取哪些 raw 文件，可能创建哪些 wiki 页面，可能更新哪些旧页面，是否更新 index.md 和 log.md。等我确认后再执行。计划阶段输出：
确认计划后再让它执行：
编译完成后，到项目资产的 wiki/ 下看结果。重点看三件事：有没有 sources 来源页，有没有 concepts / topics / comparisons，index.md 和 log.md 有没有更新。如果只是生成了几篇摘要，还不够——真正的 LLM Wiki 要开始形成结构，页面之间最好有 wikilinks。
7. 对知识库提问
后面可以直接在这个项目里提问。例如：
text基于当前项目资产里的 wiki 内容，解释一下 LLM Wiki 和传统 RAG 的区别。请先读 index.md，再读相关 wiki 页面；wiki 不够时再回看 raw。回答后列出依据了哪些页面。我验证过，WorkBuddy 的回答路径会按项目指令走：先看 index.md，再找相关 wiki 页面，不够再回 raw。项目指令不是摆设，确实能约束回答路径。
如果回答里出现了新的判断，可以继续让它写回：
text请把刚才的回答整理成 wiki/comparisons/LLM-Wiki-vs-RAG.md，并更新相关 topic。写回前先列出将修改或新增的资产。有回写，知识库才会越用越厚。
8. 用定时任务治理知识库
知识库只进不管，很快会乱。再创建一个定时任务做健康检查：
text检查项目资产下，wiki/ 是否有孤立页面、重复页面、断裂链接，index.md 是否过旧，sources 是否缺少来源信息，log.md 是否完整。
生成治理报告到 projects/knowledge-health/，只提出建议，不自动删除或合并文件。治理任务只给建议，不要自动删除或合并。知识库是长期资产，清理动作最好经过确认。
9. 用 projects 接真实工作
知识库不能只停在 raw 和 wiki。比如你要写一篇文章，直接在项目资产 /projects 下建一个项目页：
在项目资产 /projects 下创建一个项目文件，标题为：WorkBuddy LLM Wiki。
内容包括：
## 目标
写一篇公众号干货教程。
## 必须说清楚
- 目录结构
- index.md
- 资料采集
- WorkBuddy ingest
- 查询和回写
- 定时治理
## 相关页面
- LLM Wiki
- WorkBuddy之后写文章、做选题、整理资料，都可以围绕这个 project 文件展开。这一步的价值是把知识库接进真实任务，否则它只是一个会回答问题的资料库。
10. 适合哪些场景
自媒体最对路。选题、热点、竞品文章、读者反馈、历史爆文，先进 IMA，再同步到 WorkBuddy 的 raw，定期编译到 wiki。每篇文章建一个 project，发布后把标题、阅读量、留言反馈写回。时间一长，它会越来越了解你的栏目、选题边界和标题偏好。
日常办公也适用。每个客户或项目建一个 project。会议纪要、政策通知、公众号文章、项目资料，都可以进 raw。决策写入 wiki，行动项写入 log。每天早上让 WorkBuddy 读取项目页和昨天 log，生成 morning brief；周五再生成周报。这类场景里，AI 的核心价值是工作状态不断线。
11. 几个注意点
这套方案本质上是云端 LLM Wiki。
WorkBuddy 的项目资产保存在云端，处理时会先下载到本地，处理完再上传。文件多的时候实际速度会慢一点，但好处也很直接：不用先折腾本地 Obsidian，直接用 WorkBuddy 项目能力就能跑起来。
项目资产可以下载。下载后可以直接导入 Obsidian，里面已经带有双链。这意味着 WorkBuddy + IMA 可以先作为云端方案，后面再迁移到 Obsidian 做本地归档和图谱展示。如果你想做 WorkBuddy + Obsidian 的本地笔记方案，也完全可行——底层思想一样，只是把 WorkBuddy 项目资产换成 Obsidian vault，把项目指令换成 AGENTS.md。
我现在把路线分成两种：
textWorkBuddy + IMA：云端最小方案，门槛低，适合先跑通。
WorkBuddy + IMA + Obsidian：增强方案，适合本地归档、双链图谱和长期迁移。最后
这次实验让我不再把 Obsidian 当成必须入口。
真正的最小 LLM Wiki，核心是这条链路能不能跑通：
IMA 解决公众号内容的稳定输入。WorkBuddy 解决项目、资产、编译、查询、回写和治理。这已经足够搭一个最小可用的个人 LLM Wiki。
Obsidian 仍然有价值，但更适合做增强层。先用 WorkBuddy + IMA 跑通，再决定要不要接 Obsidian，反而更稳。
我是「超级猛」，长期折腾AI编程、Agent和自动化工作流。写Claude Code、Codex、Hermes这些工具的实战笔记，也聊AI怎么改变开发和内容生产的真实逻辑。