过去一年我折腾过不少笔记方案。从最早的云端文档到后来的本地 Markdown 编辑器再到现在固定下来的这套组合Obsidian 负责存储和链接WorkBuddy 负责把 AI 嵌入笔记流程Gitee 负责远端备份和版本管理。三者各干一件事拼起来却解决了一个大问题——个人知识库既要智能、又要私有、还得可靠。这篇就完整记录我是怎么把这三样东西装到一起的包括目录怎么规划、Skill 怎么配、Git 怎么提交、以及哪些坑值得绕道走。适合正在搭建或者想迁移个人知识库的朋友直接抄作业。1. 先想清楚为什么必须三件套而不是一个 App 搞定1.1 一条流水线解决三件事很多人的知识库问题不是“没工具”而是“工具太多不知道信谁”。信谁这个问题本质上是三件事能不能存得住、能不能用得起来、能不能找得回来。Obsidian 解决“存得住”。它本地优先所有笔记都是一份份 Markdown 文件没有私有格式没有服务商跑路风险文件夹就是你的库。这一点对长期积累内容的人来说是决定性的——笔记放本地谁也锁不住你。WorkBuddy 解决“用得起来”。它等于一个给 AI 能力加挂的工作台能把大模型接到我的笔记流程里。写临时想法、整理摘录、生成标签、总结周报都可以在 WorkBuddy 的对话或 Skill 任务里完成最后产出的是 Markdown 文件直接落入 Obsidian 的库。它不绑架我的笔记格式只负责在笔记流中间加一段“智能处理”。Gitee 解决“找得回来”。本地文件再可靠也有硬盘损坏、电脑丢失的时候。我用 Gitee 的私有仓库做远端镜像每次提交都是一份带历史的备份。哪天本地库毁了clone 下来又是一套完整的。三者之间是接力关系不是嵌套关系。Obsidian 产出的文件通过目录落地WorkBuddy 在采集和整理两端介入Git 在这些文件外层做版本管理。这也是我个人比较推荐的分工存储、智能、备份各自独立换掉任何一个都不影响另外两个。1.2 和纯云端、纯本地方案的对比不做这个组合常见的替代路线有两种。一种是纯云端笔记比如各类在线文档或主流云笔记。优点是开箱即用多端同步几乎零成本缺点是内容被放进私有格式导出一堆 HTML、PDF 时格式经常错乱而且 AI 能力大多作为厂商的增值功能存在要么订阅不便宜要么只能在固定场景里用。另一种是纯本地纯手动比如只装个 Obsidian不加 AI 也不做远端镜像。优点是简单、完全可控缺点也很明显——采集端没有任何智能加工所有内容都要自己从零敲成结构化笔记写作压力一上来笔记很快就断层同时没有远端备份一次硬盘故障就全没了。把两条路线放在一张表里看会更直观能力项纯云端笔记纯本地手动ObsidianWorkBuddyGitee数据所有权低受服务商格式锁定高Markdown 本地留存高Markdown 本地留存多设备同步自带最省事不处理通过 Git 推送/拉取AI 加工能力厂商内置场景受限无通过 WorkBuddy 自由编排历史版本有限无每次 commit 即一份版本迁移成本高极低极低学习门槛低低中等需要一点 Git 基础这张表的最后一行是关键。三件套的代价是需要你愿意花一小时学一下最基本的 Git 操作和目录规划。换来的东西则是笔记永远是你的、AI 能力永远是自定义的、历史版本永远可回退。我个人觉得这笔交易非常划算。2. 动手前的基础准备安装、配置与仓库搭建2.1 Obsidian 本地库初始化与目录规划第一步先在官网下载 Obsidian 安装包装完后选择“创建新库”指定一个专门的文件夹比如D:\KnowledgeBase。这里有个建议库的路径尽量用英文不要带空格和中文。不是 Obsidian 不认中文而是后面 Git 操作时某些工具对特殊字符、中文路径的处理会让你多花很多冤枉时间。库建好之后先别急着写笔记把目录骨架搭起来。我用的是一套简化版 PARA 结构00-Inbox 收件箱所有未整理的原始笔记先进这里 10-Projects 项目有明确目标和时间的任务资料 20-Fields 领域长期关注的方向比如写作、编程、健康 30-Resources 资源参考素材、书摘、论文笔记 40-Archive 归档已结束或不再活跃的内容 95-Templates 模板各类笔记模板这个结构不复杂但它给 AI 处理留了一个好接口所有新内容先统一落在00-InboxWorkBuddy 可以无脑地对这一个文件夹做批量处理整理结束后再按内容归属分别移到其他目录。分类的动作由 AI 和人工共同完成而不是一开始就让写笔记的人陷入“这条笔记该放哪”的选择困难。进 Obsidian 后我建议立刻打开两个设置编辑器里的“严格换行”和“显示行号”前者保证 Git diff 起来逐行清晰后者方便定位问题。另外把“附件默认存放路径”设置为30-Resources/attachments避免图片散落各目录后面同步时会省很多心。2.2 WorkBuddy 安装、大模型接入与 Skill 基础WorkBuddy 的安装取决于你的操作系统Windows、macOS 都有对应版本按向导装好就行。第一次打开会让你配置模型服务在设置页填入你的 API Key、选择要用的模型然后就能进入对话式的工作台界面。这里我先解释一下 WorkBuddy 在我这套里的定位。它的本质是一个“AI 任务工作台”可以跟我以对话形式写草稿、整理文本也可以按预设的 Skill技能自动跑一套固定的处理流程。Skill 类似预制好的提示词包加输出规则比如我给它定义一个“读书卡片”技能只要输入一段摘录它就按固定格式输出观点、应用场景和双链建议。基础配置做完建议把默认输出语言设成中文输出格式明确写“Markdown”这样可以减少后期转换成本。模型部分不必执着于最强最贵的那档日常整理笔记、写摘要这类任务中等规模的模型完全够用成本也更可控。配置入口一般就在设置页的模型管理里各个版本的按钮位置略有差异找不到就搜“Model”或“密钥”。2.3 Gitee 私有仓库创建与 SSH 密钥配置Gitee 这块先说结论只建私有仓库公开仓库就别想了。知识库是个人资产里面各种想法的早期草稿、未打磨的随笔直接公开没有任何好处。登录 Gitee 后点“新建仓库”填个名字比如knowledge-base可见性选“私有”不要勾选任何初始化选项直接创建。这样得到的是一个空仓库正好让我们把本地已有内容推上去。接着配置 SSH 密钥。为什么要 SSH 而不是 HTTPS因为 SSH 密钥登录更省事push/pull 不需要反复输账号密码尤其适合后面我要做的每日提交节奏。生成密钥ssh-keygen -t ed25519 -C 你的邮箱一路上回车即可。如果设置了 passphrase每次使用时需要输入一次口令我个人建议设置安全性更好后面在踩坑部分我会聊一个相关教训。生成完查看公钥cat ~/.ssh/id_ed25519.pub复制整段输出到 Gitee 的“设置 → SSH 公钥”里粘贴保存。最后测试连通性ssh -T gitgitee.com看到类似Hi xxx! Youve successfully authenticated的提示就说明密钥已经生效。3. 核心工作流让笔记从采集到归档全程有 AI 参与3.1 碎片想法的 AI 初筛与结构化我用 WorkBuddy 的第一高频场景是把特别零碎的输入转成能进 Obsidian 的原子笔记。比如我今天在通勤路上想到一个关于“写作节奏”的点原文可能只有一句话“好文章是改出来的不是写出来的”。这句话直接丢进 Inbox 没问题但它太薄日后几乎不会被检索到。我把它丢给 WorkBuddy指令类似“根据这句话扩展成一页笔记包含原始想法、3 个支撑解释、我的实践建议控制在 200 字以内Markdown 格式。”WorkBuddy 返回的是一篇结构完整的初稿我再花两分钟调整语气和补充例子往00-Inbox一放这篇笔记就比原来有活力得多。这个流程的关键不在 AI 写得有多好而在于把“记录”的门槛降到几乎为零。过去我记录时脑子里要同时处理“记什么”和“怎么记”很容易放弃现在我只负责扔原始素材结构化的工作交给 WorkBuddy我只需要做最后一道人工校对。注意AI 扩展不等于 AI 编造。我要求 WorkBuddy 所有生成的内容必须基于我给的原始素材不要自行补充“据研究显示”这类无出处结论。这一点我会在 Skill 定义里写死宁可内容朴素也不要失真。3.2 标签、双链和命名AI 辅助的三种用法整理环节是很多人坚持不下去的地方。我的应对办法是把标签、双链、命名这三件事尽量交给 AI我只做判断。标签方面我给 WorkBuddy 的指令是给这篇笔记提 3 到 5 个标签优先复用已有标签而不是每次发明新词。Obsidian 对标签的检索能力很强但前提是标签一致性做得够好否则标签会迅速变成一团乱麻。AI 在这里的角色更像“标签评审”我定期把标签清单导出喂给它让它在我新增笔记时提建议。双链方面WorkBuddy 能根据笔记内容检索我库里已有的笔记标题推荐可能相关的链接。比如我写一篇关于记录方法的笔记它会提示“你之前有一篇关于 GTD 的笔记建议链接”。这样知识库会自然形成网状结构而不是一片孤岛。命名方面我的规则是日期加短标题比如2025-06-12-写作节奏是改出来的.md。文件名决定了 Obsidian 里链接的稳定性一旦改文件名所有引用它的双链都会出问题。所以 AI 生成文件名时我会要求它遵循这个规则人工确认后再落盘。这套在源头控制命名的思路极大减少了后续维护成本。3.3 每日一次 Git 提交版本管理与多设备同步笔记每天产生增量我的习惯是每天晚上做一次提交。如果你是新手先把基础命令跑通git add . git commit -m daily update: YYYY-MM-DD git push坦白说这套流程真正麻烦的地方不在命令本身而在两个细节。第一首次提交前要检查用户信息。Git 的每次提交会记录作者不设置的话会提交出一个奇怪的默认身份以后回溯历史时一脸懵。所以第一次跑之前先执行git config user.name 你的昵称 git config user.email 你的邮箱第二Obsidian 库里有大量文件git add .会把.obsidian配置目录、附件图片一并提交这没问题但要注意不要在库存放体积庞大的临时文件。我曾经把一个几十 MB 的演示视频直接丢进资源目录导致仓库体积暴涨之后每次 push 都很痛苦。大文件要么放别处要么用 Git LFS别混进知识库仓库里。多设备同步的场景下我的习惯是工作电脑和家用电脑都 clone 同一份仓库笔记本上完成当日记录后 push家用电脑 pull 后再继续。这个模式跟云笔记的“自动同步”体验有差距需要手动执行或借助定时脚本但它有一个云笔记给不了的好处——每一次同步都对应一个明确的版本点出了矛盾我可以直接回退到昨天、上周甚至上个月的笔记状态。4. 进阶玩法从“存下来”到“能回答”4.1 存量笔记的批量知识卡片化这套组合跑顺之后我开始回头处理存量笔记。以前的几百篇散乱文章不可能靠人工一篇篇重写。我的做法是写一个批量 Skill输入某个文件夹让它逐篇读取 Markdown 文件提取出核心观点、关键术语、适用场景每篇输出一个知识卡片文件。比如原笔记是一篇关于“复利思维”的长文卡片会包含三部分它讲了什么、我能怎么用、和库内哪几篇笔记相关。卡片文件统一放在30-Resources/cards目录原笔记仍然保留在 Archive 里原文信息没有丢失卡片则成为新的检索入口。这个批量处理的过程会比较久尤其是笔记数量多的时候。我建议按目录分批处理不要一次性把整个库都塞进 AI 的上下文否则很快就撞上窗口限制。一次处理一个文件夹处理完先抽查几篇卡片质量质量稳定再继续下一批。这里我也踩过一个教训不要追求每张卡片都完美。AI 批量处理的任务目标是把“不可检索的旧内容”变成“可检索、可链接的新入口”只要核心意思没跑偏细节上的小瑕疵完全可以在日常使用中再修。完美主义是批量整理最大的敌人。4.2 定制自己的 Skill 流水线WorkBuddy 的 Skill 机制是我用下来觉得投入产出比最高的部分。一个 Skill 本质上就是一份固定格式的指令模板写一次以后反复用。我拿“周报生成器”举例。一个最简单的 Skill 可以长这样名称周报生成器 触发输入上周做了什么 指令 1. 读取本周写下的所有笔记标题和摘要 2. 按项目/领域分组 3. 每类提取 2-3 条完成项 4. 输出 Markdown 周报标题为《周报-WXX周》 5. 输出后不要假设只基于实际笔记内容定义好之后每到周五我只需要在 WorkBuddy 里说“上周做了什么”它就按规则跑出一份初稿。我再补两句人话一封周报就完成了。这种前置定义指令的做法比每次现场打字描述需求要稳定得多AI 不会因为你的提示词写得含糊就跑偏。Skill 的价值在于把重复劳动沉淀成模板。建议每做一个 Skill 时先想清楚三个问题输入是什么、处理规则是什么、输出格式是什么。想清楚了Skill 就用起来很顺想不清楚过两周你自己都忘了这个 Skill 是干嘛的。4.3 多模型协作与主动问答场景进阶一点的玩法是把不同模型分到不同岗位。WorkBuddy 支持配置多个模型我就按任务性质做了分工日常对话和摘要这类交互性强的任务用主模型效果细腻批量整理、周报这些量大但要求不高的任务用参数稍弱、成本更低的模型跑反正最后还有人工校对这一道关。这个“多模型协作”的思路本质上跟团队分工一样复杂问题交给主模型处理批量任务交给执行岗统筹者是 WorkBuddy 这套任务编排。一句话总结就是复杂任务用强模型简单任务用低成本模型总成本能降下来体验还几乎不受影响。至于主动问答我现在的用法是把知识库目录结构喂给 AI它能告诉我某类问题应该去哪个目录、哪篇笔记里找答案。更进一步配合 Obsidian 的搜索语法我甚至会让 AI 先生成候选搜索词我复制进 Obsidian 的全库搜索命中率比我自己瞎猜关键词高很多。到这个阶段知识库不再只是“存笔记”的地方而更像一个能被检索、能给出答案方向的个人外脑。5. 踩坑实录我在这套方案里交过的学费5.1 认证方式的坑HTTPS 省事但别换来换去一开始图省事我用的是 HTTPS 方式 clone 仓库也就是地址形如https://gitee.com/用户名/仓库名.git。当时觉得不用配密钥push 时输一次账号密码就行。问题出在邮箱和密码输入太频繁一旦在 Git 凭据管理器里保存了错误的账号组合后面所有 push 都会报权限错误排查起来相当麻烦。后来我统一改成 SSH 方式把所有远端地址改成gitgitee.com:用户名/仓库名.git。改完之后清净了不用再记账号密码身份验证全部交给密钥。要提醒的是交接时别把origin的地址在 HTTPS 和 SSH 之间反复切换每次切换都可能引入凭据混乱排查成本比一开始配 SSH 高多了。检查当前远端地址用这个命令git remote -v如果显示的是 HTTPS 地址想换成 SSH直接执行git remote set-url origin gitgitee.com:用户名/仓库名.git5.2 passphrase 把钥匙“锁”住了这是我自己踩过的实坑。配置 SSH 密钥时我为了方便复制顺手设置了一个很长又很少用的 passphrase。结果两个月后某天需要在一台新电脑上推送笔记我发现怎么都想不起那段口令于是这台设备的密钥就废了。解决办法是在 Gitee 后台删掉旧公钥重新生成一对密钥再换上新公钥。整个流程十分钟内可以搞定但每次重装系统或换电脑都得来一遍实在烦人。所以我的建议是要么不设 passphrase把密钥文件保存在安全的地方要么设置一个自己绝对忘不掉的简单口令。安全性和可用性的平衡点得你自己选。另外提醒一个细节如果你有多个设备要访问同一个仓库不要简单拷贝同一份私钥到处用。正确做法是每台设备各自生成自己的密钥对分别把公钥加到 Gitee 账号下。这样某台设备出问题时只需要吊销那一台对应的公钥不至于影响其他设备。5.3 known_hosts 变化导致同步突然失败有一次 push 时 Git 突然报错提示REMOTE HOST IDENTIFICATION HAS CHANGED。第一次遇到这种情况很慌以为仓库或密钥出了问题。后来查明白了这是本机的~/.ssh/known_hosts里记录的远端主机指纹和 Gitee 服务器当前指纹对不上了。常见原因是重装系统、网络环境变化或中间设备影响。处理前一定要先确认是真正的主机变化而不是有人想拦截你的连接。确认之后删除 known_hosts 里对应主机的旧记录即可ssh-keygen -R gitgitee.com然后再执行一次ssh -T gitgitee.com重新信任主机指纹之后 push 就恢复正常。这条我不建议无脑照做每次操作前都应该想清楚“为什么指纹会变”确认环境安全再处理。5.4 仓库体积膨胀和文件名编码问题仓库体积问题前面提过这里再展开一些细节。Gitee 的私有仓库并不是无限容量免费仓库尤其要注意体积控制。以 Markdown 为主的纯文本库非常省空间几百万字的笔记也就几十 MB但一旦混入图片、PDF、音频仓库体积会迅速上涨。我的处理策略是图片尽量压缩后存放超过 5MB 的附件放网盘并在笔记里留链接体积大的原始文件绝不进 Git 仓库。底线是保证仓库体积维持在一个可控范围push 和 pull 都保持轻快。文件名的编码问题则隐蔽得多。Windows 平台下 Git 默认会把非 ASCII 文件名转义成八进制序列所以你 push 到 Gitee 上看中文文件名会显示成一串\346\265\213...之类的乱码。解决办法是在 Git 配置里关掉这个转义git config --global core.quotepath false配置完之后再 push中文文件名就会正常显示了。这条配置建议设成全局因为不只这个仓库会用上。5.5 上下文窗口不够用时的切分策略最后说一个 AI 使用层面的坑。WorkBuddy 对话时如果一次性丢给它整本电子书或几十篇长文大概率会提示超出上下文限制。我一开始习惯“一股脑全给”发现经常在输出一半时断掉。后来总结了两个对策。第一在输入侧就做切分只给它一章、一篇或一个主题范围内的内容让它在可处理的范围内做到最好。第二在输出侧强制结构化要求它先给骨架比如目录、要点列表我再挑需要展开的部分单独追问。这样虽然多了一轮交互但每次生成的质量和完整性都明显更高。这其实也符合知识库本身的设计理念原子化的笔记、清晰的链接、按主题组织的目录天然就是为 AI 处理效率服务的。先有结构再谈智能而不是反过来。收尾的一点个人体会这套组合我用了大半年最大的感受是个人知识库的瓶颈从来不是工具而是可持续性。Obsidian、WorkBuddy、Gitee 这三样分别解决了存储格式、智能处理和备份安全感的问题但真正让系统跑起来的是每天哪怕只有十分钟的记录习惯以及一套足够低门槛的流程。如果你也想搭我建议别一次性追求完美先把 Obsidian 和 Gitee 的同步跑通让内容安全落地再加入 WorkBuddy从一个最常用的 Skill 开始比如“把一句话扩写成笔记”。等这三样都成为肌肉记忆了再去折腾标签体系、双链网络、批量整理这些进阶动作。知识库是长出来的不是装出来的慢慢养它自然会成为你离不开的东西。