llm-wiki-compiler：把原始资料编译成可引用维基的 TypeScript 工具链
The knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.
秒懂
- 它是什么？
- 它把 LLM Wiki 模式做成一个带 profile 契约、写入期信任门和 MCP 接口的知识编译器。适合需要长期复用同一批资料的人，不适合把快速变化的日志当作知识源的人。
- 适合谁用？
- 如果手上的资料值得反复查阅、需要引用可追溯，并且你愿意维护一份 .llmwiki/profile.json 作为唯一契约，llmwiki 值得先跑一个 autosci 模板做小规模验证。如果知识源每天都在变、只做一次性检索，或者你想要的只是一个静态站点生成器，它不合适。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是查询时反复重新发现知识的问题
常见的做法是把一堆文件塞进向量库，每次提问时再检索片段。问题是同一份资料会被反复解析、反复推断，结论不沉淀，下一次提问又从头来一遍。llmwiki 的出发点不同：README 说它实现的是 Karpathy 的 LLM Wiki 模式，把知识在编译期一次性写成持久页面，页面本身会累积结构、出处、审阅状态和检索元数据。
目标用户写得很明确。需要从论文、笔记、README、转录稿、PDF、图片或网页里得到长期知识库的人；想让 agent 拿到稳定的、带引用的上下文包而不是散落文件的人；需要审阅队列、新鲜度检查和引用审计的人。README 同时列出了反向清单：不要把它当通用静态站点生成器，不要当重量级本体数据库，也不要拿它替代对快速变化原始日志的临时搜索。这三条排除比功能列表更能说明它的定位。
两阶段编译与四类页面
核心流程是两阶段 LLM 管线。第一阶段从原始资料中抽取概念，第二阶段生成带类型的页面，README 列出的类型是 concept、entity、comparison 和 overview。默认 profile 保持经典的 concepts-and-queries 布局，可选 profile 增加领域类型和工作流，但不往编译器里塞领域分支。
引用是编译产物的一部分。README 说段落和论断会引用源文件与行号范围，llmwiki lint 负责校验这些链接。检索侧是混合式的：语义分块搜索、BM25 重排，加上 wikilink 图扩展，组合成紧凑的证据包供查询和 agent 使用。这三层叠在一起意味着检索质量同时受分块策略、重排和链接密度影响，链接稀疏的语料上图扩展这一层基本不起作用。
写入路径上还有运行时信任门。README 的措辞是关系、证据、产物和人工/agent 门由写入路径强制执行，而不是停留在提示词约定；事后由常驻 lint 检测漂移。这是这个项目与纯提示词方案最实质的差别，代价是配置复杂度上升。
profile.json 是唯一契约，也是主要学习成本
Configurable Lifecycle Profiles 是 1.0 之后的重点。一个经过校验的 .llmwiki/profile.json 声明类型化实体、字段与有向关系，生命周期状态、转换证据与信任门，多阶段工作流与声明的动作，哈希固定的产物与一方连接器绑定，以及内容分层与检索行为。CLI、SDK、MCP 服务器、查看器、上下文构建器、lint、status、导出和 OKF 交换都从同一份 profile 契约出发。
失败是封闭的：无效 profile 和绕过已声明门的写入都会失败，而不是降级继续。向后兼容也做了设计：没有 profile.json 的项目走内置默认 profile，保持 1.0 之前的行为。
模板是分发的载体。README 明确说模板只包含配置和示例，永远不含可执行插件代码；发布者用 llmwiki template publish 构建签名的离线分发包，签名算法是 Ed25519（README 在此处被截断）。内置的 autosci 是研究系统，含论文、想法、实验、手稿、证据产物、工作流和 Crossref 导入；newsroom 把同一套机制用在文章、编辑台、署名和编辑流程上。两个模板的存在本身就是对 CLP 通用性的检验，但模板质量如何，材料里没有可核实的说明。
上手命令与配置落点
README 给出的路径有三条：自己写 profile、装内置或本地模板、或从可信 tap 装签名模板。具体命令如下。
llmwiki profile init research --entity paper llmwiki template list llmwiki template inspect autosci llmwiki template init autosci llmwiki profile validate llmwiki workflow list
运行期相关命令包括 llmwiki view 打开只读浏览器界面，带搜索、页面元数据、图浏览、源新鲜度徽章和引用标签；llmwiki serve 暴露 MCP 工具，覆盖 ingest、compile、query、lint、read、status、eval、context-pack 和 OKF 交换；llmwiki lint 与 llmwiki next 暴露过期或孤立页面；llmwiki refresh --stale 修复已变化的知识而不编译无关新源；llmwiki eval 报告健康分、逐页健康分布、wikilink 图健康、引用覆盖率与精确率、语料统计和回归差值。SDK 侧用 createWiki({ root }) 驱动 ingest、compile、query、context、status、export、eval 和 OKF 导入导出，不需要走 shell。
provider 层面支持 Anthropic、Claude Agent SDK 本地登录、OpenAI Codex CLI 本地登录、OpenAI 兼容服务、Ollama、GitHub Copilot、Atlas Cloud、OrcaRouter 以及本地 OpenAI 兼容运行时。这个列表很宽，但每一项的实际可用性取决于你的账号与网络条件，材料里没有对应的验证说明。
失败模式：语料不值得编译时，整条管线都是负担
最明显的边界 README 自己写了：不要用它替代对快速变化原始日志的临时搜索。原因在机制里。编译是两阶段的 LLM 调用，产物是持久页面，而新鲜度靠 lint 和 refresh --stale 事后修补。如果源材料的变化速度接近你的查询频率，你会一直在修复过期页面，而不是在使用知识。
第二个边界是引用精度依赖源文件的行号稳定性。lint 校验链接，说明链接会断。对源文件做重排、重新格式化或换版本，都可能让已有引用失效，这属于编译式知识库的固有成本，不是实现缺陷。
第三个边界是 profile 的封闭性。无效 profile 直接失败，绕过信任门的写入也直接失败。这对审计是好事，对探索是阻碍：在还没想清楚实体和关系模型之前，你会反复撞在 validate 上。模板能缓解这一点，但模板只给配置和示例，最终仍要你自己承担契约的正确性。
还有一点材料没有覆盖：编译质量在多大程度上取决于抽取阶段所用的模型。provider 列表很长，README 没有给出不同 provider 下的质量差异说明，也没有说明评测集规模。llmwiki eval 能给出回归差值，但那是相对你自己的历史基线，不是跨项目的绝对分数。
与 Obsidian 加检索插件的分工差异
最自然的对照是 Obsidian 加一套检索或 RAG 插件。Obsidian 的模型是人工撰写笔记，链接由人建立，检索在查询时对已有笔记做匹配，知识本身不经过编译步骤。llmwiki 反过来：原始资料是输入，页面是编译产物，链接、类型、引用和生命周期状态由管线和 profile 决定。
差别体现在三处。一是出处，llmwiki 的引用落到源文件和行号范围，并由 lint 校验，Obsidian 的链接指向笔记而非源材料的具体位置。二是审阅，llmwiki 有 review 策略，页面在置信度、矛盾、schema 或出处规则触发时会被自动挂起进入审阅队列，Obsidian 没有这层。三是交换格式，llmwiki 导出 OKF、JSON、JSON-LD、GraphML、Marp 和 llms.txt，其中 OKF 支持双向导入导出，外部导入默认经过审阅队列暂存，可信包才显式直写。
反过来说，如果你要的是长期手工积累的个人笔记，编译步骤带来的 profile 维护和 lint 修复都是额外开销，Obsidian 那一侧更轻。llmwiki 的 topics 里带 obsidian，说明两者可以并存：把编译结果作为 vault 的一部分浏览，而不是二选一。
维护成本与许可
版本节奏可以从发布记录读出：v1.0.0 在 2026 年 7 月 11 日，v1.1.0 在 7 月 16 日，v1.2.0 在 9 月 10 日。1.0 引入了 CLP，1.1 到 1.2 之间隔了约两个月。这意味着 1.x 阶段仍在较快演进，profile 契约虽然承诺向后兼容，但升级前仍应跑一次 llmwiki profile validate 和 llmwiki eval 对比回归差值，而不是直接替换版本。
日常维护成本主要落在三处：profile 的演进（新增实体类型和关系会牵动 lint 与检索行为）、引用修复（源文件变动导致的断链）、以及 provider 侧的调用费用。前两项是人力，第三项是持续支出，材料里没有给出任何成本估算，需要按自己的语料规模测算。
许可证是 MIT，仓库主页和 LICENSE 徽章一致。MIT 属于宽松许可，通常允许商用和修改，但具体义务（例如保留版权声明与许可文本）以及你所在组织对生成内容的合规要求，需要自行核对，这里不构成法律意见。另外模板分发使用 Ed25519 签名，签名密钥的保管责任在发布方，安装第三方 tap 前应确认来源。
编辑结论
如果手上的资料值得反复查阅、需要引用可追溯，并且你愿意维护一份 .llmwiki/profile.json 作为唯一契约，llmwiki 值得先跑一个 autosci 模板做小规模验证。如果知识源每天都在变、只做一次性检索，或者你想要的只是一个静态站点生成器，它不合适。上手前先确认三件事：profile validate 能否通过、lint 报出的引用覆盖率与孤立页比例是否可接受、以及所选 provider 是否在你的网络与账号条件下可用。这三项决定后续编译是否值得持续投入。
社区笔记