去年在社群分享 Obsidian 工作流时不少朋友问我最多的一句话是“笔记越记越多回头看全是断头路怎么让知识自己串起来”当时我给不出特别好的答案。直到后来把 WorkBuddy 接进 Obsidian用本地模型跑通了一套“自动整理、自动关联、自动更新”的飞轮我才敢说知识库真的可以做到“自己进化”而你只需要在开头用力推一把。这个方案的核心其实不复杂Obsidian 负责存笔记、画关系图谱WorkBuddy 负责当“管家”定时调度本地模型去扫描、归类、补链接、做摘要。整个过程数据不出本机隐私可控跑起来之后你唯一要做的就是把素材丢进 Inbox剩下的分类、打标签、补双链、维护摘要机器帮你干。适合谁适合 Obsidian 重度用户、用本地模型做个人知识管理的折腾党以及所有觉得“记笔记轻松、整理笔记要命”的普通人。1. 整体设计思路为什么是 Obsidian WorkBuddy 本地模型1.1 先想清楚知识库为什么需要“自进化”传统知识库的问题是单向的你往里写笔记它负责存偶尔手动建一个链接。刚搭好时感觉很清爽但三个月后笔记数量上来整个库就像一间没有整理过的仓库——东西都在但你找不到也不记得当初为什么留它。这种情况下知识库不仅不帮你思考反而在消耗你的注意力去“维护”。“自进化”要解决的正是“维护成本”这件事。一个能自己进化的知识库至少要做三件事新笔记进去后被自动归类、打标签内容相关的旧笔记会被自动建立关联过一段时间后热点主题会被自动聚合、提炼、更新摘要。听起来像科幻但拆开之后每一环都是很成熟的技术文件解析、文本抽取、向量相似度、模板回写、定时调度。WorkBuddy 在这里扮演的是“胶水层”和“调度层”。它不负责思考思考交给本地模型来完成它负责的是把“思考结果”变成“对 Obsidian 库的真实修改”比如写入标签、插入双链、更新 frontmatter。这种分工的好处是把稳定性问题隔离了——模型胡说了你最多丢几个标签不会把你的整个笔记库搞乱。1.2 为什么选 Obsidian而不是 Notion / 思源笔记 / Logseq我最早也纠结过一阵子当时在 Obsidian 和思源笔记之间反复横跳。思源笔记的双链和块级引用做得确实舒服尤其是它的块引用机制比 Obsidian 的文件级双链要精细。但最后让我定下来选 Obsidian 的是这两个原因一是纯本地 Markdown 文件任何脚本、任何工具都可以直接读改写二次开发成本极低二是插件生态和社区模板太丰富了配合 Homepage、Templater、Dataview 这些插件知识库的“骨架”可以搭得非常灵活。当然如果你是重度块级引用用户思源的块级双向链接体验更好如果你要多人协作Notion 更省心。但做“本地知识库自进化”这个场景Obsidian 的文件系统开放性几乎是没有对手的。你想让 AI 自动建链接前提是它得有权限直接读写你的笔记文件——这一点 Obsidian 天生就能做到。1.3 本地模型为什么选 Qwen2.5-7B-Instruct很多人问我直接用 ChatGPT 或 DeepSeek 的 API 不香吗香是香但对“自进化”这个场景用在线大模型有三个问题第一是隐私个人笔记里有大量碎片化信息不适宜全部传到云端第二是成本如果你每篇笔记都做定期更新摘要长期累积的 token 消耗并不低第三是稳定性在线 API 有网络延迟每次调度都可能卡壳定时任务根本跑不稳。所以就选了本地模型。Qwen2.5-7B-Instruct 是 7B 参数里的一个均衡点显存占用不算高普通消费级显卡乃至部分 16GB 内存的 Mac就能跑中文理解能力在同尺寸里属于第一梯队而且对“提取标签、输出 JSON、写摘要”这类结构化任务的表现很稳定。我最初也试过更小的 3B 模型速度是快了但抽取出来的标签经常五花八门同一意思能给你三个写法后来换到 7B准确率才达到可用的程度。2. 环境准备先把地基打好后面才省心2.1 三步搞定 WorkBuddy 安装与初始化WorkBuddy 的安装不算难但第一次用的人容易卡在“它到底是干嘛的”这个问题上。简单理解它是一个本地优先的 AI 工作台/自动化调度工具可以连接模型 API、读取本地文件、执行定时任务。你可以把它的 Skill 机制理解成“给 AI 写岗位说明书”告诉它笔记放在哪、按什么规则处理、处理完写到哪里。安装时我建议按照官方文档走一遍核心就三步下载安装包Windows / macOS / Linux 都有对应版本服务器环境还可以用 Docker 跑、安装后初始化一个工作区、在设置里填写模型接口。比较推荐的做法是让 WorkBuddy 直接以 OpenAI 兼容接口对接本地模型服务我用的是 Ollama 启动 Qwen2.5-7B-Instruct地址是http://localhost:11434/v1这样 WorkBuddy 的模型配置就和调用云端 API 一样简单只是把地址改成本地。有一点需要注意WorkBuddy 启动慢的问题不少人都遇到过。我的经验是如果卡在启动界面超过一两分钟多半是网络请求超时——它可能试图访问外网检查更新或拉取插件元数据。解决方法是离线安装所需组件或在配置里把自动更新关掉。具体按钮位置不同版本可能不一样但核心思路就是让它别在启动时依赖外网这个问题处理完启动速度能快上一个量级。2.2 搭好 Obsidian 知识库的骨架目录 模板 元数据Obsidian 本身的安装没什么好讲的关键是“骨架怎么搭”。我建议你在动手之前先想把知识库分成几个区。我自己的方案是简化版 PARA01_Inbox所有新笔记的入口、02_Projects有明确目标的项目笔记、03_Areas长期维护的领域笔记、04_Resources主题资料和素材、05_Archive归档区。每个笔记文件我强制带上 YAML frontmatter里面有title、tags、created、updated、related、summary这几个字段。你可能觉得繁琐但这一步恰恰是“自进化”能跑起来的关键——AI 整理笔记时需要稳定的字段去写入结果。如果你连 tags 字段都没有模型每次处理时还得猜写到哪里结果就乱套了。例如一篇新笔记的 frontmatter 初始状态是这样--- title: WorkBuddy 对接本地模型的踩坑记录 tags: [] created: 2026-01-12 updated: 2026-01-12 related: [] summary: ---然后正文随便写哪怕只是流水账。AI 之后会帮你把tags和related填上并生成summary。你用 Obsidian 自带的模板功能Templater 插件更好把这几行预填进去后面每次新建笔记就方便了。2.3 关系图谱要好看关键在“双链”而不是文件夹不少人看到 Obsidian 的关系图谱密密麻麻一片觉得高级。但如果你点开看大多数是文件放在同一个文件夹所以聚在一起这种“结构邻近”不是真正的知识关联。真正有价值的关系图谱节点之间必须通过 Markdown 里的[[双向链接]]连起来。所以我在设计自进化流程时给 AI 下了一条死命令整理笔记时一定要在related字段里写入至少 1-3 个现有笔记的链接。这样图谱才会有机生长。Obsidian 的关系图谱默认只会渲染文档里的[[]]链接和标签所以只要 AI 把双链写进正文或 frontmatter图谱就会自动长出来。这一步是“会进化”视觉化最直观的体验——你每天晚上瞄一眼图谱都能看到新的连线在蔓延。3. 手把手配置 WorkBuddy Skill让 AI 真正动起来3.1 Skill 一自动整理——给新笔记打标签、写摘要第一个要写的 Skill是处理01_Inbox里所有未经整理的笔记。思路是让 WorkBuddy 定时扫描这个目录找到没有补齐元数据的文件交给本地模型处理然后把结果写回文件。一个典型的 WorkBuddy Skill 配置大概长这样不同版本写法略有差异但逻辑是通用的name: inbox-sorter trigger: schedule: */30 * * * * # 每30分钟扫描一次 scan_dir: obsidian-vault/01_Inbox filters: - extension: .md - condition: metadata.tags 为空 或 metadata.summary 为空 action: model: qwen2.5-7b-instruct task: | 阅读这篇笔记内容完成以下任务 1. 提炼 3-5 个标签写入 frontmatter 的 tags 字段 2. 用一句话总结内容写入 summary 字段 3. 根据内容主题从知识库中寻找最多 3 篇相关笔记 在 related 字段中加入这些笔记的 [[链接]]。 4. 如果内容质量较差或只是临时灵感建议移入 Archive 否则保持原路径不变。 output: write_back_to_frontmatter_and_body这里有一个经验值得多说一句写任务指令时一定要明确告诉模型**“不要改变原文正文”**只更新 frontmatter 和追加关联区块。不然模型偶尔会在摘要生成时把正文也改写了这是我最早期踩过的坑。处理完成后建议在笔记正文末尾自动追加一个“AI 摘要”区块## AI 摘要 这篇笔记记录了 WorkBuddy 对接本地模型时的配置要点核心是使用 Ollama 提供 OpenAI 兼容接口。 ## 相关笔记 - [[Obsidian 插件推荐]] - [[本地知识库的元数据设计]]你会发现这个流程跑上两三天后Inbox 基本都是空的。新笔记丢进去最多半小时就被整理得干干净净标签、摘要、关联一应俱全。3.2 Skill 二自动关联——用相似度补齐“暗链接”手动双链靠人记总会有遗漏。何况人记笔记时很容易在脑内“以为”某两条笔记有关联但根本没有实际落笔。这个 Skill 的职责就是定期做一次全库扫描找出语义相似的笔记自动补上它们之间的关联链接。实现上并不需要用特别复杂的向量数据库。如果你用 WorkBuddy 的开发者平台可以直接调用它的文本嵌入能力但就算不用也有个“土办法”把每篇笔记的标题和摘要抽出来拼成一个纯文本清单丢给本地模型让它输出“哪些条目两两之间内容相关”的 JSON 结果。7B 模型做这种基础的文本相似度判断效果完全够用。我习惯把这类 Skill 设置为每周日凌晨跑一次每次最多处理 20 个候选组避免一次改动太多导致知识库震荡。处理时AI 会在合适的笔记里补上类似这样的句子“相关问题可参见 [[某某笔记]]”或者直接更新 frontmatter 的related字段。这里要注意让模型把新链接追加到已有链接列表里而不是覆盖这样能保住人工维护过的关联。这个 Skill 跑起来之后关系图谱的形态会发生质的变化。最初图谱是几个孤岛跑了几轮之后岛与岛之间会生出一批跨领域桥梁——比如“Obsidian 元数据设计”和“WorkBuddy 定时任务配置”这两篇看起来毫无关系的笔记竟然因为都涉及 YAML 解析产生了连接线。这个效果光靠自己手动维护几乎不可能做到。3.3 Skill 三自动更新——定期刷新高频笔记的摘要和时效性知识库里最怕的是什么是笔记过时了你还当宝贝一样引用。我见过不少人的笔记标题写着“2024 年最新方案”到了 2026 年还在当参考资料用。让知识库自进化就必须解决“时效性”问题。我的方案是两类笔记定期更新一类是summary为空的笔记这属于初始整理遗漏另一类是“被引用次数较多”的高频笔记——之所以重点关注它们是因为这类笔记被反复引用如果内容过时危害面最大。WorkBuddy 可以通过 Dataview 插件的查询结果导出或者直接解析 Markdown 文件统计每篇笔记被[[]]引用的次数生成一个高频笔记清单然后逐篇交给本地模型做“时效性检查”如果这篇笔记包含日期、版本号等时效信息就检查是否过期如果过期就在笔记头部追加一条提示说明“本笔记可能已过时请人工确认”。同时重新生成摘要保证引用你的人拿到的是一份当前状态下的准确描述。这个 Skill 的触发频率不用太高每两周跑一次就够。跑完之后建议在 Obsidian 里用 Dataview 生成一个“待人工确认的过时笔记”列表你只需要抽空扫一眼列表确认那些 AI 拿不准的内容即可。这样知识库就有了“持续维护”的机制不会因为记完就忘而腐烂。3.4 自定义指令设计几个让输出更稳定的 Trick在配置 Skill 时我总结了几个让模型输出更稳定的细节这里一并分享。第一输出格式一定要给死。比如要求标签必须用英文小写、用连字符分隔避免模型给出“机器学习、机器学习/Machine Learning”这种混乱的写法。个人的做法是在任务指令里明确规定“标签只能是英文小写字母、数字和连字符”。第二一定要让模型“只输出 JSON 或只做局部修改”不要让它自由发挥。自由发挥的后果五花八门有的模型会重新格式化整个文档有的会自作主张删除它认为“没用”的段落。我的经验是在指令里加一句“除非确认为纯垃圾内容否则不得删除正文里的任何信息”。第三加入“不确定就跳过”的防御性指令。比如模型面对一篇内容极其碎片化的笔记硬要它提炼标签结果可能很离谱。这时候让它写一个固定标记比如在summary里填“待人工整理”比强行生成一堆错误标签要安全得多。4. 实操过程从零跑通第一条自进化流水线4.1 在 WorkBuddy 里添加 Obsidian 工作区启动 WorkBuddy 后第一件事是创建一个新的工作区专门用于 Obsidian 知识库。工作区本质上是一个沙箱环境里面会存放 WorkBuddy 的配置文件、Skill 定义、日志等。由于 WorkBuddy 要直接修改 Obsidian 库所以工作区的目录权限要设好保证它可以读写你的笔记目录。然后在 WorkBuddy 的设置面板里添加你的 Obsidian Vault 路径。这里有个小建议在一开始就用绝对路径不要用相对路径。因为定时任务在不同工作目录下执行时相对路径很容易踩到“找不到文件”的坑。我当时在 Linux 环境部署时就因为路径配错浪费了一个下午。配置好之后可以先手动跑一个最简单的 Skill扫描某篇笔记只更新 tags。确认能正常读文件、调模型、写回文件之后再逐步扩展成完整的整理流程。整个链路打通了最后才挂上定时任务。4.2 本地模型服务配置Ollama 跑 Qwen2.5-7B-Instruct本地模型服务我用的是 Ollama。安装很简单装完之后在终端执行ollama pull qwen2.5:7b-instruct ollama serve默认情况下Ollama 会监听11434端口并且提供 OpenAI 兼容接口。如果你不确定服务是否正常可以用 curl 快速验证curl http://localhost:11434/v1/models看到模型列表返回就说明服务正常。然后在 WorkBuddy 的模型配置里填接口地址http://localhost:11434/v1模型名填qwen2.5:7b-instruct。如果你的机器没有 GPU7B 模型在 CPU 上也能跑就是速度慢一些如果显存或内存只有 8GB 左右建议降到qwen2.5:3b-instruct但标签抽取的稳定性会略降。我自己实测下来Qwen2.5-7B-Instruct 处理一篇 500 字左右的笔记在 M 系列芯片的 Mac 上大概需要 5-10 秒在无独显的 Windows 机器上可能需要 20 秒以上。如果笔记数量大建议调整 Skill 的扫描时间间隔别太频繁。4.3 用模板 Templater 规范新建笔记入口WorkBuddy 负责处理存量文件但知识库每天还会有新增。为了避免“新增笔记”也变成脏数据我强烈建议用 Templater 插件做一个“新笔记模板”这样每次新建笔记时frontmatter 自动带全字段正文自带一个小标题结构。我的模板文件大致是--- title: {{title}} tags: [] created: {{date}} updated: {{date}} related: [] summary: --- ## 背景 ## 核心信息 ## 我的想法 ## 待办/下一步这样做的好处是WorkBuddy 扫描时只看到它该处理的字段不用再花模型能力去“补全结构”准确率自然就高。而且有了固定的小节结构模型在生成摘要时更容易抓住重点。说到底一个能被 AI 高效处理的知识库首先得是一个结构规范的知识库。人都不喜欢收拾乱房间AI 也一样。4.4 跑通第一次自动化从手动触发到定时调度第一次跑通自动化建议遵循“手动 → 单文件 → 多文件 → 定时”的节奏第一步手动触发一个 Skill让 WorkBuddy 处理单篇测试笔记检查输出是否符合预期。第二步处理一个目录里的 5-10 篇笔记观察是否有笔记被模型改坏。第三步确认结果稳定后再配置定时触发器比如每 30 分钟扫 Inbox、每周日深夜做全库关联。定时任务建议遵循“多次小批量”原则而非“一次全量跑完”。因为一次性处理几百篇笔记一来耗时长二来一旦模型出现系统性错误全库都会受影响。分批少量执行即便出问题也只会波及少数几篇修复成本低。5. 常见问题与排查技巧实录5.1 模型把 frontmatter 写坏了怎么破这是最常遇到的问题。7B 模型在生成 YAML 时偶尔会在字段值里带上换行符或者把双引号写成中文引号导致 Obsidian 解析 frontmatter 失败。解决的思路是在 WorkBuddy 的 Skill 里加一道“书写校验”规则写完文件后校验 YAML 是否能被正常解析失败则自动回滚到处理前的版本。另一个非常有效的土办法是不让 AI 直接改写原文件而是让 AI 只输出标准 JSON由 WorkBuddy 的脚本负责把 JSON 合并进原文件的 frontmatter。AI 只负责“思考产出内容”实际写文件交给代码出错率直接下降一个数量级。我后期基本全部改成这种模式。5.2 双链[[笔记]]写不进 Obsidian 图谱偶尔会发生这样的怪事AI 明明在文件里写了[[相关笔记]]但 Obsidian 图谱里就是不显示。排查下来大多数原因是文件链接指向的笔记名和文件名不完全一致——比如文件名是“Obsidian 教程 2026”AI 写链接时写成了“[[Obsidian 教程]]”自然匹配不上。在 Skill 里加上一个约束“链接文本必须与目标文件名完全一致如果拿不准就只搜索文件名不要缩写或加年份注释。”这个规则加进去之后断链率低了很多。另外建议定期用 Obsidian 自带的“未解析的链接”面板检查一下看有没有模型生成的死链遇到手动批量修正即可。5.3 Inbox 里的笔记一直被重复处理这个问题也让人头大一篇笔记处理完了下次扫描又被拉去处理一遍标签越加越多、摘要反复改。解决方法是给系统一个“已处理”的信号。我是在处理完成的笔记里追加一个元数据字段ai_processed: true然后在 Skill 的过滤条件里显式排除所有ai_processedtrue的文件。逻辑虽然简单但确实能彻底避免重复加工。定时任务跑了一阵子之后建议打开 Obsidian 的 Git 插件或者文件历史版本功能检查 AI 最近一周的改动记录。一方面能让你心里有数“AI 到底动了哪些文件”另一方面万一发现异常修改也能快速回滚。知识库越是自动化越要有“审查”的习惯。5.4 速查表WorkBuddy Obsidian 自进化知识库问题排查问题现象最可能的原因解决办法WorkBuddy 启动很慢启动时尝试访问外网检查更新关闭自动更新离线安装依赖模型返回空内容本地模型服务未就绪或接口地址错误用 curl 验证/v1/models接口标签全是中文且格式混乱任务指令没有规定标签格式在 Skill 中强制“英文小写、连字符分隔”双链不显示链接名称与目标文件名不一致约束模型链接文本必须精确匹配文件名frontmatter 解析失败YAML 出现非法字符或换行改为 AI 输出 JSON脚本负责写入 YAML笔记被重复处理缺少已处理标记统一维护ai_processed字段作为过滤条件定时任务不触发目录路径配置错误或权限不足确认绝对路径和读写权限摘要内容质量差笔记原始结构混乱、信息量低用模板规范新笔记结构人工清理少量老笔记6. 这套方案能走多远进一步扩展的方向目前整个流程跑熟之后我每天的工作流变成了碎片时间往01_Inbox里丢素材链接、随手写感想 → 每半小时 WorkBuddy 自动把新笔记整理好补上标签、摘要和关联 → 每周日深夜自动做一次全库相似度关联跨领域知识开始自发产生链接 → 每两周做一次高频笔记时效性检查确保笔记不会腐烂。这个流程跑起来之后我做知识管理的心态完全变了从“我必须勤快整理”变成了“我只负责思考和记录整理是系统的事”。Obsidian 也从“笔记软件”升级成了“会呼吸的第二个大脑”。再往后这套方案还能继续扩展。比如在 WorkBuddy 里加一个“每日回顾”Skill把当天新增笔记的摘要汇总成一张晨报第二天早上推送给你或者用类似思路接入邮件、RSS、微信收藏所有信息流进 Inbox 后自动归档甚至可以在本地再接一个 Embedding 模型做真正的语义向量检索让“自动关联”从基于摘要文本升级为基于语义相似度。工具永远是死的思路是活的。核心还是那四个字飞轮转起来。我自己在这套方案上踩过最多的坑就是一开始太想“做得全”结果哪个 Skill 都没调稳最后落得个三天打鱼两天晒网。所以在这里最想提醒你一句先跑通最小的闭环哪怕一开始只做一个“自动打标签”坚持一周之后你会亲眼看到知识库开始“自己长出形状”。那时候你就会理解为什么这么多人对“自进化知识库”这件事上头了。