如何从零搭建Obsidian知识库：把你的知识库变成可复用的Agent Skill

如何从零搭建Obsidian知识库：把你的知识库变成可复用的Agent Skill 如何从零搭建Obsidian知识库：把你的知识库变成可复用的Agent Skill Modified May 20 02.如何做一个你自己的Skill 不是什么都适合变成Skill。我总结了三条标准。 第一，高频重复的工作流。 你每天做、每周做、重复做的工作，最适合变成Skill。比如我写日报，每天早上走一遍流程，变成Skill之后，我说"生成日报"，AI自动执行。 第二，有明确输入输出的任务。 输入是什么，输出是什么，中间步骤是什么，清清楚楚。比如"给一篇文章链接，生成海报"，输入是链接，输出是海报图片，中间步骤是提取内容、诊断需求、生成brief、构建prompt、出图。吴熳老师的wuman brief to poster Skill就是这个逻辑。 给Codex一篇公众号文章，用这个开源skill直出优雅海报 第三，需要上下文理解的复杂任务。 这 不只"翻译这段文字"那么简单，而是"参考我知识库里日报模板的格式，整理今天的聊天记录"。这里的关键是"参考我知识库"，AI需要知道去哪里找规则，怎么匹配你的个人偏好。 什么样的知识不适合变成Skill？一次性的、创意性的、需要人工判断的。比如"帮我写一首诗"，每次需求不同，不适合固化。比如"这个设计好不好看"，需要人的审美判断，AI做不了。 具体怎么做？我以自己的x scan为例，走一遍。 首先，从知识库里提取工作流。 打开我的知识库，找到02 Areas/AI工具助手/X资源收藏/这个目录。 里面存着x scan的原始脚本、配置文件、运行日志。 但脚本不是工作流，工作流是我每天怎么用它：检查Chrome、设置环境变量、运行x scan、过滤关键词、去重、生成Markdown文件、存进知识库。 这个流程我每天都在做，但之前只存在脑子里。现在要把它写下来。 接着，写成结构化Skill文件。 Skill文件的标准格式是SKILL.md，包含两部分： YAML frontmatter（前置信息） ：必填 name （名称，kebab case格式）和 description （描述，说明做什么+什么时候用），可选 metadata 声明运行时需求（比如需要什么环境变量）。 Markdown body ：执行步骤、输出格式、示例、故障排查等实际指令。 再举个例子。假设你想写一个"整理微信聊天记录"的Skill，SKILL.md可以这么写： Code block Plain Text Copy name: wechat daily reportdescription: 整理微信聊天记录，按日报模板格式输出日报。当用户说"生成日报""整理今天的群聊""跑日报"时触发。 工作流程 1. 读取知识库中的日报模板： 2. 获取当天聊天记录（00:00 23:59） 3. 去重：排除系统消息、撤回消息 4. 分类： 资源分享（链接、文章、工具） 讨论热点（多人参与、有争议） 边缘信号（X/HN/GitHub的行业趋势） 5. 统计：计算每个人发言次数，生成龙王榜 6. 按模板格式输出日报 输出格式 标题： 📰 SimonlinのAI学术交流（兄弟姐妹）· 日报 资源分享在顶部 龙王榜紧随其后 事件按时间顺序排列 每条事件含：标题、内容叙述、毒舌点评 结尾：今日总结（最卷的人/最佳气氛组/最佳助攻/最佳预言家） 故障排查 如果获取不到聊天记录，检查wechat cli服务是否运行 如果去重后消息数为0，检查时间范围是否正确 如果输出格式错乱，重新读取日报模板 这就是SKILL.md的核心结构：frontmatter告诉AI这是什么、什么时候用，body告诉AI具体怎么做。 x scan的SKILL.md也是这个逻辑。 最后，测试迭代。你以为写好Skill就万事大吉？不，其实才刚刚开始。 因为x scan我跑了5轮测试才稳定... 第一轮超时，第二轮抓取太少，第三轮去重逻辑有问题，第四轮格式不对，第五轮才正常。 每次测试发现问题，回到Skill文件修正，再测。 这个过程很重要，因为Skill不是写一次就完，是不断迭代的过程。 03.Skill的进化之路 Skill有三个层级—— • 本地Skill，只给自己用，存在你的Agent的skills目录下。你的个人工作流，你的个人偏好，你的个人规则。 • 共享Skill，上传到GitHub，别人能装能用。x scan我上传到了 github.com/simonlin000/x scan ，别人用npx skills add就能装。这里有个关键点：共享Skill要写好README，特别是"For AI Agents"板块，因为总有人会用AI帮他安装的，所以得告诉其他AI怎么安装、怎么配置、怎么使用。 • 生态Skill，ClawHub上的Skill市场，168万+ SKILL.md文件。SkillsVote项目统计了这些数据，你可以搜索、安装、评价别人的Skill。你的Skill从本地到共享到生态，影响力越来越大。 如果你已经按前面的教程建好了Obsidian知识库，你可以试试看做这件事情： 打开你的知识库，找一个你每周做三次以上的工作流。把它写成Skill。先别追求完美，给它写出来，测试，迭代。 下周你会发现：同样的事，你说一句话，AI自己按规则执行。 这就是Skill的真正价值： 不是你教AI做事，是AI按你的规则自己做事。 感谢你看到这里。 如果觉得这篇文章还不错，欢迎： 点赞，推荐，转发 给你身边正在用AI的朋友，让他也能把知识库变成可复用的Skill。 我建了一个AI交流群，群里都是爱好AI的朋友，这个群有AI，也有爱。感兴趣的话，移步到公众号后台，回复： "进群" ， 和朋友们一起聊关于AI的那些事儿。 我是Simonlin，下次见。 给Codex一篇公众号文章，用这个开源skill直出优雅海报 github.com/simonlin000/x scan 02.如何做一个你自己的Skill 不是什么都适合变成Skill。我总结了三条标准。 第一，高频重复的工作流。 你每天做、每周做、重复做的工作，最适合变成Skill。比如我写日报，每天早上走一遍流程，变成Skill之后，我说"生成日报"，AI自动执行。 第二，有明确输入输出的任务。 输入是什么，输出是什么，中间步骤是什么，清清楚楚。比如"给一篇文章链接，生成海报"，输入是链接，输出是海报图片，中间步骤是提取内容、诊断需求、生成brief、构建prompt、出图。吴熳老师的wuman brief to poster Skill就是这个逻辑。 给Codex一篇公众号文章，用这个开源skill直出优雅海报 给Codex一篇公众号文章，用这个开源skill直出优雅海报 第三，需要上下文理解的复杂任务。 这 不只"翻译这段文字"那么简单，而是"参考我知识库里日报模板的格式，整理今天的聊天记录"。这里的关键是"参考我知识库"，AI需要知道去哪里找规则，怎么匹配你的个人偏好。 什么样的知识不适合变成Skill？一次性的、创意性的、需要人工判断的。比如"帮我写一首诗"，每次需求不同，不适合固化。比如"这个设计好不好看"，需要人的审美判断，AI做不了。 具体怎么做？我以自己的x scan为例，走一遍。 首先，从知识库里提取工作流。 打开我的知识库，找到02 Areas/AI工具助手/X资源收藏/这个目录。 里面存着x scan的原始脚本、配置文件、运行日志。 但脚本不是工作流，工作流是我每天怎么用它：检查Chrome、设置环境变量、运行x scan、过滤关键词、去重、生成Markdown文件、存进知识库。 这个流程我每天都在做，但之前只存在脑子里。现在要把它写下来。 接着，写成结构化Skill文件。 Skill文件的标准格式是SKILL.md，包含两部分： YAML frontmatter（前置信息） ：必填 name （名称，kebab case格式）和 description （描述，说明做什么+什么时候用），可选 metadata 声明运行时需求（比如需要什么环境变量）。 Markdown body ：执行步骤、输出格式、示例、故障排查等实际指令。 再举个例子。假设你想写一个"整理微信聊天记录"的Skill，SKILL.md可以这么写： 这就是SKILL.md的核心结构：frontmatter告诉AI这是什么、什么时候用，body告诉AI具体怎么做。 x scan的SKILL.md也是这个逻辑。 最后，测试迭代。你以为写好Skill就万事大吉？不，其实才刚刚开始。 因为x scan我跑了5轮测试才稳定... 第一轮超时，第二轮抓取太少，第三轮去重逻辑有问题，第四轮格式不对，第五轮才正常。 每次测试发现问题，回到Skill文件修正，再测。 这个过程很重要，因为Skill不是写一次就完，是不断迭代的过程。 03.Skill的进化之路 Skill有三个层级—— • 本地Skill，只给自己用，存在你的Agent的skills目录下。你的个人工作流，你的个人偏好，你的个人规则。 • 共享Skill，上传到GitHub，别人能装能用。x scan我上传到了 github.com/simonlin000/x scan ，别人用npx skills add就能装。这里有个关键点：共享Skill要写好README，特别是"For AI Agents"板块，因为总有人会用AI帮他安装的，所以得告诉其他AI怎么安装、怎么配置、怎么使用。 github.com/simonlin000/x scan • 生态Skill，ClawHub上的Skill市场，168万+ SKILL.md文件。SkillsVote项目统计了这些数据，你可以搜索、安装、评价别人的Skill。你的Skill从本地到共享到生态，影响力越来越大。 如果你已经按前面的教程建好了Obsidian知识库，你可以试试看做这件事情： 打开你的知识库，找一个你每周做三次以上的工作流。把它写成Skill。先别追求完美，给它写出来，测试，迭代。 下周你会发现：同样的事，你说一句话，AI自己按规则执行。 这就是Skill的真正价值： 不是你教AI做事，是AI按你的规则自己做事。 感谢你看到这里。 如果觉得这篇文章还不错，欢迎： 点赞，推荐，转发 给你身边正在用AI的朋友，让他也能把知识库变成可复用的Skill。 我建了一个AI交流群，群里都是爱好AI的朋友，这个群有AI，也有爱。感兴趣的话，移步到公众号后台，回复： "进群" ， 和朋友们一起聊关于AI的那些事儿。 我是Simonlin，下次见。 🔗 原文链接： https://mp.weixin.qq.com/s/3B8Zwz6m... https://mp.weixin.qq.com/s/3B8Zwz6m... 原创 Simonlin Simonlin Simonlin的精神世界2026年5月20日 09:22 福建 Hello啊朋友们，我是Simonlin，用通俗易懂的语言，手把手带你玩转AI，提高10倍效率！ 上一篇我讲了怎么用x scan当信息守门员，自动从X、GitHub、RSS抓取AI相关内容，存进Obsidian知识库。 如何从零搭建Obsidian知识库：让AI替你当信息守门员（附工具资源） 如何从零搭建Obsidian知识库：让AI替你当信息守门员（附工具资源） 但是接下来，你可能会遇到这个问题—— 信息是收集了不少，但每次让AI整理的时候，都要重新解释一遍规则。 那有没有办法让AI记住这些规则，下次直接按规则执行？ 这个问题，我觉得必须得跟朋友们好好说道说道。 我刚开始用AI的时候也是这样。每天早上打开Cola，说"帮我整理昨天的群聊"，然后从头解释：先去重，再按主题分类，然后提取每条推文的核心观点，最后按日报模板格式输出。 解释一次两次还行，每天解释就疯了。我感觉自己不是在用AI，是在教一个永远记不住的学生。 这件事儿一度让我十分苦恼。 直到有一天，我突然想到：能不能把它做成一个Skill？ 01.最近很火的Skill，到底是个啥？ Skill是啥？ 举个栗子你就知道了。 千九是我们群的电商设计大佬。他每天用GPT生成电商详情页，流程很固定：先让GPT反推提示词，按模块区域单独生成场景图，再替换到详情页中。 这个流程他做了几百次，闭着眼睛都能走完。但每次都是手动操作——打开GPT，输入提示词，等生成，下载图片，打开PS，替换，检查效果。 昨天，他在群里说： "我想把这个流程蒸馏成一个Skill，让Codex直接调用。" 其实千九这句话，说出了很多人没意识到的事： 知识库里的工作流，如果只存着不用，就是死的。变成Skill，才是活的。 这句话属实是说到点子上了。 x scan的整个流程，就是被我写成了Skill。以前我说"跑x scan"，后面要跟一大串解释。现在我说"跑x scan"，AI自己知道怎么做。整个过程不需要我解释。 这就是Skill的价值： 你把规则写一次，AI按规则执行无数次。 但很多人把Skill和提示词搞混，我澄清一下。 Skill不是什么？ 它不是提示词。提示词是一次性的，你写一段发给AI，AI做一次。下次再做，你得重新发。 它也不是笔记。笔记是给人看的，你自己看，按步骤操作。Skill是给AI执行的，AI读到之后，按指令自动执行。 Skill是可复用的。你写好Skill文件，存进系统，AI随时能调用。 它的本质，其实就是三个东西： 结构化指令 + 执行逻辑 + 上下文理解。 • 结构化指令告诉AI要做什么，步骤是什么，输出格式是什么。 • 执行逻辑告诉AI用什么工具，调什么API，怎么处理异常。 • 上下文理解告诉AI去哪里找相关背景信息，怎么匹配你的个人偏好。 x scan最早是一个Python脚本，256行代码。但脚本有个问题：只有我会用。别人拿到脚本，不知道怎么配置环境变量，不知道怎么调参数，不知道输出格式。 后来我把它改成Skill。加了一个SKILL.md文件，用英文写了name（名称）、description（描述）和具体的执行步骤。 改完之后，任何人装了这个Skill，说"跑一下x scan"，AI就知道怎么执行。不需要解释，也不需要一次次的纠正。 这就是Skill和脚本的区别： 脚本给程序员用，Skill给所有人用。