基于大模型、SKills 的知识管理

张开发
2026/6/6 19:52:22 15 分钟阅读
基于大模型、SKills 的知识管理
今天不聊新工具聊点更高级的东西——三个巨佬的知识管理哲学还有我自己的知识管理及内容生成工作流Karpathy昨天 Andrej Karpathy斯坦福 PhD、OpenAI 创始成员、前特斯拉 AI 总监、CS231n全球最火深度学习课程缔造者发了条长推炸了整个 AI 圈子。这条推文的核心观点是他现在把大部分 token 预算花在了操作知识上而不是操作代码。什么意思他搭了一套 LLM 驱动的个人知识库系统用 Obsidian 做前端Markdown 做底层格式LLM 负责一切脏活累活。整个系统的架构可以拆成五个模块 Karpathy 知识库系统五大模块1. 数据导入Data Import把各种原始素材——论文、文章、代码库、数据集、图片——统统丢进raw/目录。用 Obsidian Web Clipper 浏览器插件一键裁剪网页文章为.md文件配合快捷键把相关图片下载到本地。核心思路先不管三七二十一把所有原始材料攒在一起。2. 知识编译Wiki Compilation这是整个系统最核心的一步——让 LLM 把raw/目录里的散碎材料编译成一个结构化的维基。具体做什么为每份原始数据生成摘要建立反向链接backlinks将数据分类到不同的概念为每个概念撰写专题文章将所有文章互相链接注意这个词编译compileKarpathy 用的是编程的隐喻——原始数据是源码维基是编译产物LLM 就是那个编译器3. 问答驱动QA当维基长到足够大他举例说他某个研究方向的维基有约 100 篇文章、40 万字就可以开始向 LLM Agent 提各种复杂问题了。一个关键的发现他本以为需要搞复杂的 RAG但实际上 LLM 自己维护的索引文件和摘要就够用了。在这个规模下Agent 可以比较轻松地读取所有重要的相关数据。这点我必须插一嘴——40 万字对现在的长上下文模型来说真不算什么。Gemini 的百万 token 窗口Claude 的 200K 上下文处理这个量级的知识库绑绑有余。Karpathy 说不需要 RAG在这个规模下我同意4. 输出呈现OutputKarpathy 不喜欢在终端里看答案他更倾向于让 LLM 生成 Markdown 文件、Marp 格式的幻灯片、matplotlib 图表然后在 Obsidian 里直接查看更聪明的是他会把输出归档回维基这样每次探索和查询都会累积在知识库里让它越用越富5. 健康检查Health Check定期让 LLM 对维基做体检查找数据不一致的地方用网络搜索填充缺失信息发现有趣的关联建议新的文章候选提出下一步要调查的问题他说 LLM 在建议进一步的问题这件事上做得相当好。这不就是我们说的Agent 自主探索吗用一张流程图来理解 Karpathy 的系统Lex Fridman把知识库变成跑步伙伴Karpathy 发完推Lex Fridman 秒回——他也有类似的系统。Lex 的身份不用多介绍了吧全球最火的 AI 播客主持人他的 Lex Fridman Podcast 采访过 Elon Musk、Sam Altman、Mark Zuckerberg、Karpathy 本人以及一堆你叫得出名字的科技大佬Lex 的设置和 Karpathy 类似但有几个独特的点前端混合体Obsidian Cursor用来编辑 .md 文件 自己 vibe-coded 的网页终端Lex 不满足于 Markdown 的静态渲染——他经常让 LLM 生成动态 HTML 页面带 JavaScript这样他可以对数据排序、筛选交互式地调整可视化做播客的知识管理需求因为播客嘉宾覆盖的领域极广Lex 的研究兴趣数量和多样性远超普通人。这种场景下知识库方法的优势更明显——你不可能把所有领域的知识都记在脑子里。最炸裂的用法——跑步语音播客Lex 会让系统为特定主题生成一个临时的迷你知识库加载进 LLM然后在 7-10 英里的长跑中开启语音模式。跑步的时候它就变成了一个交互式播客——他可以随时提问、听答案、深入探讨。你品品一个人一边跑步一边跟 AI 讨论量子力学或者神经科学。知识的摄入方式从坐着读变成了边跑边聊kepanoObsidian 创始人的冷水然后 Obsidian 的创始人 kepanoSteph Ango出来说话了他没有否定 Karpathy 的方法而是提出了一个很微妙的警告“我更喜欢我的个人 Obsidian 仓库具有高信号噪声比并且所有内容都有已知的来源。”kepano 的核心观点你的个人笔记库应该是你的思想的体现而不是 AI 的。他的建议是保持个人仓库干净——这是你的思维主场**给 Agent 一个单独的杂乱仓库**——让 AI 在那里随便折腾只在 Agent 产出有用工件时才手动搬到主仓库他担心什么如果人类写的和 AI 写的混在一起太多搜索会被 AI 生成内容淹没反向链接不再局限于你真正思考过的内容图谱视图变成 AI 的知识图谱不再是你的你无法追溯哪些想法是自己的、哪些是机器生成的这段话的背后是 kepano 一贯的哲学他写过一篇很有名的文章叫 **“File over app”**文件优先于应用核心主张是如果你希望你的写作在 2060 年甚至 2160 年的电脑上仍然可读那它最好在 1960 年代的电脑上也能被读取。他还写过 **“Don’t delegate understanding”**不要把理解力外包——你可以让 AI 帮你干活但不能让 AI 替你思考理解力本身就是你最大的资产在他的个人 Obsidian 实践中他甚至直接说“有人问我能不能用 LLM 自动化笔记整理但我不想这么做。我享受这个过程。做这种维护工作帮助我理解自己的模式。”老章的观点Karpathy 的方法论是天才级别的Lex 的应用场景让人拍案叫绝kepano 的警告确实发人深省他们三个人讲的是知识管理链路上不同的环节 我在做的事补上最后一公里Karpathy 搭的是一个知识积累与检索系统——把数据灌进去编译成知识然后查询和输出。但作为一个每周要输出 3-5 篇技术文章、配套口播视频、社交媒体内容的人我需要的不只是积累和查询我需要把知识变成内容产品推出去。这就是我做的事——知识管理的下游内容生产流水线。zhangAI/ # Karpathy 说的知识库├── 1-Wechat/ # 公众号文章成品库│ ├── Archive/ # 已发布文章│ └── ing/ # 正在写的稿子├── .agent/skills/ # 58 个 AI Skill执行层│ ├── 1-write_tech_article_pro/ # 技术文章撰写│ ├── 1-title_generator/ # 标题生成3种风格│ ├── 1-video-script-converter/ # 文章→口播稿│ ├── 1-doubao-tts-voice-clone/ # 口播稿→克隆语音│ ├── audio-to-video/ # 语音→竖版短视频│ ├── 1-upload-images-to-picgo/ # 图片→个人图床│ ├── design_svg_card/ # 知识卡片设计│ └── ...还有 50 多个├── Video/ # 视频产物│ ├── 口播稿/│ ├── 口播音频/│ └── 成品视频/├── Clippings/ # Karpathy 说的 raw/ 目录├── CLAUDE.md # AI Agent 的操作手册├── AGENTS.md # Codex 的上下文配置└── GEMINI.md # Gemini 的指令文件看出区别了吗Karpathy 的系统是raw/ → wiki/ → query——知识的上游。我的系统是素材 → skills/ → 文章 → 视频 → 社交媒体——知识的下游。它们不是竞争关系是上下游互补关系Karpathy 解决的问题是大量散碎信息怎么变成可查询、可增长的结构化知识 我解决的问题是有了知识和选题怎么高效地变成文章、视频、社交内容一篇文章从素材到成品视频我的 Skill 流水线是这样的一条命令帮我写篇技术文章触发write_tech_article_proSkill输出 Markdown 成品。然后转成口播稿触发video-script-converter接着用豆包转成音频触发doubao-tts-voice-clone最后音频转视频触发audio-to-video从一篇文章到一条短视频全程约 8 分钟传统方式需要 2-3 小时。所以理想的完整架构应该是把上下游接起来Karpathy 的知识编译层上游积累、编译、检索 ↓ 老章的内容生产流水线下游写作、配音、视频 ↓ 发布 多形态分发 ↓ 反馈回知识库闭环← 这一步大家都还没完全做好这也是我接下来要补的课——给自己的系统加上 Karpathy 式的知识编译层让过去写的每一篇文章都成为未来创作的养料。 关于 kepano 的污染论kepano 担心 AI 生成的内容会污染个人知识库他的解决方案是两个仓库——一个干净的给自己一个脏的给 AI这个担心是合理的不过在我的实际操作中我用的是另一条路溯源标记。在我的系统里每个 Skill 生成的文件都有清晰的来源标记——YAML 头部的author字段、文件路径本身比如Video/口播稿/一看就知道是 AI 转的、以及 Skill 的执行日志。这样不需要物理隔离也能知道每一段内容是谁写的、用什么工具写的、基于什么素材写的两种方案各有道理kepano 的物理隔离更干净纯粹适合把 Obsidian 当思维延伸的人我的溯源标记更灵活适合人机协作频繁、产出量大的场景不过 kepano 有句话我是完全同意的——**“Don’t delegate understanding”**你可以让 AI 帮你整理知识但你不能让 AI 替你理解知识如果你连自己知识库里的内容都没读过、没消化过那这个知识库再大也不是你的 Karpathy 最有远见的一句话Karpathy 整个推文我认为最有远见的一句话“随着仓库的增长自然地也想考虑合成数据生成 微调让你的 LLM 知道’数据在其权重中而不仅仅是上下文窗口。”这才是真正的终局——从上下文到权重现在所有的知识管理方案本质上都是在上下文工程的范畴内打转把知识塞进上下文窗口让 LLM 读取——管你是 RAG 还是直接长上下文但想象一下如果你能用自己积累的 40 万字知识库微调一个专属的小模型让它从骨子里理解你的领域知识和思考方式。那就不是你问它答了那是你训练了一个数字分身。 三人观点对比维度KarpathyLex Fridmankepano核心身份AI 研究者 / 教育者播客主持人 / 研究者Obsidian CEO / 产品哲学家知识库用途研究探索多领域播客准备个人思维记录对 LLM 的态度全面拥抱让 LLM 管理一切拥抱但重视多模态输出审慎警惕过度依赖Obsidian 角色只是前端渲染器混合前端之一思维的延伸核心哲学“编译知识”“知识要可交互”“文件优先于应用”最大贡献完整方法论框架语音交互式学习人机边界思考One More Thing三位巨佬给了我们三个视角Karpathy搭了知识管理的上游基建——raw/ → compile → wiki → queryLex打开了知识消费的新维度——语音对话、动态可视化、运动中学习kepano守住了最重要的底线——知识库的主人是你不是 AI而我在做的事情是补上下游的最后一公里——把知识变成文章、视频、社交媒体内容让它流动起来积累Karpathy→ 消费Lex→ 守护kepano→ 生产老章→ 反哺积累你的知识管理系统走到了哪一环学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

更多文章