从笔记到知识编译器：一次个人探索

Andrej Karpathy 在那篇关于大模型知识管理的文章里提了一个方向——让 AI 提前消化知识，而不是在提问的时候临时翻找。这个概念击中了我。不是因为技术有多新，是因为它挑战了一个我长期以来默认接受的假设：知识管理等于做好检索。

这个假设往前追溯，有它的历史合理性。从文件系统到数据库，从全文搜索到向量检索，整个信息管理的发展史，本质上就是检索能力不断升级的历史。我们默认知识是静态存储的，使用时才被调用。这个范式如此根深蒂固，以至于很少有人问另一个问题：如果知识在被存储之前，就已经被重新组织过了呢？

两周时间，从搭建到跑顺。下面记的不是一个工具的选型过程，是这次探索背后的理念推演和架构决策。

一、两种范式：检索 vs 编译

先理清这两个概念。

检索范式：信息先存起来，用的时候再搜。搜索引擎、数据库查询、向量相似度匹配，都属于这个路线。它的核心假设是，信息的价值在存储时已经固定，检索只是把它找出来。

编译范式：信息在被存储之前，先经过消化和重组。源代码写成后，编译器翻译一次，之后执行用的全是编译产物。你不需要每次运行程序的时候重新去源码里翻找逻辑。

这两种范式没有高下之分，但适用场景完全不同。检索适合的是“我知道自己在找什么”的场景。编译适合的是“我需要知识自己浮现出来”的场景。

传统笔记走的是检索路线。存的时候不做加工，用的时候临时搜。这条路我走了很久，一直走到一个死胡同里：笔记越写越多，用得越来越少。信息被存下来了，知识没有长出来。

问题出在检索本身上吗？不是。是中间缺了一个环节——人的参与。检索范式假设信息存进去就有价值，但一堆未经消化的信息堆在一起，能提供的价值极其有限。编译范式把这个缺失的环节补上了：AI在后台对Raw素材进行提炼和重组，人审视编译结果，决定认不认可、要不要调整、哪些方向需要补充素材。人和AI在编译—反馈—再编译的循环里共同推动知识的生长。

这就是LLM-Wiki的起点。它不是用编译替代检索，更不是让AI替代人。是把过去被人忽略的那个消化环节显性化，让人和AI各自在擅长的环节发挥作用。

二、架构决策：三层分离与物理隔离

理念定了，到架构这一步，第一个要回答的问题是：人和 AI 的协作边界怎么划。

这个问题的历史教训太多了。从版本控制的锁机制到协同编辑的 OT 算法，从文件权限到数据库事务，每一次多主体协作的架构设计，核心矛盾都是同一件事：谁能在什么时候改什么。

我选了一个最朴素、也最不容易出错的路：物理隔离。

llm-wiki/
├── raw/           # 人的地盘，AI 只读
├── wiki/          # AI 的地盘，人只读
└── schema/        # 格式规范，AI 维护

Raw 里放原始素材——读过的论文、随手写的想法、项目复盘。铁律一条：AI 只能读，不能写，不能删。这是我的思想原料仓库，不能有任何污染。

Wiki 里是 AI 基于 Raw 主动生成的结构化知识。每一篇都是它自己消化素材、自己提炼概念、自己组织语言写出来的。不是简单摘要，是重新组织的永久笔记。它会随着 Raw 的增长持续演化。

Schema 是格式规范。但重点不是规范本身，是谁来维护规范。我把 Schema 也交给 AI——发现格式不对，告诉它改，它自己更新 Schema，下次编译照着新的来。

这个架构决策背后有一个原则：协作边界的复杂度，应该由边界本身的结构来消解，而不是靠规则和标记去维持。我早期试过在同一个文件里用标签区分人和 AI 的内容，很快就败下阵来——人会不小心越界，AI 需要在文件里找自己的领地，权限控制越来越复杂。把两个独立演进的系统锁在同一个文件里，就像把两种不同的物质放在同一个容器里，维持边界本身就成了主要工作。

物理隔离一劳永逸地解决了这个问题。文件系统本身就是边界。

三、规则设计的尺度：宪法还是民法典

架构解决了协作边界，下一个问题是规则。LLM-Wiki 需要一份 Skill 文件告诉 AI 该干什么。

这个东西经历了一次典型的膨胀—收缩周期。一开始只有十几条规则，跑起来之后总觉着这里不够、那里可以更好，于是一条一条往上加。提到多个概念时先做对比分析，超过五百字生成要点摘要，回答前先检索相关 Wiki——很快加到近三百行。

然后发现一个反直觉的事实：规则越多，AI 的表现反而越机械。

原因后来想清楚了。大语言模型本身具备对比分析、深度综述、要点总结这些能力。我把这些能力又用规则规定了一遍，它不仅没变强，反而在不需要的场合也强行套用。规则本意是规范行为，结果却压制了它本来就有的判断力。

收缩的转折点是问自己一个问题：这份 Skill 文件里，哪些东西是 AI 靠自然对话理解不了的？

答案只有三个：边界——哪里能碰哪里不能碰。禁忌——绝对不能做的事。触发——什么关键词对应什么动作。

至于怎么做、用什么格式、写到什么深度，这些交给 AI 基于上下文自己做判断。

最后 Skill 压回几十行。核心就六条：身份定义、信息来源、输出空间、触发词、检索优先级、规范维护。

我把这个设计尺度总结为：规则应该像宪法，不是民法典。它只画边界，不规定公民的每一个行为。

这个判断不只是用在 Skill 设计上。它后来成了一个通用的评估标准：每次有人提议加一条新规则，先问一句——这个东西 AI 自己能不能判断？如果能，就不要写成规则。

四、试探过的方向及其价值

有几个方向花了不少时间试探，最后没有留在方案里。但它们不是弯路，是推演成本。

状态机。早期设计过一套复杂的状态机来管理人和 AI 在同一文件里的编辑权限：ai-draft → human-reviewed → evergreen → needs-update。每个文件打标签，不同状态不同权限。

结果是人和 AI 都不遵守。人老是忘记改标签，AI 在多个状态之间犯迷糊。

这段试探的价值在于：它用实践确认了一个后来反复出现的结论——协作边界应该用物理方式解决，而不是用标记。这个结论直接影响了 LLM-Wiki 的目录隔离，后来也影响了 OpenViking 的独立文件方案。

长 Prompt。试过把所有写作规范、格式要求、质量标准都塞进系统 Prompt。结果 Prompt 越来越长，AI 输出反而越来越飘。有些规则隐性冲突，有些在特定场景下不适用，AI 没有判断该用哪条不该用哪条的灵活性。

这段的价值在于：它让我把规范和规则分开了。规范交给 Schema，可读可改可演进。规则只留给 Skill，只定义边界。让 AI 参与维护规范，而不是人单方面定死然后强制执行。

五、留在我口袋里的东西

经过这些试探和收缩，方案收敛到了一个极简版本。三个文件夹，一份几十行的 Skill，一个编译动作。

留下来的东西，解决了个人知识管理最核心的几个矛盾：人和 AI 的边界怎么划、知识怎么持续生长、规范怎么灵活维护。那些没有留到最后的方向——状态机、长 Prompt、过度细化的规则——每一段试探都在帮我摸清某个边界的形状。

回顾这次探索，从理念到架构到规则设计，有一条线始终贯穿：找到正确的粒度。协作边界用目录不用标签，是粒度的选择。规则只画边界不规定行为，是粒度的选择。编译提前消化、检索临时查找，是流程粒度的选择。每一次推演和收缩，本质上都是在找那个“恰好够用”的粒度。而确定这个粒度的，始终是人——人的判断、人的审美、人在每一个决策点上的选择。AI负责编译的繁重工作，人负责编译的方向与边界。

那些不在最终方案里的试探，不是错误。是排错成本。这笔成本付了，最后的简单才有底气。

写在最后

这次探索的起因是 Karpathy 那篇文章。他提了一个方向，我用两周把它落到了一套可以跑的方案里。

现在的方案长这样：三个文件夹，一份几十行的 Skill，一个编译动作。没了。这不是一开始就想清楚的，是把复杂的方向都试过一遍之后，才看清简单的那个为什么是对的。

有一件事从头到尾没变过：这套东西不管架构多巧妙、规则多精准，它的输出上限卡在喂进去的 Raw 质量上。编译本身不创造新知识，只是重组已有信息。垃圾进，垃圾出。Raw 里放的是随手存的文章、没核实过的观点、自己都没读透的摘要，Wiki 里长出来的也只能是这些低质信息的排列组合。知识能长成的高度，编译的起点已经决定了。