个人 LLM 知识库（Karpathy LLM wiki 范式）

解决内容创作的地基层问题——让 AI 记住你的私有资料，创作时能引用，而不是每次都从零开始猜。

本技能是横切地基：增长三件套（growth-content-strategy / growth-content-writing / growth-content-ops）和内容工具包（content-toolkit）都可以"挂载" wiki 作为知识增强源。它不解决"写什么/怎么写/怎么发"，而是解决"AI 怎么知道我的品牌、我的行业、我的历史爆款"。

核心范式：LLM Wiki（不是 RAG）

本技能实现的是 Andrej Karpathy 提出的 LLM wiki 范式，核心理念一句话：

Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

与传统 RAG 的根本区别

为什么本项目选 wiki 而非 RAG：本仓库定位是"模型无关的 prompt 资产"——不引入向量库、embedding 模型、本地推理等重基础设施。LLM wiki 让任何 Agent 都能用原生文件读写能力维护知识库，完美契合这一理念。

三层架构

┌─────────────────────────────────────────────┐
│  浏览层：Obsidian / 任意 Markdown 编辑器      │
│  （人读、人改、双链跳转）                      │
└───────────────────┬─────────────────────────┘
                    │ 读写 Markdown 文件
┌───────────────────┴─────────────────────────┐
│  编译维护层：LLM（你正在对话的这个 Agent）    │
│  （按 Schema 抽取、组织、维护、去重）          │
└───────────────────┬─────────────────────────┘
                    │ 遵循
┌───────────────────┴─────────────────────────┐
│  规范层：Schema 文件                          │
│  （定义每类页面该有哪些字段、什么格式）         │
└─────────────────────────────────────────────┘

核心心法

1. Wiki 是"编译"出来的，不是"存"进去的

不要把原始资料直接堆进 wiki。原始资料进 inbox/，LLM 读完后按 Schema 抽取结构化条目，写入对应页面。就像源代码（原始资料）要编译成可执行程序（结构化 wiki）才能用。

2. 持续维护，不是一次性生成

wiki 的价值在于持续积累。每次有新资料进来，不只是加一条，而是：

• 更新相关的交叉引用（双向链接）
• 刷新受影响页面的摘要
• 检测与现有内容的冲突，合并或标注
• 保持首页索引与实际页面一致

3. Schema 是契约

每类知识库页面都有 Schema（字段定义）。LLM 写入时必须符合 Schema，这样：

• 页面结构统一，LLM 后续读取时能稳定定位字段
• 人能快速浏览
• 可以做 lint 自检（字段缺失、引用失效）

与内容创作技能的联动（关键）

wiki 不是孤岛，它是创作链路的知识源。下面是各技能如何"挂载" wiki：

联动约定（详见 references/wiki-maintenance.md 的"与创作技能联动"一节）：

• 创作时主动声明"本次挂载 X-wiki"，列出读取了哪些页面
• 产出中引用了 wiki 内容时，标注来源页面（[[页面名]]）
• 创作产出的新结论（如新爆款拆解）要回流写回 wiki

执行流程（根据意图路由）

1. 先判断用户处于哪个阶段：
   • 不了解范式 / 第一次建 wiki → 先读本 SKILL.md 的"核心范式"和"三层架构"，再读 references/wiki-maintenance.md 的四阶段工作流
   • 已有 wiki、要加内容 → 读 references/wiki-maintenance.md 的"摄入→抽取"流程
   • 要内容创作专用的 Schema 模板 → 读 references/wiki-schema-templates.md
2. 按需读取参考文件：
   • 建库 / 维护 / lint → references/wiki-maintenance.md（四阶段：摄入/抽取/组织/维护 + lint 清单）
   • 要品牌/行业/爆款/对标/模板五类模板 → references/wiki-schema-templates.md（开箱即用的 Schema + 示例条目）
3. 执行时遵循 Schema：写入任何页面前，先确认（或与用户确认）该用哪个 Schema；没有现成 Schema 时，先和用户一起定义 Schema 再写。
4. 每次写入后做最小维护：更新交叉引用 + 刷新受影响摘要（不必每次全量 lint，但新增页面必须接上双链）。

输出原则

• 先定 Schema 再写内容：没有 Schema 的 wiki 会很快退化成垃圾堆。
• 编译而非堆砌：原始资料进 inbox，结构化条目进 wiki，不要混在一起。
• 持续维护：每次写入都顺手更新交叉引用；定期（用户主动要求时）跑一次完整 lint。
• 人可读优先：所有页面用 Markdown 写，人能用 Obsidian 直接浏览和编辑，不依赖任何特殊工具。
• 来源可追溯：每个条目标注资料来源（URL / 文件 / 对话），方便后续核对。

与本仓库其他技能的关系

• 本技能不产出"内容"，产出的是"知识库"。要写文案/选题/优化，去增长三件套。
• 本技能是地基：当三件套或 content-toolkit 需要"引用我的私有资料"时，会路由到这里先建/查 wiki。
• 沉淀闭环：content-toolkit/competitor-pattern-mining 拆出的竞品框架、growth-content-strategy/benchmark-analysis 拆出的账号维度，都应该回流到本技能维护的 benchmarks-wiki/ 和 hits-wiki/。