ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Obsidian+WorkBuddy+Gitee三联组合:从零搭建AI驱动的个人知识管理系统

2026/10/4 7:19:12 拓冰建站 浏览量
Obsidian+WorkBuddy+Gitee三联组合:从零搭建AI驱动的个人知识管理系统 最近把笔记系统彻底重构了一遍。之前试过各种笔记软件收藏夹里躺着几百篇“以后再看”的文章可真到用的时候关键词搜索翻半天也找不到想要的内容。现在这套 Obsidian WorkBuddy Gitee 的三联组合算是把“记笔记”这件事真正变成了“用知识”Obsidian 负责本地知识库的存储与链接WorkBuddy 这类 AI 工作台负责把碎片信息加工成结构化笔记Gitee 则承担多设备同步和版本回滚的脏活累活。这套方案适合需要大量阅读、写作、做技术调研的知识工作者也适合想把自己积累的资料变成“可检索、可调用、可回溯”资产的人。1. 从“记笔记”到“用知识”这套组合到底在解决什么问题1.1 传统笔记的“高墙”在哪里大多数人的笔记现状可以用三个词概括碎片化、孤立化、停滞化。碎片化指的是信息来源太多——微信收藏、浏览器书签、PDF 文档、随手拍的照片、即时通讯里的灵感对话全部散落在不同应用里没有一个统一出口。孤立化更致命每篇笔记都是“一座孤岛”没有和之前的笔记建立关联等到需要的时候根本想不起来自己写过类似内容。停滞化则是说很多笔记记完就再也不打开知识只进不出没有二次加工和输出。我过去用过多款主流笔记软件问题几乎一样采集容易调用难。搜索靠关键词匹配但人的记忆不是按关键词存的而是按场景和关联存的。我要找“之前看到过的、关于知识库同步方案对比的资料”脑子里根本没有准确的关键词传统笔记工具对此毫无办法。真正需要的是一个能对内容做语义理解、主动提炼摘要、自动建立关联的“加工层”。这就是把 AI 拉进来的根本原因。1.2 三联组合的分工逻辑Obsidian、WorkBuddy、Gitee 不是三个工具简单叠加而是各管一段的流水线设计。Obsidian 是存储与组织层。它把笔记存成本地 Markdown 纯文本文件不依赖任何云厂商数据主权完全在自己手里。双向链接与图谱视图让笔记之间可以形成“知识网络”而不仅仅是“文档列表”。这条网络是后续 AI 加工的基础——AI 可以读取全文、识别链接关系、理解上下文。WorkBuddy 是理解与加工层。它并不是单纯的聊天机器人而是提供一个“工作台”你可以在里面挂多个 AI 技能skill让 AI 读文件、提炼摘要、生成标签、按模板写回笔记库。这样它就站在了“笔记阅读者”的位置上把 Obsidian 里堆积的原始素材变成结构化笔记。Gitee 是同步与安全层。本地文件有了AI 加工也有了但知识库需要跨设备访问也需要防误删。Gitee 私有仓库提供 Git 版本管理每次改动都有提交记录误删可以随时回滚换电脑只需要 pull 一次。这是“知识演化”的记录仪。打个比方Obsidian 是书架WorkBuddy 是图书管理员Gitee 是保险柜里的账本。书架负责摆管理员负责整理和索引账本负责记录每一次增删改。三个角色缺一不可。1.3 一条信息从采集到沉淀的完整路径把这套组合串起来之后处理一条信息的完整路径是这样的在网页上看到一篇好文章用剪藏工具丢进 Obsidian 的 inbox 目录WorkBuddy 定时或手动扫描 inbox读取文章全文生成摘要、关键词、核心观点并建议可以链接到哪些已有笔记AI 按预设模板把整理后的内容写回知识库对应目录Obsidian Git 插件自动提交推送Gitee 上多出一笔新提交记录另外一台设备启动时自动拉取知识库保持同步以后要检索这条知识时直接问 WorkBuddy“我之前读过一篇关于 XX 的文章”它会基于本地文件内容给出带原文出处的回答。这个流程最大的变化在于原来“采集完就结束”现在“采集只是开始”。AI 帮你把原材料加工成半成品你只需要做最后的审核和删改。这才叫把笔记变成资产。1.4 这套方案适合谁不适合谁先说不适合的免得你白折腾如果你完全不想接触命令行对文件目录概念比较陌生这套方案的前期搭建可能会让你头疼建议先用现成的全托管笔记工具如果你需要和团队多人实时在线协作文档要同时编辑、同时评论Gitee 加 Obsidian 的组合不如文档类协作产品来得直接如果你绝大多数场景都在手机上记录Obsidian 移动端虽然能用但配合 Git 同步的体验确实不如原生云笔记丝滑。适合的人非常明确开发者、产品经理、技术研究者、写作人员以及所有手里有大量资料需要整理但又不放心把数据完全交给某个云平台的人。这套方案特别适合那些“资料多、检索难、跨设备需求强”的用户。我自己是程序员背景日常工作大量涉及技术文档、论文、项目方案这套组合几乎完美匹配。2. 工具选型为什么偏偏是这三个2.1 Obsidian本地 Markdown 不是复古是战略选择很多人不理解2025 年了为什么还有人用本地文件记笔记云笔记不香吗我在选型时的判断标准很简单知识库的最终形态必须是纯文本因为只有纯文本才是任何工具都能读取的开放格式。图片、PDF、专属数据库格式短期内看着方便长期都是锁定。举几个对比维度看一下维度ObsidianNotion / 语雀印象笔记存储形式本地 Markdown 文件云端私有格式云端私有格式离线访问完全可用受限受限数据导出直接复制文件即可导出流程繁琐导出流程繁琐笔记间关联双向链接 图谱有链接但弱基本无插件生态丰富可深度定制有限有限隐私本地文件可控平台可见平台可见“数据主权”这四个字平时不觉得直到你遇到一次“某个笔记工具宣布调整免费策略”或者“平台账号异常登录”的情况才会意识到本地文件多重要。Obsidian 的另一个优点是插件生态尤其是第三方插件可以配合 Git、AI 工作流这让它不像一个封闭的 App更像一个可以自由组装的工作台底座。2.2 WorkBuddyAI 聊天是外壳工作台才是本体最初接触 WorkBuddy 时我以为它又是一位“对话式 AI”用了几次才发现它的设计思路不一样。它不是给你一个对话框就完事而是强调“搭建工作台”——把多个 AI 能力、多个技能组合到一个工作流里。比如你可以配置一个“文献整理”技能AI 读取 PDF 后按你定义的结构输出摘要、方法、结论、局限性再配一个“剪藏清洗”技能把网页上复制下来的正文去广告、去重复、补全标题。这些技能组合起来就是一个自动化的知识处理流水线。在知识库场景里WorkBuddy 相对其他 AI 工具有几个实用点它能读取本地文件不需要把内容复制粘贴进对话它支持技能复用同一套处理逻辑可以反复使用它允许多智能体协作比如一个 Agent 负责初筛另一个负责精炼第三个负责校验链接是否有效。和 Cursor、Trae 这类偏代码场景的工具相比WorkBuddy 更侧重办公和文档场景如果你主要做的是写代码CodeBuddy 那边会更顺手WorkBuddy 更合适的场景是把文档、PDF、网页素材变成知识库内容。2.3 Gitee用 Git 管知识库的三个硬理由第一版本历史免费拿。Git 本身就是为“记录每一次改动”而生的笔记库变成本地 Git 仓库后每一次 AI 写回、每一次手动修改都可以提交。误删git checkout 回来。改坏了git revert。这在云笔记里是付费功能在这里是标配。第二多设备同步不需要第三方服务。Gitee 私有仓库充当中间存储电脑 A 推上去电脑 B 拉下来。移动端也能配合相关 Git 客户端做拉取基本满足日常查看需求。第三国内访问稳定且免费额度足够个人使用。一个私有仓库放几万篇 Markdown 笔记毫无压力仓库大小对纯文本来说几乎不是瓶颈。至于为什么不用 Obsidian 官方同步、iCloud、百度网盘Obsidian Sync 体验好但需要持续付费iCloud 在 Windows 上体验差而且文件冲突管理基本靠运气网盘能同步但没有任何版本回溯能力同步冲突时还会生成一堆“副本(1)”知识库很快就乱掉。Git 是专门解决这类问题的工具拿它做知识库同步属于降维打击。2.4 为什么不直接用“Obsidian AI 插件”市面上也有不少 Obsidian 内置 AI 插件能对话、能总结、能问答。我也试过最后放弃了原因有三个。第一插件运行在 Obsidian 进程内处理大量文件时会拖垮笔记库的响应速度第二插件的上下文管理能力有限处理长文档或跨多篇笔记的复杂任务时不稳定第三工作流无法沉淀每次都要重新组织提示词无法像 WorkBuddy 的 skill 一样把流程固化下来。外部 AI 工作台和笔记库解耦反而更灵活——笔记库保持纯粹AI 处理层独立演进两者通过文件系统对接这是更干净的架构。3. 动手搭建把三联组合串起来3.1 准备阶段安装与初始化不管你用什么系统先把两个基础工具装好Obsidian 和 Git。Obsidian 直接官网下载对应版本安装后新建一个 vault仓库建议路径不要带中文和空格比如D:\kb或~/Documents/kb。这一步容易被忽略但后面 WorkBuddy 读文件、Git 提交时路径里的中文和空格经常引发莫名其妙的报错。Git 的安装方式因系统而异Windows 直接装 Git for WindowsmacOS 用brew install gitLinux 用发行版自带的包管理器。装完打开终端验证git --version能看到版本号就说明装好了。另外强烈建议装一下 VS Code 或者任意一个支持 Markdown 预览的编辑器虽然 Obsidian 本身能编辑但查看冲突文件、diff 改动时用代码编辑器更顺手。3.2 在 Gitee 建私有仓库并配置 SSH打开 Gitee 官网注册登录后点击“新建仓库”。仓库名建议和本地 vault 同名比如kb。这里有一个关键选择初始化仓库时不要勾选“使用 Readme 初始化”。如果勾选了远程仓库会多出一个初始提交本地仓库和远程仓库的提交历史不一致首次推送时需要额外处理合并麻烦。建好空仓库后回到终端生成 SSH 密钥。用 Ed25519 算法比 RSA 更安全、更短ssh-keygen -t ed25519 -C your_emailexample.com一路回车即可默认会生成~/.ssh/id_ed25519和~/.ssh/id_ed25519.pub。然后把公钥内容复制到 Gitee 的“设置 → SSH 公钥”里cat ~/.ssh/id_ed25519.pub复制整行粘贴保存。之后测试连接ssh -T gitgitee.com如果返回欢迎信息说明 SSH 通道已通。这里有个容易踩的坑如果你之前配置过 GitHub 的 SSH 密钥Git 默认会用id_rsa或id_ed25519去连所有主机多平台密钥会冲突。解决办法是新建一个~/.ssh/config文件把不同主机的密钥区分开Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee IdentitiesOnly yes这样 Gitee 会用专属密钥不影响 GitHub 等其他仓库。3.3 本地仓库初始化与首次推送打开终端进入本地 vault 目录cd ~/Documents/kb git init然后创建.gitignore文件排除 Obsidian 的临时文件和本地状态。这里要特别注意不要直接忽略整个.obsidian目录否则你的主题、插件设置不会同步到其他设备。正确的做法是只忽略本地状态文件.obsidian/workspace.json .obsidian/workspace-mobile.json .trash/ .DS_Store接着把当前文件加入版本管理并做首次提交git add . git commit -m init knowledge base再关联远程仓库并推送。Gitee 仓库页有对应的仓库地址建议用 SSH 地址git remote add origin gitgitee.com:你的用户名/kb.git git push -u origin master注意分支名。如果你的本地默认分支是master推送时就用master如果是main就推送main。不确定就运行git branch看当前分支名。3.4 配置 Obsidian Git 插件实现自动同步手动敲 Git 命令太烦一次两次可以坚持不下来。obsidian-git 插件解决了这个问题它可以定时自动 commit、push、pull完全不需要手动干预。Obsidian 里打开“设置 → 第三方插件 → 关闭安全模式”然后在社区插件市场搜索obsidian-git安装启用。我推荐的核心配置如下自动备份间隔设为 10 到 15 分钟太频繁会干扰编辑太疏容易积累大量差异。自动提交信息模板建议写成chore: update notes - {{date}}方便以后看提交记录。是否自动 pull建议开启“启动时拉取”但关闭“运行时自动 pull”否则编辑中突然拉取容易和本地修改冲突。配置完成后每次 Obsidian 里的增删改都会在后台定时提交并推送到 Gitee。你在另一台电脑上打开 Obsidian 时插件会自动拉取远程更新知识库就同步了。3.5 安装 WorkBuddy 并接入知识库WorkBuddy 的安装很简单从官网下载对应系统版本安装后打开。初次启动需要登录账号然后会进入“工作台”界面。接入本地知识库的关键在于让 WorkBuddy 有权读取 Obsidian vault 目录。以我实际使用的方式为例我会在创建个人工作台时指定一个“知识库目录”把~/Documents/kb关联进去。这样 AI 就能直接读取里面的 Markdown 文件不需要复制粘贴。如果你的版本里没有直接的“目录关联”入口一个兜底方案是直接把 vault 路径告诉 AI并在提示词里说明“我的笔记在 X 目录下请读取”。多数 AI 工作台类工具都支持本地文件访问关键是理清手里的工具具体支持哪种方式。不确定就先用拖拽方式把单个文件丢进去测试验证能读文件后再设计批量处理流程。3.6 第一个自动化把一篇网页文章变成结构化笔记工具都装好后跑通第一个自动化流程。我在 Obsidian 里建了一个inbox目录专门放剪藏下来的原始内容。用 Obsidian 官方的 Web Clipper 插件或者在浏览器里直接复制文章正文粘贴到 inbox 目录下的新文件。然后打开 WorkBuddy调用一个我预先配好的 skill提示词大致是请阅读 inbox 目录下的最新一篇 Markdown 文件完成以下任务 1. 提取文章核心观点写成 3-5 条摘要 2. 提取 3-5 个关键词作为标签 3. 判断这篇文章和知识库中哪些已有笔记相关列出链接 4. 按下面模板把整理结果写入 articles 目录文件名用文章标题。 模板 --- title: tags: source: summary: --- ## 核心观点 ## 关键词 ## 相关笔记AI 处理完成后检查写回的文件手动调整不准确的部分然后提交推送。这个流程一次跑通之后你会明显感觉到原来“剪藏了等于没剪藏”的困境消失了——每篇文章进来都变成了带摘要、带标签、带关联的结构化笔记。4. 进阶用法多 AI 协作与知识流水线4.1 WorkBuddy skill把提示词变成可复用资产如果每次让 AI 干活都要重新写一大段提示词效率提升有限。WorkBuddy 的 skill 机制解决的就是这件事把一段成熟的提示词和处理逻辑固化成一个可以重复调用的“技能包”。我用了一段时间后沉淀了几个核心 skill基本覆盖日常 80% 的知识处理需求Skill 名称输入输出网页剪藏清洗inbox 下的原始网页粘贴去重、去广告、补全标题、Markdown 格式化文献提炼PDF 或论文文件研究问题、方法、结论、局限性的结构化摘要笔记关联单篇笔记推荐链接到哪些已有笔记、缺失的标签日报生成当日新增笔记按主题汇总当天积累的知识点每个 skill 都是一次“把个人经验固化”的过程。第一次配置时多花 30 分钟后面每次使用都能节省 15 到 20 分钟而且输出越来越稳定。4.2 多智能体协作拆解“调研-整理-提炼-归档”流水线单次 AI 对话处理不了大量文件的场景。一次丢 50 篇文献给它大概率只给你几段泛泛而谈的总结。多智能体协作的思路是把任务拆成多个角色各干一段。以我常用的调研流程为例先让一个 Agent 扫描 inbox对每篇文档做粗分类决定“是技术文章、行业报告还是观点随笔”再让第二个 Agent 对每类文档按对应模板提炼结构化摘要最后由第三个 Agent 做整合检查知识库中是否存在相关旧笔记生成跨文档的综述草稿。三个 Agent 的协作方式是全自动串联。中间的判断逻辑各管一段听起来复杂配置起来其实就是三个 skill 按顺序执行。这一步走通之后知识库的价值翻倍你处理和阅读理解的速度会快很多。4.3 Gitee 的版本回溯不是备份是知识演化的记录我一直觉得把 Gitee 当网盘用是浪费。Git 不只是防丢它还能回答一个关键问题我的知识库是“如何变成今天这样的”。比如有一次我把某个笔记目录大重构三个月后发现某些旧笔记里的独到观点在重构中被覆盖了。这时候用 Git 查看历史提交记录找到重构之前的那次提交把需要的段落恢复到新文件里完美解决。命令很基础git log --oneline -- 目录路径 git show commit-hash -- 目录路径另一个有用的实践AI 批量写回笔记后不要直接信任。我会先git diff查看改动内容确认 AI 生成的摘要没有事实性错误再由 Obsidian Git 插件的自动提交入库。如果 AI 写坏了直接git checkout .还原一条命令救回整个库。进阶玩法是分支管理长期维护一个inbox分支存放未加工素材一个main分支存放已归档的正式笔记。素材够了就在main上合并保持正式库的整洁。4.4 日常知识处理流程我的一天怎么跑这套系统目前已经稳定运行了一段时间形成了固定的节奏早上打开电脑Obsidian 自动从 Gitee 拉取最新内容。上班途中手机看到好文章直接发给剪藏工具自动落到 inbox 目录。白天凡是脑子里闪过“这个点可以记一下”就在 Daily Note 里用三五句话随手记。不用管格式不用管标签乱糟糟也没关系这是原材料。晚上睡觉前打开 WorkBuddy让“剪藏清洗”和“文献提炼”两个 skill 处理当天的 inbox 内容。AI 生成结构化笔记后我花十来分钟 review改掉不准确的摘要补上自己觉得重要的关联然后关闭 Obsidian插件自动提交推送。周末花半小时打开 Obsidian 图谱视图看看这周新增了哪些笔记、哪些领域密度特别高决定下周精力集中在哪块。这就是“知识管理”的日常形态AI 处理琐事人做判断。4.5 这套架构还能扩展到什么场景一种是技术文档库把项目设计文档、接口说明、代码评审记录全部纳入知识库WorkBuddy 可以把散落的决策过程提炼成架构演进记录。一种是写作素材库大量采访记录、读书笔记、旅行见闻都能按主题自动聚类写作时直接问 AI“我有哪些关于某个话题的素材”比翻聊天记录高效得多。还有一种偏专业的场景做专利相关的前期技术调研时用这个架构把文献列表、技术方案对比、已有专利线索全部集中整理后续撰写交底书时资料检索效率会有明显提高。核心逻辑是一样的任何以“读、想、写”为主的工作都能套用“原始素材 AI 加工 版本管理”的三层架构。5. 踩坑实录三联组合最容易翻车的六个位置5.1 Obsidian 打不开或社区插件商店空白新装 Obsidian 双击没反应或者插件市场一直转圈。前者常见于 Windows 老机器先试“右键 → 以管理员身份运行”不行再去设置里关掉硬件加速后者多半是网络问题社区插件列表是从海外源拉取的国内直连稳定与否看网络环境。我的解决方式是直接通过 GitHub 手动下载插件的 release 文件解压到.obsidian/plugins/目录重启即可插件版本更新也手动处理不依赖在线商店。5.2 GitHub 和 Gitee 的 SSH 密钥互相打架前面提到过的~/.ssh/config方法这是多平台账号的标配。我一开始就是没配 config明明测试 Gitee 的 SSH 能通但 git push 时总是报Permission denied (publickey)因为 Git 默认尝试了第一次生成的 GitHub 密钥。配置好之后优先用对应域名下的 IdentityFile问题立刻消失。如果配了 config 还不行检查密钥文件权限。Linux 和 macOS 下密钥文件权限必须是 600 以内chmod 600 ~/.ssh/id_ed25519_giteeWindows 上也可能遇到 OpenSSH 服务未启动的问题在服务管理器中开启OpenSSH Authentication Agent即可。5.3 push 到 Gitee 提示仓库不存在这个报错很迷惑明明仓库就在那。原因是 Gitee 的 Push 地址用的是“用户名”而不是“昵称”。如果你注册时显示的是中文昵称但 URL 里的拼音才是真实用户名。去仓库主页看浏览器地址栏的gitee.com/xxx/kb.git用xxx那段替换 remote 地址。另一个导致的点仓库名大小写敏感。Kb.git和kb.git在 Git 看来是两个地址核对清楚。5.4 Obsidian Git 插件报错“could not read Username”这个通常是 remote 地址写成了 HTTPS 格式插件每次 push 都要弹账号密码。解决办法就是换成 SSH 地址git remote set-url origin gitgitee.com:用户名/kb.git如果你只有 HTTPS 端口可用也可以配置 Gitee 的私人令牌私人令牌在 Gitee 设置里生成然后以https://用户名:令牌gitee.com/用户名/kb.git形式写入 remote。但我更推荐 SSH一劳永逸。5.5 WorkBuddy 处理本地文件时中文路径报错我遇到过几次 AI 读文件失败排查下来是路径里有中文。比如D:\知识库\我的笔记\经济学-原理.md这种路径偶尔会在工具的文件系统接口上出问题。方案有两个一是新建 vault 时就用英文路径二是给 WorkBuddy 配置的目录入口用英文路径做软链接。不建议在生产环境中保留大量中文文件名的同时指望 AI 处理完全不报错。更隐蔽的坑是文件名里的特殊符号比如#、、%。我在网上下载资料时经常带着这些字符AI 读取时偶尔解析出错。用 skill 处理时加一步“文件名清洗”把特殊符号替换成-一劳永逸。5.6 同步冲突文件堆了一堆冲突通常发生在两台设备同时修改了同一篇笔记并且都在编辑状态下触发了提交。Obsidian Git 插件默认会生成.sync-conflict-时间戳文件本质上两个版本都在需要手动合并。解决办法是改变使用习惯桌面端长时间编辑时注意看一下本地有没有未提交修改如果确定当前设备是“只读查询”状态先手动 pull 再查看。另一套做法是让同一个笔记只在同一台设备上编辑另一台设备只负责阅读和检索。知识库的主人是人不要制造设备之间的混乱竞争。5.7 常见问题速查表现象原因解决方案Obsidian 无法启动显卡兼容/硬件加速管理员运行关闭硬件加速插件市场空白网络拉取不到插件列表手动下载插件包到 plugins 目录SSH 连接失败密钥权限或平台冲突配置 config 文件chmod 600Push 仓库不存在用户名错误用 URL 中的拼音用户名Git 要用户名密码remote 是 HTTPS换成 SSH 地址AI 读不了文件中文路径/特殊字符英文路径文件名清洗 skill冲突文件过多多设备同时编辑设备分工先 pull 再改6. 关于这套组合我最想说的三件事这套架构已经稳定运行了很久中间经历过几次插件崩溃、AI 输出乱写、同步冲突但从来没有一次丢失过笔记。这要归功于 Git 版本管理兜底。不过工具只是工具真正让知识库产生价值的是使用方式。有三件事我觉得比工具本身更重要。第一AI 的输出永远要过一个“人的节点”。WorkBuddy 生成的摘要、标签、关联笔记我全部先 review 再入库。不是不相信 AI而是知识库是你的认知体系不是别人的。AI 的建议可以参考但决策权必须在自己手里。我见过一些朋友让 AI 全自动写笔记一个月后知识库变成了一堆看起来专业其实没有灵魂的文本垃圾。第二工具组合的稳定性比功能丰富更重要。Obsidian 插件动辄几十上百个但每个插件都是潜在的不稳定点。我的知识库只保留 5 个左右的核心插件Git、Templater、Dataview、Outliner 和一些外观微调插件。WorkBuddy 的 skill 我也控制在 5 个以内每个 skill 都反复迭代过确保输出稳定可靠。功能简洁系统才能长期健康运转。第三小步快跑别等完美方案。不用等把所有 skill 都配好再开始用。我当时就是先装好 ObsidianGit 仓库建起来让 WorkBuddy 每天只做一个动作——总结 inbox 里的新文章。跑了两个星期摸清了 AI 输出的规律才开始加自动标签、多智能体协作、分支管理。从最小闭环开始逐步扩展这套系统才真正长成了适合我自己的工作方式。你现在就可以从一条剪藏开始。