1. 为什么是 Obsidian WorkBuddy Gitee这套组合解决的真实痛点先说个扎心的事实我见过太多人的知识库建的时候热血沸腾三个月后沦为吃灰文件夹。笔记越记越乱标签体系崩坏搜索靠滚动跨设备同步靠“微信传输助手”——这哪里是知识库根本就是数字垃圾场。我自己也经历过这个阶段。从最初用 Word 存资料到后来换各种笔记软件再到自建博客走了不少弯路。最后留在我工作流里、真正每天都在用的就是 Obsidian WorkBuddy Gitee 这套组合。它不是最炫的但绝对是最能打的。这套组合解决的真实痛点可以拆成三个层面第一输入端的碎片化。我一天要接触的信息来源太多了——网页文章、PDF 论文、开会记录、灵感闪念、代码片段。如果没有一个统一的收纳容器信息就散落在各个 App 里。Obsidian 的本地 Markdown 体系之所以适合做底座是因为它把笔记变成了一堆纯文本文件不锁定格式、不绑架数据。文件就在硬盘上随时可以用任何编辑器打开几十年后都不会打不开。第二加工端的低效。光收纳还不够知识库的核心价值在于“加工”——把零散信息变成结构化知识。这一步过去全靠人工读一遍、提炼一遍、整理一遍时间成本极高。WorkBuddy 这类 AI 工作台的价值就在这里它能直接读取我 Obsidian 库里的内容做摘要、对比、重组、扩写把我从重复劳动里解放出来。第三存储端的备份焦虑。本地文件有个致命弱点——硬盘会坏电脑会丢。数据全部放在本地等于裸奔。Gitee 作为国内的代码托管平台访问速度快私有仓库免费正好用来给知识库做版本管理和异地备份。一句话总结这套组合Obsidian 负责“记”WorkBuddy 负责“想”Gitee 负责“存”。三者各干各的活又通过文件系统天然打通——因为它们处理的都是最普通的 Markdown 文本文件没有任何格式壁垒。如果你是知识工作者、程序员、产品经理、研究生或者任何需要长期积累信息的人这篇文章都值得看完。我会把从零搭建到日常使用的完整流程、踩坑经验、以及让 AI 真正参与知识管理的方法一次性讲清楚。2. 环境搭建从 Gitee 仓库到本地 Obsidian 库的完整链路2.1 先建远端仓库再初始化本地库正确的顺序是先在 Gitee 上建仓库再把本地文件夹变成 Git 仓库最后用 Obsidian 打开这个文件夹。这样做的好处是远端地址从一开始就明确省得后面反复改配置。在 Gitee 上创建仓库时有几个选项需要留意仓库名称建议用knowledge-base或者obsidian-vault这种一眼能看懂的名字。别用拼音缩写三个月后你自己都认不出来。私有还是公开知识库强烈建议选私有。虽然 Gitee 的私有仓库对个人用户免费但有些历史包袱要注意——如果你后期想配合 Pages 服务搭建个人博客私有仓库用不了 Pages到时候再调整。初始化仓库不要勾选“初始化仓库”里那些自动生成 README、.gitignore 的选项。让仓库完全空白方便本地作为唯一源头推上去避免产生无谓的 merge 冲突。开源许可证个人私有知识库不涉及开源选“无”就行。本地这边我推荐用 Git BashWindows或者系统自带终端macOS/Linux操作。命令行听起来吓人但其实只需要记住几条固定命令完全够用。整个初始化流程如下# 进入你想存放知识库的目录 cd /d/workspace # 克隆空仓库到本地。注意替换成你自己的仓库地址 git clone gitgitee.com:yourname/knowledge-base.git # 进入仓库目录 cd knowledge-base # 创建一个基础目录结构这里按我的习惯来 mkdir -p 01-Inbox 02-Projects 03-Areas 04-Archive 05-Resources _attachments # 告诉 Git 忽略临时文件 echo .DS_Store .gitignore echo .obsidian/workspace.json .gitignore # 首次提交 git add . git commit -m init: 初始化知识库目录结构 git push origin main这里面_attachments目录很有必要单独建。Obsidian 默认会把粘贴的图片存到库根目录下一个叫Pasted Images的文件夹如果你不干预时间长了根目录会变得非常乱。我们在早期就规划好附件目录Obsidian 设置里指向它后面就省心了。2.2 配置 SSH 密钥让推送不再输密码用 HTTPS 方式推送也不是不行但每次都要输用户名密码体验很糟。而且 Gitee 的 HTTPS 推送偶尔会抽风提示密码错误——其实不是密码错了是 Gitee 要求用“私人令牌”而不是账户密码。这个坑我踩过浪费了半个小时。推荐直接上 SSH 密钥。整个过程分三步第一步生成本机密钥对ssh-keygen -t ed25519 -C your_emailexample.com一路回车就行。ed25519比传统的rsa更安全、更短Gitee 是支持的。生成的密钥默认在~/.ssh/id_ed25519目录下其中.pub后缀的文件是公钥可以公开没有后缀的私钥文件打死不能泄露。第二步把公钥填到 Gitee登录 Gitee进入“设置 → 安全设置 → SSH 公钥”把id_ed25519.pub文件内容完整复制粘贴进去标题随便写个比如“我自己的电脑”。保存之后可以测试连通性ssh -T gitgitee.com第一次连接会提示“Are you sure you want to continue connecting”输入yes回车。如果配置成功会返回一串欢迎语类似于“Successfully authenticated”。第三步把本地仓库的远端地址改为 SSH 形式git remote set-url origin gitgitee.com:yourname/knowledge-base.git改完之后试试推送不再要密码一秒完成这个体验才配得上“自动化”三个字。2.3 Obsidian 侧的关键设置打开 Obsidian选择“打开本地仓库”选中刚才那个文件夹Obsidian 就能识别这是一个 vault 了。但此时还不能直接用有几个设置必须改关闭 Obsidian 同步插件内置的 Obsidian Sync 是付费商业服务我们用 Gitee 免费方案不需要它。设置附件默认路径设置 → 文件与链接 → 附件默认保存路径选择“指定文件夹”指向_attachments。这样之后粘贴图片、拖入 PDF都会自动归位。关闭自动更新设置 → 关于 → 自动更新建议关闭。因为某些第三方插件对 Obsidian 版本敏感自动更新可能导致插件兼容问题。新笔记默认格式设置 → 编辑器 → 默认编辑格式选 Markdown。禁用“自动保存”的顾虑Obsidian 本身就是实时保存的不用担心断电丢内容。这套基础环境搭完之后你的本地知识库骨架就成型了。下一步让 AI 进场。3. 让 WorkBuddy 接入知识库核心配置与使用姿势3.1 WorkBuddy 是什么以及它在这套体系里的定位WorkBuddy 是一款 AI 工作台产品核心能力是“理解你的文件 执行你的任务”。注意关键词是“工作台”——它不只是个聊天机器人而是能基于指定目录或文件做处理的操作平台。这也是为什么它特别适合放进知识库工作流市面上大多数 AI 工具你只能“复制粘贴”内容进去而 WorkBuddy 可以直接读取本机文件把 AI 处理和知识库文件系统连成一条线。在开始之前我补充一句WorkBuddy 这个名字在搜索结果里经常和 CodeBuddy 同时出现前者偏通用任务执行后者偏编码场景。我们这里讨论的是 WorkBuddy 在知识管理上的用法并不涉及代码生成场景。安装过程不多赘述官网下载客户端、安装、注册账号即可。重点在于它和 Obsidian 库的协同方式——本质上是给 WorkBuddy 开一个“读取本机目录”的权限通道。在 WorkBuddy 的对话窗口或任务面板里可以直接指定本地路径让它访问你 Obsidian 库所在的文件夹。3.2 给 WorkBuddy 的正确“投喂姿势”很多人在第一步就翻了车把 AI 当成搜索引擎问“帮我总结一下我的知识库”。这个问题太宽泛了AI 即使能读文件也不知道你想总结什么、以什么形式输出。我摸索出来的有效姿势是先缩小范围再明确动作最后约束输出格式。举个具体例子。我在读一批关于 LLM 的 PDF 文章想把它们变成一份对比笔记。正确的 WorkBuddy 指令应该长这样请读取 /path/to/vault/05-Resources/LLM 目录下的所有 PDF 文件。 任务 1. 提取每篇文章的核心观点每篇不超过 200 字。 2. 从「训练方法」「推理成本」「适用场景」三个维度做横向对比。 3. 输出为 Markdown 表格形式。 4. 将结果保存到新文件 /path/to/vault/02-Projects/LLM对比笔记.md看到了吗目录范围、任务动作、输出格式、结果去向这四个要素全部明确。AI 不需要猜你想要什么出错的概率大幅下降。还有一个小技巧在 Obsidian 里给每条笔记的 YAML front matter 写上元信息包括 tags、source、date。WorkBuddy 读取文件时能顺着这些元信息做更精准的分类处理。比如--- tags: [AI, LLM, 论文笔记] source: arxiv date: 2025-04-15 ---这些元信息对 AI 而言就是“路标”让它在处理文件时有上下文依据加工出来的内容质量高一个档次。3.3 我常用的三类 WorkBuddy 任务模板用得久了我攒下几个固定的指令模板分享出来供参考模板一周回顾摘要读取 /path/to/vault/01-Inbox 目录下本周新增的所有笔记。 按主题聚类输出一篇「周回顾」总结 - 每类主题的核心产出是什么 - 有哪些尚未解决的问题 - 建议下一步行动 保存到 /path/to/vault/02-Projects/Weekly/2025-WXX.md这个模板帮我解决了一个老大难问题周报不会写。以前每周五都要花一两个小时翻笔记回忆现在 WorkBuddy 在五分钟内生成初稿我在它基础上改一改就交。模板二零散观点重组以下是我的几条零散笔记 [粘贴内容] 请找出它们之间的逻辑关系合并成一篇结构化的主题笔记。 要求保留原有观点不改写添加小标题和层级结构末尾输出「当前知识缺口」列表。模板三旧笔记深度清洗读取 /path/to/vault/03-Areas/某个旧笔记.md 这份笔记记于一年前现在我要重新使用它。 请 1. 检查事实性信息是否可能过时 2. 重新组织结构删除重复内容 3. 为它补充相关的反向链接建议这三个模板覆盖了我 80% 的日常需求。剩下的 20% 属于即兴任务比如“把这段话改得更口语化”“给这个项目写个 README”——本质上也是文件读取加输出重写。3.4 一个重要的认知AI 是加工厂不是记忆宫殿这里必须泼盆冷水。有些朋友用 Obsidian 搭配 AI 工具期待它能变成“第二大脑”——问它“去年三月我记过什么”它秒答。这个期待现阶段并不现实。AI 工具做的是基于上下文的加工不是全库检索。当它读取一个目录时处理的是这个目录里的文件你让它回忆一条从未给它看过或者很久远的内容它只能凭全局知识“编”这时候给出的答案就不可靠了。所以我的原则是凡是需要 AI 加工的信息把范围限定在具体文件或文件夹凡是需要“记得”的信息靠 Obsidian 的搜索和反向链接机制解决。两者搭配AI 做深度加工Obsidian 做广度关联各司其职。4. 日常三连工作流记录 → 智能加工 → 自动同步4.1 记录环节给 Obsidian 立几条输入规矩知识库能不能用起来80% 取决于输入端的纪律。我给自己定了四条规矩规矩一任何想法先进 Inbox。极速记录插件装好全局快捷键一按就能呼出输入框记完自动保存到01-Inbox。先记录下来分类整理是后面的事。这条是防止“因为来不及打字而失去想法”的关键。规矩二每条笔记只写一个主题。灵感是发散的但笔记必须有边界。一条笔记试图塞下五个话题未来检索时它大概率只被使用一次剩下的内容全被浪费。规矩三来源必留。引用外部信息时在笔记末尾写上来源链接和摘录日期。这件事 AI 也能帮做但养成手动标注的习惯更保险——AI 有幻觉你的笔记不能有。规矩四每周日做一次 Inbox 清空。把所有新进的东西打上标签、归入对应目录。如果某条笔记已经没价值了直接删。Inbox 永远保持在几乎清空的状态这样它才能一直承担“临时收容”的职能。要是放任 Inbox 涨到几百条那就跟不分类没区别了。4.2 加工环节让 WorkBuddy 参与的三类高频操作日常加工分三个场景每个场景有不同的指令写法场景一文章精读。网上的长文复制到 Inbox选中后丢给 WorkBuddy“把上面这篇文章压缩成 500 字摘要提取核心观点和可执行建议输出为 Markdown 格式。”生成后把摘要放正文原文链接放来源栏。以后检索时摘要就是第一条信息正文只是备查。这个习惯让我的阅读效率起码翻了一倍——不是不看了而是先把框架吃透值得精读的部分再翻开原文。场景二会议纪要整理。会议中的零散记录直接语音转文字丢进 Inbox。事后让 WorkBuddy 处理“按论点依次整理上面内容标注每个观点的赞成方和分歧点末尾输出待办事项列表。”生成的结构化纪要比我自己整理板正得多而且待办事项可以直接复制到任务管理工具。场景三资料关联梳理。当你手里有三五篇相关的旧笔记想看看它们能碰撞出什么新东西时把文件路径都甩给 WorkBuddy“读取这几篇笔记找出共同主题和冲突观点输出一篇综合对比分析。”这一招特别适合做文献综述或者方案对比人工读这几篇要一小时AI 五分钟出草稿你再花半小时精修效率差距肉眼可见。关于加工质量我给三点建议第一AI 生成的内容一定要过一遍手。它可能遗漏微妙细节、用词不够精准、或者做出了过度概括。把它当“初稿机器”而不是“成品机器”。第二生成结果带出原始引用。指令里加上“每个观点后面标注来源笔记名称”这样你能回溯到原文件避免断章取义。第三把 AI 产出的好模板沉淀下来。如果某次输出你只需要改几个字就能用那下次把同样的指令保存成 easy 模板持续复用。4.3 同步环节推送 Gitee 的两种方式对比处理完信息本地文件已经更新了但远端 Gitee 仓库还是旧版本。这时候需要同步。方法一手动推送。在 Obsidian 里装了 Git 插件后可以设置一个快捷键来执行 commit push 二连动作。我习惯在每天工作收尾时按一下形成肌肉记忆。这个方法“手动”但很可靠——你清楚知道自己推了什么。如果将来某次同步出问题能精确回溯到是哪个提交造成的。方法二自动推送。Obsidian 的 Git 插件支持设置“自动备份”功能每隔一段时间就自动提交和推送。表面看省心实际有个隐患本地 Git 历史会产生大量无意义的提交记录把仓库变成“每条笔记每次修改都一条提交”的流水账。想回溯某一周的变化时diff 结果会被噪音淹没。我的折中方案是工作结束统一手动推一次并写一条有语义的 commit message。比如git add . git commit -m 周回顾LLM 对比笔记 3 篇新文章摘要 git push这条记录本身就是当天的知识产出清单三个月后回看这些 commit能清楚还原自己研究轨迹。自动推送做不到这一点。那 Obsidian Git 插件还有没有存在意义有它提供图形界面的 commit、push、pull 操作不用去命令行敲命令了。插件设置里把“自动提交”关掉保留手动按钮就刚刚好。5. 联调阶段最容易踩的三个坑5.1 多设备编辑导致的 Git 冲突在笔记本和台式机之间来回切换几乎每个人都会遇到一次 Git 冲突。症状很典型在某台设备上git pull时提示“CONFLICT (content): Merge conflict in xxx.md”文件里出现一堆 HEAD和标记。冲突的核心原因是同一份文件在两台设备上都被修改了而 Git 不知道该保留哪一个版本。预防为主的做法是每次切换设备前先 pull 最新代码再开始工作。 Obsidian Git 插件提供了“拉取变更”按钮切换设备的第一件事就是按它。如果冲突已经发生了处理方法也很简单用编辑器打开冲突文件手工选择保留哪段内容删掉冲突标记。然后 commit push 收尾。Markdown 文件不像代码文件那样有复杂的合并需求冲突处理成本通常很低几分钟搞定。还有一个细节值得说Obsidian 自身的配置也会参与同步特别是工作区布局文件workspace.json。如果两台设备在关闭 Obsidian 时布局不同这个文件就会产生冲突。解决方案是在.gitignore里把它排除掉让布局配置只留在本机不进入同步链。我前面环境搭建时已经在.gitignore里加了一行就是这个原因。5.2 附件越来越多仓库迅速膨胀知识库用久了真正占体积的不是 Markdown 文本——写十年的纯文本可能还没一部电影大——而是塞进_attachments的图片、PDF、音频文件。仓库体积和 Git 操作的性能是强相关的仓库变成 2GB 以后每次 push 的体验会明显变卡。应对思路有三条第一条控制入口。图片尽量压缩PDF 只保留真正要精读的在手机上只想“存着以后再看”的放到网盘而不是知识库。第二条定期清理。每季度审查一次_attachments把不再需要的文件移出库目录。提醒一下移动附件会导致笔记里的链接失效最好只在确实不再使用时才删。第三条把大文件移出 Git 管理。超过 20MB 的单体文件用 Git LFS大文件存储或者干脆不要放知识库。最省心的做法是知识库里只放“文字”和“需要长期锚定的少量图片”其他一切放外部存储。这跟我们前面说的“Obsidian 负责记Gitee 负责存”有一个隐含前提——存的是纯文本精华不是杂物间。5.3 WorkBuddy 理解偏差AI 再厉害也有翻车时候。我遇到过它把我笔记里的“建议方案 A 优于 B”在摘要里理解成“B 是推荐方案”导致我在周报里引用错了结论。发现这个问题的教训是AI 加工结果必须和原始内容做一致性抽检。尤其是事实型、结论型信息抽检比例不要低于 30%。对重要笔记我会在 WorkBuddy 输出后用 Obsidian 打开原文对照关键论点看一遍确认没有方向性错误再入库。AI 的摘要适合用于定位和筛选不适合作为最终引用依据。另外WorkBuddy 读取文件的范围需要留意。当指定目录中有大量毫不相关的主题混在一起时它会难以辨别优先级产生不稳定的输出。所以每个目录内的主题越聚焦AI 的加工准确率越高——这反过来倒逼了我的知识库目录体系保持整洁。6. 进阶玩法让这套知识库真正“活”起来6.1 双链 AI 的双重关联体系基础工作流跑通之后我开始琢磨怎么让知识库产生“网络效应”。Obsidian 的核心能力之一是双链——用[[笔记名]]语法把笔记连成网。而 WorkBuddy 的加工能力恰好能帮这个网络自动生长。我的做法是在通过 WorkBuddy 生成新笔记或者整理旧笔记时在指令中明确要求“补充相关笔记的双链建议”。比如读取 /path/to/vault/03-Areas/思维模型.md 请为它的每个核心概念推荐 2 个现有笔记作为反向链接如果它们相关。 输出格式概念 → 推荐链接笔记 → 理由AI 会遍历整个目录基于语义相关性给出建议。我人工过一遍觉得合理的就补上链接。这个过程让 AI 扮演了一个“知识关联助手”的角色很多我凭记忆根本想不起来的关联AI 能找到。双链体系建立起来后Obsidian 的“关系图谱”视图才会真正有意义——从一个主笔记出发能顺着链接走到相邻主题知识不再是孤岛而是一张可以持续生长的网。6.2 用 Gitee Webhook 或者定时任务实现全自动备份前面我讲了手动推送的好处但有些场景确实需要自动化兜底。比如出差在外、电脑突然故障如果你已经半个月没推过 Gitee数据风险就大了。我的做法是手动推送为主 每周一次自动保险推送。在 Windows 上用“任务计划程序”在 macOS 上用 launchd设置每周五晚上自动执行一次“提交并推送”。由于大部分时候没有新变更这个自动任务基本是空跑不会产生噪音。但万一你哪天忘了手动推这个兜底的自动任务就保护了你的数据。这条防线对知识库来说足够可靠了。毕竟知识库不像软件项目那么紧急丢失一天的数据可以接受也好过全部丢失每周一次的自动备份能把损失降到最低。6.3 把 WorkBuddy 生成的笔记反向补充到日常流程最后讲一个让我工作流产生质变的习惯把 WorkBuddy 的输出变成新一轮输入。举个例子。WorkBuddy 帮我做了一篇“LLM 对比笔记”其中提到某个模型在推理成本上有显著优势。这条信息并不会躺在笔记里“死亡”它可以作为线索触发我下一步行动——找这篇原始论文、深入研究其技术细节、把心得写成新笔记。于是知识库的“输入 → 加工 → 输出 → 新输入”闭环就形成了。具体到操作层面我每周会抽出一小时打开 WorkBuddy 生成的所有近期笔记找出里面有“进一步研究价值”的钩子把这些钩子拆成任务丢进待办清单。这一小时的名字叫“知识梳理”效果比盲目地多记十篇笔记好得多。这也是我反复想强调的观念知识库的体量不等于价值。真正有价值的是内容之间的连接、提炼和循环——AI 帮你加速这个过程但不能替代你的判断力。最后分享一个经验之谈不要在一开始就追求完美体系。Obsidian 的目录结构先简单点WorkBuddy 的指令模板先攒个两三条Gitee 推送先保证每天一次。跑通一个极简闭环再逐步增加环节。知识库建设最怕的不是走弯路而是建了个精密的空壳从不往里面放东西。工具永远是服务于产出的只要你想记录、思考和沉淀这套组合就能帮上忙。