我为什么把知识库升级到 LLM Wiki V2我之前搭过一版 AI 知识库。第一版能用但有个问题资料越多越像一个“看起来很勤奋的垃圾堆”。文章、项目、代码仓库、日报、截图全都在里面真要找结论时还是要人一点点翻。后来我把它升级成 LLM Wiki V2。它不是换一套目录名而是换了一种思路知识库不是给人摆放文件的仓库而是给 AI 和人一起复用上下文的系统。V1 的问题资料存了但不一定用得上我当时已经积累了不少内容。文章、项目记录、工具笔记、Agent 配置、运维日志各种东西都有。问题也很明显原始资料和结论混在一起有些内容已经过期但还排在很显眼的位置AI 读到旧信息时不知道该不该信目录越分越细最后自己也不想翻。最尴尬的是我明明“存了”下次做事却还是要重新解释一遍背景。这就说明知识库没有真正进入工作流。V2 的核心把原始资料和可复用结论分开我现在更认同一个简单分层raw原始资料尽量保留现场wiki整理后的结论要求能复用、能回查projects项目上下文、决策和交接content文章、选题、脚本和发布记录ops运维、故障和变更archive历史内容不再当成当前事实。这里最重要的不是目录名字而是边界。原始资料可以乱一点因为它负责保真wiki 必须克制因为它会被 AI 当成参考archive 要明确降级避免旧结论继续误导新任务。这也是我后来把 OpenClaw 旧目录当成历史来源而不是继续写新知识的原因。它有参考价值但不能和当前 NAS 知识库主线混在一起。AI 编译知识不是让它随便总结V2 里我最常用的动作是让 AI 把新资料编译成可复用的知识。但这里有个坑不能只说“帮我总结一下”。我会要求它做几件事先说明资料来源区分事实、判断和待验证内容给结论加时间和可信度写入对应目录保留原始资料链接方便回查。这样做之后知识库才不会变成一堆漂亮但不可追溯的总结。对我来说AI 编译的价值不是“省一篇笔记”而是让下次 Agent 能接着上次的上下文继续干活。搜索比完美分类更重要我以前很执着目录结构。后来发现目录只能解决“我知道它在哪一类”的问题。真正工作时更多情况是我只记得一个模糊片段某次 Agent 崩了、某篇文章讲过排版、某个项目里写过权限边界。这时语义搜索比目录更有用。所以 V2 的重点不是把文件夹分到极致而是让资料能被搜到、能被 AI 读懂、能回到原始证据。目录负责大致分层搜索负责把东西找回来。适合谁这套东西不只适合程序员。如果你用 AI 做自媒体、写方案、做项目、整理资料只要你已经开始反复给 AI 解释同一批背景就说明你需要一个更稳定的知识库。尤其适合三类人笔记很多但真正用的时候找不到有多个 Agent 或工具一起工作需要共享上下文想把文章、项目和经验沉淀成长期资产。不需要一开始就做得很复杂。先把 raw 和 wiki 分开再把项目背景写清楚就已经比“所有东西丢一个文件夹”强很多。局限性知识库不会自己变好。AI 编译会犯错旧结论会过期目录也会慢慢长歪。你仍然要定期清理、降级、复核。所以我现在不把知识库当成一次性工程而是当成一套维护习惯。资料能沉淀结论能更新旧知识能降级AI 下次能接着干活。这就是我升级到 LLM Wiki V2 的原因。作者维天说。