1. 为什么我要折腾这套三联组合1.1 从“笔记坟场”到“第二大脑”的转折点我用 Obsidian 差不多三年了本地 Markdown 文件攒了四千多篇但说实话前两年半基本就是“笔记坟场”——记完就忘搜索靠关键词关联靠手动双链真正需要调用某个知识点的时候翻半天找不到找到了也忘了当时为什么记。后来我意识到一个问题知识库的核心价值不在于“存”而在于“取”和“用”。存得再多取不出来等于零。这个痛点逼着我开始琢磨怎么让知识库“活”起来。我的需求很明确第一数据必须在我自己手里不能放在别人的服务器上这是底线第二要有 AI 能力能帮我自动整理、摘要、关联、问答第三要有版本管理和多端同步防止硬盘挂了或者误删。市面上现成的 SaaS 知识库工具不少但要么数据不在自己手里要么 AI 能力是黑盒要么收费贵得离谱。折腾了一圈最终落地的方案就是这套Obsidian WorkBuddy Gitee的三联组合。Obsidian 负责本地知识库的存储和编辑WorkBuddy 负责 AI 能力的接入和自动化工作流Gitee 负责版本管理和远程备份。三个工具各司其职组合起来就是一个完整的、数据自主可控的、带 AI 能力的个人知识库系统。这套方案适合谁适合那些有一定技术基础、重视数据隐私、愿意花点时间折腾但不想被平台绑架的知识工作者。如果你只是想找个开箱即用的笔记软件那这套方案可能不适合你但如果你想要一个真正属于自己的“第二大脑”往下看。1.2 三个工具各自的角色定位先说 Obsidian。它的本质就是一个本地 Markdown 文件管理器加上双链、图谱、插件系统。很多人把它当笔记软件用但其实它更像一个“知识操作系统”——你的所有笔记就是纯文本文件存在本地文件夹里不依赖任何云服务。这一点极其重要因为这意味着你的知识资产永远不会被平台锁定。Obsidian 的插件生态是它最大的护城河社区插件超过两千个从日历、看板到 AI 对话、自动化脚本几乎你能想到的功能都有对应的插件。再说 WorkBuddy。这是一个 AI 工作流自动化工具核心能力是把 AI 模型接入到你的日常工作流中。它可以理解为一个“AI 中间层”一边连接你的本地文件系统或知识库一边连接各种 AI 模型接口中间通过可视化的工作流编排来实现自动化处理。比如你可以配置一个工作流监控 Obsidian 的某个文件夹当有新文件写入时自动调用 AI 模型生成摘要、提取关键词、写入 frontmatter然后同步到指定位置。整个过程不需要你手动干预。最后说 Gitee。它是国内的代码托管平台提供 Git 仓库服务。我用它来做什么把整个 Obsidian 知识库作为一个 Git 仓库管理起来。每次笔记有变动提交一次 commit推送到 Gitee 的私有仓库。这样做的好处有三个一是版本管理任何一次修改都有记录误删了可以回滚二是远程备份本地硬盘挂了也不怕三是多端同步家里电脑和公司电脑通过 Git 拉取推送保持一致。Gitee 的私有仓库免费额度对个人知识库来说完全够用而且国内访问速度快不像某些国外平台时不时连不上。这三个工具组合在一起形成了一个闭环Obsidian 负责“写和存”WorkBuddy 负责“处理和增强”Gitee 负责“备份和同步”。下面我逐个拆解每个环节的具体配置和实操细节。2. Obsidian 知识库的搭建与核心配置2.1 安装与初始设置别急着装插件Obsidian 的安装没什么好说的官网下载对应平台的安装包一路下一步就行。但初始设置有几个关键点需要注意这些设置直接影响后续的使用体验和 AI 接入的便利性。第一个关键设置是仓库位置。Obsidian 的“仓库”Vault本质上就是一个文件夹里面存放你所有的 Markdown 文件和附件。我强烈建议把仓库放在一个路径简单、没有中文、没有空格的目录下比如D:\KnowledgeBase或~/Documents/MyVault。为什么因为后续 WorkBuddy 和 Git 都要操作这个路径路径里有中文或空格容易出各种莫名其妙的错误。我踩过这个坑早期把仓库放在D:\我的笔记\知识库下面结果 Git 提交时路径解析出问题折腾了半天才找到原因。第二个关键设置是附件管理。Obsidian 默认把粘贴的图片放在仓库根目录时间一长根目录全是图片文件乱得没法看。你需要在设置里找到“文件与链接”选项把“新附件的默认位置”改为“指定的附件文件夹”然后填一个路径比如attachments。同时把“内部链接类型”设置为“基于当前仓库的绝对路径”或“相对路径”这样即使你移动了文件夹链接也不会断。第三个关键设置是模板文件夹。Obsidian 自带模板功能你可以创建一个templates文件夹在里面放各种笔记模板。比如我创建了一个“文献笔记模板”包含 frontmatter 字段title、author、year、tags、status和固定的正文结构摘要、方法、结论、个人思考。每次新建文献笔记时直接调用模板省去重复劳动。这个功能配合后续的 WorkBuddy 自动化可以实现模板字段的自动填充。注意Obsidian 的配置文件存在.obsidian隐藏文件夹里这个文件夹不要手动修改也不要用 Git 跟踪后面会讲怎么排除。如果你不小心删了它所有插件配置和快捷键设置都会丢失。2.2 必装插件清单与配置要点Obsidian 的插件分核心插件和社区插件。核心插件是官方自带的在设置里直接开启就行社区插件需要去“第三方插件”里关闭安全模式后浏览安装。下面是我用了三年下来认为对知识库管理最关键的几个插件以及它们的配置要点。Dataview是第一个必须装的。它让你可以用类似 SQL 的查询语句从所有笔记的 frontmatter 中提取数据动态生成列表、表格、任务清单。比如你可以写一个查询列出所有status: 待读的文献笔记按添加时间倒序排列。这个插件是把“死笔记”变成“活数据库”的关键。配置上没什么特别的安装后在设置里开启“启用 JavaScript 查询”和“启用内联查询”就行。Templater是第二个必须装的。它比 Obsidian 自带的模板功能强大得多支持 JavaScript 脚本、动态日期、用户输入变量。比如你可以写一个模板新建笔记时自动弹出对话框让你输入标题和标签然后自动生成带日期前缀的文件名。这个插件和 WorkBuddy 配合起来特别好用后面会详细讲。Git插件是第三个必须装的。它把 Git 操作集成到 Obsidian 界面里你可以直接在 Obsidian 里执行 commit、push、pull不用切换到命令行。配置时需要填写仓库的远程地址、分支名、用户名和邮箱。这个插件是连接 Obsidian 和 Gitee 的桥梁后面会专门讲怎么配。Calendar和Periodic Notes这两个插件配合使用可以建立日记、周记、月记体系。Calendar 在侧边栏显示一个月历点击某一天就打开对应的日记文件Periodic Notes 负责自动创建和管理这些周期性笔记的模板。我的日记模板里有一个“今日知识碎片”区块专门用来快速记录当天的灵感、摘录、待办后续 WorkBuddy 会扫描这些区块自动提取有价值的内容归档到永久笔记。Excalidraw是画图插件适合画流程图、架构图、思维导图。它生成的文件是.excalidraw格式本质上是 JSON可以嵌入到 Markdown 笔记里。我一般用它来画知识图谱的草图、项目架构图、读书笔记的结构图。这个插件不是必须的但如果你经常需要可视化表达强烈推荐。Omnisearch是增强搜索插件比 Obsidian 自带的搜索快得多支持模糊匹配和中文分词。Obsidian 自带的搜索对中文支持一般搜一个词经常搜不全Omnisearch 解决了这个问题。安装后在设置里把语言设为中文然后重建索引就行。插件装完之后建议在.obsidian文件夹里把plugins和themes两个子文件夹加入 Git 的.gitignore只跟踪笔记内容本身。为什么因为插件版本更新频繁配置文件经常变动如果全部纳入 Git 管理每次提交都会产生大量无意义的 diff而且不同电脑上的插件版本可能不一致容易冲突。只跟踪笔记内容插件在各台电脑上单独安装配置这样最干净。2.3 文件夹结构与命名规范知识库的文件夹结构没有标准答案但有一个原则结构要服务于检索而不是服务于分类。很多人喜欢建一大堆嵌套文件夹什么“技术/编程/前端/React/ hooks”结果笔记放进去之后自己都忘了放哪了。我的建议是文件夹层级不超过三层大部分笔记靠标签和双链来组织而不是靠文件夹。我的仓库结构是这样的KnowledgeBase/ ├── 00-Inbox/ # 收件箱所有新笔记先扔这里 ├── 10-Notes/ # 永久笔记经过整理的知识卡片 ├── 20-Literature/ # 文献笔记读书、论文、文章的摘录 ├── 30-Projects/ # 项目笔记每个项目一个文件夹 ├── 40-Areas/ # 领域笔记长期关注的领域 ├── 50-Archive/ # 归档不再活跃的笔记 ├── 90-Templates/ # 模板文件夹 ├── 99-Attachments/ # 附件文件夹 └── .obsidian/ # 配置文件夹不纳入 Git这个结构参考了 PARA 方法Projects、Areas、Resources、Archives但做了简化。核心思路是新笔记先进00-Inbox定期整理时再移动到10-Notes或20-Literature。30-Projects和40-Areas按需创建子文件夹。50-Archive存放已经完成或不再关注的内容保持主目录清爽。命名规范方面我采用“日期前缀 描述性标题”的格式比如20240115-如何配置Obsidian的Git插件.md。日期前缀的好处是文件按时间自然排序而且避免重名。描述性标题用中文方便搜索。frontmatter 里再单独记录title、aliases、tags、created、modified等字段。这样即使文件名改了通过 aliases 也能找到。实操心得不要花太多时间纠结文件夹结构先用起来用着用着自然就知道该怎么调整了。我前前后后改了五六次结构每次都是因为实际使用中发现了不便之处。结构是长出来的不是设计出来的。3. WorkBuddy 接入让知识库拥有 AI 大脑3.1 WorkBuddy 的安装与基础配置WorkBuddy 的安装方式取决于你用的版本。它目前有桌面版和命令行版两种形态桌面版适合不熟悉命令行的用户命令行版适合喜欢脚本化操作的用户。我两个都装了日常用桌面版做工作流编排用命令行版做定时任务和批量处理。安装过程不复杂官网下载安装包一路下一步。首次启动后需要配置几个关键项。第一个是模型接口WorkBuddy 支持多种 AI 模型接口你需要填入 API Key 和接口地址。我目前用的是国内某厂商的模型接口响应速度快中文理解能力也够用。配置界面里有一个“测试连接”按钮填完之后点一下能正常返回结果就说明配置对了。第二个是工作目录也就是 WorkBuddy 默认操作的文件目录。这里要填你的 Obsidian 仓库路径比如D:\KnowledgeBase。填完之后 WorkBuddy 就能读取和写入仓库里的文件了。注意权限问题Windows 下如果 Obsidian 仓库在系统保护目录比如C:\Program Files下WorkBuddy 可能没有写入权限建议放在用户目录下。第三个是日志级别。默认是 INFO建议调试阶段设为 DEBUG这样能看到每一步的详细输出方便排查问题。正式使用后改回 INFO避免日志文件膨胀太快。WorkBuddy 的核心概念是“工作流”Workflow一个工作流由多个“节点”Node组成节点之间通过“连线”传递数据。节点类型包括触发器文件变动、定时、手动、处理器读取文件、写入文件、调用 AI、条件判断、循环、输出写入文件、发送通知、调用外部接口。你可以在可视化界面里拖拽节点、连线、配置参数形成一个完整的自动化流程。3.2 核心工作流设计自动摘要与标签生成我配置的第一个工作流是“新笔记自动摘要与标签生成”。触发条件是00-Inbox文件夹中有新文件创建。流程是这样的读取新文件内容 → 调用 AI 模型生成摘要和关键词 → 将摘要和关键词写入 frontmatter → 在文件末尾追加“AI 摘要”区块 → 记录处理日志。具体配置步骤在 WorkBuddy 里新建一个工作流命名为“Inbox 自动处理”。添加一个“文件监控”触发器监控路径设为D:\KnowledgeBase\00-Inbox监控事件选“文件创建”。然后添加一个“读取文件”节点文件路径用变量{{trigger.filePath}}表示这样它会自动读取触发事件对应的文件。接下来是核心的“AI 调用”节点。在节点配置里提示词Prompt这样写请阅读以下笔记内容完成三件事 1. 用一句话概括核心内容不超过50字 2. 提取3-5个关键词 3. 判断笔记类型文献笔记/永久笔记/项目笔记/日记/其他 笔记内容 {{readFile.content}} 请以 JSON 格式返回字段为summary, keywords, noteType这个提示词的关键在于结构化输出。让 AI 返回 JSON 而不是自由文本后续节点才能方便地解析和写入 frontmatter。WorkBuddy 的 AI 节点支持“输出格式”选项选 JSON 模式模型会尽量按 JSON 格式返回。AI 节点之后接一个“解析 JSON”节点把返回的 JSON 字符串解析成对象。然后接一个“更新 frontmatter”节点把summary、keywords、noteType写入文件的 frontmatter。最后接一个“追加内容”节点在文件末尾追加一个## AI 摘要区块把摘要内容写进去。整个工作流跑下来一篇新笔记从创建到完成 AI 处理大概需要 3-5 秒。我实测下来摘要质量相当不错关键词提取也基本准确。偶尔会有格式错误比如 AI 返回的 JSON 不完整这时候需要在 AI 节点后面加一个“错误处理”分支解析失败时把原始返回内容写入日志方便排查。注意事项AI 调用是有成本的虽然单次调用很便宜但如果你的 Inbox 每天新增几百篇笔记累积起来也是一笔开销。建议在 AI 节点前加一个“条件判断”节点只对字数超过 200 字的笔记做 AI 处理太短的笔记直接跳过。3.3 进阶玩法知识库问答与关联推荐基础工作流跑通之后我开始折腾更高级的玩法。第一个是“知识库问答”思路是把 Obsidian 仓库里的所有笔记向量化存到一个本地向量数据库里然后通过 WorkBuddy 提供一个问答接口你问一个问题它从知识库里检索相关笔记拼接成上下文调用 AI 生成回答。这个工作流稍微复杂一些需要用到 WorkBuddy 的“向量化”节点和“向量检索”节点。向量化节点负责把笔记内容转成向量存到本地数据库WorkBuddy 内置了轻量级向量库。向量检索节点负责根据问题检索最相关的笔记片段。整个流程是用户输入问题 → 向量化问题 → 检索相关笔记 → 拼接上下文 → 调用 AI 生成回答 → 返回结果。我实测下来这个问答系统对“事实型问题”效果很好比如“我之前记的关于 Git 分支管理的笔记在哪里”或者“总结一下我关于 RAG 的所有笔记”。但对“推理型问题”效果一般比如“根据我的笔记我应该怎么设计一个知识管理系统”因为 AI 只能基于检索到的片段回答如果片段不完整回答就会有偏差。第二个进阶玩法是“关联推荐”。Obsidian 本身有双链和图谱但需要你手动建立链接。WorkBuddy 可以自动做这件事每天定时扫描10-Notes文件夹对每篇笔记提取向量然后计算笔记之间的相似度把相似度超过阈值的笔记自动写入“相关笔记”区块。这样你不需要手动维护双链系统会自动帮你发现笔记之间的隐藏关联。这个工作流的配置要点是定时触发器每天凌晨 2 点→ 遍历10-Notes文件夹 → 对每篇笔记向量化 → 计算相似度矩阵 → 筛选 Top 5 相似笔记 → 写入“相关笔记”区块。注意要排除已经存在的链接避免重复写入。另外相似度阈值需要调我一开始设 0.8发现推荐太少后来降到 0.65推荐数量比较合适但偶尔会有不太相关的推荐。这个阈值需要根据你的笔记质量和数量来调。4. Gitee 仓库配置与多端同步实战4.1 创建私有仓库与 SSH 密钥配置Gitee 的仓库创建很简单登录后在右上角点“新建仓库”填写仓库名称比如knowledge-base选择“私有”不要勾选“初始化仓库”因为本地已经有内容了然后点创建。创建完成后你会得到一个远程地址格式是gitgitee.com:你的用户名/knowledge-base.git。接下来配置 SSH 密钥。为什么用 SSH 而不是 HTTPS因为 SSH 配置一次之后就不用每次输入密码了而且更安全。配置步骤打开终端Windows 用 Git Bash 或 PowerShell输入ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车会在~/.ssh/目录下生成id_rsa和id_rsa.pub两个文件。用文本编辑器打开id_rsa.pub复制里面的全部内容。然后回到 Gitee 网页点右上角头像 → 设置 → SSH 公钥 → 新建公钥把刚才复制的内容粘贴进去标题随便填比如“我的笔记本”点确定。配置完成后在终端里输入ssh -T gitgitee.com如果返回“Hi 你的用户名! Youve successfully authenticated...”就说明配置成功了。踩坑记录如果你之前配置过多个 Git 平台的 SSH 密钥可能会遇到冲突。解决办法是在~/.ssh/config文件里为每个平台指定不同的密钥文件。比如给 Gitee 单独指定一个密钥Host gitee.com下面加IdentityFile ~/.ssh/gitee_rsa。这个坑我踩过当时配了半天一直提示权限拒绝后来才发现是密钥冲突。4.2 本地仓库初始化与首次推送SSH 配好之后在 Obsidian 仓库根目录打开终端执行以下命令git init git remote add origin gitgitee.com:你的用户名/knowledge-base.git git add . git commit -m 初始提交知识库初始化 git push -u origin master这几条命令做的事情是初始化本地 Git 仓库、关联远程仓库、把所有文件加入暂存区、提交、推送到远程。注意git push -u origin master里的master是分支名Gitee 默认分支可能是master也可能是main根据实际情况调整。推送之前一定要先创建.gitignore文件排除不需要跟踪的内容。我的.gitignore内容如下.obsidian/plugins/ .obsidian/themes/ .obsidian/workspace.json .obsidian/workspace-mobile.json .trash/ .DS_Store Thumbs.db *.tmp为什么要排除这些.obsidian/plugins/和.obsidian/themes/里是插件和主题的代码文件体积大且更新频繁不同电脑上单独安装就行。workspace.json记录的是当前打开的窗口布局每台电脑不一样跟踪它会导致频繁冲突。.trash/是 Obsidian 的回收站不需要备份。首次推送时如果仓库内容很多比如几千篇笔记加附件可能会比较慢。Gitee 对单次推送的文件数量和体积有限制如果附件文件夹特别大建议把附件也排除掉或者用 Git LFSLarge File Storage来管理大文件。Git LFS 的配置稍微复杂一些需要先安装 Git LFS 扩展然后在仓库里执行git lfs track *.png之类的命令。我的附件不多所以没上 LFS直接排除了99-Attachments/文件夹附件单独用网盘备份。4.3 多端同步的日常操作流程多端同步的核心原则是每次开始工作前先 pull每次结束工作后 push。听起来简单但实际操作中有很多细节需要注意。我在家里电脑和公司电脑上都装了 Obsidian 和 Git。早上到公司第一件事是打开终端进入知识库目录执行git pull。这会从 Gitee 拉取最新的改动。然后打开 Obsidian 开始工作。中午休息前执行git add . git commit -m 中午提交 git push。下午重复这个过程。晚上回家先git pull再开始工作。这个流程听起来很繁琐但其实可以自动化。Obsidian 的 Git 插件支持“自动提交”和“自动推送”功能你可以在设置里开启“每隔 X 分钟自动提交”和“提交后自动推送”。我设的是每 30 分钟自动提交一次每次提交后自动推送。这样基本不需要手动操作只有在大改动之后才会手动提交一次写个有意义的 commit message。但自动提交有一个问题如果两台电脑同时修改了同一个文件pull 的时候会冲突。Git 的冲突解决对非程序员来说不太友好Obsidian 的 Git 插件虽然提供了冲突解决界面但体验一般。我的经验是尽量避免在两台电脑上同时编辑同一篇笔记。如果确实需要可以在 pull 之前先 commit 本地改动然后 pull再手动合并冲突。或者更简单的方法用 Obsidian 的“同步”插件比如 Self-hosted LiveSync做实时同步Git 只做版本备份不做实时同步。这样分工更明确冲突概率也低得多。实操心得Git 仓库的体积会随着提交次数增加而膨胀因为每次提交都保存了文件的完整快照。如果你的知识库很大比如超过 1GB建议定期执行git gc压缩仓库或者每隔一两年重建一次仓库只保留最新的文件快照。我目前的知识库大概 300MB提交了两年多仓库体积 800MB 左右还能接受。5. 常见问题与排查技巧实录5.1 Obsidian 打不开或插件冲突Obsidian 打不开的情况我遇到过几次原因各不相同。最常见的是插件冲突某个插件更新后和 Obsidian 版本不兼容导致启动时卡死。解决办法是进入安全模式关闭 Obsidian找到.obsidian文件夹把plugins文件夹重命名为plugins_backup然后重新打开 Obsidian。如果能正常打开说明是插件问题再把plugins_backup里的插件逐个移回去每移一个重启一次直到找到罪魁祸首。另一个常见原因是配置文件损坏。.obsidian文件夹里的app.json或workspace.json如果格式错误Obsidian 也会打不开。解决办法是删除这两个文件Obsidian 会自动重建但这样会丢失你的界面布局和部分设置。所以建议定期备份.obsidian文件夹出问题时直接恢复。还有一种情况是仓库路径包含特殊字符或中文导致 Obsidian 无法正确读取文件。这个前面提过解决办法是把仓库移到纯英文路径下。如果你已经有很多笔记在中文路径下可以先把整个文件夹复制到英文路径然后在 Obsidian 里重新打开仓库链接一般不会断因为 Obsidian 用的是相对路径。5.2 WorkBuddy 工作流执行失败排查WorkBuddy 工作流执行失败的原因通常有三类权限问题、路径问题、AI 接口问题。权限问题表现为“无法读取文件”或“无法写入文件”。排查方法是检查 WorkBuddy 的运行权限Windows 下尝试以管理员身份运行macOS 下检查“安全性与隐私”里的文件访问权限。另外检查文件是否被其他程序占用比如 Obsidian 正在编辑该文件WorkBuddy 可能无法同时写入。路径问题表现为“文件不存在”或“路径解析错误”。排查方法是检查工作流里的路径变量是否正确特别是{{trigger.filePath}}这类变量在不同触发器下可能格式不同。建议在关键节点后加一个“日志输出”节点把变量值打印出来看看实际路径是什么。AI 接口问题表现为“请求超时”或“返回格式错误”。排查方法是先单独测试 AI 接口是否可用WorkBuddy 设置里有测试按钮然后检查提示词是否过长超过模型上下文限制最后检查返回格式是否符合预期。如果 AI 返回的不是合法 JSON可以在 AI 节点后加一个“正则提取”节点用正则表达式从返回文本中提取 JSON 部分再解析。下面是我整理的一个常见问题速查表问题现象可能原因排查方法解决方案Obsidian 启动卡死插件冲突安全模式启动逐个禁用插件排查WorkBuddy 无法写入文件权限不足检查运行权限以管理员身份运行Git push 被拒绝远程有本地没有的提交先 pull 再 push解决冲突后重新推送AI 返回格式错误提示词不明确检查提示词和返回内容加正则提取节点多端同步冲突同时编辑同一文件查看冲突标记手动合并或避免同时编辑仓库体积过大提交历史太多查看 .git 文件夹大小执行 git gc 或重建仓库5.3 Git 同步冲突的预防与解决Git 冲突是多人协作或多端同步中最头疼的问题。虽然我的知识库只有我一个人用但两台电脑之间同步也会冲突。冲突的根本原因是两台电脑都基于同一个旧版本做了修改push 的时候后 push 的那台会被拒绝因为远程已经有了新的提交。预防冲突的最好方法是缩短同步间隔。我现在的习惯是到公司先 pull走之前 push回家先 pull睡觉前 push。中间如果做了大改动手动 commit 一次。这样两台电脑之间的版本差异最多只有几个小时冲突概率大大降低。如果冲突还是发生了解决步骤是先git pullGit 会提示哪些文件冲突。打开冲突文件你会看到 HEAD和标记中间是冲突的内容。手动编辑文件保留你想要的内容删除标记符号。然后git add冲突文件git commit提交合并结果最后git push。Obsidian 的 Git 插件提供了一个图形化的冲突解决界面比命令行友好一些。但我的经验是对于简单的冲突比如两台电脑都修改了同一篇笔记的不同段落手动合并最快对于复杂的冲突比如同一段落被两边修改建议用专业的合并工具比如 VS Code 内置的合并编辑器来处理。避坑技巧在.gitattributes文件里配置*.md mergeunion可以让 Git 在合并 Markdown 文件时自动把两边的修改都保留下来而不是标记冲突。这个配置对知识库场景特别有用因为大部分冲突都是两边各加了一段内容union 合并正好符合需求。但要注意如果两边修改了同一行union 合并会产生重复内容需要手动清理。6. 这套组合的扩展方向与个人体会6.1 可以继续折腾的方向这套三联组合跑通之后我又陆续加了一些扩展。第一个是微信公众号文章自动归档用 WorkBuddy 配置一个工作流监控某个 RSS 源或手动触发的 URL 列表自动抓取文章内容转成 Markdown写入 Obsidian 的20-Literature文件夹然后自动生成摘要和标签。这样看到好文章不用手动复制粘贴直接扔链接进去就行。第二个是专利辅助检索我偶尔需要查一些专利信息就在 WorkBuddy 里配了一个工作流输入关键词自动调用专利数据库接口把检索结果整理成表格写入 Obsidian。这个工作流需要对接外部 API配置稍微复杂一些但跑通之后效率提升很明显。第三个是移动端快速记录Obsidian 有移动版但移动端的 Git 同步体验一般。我的方案是用手机上的 Markdown 编辑器比如 iA Writer写笔记存到手机本地文件夹然后用 FolderSync 之类的工具同步到电脑的00-Inbox文件夹再触发 WorkBuddy 的自动处理流程。这样手机上只需要一个简单的编辑器复杂的处理都在电脑上完成。6.2 我踩过的坑和最终建议回顾这套系统的搭建过程我踩过的坑不少。最大的坑是一开始就想做完美花了很多时间设计文件夹结构、配置插件、写工作流结果真正用来记笔记的时间反而少了。后来我想通了知识库的核心是“用”不是“搭”。工具够用就行先把笔记记起来用着用着自然知道哪里需要优化。第二个坑是过度依赖 AI。WorkBuddy 的自动摘要和标签生成确实方便但 AI 生成的内容不能完全替代自己的思考。我现在的做法是AI 摘要作为参考自己再写一段“个人思考”放在笔记末尾。这样既享受了 AI 的效率又保留了自己的理解。第三个坑是Git 提交太频繁。一开始我设了每 5 分钟自动提交一次结果一天下来几百个 commit仓库体积膨胀得很快而且 commit 历史全是“自动提交”毫无意义。后来改成 30 分钟一次并且只在有实际改动时才提交情况好多了。如果你也想搭这套系统我的建议是先跑通最小闭环再逐步优化。最小闭环就是Obsidian 装好 → 建一个 Gitee 私有仓库 → 配好 Git 插件 → 能手动 push/pull → 再装 WorkBuddy 配一个最简单的摘要工作流。这个闭环跑通之后你已经有了一个带 AI 能力和版本管理的知识库了。剩下的向量检索、自动关联、多端同步都是锦上添花可以慢慢加。最后分享一个小技巧Obsidian 的00-Inbox文件夹不要放太多东西我给自己定了一个规矩——每周日晚上花 30 分钟清理 Inbox把笔记归类到10-Notes或20-Literature该归档的归档该删除的删除。这个习惯坚持了半年知识库一直保持清爽检索效率也高了很多。工具再好也需要人的维护知识库说到底是一个“养”出来的东西不是“搭”出来的。