我以前对知识库有一个误解：只要资料够多，它自然就会有用。
后来发现不是。资料多了以后，问题反而更明显。页面互相不连，旧结论没人更新，弱证据和强证据混在一起，想写文章时还要重新翻一遍。看起来有一个知识库，实际每次还是从零开始。
llmwiki 这个项目解决的是另一个问题：
让 LLM 持续维护一个会增长的 Markdown wiki。这里的重点不是“问一次答一次”，而是让读过的资料被编译进一个长期存在的知识层里。摘要、概念、冲突、关联、综合判断，都要留下来。以后新资料进来，不是再生成一份孤立摘要，而是更新已有页面。
我是怎么把它搭起来的
第一步，先分层。根目录资料和 原始资料/ 默认只读，知识库/ 才是正式写入层。这个边界非常重要，不然 Codex 很容易把原始资料也改了。
第二步，建三个入口文件：首页.md、索引.md、日志.md。首页回答“这个知识库是什么”，索引回答“有哪些页面”，日志回答“最近改了什么”。没有这三个入口，知识库会很快变成一堆孤立笔记。
第三步，建立页面类型。来源/ 放资料摘要和出处，专题/ 放跨资料综合，流程/ 放纳入、查询、巡检、公众号生产这些动作，元信息/ 放结构规范和工具公约。页面类型清楚，后续才知道该更新哪里。
第四步，让 Codex 按纳入流程处理资料。每次新资料进来，不是只写摘要，而是判断它影响哪些专题页，要不要更新首页、索引和日志。如果和旧结论冲突，就显式记录，不偷偷覆盖。
第五步，建立 Codex 和 Obsidian 的分工。Codex 做编辑部，负责检索、整理、重构、写作、回写和巡检；Obsidian 做阅读器，负责浏览、搜索、双链查看和轻量批注。
第六步，把重复动作固化成 llm-wiki-manager 技能。以后要查资料、生成公众号文章、做全库巡检、维护首页索引日志，不需要每次重新解释流程，直接按技能入口走。
到这一步，llmwiki 才从一个 Markdown 仓库变成了一个可维护系统。
Codex 做编辑部，Obsidian 做阅读器
这个项目里有一个很清楚的分工：
Codex = 知识库编辑部
Obsidian = 知识库阅读器Obsidian 适合浏览、搜索、看双链、轻量批注。Codex 负责更重的动作：资料纳入、专题综合、索引和日志维护、弱证据清洗、重叠页面合并、公众号文章提纲和发布包生成。
这个分工很实用。因为知识库真正费人的，不是看，而是维护。
维护需要判断：这份资料该进哪个专题？会不会和旧页面重复？有没有改变首页的顶层理解？索引要不要补？日志要不要记？如果新资料和旧结论冲突，是覆盖，还是显式记录冲突？
这些事交给人手工做，很容易拖。交给 Codex 做，至少流程能稳定跑起来。
llmwiki 的最小工作链
这个知识库现在有几类关键页面：
首页.md：总入口和顶层综述。索引.md：页面目录和一句话说明。日志.md：记录知识库演化。专题/：主题综合页。来源/：原始资料摘要和影响范围。流程/：纳入、查询、巡检、公众号生产等操作流程。元信息/：结构规范、工具分工和发布公约。
每次资料纳入，不是写完一页就结束，而是按流程更新来源页、专题页、首页或索引，并在日志里留下记录。
这听起来有点啰嗦，但它解决了一个老问题：知识不会消失在对话里。
公众号生产线也是知识库的一部分
后来 llmwiki 不只是知识管理，也接上了公众号文章生产。
它可以从已有专题里找选题，生成素材包，写工作稿，再输出公众号最终发布包。发布包默认包括内联样式 HTML、纯文本兜底和 PNG 配图说明。文章发布之后，还要回写知识库，避免写作成果只留在外部平台。
这个用法很有意思。
以前写文章像从仓库里临时搬货，搬完就走。现在更像在知识库内部开一条生产线：选题从知识库来，素材从知识库来，文章写完再回到知识库。
这类 Codex 用法的关键
不要让它无限生成新页面。
llmwiki 的规约里反复强调：原始资料默认只读，正式知识写入 知识库/；优先更新已有页面，不创建主题重叠的重复页；新增页面或重要更新要同步索引；新资料和旧结论冲突，要显式记录，不要静默覆盖。
这几个约束很要命。
没有约束，Codex 会很勤快，但知识库会变胖。页面越来越多，入口越来越乱，最后又回到原点。
真正好的知识库型 Agent，不是会写很多页，而是知道什么时候该更新旧页，什么时候该合并，什么时候该停。
知识库不是资料的坟场。
它应该是能继续工作的地方。