LLM Knowledge：把 Claude CLI 当成知识库的大脑
线上体验：https://wiki.bruceding.me/，项目源码：github.com/bruceding/llm_knowledge 下面这张图是线上版本的 Inbox 视图，左侧是导航（Inbox / Later / Archived / Wiki Index 等），右侧是文档卡片，每张卡片都带有 LLM 生成的摘要、标签、语言标记和状态按钮。 日常阅读中，我们经常遇到这样的场景：在浏览器里看到一篇好文章随手收藏，过阵子却再也找不回来；订阅了一堆 RSS 和 Newsletter，信息反而变成噪音；想回顾一份英文 PDF，又懒得逐页重读。各种收藏夹和稍后读工具都能解决"保存"这一步，却很难真正解决"理解和检索"。 市面上的笔记软件（Notion、Obsidian、Logseq）都强调"双向链接"和"第二大脑"，但它们几乎都要求用户自己去整理、打标签、写笔记。真正能帮你读完、帮你抽取、帮你串起来的工具很少。LLM Knowledge 就是为了解决这个问题而做的小工具。它把内容收集、LLM 抽取、对话问答整合到一套自托管的服务里，下载后跑一个二进制就能用，数据全部落在本地。 下面把它的整体设计、几个关键技术点和主要功能梳理一下。 设计约束 在动手写代码之前，先给自己定了几条约束，后面所有的设计都在围绕这些约束做取舍： 约束 取舍 自托管优先 所有数据都放在本地 ~/.llm-knowledge/ 下，不依赖第三方 SaaS，避免敏感文档外泄 单文件部署 前端 dist 嵌进 Go 二进制，用户拿到一个可执行文件就跑，不用折腾 Node 或 Nginx LLM 能力外挂 不自己训模型，也不绑定某个 SDK，把 Claude CLI 当作子进程调用 — 模型升级、换模型、切本地模型，只需要替换 CLI 多源入口收敛 PDF、网页、RSS、Blog、Newsletter 都走同一条处理链路：原始文件保留，再抽取结构化内容到 Wiki 层 多用户分区 数据按 users/<id>/ 分区，家人或同事共用一套服务也不串数据 安全 fail-closed Claude CLI 是外部进程，但绝不能让它随意读写宿主机文件，必须有沙箱 把 LLM 当作子进程而不是 SDK，是这个项目最特别（也最容易被质疑）的设计。它带来的好处是：模型能力完全交给 CLI 本身演进，不用关心 SDK 升级；坏处是必须管理好子进程生命周期，尤其在 HTTP 请求被取消时要及时 SIGTERM，避免僵尸进程吃掉配额。后文会详细讲会话池的设计。...