llm-wiki

LLM Wiki 技能（提案）

目的： 由大模型维护一套不断积累的 Markdown 知识库，存放外部知识（文章、论文、转录文本、剪藏的网页内容），让记录整理工作自动完成，知识也能不断积累。基于 Andrej Karpathy 于 2026 年 4 月发布的「LLM Wiki」模式。完整设计依据，以及它与现有 AgentOps 技能的协同方式，请参阅 references/architecture.md。

状态： 提案——尚未合并。于 2026-04-11 提交，供委员会评审。有关促成本技能设计的研究，请参阅 .agents/research/2026-04-11-karpathy-llm-wiki-integration.md。

核心理念（一段话）

RAG 有一个关键缺陷：无法积累知识。每次查询都要从原始语料中重新发现片段。LLM Wiki 模式用一套由大模型持续维护的 Markdown 知识库取代逐次查询的 RAG，作为原始来源与用户之间的中间层。大模型只需读取每篇原始文档一次，提取概念、撰写摘要、交叉链接相关观点，并持续更新全部内容。查询时，大模型读取已经编纂好的知识库——速度更快、内容更丰富，而且知识还能不断积累。

Karpathy 的比喻是：“Obsidian 是 IDE。大模型是程序员。知识库是代码库。” 这与 AgentOps 的内部飞轮模式相同，只是应用于外部知识。

本技能的用途

针对采用知识库结构的资料库执行四项操作的规范：

1. ingest — 处理新的原始来源 → 编写知识库页面 + 更新索引 + 记录日志
2. query — 根据知识库页面回答问题 → 将综合结果归档为新页面
3. lint — 定期健康检查，查找矛盾、过时论断、孤立页面或缺失概念
4. promote — 将成熟的知识库页面从草稿转为已审核，或从知识库转为原创内容

本技能不适用于

• 不用于取代 compile — skills/compile 处理 AgentOps 内部产物（.agents/learnings/ → .agents/compiled/）。llm-wiki 处理外部源材料（raw/ → wiki/）。两者相辅相成，职责不重叠。区别请参阅 references/architecture.md。
• 不用于取代 research — research 通过调查撰写全新的研究成果；llm-wiki 则整理已有的外部资料。研究成果可以引用知识库页面；知识库页面也可以为研究成果提供参考。
• 不是 RAG 系统 — 它的做法恰恰相反。RAG 会在每次查询时检索片段；LLM Wiki 则预先将这些内容编纂成持久页面。
• 不自动安排任务 — 本技能定义操作；任务调度（cron / systemd / launchd / Claude Code hooks）由宿主负责。参考文档说明了三级模型（常驻的 Tier 1 本地大模型、按需使用的 Tier 2 Claude、人工 Tier 3），但不强制使用特定的调度程序。

快速开始

# Initialize the wiki layout in the current project
/llm-wiki init

# Drop a raw file into raw/articles/ then ingest it
/llm-wiki ingest raw/articles/karpathy-llm-wiki-gist.md

# Query the wiki for what we know about a topic
/llm-wiki query "what's the Karpathy LLM Wiki pattern?"

# Lint the wiki for orphans, contradictions, stale pages
/llm-wiki lint

# Promote a mature wiki page out to authored content
/llm-wiki promote wiki/concepts/llm-wiki.md --to platform-lab/patterns/llm-wiki-architecture.md

标志

标志	默认值	说明
--tier 1|2|3	2	操作者层级。Tier 1 只写入 status: draft，绝不触碰原创内容目录。Tier 2 写入 status: reviewed，并可执行提升操作。Tier 3（人工）负责将内容最终提升至 MEMORY.md / 原创内容路径。
--raw PATH	raw/	覆盖默认的原始内容收件箱位置
--wiki PATH	wiki/	覆盖默认的知识库输出位置
--dry-run	off	显示将要摄取或写入的内容，不做任何更改
--force	off	用于 lint，应用自动修复（链接孤立页面、标记过时内容），而不只是报告问题
--since DATE	30 days	用于 lint，仅检查自该日期以来有过更新的页面
--index PATH	INDEX.md	覆盖索引位置
--log PATH	LOG.md	覆盖日志位置

执行阶段

阶段 1 — init

如果当前项目中尚未存在 wiki 布局，则创建该布局：

<project>/
├── INDEX.md                 ← content catalog
├── LOG.md                   ← append-only operation log
├── SOUL.md                  ← (optional) user identity for always-load
├── CRITICAL_FACTS.md        ← (optional) ~150-token always-load context
├── raw/                     ← Karpathy raw layer
│   ├── articles/
│   ├── papers/
│   ├── transcripts/
│   ├── screenshots/
│   └── assets/
└── wiki/                    ← Karpathy compiled layer
    ├── sources/             ← per-raw-doc summaries
    ├── entities/            ← people, orgs, products, tools
    ├── concepts/            ← ideas, frameworks, theories
    └── synthesis/           ← cross-cutting analyses

为 INDEX.md 和 LOG.md 添加标题；将 SOUL.md 和 CRITICAL_FACTS.md 保留为可选存根。创建 _CLAUDE.md（或更新现有文件）并添加工作流章节。幂等 — 在现有布局上重新运行不会产生任何变化。

阶段 2 — ingest <raw-path>

对于每个原始来源：

1. 完整阅读（不要略读）。
2. 在 wiki/sources/<slug>.md 创建摘要页面，并添加 frontmatter：

   type: source
   raw: <path to raw file>
   ingested: <ISO datetime>
   status: draft|reviewed    # draft if Tier 1, reviewed if Tier 2
   

3. 提取候选实体（人物、组织、产品、工具）→ 在 wiki/entities/ 中创建存根页面，或更新现有页面。在来源页面中添加反向链接。
4. 提取候选概念（想法、框架）→ 在 wiki/concepts/ 中创建存根页面，或更新现有页面。
5. 使用所有新页面更新 INDEX.md。未能更新索引 = 后续 lint 失败。
6. 在 LOG.md 中追加：YYYY-MM-DD HH:MM | <actor> | INGEST | <source slug> | <pages created> | <wikilink>
7. 如果任何现有的 wiki/synthesis/* 页面涵盖此主题，则修订该页面以纳入新来源；不要留下过时版本。

Tier 1 限制： 如果以 --tier 1 运行，所有写入内容都添加 status: draft。Tier 1 绝不修改 wiki/synthesis/（综合内容需要审核）。Tier 1 绝不修改现有的 status: reviewed 页面。

阶段 3 — query <question>

根据 wiki 回答问题：

1. 搜索 wiki/** 中的相关页面。还要检查 .agents/learnings/、.agents/findings/，以及存在时的已撰写内容目录。
2. 综合答案并附上引用——每个实质性论断都必须通过 wikilink 引用具体页面。
3. 如果答案具有实质性且可能会再次被问到，则将其保存为新的 wiki/synthesis/<slug>.md，其中包含问题、答案和引用。
4. 在 LOG.md 中追加一条 op 为 QUERY 的记录。

已撰写内容优先于 wiki 草稿。 如果 .agents/findings/ 或 .agents/learnings/ 中已有涵盖该概念的内容，应优先引用该内容，并将 wiki 视为补充材料。

阶段 4 — lint

遍历 wiki/ 并标记：

1. 孤立页面 — 没有任何其他 wiki 页面反向链接到该页面，且 INDEX.md 中没有对应条目
2. 失效的 wikilink — 链接指向不存在的页面
3. 过时页面 — ingested 日期早于 --since 截止日期，且该领域正在演变（用户配置的过时领域列表）
4. 矛盾 — 两个页面提出不兼容的主张，却没有调和说明。使用简单的关键词启发式，并通过 LLM 重新阅读候选页面。
5. 缺少概念页面 — wiki/sources/ 中提及的实体或概念没有专属页面
6. 索引偏差 — wiki/** 中未列入 INDEX.md 的文件，或索引条目指向不存在的文件

将发现写入 wiki/synthesis/lint-YYYY-MM-DD.md。默认不要自动修复 — lint 只生成报告，由人工或 Tier 2 决定。

使用 --force 时，自动修复：

• 添加缺失的索引条目
• 将过时页面标记为 status: stale
• 在孤立页面中写入孤立警告注释

在 LOG.md 中追加一条 op 为 LINT 的记录。

阶段 5 — promote <wiki-path> --to <destination>

将成熟的 wiki 页面移至已撰写内容：

1. 确认目标路径是有效目标（platform-lab/patterns/*、career/*、learning/* 或类似的项目专属已撰写内容目录）。
2. 尽可能使用 git mv 以保留历史记录；否则重写。
3. 更新 INDEX.md — 从 wiki 部分移除，并添加到已撰写内容部分。
4. 查找并更新所有指向旧路径的反向链接。
5. 在 LOG.md 中追加一条 op 为 PROMOTE 的记录。

Tier 1 不能晋升。 Tier 2 可以在 wiki 内晋升（status: draft → reviewed）。Tier 3（人工）可以将内容从 wiki 晋升到已撰写内容目录。

与现有 AgentOps 技能的集成

技能	交互方式
skills/compile	处理内部 .agents/ 工件 → .agents/compiled/。结构上与 llm-wiki 相同，但针对内部来源。两个 wiki（wiki/ 和 .agents/compiled/）可以相互链接，但不会合并。
skills/research	可以在研究工件中引用 wiki 页面。也可以选择在撰写研究工件前，先对材料运行 llm-wiki ingest。
skills/forge	可以通过常规的发现项注册流程，将已凝练为可复用模式的 wiki 页面概念，提升至 .agents/findings/。
skills/inject	应在会话开始时，学习将相关 wiki/ 页面与 .agents/* 内容一同注入。
skills/post-mortem	第 2 阶段（提取经验）可以将近期的 wiki/synthesis/ 页面作为辅助背景信息。
skills/pre-mortem	可以查询 wiki/，获取与事前复盘主题相关的过往背景信息。
skills/knowledge-activation	可以将高价值 wiki 页面与 .agents/learnings/ 中提升的内容一同激活到 MEMORY.md。

与 AgentOps 飞轮的关系

AgentOps 飞轮积累内部工作知识（我们做了什么、学到了什么、出了什么问题）。LLM Wiki 积累外部阅读知识（我们读了什么、他人得出了什么结论、当前最先进的技术是什么）。

两个飞轮相互促进：

• Wiki 页面可以被研究工件引用，为内部飞轮提供输入
• 内部经验可以引用 wiki 页面，解释“我们为何采用方案 X”
• 发现项可以通过 wiki 来源的背景信息得到充实

设计原则： 外部知识和内部知识存放在不同的目录树中（wiki/ 与 .agents/），以始终明确知识来源。两个目录树相互链接，但不会合并。

调度（不属于此技能，但此处会提及）

Karpathy 模式在技能按计划运行时效果最佳，而不只是按需运行。拟议的 3 层模型（来自社区实现）：

• 第 1 层 — 始终运行、成本低廉的本地 LLM（例如，在消费级 GPU 上运行 Gemma 4 26B A4B）。每晚摄取 raw/、生成草稿、检测孤立页面并执行 lint。
• 第 2 层 — 按需使用、成本较高的专家模型（Claude / Codex / 同类产品）。每周审阅草稿、进行综合整理，并将内容提升为撰写完成的内容。
• 第 3 层 — 人工。每周审批提升至长期记忆／撰写完成内容的内容。

完整的分层模型和调度建议，请参阅 references/architecture.md。此技能与层级无关；由宿主项目接入调度器。

供评审委员会审议的未决问题

1. Wiki 目录结构（raw/、wiki/）应位于项目根目录，还是 .agents/wiki/ 下？提案建议：项目根目录，以便明确区分外部知识与内部工作。
2. 这与 skills/compile 的重叠是否足以让两者合并？提案建议：不合并——保持分离并说明二者的区别。
3. 应通过 --tier 标志将 3 层模型纳入技能，还是将其作为惯例？提案建议：使用 --tier 标志，默认设为第 2 层。
4. init 是否也应创建 SOUL.md 和 CRITICAL_FACTS.md，还是将它们设为可选项？提案建议：创建带有说明的模板文件。
5. 合适的输出契约是什么？Post-mortem 使用 council/schemas/verdict.json；llm-wiki 是否应为摄取／查询／lint 结果定义自己的输出架构？提案建议：是，具体形式由评审委员会确定。

参考资料

• .agents/research/2026-04-11-karpathy-llm-wiki-integration.md — 促成此技能的研究成果
• references/architecture.md — 完整的设计原理、分层模型、互操作详情和反模式
• references/research.md — 外部来源研究摘要与综合分析
• Karpathy 的原始 LLM Wiki gist（2026 年 4 月）
• 社区实现：NicholasSpisak/second-brain、eugeniughelbur/obsidian-second-brain

另请参阅

• skills/compile/SKILL.md — 内部成果编译器（结构相同，但来源不同）
• skills/research/SKILL.md — 研究成果编写
• skills/forge/SKILL.md — 从转录文本中挖掘知识
• skills/inject/SKILL.md — 在会话开始时注入上下文
• skills/post-mortem/SKILL.md — 此技能在外部扩展的六阶段知识飞轮

---

提案状态：开放。此 SKILL.md 描述了预期行为，但目前尚未实现。在编写任何代码之前，理事会应通过 /pre-mortem --preset=product 审查并验证设计。如果获批，下一步应先实现 ingest 和 query 阶段（以实验功能形式发布），然后在前两阶段通过验证后再实现 lint 和 promote。