我先把这套组合的使用场景说清楚。日常做技术笔记、项目复盘、知识管理的人多少都会遇到一个尴尬笔记越写越多但要用的时候找不着电脑、手机、公司工作机之间来回传文件版本混乱更不要说让 AI 真正参与处理笔记内容而不是停留在“帮我搜索一下”的问答阶段。我搭这套 Obsidian WorkBuddy Gitee 的组合起因就是为了解决这三个具体问题——本地优先的笔记底座、能读能写知识库的 AI 智能体、以及稳定可控的版本同步链路。它适合两类人一类是已经用 Obsidian 但被同步问题困扰的笔记重度用户另一类是希望 AI 从“聊天窗口”变成“能替我整理资料并产出文档”的实践者。下面把这套组合的选型逻辑、完整搭建步骤、实际操作闭环以及踩过的坑逐项拆开讲。1. 选型逻辑三个工具各自补位构成完整闭环先别急着装软件。我建议你花十分钟想清楚一件事个人知识库真正需要的不是“更多功能”而是三个能力——可靠存储、顺畅同步、自动化处理。Obsidian、WorkBuddy、Gitee 恰好在这三块各自补位组合起来才是完整闭环。1.1 Obsidian 是知识库的“底座”Obsidian 的定位是本地 Markdown 笔记软件但它和普通笔记软件的根本差异在于两点。第一所有内容都是普通.md文件存在你自己电脑的文件夹里不依赖任何服务商这意味着数据永远在你手上换工具、做迁移、写脚本处理都极其方便。第二它支持双链和关系图谱笔记之间可以通过[[笔记名]]相互引用形成真正的关系网络而不是一堆孤立的文档。我把 Obsidian 比作“知识库的底座”主要是因为它的开放文件格式给了后续所有自动化和 AI 处理留了窗口。WorkBuddy 要读你的笔记、改你的笔记、批量生成笔记前提就是笔记文件必须是标准的、可解析的文本格式。如果你用的是某个封闭系统的数据库笔记AI 想插手就非常费劲。这是 Obsidian 不可替代的第一层原因。1.2 WorkBuddy 承担“智能处理层”WorkBuddy 是目前很典型的 AI 智能体工具它和普通聊天 AI 最不一样的地方在于它能访问你指定的本地目录读文件内容、按照你的要求执行多步任务、把结果写回文件。换句话说它不是“回答你的问题”而是“代替你干活”。打个比方传统知识库是一个堆满资料的文件柜你需要自己翻抽屉找资料普通 AI 聊天是你把资料拍照发给助理助理给你口头回复而 WorkBuddy 的工作方式是直接把助理放到你的文件柜前面它自己开抽屉、自己浏览、自己把新资料归位。它能做到这一点依赖的还是底层大模型的能力但更关键的是工具本身提供了文件读写和命令执行的“手和脚”。这就是为什么我坚持用 WorkBuddy 而不只是 Obsidian 自带的 AI 插件。自带插件更多是做检索增强比如“根据我的笔记回答 XX 问题”而 WorkBuddy 可以完成“把 Inbox 里所有未整理的笔记按模板生成结构化文档并放到对应目录”这类涉及多文件、多步骤、有产出的任务。1.3 Gitee 是知识库的“数据管道”有了底座和大脑还缺一条数据管道。Gitee 是国内使用的 Git 托管平台我的知识库同步链路就是靠它实现的。选 Gitee 而不是 GitHub 或国外其他平台主要是因为访问速度和稳定性。这套组合里的 Gitee 承担三个角色一是版本安全网每一次提交都是笔记库的一个快照改坏了、删错了都能回滚二是多设备同步的中间站家里电脑、办公室电脑都可以通过git push / pull与远端仓库同步三是目录结构的云端备份换电脑时不用靠移动硬盘导数据。有人可能会问为什么不直接用 iCloud、OneDrive 这类网盘同步答案很直接网盘同步对 Markdown 文件偶尔也会出现冲突副本、文件锁和同步延迟问题而且没有版本概念。Git 的语义天生适合文本文件每次改动产生一次干净的提交记录冲突解决也比网盘文件覆盖要可控得多。我的实测结论是笔记这种高频小文本变更的场景Git 同步的稳定性和可追溯性都比普通网盘好。1.4 和主流替代方案做个对比给还在纠结选型的人一张清晰对比表方案数据格式AI 介入能力同步方式版本回溯我的评价Obsidian Gitee WorkBuddy纯 Markdown开放强可读写文件Git 同步完整提交历史适合深度用户可玩性高Notion封闭数据库中等受 API 限制官方云同步历史记录有限协作方便但数据不在本地语雀 / 印象笔记封闭格式弱官方同步一般开箱即用但难自动化纯 Obsidian 网盘Markdown弱网盘基本没有适合轻量用户核心结论是这套组合的价值并不在于某个工具多强大而在于三个工具的接口是开放的。Markdown 是开放格式、Git 是开放协议、WorkBuddy 支持本地目录读写三层一打通整个知识库就变成了一个可以编程、可以自动化的系统。2. 本地库搭建Obsidian 的目录结构与核心设置选型确定后第一步是把本地知识库的结构搭好。这一步很容易被忽略但后续 AI 能不能高效地从知识库里提取信息完全取决于目录结构和命名规则是否清晰。如果你让 AI 面对一个所有文件都堆在根目录、命名乱七八糟的笔记库它会和你一样头疼。2.1 目录结构设计让 AI 一看就懂我采用的是 PARA 方法的一个变体因为这套结构逻辑简单、边界清晰非常适合 AI 按路径定位文件。我的知识库根目录长这样KnowledgeBase/ ├── 00_Inbox/ # 临时收集箱一切碎片记录先扔这里 ├── 01_Projects/ # 正在进行的项目和任务 ├── 02_Areas/ # 需要长期维护的领域比如健康、理财、职业 ├── 03_Resources/ # 主题资料库按主题分子目录 │ ├── Network/ # 例如网络协议 │ ├── AI/ # 例如AI 工具与应用 │ └── WorkFlow/ # 例如效率方法论 ├── 04_Archive/ # 归档已结束项目、过期资料 ├── 90_Assets/ # 附件图片、PDF、其他文件 ├── 99_Templates/ # 模板笔记模板、日记模板 └── README.md # 知识库总说明给 AI 看的“地图”这套结构的好处有三个。第一数字前缀让目录排序固定收集箱永远在最上面归档永远在最下面AI 按路径读取时不会迷失。第二00_Inbox 是 AI 处理的起点所有未整理的碎片笔记统一放这里AI 每次只需要扫描这一个目录就能获得“待办清单”。第三90_Assets 独立出来避免图片和附件混进正文目录既让正文目录干净也方便在 Git 里做忽略处理。2.2 Obsidian 核心设置调整我的建议是打开 Obsidian 后先关掉一些默认行为再手动设置几个关键项新建笔记默认位置改为00_Inbox这一步会让所有临时记录自动进入收集箱避免笔记散落各处。附件默认存放路径改成90_Assets避免图片和 PDF 直接躺在笔记目录里污染文件列表。新建笔记格式用完整链接也就是[[笔记名]]这种 Markdown 标准格式方便 WorkBuddy 后续识别和补充双链。日期格式统一成YYYY-MM-DD比如2025-06-10这个格式对 Git 提交记录和 AI 排序都很友好。如果团队里有人协作可以考虑关闭 Obsidian 的实时预览中的某些插件级格式修正因为这些自动改动会导致 Git diff 里出现大量无意义的格式变化。这些设置里我最想强调“新笔记默认进 Inbox”这一条。大多数人用 Obsidian 记笔记失败的根源就是没有收集箱随手新建的笔记零散放在各处时间一长根本不知道去哪找。有了固定收集箱整个知识库的入口就统一了AI介入处理时也有了一个明确的“上游”。2.3 必装插件清单我把自己的插件列表精简到五个核心项尽量避免装太多导致配置复杂、更新冲突插件用途备注Dataview用类 SQL 语法查询笔记元数据动态生成索引页时非常好用Templater预置笔记模板配合 99_Templates 使用Obsidian Git自动完成 Git commit 和 push同步链路的核心插件下一章细讲QuickAdd快速捕获内容到指定目录一键把想法扔进 00_InboxCalendar日历视图日记流必备按日期查看记录其中 Dataview 值得多说一句。它可以在笔记里写查询语句把散落在各处的笔记按标签、路径、创建时间聚合到一个页面。比如我可以写一行 Dataview 查询把03_Resources/AI目录下所有带“工具推荐”标签的笔记自动列成一张表格。这个能力在 WorkBuddy 生成目录索引时特别有用AI 写回文件后Dataview 会自动渲染出最新列表。3. 同步链路Gitee 仓库配置与 Obsidian Git 联动知识库本地搭好后紧接着就是同步链路。这是最容易出问题的一环也是整套组合稳定运行的关键。我在这里把从零到一的完整过程写清楚包含仓库创建、本地 Git 初始化、Obsidian Git 插件配置以及冲突处理。3.1 在 Gitee 创建私有仓库的注意项登录 Gitee 后右上角“新建仓库”。需要注意几个关键选项仓库名称建议和本地文件夹同名比如KnowledgeBase后续从远端克隆时目录名就自动对应上了。可见性选择“私有”。个人知识库里面可能有隐私信息、项目细节不要因为图方便建公开仓库。初始化仓库时不要勾选“使用 Readme 初始化”。如果你本地已经有内容勾选后会导致本地仓库和远端仓库的历史不一致首次 push 大概率被拒绝。开源许可证不要选。私人笔记仓库不需要 License选了反而会让 Git 自动生成一个 LICENSE 文件增加无意义的首次 diff。这节课很多人会忽略。我第一次搭的时候图省事勾了 README 初始化结果本地仓库和远端仓库像两个平行世界只能用git pull --rebase强行合并提交历史乱七八糟。所以建议直接把这一步回避掉。3.2 本地 Git 初始化与凭证配置本地进入KnowledgeBase目录依次执行git init git add -A git commit -m init: 初始化知识库 git remote add origin gitgitee.com:你的用户名/KnowledgeBase.git git push -u origin master这里最容易卡住的是 SSH 密钥。我建议在推送前先配置 Git 的 SSH 密钥否则每次都要输入密码体验很差。生成方式ssh-keygen -t ed25519 -C 你的邮箱 cat ~/.ssh/id_ed25519.pub把公钥复制到 Gitee 的“个人设置 - SSH 公钥”里然后测试连接ssh -T gitgitee.com如果返回成功提示说明 SSH 通路已经打通。这一步做完之后才是git remote add origin那一条命令我好几次遇到 push 失败都是因为跳过了 ssh 测试、URL 写错或者密钥没生效。3.3 Obsidian Git 插件的设置要点Obsidian Git 插件是同步链路的核心。安装插件后进入设置页面重点配置这些项自动保存时间5 分钟。这个值不能太频繁否则每次敲字都会触发 commitCPU 占用会很高。自动拉取间隔10 分钟。也就是说每 10 分钟从 Gitee 拉取一次远端变更适合多设备场景。自动推送间隔15 分钟。推一次拉一次时间错开避免插件同时在做两件事导致冲突。在关闭 Obsidian 前执行 commit 和 push建议打开保证当天所有改动都在最后一刻提交入库。版本历史保留最近 30 个提交避免仓库体积迅速膨胀。额外提醒一点如果你在手机上也装了 Obsidian不要直接让手机端参与自动 push。手机上很多文件和配置路径与电脑不同自动同步容易生成大量冲突提交。我的做法是手机上只做阅读和快速记录修改统一回到电脑端整理提交。3.4 多端修改冲突怎么处理即使自动同步做得很顺多设备同时使用时偶尔仍会遇到代码冲突。Git 冲突的表现是文件里出现这种标记 HEAD 这是电脑端修改的内容 这是手机端修改的内容 6139254解决方式不复杂打开冲突文件保留正确的那部分内容删掉、、这三行标记然后执行git add和git commit即可。关键在于避免冲突养成“电脑端为主、其他设备只读”的使用习惯比任何插件配置都有效。4. 智能接入把 WorkBuddy 指向知识库同步问题解决后整个链路的“底座”和“管道”都完成了接下来是最有意思的部分——把 WorkBuddy 接进来让 AI 真正参与知识库的读写。这一步做得好的话你的知识库就从“静态资料库”变成了“自动运转的生产线”。4.1 WorkBuddy 的工作模式与权限边界WorkBuddy 这类智能体工具核心能力是访问本地文件系统、执行终端命令、调用大模型推理。在使用它之前你必须明确给它划定工作目录。我的建议是只把KnowledgeBase这一个目录授权给它不要给它整个用户目录或磁盘根目录权限。原因特别简单给的工作目录越小AI 出错的影响范围就越小。它可能在整理笔记时批量重命名文件如果权限边界失控误操作会波及到工作区外的其他项目文件。我实际操作时会把 WorkBuddy 的会话工作目录设置为KnowledgeBase并在项目说明文件里写清楚“你只能操作此目录下的 .md 文件禁止修改 .obsidian 配置和 .git 目录”。这个“边界说明”不是形式主义。AI 在自由执行任务时经常会有“顺手改点别的”的倾向明确约束能大幅降低风险。即使你已经授权了指定目录也强烈建议在知识库根目录放一个说明文件让 AI 每次开始任务前先读一遍。4.2 让 AI 理解知识库规则的三种方式想让 WorkBuddy 高质量地处理知识库内容光给它目录还不够还要让它“懂事”。我用三种方式叠加第一在知识库根目录放一个README.md里面写清楚目录结构的意义、笔记命名规范、标签规范。AI 每次进入工作目录时先读这个文件就等于拿到了一张地图。第二写一份专门的知识库守则.md列出处理规则。比如“所有新笔记必须先落到 00_Inbox”“整理后的笔记必须保留原始来源链接”“双链引用统一使用 [[笔记名]] 完整格式”。这些规则直接决定 AI 产出的文件质量。第三把常见任务做成固定提示词模板。与其每次随口说不如把“整理 Inbox”“生成主题索引”“生成周报”这几类高频任务的提示词固定下来存到99_Templates/AI-Prompts目录。这样每次调用时只需要替换变量比如指定某个 Inbox 文件的名称。4.3 一个亲测好用的 Inbox 清空流程我使用频率最高的自动化流程是“清空收集箱”。具体操作是直接在 WorkBuddy 对话框里输入一段指令让它扫描00_Inbox下所有未整理的.md文件逐个完成以下工作读取内容提炼核心要点根据内容主题自动判断应该归类到03_Resources下的哪个子目录按我指定的模板生成结构化笔记在正文末尾补充双链关联已有相关笔记将原始碎片笔记移动到04_Archive。这个流程在纯人工操作时可能需要半小时我用 WorkBuddy 之后通常五分钟内完成。AI 的处理质量取决于模板的约束程度所以模板里我会强制写清楚几个字段来源、核心结论、相关笔记、下一步行动。4.4 示例提示词可以直接照抄给你一个可以直接用的模板请整理 00_Inbox 目录下的所有 .md 文件按以下步骤处理 1. 先阅读根目录 README.md理解目录结构 2. 逐个读取 Inbox 中的文件提取核心信息 3. 根据内容主题归类到 03_Resources 下合适子目录 4. 使用 99_Templates/note-template.md 的格式生成新笔记 5. 生成的新笔记必须带上 [来源]、[核心观点]、[相关笔记] 字段 6. 在“相关笔记”字段中检索知识库已有笔记并填入 [[链接]] 7. 原碎片文件移动到 04_Archive 目录 8. 全部完成后列出你处理了哪些文件、放到了哪个目录。实际跑下来这类任务的成功率很高偶尔会出现分类不准的情况尤其是同时涉及多个主题的内容。我的处理方式是分类不准就手动拖一下文件反正 Git 会记录下每一次变更调整成本极低。千万不要因为 AI 偶尔出错就放弃整个流程它的价值在于处理 80% 的确定性工作剩下 20% 的判断留给人。5. 实战闭环从随手记录到可交付内容前面铺垫了那么多这一章我完整演示一个真实的处理流程让你直观感受这套组合是如何把一条随手记录变成一篇结构完整、可直接发布的内容。5.1 一个具体案例从一条碎片记录开始假设某天我在排查一个后端接口鉴权问题当时随手在 Obsidian 的00_Inbox里新建了一条笔记内容只有几个关键词“JWT 过期时间 8h前端刷新后仍提示 401需要看后端中间件逻辑可能和服务器时区有关”。这条记录非常碎片化如果不处理三个月后会完全变成无法理解的乱码。现在我把 WorkBuddy 的工作目录指向知识库让它整理这条笔记。5.2 WorkBuddy 实际执行的三步WorkBuddy 会分三步处理这条碎片记录。第一步总结和补全。它把“JWT 过期时间 8h”扩展成“前端登录后获得的 JWT 有效期设置为 8 小时但在刷新页面后仍收到 401 未授权响应”把“服务器时区”扩展成“服务器操作系统时区与 JWT 签发/校验逻辑可能不一致导致过期时间判断与实际相差若干小时”。这一步解决的是“让记录具备可读性”。第二步关联已有笔记。它会扫描知识库中03_Resources下有没有和 JWT、后端鉴权相关的笔记如果发现有一篇“后端接口鉴权方案”的旧笔记就自动在新笔记里补上[[后端接口鉴权方案]]这条双链同时也在旧笔记里追加一条反向引用。这一步解决的是“让知识成为网络”。第三步生成可发布的文档。它按我的输出模板把这条笔记整理成包含“问题现象”“可能原因”“排查步骤”“临时规避方案”“后续优化建议”五个部分的完整文档并放到03_Resources/WorkFlow/下。这一步解决的是“从归档备查到可产出”的跨越。5.3 人工审查和版本回滚AI 生成内容之后我绝不会直接信任而是做一次快速人工校对。重点看三件事技术细节是否准确、归类是否合理、双链是否真的有价值。我遇到过 AI 把“JWT”错误解释成“JSON Web Token 的缩写是 Java Web Token”的情况这就是典型的知识性错误没有审查直接发布的话会误导读者。好在整套系统有 Git 层面的兜底。如果 AI 批量修改出现严重问题我可以直接执行git log --oneline git revert commit哈希整个知识库瞬间回到修改前的状态。这也是我强烈推荐把 Gitee 纳入组合的核心理由——AI 参与的自动化流程必须有版本管理作为安全网否则你不敢放心让它批量动手。6. 踩坑记录与实际避坑建议这部分是我实操了大半年后总结出来的问题清单每个都对应了具体的解决方式。如果你能提前避开可以省下非常多调试时间。6.1 推送被拒几乎都是这三个原因第一次用 Gitee 做同步时最容易遇到的报错是failed to push some refs原因逃不出三个第一本地仓库和远端仓库历史不一致。解决办法是首次推送前不要勾选远程初始化。已经出错的执行git pull --rebase origin master再重新推送。第二SSH 密钥没生效。检查方法是ssh -T gitgitee.com确认输出里能看到你的用户名。如果提示Permission denied重新添加公钥并检查公钥文件路径是不是~/.ssh/id_ed25519.pub。第三分支名不一致。Gitee 新仓库默认分支可能叫master也可能存在main你的本地分支是什么名字要确认清楚。查看和修改分支名的命令git branch -m master main git push -u origin main6.2 仓库体积膨胀图片和附件必须隔离笔记本身全是文本体积很小但图片、PDF、压缩包会迅速拖垮仓库。Gitee 对单文件大小有限制而且仓库整体涨到几百 MB 后克隆和推送都会变得很慢。我的解决方案是做两层隔离。第一层是.gitignore文件打开90_Assets目录下的临时文件忽略比如*.tmp、.DS_Store还有 Obsidian 的工作区缓存.obsidian/workspace.json。第二层限制图片入库所有图片统一放 90_Assets能不压进 Git 的尽量用图床或对象存储。如果一定要本地存图建议定期手动清理无引用素材。6.3 WorkBuddy 上下文越界任务范围要收紧大模型的上下文窗口有限如果你让它扫描整个知识库再整理某一条笔记它很可能读不完所有文件或者在前半段就“忘记”了任务要求。我的经验是每次任务只限定一个子目录不要同时处理全部。比如不要下“整理 00_Inbox 里所有文件并更新整个 03_Resources 的索引”而应该下“只处理 00_Inbox 里的 2025-06-10.md并更新 03_Resources/AI 目录下的索引”。范围越小输出质量越高。这个规律在 AI 工具上屡试不爽。6.4 同步间隔设置不当导致卡顿Obsidian Git 的自动提交间隔设得太短比如 60 秒每次敲字都会触发 Git 操作CPU 占用飙升笔记体验非常卡。建议时间间隔按“提交 5 分钟、拉取 10 分钟、推送 15 分钟”配置并且在 Obsidian 关闭时执行一次最终提交。如果嫌自动推送不够及时也可以把 Obsidian Git 的自动推送关掉全部手动提交。我自己的习惯是白天高频记录用自动提交兜底晚上收尾时手动推一次兼顾即时性和 CPU 占用。整套组合走到这里最核心的链路已经完整Obsidian 负责本地写作和内容组织Git 通过 Gitee 完成版本同步和安全兜底WorkBuddy 负责脏活累活——整理、归类、关联、产出。我在实际使用大半年后的体会是这套方案最大的价值不是“省了几分钟”而是让我对知识库的处理方式发生了变化以前我因为整理成本太高而不愿意记录碎片现在我知道只要丢进 00_Inbox后面会有人自动处理所以我更愿意记、记得更多知识沉淀的“上游”变大了后续能产的料自然就多了。如果你也打算照这个方案搭我的建议是别急着一步到位先把 Obsidian 目录结构搭好、让 Gitee 同步跑顺再逐步把 WorkBuddy 接进来一次只加一个自动化流程跑稳定两周后再加下一个。知识库的建设本来就是长期工程工具组合只是让这条路走得更轻松一点。