1. 为什么我要折腾这套组合拳1.1 从笔记坟场说起我用了差不多五年的笔记软件从最早的印象笔记到后来的语雀、飞书文档再到Notion几乎每一款都深度用过至少半年。但说实话大部分人的笔记最后都变成了坟场——记的时候很爽找的时候找不到用的时候想不起来。我自己也不例外最多的时候有三千多条笔记散落在四五个平台里真正能被我二次调用的可能不到百分之五。这个问题的本质不是记不记而是知识有没有被激活。传统笔记软件的问题在于它们是存储导向的你写进去的东西就是死的除非你主动去翻。而AI时代最大的机会就是让知识库从静态仓库变成动态助手——你问它它能答你写东西它能补你整理它能帮你归类。我最终选定的方案是Obsidian WorkBuddy Gitee这个三联组合。Obsidian负责本地知识库的存储和双链管理WorkBuddy负责AI能力的接入和自动化处理Gitee负责版本管理和多端同步。三个工具各司其职组合起来就是一个完全属于自己、不依赖任何平台、还能被AI驱动的个人知识库。1.2 这套组合到底解决了什么问题先说清楚这套方案适合谁。如果你是以下几类人这套组合会非常合适笔记量大但利用率低的人有几百上千条笔记但基本不回看需要AI帮你激活对数据隐私有要求的人不想把笔记放在别人的服务器上希望本地存储多设备用户办公室电脑、家里台式机、笔记本、手机都要能访问喜欢折腾的技术人愿意花一两个小时配置换来长期的生产力提升它解决的核心问题有三个。第一是数据主权所有笔记以Markdown纯文本存在本地就算哪天Obsidian倒闭了你的笔记照样能用任何编辑器打开。第二是AI激活通过WorkBuddy把大模型能力接进来让知识库能问答、能总结、能自动打标签。第三是版本可控用Gitee做Git仓库每次改动都有记录误删了能回滚多设备冲突能合并。我实测下来这套方案配置一次大概需要一到两个小时之后基本就是无感使用——你只管写同步和AI处理都在后台自动完成。1.3 三个工具的分工逻辑很多人会问为什么不用Notion AI或者飞书知识库这种一体化方案原因很简单一体化方案意味着你把所有鸡蛋放在一个篮子里平台改政策、涨价、甚至关停你都无能为力。而且一体化方案的AI能力往往是通用型的没法针对你的个人知识做深度定制。三联组合的分工是这样的工具角色核心职责替代方案Obsidian知识库主体本地存储、双链、标签、插件生态Logseq、思源笔记WorkBuddyAI 引擎大模型接入、自动化工作流、批量处理Dify、FastGPTGitee版本仓库Git 托管、多端同步、历史回溯GitHub、GitLabObsidian的强项是本地优先插件生态它的双链和标签系统是目前笔记软件里最灵活的。WorkBuddy的强项是工作流编排你可以把读取笔记→调用大模型→写回笔记这一整套流程做成自动化。Gitee的强项是国内访问稳定免费私有仓库对于不想折腾网络环境的用户来说是最省心的选择。提示这三个工具都是可以独立使用的组合起来是1113的效果。如果你只想先试试水建议从Obsidian开始用顺了再加AI和同步。2. 环境准备与工具选型细节2.1 Obsidian 的安装与初始配置Obsidian的下载很直接官网就能拿到各平台安装包。Windows用户建议下载exe安装版而不是便携版因为安装版会自动注册系统级的文件关联双击md文件就能直接打开。Mac用户注意区分Intel和Apple Silicon版本M系列芯片一定要下arm64版本否则会通过Rosetta转译运行插件加载速度会明显变慢。安装完成后第一件事是创建仓库Vault。这里有个关键决策仓库放在哪里我的建议是放在一个路径中不含中文和空格的目录下比如D:\KnowledgeBase或者~/Documents/kb。原因后面讲Gitee同步的时候会说到Git对中文路径的处理在某些场景下会出问题提前避开能省很多麻烦。初始配置我建议做这几件事关闭安全模式设置→第三方插件→关闭安全模式这样才能装社区插件开启核心插件把标签面板大纲反向链接日记这几个核心插件打开设置附件目录设置→文件与链接→附件默认位置改成在指定文件夹中路径填attachments这样图片和附件不会和笔记混在一起开启Wiki链接设置→文件与链接→使用Wiki链接打开后[[笔记名]]这种写法才能生效关于主题热词里提到的Anuppuccin确实是个很漂亮的主题但安装失败通常是因为网络问题或者Obsidian版本不匹配。我的建议是先用默认主题把功能跑通主题这种东西属于锦上添花不影响核心使用。2.2 WorkBuddy 的部署方式选择WorkBuddy的部署有两种方式本地部署和云端部署。本地部署适合对数据隐私要求极高的用户所有AI调用都在自己机器上完成但需要一定的硬件配置至少16G内存最好有独立显卡。云端部署则更省事配置简单但需要把笔记内容发送到云端处理。我个人的选择是混合模式敏感笔记用本地模型处理普通笔记用云端API。WorkBuddy支持配置多个模型源你可以在工作流里根据笔记的标签或者目录来决定用哪个模型。安装WorkBuddy的时候有几个坑要注意缓存目录默认缓存目录在C盘如果你的C盘空间紧张一定要在设置里改成其他盘。我见过有人因为缓存把C盘塞满导致系统卡死的。端口占用WorkBuddy默认占用几个端口如果和你机器上其他服务冲突需要在配置文件里改。常见的冲突是3000端口很多前端开发工具默认用这个。国际版和国内版如果你主要用国内的模型API装国内版就行如果需要调用一些国外的模型国际版的兼容性更好。两个版本可以共存但要注意端口不要冲突。2.3 Gitee 仓库的创建与密钥配置Gitee的注册很简单重点说仓库创建和密钥配置。创建仓库的时候一定要选私有仓库。知识库这种东西包含大量个人信息公开仓库等于把自己的笔记摊开给所有人看。Gitee的私有仓库对个人用户是免费的容量也够用。仓库创建后关键是配置SSH密钥。很多人图省事用HTTPS方式每次push都要输密码非常烦。SSH密钥配置一次之后就是无感的。配置步骤# 1. 生成密钥对如果已有可以跳过 ssh-keygen -t ed25519 -C your_emailexample.com # 2. 查看公钥内容 cat ~/.ssh/id_ed25519.pub # 3. 复制输出的内容粘贴到 Gitee 的 SSH 公钥设置页面Windows用户注意密钥文件在C:\Users\你的用户名\.ssh\目录下。如果这个目录不存在说明你还没生成过密钥需要先执行上面的生成命令。配置完成后测试连接ssh -T gitgitee.com看到欢迎信息就说明配置成功了。如果提示权限拒绝检查一下公钥有没有正确粘贴以及Gitee账户有没有绑定邮箱。注意SSH密钥是绑定设备的如果你在多台电脑上使用每台电脑都需要生成自己的密钥并添加到Gitee。不要图省事把同一份密钥复制到多台机器这样一旦某台机器泄露所有设备都不安全。3. 核心架构设计与数据流拆解3.1 整体数据流向这套系统的数据流可以概括为本地写入→AI处理→Git同步三个环节。理解这个流向很重要因为它决定了你遇到问题时该从哪里排查。写入环节你在Obsidian里写笔记笔记以md文件形式存在本地仓库目录。这个环节完全离线不依赖任何网络。处理环节WorkBuddy监听仓库目录的变化当检测到新笔记或者笔记修改时触发预设的工作流。工作流可能包括自动打标签、生成摘要、提取关键概念、建立双链建议等。处理结果写回笔记的frontmatter或者追加到笔记末尾。同步环节Gitee作为远程仓库通过Git的push/pull实现多端同步。你可以设置定时自动同步也可以手动触发。同步的内容包括笔记本身和Obsidian的配置文件插件配置、主题设置等。这个架构的关键设计点是处理环节和同步环节解耦。也就是说AI处理失败不影响同步同步失败也不影响AI处理。这样任何一个环节出问题都不会导致整个系统瘫痪。3.2 目录结构设计目录结构是知识库的骨架设计得好后期维护成本极低设计得差笔记一多就乱成一锅粥。我踩过几次坑之后总结出这套结构KnowledgeBase/ ├── 00-Inbox/ # 收集箱所有新笔记先放这里 ├── 10-Notes/ # 永久笔记经过整理的知识 ├── 20-Projects/ # 项目相关笔记 ├── 30-Areas/ # 领域知识长期维护 ├── 40-Archive/ # 归档不再活跃的笔记 ├── 90-Templates/ # 模板文件 ├── 99-Attachments/ # 附件图片、PDF等 └── .obsidian/ # Obsidian 配置目录这个结构借鉴了PARA方法Projects、Areas、Resources、Archives但做了简化。数字前缀是为了让文件夹在文件管理器里按顺序排列视觉上更清晰。Inbox机制是这套结构的关键。你写任何新笔记第一站都是Inbox不要纠结放哪里。等周末整理的时候再决定这条笔记是变成永久笔记、归入某个项目、还是直接删掉。这个机制能极大降低记录时的心理负担让你更愿意写。3.3 AI 处理工作流的设计原则WorkBuddy的工作流设计有几个原则我按重要性排序原则一AI只做建议不做决策。比如自动打标签AI给出建议标签但最终是否采纳由你决定。我见过有人让AI全自动整理笔记结果标签体系越来越乱最后完全没法用。原则二处理结果可追溯。AI对笔记做的任何修改都要在笔记里留下记录比如在frontmatter里加一个ai_processed: 2024-01-15字段。这样你回看笔记时知道哪些内容是AI加的哪些是自己写的。原则三批量处理要限流。如果你有几千条笔记不要让AI一次性全部处理那样既费钱又容易出错。建议按目录分批处理每次处理50-100条处理完检查一下效果再继续。原则四保留原始版本。AI处理前先让Gitee做一次commit这样如果AI处理结果不理想可以随时回滚。3.4 多端同步的冲突处理策略多端同步是这套系统里最容易出问题的环节。核心矛盾是你在A设备改了笔记还没同步又在B设备改了同一条笔记两边一同步就冲突了。我的策略是**单写多读**同一时间只在一台设备上写笔记其他设备只读。具体做法是主力写作设备比如办公室电脑开启自动同步其他设备手机、平板只做查看需要编辑时先手动pull一次。如果确实需要多设备同时写那就要接受偶尔的冲突。Git处理冲突的方式是生成冲突标记你需要手动解决。Obsidian本身没有内置的冲突解决界面所以冲突多了会很烦。我的建议是配合Obsidian Git插件设置成启动时自动pull关闭时自动push能减少大部分冲突。场景推荐策略冲突概率单设备主力写作自动同步极低双设备交替使用启动pull关闭push低多设备同时编辑手动同步冲突解决中高团队协作不建议用这套方案高4. 实操过程与关键环节实现4.1 Obsidian 仓库初始化实操假设你已经装好了Obsidian现在从零开始建仓库。第一步打开Obsidian点击创建新仓库仓库名称填KnowledgeBase位置选D:\KnowledgeBaseWindows或~/KnowledgeBaseMac/Linux。创建完成后Obsidian会自动生成.obsidian配置目录。第二步按3.2节的目录结构创建文件夹。你可以手动创建也可以在Obsidian里用命令面板CtrlP输入新建文件夹逐个创建。我建议手动在文件管理器里创建更快。第三步安装必备插件。打开设置→第三方插件→浏览搜索并安装以下插件Obsidian GitGit同步的核心插件Dataview用类SQL语法查询笔记做知识库仪表盘Templater高级模板功能比核心模板插件强很多Tag Wrangler标签管理批量重命名标签Advanced Tables表格编辑增强安装完插件后每个插件都需要在设置里单独配置。Obsidian Git的配置后面会详细讲其他插件用默认配置就能跑。第四步创建模板文件。在90-Templates目录下创建note-template.md内容如下--- created: {{date:YYYY-MM-DD}} tags: [] status: inbox ai_processed: --- # {{title}} ## 核心内容 ## 相关链接这个模板会在你新建笔记时自动填充日期和标题status: inbox标记这条笔记还在收集箱里ai_processed留空表示还没被AI处理过。4.2 Gitee 仓库关联与首次推送仓库初始化完成后接下来把它和Gitee关联起来。第一步在Gitee上创建私有仓库仓库名建议和本地一致叫KnowledgeBase。创建时不要勾选使用Readme初始化仓库因为我们要推送本地已有的内容远程仓库如果有初始文件会导致冲突。第二步在本地仓库目录打开终端Windows用Git BashMac用Terminal执行cd /d/KnowledgeBase # Windows # 或 cd ~/KnowledgeBase # Mac/Linux git init git add . git commit -m 初始化知识库 git remote add origin gitgitee.com:你的用户名/KnowledgeBase.git git push -u origin master如果Gitee默认分支是main而不是master把最后一行改成git push -u origin main。第三步配置Obsidian Git插件。打开插件设置关键配置项Auto backup开启间隔设为10分钟Auto backup after file change开启Auto pull on boot开启Pull before push开启Commit messagevault backup: {{date}}这样配置后Obsidian每10分钟自动commit一次启动时自动pull关闭时自动push。日常使用基本不用管Git。注意首次push可能会因为仓库里有大文件比如附件目录里的图片而失败。Gitee对单文件大小有限制超过100M的文件会被拒绝。如果你的附件目录很大建议在.gitignore里排除掉或者用Git LFS。4.3 WorkBuddy 工作流配置详解WorkBuddy的核心是工作流Workflow一个工作流由多个节点组成节点之间用连线表示数据流向。我配置了三个核心工作流分别对应不同的使用场景。工作流一新笔记自动处理触发条件Inbox目录下有新文件创建。节点流程文件监听节点监听00-Inbox目录读取文件节点读取新笔记的完整内容大模型节点调用大模型提示词如下你是一个知识管理助手。请阅读以下笔记内容完成三件事 1. 生成一句话摘要不超过50字 2. 建议3-5个标签用英文小写连字符分隔 3. 提取笔记中提到的关键概念如果有的话 笔记内容 {{content}} 请以JSON格式输出字段为summary, tags, concepts解析JSON节点解析大模型返回的结果更新frontmatter节点把摘要、标签、概念写回笔记的frontmatter这个工作流跑通后你写完笔记保存几秒钟后frontmatter里就会自动出现摘要和标签。工作流二知识库问答触发条件手动触发在WorkBuddy界面输入问题。节点流程输入节点接收用户问题向量检索节点在知识库中检索相关笔记需要先建立向量索引大模型节点把检索到的笔记作为上下文让大模型回答问题输出节点返回答案这个工作流的关键是向量检索。WorkBuddy支持多种向量数据库我推荐用本地的ChromaDB配置简单不需要额外部署服务。建立索引的时候建议按目录分批建立不要一次性索引整个仓库。工作流三定期知识整理触发条件定时触发每周日晚上。节点流程查询节点查询所有status: inbox的笔记大模型节点让大模型分析这些笔记给出归类建议输出节点生成一份整理报告保存到00-Inbox/整理报告-{{date}}.md这个工作流帮你做周回顾把收集箱里的笔记过一遍决定哪些该归档、哪些该删除、哪些该进一步加工。4.4 向量索引的建立与更新向量索引是AI问答的基础。没有索引大模型只能靠猜来回答你的问题有了索引大模型能基于你的实际笔记内容来回答。建立索引的步骤第一步在WorkBuddy里配置向量数据库。选择ChromaDB数据目录设为D:\KnowledgeBase\.vectorstore注意这个目录要加到.gitignore里不要同步到Gitee。第二步配置嵌入模型。嵌入模型负责把文本转成向量我推荐用bge-small-zh这个模型体积小、速度快、中文效果好。如果你有GPU可以用bge-large-zh效果更好但更吃资源。第三步执行索引建立。在WorkBuddy里选择建立索引选择要索引的目录建议先索引10-Notes和30-Areas点击开始。索引过程会遍历目录下所有md文件分块、向量化、存入数据库。索引建立的时间取决于笔记数量和硬件配置。我实测下来1000条笔记用CPU大概需要10-15分钟用GPU大概2-3分钟。第四步配置增量更新。索引不需要每次全量重建WorkBuddy支持增量更新。配置一个定时任务每天凌晨跑一次只索引新增和修改过的笔记。提示向量索引的质量很大程度上取决于分块策略。默认的分块是按固定字数切分但更好的做法是按语义切分——比如按标题层级切分每个二级标题下的内容作为一个块。WorkBuddy支持自定义分块规则建议花点时间调一下。5. 常见问题与排查技巧实录5.1 同步类问题排查问题一push被拒绝提示non-fast-forward这是最常见的问题原因是远程仓库有你本地没有的提交。解决方法git pull --rebase origin master git push origin master--rebase参数的作用是把你的本地提交挪到远程提交之后避免产生合并提交。如果pull的时候有冲突需要手动解决冲突后再继续。问题二Obsidian Git插件不自动同步排查顺序检查插件是否启用设置→第三方插件→已安装插件检查自动备份间隔是否设置默认可能是关闭的检查是否有未解决的冲突打开终端执行git status检查SSH密钥是否有效执行ssh -T gitgitee.com我遇到过一次插件不工作的情况最后发现是仓库路径里有中文Git命令执行失败。改成纯英文路径后就正常了。问题三多设备同步后笔记内容错乱这通常是冲突没有正确解决导致的。Git在冲突时会生成这样的标记 HEAD 你本地的内容 远程的内容 origin/master你需要手动编辑文件决定保留哪部分然后删除这些标记再commit。如果冲突文件很多建议用VS Code打开仓库目录它的Git集成界面能可视化解决冲突。5.2 AI 处理类问题排查问题一大模型返回格式不对JSON解析失败大模型有时候会自由发挥返回的JSON格式不标准。解决方法是在提示词里加一句只输出JSON不要有任何其他文字并且在WorkBuddy的解析节点里开启容错模式能自动修正常见的JSON格式错误。问题二AI处理速度慢影响因素有三个模型选择、笔记长度、并发数。如果用的是云端API换一个更快的模型比如从GPT-4换成GPT-3.5如果笔记很长先做摘要再处理如果并发数设置太高降低一点避免触发API限流。问题三AI打的标签不符合预期这是提示词的问题。我一开始的提示词只说建议标签结果AI给了一堆很泛的标签比如知识学习。后来改成建议3-5个具体、有区分度的标签避免使用过于宽泛的词汇效果就好多了。提示词工程是个迭代的过程需要根据实际效果不断调整。5.3 性能与存储类问题问题一Obsidian打开慢原因通常是插件太多或者笔记太多。解决方法禁用不常用的插件关闭显示反向链接等实时计算功能如果笔记超过5000条考虑拆分仓库问题二Gitee仓库容量不够Gitee免费私有仓库有容量限制如果附件太多容易超。解决方法在.gitignore里排除附件目录用图床替代本地图片比如PicGoSM.MS定期清理历史提交用git gc或者重建仓库问题三向量索引占用空间大向量索引的大小和笔记数量成正比。如果空间紧张可以只索引核心目录不索引Inbox和Archive用更小的嵌入模型定期重建索引删除过期数据5.4 常见问题速查表问题现象可能原因排查方法解决方案push 被拒绝远程有新提交git statusgit pull --rebase后 push插件不工作路径含中文检查仓库路径改为纯英文路径AI 返回格式错提示词不明确查看原始返回加只输出 JSON约束同步冲突多端同时编辑git status手动解决冲突标记打开慢插件/笔记过多逐个禁用插件精简插件拆分仓库索引失败嵌入模型未加载查看 WorkBuddy 日志重新下载模型文件5.5 我踩过的几个坑第一个坑是过早引入AI。我一开始就把AI处理接入了所有笔记结果标签体系被AI搞得乱七八糟花了两周才清理干净。后来改成只对Inbox里的新笔记做AI处理整理后再归入正式目录问题就解决了。第二个坑是忽略.gitignore。我一开始没配置.gitignore把.obsidian/workspace这种临时文件也同步了导致每次切换设备都要重新调整界面布局。后来在.gitignore里加了.obsidian/workspace .obsidian/workspace.json .vectorstore/ .trash/第三个坑是用同一个模型处理所有任务。摘要、打标签、问答这三个任务对模型的要求不一样。摘要需要概括能力强的打标签需要分类能力强的问答需要推理能力强的。后来我在WorkBuddy里配置了多个模型按任务类型路由效果明显提升。6. 进阶玩法与扩展方向6.1 用 Dataview 做知识库仪表盘Dataview是Obsidian最强大的插件之一它能让你用类SQL的语法查询笔记。我建了一个Dashboard.md文件放在仓库根目录内容如下# 知识库仪表盘 ## 收集箱待处理 dataview TABLE created, summary FROM 00-Inbox WHERE status inbox SORT created DESC最近修改的笔记TABLE file.mtime as 修改时间 FROM 10-Notes SORT file.mtime DESC LIMIT 10标签统计TABLE length(rows) as 数量 FROM 10-Notes FLATTEN file.tags as tag GROUP BY tag SORT length(rows) DESC这个仪表盘让你一眼看到知识库的状态有多少笔记待处理、最近改了什么、标签分布如何。配合Obsidian的固定标签页功能可以把它常驻在侧边栏。 ### 6.2 多AI协作的配置思路 热词里提到了多AI协作这在WorkBuddy里是可以实现的。核心思路是让不同的模型负责不同的环节形成流水线。 比如处理一条新笔记 1. 用快速模型如GPT-3.5做初步分类 2. 用强模型如GPT-4做深度摘要和概念提取 3. 用嵌入模型做向量化 4. 用另一个模型做质量检查 这样配置的好处是成本和效果的平衡——简单任务用便宜模型复杂任务用贵模型。WorkBuddy的工作流支持条件分支可以根据笔记的长度、标签等条件决定走哪条路径。 ### 6.3 知识库的长期维护策略 知识库不是建好就完事了它需要持续维护。我的维护策略是日清周结月回顾 **日清**每天花5分钟把Inbox里的笔记快速过一遍能归类的归类能删的删。 **周结**每周日花30分钟跑一次定期知识整理工作流处理本周积累的笔记更新仪表盘。 **月回顾**每月最后一天做一次全库检查——删除过时笔记、合并重复笔记、重构标签体系、重建向量索引。 这套维护策略听起来麻烦但实际执行下来每天5分钟、每周30分钟、每月1小时总投入并不大。关键是养成习惯让知识库保持活的状态。 ### 6.4 从个人知识库到团队知识库 如果你想把个人知识库扩展成团队知识库这套架构也能支撑但需要做一些调整 - **Gitee仓库改为团队仓库**添加团队成员为开发者设置分支保护规则 - **目录结构增加协作区**比如加一个 50-Team 目录存放团队共享的笔记 - **AI处理增加权限控制**不同成员看到的AI处理结果可能不同 - **同步策略改为分支模式**每个人在自己的分支上工作定期合并到主分支 不过说实话团队知识库用这套方案会比较折腾Git的冲突处理对非技术成员不友好。如果团队规模超过5人建议考虑更专业的协作平台。 ### 6.5 数据备份的兜底方案 最后说一个很多人忽略的问题备份。Gitee虽然可靠但不能把备份完全寄托在它身上。我的做法是三副本 - **本地副本**Obsidian仓库本身 - **远程副本**Gitee仓库 - **离线副本**每月一次把整个仓库打包压缩存到移动硬盘 离线副本是最重要的兜底。我见过有人因为误操作把远程仓库清空了本地又刚好重装了系统结果几年的笔记全没了。这种悲剧完全可以避免一个月花5分钟做个离线备份成本极低。 我个人在实际操作中的体会是这套组合最大的价值不是AI有多强而是数据完全属于自己。你可以随时换掉AI模型、换掉同步方案但笔记本身永远是纯文本永远能被任何工具读取。这种数据主权带来的安全感是任何一体化平台都给不了的。 最后再分享一个小技巧如果你觉得配置太复杂可以先只做ObsidianGitee的同步把AI部分放一放。等笔记积累到一定量、真正感受到找不到东西的痛点了再引入WorkBuddy做AI处理。工具是为人服务的不要为了用工具而用工具。 Obsidian+WorkBuddy+Gitee：打造AI驱动的本地个人知识库
1. 为什么我要折腾这套组合拳1.1 从笔记坟场说起我用了差不多五年的笔记软件从最早的印象笔记到后来的语雀、飞书文档再到Notion几乎每一款都深度用过至少半年。但说实话大部分人的笔记最后都变成了坟场——记的时候很爽找的时候找不到用的时候想不起来。我自己也不例外最多的时候有三千多条笔记散落在四五个平台里真正能被我二次调用的可能不到百分之五。这个问题的本质不是记不记而是知识有没有被激活。传统笔记软件的问题在于它们是存储导向的你写进去的东西就是死的除非你主动去翻。而AI时代最大的机会就是让知识库从静态仓库变成动态助手——你问它它能答你写东西它能补你整理它能帮你归类。我最终选定的方案是Obsidian WorkBuddy Gitee这个三联组合。Obsidian负责本地知识库的存储和双链管理WorkBuddy负责AI能力的接入和自动化处理Gitee负责版本管理和多端同步。三个工具各司其职组合起来就是一个完全属于自己、不依赖任何平台、还能被AI驱动的个人知识库。1.2 这套组合到底解决了什么问题先说清楚这套方案适合谁。如果你是以下几类人这套组合会非常合适笔记量大但利用率低的人有几百上千条笔记但基本不回看需要AI帮你激活对数据隐私有要求的人不想把笔记放在别人的服务器上希望本地存储多设备用户办公室电脑、家里台式机、笔记本、手机都要能访问喜欢折腾的技术人愿意花一两个小时配置换来长期的生产力提升它解决的核心问题有三个。第一是数据主权所有笔记以Markdown纯文本存在本地就算哪天Obsidian倒闭了你的笔记照样能用任何编辑器打开。第二是AI激活通过WorkBuddy把大模型能力接进来让知识库能问答、能总结、能自动打标签。第三是版本可控用Gitee做Git仓库每次改动都有记录误删了能回滚多设备冲突能合并。我实测下来这套方案配置一次大概需要一到两个小时之后基本就是无感使用——你只管写同步和AI处理都在后台自动完成。1.3 三个工具的分工逻辑很多人会问为什么不用Notion AI或者飞书知识库这种一体化方案原因很简单一体化方案意味着你把所有鸡蛋放在一个篮子里平台改政策、涨价、甚至关停你都无能为力。而且一体化方案的AI能力往往是通用型的没法针对你的个人知识做深度定制。三联组合的分工是这样的工具角色核心职责替代方案Obsidian知识库主体本地存储、双链、标签、插件生态Logseq、思源笔记WorkBuddyAI 引擎大模型接入、自动化工作流、批量处理Dify、FastGPTGitee版本仓库Git 托管、多端同步、历史回溯GitHub、GitLabObsidian的强项是本地优先插件生态它的双链和标签系统是目前笔记软件里最灵活的。WorkBuddy的强项是工作流编排你可以把读取笔记→调用大模型→写回笔记这一整套流程做成自动化。Gitee的强项是国内访问稳定免费私有仓库对于不想折腾网络环境的用户来说是最省心的选择。提示这三个工具都是可以独立使用的组合起来是1113的效果。如果你只想先试试水建议从Obsidian开始用顺了再加AI和同步。2. 环境准备与工具选型细节2.1 Obsidian 的安装与初始配置Obsidian的下载很直接官网就能拿到各平台安装包。Windows用户建议下载exe安装版而不是便携版因为安装版会自动注册系统级的文件关联双击md文件就能直接打开。Mac用户注意区分Intel和Apple Silicon版本M系列芯片一定要下arm64版本否则会通过Rosetta转译运行插件加载速度会明显变慢。安装完成后第一件事是创建仓库Vault。这里有个关键决策仓库放在哪里我的建议是放在一个路径中不含中文和空格的目录下比如D:\KnowledgeBase或者~/Documents/kb。原因后面讲Gitee同步的时候会说到Git对中文路径的处理在某些场景下会出问题提前避开能省很多麻烦。初始配置我建议做这几件事关闭安全模式设置→第三方插件→关闭安全模式这样才能装社区插件开启核心插件把标签面板大纲反向链接日记这几个核心插件打开设置附件目录设置→文件与链接→附件默认位置改成在指定文件夹中路径填attachments这样图片和附件不会和笔记混在一起开启Wiki链接设置→文件与链接→使用Wiki链接打开后[[笔记名]]这种写法才能生效关于主题热词里提到的Anuppuccin确实是个很漂亮的主题但安装失败通常是因为网络问题或者Obsidian版本不匹配。我的建议是先用默认主题把功能跑通主题这种东西属于锦上添花不影响核心使用。2.2 WorkBuddy 的部署方式选择WorkBuddy的部署有两种方式本地部署和云端部署。本地部署适合对数据隐私要求极高的用户所有AI调用都在自己机器上完成但需要一定的硬件配置至少16G内存最好有独立显卡。云端部署则更省事配置简单但需要把笔记内容发送到云端处理。我个人的选择是混合模式敏感笔记用本地模型处理普通笔记用云端API。WorkBuddy支持配置多个模型源你可以在工作流里根据笔记的标签或者目录来决定用哪个模型。安装WorkBuddy的时候有几个坑要注意缓存目录默认缓存目录在C盘如果你的C盘空间紧张一定要在设置里改成其他盘。我见过有人因为缓存把C盘塞满导致系统卡死的。端口占用WorkBuddy默认占用几个端口如果和你机器上其他服务冲突需要在配置文件里改。常见的冲突是3000端口很多前端开发工具默认用这个。国际版和国内版如果你主要用国内的模型API装国内版就行如果需要调用一些国外的模型国际版的兼容性更好。两个版本可以共存但要注意端口不要冲突。2.3 Gitee 仓库的创建与密钥配置Gitee的注册很简单重点说仓库创建和密钥配置。创建仓库的时候一定要选私有仓库。知识库这种东西包含大量个人信息公开仓库等于把自己的笔记摊开给所有人看。Gitee的私有仓库对个人用户是免费的容量也够用。仓库创建后关键是配置SSH密钥。很多人图省事用HTTPS方式每次push都要输密码非常烦。SSH密钥配置一次之后就是无感的。配置步骤# 1. 生成密钥对如果已有可以跳过 ssh-keygen -t ed25519 -C your_emailexample.com # 2. 查看公钥内容 cat ~/.ssh/id_ed25519.pub # 3. 复制输出的内容粘贴到 Gitee 的 SSH 公钥设置页面Windows用户注意密钥文件在C:\Users\你的用户名\.ssh\目录下。如果这个目录不存在说明你还没生成过密钥需要先执行上面的生成命令。配置完成后测试连接ssh -T gitgitee.com看到欢迎信息就说明配置成功了。如果提示权限拒绝检查一下公钥有没有正确粘贴以及Gitee账户有没有绑定邮箱。注意SSH密钥是绑定设备的如果你在多台电脑上使用每台电脑都需要生成自己的密钥并添加到Gitee。不要图省事把同一份密钥复制到多台机器这样一旦某台机器泄露所有设备都不安全。3. 核心架构设计与数据流拆解3.1 整体数据流向这套系统的数据流可以概括为本地写入→AI处理→Git同步三个环节。理解这个流向很重要因为它决定了你遇到问题时该从哪里排查。写入环节你在Obsidian里写笔记笔记以md文件形式存在本地仓库目录。这个环节完全离线不依赖任何网络。处理环节WorkBuddy监听仓库目录的变化当检测到新笔记或者笔记修改时触发预设的工作流。工作流可能包括自动打标签、生成摘要、提取关键概念、建立双链建议等。处理结果写回笔记的frontmatter或者追加到笔记末尾。同步环节Gitee作为远程仓库通过Git的push/pull实现多端同步。你可以设置定时自动同步也可以手动触发。同步的内容包括笔记本身和Obsidian的配置文件插件配置、主题设置等。这个架构的关键设计点是处理环节和同步环节解耦。也就是说AI处理失败不影响同步同步失败也不影响AI处理。这样任何一个环节出问题都不会导致整个系统瘫痪。3.2 目录结构设计目录结构是知识库的骨架设计得好后期维护成本极低设计得差笔记一多就乱成一锅粥。我踩过几次坑之后总结出这套结构KnowledgeBase/ ├── 00-Inbox/ # 收集箱所有新笔记先放这里 ├── 10-Notes/ # 永久笔记经过整理的知识 ├── 20-Projects/ # 项目相关笔记 ├── 30-Areas/ # 领域知识长期维护 ├── 40-Archive/ # 归档不再活跃的笔记 ├── 90-Templates/ # 模板文件 ├── 99-Attachments/ # 附件图片、PDF等 └── .obsidian/ # Obsidian 配置目录这个结构借鉴了PARA方法Projects、Areas、Resources、Archives但做了简化。数字前缀是为了让文件夹在文件管理器里按顺序排列视觉上更清晰。Inbox机制是这套结构的关键。你写任何新笔记第一站都是Inbox不要纠结放哪里。等周末整理的时候再决定这条笔记是变成永久笔记、归入某个项目、还是直接删掉。这个机制能极大降低记录时的心理负担让你更愿意写。3.3 AI 处理工作流的设计原则WorkBuddy的工作流设计有几个原则我按重要性排序原则一AI只做建议不做决策。比如自动打标签AI给出建议标签但最终是否采纳由你决定。我见过有人让AI全自动整理笔记结果标签体系越来越乱最后完全没法用。原则二处理结果可追溯。AI对笔记做的任何修改都要在笔记里留下记录比如在frontmatter里加一个ai_processed: 2024-01-15字段。这样你回看笔记时知道哪些内容是AI加的哪些是自己写的。原则三批量处理要限流。如果你有几千条笔记不要让AI一次性全部处理那样既费钱又容易出错。建议按目录分批处理每次处理50-100条处理完检查一下效果再继续。原则四保留原始版本。AI处理前先让Gitee做一次commit这样如果AI处理结果不理想可以随时回滚。3.4 多端同步的冲突处理策略多端同步是这套系统里最容易出问题的环节。核心矛盾是你在A设备改了笔记还没同步又在B设备改了同一条笔记两边一同步就冲突了。我的策略是**单写多读**同一时间只在一台设备上写笔记其他设备只读。具体做法是主力写作设备比如办公室电脑开启自动同步其他设备手机、平板只做查看需要编辑时先手动pull一次。如果确实需要多设备同时写那就要接受偶尔的冲突。Git处理冲突的方式是生成冲突标记你需要手动解决。Obsidian本身没有内置的冲突解决界面所以冲突多了会很烦。我的建议是配合Obsidian Git插件设置成启动时自动pull关闭时自动push能减少大部分冲突。场景推荐策略冲突概率单设备主力写作自动同步极低双设备交替使用启动pull关闭push低多设备同时编辑手动同步冲突解决中高团队协作不建议用这套方案高4. 实操过程与关键环节实现4.1 Obsidian 仓库初始化实操假设你已经装好了Obsidian现在从零开始建仓库。第一步打开Obsidian点击创建新仓库仓库名称填KnowledgeBase位置选D:\KnowledgeBaseWindows或~/KnowledgeBaseMac/Linux。创建完成后Obsidian会自动生成.obsidian配置目录。第二步按3.2节的目录结构创建文件夹。你可以手动创建也可以在Obsidian里用命令面板CtrlP输入新建文件夹逐个创建。我建议手动在文件管理器里创建更快。第三步安装必备插件。打开设置→第三方插件→浏览搜索并安装以下插件Obsidian GitGit同步的核心插件Dataview用类SQL语法查询笔记做知识库仪表盘Templater高级模板功能比核心模板插件强很多Tag Wrangler标签管理批量重命名标签Advanced Tables表格编辑增强安装完插件后每个插件都需要在设置里单独配置。Obsidian Git的配置后面会详细讲其他插件用默认配置就能跑。第四步创建模板文件。在90-Templates目录下创建note-template.md内容如下--- created: {{date:YYYY-MM-DD}} tags: [] status: inbox ai_processed: --- # {{title}} ## 核心内容 ## 相关链接这个模板会在你新建笔记时自动填充日期和标题status: inbox标记这条笔记还在收集箱里ai_processed留空表示还没被AI处理过。4.2 Gitee 仓库关联与首次推送仓库初始化完成后接下来把它和Gitee关联起来。第一步在Gitee上创建私有仓库仓库名建议和本地一致叫KnowledgeBase。创建时不要勾选使用Readme初始化仓库因为我们要推送本地已有的内容远程仓库如果有初始文件会导致冲突。第二步在本地仓库目录打开终端Windows用Git BashMac用Terminal执行cd /d/KnowledgeBase # Windows # 或 cd ~/KnowledgeBase # Mac/Linux git init git add . git commit -m 初始化知识库 git remote add origin gitgitee.com:你的用户名/KnowledgeBase.git git push -u origin master如果Gitee默认分支是main而不是master把最后一行改成git push -u origin main。第三步配置Obsidian Git插件。打开插件设置关键配置项Auto backup开启间隔设为10分钟Auto backup after file change开启Auto pull on boot开启Pull before push开启Commit messagevault backup: {{date}}这样配置后Obsidian每10分钟自动commit一次启动时自动pull关闭时自动push。日常使用基本不用管Git。注意首次push可能会因为仓库里有大文件比如附件目录里的图片而失败。Gitee对单文件大小有限制超过100M的文件会被拒绝。如果你的附件目录很大建议在.gitignore里排除掉或者用Git LFS。4.3 WorkBuddy 工作流配置详解WorkBuddy的核心是工作流Workflow一个工作流由多个节点组成节点之间用连线表示数据流向。我配置了三个核心工作流分别对应不同的使用场景。工作流一新笔记自动处理触发条件Inbox目录下有新文件创建。节点流程文件监听节点监听00-Inbox目录读取文件节点读取新笔记的完整内容大模型节点调用大模型提示词如下你是一个知识管理助手。请阅读以下笔记内容完成三件事 1. 生成一句话摘要不超过50字 2. 建议3-5个标签用英文小写连字符分隔 3. 提取笔记中提到的关键概念如果有的话 笔记内容 {{content}} 请以JSON格式输出字段为summary, tags, concepts解析JSON节点解析大模型返回的结果更新frontmatter节点把摘要、标签、概念写回笔记的frontmatter这个工作流跑通后你写完笔记保存几秒钟后frontmatter里就会自动出现摘要和标签。工作流二知识库问答触发条件手动触发在WorkBuddy界面输入问题。节点流程输入节点接收用户问题向量检索节点在知识库中检索相关笔记需要先建立向量索引大模型节点把检索到的笔记作为上下文让大模型回答问题输出节点返回答案这个工作流的关键是向量检索。WorkBuddy支持多种向量数据库我推荐用本地的ChromaDB配置简单不需要额外部署服务。建立索引的时候建议按目录分批建立不要一次性索引整个仓库。工作流三定期知识整理触发条件定时触发每周日晚上。节点流程查询节点查询所有status: inbox的笔记大模型节点让大模型分析这些笔记给出归类建议输出节点生成一份整理报告保存到00-Inbox/整理报告-{{date}}.md这个工作流帮你做周回顾把收集箱里的笔记过一遍决定哪些该归档、哪些该删除、哪些该进一步加工。4.4 向量索引的建立与更新向量索引是AI问答的基础。没有索引大模型只能靠猜来回答你的问题有了索引大模型能基于你的实际笔记内容来回答。建立索引的步骤第一步在WorkBuddy里配置向量数据库。选择ChromaDB数据目录设为D:\KnowledgeBase\.vectorstore注意这个目录要加到.gitignore里不要同步到Gitee。第二步配置嵌入模型。嵌入模型负责把文本转成向量我推荐用bge-small-zh这个模型体积小、速度快、中文效果好。如果你有GPU可以用bge-large-zh效果更好但更吃资源。第三步执行索引建立。在WorkBuddy里选择建立索引选择要索引的目录建议先索引10-Notes和30-Areas点击开始。索引过程会遍历目录下所有md文件分块、向量化、存入数据库。索引建立的时间取决于笔记数量和硬件配置。我实测下来1000条笔记用CPU大概需要10-15分钟用GPU大概2-3分钟。第四步配置增量更新。索引不需要每次全量重建WorkBuddy支持增量更新。配置一个定时任务每天凌晨跑一次只索引新增和修改过的笔记。提示向量索引的质量很大程度上取决于分块策略。默认的分块是按固定字数切分但更好的做法是按语义切分——比如按标题层级切分每个二级标题下的内容作为一个块。WorkBuddy支持自定义分块规则建议花点时间调一下。5. 常见问题与排查技巧实录5.1 同步类问题排查问题一push被拒绝提示non-fast-forward这是最常见的问题原因是远程仓库有你本地没有的提交。解决方法git pull --rebase origin master git push origin master--rebase参数的作用是把你的本地提交挪到远程提交之后避免产生合并提交。如果pull的时候有冲突需要手动解决冲突后再继续。问题二Obsidian Git插件不自动同步排查顺序检查插件是否启用设置→第三方插件→已安装插件检查自动备份间隔是否设置默认可能是关闭的检查是否有未解决的冲突打开终端执行git status检查SSH密钥是否有效执行ssh -T gitgitee.com我遇到过一次插件不工作的情况最后发现是仓库路径里有中文Git命令执行失败。改成纯英文路径后就正常了。问题三多设备同步后笔记内容错乱这通常是冲突没有正确解决导致的。Git在冲突时会生成这样的标记 HEAD 你本地的内容 远程的内容 origin/master你需要手动编辑文件决定保留哪部分然后删除这些标记再commit。如果冲突文件很多建议用VS Code打开仓库目录它的Git集成界面能可视化解决冲突。5.2 AI 处理类问题排查问题一大模型返回格式不对JSON解析失败大模型有时候会自由发挥返回的JSON格式不标准。解决方法是在提示词里加一句只输出JSON不要有任何其他文字并且在WorkBuddy的解析节点里开启容错模式能自动修正常见的JSON格式错误。问题二AI处理速度慢影响因素有三个模型选择、笔记长度、并发数。如果用的是云端API换一个更快的模型比如从GPT-4换成GPT-3.5如果笔记很长先做摘要再处理如果并发数设置太高降低一点避免触发API限流。问题三AI打的标签不符合预期这是提示词的问题。我一开始的提示词只说建议标签结果AI给了一堆很泛的标签比如知识学习。后来改成建议3-5个具体、有区分度的标签避免使用过于宽泛的词汇效果就好多了。提示词工程是个迭代的过程需要根据实际效果不断调整。5.3 性能与存储类问题问题一Obsidian打开慢原因通常是插件太多或者笔记太多。解决方法禁用不常用的插件关闭显示反向链接等实时计算功能如果笔记超过5000条考虑拆分仓库问题二Gitee仓库容量不够Gitee免费私有仓库有容量限制如果附件太多容易超。解决方法在.gitignore里排除附件目录用图床替代本地图片比如PicGoSM.MS定期清理历史提交用git gc或者重建仓库问题三向量索引占用空间大向量索引的大小和笔记数量成正比。如果空间紧张可以只索引核心目录不索引Inbox和Archive用更小的嵌入模型定期重建索引删除过期数据5.4 常见问题速查表问题现象可能原因排查方法解决方案push 被拒绝远程有新提交git statusgit pull --rebase后 push插件不工作路径含中文检查仓库路径改为纯英文路径AI 返回格式错提示词不明确查看原始返回加只输出 JSON约束同步冲突多端同时编辑git status手动解决冲突标记打开慢插件/笔记过多逐个禁用插件精简插件拆分仓库索引失败嵌入模型未加载查看 WorkBuddy 日志重新下载模型文件5.5 我踩过的几个坑第一个坑是过早引入AI。我一开始就把AI处理接入了所有笔记结果标签体系被AI搞得乱七八糟花了两周才清理干净。后来改成只对Inbox里的新笔记做AI处理整理后再归入正式目录问题就解决了。第二个坑是忽略.gitignore。我一开始没配置.gitignore把.obsidian/workspace这种临时文件也同步了导致每次切换设备都要重新调整界面布局。后来在.gitignore里加了.obsidian/workspace .obsidian/workspace.json .vectorstore/ .trash/第三个坑是用同一个模型处理所有任务。摘要、打标签、问答这三个任务对模型的要求不一样。摘要需要概括能力强的打标签需要分类能力强的问答需要推理能力强的。后来我在WorkBuddy里配置了多个模型按任务类型路由效果明显提升。6. 进阶玩法与扩展方向6.1 用 Dataview 做知识库仪表盘Dataview是Obsidian最强大的插件之一它能让你用类SQL的语法查询笔记。我建了一个Dashboard.md文件放在仓库根目录内容如下# 知识库仪表盘 ## 收集箱待处理 dataview TABLE created, summary FROM 00-Inbox WHERE status inbox SORT created DESC最近修改的笔记TABLE file.mtime as 修改时间 FROM 10-Notes SORT file.mtime DESC LIMIT 10标签统计TABLE length(rows) as 数量 FROM 10-Notes FLATTEN file.tags as tag GROUP BY tag SORT length(rows) DESC这个仪表盘让你一眼看到知识库的状态有多少笔记待处理、最近改了什么、标签分布如何。配合Obsidian的固定标签页功能可以把它常驻在侧边栏。 ### 6.2 多AI协作的配置思路 热词里提到了多AI协作这在WorkBuddy里是可以实现的。核心思路是让不同的模型负责不同的环节形成流水线。 比如处理一条新笔记 1. 用快速模型如GPT-3.5做初步分类 2. 用强模型如GPT-4做深度摘要和概念提取 3. 用嵌入模型做向量化 4. 用另一个模型做质量检查 这样配置的好处是成本和效果的平衡——简单任务用便宜模型复杂任务用贵模型。WorkBuddy的工作流支持条件分支可以根据笔记的长度、标签等条件决定走哪条路径。 ### 6.3 知识库的长期维护策略 知识库不是建好就完事了它需要持续维护。我的维护策略是日清周结月回顾 **日清**每天花5分钟把Inbox里的笔记快速过一遍能归类的归类能删的删。 **周结**每周日花30分钟跑一次定期知识整理工作流处理本周积累的笔记更新仪表盘。 **月回顾**每月最后一天做一次全库检查——删除过时笔记、合并重复笔记、重构标签体系、重建向量索引。 这套维护策略听起来麻烦但实际执行下来每天5分钟、每周30分钟、每月1小时总投入并不大。关键是养成习惯让知识库保持活的状态。 ### 6.4 从个人知识库到团队知识库 如果你想把个人知识库扩展成团队知识库这套架构也能支撑但需要做一些调整 - **Gitee仓库改为团队仓库**添加团队成员为开发者设置分支保护规则 - **目录结构增加协作区**比如加一个 50-Team 目录存放团队共享的笔记 - **AI处理增加权限控制**不同成员看到的AI处理结果可能不同 - **同步策略改为分支模式**每个人在自己的分支上工作定期合并到主分支 不过说实话团队知识库用这套方案会比较折腾Git的冲突处理对非技术成员不友好。如果团队规模超过5人建议考虑更专业的协作平台。 ### 6.5 数据备份的兜底方案 最后说一个很多人忽略的问题备份。Gitee虽然可靠但不能把备份完全寄托在它身上。我的做法是三副本 - **本地副本**Obsidian仓库本身 - **远程副本**Gitee仓库 - **离线副本**每月一次把整个仓库打包压缩存到移动硬盘 离线副本是最重要的兜底。我见过有人因为误操作把远程仓库清空了本地又刚好重装了系统结果几年的笔记全没了。这种悲剧完全可以避免一个月花5分钟做个离线备份成本极低。 我个人在实际操作中的体会是这套组合最大的价值不是AI有多强而是数据完全属于自己。你可以随时换掉AI模型、换掉同步方案但笔记本身永远是纯文本永远能被任何工具读取。这种数据主权带来的安全感是任何一体化平台都给不了的。 最后再分享一个小技巧如果你觉得配置太复杂可以先只做ObsidianGitee的同步把AI部分放一放。等笔记积累到一定量、真正感受到找不到东西的痛点了再引入WorkBuddy做AI处理。工具是为人服务的不要为了用工具而用工具。