Obsidian + WorkBuddy + Gitee：AI驱动个人知识库实战

记笔记这件事我坚持了快十年。从最早的纯文本文件夹到后来用各种在线笔记再到三年前全面迁回 Obsidian。工具换了一轮最核心的痛点始终没变记进去的多用起来的少。三千多篇笔记躺在文件夹里搜索靠关键词回顾靠回忆知识库更像一个数字仓库而不是能帮我思考的东西。直到我把 Obsidian、WorkBuddy、Gitee 三件事串在一起情况才真正改变。这套组合做的事情很朴素Obsidian 负责承载一切笔记内容Gitee 负责给所有笔记做异地备份和版本管理WorkBuddy 负责把 AI 能力接进本地笔记让它能回答问题、批量整理、自动补摘要。三个角色各管一段拼起来就是一个AI 驱动的个人知识库完整闭环。这篇文章适合所有正在用 Obsidian、但对怎么让笔记真正被用起来还不太满意的人也适合刚接触这类工具、想一步到位搭一套靠谱知识库体系的新手。我会把分工逻辑、配置步骤、结构设计、实战工作流以及我踩过的坑完整讲一遍你可以照着搭也可以在这个框架上改成自己的玩法。1. 为什么是这三件套Obsidian、WorkBuddy、Gitee 的分工逻辑1.1 Obsidian一切内容留在本地这是一切的前提我用来用去最终还是回到 Obsidian原因只有一个它把笔记当成普通文件放在本地文件夹里。Markdown 纯文本不锁格式不锁平台不锁数据库。今天用 Obsidian 打开明天用 VS Code 打开后天写个脚本直接批量处理都行。我的笔记主权在我自己手里这才是知识库能被 AI 驱动的前提。相比之下在线笔记工具的问题不在功能而在数据流动性。笔记存在别人服务器上格式私有化导出经常丢三落四。AI 要处理你的知识库第一步得能读到原始内容——本地 Markdown 文件夹天然是最容易让程序读取的数据形态。另外一个隐藏优势是插件生态。Obsidian 的社区插件里Dataview 能做结构化查询Templater 能自动化模板Obsidian Git 能直接把仓库和远端代码平台打通。这些插件让知识库不再只是一个文件夹而是一套可以被脚本和 AI 驱动的工作台。1.2 WorkBuddy给静态笔记装上一双会干活的手Obsidian 擅长存不擅长想。你问它我半年前记的那个关于浏览器插件性能对比的结论是什么它能做的只是把包含关键词的笔记列出来然后让你自己翻。这个缺口需要 AI 来补WorkBuddy 就是补这个缺口的角色。WorkBuddy 是一款以 LLM 为核心的 AI 工作台工具。你可以把它理解成一个能读写本地文件、执行多步任务的 AI 助手它把大模型的对话能力、工具调用能力、Skill 技能机制组合在一起让 AI 不是停留在聊天窗口里而是真正可以操作你指定的文件夹。对个人知识库的场景来说这就意味着你可以问它根据 2025 年项目笔记我上半年遇到的最多问题是什么它可以帮你给一堆旧笔记自动生成摘要再写回每篇笔记的元数据里。它可以按你的要求把某个 MOC内容地图索引页重新整理成带链接结构的文档。用一句话概括Obsidian 负责记住WorkBuddy 负责理解和干活。需要注意WorkBuddy 本身不内置大模型能力它需要对接可用的模型服务或本地模型。具体用哪个模型取决于你对隐私、成本、效果的权衡。我后面会在 4.4 专门讲这部分。1.3 Gitee给知识库一份带时光机的异地副本个人知识库最怕的不是记不全而是丢。硬盘会坏电脑会丢云盘可能出问题。所以知识库必须有一个异地副本。挑来挑去我用的是 Gitee 私有仓库。选择 Gitee核心理由有三个。第一国内访问速度快push 和 clone 都稳定不像某些境外托管平台经常连不上第二私有仓库免费额度足够个人笔记使用你的笔记不需要暴露在公网上第三它兼容标准 Git 协议Obsidian Git 插件可以直接对接手机网页端也能随时浏览。Git 平台给知识库带来的不只是备份还有版本管理。我误删过笔记改坏过结构最后都是靠 git log 找回来的。那种任何时刻都有后悔药的安全感是普通文件夹同步工具给不了的。这套组合我还想再强调一个边界Obsidian 管内容形态WorkBuddy 管智能处理Gitee 管安全兜底三者各司其职互不替代。想用 Obsidian 的插件硬做 AI或者用 Git 硬做桌面端管理都会很难受。分工清楚后面所有流程才顺。2. 从零搭建最小可用闭环的完整配置这一节我按实际操作顺序写目标是让你在一小时内跑通本地笔记 → Gitee 云端 → 多端同步这条链路。配置部分我只保留真正必要的项避免一上来就被插件淹没。2.1 本地侧Obsidian 仓库初始化清单第一步安装 Obsidian。打开官网下载对应系统版本安装后选择创建新库指定一个本地文件夹作为 Vault。我建议直接放在一个专门的数据目录比如~/Documents/KnowledgeBase路径里尽量不要有中文和空格后面接脚本、接 Git 都会省事。第二步进入 Vault 后打开设置 → 第三方插件 → 关闭安全模式启用社区插件。先装三个它们是这个体系的地基插件作用为什么必须装Obsidian Git自动 commit、push、pull打通 Gitee 的关键通道Templater自定义笔记模板让新笔记自动带上结构化元数据Dataview基于元数据做查询让 AI 处理后回写的结构化字段能被复用这三个插件装完先不急着配Obsidian Git 要等远端仓库建好之后再配置。2.2 远端侧Gitee 仓库创建与 SSH 密钥配置登录 Giteegitee.com点右上角新建仓库。仓库名我建议和本地 Vault 名保持一致比如knowledge-base。关键一步是路径选私有个人知识库任何情况下都不该设成公开。初始化仓库时不要勾选初始化仓库因为本地已经有内容了直接从空仓库开始最干净。接下来配置 SSH 密钥。打开终端执行ssh-keygen -t ed25519 -C 你的邮箱example.com一路回车即可。生成的公钥在~/.ssh/id_ed25519.pub复制出来。回到 Gitee 页面进设置 → 安全设置 → SSH 公钥把公钥粘贴进去标题随便填。验证是否配置成功ssh -T gitgitee.com看到类似Hi your_name! Youve successfully authenticated的提示就说明通了。这一步如果失败先检查公钥有没有复制完整再检查本地 SSH 客户端是否有代理干扰。很多第一次配置的人问题都出在复制时漏了结尾的邮箱注释。2.3 打通双向同步Obsidian Git 的保存与拉取细节打开 Obsidian设置 → 第三方插件 → Obsidian Git做四件事在备份仓库路径里填远端地址用 SSH 格式gitgitee.com:你的用户名/knowledge-base.git。勾选保存时自动提交并推送提交间隔默认即可。设置自动拉取间隔为 15 分钟这决定了多端编辑时能多快拿到最新版本。配置.gitignore建议至少排除.obsidian/workspace.json界面状态不需要版本管理.obsidian/cache相关目录node_modules如果存在的话在 Obsidian 里直接拉取可能因网络原因偶发失败我会在Obsidian Git插件的命令面板里手动执行Git: Pull看输出信息判断是网络问题还是密钥问题比干等智能提示更靠谱。2.4 验证闭环一条笔记走完整个链路新建一篇测试笔记内容随便写点Obsidian Git 会自动把它提交并推送到 Gitee。打开 Gitee 仓库页面看到main分支上出现了刚才的提交记录说明闭环已经通了。此时再模拟另一台设备在另一台电脑上git clone gitgitee.com:你的用户名/knowledge-base.git用 Obsidian 打开这个文件夹你会发现所有笔记都在。至此最小可用的Obsidian Gitee同步体系建立完成。接下来才轮到 AI 的接入。3. 让 AI 真正读懂你的知识库笔记结构设计工具配好了如果笔记本身是一团浆糊AI 再好也白搭。很多人忽略这件事AI 能发挥多少作用取决于你的笔记有没有给它足够的结构信息。这一节讲我如何设计笔记结构让 AI 读懂。3.1 机器可读与人类可读的统一人类读笔记靠标题、排版、上下文联想。AI 读笔记靠的是结构。同一个文件夹里一篇纯散文的笔记和一篇带元数据、带标题层级的笔记AI 处理起来效果差很多。我并不是说每篇笔记都要写得像论文。我的做法是正文随意元数据严谨正文保持自然记录的状态但每篇笔记开头都有一段机器可读的元数据告诉 AI 这篇笔记是什么主题、什么类型、创建时间、关联标签。这部分数据我接下来用 frontmatter 实现。3.2 用 YAML frontmatter 给笔记加身份信息在 Obsidian 里每篇 Markdown 笔记的最顶部可以写一段 YAML 格式的属性区这叫 frontmatter。Obsidian 原生支持Dataview 插件也能读。我的每篇笔记至少包含这样的字段--- title: Obsidian Git 插件同步失败排查 date: 2025-06-10 type: note tags: [obsidian, git, 排错] status: permanent source: summary: ---具体解释一下每个字段的用意title笔记标题避免 AI 依赖文件名做判断。date创建日期方便按时间维度筛选。type笔记类型。我用note表示日常记录moc表示索引页project表示项目相关archive表示归档。这个字段让 AI 一眼就能判断笔记在知识库里的身份。status状态。fleeting表示临时想法permanent表示已整理过的长期笔记。有了它AI 可以优先处理permanent的笔记做知识问答忽略fleeting的内容。summary摘要。初期留空后面让 WorkBuddy 自动生成回填。这就是 AI 驱动的价值点。有了这套 frontmatterAI 处理知识库时就有了筛选条件和回写位置所有批量操作都变得可行。3.3 目录与命名短文件名比好看更重要知识库的目录结构我建议浅而清晰三到四层即可。比如KnowledgeBase/ 00-收件箱/ # 临时想法未处理内容 10-项目/ # 按项目划分的笔记 20-领域/ # 按知识领域划分比如 AI、效率、写作 30-资源/ # 书摘、文章摘录、工具对比 90-归档/ # 已失效或不再使用的笔记数字前缀的作用是让文件夹排序可控。收件箱只有这一个入口所有快速记录先进那里处理完毕再移动位置。这种Inbox 模式在实际使用中非常有用保证 AI 扫描的时候不会把大量半成品当成成品内容。文件命名我坚持三条规则全小写、短横线分隔、不用空格和中文。比如obsidian-git-sync-troubleshooting.md而不是Obsidian Git 同步问题记录.md。理由是 Git 对特殊字符和中文文件名的处理在不同平台上有差异空格更是所有命令行操作的噩梦。给 AI 处理时干净的英文文件名也便于脚本匹配。3.4 双链与 MOCAI 的上下文跳板Obsidian 的双链语法[[笔记名]]不只是人类导航工具它给 AI 提供了天然的关联信息。当 AI 读一篇关于Obsidian Git 插件的笔记时如果里面链接着[[Gitee私有仓库配置]]和[[SSH密钥管理]]它就知道这个话题还有两个相关延伸点回答问题时可以把它们纳入上下文。MOCMap of Content内容地图是更高一层的结构。我每周会维护一到两个 MOC 页比如[[AI知识库总览]]里面用列表组织当前知识库的核心主题和对应笔记链接。这个页面像是 AI 的目录文件——它不用扫描全部三千篇笔记只要先读总览就能按图索骥找到相关内容。4. WorkBuddy 实战把 AI 接进知识库工作流4.1 安装与核心概念Skill 机制是关键WorkBuddy 的安装方式按官方说明操作即可支持桌面端环境。装好之后先理解它的三个核心概念会话你和 AI 的一次连续对话可以临时指定工作目录。Skill 技能把一段固定指令、工具调用、参数定义打包成一个可复用的技能。这是最核心的部分。文件系统访问WorkBuddy 可以授权读写指定文件夹这是它和普通聊天 AI 的本质区别。对知识库场景绝大多数能力都通过 Skill 实现。我配置了三个自用的 Skill知识库问答、笔记摘要回填、MOC 索引更新。下面分别讲。4.2 配置知识库问答Skill这个 Skill 的目标是让 WorkBuddy 基于你指定目录里的 Markdown 笔记回答问题并明确标注答案来源笔记。技能配置大致是这个结构{ name: kb_query, description: 基于个人知识库指定目录的Markdown笔记回答用户问题并返回引用来源。, tools: [read_file, list_files, search_files], instructions: 用户提问时先扫描目录下所有.md文件按问题关键词筛选候选笔记对候选笔记逐个读取综合内容给出回答回答末尾列出引用笔记的相对路径。若没有找到相关内容明确说明知识库中无该信息不要编造。 }具体字段格式会随 WorkBuddy 版本迭代变化但这个先扫描、再筛选、后引用的逻辑是核心。它确保 AI 回答时有据可依而不是凭空发挥。使用场景举例我在做一份季度总结前直接问 WorkBuddy根据知识库里 10-项目 目录下的笔记整理出我这个季度完成的三件主要事项。 它会把相关项目笔记全部读一遍再按时间线输出结果。过去我要手动翻半天现在几分钟就拿到草稿。这里有一个重要原则AI 的回答质量上限取决于你喂给它的笔记质量。如果知识库里全是碎片化的临时记录AI 也只能给你碎片化的答案。所以我在第 3 节强调的结构设计是整套体系能跑通的真正前提。4.3 批量任务自动摘要与标签补全比问答收益更大的是批量处理。我每个月跑一次旧笔记清理让 WorkBuddy 做三件事扫描00-收件箱里超过 30 天未修改的笔记。为每篇生成一句摘要回填到 frontmatter 的summary字段。根据内容自动补充tags标签。这个 Skill 的核心指令可以这样写扫描指定目录下的所有.md文件。 对每个文件执行以下步骤 1. 读取全文内容。 2. 识别主题和关键结论用不超过50字的中文写摘要。 3. 提取3个以内的主题标签。 4. 将摘要和标签更新到文件开头的frontmatter中保留其他字段不变。 处理完毕后输出一个清单列出所有处理过的文件名和包含的原始字段。最让我惊喜的是回填 frontmatter这个操作。因为笔记的元数据是结构化的AI 把摘要写回summary字段之后Dataview 插件立刻就能用这些元数据生成漂亮的索引表格整个知识库的可检索性跨了一个台阶。这形成了正循环越整洁的知识库AI 处理效果越好AI 处理得越好知识库越整洁。4.4 模型选择与成本考量WorkBuddy 需要对接模型服务这里有几个方向云端大模型效果好理解能力强适合高质量的问答和复杂整理。但需要注意两点一是按 token 计费如果让 AI 大批量扫描几千篇笔记成本不低二是隐私边界个人日记、工作机密等敏感内容传到云端要有这个意识。我的做法是只有public字段标记的可公开内容才交给云端模型处理私密内容用本地模型。本地模型通过 Ollama 这类工具跑量化小模型速度慢一些完全免费且内容不出本机。适合批量摘要这种不需要深度理解的重复劳动。我实际测试下来7B 级别的模型做标签补全和短摘要足够做复杂的多步推理还是云端模型更强。我的经验是分层使用日常知识问答走云端模型批量摘要和标签提取走本地模型。这样既控制了成本也保护了最私密的内容。WorkBuddy 支持多模型配置切换成本很低建议你两种都试试再定自己的策略。5. 日常闭环与跨设备协同我的实际操作流结构设计得再漂亮如果每天用起来太繁琐这套体系很快就会被抛弃。这一节我会还原一天的真实操作流以及多端协同中的关键细节。5.1 一天的工作流记录、榨取、同步我的日常流程可以用一句话总结随时随地记录定时批量榨取退出前自动同步。早上开始工作前我会打开 Obsidian。新想法直接扔进00-收件箱用 Templater 创建的模板自动带上前面的 frontmatter 结构。这个动作只需要十秒不需要任何格式上的纠结。下午如果写文档或者做研究相关素材按项目归档到10-项目或20-领域对应目录。边写边用的中间过程不用管 GitObsidian 的自动提交会在后台处理。工作收尾前我会打开 WorkBuddy针对当天新增的笔记问一两个问题比如今天记录的笔记里有哪些可以合并到已有的领域笔记AI 给出合并建议有时候直接生成合并后的大纲。这相当于每天让知识库重新梳理一遍。最后留意 Obsidian Git 插件的自动推送是否成功。如果失败我会手动执行一次推送避免笔记只在本地、云端没有最新版本。这一天的流程里AI 不是主角但它是最关键的执行者它把我记的内容转化为我能用的资产。5.2 多端编辑冲突处理我在台式机和笔记本之间切换编辑遇到过不少冲突。Obsidian Git 自动拉取 15 分钟一次如果两台设备同时编辑同一篇笔记就可能产生冲突文件内容里出现 HEAD这样的标记。处理冲突的正确顺序是这样的先不要盲目点保存否则可能把冲突标记一起存进去。在 Obsidian 里搜索冲突标记定位到冲突文件。手动选择要保留的内容删除冲突标记。在 Obsidian Git 命令面板执行Git: Commit把解决结果提交覆盖。这个问题的本质是 Git 对同一文件不同分支的合并策略。多端协同最常见的冲突场景是两台设备在同一段时间内修改了同一篇笔记所以我的经验策略是编辑之前先手动 pull 一次形成先拉后改的习惯可以规避大部分冲突。Obsidian Git 的自动拉取是兜底不是保险箱。5.3 版本回滚误删笔记的后悔药我曾经误删了一整篇写了三天的项目复盘当时脑子里嗡的一声。幸运的是Obsidian Git 在保存时已经把它提交到了 Gitee 仓库。恢复流程如下# 查看提交历史找到删除前的最后一次提交 git log --all --oneline -- 路径/被删笔记.md # 从指定提交中恢复该文件 git checkout 提交哈希 -- 路径/被删笔记.md文件立刻出现在本地目录Obsidian 刷新后完好如初。这种回滚到任意时刻的能力是知识库用 Git 托管最大的附加价值。没有版本控制的知识库一次手误可能就是永久损失有了版本控制你随时可以回到过去。5.4 手机上随时查Gitee 网页端兜底手机上我一般不编辑 Obsidian太难受。但需要临时查一篇笔记时方案很简单打开手机浏览器访问 Gitee 仓库页面直接预览任意 Markdown 文件的渲染效果。这虽然不如 Obsidian 移动端方便但胜在零配置、永远可用应急完全够。如果想要更完整的手机端方案可以考虑用第三方 Git 客户端配合 Obsidian 移动端。但我的建议是初期不要折腾这个真实知识管理需求大部分集中在电脑前手机端能看就行。等你确认体系稳定了再考虑移动端编辑的体验优化避免一上来被配置成本劝退。6. 踩过的坑与优化思路任何工具组合用一段时间之后一定会暴露问题。这节记录我踩过的坑以及对应的解决思路可以帮你少走弯路。6.1 仓库体积膨胀附件和二进制文件怎么办用了一段时间我遇到过一个明确警告Gitee 仓库体积逼近限制。原因是我的知识库被塞进了大量截图和 PDF。Git 对文本文件极其高效但对二进制文件毫无办法每一份图片改动都会产生全新的副本仓库体积迅速膨胀。解决办法分三层附件外移图片统一放到 Vault 外的专用附件目录或者干脆用图床。Obsidian 可以设置附件默认路径在设置里把图片保存位置指向 Vault 外即可。大文件不进 Git超过几十 MB 的 PDF、压缩包、视频不要放知识库仓库。用网盘或对象存储托管在笔记里留链接。定期瘦身如果仓库已经很大了用 git 过滤历史大文件重写提交历史但这一步操作有风险建议先备份再动手。或者更稳妥的方式开一个新仓库把当前内容重新初始化旧仓库存保留档。6.2 同步节奏不当导致的云端漂移Obsidian Git 插件配置了自动推拉但它的定时任务依赖 Obsidian 应用处于运行状态。如果你长时间不打开 Obsidian笔记自然不会被推送。可能发生的情况是你一周后打开 Obsidian发现插件一次性推了数百个提交或者自动拉取时和本地产生大量冲突。我的解决思路是给同步设置固定检查点。每天收工时手动执行一次Git: BackupObsidian Git 插件提供的完整备份命令确保当天内容全部入仓。周末再做一次全量查看。不要依赖插件定时的后台任务定时任务只是保险主动备份才是纪律。6.3 WorkBuddy 对超长上下文的妥协让 WorkBuddy 一口气处理几百篇笔记时我发现一个现实问题上下文窗口再大也有极限指令目标过大会导致 AI 丢失前文信息、中间结果失真。比如让它批量更新整个知识库的标签跑到后面它会忘记最初的规则。解决方案是分块处理。一次只处理一个目录或者一次只处理 30 篇笔记处理完一批先验证效果再继续下一批。把一个大任务拆成若干小任务看起来效率低了实际结果反而更可靠。这跟软件工程里小步提交是一个道理。还有个细节WorkBuddy 处理大量小文件时我建议先在 Skill 指令里明确跳过 frontmatter 中已有 summary 字段且 status 为 permanent 的笔记避免重复劳动也避免 AI 反复改写已稳定的内容。6.4 备份不能只靠同步异地双仓库加定期导出最后一条也是我这两年最深刻的教训同步不等于备份。如果你的 Gitee 账号被盗、仓库被误删或者 Gitee 服务本身出问题本地和云端会同时失去数据。所以我现在的策略是在同步之外再加一层真正的备份每个月把 Vault 目录用压缩工具打包一次传到独立的对象存储或网盘。有条件的话在另一个 Git 托管平台建一个私有镜像仓库定期 push 过去。重要程度极高的工作笔记我会单独导出 PDF 存档。这套体系的核心思想永远是本地一份、同步一份、冷备一份的备份架构。Obsidian、WorkBuddy、Gitee 都只是支撑这一架构的工具知识库的安全底线不能寄托在任何一个单点上。还有一个容易被忽略的点Gitee 私有仓库也建议设置强密码和二次验证SSH 密钥的私钥文件不要随意同步到云盘。你的知识库包含了你多年的思考脉络它的价值不亚于任何重要资产安全等级应该匹配得上。最后说点实际操作中的体会搭完这套系统后我最明显的感觉不是我的笔记变多了而是我的笔记开始主动产生价值。以前每次打开知识库都是负担——内容多到不知道从哪里下手。现在有了 WorkBuddy 这个执行层我可以让它去整理、摘要、关联、回答知识库从被动的存储空间变成了真正会思考的工作伙伴。如果让我给刚接触这套组合的人一个建议我不会建议你一开始就配齐所有插件、所有 Skill、所有自动化流程。先用最朴素的方式跑起来Obsidian 记笔记Gitee 做同步WorkBuddy 只做问答。等这三个环节都稳定运转了再逐步把批量摘要、标签补全、MOC 自动维护这些高级玩法加进来。知识库建设是一个持续积累的过程工具只是放大器你的持续记录才是原动力。最后分享一个我每周都会做的小仪式周五下午让 WorkBuddy 随便挑三篇三个月前的旧笔记重新阅读、重新整理。这短短十分钟让我发现很多当时记录时觉得普通的内容回头再看全是宝贵的经验。AI 驱动的个人知识库最迷人的地方就在这里——它帮你把过去的自己重新变成现在的自己的智囊。