Karpathy的AI知识库方法很好用，但不一定适合你

最近，一位AI领域的重要人物分享了他构建LLM知识库的方法，引发了广泛关注。这套方案的核心思路是：与其让AI每次都去原始资料中查找答案，不如让AI帮助用户将知识编译成一个持续维护的结构化Wiki系统。听起来很有道理，但实际使用效果如何，需要结合具体场景来分析。

学习研究场景：完美适配

这套方法采用三层架构设计：Raw层、Wiki层和Schema层。Raw层存放原始资料，如博客文章、论文、笔记等；Wiki层由AI根据原始资料自动生成结构化的知识条目，包括概念解释、人物介绍、产品专题、摘要索引等内容；Schema层则是规则文档，定义AI如何组织Wiki内容、命名文件以及建立条目间的交叉引用。整个系统借助Obsidian和Claude Code等工具实现自动化管理。

内容创作场景：需要调整

但如果你是内容创作者，直接照搬可能就会遇到问题。关键差异在于知识库的结构逻辑不同。Karpathy的方案是从Raw到Wiki，核心是把外部信息结构化。但创作者的知识库通常是IPO结构：Input（输入）→Processing（加工）→Output（输出）。想让AI理解你的思想和风格，应该喂给它的是Output（你的原创内容），而不是Input（你看到的内容）。因为AI需要学习的是“你怎么想”，而不是“你看了什么”。此外，AI生成的内容可能与你的真实观点存在偏差，需要人工把关确认。

关于企业应用，这套方法存在明显局限。首先是规模上限问题——目前测试的体量大约是100篇文章、40万字，当文档数量增加到数百上千时，索引文件可能超出上下文窗口，最终仍需引入分片和检索机制，这就变成了'RAG-over-wiki'。其次是权限管理缺失，企业级RAG系统通常具备成熟的RBAC权限控制，而LLM Wiki目前还无法满足这一需求。最后是引用精确性问题，企业场景对来源追溯要求很高，但完全由LLM维护的Wiki可能会产生幻觉关联，一旦错误写入知识库，会影响后续所有查询结果。

企业知识库场景：规模受限

如有侵权，请联系删除。