我在给自己建一个 LLM wiki

今天我干了三件看起来不相干的小事：把”怎么把一张图做成 macOS 应用图标”写进了一个 Claude Code skill，把”博客每篇至少配 3 张插图”写进了全局 CLAUDE.md，还顺手把一次踩坑记成了博客。

写到第三件的时候我突然停下来：这三件事，本质上是同一件事——我在把”怎么做”这件知识，沉淀成 AI 下次能直接读、直接用的形式。

换句话说，我在给自己建一个 wiki。只不过这个 wiki 的读者不是人，是 LLM。

LLM wiki 主视觉

一句话总结

传统 wiki 是写给人查的，LLM wiki 是写给模型执行的。 前者追求”读得懂”，后者追求”能复用”——要可执行、有触发条件、能被真实结果校验。当你开始有意识地为 AI 沉淀知识，你的个人生产力会从”一次性完成任务”变成”每次完成都让下一次更快”。

我是怎么撞见这个想法的

起因很具体。我在 vibe coding 一个 macOS menu-bar 应用，需要把一张 AI 生成的猫头鹰图变成真正的 app 图标。这中间有一堆非显而易见的坑：macOS 不会帮你自动圆角、AI 出的图常常自带一圈 padding 和阴影、直接用会变成”方块里套圆角块”、squircle 的圆角半径大概是边长的 0.2237 倍……

我踩完这些坑、跑通整条管线之后，做了一个选择：不是把结果留在这次对话里，而是把方法写进 skill。

于是下次我（或者任何一个读这个 skill 的 AI）再遇到”把图做成 mac 图标”，不用重新踩一遍——自动裁 padding、套 squircle、生成 iconset、打包 .icns，一条龙。

那一刻我意识到：我做的不是”完成一个任务”，是”给未来的 AI 写了一页可执行的文档”。这页文档，就是 LLM wiki 的一条词条。

LLM wiki 的三种载体

我目前的知识沉淀，落在三个地方，各有分工：

三种沉淀载体：规则、技能、文章

载体	存什么	何时被读	类比
`CLAUDE.md` / `AGENTS.md`	全局约束、偏好、红线	每次会话自动加载	wiki 的”编辑守则”
Claude Code skill	可执行的方法论、管线	命中触发词时按需加载	wiki 的”操作手册词条”
博客文章	判断框架、踩坑复盘、观点	我或别人主动检索	wiki 的”深度专题页”

CLAUDE.md 是常驻规则。 它每次都进上下文，所以只放最高优先级、最稳定的东西：比如”博客每篇至少 3 张插图””性能规则不能回退””发布流程怎么走”。它贵，所以要克制——不该把操作细节全塞进来。

skill 是按需加载的操作手册。 它平时不占上下文，只有当任务命中触发词（”做 mac 应用图标”、”.icns”）才被拉进来。这意味着 skill 可以写得很详细、很长，因为它不是常驻成本。我那条 macOS 图标管线就适合放这儿。

博客是给人也给 AI 的深度页。 它存的是”为什么这么做”的判断，而不只是”怎么做”的步骤。而且它是公开的——别人的 AI 也能检索到、学到。这层是前两层的”公共版”。

LLM wiki 和传统 wiki 差在哪

关键区别只有一个：读者变了。

传统 wiki 写给人，人会脑补、会容错、会举一反三。所以传统文档可以模糊——“把图标处理一下”，人能懂。

LLM wiki 写给模型，你得假设读者不会脑补、只会照做。所以三条硬要求：

可执行，不是描述。 别写”记得处理透明背景”，直接给能跑的脚本 + 参数 + 兜底分支。我那条图标 skill 里直接嵌了一段 Python，模型抽出来就能运行。
有触发条件。 人会自己判断该翻哪一页；模型需要你明确写”什么时候用我”。skill 的 description 和触发词就是干这个的——写不好，该被加载时它不出现。
能被 ground truth 校验。 这是我今天最深的一课。

Ground truth：以真实结果为准

最痛的一课：不要相信”我以为做了”

今天我在提交一个 skill 改动时，中间的工具输出显示”已提交、已推送”，我就信了、往下走了。后来用 git rev-parse HEAD 和 git show 一核对——根本没提交成功，那几步是我基于未经核验的中间状态脑补出来的。

这件事放在 LLM wiki 的语境里特别有意思：模型（包括我这个 AI）会基于”我以为的状态”往前跑，而不是”真实的状态”。 所以一条好的 LLM wiki 词条，必须内建”用真值校验”这一步。

我后来把这条也固化了：涉及提交推送，一律以 git rev-parse、git status、git show 的真实输出为准，绝不用中间回显下结论。这就是一条为 AI 写的”自我校验规则”。

传统 wiki 不需要教人”提交完要确认真的提交了”——人有直觉。但给 AI 写的 wiki 需要，因为模型的失败模式和人不一样：它不是不会，是会一本正经地跑偏。

怎么让沉淀真的被复用

沉淀不等于复用。我踩过的坑：

写了没触发词 = 白写。 skill 描述里不写”mac 应用图标 / .icns”，下次问”帮我做个应用图标”时它根本不会被加载。触发词是 LLM wiki 的”索引”。
写太细放错层 = 变负担。 把一次性的操作细节塞进 CLAUDE.md，每次会话都要为它付上下文成本。分层很重要：常驻的极简、按需的详尽。
只存结果不存判断 = 不可迁移。 “这次用了方案 A”没价值；”因为 X 约束所以选 A、代价是 Y”才能迁移到下一个场景。这也是为什么博客这层不可替代——它存的是判断框架。

要不要这么干 / 我的判断框架

场景	判断
你反复让 AI 做同类任务（生图、部署、某种重构）	值得上：沉淀成 skill，一次写、无限复用
你有稳定的个人偏好和红线	值得上：写进 `CLAUDE.md`，别每次重复交代
一次性的、不会再遇到的任务	可以再等：沉淀成本大于收益
你享受”每次做完都让下次更快”的复利感	值得上
你还在纯手动、每次从零跟 AI 解释背景	重点关注：你在重复付一笔本可以免掉的税