别用飞书文档当知识库了,试试 Git + LLM 自动编译

Photo by Pexels

4 月 3 日，Andrej Karpathy 在 X 上发了一条帖子，讲他怎么用 LLM 管理个人知识库。

帖子的数据很夸张：1500 万浏览，8.8 万收藏。

他的做法简单粗暴——把论文、文章、笔记等原始资料丢进一个文件夹，让 LLM 自动”编译”成一套带分类、摘要、交叉链接的 Markdown Wiki。大概 100 篇文章，40 万字，他自己几乎没写一个字。

他给了一个精准的类比：Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

这个方案解决了个人知识管理中一个长期痛点——谁来维护。答案是 LLM 来。

但看完之后我一直在想一个问题：个人知识库解决了，团队的呢？

· · ·

团队知识库，一个老大难问题

几乎每个团队都试过搭知识库。Confluence、飞书文档、Notion、语雀……工具换了一茬又一茬。

结局出奇一致：前三个月热火朝天，半年后变成信息坟场。

不是工具不行，是这件事本身就难。难在哪？

第一，知识散落在各处。技术方案在 Confluence 里，需求讨论在飞书群里，排查经验在某人的本地笔记里，架构决策在某次会议的录音里。你想找一个问题的完整上下文，得翻四五个系统。

第二，写了没人维护。文档最怕的不是没有，是过时。一份半年前的技术方案，接口改了三版，但文档还停留在初版。新人照着做，踩坑了才发现。写文档已经很累了，谁还有精力持续更新？

第三，知识在人脑里，不在系统里。真正值钱的经验——为什么选了方案 A 而不是 B、这个 bug 上次怎么解的、这个业务逻辑为什么这么设计——全装在个别人脑子里。人一走，知识就断了。

第四，新人接手等于从零开始。理论上知识库是为了降低新人的上手成本。但实际上新人面对的是一堆不知道哪篇过时、哪篇还有效的文档，不敢信也不敢不信。

归根到底，团队知识库的核心矛盾是：知识产出是分布式的，但知识维护需要一个中心化的”管理员”。没有人愿意持续当这个管理员。

· · ·

Karpathy 方案的核心启发

回到 Karpathy 的 LLM Wiki。他的方案之所以引起这么大反响，不是因为用了什么新技术，而是他想清楚了一个架构问题：

他的架构分三层：

这里面最关键的洞察是——知识像代码一样被版本管理。每次变更有迹可循，可以 diff，可以回滚，可以 review。

而维护者，从人变成了 LLM。

这给团队知识库的问题指了一条路。

Photo by Luis Gomes / Pexels

· · ·

一种落地思路：Git 大仓 + LLM 自动编译

Karpathy 的方案是个人用的。要搬到团队，需要解决两个额外问题：多人协作和知识聚合。

我最近在团队里试了一种做法，核心思路是：用 Git 仓库当知识的”源代码”，用 LLM 当自动编译器和聚合器。

具体分四步。

第一步：每个成员在自己的分支提交原始知识。

团队 Git 仓库里，每个人有自己的分支或目录。排查了一个线上问题？写下来提交。做了一次技术选型？把决策过程记下来。不需要多正式，哪怕就几行笔记。

用 Git 而不是飞书文档，有一个根本性的好处：版本控制是天然的。谁写的、什么时候写的、改了什么，Git log 全有。知识从第一天就有了完整的变更历史。

第二步：LLM 自动将碎片编译为结构化 Markdown。

成员提交的可能就是一段粗糙的笔记，甚至是一段聊天记录的截图。LLM 的工作是把它”编译”成结构化的知识页面——补上背景、提取关键结论、标注相关概念、生成摘要。

这个过程可以做成自动化：成员 push 代码 → 触发 CI/CD → LLM 读取新提交 → 生成或更新对应的知识页面。

第三步：LLM 定期聚合全团队知识。

这是从个人到团队最关键的一步。单个成员的知识是碎片化的，但 LLM 可以做全局视角的事：

— 张三上周排查的内存泄漏和李四上个月的性能优化，其实是同一个组件的问题，LLM 把它们关联起来。

— 团队分别在三个项目里用了三种不同的缓存策略，LLM 生成一份对比分析。

— 某个技术方向有五个人都记了笔记，LLM 综合成一篇完整的综述。

这种聚合能力，是人类知识管理员根本做不到的——没人能读完全团队所有人的笔记。

第四步：知识自动注入成员的 AI 工具上下文。

聚合出来的知识不应该躺在仓库里等人来翻。更好的做法是——直接注入到成员日常使用的 AI 工具中。

小王用 CodeBuddy 写代码，打开一个模块，相关的架构决策、踩坑记录、最佳实践已经在他的 AI 上下文里了。不需要先去翻知识库，不需要记住文档在哪，知识直接跟着工作场景走。

反过来也成立。小王在 AI 工具里排查了一个线上问题，整个对话过程——定位思路、尝试方案、最终结论——本身就是一份高质量的知识。LLM 可以自动识别这段对话中有价值的部分，抽取关键结论，提交回 Git 知识库，进入下一轮编译和聚合。

这就形成了一个闭环：知识库喂给 AI 上下文，AI 上下文又反哺知识库。越用越多，越多越准。

Photo by Pexels

· · ·

非开发同学怎么办？用 Skills 抹平 Git 门槛

说到这里，可能有人会想：方案挺好，但我团队里有产品经理、有运营、有设计师，让他们用 Git？

确实，git clone、git push 这些命令对非开发同学来说是真实的门槛。

但换个角度想——他们其实不需要”会用 Git”，只需要”能把知识交给系统”。

这正是 LLM Skills 可以发挥的地方。

把 Git 操作封装成 LLM 可以调用的 Skills（技能包）：上传知识、下载知识、搜索知识、查看更新。非开发同学面对的不是命令行，而是一个对话框。

背后的 git add、git commit、git push，全部由 LLM 的 Skill 自动完成。用户不需要知道仓库地址，不需要配 SSH key，甚至不需要知道 Git 是什么。

本质上，LLM 在这里扮演了两个角色：对上是自然语言接口，对下是 Git 操作代理。非开发同学看到的是聊天框，开发同学看到的是 Git 仓库。双方在同一个知识体系里协作，但用各自舒服的方式。

技术门槛的问题，LLM 一层封装就解决了。

· · ·

为什么是 Git，不是飞书文档

最后聊一个可能的疑问：为什么底层要用 Git，而不是直接在飞书文档或 Notion 上让 LLM 干活？

三个原因。

一、Git 是天然的版本控制系统。知识的变更历史、谁写的、什么时候改的、改了什么，Git 原生支持。飞书文档的版本历史功能比起来就是个玩具。当 LLM 大规模更新 Wiki 页面时，你需要 diff 来检查它做了什么。

二、Markdown 是 LLM 的母语。LLM 读写 Markdown 的能力远强于操作飞书文档的 API。Markdown 是纯文本，没有富文本编辑器的格式噪音，LLM 可以精准地做增删改查。

三、Git 仓库可以对接一切。CI/CD 自动触发知识编译、Webhook 通知更新、MCP 协议接入 LLM Agent——这些在 Git 生态里都是现成的。飞书文档是一个封闭花园，Git 是一个开放平台。

说到底，Git + Markdown 是把知识当代码来管理。代码管理这套体系已经被全球开发者验证了几十年，分支、合并、Review、CI/CD 全是现成的。知识管理不需要再发明轮子。

· · ·

写在最后

团队知识管理这个问题喊了很多年，工具换了一个又一个，核心痛点从来没变过——不是”怎么存”的问题，是”谁来维护”的问题。

Karpathy 用他的 LLM Wiki 给出了一个回答：让 LLM 来。

从个人到团队，多了协作和聚合的需求，但核心模式不变——人负责产出知识碎片，LLM 负责编译、关联、维护，再把知识注入到每个人的 AI 工作流里。而工作流中产出的新知识，又自动回流。Git 提供版本控制和协作基础设施，Skills 抹平非技术成员的使用门槛。

这套东西不复杂。一个 Git 仓库，一套 LLM Skills，几条自动化规则，一个双向打通的知识闭环，就能跑起来。

真正难的是迈出第一步：让团队里每个人愿意把脑子里的东西写下来，哪怕只是几行。

剩下的，交给 LLM。