我见过太多人把知识库做成“数字垃圾场”收藏了几百篇文章笔记写了上千条真到用的时候什么都搜不到。自己也踩过这个坑直到把 Obsidian、WorkBuddy、Gitee 这三样东西组合到一起才算是把个人知识库从“能记”推进到了“能用”的阶段。这套组合的核心逻辑很简单——Obsidian 负责本地笔记的组织和沉淀WorkBuddy 负责把 AI 能力灌进工作流里Gitee 负责解决多设备同步和历史版本回溯。三者各管一段拼成一条完整的链路输入素材 → AI 处理后落库 → 多端同步与版本管理。这篇文章就把这套组合从零到一的搭建过程、我在实际使用中踩过的坑、以及一些常规文档里不会写的小技巧一并整理出来。不管你是刚开始接触 Obsidian 的新手还是已经用了一段时间但想引入 AI 能力的老用户都可以参考这套方案。1. 方案设计为什么是“本地笔记 AI 处理 Git 同步”这个组合1.1 先想清楚知识库到底要解决什么问题很多人搭知识库第一步就选错了方向。上来先研究哪个笔记软件好看、哪个插件炫酷折腾半天主题和图标最后笔记没写几条。知识库的核心不是“记录”是“检索”和“复用”。你记下来的东西在需要的时候能快速找到能和其他知识产生关联能被二次加工成新的产出——这才是知识库存在的意义。基于这个目标我给自己的知识库定了三条硬性要求数据必须在我自己手里不能依赖某个云服务商的存活性内容必须能被程序化处理方便用 AI 做批量加工版本必须可回溯防止误操作把整批笔记搞丢。按这三条标准筛下来Obsidian 几乎是唯一的选择——纯本地 Markdown 文件存储插件生态成熟数据格式开放不存在厂商锁定的问题。1.2 三个工具各自的角色定位这套组合里每个工具承担的角色完全不同不要混为一谈。Obsidian 是“仓库”负责所有笔记文件的存储、组织和呈现。它的核心能力是双向链接和图谱视图但我觉得对大多数人来说真正好用的是它基于本地 Markdown 的特性——每个笔记都是一个纯文本文件没有数据库、没有私有格式随时可以用其他工具打开和编辑。WorkBuddy 是“加工线”负责把 AI 能力嵌入到知识管理的各个环节。比如批量生成笔记摘要、根据已有笔记内容回答问题、把零散的素材整理成结构化文档、甚至自动为笔记打标签和建立关联。它解决的是知识库“重建设、轻使用”的问题——笔记存进去之后不能就躺着吃灰得让 AI 持续帮你盘活这些内容。Gitee 是“保险柜加传输带”负责两件事多设备之间的笔记同步以及历史版本的留存。Obsidian 官方提供的 Sync 服务收费不低第三方同步方案又各有各的毛病。用 Git 仓库做同步是技术人最顺手的路子——免费、可靠、可回溯。Gitee 在国内访问速度快还提供了私有仓库正好满足需求。1.3 这条链路的工作流程整套系统的运转流程可以概括为三步。第一步是“摄入”无论是网页文章、PDF 摘录、读书笔记还是随手灵感统一以 Markdown 格式落入 Obsidian 仓库的对应目录第二步是“加工”WorkBuddy 定时或按需对新增笔记做摘要提取、关键词标注、知识点关联把零散的素材转化为有结构的知识单元第三步是“同步”写完或者加工完Git 提交推送Gitee 仓库自动更新其他设备拉取即可获得最新内容。这套流程的好处在于每一步都有明确的工具负责互不干扰。Obsidian 不负责同步所以不需要折腾它的插件生态里的同步方案WorkBuddy 不负责存储所以不会出现 AI 生成的内容散落在各个对话中无法沉淀的情况Gitee 不负责内容组织所以不会出现代码仓库和知识库结构相互污染的问题。各司其职出了故障也容易排查——哪个环节坏了替换哪个环节就行。2. 实操准备Obsidian 仓库搭建和目录结构设计2.1 Obsidian 安装与基础配置Obsidian 的安装没什么好说的官网下载对应平台版本即可。Windows、macOS、Linux 都有原生客户端移动端也有 App。我要强调两点新手容易忽略的配置。第一关闭“自动更新”不等于不更新而是要在确认插件兼容性后再手动升级。Obsidian 的插件生态更新速度很快但反过来也意味着某个插件可能因为核心版本升级而失效。我自己的做法是核心版本保持在次新状态新版本发布后等一周左右再升级给插件作者留出适配时间。第二打开设置里的“附件默认存放路径”让它指向一个统一的_attachments文件夹。 Obsidian 默认会把你插入的图片存到和笔记相同的目录下短期没问题但当你开始用 Git 做同步时散落在各个目录的图片文件会让仓库体积迅速膨胀也会让目录结构变得混乱。统一存放后续做清理、压缩、迁移都方便。2.2 目录结构设计别让笔记变成深渊目录设计直接影响知识库的可用性。很多人刚开始用 Obsidian 的时候脑子里想的是“怎么分类”于是建了一堆套娃文件夹——生活/工作/学习/项目/读书笔记/会议记录……听起来很合理实际用起来会发现一个问题一条笔记往往属于多个分类你根本不知道该把它放哪里。我用的是一种混合结构核心是“按来源分不按主题分”。具体来说00_收件箱所有临时性、未处理的素材都扔这里相当于一个物理世界的“待办篮子”。10_项目按当前正在推进的项目各建一个文件夹项目内部的笔记天然内聚。20_领域按长期关注的领域存放比如编程、设计、写作、管理。这类笔记往往是跨项目的沉淀。30_资源读书笔记、文章摘录、视频课程的笔记统一放这里作为外部知识的输入口。40_归档已经完成不再活跃的项目或过期内容整体移入归档区不影响当前工作视野。这个结构的关键是“收件箱”的存在。任何新素材进来先丢进收件箱不做分类决策。等素材积累到一定程度或者某个主题相关的笔记超过三五条再花十分钟统一整理归类。这样做的好处是让分类动作延迟进行避免在采集阶段消耗过多心智。2.3 给笔记定义统一的模板模板是 Obsidian 知识库最容易见效、也最容易被忽视的功能。我建议至少准备两种模板一种给日常笔记用一种给读书笔记用。日常笔记模板包含以下字段标题、创建日期、标签、来源URL 或书名、一句话摘要、正文。其中“一句话摘要”是我后加进去的也是我在引入 WorkBuddy 之后才意识到的价值——让 AI 帮你生成摘要很容易但如果没有强制留出这个字段的位置AI 生成的摘要就只能散落在对话里无法沉淀到笔记本身。模板用 Obsidian 内置的 Templater 插件管理配合 QuickAdd 可以实现输入命令直接创建带模板的笔记。这块后面在插件配置里细说。3. WorkBuddy 接入把 AI 能力注入知识管理全流程3.1 WorkBuddy 是什么它能做什么WorkBuddy 本质上是一个 AI 智能体工作台类似 CodeBuddy 的生态但它更侧重于把 AI 能力编排成可复用、可组合的工作流。你可以把它理解为“能调教 AI 替你干活的中控台”。它支持定义自己的 skill技能也就是把一段提示词、交互流程和工具调用封装成一个可以被反复调用的能力单元。在知识管理的场景下WorkBuddy 实际解决的是三类问题。第一类是“改写润色”——把口语化的灵感整理成结构清晰的笔记第二类是“提取关联”——从已有的笔记库中找出与当前笔记相关的知识点并自动生成双向链接第三类是“批量操作”——对一批历史笔记做统一的格式修正、标签补充或摘要生成。3.2 在 WorkBuddy 中配置知识库加工技能WorkBuddy 的使用核心在于 skill 的配置。与直接使用聊天窗口不同skill 的目的是把一次性的、靠临时对话实现的操作固化为可重复使用的标准化流程。以“笔记摘要生成”这个 skill 为例大致步骤是这样的在 WorkBuddy 中新建一个 skill命名为“obsidian_note_summary”。定义 skill 的输入参数笔记路径、摘要长度、输出语言。编写核心提示词要求 AI 读取指定 Markdown 文件的内容提取核心论点、关键数据和结论按照“一句话摘要 三个要点 相关名词”的结构输出。开启工具调用权限让 skill 可以直接读写本地文件系统中的 Obsidian 仓库目录。保存并测试先拿一两条笔记跑一遍观察摘要质量调整提示词。实际用下来提示词里最关键的一句是“不要试图忠实地复述原文而是提炼出你自己读完后的理解”。没有这句AI 生成的摘要常常是把原文段落改写了一遍失去了摘要的意义。3.3 把不常用的笔记批量盘活知识库建久了最尴尬的事情是仓库里有上千条笔记但每次搜索的时候翻来覆去看到的还是那几篇新的。大量历史笔记其实质量不错只是因为没有摘要、标签不准确、格式混乱导致它们在搜索和关联时失去了被触达的机会。用 WorkBuddy 做一次存量笔记的“体检”和“加工”可以大幅改善这种情况。具体操作是先让 AI 扫描指定目录下所有笔记文件找出缺少摘要标签的、字数异常的、内部链接为空的笔记生成一份清单然后针对清单批量执行补摘要、补标签、清理格式的操作。这个环节要注意控制批量操作的节奏不要图省事一下子把全库几千条笔记一次性交给 AI 处理。建议按目录或者按时间分批跑每次几十条人工抽查其中几条的质量确认没问题再继续。AI 生成的标签和摘要质量不稳定一次性全量处理出错了很难排查。3.4 用 AI 辅助“输出”而不只是“输入”很多人把 AI 用在知识库的“写入”环节——帮你写笔记、写摘要这当然有用但 AI 在知识库上的价值远不止于此。我一年来用得最多、也最觉得值回票价的场景全部集中在“输出”环节。比如写周报的时候我让 WorkBuddy 读取过去一周新增的项目笔记自动汇总成一份周报草稿写技术方案的时候让它从领域文件夹里提取相关的历史笔记整理成前情摘要帮我在动笔之前快速回忆起当时的思路做文章大纲的时候直接从一个主题关键词出发让 AI 在仓库里检索相关内容生成包含内部链接的大纲框架。这些场景的共同点是用 AI 把你积累的“库存”变成可用的“产出”而不是单纯帮你在空白文档里堆字。这个方向其实是个人知识库从“死库”变“活库”的转折点。笔记不只是用来回头看的东西它更应该成为你持续产出的素材库和弹药库。4. Gitee 同步给知识库上一道“版本保险”4.1 为什么选 Gitee 而不是云盘或网盘知识库的同步方案选择很多人第一反应是网盘或云盘但这些方案有几个绕不开的问题首先数据经过第三方平台处理你的笔记内容理论上对服务商透明其次网盘的双向同步逻辑和 Git 有本质区别你无法精确知道哪些文件发生了变化、恢复到某个历史版本的成本有多高再次笔记里常常有代码片段、配置信息网盘对这类文件的支持并不友好。Gitee 作为国内代码托管平台本质是一个标准的 Git 服务。用 Git 做笔记同步你的每一次修改都会产生一个可追溯的提交记录每一条笔记的任何历史版本都可以一键恢复。多设备之间的冲突处理Git 的机制也比网盘的“复制冲突副本”优雅得多。再加上私有仓库完全免费Gitee 就成了绕不开的选项。4.2 从零开始创建仓库和配置 SSH 密钥Gitee 仓库的创建非常简单注册登录后在首页点“新建仓库”填写仓库名选择私有仓库即可。划重点选“私有”而不是“公开”。知识库是你的私人资产公开仓库等于把笔记内容向所有人开放大多数人的笔记里都含有不该公开的内容。另外初始化仓库时不要勾选“初始化仓库”保持空仓库状态这样本地已建立的 Obsidian 仓库可以直接推上去。SSH 密钥配置是新手最容易卡住的地方。配置的目的是让本地设备和 Gitee 之间建立一条无需频繁输入密码的安全通道。大致步骤如下本地生成密钥对打开终端执行ssh-keygen -t ed25519 -C 你的邮箱一路回车即可。生成的密钥文件默认在~/.ssh/目录下id_ed25519是私钥id_ed25519.pub是公钥。私钥必须保管好别发给任何人。复制公钥内容执行cat ~/.ssh/id_ed25519.pub把输出的内容完整复制。在 Gitee 中添加公钥登录 Gitee进入“设置” → “安全设置” → “SSH 公钥”把刚刚复制的公钥粘贴进去确认添加。验证连通性终端执行ssh -T gitgitee.com看到欢迎信息就说明配置成功。如果配置过程中出现问题请直接参考后面的故障排查章节。4.3 本地仓库初始化与首次推送在 Obsidian 仓库目录下执行 Git 初始化将整个目录纳入版本管理。这里有两个强制建议第一务必创建一个.gitignore文件把.obsidian/workspace.json工作区状态、临时文件和系统文件排除在版本管理之外第二提交信息要有明确的语义比如用的是notes: 添加 XX 主题的读书笔记而不是update。首次推送到 Gitee 的完整流程如下# 进入 Obsidian 笔记目录 cd /你的笔记目录 # 初始化 git 仓库 git init # 创建并配置 .gitignore echo .obsidian/workspace.json .gitignore echo .DS_Store .gitignore # 添加所有文件并提交 git add . git commit -m init: 初始化知识库 # 关联远程仓库 git remote add origin gitgitee.com:你的用户名/你的仓库名.git # 推送 git push -u origin master注意分支名。Gitee 新建仓库默认分支是master但近年新项目也常使用main。推送前先通过git branch -M master或git branch -M main将本地分支名调整为与仓库一致避免推送失败。4.4 日常同步习惯提交要勤推送要稳仓库建好之后剩下的就是“习惯了”。我的实践是每次做完一批笔记修改后立即执行一次提交每天工作结束时把当天的提交推送一次每周挑一个固定时间做一次仓库整理把已完成的归档文件移动一遍并压缩仓库体积。操作上有几个小技巧值得分享。第一提交可以使用 GitHub Desktop 或 VS Code 的 Git 面板不必每次敲命令行。Obsidian 也有 Git 插件可以做自动提交和推送但我试用下来感觉它有时过于激进手动控制更稳妥。第二恢复误删文件只需要git checkout -- 文件名恢复某个历史版本则需要git log找到对应提交 ID执行git restore --source提交ID 文件名。第三图片等二进制文件不要直接塞进笔记仓库。我的习惯是图片统一放到_assets/目录并定期用工具压缩。本地图片体积太大必然导致仓库克隆变慢、推送卡顿。5. 三件套联动从零散素材到成品笔记的完整实战5.1 实战场景加工一篇网文摘录假设你在浏览器里看到一篇关于“分布式系统设计”的文章读下来有几个关键点很有价值想把它存入知识库。这是知识库最典型的日常输入。第一步直接把链接和摘录内容扔进00_收件箱命名如分布式系统设计的几个关键问题待整理.md。这一阶段不做任何加工纯粹是为了把临时内容落进来。第二步借助 WorkBuddy 对该素材做初步加工。这里建议的做法是先将收件箱中的笔记交给 AI让它完成两项任务提取全文核心观点并生成摘要基于文章内容补充你自己之前写过的相关笔记链接。AI 生成的摘要通常有 80% 的可用度剩下 20% 需要人工校准。人工校准的重点是补充你自己真实的思考而不是让笔记只留下 AI 的转述。第三步把整理好的笔记移动到20_领域/编程/分布式系统.md在笔记的 frontmatter 里更新创建日期、标签保持与知识库模板一致。最后执行 Git 提交和推送。5.2 实战场景用 WorkBuddy 快速创建一篇主题综述再举一个更复杂的场景。某天你需要写一篇关于“AI 辅助测试开发”的综述性笔记但你对这个主题的已有积累只有零星几篇笔记不够系统。这时候如果从零开始去网上搜资料效率很低直接从已有笔记里检索归纳又怕信息不够完善。我的做法是让 WorkBuddy 做一个“主题整合”的任务。给它一个输入主题关键词“AI 测试开发”允许它检索 Obsidian 仓库内所有笔记输出一份知识综述草稿包含该主题下的既有知识点、相关笔记的链接引用、与外部公开资料结合后的扩展建议。AI 会先扫描仓库内相关内容结合自身预训练知识输出一份结构完整的综述。然后我做两件事核查内部链接是否正确、根据自己的实际经验补充几个自己的观点。最后生成的新笔记既包含知识库已有的内聚内容又借 AI 扩展了视野。这个流程的核心价值在于“让 AI 在知识库内做功课然后再做总结”。这和直接在聊天框里让 AI 写文章有本质区别——AI 在知识库内生成的内容是基于你已有的笔记体系不是凭空想象。长期用这种方式做综述你会发现自己笔记的复用率越来越高。5.3 移动端的配合Obsidian 的移动端可以直接访问本地 Git 仓库目录。我用的方法是先通过移动端 Obsidian 打开仓库文件夹指到本地的克隆目录日常在手机上记录灵感记录完后在应用内直接执行 Git 提交和推送需要安装 Mobile Git 相关插件。到电脑端后拉取最新内容做进一步整理。移动端适合做抓捕灵感的快速记录不适合做深度的内容加工。插件体系在移动端受限较多WorkBuddy 这种 AI 工作台目前更适合在桌面端运行。所以我个人不会强制要求在手机上跑完整流程只要实现“随时能记录”和“路上能阅读”就足够了。6. 常见问题排障与踩坑实录6.1 SSH 连接失败问题表现git push报错Permission denied (publickey)。排查步骤依次为用ssh -T gitgitee.com测试连通性确认返回欢迎信息检查本地~/.ssh/目录下密钥文件是否存在确认已添加的公钥内容是否与id_ed25519.pub内容完全一致。最常见的原因是公钥粘贴时多了空格或换行。另外一个隐蔽问题是密钥权限——~/.ssh目录和文件权限过于开放部分系统会拒绝加载私钥需要把私钥权限设为600。6.2 推送时提示“rejectedfailed to push”这个问题通常是因为本地仓库和远程仓库的历史记录不一致引起的。解决办法是先把远程的改动拉下来合并再推送git pull origin master --allow-unrelated-histories git push origin master出现这类问题的典型场景是建仓时勾选了“初始化仓库”导致远程有一个和你本地不相关的初始提交。如果你刚建仓发现这个问题最简单的处理是删掉远端仓库重新创建选择“空仓库”再推一次。6.3 Obsidian 插件不生效Obsidian 的插件不生效最常见的原因是关闭了安全模式或者没有正确启用。早期版本需要在“设置-第三方插件”里关闭安全模式新版则改为开启“受限模式”。另一个更常见的原因是在移动端 Obsidian 上插件安装路径错误。插件应该放在仓库根目录的.obsidian/plugins/文件夹下如果你把插件解压到其他地方Obsidian 扫描不到自然不会加载。6.4 WorkBuddy 读取不到笔记文件WorkBuddy 在处理本地文件时需要授予终端或工具足够的文件系统访问权限。如果你用的是 macOS可能需要在“系统设置-隐私与安全性-完全磁盘访问权限”里把 WorkBuddy 加进去Windows 上则要检查是否以管理员权限运行。另外一个容易忽视的点是路径中包含中文或特殊字符时某些工具解析会出错——可以先把笔记仓库路径改为纯英文降低出问题概率。6.5 历史笔记批量加工时标签错乱这是我踩过最典型的坑之一。第一次用 WorkBuddy 批量给老笔记补标签时AI 生成的一批标签里出现了一些不属于我知识体系的新标签而且这些新标签语义相近比如“分布式系统”和“分布式架构”同时出现后续检索时被切成了两半。修正的过程很繁琐——需要写脚本批量合并标签。6.6 仓库体积膨胀问题用 Git 管理笔记库一段时间后仓库体积会比预期增长得快。打开.git目录看看常常有几个 GB 甚至更大。这通常是因为误把大文件提交进了仓库。解决办法是先停用仓库用git filter-branch或git filter-repo清理历史中的大文件再重新推送。以后注意在.gitignore中排除所有大文件目录图片、PDF 附件等一并忽略。仓库体积控制在 500MB 以下推送和克隆的速度才比较理想。7. 扩展思路这套组合还能怎么玩这套组合的价值不在于三个工具本身而在于它们组合后形成的“可控的 AI 知识工作流”。如果你已经搭好基础可以沿着几个方向继续扩展。第一个方向是“整库知识问答”。当知识库积累到一定体量单条笔记的检索已经无法满足需求。把知识库导出为向量化索引接上大模型的本地推理接口就能实现“对全库提问”。比如问“我在哪几篇笔记里提到过容器化部署的坑”系统会遍历全库给出带原文引用的答复。第二个方向是“自动化管线”。结合定时任务让 WorkBuddy 每隔一段时间自动扫描收件箱中的未处理笔记、执行摘要生成、提交到 Git。这需要配置脚本和简单的工作流编排但对那些笔记量大、输入节奏快的人来说很值得。第三个方向是“知识卡片化”。通过 WorkBuddy 把长笔记拆条为原子化的知识卡片每张卡片只讲一个概念配合 Anki 做间歇重复复习。如果你用知识库的目的是学习新领域这个玩法比单纯记录更能强化记忆。第四个方向是“反向引入”——把 Gitee 的 issue 功能作为灵感收集器。日常在手机或任意设备上通过 Gitee 的 App 给仓库提 issue内容就是一条快速灵感本地用一个脚本把 issue 转为 Markdown 落进收件箱。这个方案解决的是“手机端 Obsidian 操作繁琐”的问题思路是把容易的部分外包给更轻量级工具聚焦在核心的笔记加工上。8. 最后的几点体会这套组合用了一年多最大的感受是“知识库”这个词很容易给人造成误解让人觉得它是一个收纳盒只管把东西放进去就行但其实它应该是一个持续的加工系统。Obsidian、WorkBuddy、Gitee 三个工具分别对应“保存”“加工”“备份”三个动作它们组合到一起才让这个加工系统真正跑了起来。如果要我总结一个最想传递给后来者的经验那就是先定义你自己的“知识加工流程”再选工具不要反过来。大多数人搭知识库失败根因不是工具不好用而是根本不清楚自己的知识输入输出形态。你需要明确的问题很简单——我的知识从哪里来我如何处理它们我用它们做什么把这三个问题回答了工具的选择自然会清晰起来。最后分享一个小技巧定期做“知识库体检”。每个月月底花半小时检查一下收件箱有没有堆积、标签是否混乱、有没有几个月没打开的“僵尸目录”。这一步很朴素但对维持知识库的长期可用性帮助极大。我自己正是靠这个习惯让这套组合在一年后依然能高效运转而不是像很多一开始热闹、三个月后吃灰的项目一样草草收场。