1. 为什么我要折腾这套组合拳先说结论我用了大半年时间把散落在微信收藏、浏览器书签、备忘录、各种云文档里的东西全部收拢到了一个本地优先的知识库里。核心工具就三样——Obsidian做知识容器WorkBuddy做 AI 处理引擎Gitee做版本托管和同步中转。这套组合跑下来我的信息处理效率大概提升了三倍不止最关键的是数据始终在我自己手里。你可能会问市面上现成的笔记软件那么多为什么非要自己搭我踩过的坑是这样的早期用在线笔记某次服务商调整策略我存了两年的技术笔记导出格式全乱了后来换本地软件又遇到多设备同步冲突、版本回溯困难的问题。直到我把 Obsidian 的本地文件管理、WorkBuddy 的 AI 处理能力、Gitee 的版本控制这三样东西串起来才算找到了一个平衡点——本地存储保证数据主权AI 增强提升处理效率Git 托管解决同步和版本问题。这套方案适合什么人如果你符合下面任意一条那这篇内容就是写给你的手头有大量零散笔记需要结构化整理想让 AI 帮你自动打标签、写摘要、建立关联需要在多台设备之间同步但不想依赖商业云服务对数据隐私有要求不希望笔记内容被第三方平台分析。哪怕你之前没用过 Obsidian 或者 Git跟着走一遍也能搭起来我会把每个环节的坑都标出来。2. 三件套各自的角色定位与选型逻辑2.1 Obsidian为什么是它而不是 Notion 或语雀Obsidian 的核心优势在于本地 Markdown 文件存储。你的每一条笔记就是一个.md文件躺在你电脑的文件夹里用任何文本编辑器都能打开。这个特性决定了它天然适合做知识库的底座——不绑定服务商不怕跑路不怕导出格式错乱。另一个关键点是双向链接。你在笔记 A 里写[[笔记B]]Obsidian 会自动建立 A 到 B 的链接同时在 B 的反向链接面板里显示 A。这个机制让知识不再是孤岛而是逐渐织成一张网。我自己的用法是每读一篇论文或技术文档先建一条文献笔记然后用双向链接把它挂到对应的主题笔记上时间久了主题笔记就自动长成了一个知识地图。插件生态也是我选它的重要原因。Obsidian 有上千个社区插件从日历、看板到 AI 集成几乎你能想到的功能都有对应插件。而且插件也是本地运行的不依赖云端服务。2.2 WorkBuddyAI 能力的接入层WorkBuddy 在这套组合里扮演的是AI 处理引擎的角色。它本质上是一个 AI Agent 框架可以对接多种大模型通过 Skill技能机制来执行具体任务。我主要用它做三件事自动摘要、自动打标签、自动建立笔记间的关联建议。为什么不用 Obsidian 自带的 AI 插件因为那些插件大多只支持单一模型而且处理长文本时容易截断。WorkBuddy 的优势在于它可以编排多步任务——比如先让模型读完整篇笔记提取关键概念再根据概念去已有笔记库里搜索相关条目最后生成关联建议。这种多步编排能力是单次 API 调用做不到的。WorkBuddy 的 Skill 机制也值得说一下。你可以把它理解成一个个预制好的工作流模板比如“摘要生成 Skill”“标签提取 Skill”“关联推荐 Skill”。每个 Skill 定义了输入格式、处理步骤和输出格式你只需要把笔记内容喂进去它就能按预设流程处理完返回结果。对于不想写代码的人来说这比直接调 API 友好太多了。2.3 Gitee同步与版本控制的中转站Gitee 在这套方案里承担两个职责版本控制和多设备同步。Obsidian 的笔记本质上是纯文本文件天然适合用 Git 管理。每次修改后提交一次你就有了完整的历史版本随时可以回溯到任何一个时间点。为什么选 Gitee 而不是其他代码托管平台主要是访问速度和稳定性。对于国内用户来说Gitee 的拉取和推送速度明显更稳定不会出现同步到一半卡住的情况。而且 Gitee 的私有仓库免费额度足够个人知识库使用不用担心笔记内容泄露。同步的逻辑是这样的你在电脑 A 上编辑笔记提交并推送到 Gitee 仓库电脑 B 从 Gitee 拉取最新版本就完成了同步。手机端可以通过 Obsidian 的 Git 插件实现同样的操作。整个链路不经过任何第三方笔记服务数据始终在你自己控制的仓库里。3. 环境搭建的完整实操流程3.1 Obsidian 的安装与基础配置Obsidian 的安装没什么难度官网下载对应系统的安装包一路下一步就行。安装完成后第一件事是创建仓库Vault。仓库就是一个文件夹你所有的笔记都会存在这个文件夹里。我建议把仓库放在一个固定的、路径中不含中文和空格的目录下比如D:/KnowledgeBase。路径含中文在某些 Git 操作中会出问题这个坑我踩过。创建仓库后进入设置界面有几个选项建议调整文件与链接把“新建链接格式”设为“相对路径”这样笔记之间的链接不会因为仓库移动而失效。外观主题选默认的就行但建议把“字体大小”调到 16px 以上长时间阅读更舒服。核心插件确保“反向链接”“大纲”“标签面板”这几个是开启状态。接下来是插件安装。Obsidian 的社区插件需要先关闭“安全模式”才能安装。进入设置 → 第三方插件 → 关闭安全模式 → 浏览社区插件。我建议先装这几个Git用于同步、Templater模板增强、Dataview数据查询。Git 插件是后面跟 Gitee 对接的关键Templater 可以帮你自动化生成笔记模板Dataview 则能让你用类 SQL 的语法查询笔记内容。3.2 WorkBuddy 的部署与模型接入WorkBuddy 的部署方式取决于你选择的版本。我用的桌面版下载安装包后直接安装即可。安装完成后第一件事是配置模型接入。WorkBuddy 支持多种模型接口你需要准备一个模型服务的 API Key然后在设置里填入接口地址和密钥。模型选择上我的建议是摘要和标签提取用轻量模型关联分析和深度处理用重量模型。原因很简单摘要和打标签是高频操作每次处理一篇笔记都要调用用大模型成本太高而关联分析需要理解语义对模型能力要求更高值得用更好的模型。WorkBuddy 支持为不同 Skill 配置不同模型这个灵活性很实用。配置完成后建议先跑一个简单的测试 Skill确认模型能正常返回结果。我遇到过接口地址填错导致一直超时的情况排查了半天才发现是 URL 末尾多了一个斜杠。3.3 Gitee 仓库创建与 SSH 密钥配置在 Gitee 上创建一个私有仓库仓库名随意比如my-knowledge-base。创建时注意不要勾选“使用 Readme 文件初始化仓库”因为我们要把本地已有的 Obsidian 仓库推上去如果远程仓库有初始文件会产生冲突。接下来配置 SSH 密钥。打开终端Windows 用 Git Bash 或 PowerShell执行ssh-keygen -t rsa -b 4096 -C your_emailexample.com一路回车密钥会生成在~/.ssh/目录下。然后查看公钥内容cat ~/.ssh/id_rsa.pub复制输出的全部内容打开 Gitee → 设置 → SSH 公钥 → 添加公钥粘贴进去保存。回到终端测试连接ssh -T gitgitee.com如果看到欢迎信息说明配置成功。这一步的坑在于有些人之前已经生成过密钥直接覆盖会导致其他服务失效。如果你不确定可以先检查~/.ssh/目录下是否已有id_rsa文件有的话就跳过生成步骤直接用现有的公钥。4. 核心环节把三者串起来的详细步骤4.1 本地仓库初始化与首次推送进入你的 Obsidian 仓库目录执行cd D:/KnowledgeBase git init git add . git commit -m 初始化知识库 git remote add origin gitgitee.com:你的用户名/my-knowledge-base.git git push -u origin master这里有个细节Obsidian 会在仓库根目录生成一个.obsidian文件夹里面存的是你的配置和插件。这个文件夹建议一起提交这样换设备时配置也能同步。但如果你在配置里存了 API Key 之类的敏感信息就要把它加入.gitignore排除掉。我的做法是API Key 统一放在系统环境变量里Obsidian 插件通过环境变量读取这样配置文件里就不会有敏感信息。推送完成后去 Gitee 仓库页面刷新应该能看到你的笔记文件。如果推送时报错“远程仓库有本地没有的提交”说明创建仓库时勾选了初始化文件需要先执行git pull --rebase origin master合并远程变更再推送。4.2 Obsidian Git 插件的配置要点前面装的 Git 插件现在要配置它自动同步。进入插件设置几个关键参数Auto backup开启间隔设为 10 分钟。这样你编辑过程中会自动提交不用手动操作。Auto pull开启间隔设为 10 分钟。多设备使用时自动拉取远程更新。Commit message设为vault backup: {{date}}这样每次提交信息都带时间戳方便回溯。Pull before push开启。避免推送时远程有新提交导致冲突。注意自动同步虽然方便但在多设备同时编辑同一篇笔记时容易产生冲突。我的经验是尽量保证同一时间只在一台设备上编辑切换设备前先手动同步一次。4.3 WorkBuddy Skill 的编排与调用WorkBuddy 的核心用法是编排 Skill 流水线。我以“自动摘要 标签提取 关联推荐”这条流水线为例说明配置过程。第一步创建一个摘要 Skill。输入格式设为 Markdown 文本处理步骤配置为读取全文 → 调用模型生成 200 字以内摘要 → 输出到指定字段。提示词我用的模板是“请用 200 字以内概括以下笔记的核心内容保留关键术语不要添加原文没有的信息。”第二步创建标签提取 Skill。输入是摘要文本处理步骤是调用模型提取 3-5 个关键词 → 与已有标签库比对 → 输出新标签和已有标签的匹配结果。这里的关键是维护一个标签库文件每次提取的新标签先跟库里的比对避免同义词泛滥。比如“机器学习”和“ML”应该统一成一个标签。第三步创建关联推荐 Skill。输入是当前笔记的摘要和标签处理步骤是在笔记库中搜索包含相同标签的笔记 → 调用模型判断语义相关性 → 输出推荐关联列表。这一步需要 WorkBuddy 能访问你的笔记库文件所以要把仓库路径配置到 WorkBuddy 的工作目录里。三个 Skill 串起来后你只需要把一篇新笔记喂给流水线它就会自动完成摘要、打标签、推荐关联三件事。处理结果可以写回笔记的 frontmatter 区域Obsidian 的 Dataview 插件就能读取这些字段做展示。4.4 多设备同步的完整链路验证在第二台设备上安装 Obsidian创建仓库时选择“打开已有文件夹”指向一个空目录。然后配置 Git 插件填入 Gitee 仓库地址执行一次手动拉取。拉取完成后你的所有笔记、配置、插件都会同步过来。验证同步是否正常可以这样做在设备 A 上新建一条笔记等待自动提交推送或手动触发然后在设备 B 上执行拉取看笔记是否出现。反过来再操作一次确认双向同步都正常。手机端的配置稍微麻烦一点。iOS 上可以用 Working Copy 这个 Git 客户端来管理仓库Android 上可以用 Termux 配合 Git 命令行。Obsidian 移动版打开仓库后通过第三方 Git 工具同步。虽然不如桌面端自动化程度高但应急查看和简单编辑是够用的。5. 常见问题排查与避坑指南5.1 同步冲突的处理方法冲突是 Git 使用中最常见的问题表现是推送时提示“rejected”或者拉取时提示“conflict”。根本原因是两台设备修改了同一文件的同一区域。处理方法是先执行git pullGit 会提示哪些文件有冲突。打开冲突文件你会看到和标记的冲突区域。手动决定保留哪部分内容删除标记符号然后git add冲突文件git commit提交最后git push。预防冲突的经验养成“编辑前先拉取编辑后立即推送”的习惯。Obsidian Git 插件的自动同步间隔可以设短一点比如 5 分钟减少冲突窗口期。另外避免在两台设备上同时编辑同一篇笔记如果确实需要可以先在一台设备上完成并推送再在另一台设备上拉取后编辑。5.2 WorkBuddy 处理长文本的截断问题大模型有上下文长度限制笔记太长时会被截断导致摘要不完整。我的解决方案是分段处理再合并先把长笔记按标题层级切成若干段每段单独生成摘要最后把所有段落摘要合并成一个总摘要。WorkBuddy 的 Skill 支持循环处理配置一个“按标题切分”的预处理步骤就行。另一个技巧是用模型的长上下文版本处理重要笔记。如果某篇笔记特别重要值得用更大上下文的模型完整处理一遍可以在 WorkBuddy 里单独为它指定模型不走默认的轻量模型。5.3 Gitee 仓库容量与文件类型限制Gitee 对单文件大小和仓库总容量有限制免费版单文件不超过 100MB仓库总容量也有上限。纯文本笔记完全不用担心但如果你在笔记里嵌入了大量图片或附件就要注意了。我的做法是图片统一放在一个附件文件夹里用图床或者压缩后存储。Obsidian 默认会把粘贴的图片存到仓库里你可以在设置里把附件路径改为固定文件夹然后定期清理不需要的图片。如果图片太多可以考虑用对象存储服务托管图片笔记里只存链接。另外Gitee 仓库不建议存放二进制大文件Git 对二进制文件的版本管理效率很低每次修改都会存一份完整副本仓库会迅速膨胀。如果确实需要管理大文件可以了解 Git LFS但个人知识库场景一般用不上。5.4 Obsidian 打不开或插件失效的应急处理Obsidian 偶尔会出现打不开的情况表现是启动后白屏或者卡在加载界面。最常见的原因是插件冲突。处理方法是进入仓库目录把.obsidian/plugins文件夹临时改名然后启动 Obsidian。如果能正常打开说明是某个插件的问题再逐个恢复插件排查。另一个原因是配置文件损坏。.obsidian文件夹里的appearance.json或community-plugins.json如果格式错误会导致启动失败。可以用文本编辑器打开检查 JSON 格式是否合法或者直接删除这两个文件让 Obsidian 重新生成默认配置。提示定期备份.obsidian文件夹是个好习惯。虽然笔记内容有 Git 管理但插件配置和主题设置如果丢失重新配一遍也很费时间。6. 进阶玩法让知识库真正活起来6.1 用 Dataview 做知识库仪表盘Dataview 插件可以让你用类 SQL 语法查询笔记。我建了一个“仪表盘”笔记里面用 Dataview 查询语句展示最近修改的笔记、待处理的标签、关联最多的笔记等信息。每次打开 Obsidian先看这个仪表盘就知道知识库的当前状态。一个实用的查询示例列出所有包含#待整理标签的笔记按修改时间倒序排列。这样你随时能看到哪些笔记还没处理完不会遗漏。LIST FROM #待整理 SORT file.mtime DESC6.2 用模板自动化新笔记创建Templater 插件可以定义笔记模板新建笔记时自动填充 frontmatter 字段、日期、标签等内容。我的文献笔记模板长这样--- title: % tp.file.title % created: % tp.date.now(YYYY-MM-DD) % tags: [文献笔记, 待整理] status: 未读 --- ## 核心观点 ## 关键术语 ## 关联笔记新建笔记时Templater 会自动填入标题和日期标签预设为“文献笔记”和“待整理”。这样每篇新笔记都有统一的格式后续用 Dataview 查询时也方便。6.3 多 AI 协作的处理流水线设计WorkBuddy 支持配置多个模型我利用这个特性设计了一条多模型协作流水线轻量模型负责初筛和分类重量模型负责深度分析和关联推荐。具体流程是新笔记先经过轻量模型判断类型技术笔记、读书笔记、灵感记录等根据类型路由到不同的处理分支技术笔记走“术语提取 代码片段识别”分支读书笔记走“观点摘要 引用提取”分支最后所有分支的结果汇总到重量模型生成跨笔记的关联建议。这种设计的优势是成本和质量的平衡。轻量模型处理高频的初筛任务成本低速度快重量模型只处理需要深度理解的部分保证质量。WorkBuddy 的 Skill 编排能力让这种多模型流水线变得很容易配置不需要写复杂的调度代码。6.4 知识库的定期维护与清理知识库用久了会积累大量过时或重复的内容定期维护很重要。我每个月做一次清理流程是用 Dataview 列出所有超过三个月未修改且标签为“待整理”的笔记逐条判断是删除、合并还是更新检查标签库合并同义标签检查断开的双向链接修复或删除无效链接。维护过程中WorkBuddy 可以帮忙做重复内容检测把所有笔记的摘要喂给模型让它找出语义高度相似的笔记对然后我人工判断是否合并。这个步骤用 AI 辅助能省不少时间但最终决策还是要人来定毕竟模型对“相似”的判断有时候过于宽泛。7. 我在这套方案上踩过的坑与最终心得最大的坑是过度自动化。刚开始我配置了非常复杂的自动处理流水线每篇笔记进来都要跑一遍摘要、标签、关联、分类全套流程。结果发现处理速度跟不上记录速度而且很多自动生成的标签和关联并不准确反而增加了清理负担。后来我把流水线简化成“摘要 标签”两步关联推荐改为按需触发整个系统才跑得顺畅。第二个坑是同步频率设置过高。Obsidian Git 插件我一开始设了 1 分钟自动同步结果频繁的 Git 操作拖慢了 Obsidian 的响应速度而且产生了大量无意义的提交记录。改成 10 分钟后体验好多了。Git 提交记录也干净了很多回溯时更容易找到有意义的版本节点。第三个坑是把所有东西都往知识库里塞。有段时间我连购物清单、临时提醒都往 Obsidian 里记导致知识库变得杂乱。后来我明确了边界Obsidian 只放需要长期积累和关联的内容临时性信息用系统自带的备忘录。知识库的纯净度直接决定了 AI 处理的质量垃圾进垃圾出这个道理在知识管理上同样适用。最后分享一个实用技巧给笔记的 frontmatter 加一个status字段值可以是“草稿”“待整理”“已整理”“已归档”。WorkBuddy 处理时根据 status 决定是否跳过Dataview 查询时也可以按 status 过滤。这个小字段让整个知识库的流转状态一目了然强烈建议加上。