llmwiki：让 Claude 按计划维护你自己的维基

它要解决的是笔记只进不出的问题

大多数人的资料收集流程是单向的：PDF 存进某个文件夹，网页剪藏丢进稍后读，笔记散在几个应用里。收集本身不产生价值，真正稀缺的是把新材料和旧材料对照、合并、改写的那一步，而这一步需要持续投入注意力，所以通常不会发生。llmwiki 把这一步交给模型，并且用定时任务保证它按周期发生。README 明确写了目标读者分三层：个人、给 AI 用的上下文层、以及希望建立机构知识层的组织。第三层是期望而非已交付的能力，README 的措辞是“we hope companies will consider”，不是功能承诺。真正落地的是前两层：一个你自己读的维基，以及一个让 Claude 在处理你的任务时能调用你既有判断的检索层。

索引留在本地，写入交给 Claude

从 README 能确认的数据流是这样的：你指定一个文件夹，llmwiki 把它索引成一份本地搜索索引，文件本身不被移动、修改或上传。工作目录里只多出两样东西，一个是存放生成页面的 wiki/ 文件夹，一个是隐藏的 .llmwiki/ 索引目录。Claude 通过 MCP 读取、写入和搜索这个工作区，所以模型看到的是你磁盘上的原始材料，而不是被复制到某个云端服务的副本。页面之间支持原生交叉引用，并且能回溯到来源文件，README 还提到图谱视图和包括 SVG、Mermaid 在内的可视化。这条链路的代价在于：索引是本地状态，换机器就要重建；而写入权在模型手上，页面质量取决于你给的来源质量和 Routine 提示词的质量。

从克隆到 localhost:3000

安装分 Python 和 Node 两部分，README 给出的命令是 pip install -r api/requirements.txt -r mcp/requirements.txt，以及 web 目录下的 npm install，环境要求为 Python 3.11+ 和 Node.js 20+。Windows 用户如果激活虚拟环境被策略拦截，README 建议执行一次 Set-ExecutionPolicy -Scope CurrentUser RemoteSigned，或者跳过激活直接用 .venv\Scripts\python 代替 python。初始化工作区并启动的命令是 ./llmwiki open ~/research，Windows 下为 python llmwiki open C:\Users\you\research，它会完成初始化、索引、启动 API 和 web 应用，并打开 localhost:3000。接 Claude 用 ./llmwiki mcp-config ~/research，把打印出来的 JSON 粘进 claude_desktop_config.json 或 .claude/settings.json。这里有个容易踩的点：一个工作区对应一个 MCP server 条目，多个文件夹就要加多条配置。

本地模式只监听 127.0.0.1

README 对本地模式的描述很直接：API 绑定在 127.0.0.1，不支持局域网或远程绑定。这意味着你没法在手机上打开自己家里的维基，也没法把它放在一台共享服务器上让同事访问。想远程使用，README 给的路径是自托管远程应用或者直接用 llmwiki.app。另一个需要留意的限制在依赖上：抽取 Word 和 PowerPoint 需要 LibreOffice，PDF 的 OCR 质量取决于是否提供 MISTRAL_API_KEY，没有它就走默认路径。这两项在 README 里都标为可选，但可选的意思是功能会降级，不是不影响结果。

Chrome 扩展记录的是你的判断，不只是原文

扩展的作用不只是剪藏。README 说它在你阅读时抓取网页和 PDF，同时记录高亮和批注，而这些批注通过 MCP 对 Claude 可见。这个设计选择决定了生成页面的性质：模型拿到的输入里包含你当时认为哪一段重要、为什么重要，所以维基沉淀的不只是读过什么，还有你怎么想。README 用“compounds over months and years”来描述这种积累效应。需要说明的是，仓库材料里没有给出扩展的具体安装方式，也没有说明它支持哪些浏览器版本，只有 Chrome 这一条线索。

自维护靠的是定时 Routine，不是后台守护进程

llmwiki 本身不包含一个常驻的整理进程，自维护能力来自外部调度。README 推荐的提示词大意是：读指南，找出上次运行以来新增的来源、剪藏和高亮，逐个阅读并更新维基，需要新页面就写，需要合并就并入既有页面，并修正受影响的交叉引用和引文。然后把这个提示词排成每晚运行。调度有两种：Claude Code Routines 在 Anthropic 的云上按固定节奏执行，即使笔记本合上也会跑；Desktop scheduled task 则在你自己的机器上执行同样的提示词。这个分工意味着维护频率由你配置的调度决定，而不是由 llmwiki 决定，模型每次改动多少页面也取决于那次运行读到了什么。

和 RAG 问答系统的区别在产出物

仓库的 topics 里同时有 rag 和 knowledge-base，但 llmwiki 的产物形态和典型 RAG 系统不同。RAG 方案通常在查询时才检索片段、拼进上下文、生成一次性回答，知识本身没有持久形态，下一次提问重新检索一遍。llmwiki 把综合结果写成文件：wiki/ 目录下的页面是长期存在的，带交叉引用和来源回溯，可以打开、浏览、被图谱视图读取。代价是它引入了写入路径，页面会随来源变化被改写，你需要接受模型对既有内容的编辑。如果你要的是稳定不变、逐条可审计的知识条目，一次性问答式的检索反而更可控；如果你要的是一份能翻阅、能看概念之间关系的长期文档，写入路径就是必要的。

维护成本与许可

仓库采用 Apache-2.0，README 顶部也标注了同一许可。Apache-2.0 允许商用和修改，并包含专利授权条款，具体义务建议查阅许可证原文或咨询法务，这里不做法律判断。维护成本主要在三个地方：依赖 Python 3.11+ 与 Node.js 20+，每次升级要同时照顾 api、mcp 和 web 三套依赖；工作区索引是本地状态，迁移或重建需要重新索引；页面由模型改写，来源变动会传导到 wiki/ 下的内容，所以版本控制或备份策略需要你自己决定。README 没有给出任何版本号或发布记录，仓库信息里也没有检索到 release，这意味着升级路径要靠提交历史自行判断。

编辑结论

适合已经在用 Claude Desktop 或 Claude Code、手上有一堆散落 PDF 与笔记、并且愿意让模型直接改写自己知识库的人。不适合需要多人协作、需要局域网或远程访问、或者不接受模型未经逐条审核就改动页面内容的团队。动手前先确认三件事：你的 Python 是否 3.11 以上、Node 是否 20 以上；LibreOffice 是否可用（否则 Word 和 PowerPoint 抽取会受限）；是否准备了 MISTRAL_API_KEY（README 说它用于更高质量的 PDF OCR）。然后在一个副本目录上跑一次 ./llmwiki open，检查生成的 wiki/ 目录和隐藏的 .llmwiki/ 索引是否符合预期，再决定要不要接定时 Routine。

官方来源

1. Issues
2. License: Apache-2.0
3. lucasastorian/llmwiki on GitHub
4. Project website
5. README