1. 这套组合到底在解决什么真实痛点我第一次把 Obsidian、WorkBuddy 和 Gitee 拼在一起用不是为了炫技而是被逼出来的。当时手头有三类内容长期处于“失联”状态一是某跨平台系统项目里零散的会议纪要和接口草稿存在本地 Markdown 文件里改完就忘存哪了二是某图像处理 Demo 的调试日志和参数对比记录写在临时文本里过两天连自己都看不懂缩写三是导师给的几份技术文档批注用 PDF 阅读器随手划线但没法和自己的思考联动。这些内容彼此割裂搜索靠 CtrlF 碰运气回溯靠翻文件夹猜时间知识越积越多反而越难调用。Obsidian 单独用能建双向链接、画关系图谱但它本质是个本地笔记工具——所有数据锁死在你电脑硬盘上换台设备就得手动同步协作更是奢望WorkBuddy 是个轻量级 AI 助手能读取当前打开的文档做摘要、改写、提问但它不存知识只做“即时服务”关掉窗口上下文全丢Gitee 倒是能托管代码和文档但纯当网盘用太浪费没人会对着 Git 提交记录去查上周的决策依据。这三者拼起来不是简单叠加而是形成一个闭环Obsidian 是你的“知识操作台”所有思考、整理、链接都在这里发生WorkBuddy 是嵌在操作台里的“实时协作者”它不替你记但能帮你快速理解、提炼、追问Gitee 则是这个操作台的“云端底座”自动备份每一次修改让历史可追溯、协作可落地、版本可回滚。它解决的从来不是“要不要用 AI”而是“AI 怎么真正长进你的工作流里而不是浮在表面当个玩具”。提示这套组合对三类人特别实用——独立开发者需要管理多项目文档调试记录、技术写作者需沉淀写作素材读者反馈版本迭代、高校研究者要整合文献批注实验日志论文草稿。它不追求大而全核心价值在于“让每一条笔记、每一次提问、每一处修改都有迹可循、有据可依、有人可问”。关键词里虽然没写但实际落地时“本地优先”“Git 版本控制”“AI 上下文感知”这三个底层逻辑必须吃透。很多人试了几天就放弃不是工具不行而是没意识到Obsidian 的威力不在花哨插件而在它强制你用纯文本组织知识WorkBuddy 的价值不在回答多准而在它能精准读取你当前正在编辑的那一页内容Gitee 的意义也不在免费仓库而在它把“知识变更”这件事变成了和“代码变更”一样可审计、可协作、可复现的技术动作。2. Obsidian为什么非得从纯文本和 Git 友好开始Obsidian 的安装本身毫无难度官网下载即用。但绝大多数人卡在第一步新建库的位置选错了。我见过太多人直接把库建在桌面或文档文件夹里结果三个月后文件夹里塞满“v2_最终版_改_1”“v2_最终版_改_2”这样的文件Git 根本没法跟踪——因为 Obsidian 库的本质是一个结构清晰的纯文本目录它的根目录下必须只有.obsidian/配置文件夹和*.md笔记文件其他任何二进制文件比如截图、PDF、Excel都应该放在assets/子目录里并且在笔记中用相对路径引用如。这是 Git 能有效工作的前提。为什么强调“纯文本”因为只有纯文本才能被 Git 精确识别差异。比如你在笔记里写“模型准确率从 82% 提升到 87%”Git diff 显示的就是这一行文字的增删但如果你把这句话截图贴进笔记Git 只能看到“图片文件被修改”完全丢失语义。我实测过一个含 500 条笔记、总大小 12MB 的 Obsidian 库开启 Git 后每次提交体积平均仅 1.3KB因为 Git 只存变化部分而如果混入大量图片和附件一次提交动辄几十 MB同步变慢历史查看变卡协作冲突变多。配置 Obsidian 时有三个插件是刚需且必须按顺序启用Core Plugin: Git内置这是整个闭环的基石。它不负责自动推送而是提供“一键暂存-提交-推送”按钮让你在 Obsidian 界面内完成全部 Git 操作。关键设置是勾选“Auto commit on save”保存即暂存并指定“Commit message template”为chore(notes): update {{file}}——这样每次保存Git 都会生成标准化的提交信息方便后续用git log --oneline快速浏览知识演进脉络。Community Plugin: Dataview它让静态笔记变成动态数据库。比如你想查“所有标注为 #bug 的笔记中最近三天修改过的有哪些”只需写一行查询LIST FROM #bug WHERE file.mtime date(today) - dur(3 days) SORT file.mtime DESC不用写 SQL不用建表所有数据源就是你的.md文件。我把它用在项目管理上每个任务建一个笔记顶部用 YAML Frontmatter 标记状态status:: todo/status:: in-progress/status:: doneDataview 自动聚合看板。Community Plugin: QuickAdd解决“想记却懒得开新文件”的惰性。我配置了两个快捷命令Daily Log按YYYY-MM-DD自动生成当天日志模板预置了“今日聚焦”“待办事项”“突发灵感”三个区块Meeting Note输入会议名称自动生成带参会人、时间、结论、行动项的结构化笔记行动项自动打上#action标签供 Dataview 后续追踪。注意不要一上来就装 20 个插件。Obsidian 的性能瓶颈不在插件数量而在“实时预览渲染”。比如同时开启 5 个高亮语法的插件编辑长文档时会明显卡顿。我的经验是先用 Git Dataview QuickAdd 三个插件跑通闭环稳定两周后再按需添加每次只加一个观察内存占用Windows 任务管理器看 Electron 进程Mac 活动监视器看 Obsidian 进程。3. WorkBuddy如何让它真正读懂你的笔记而不是瞎猜WorkBuddy 的安装包很小双击即装。但很多人装完发现“AI 不工作”根本原因是没理解它的设计哲学它不是 ChatGPT 那种通用聊天机器人而是一个“上下文感知型协作者”。它的能力边界非常明确——它只能处理你当前在 Obsidian 中打开并聚焦focus的那个文件的内容。它不会扫描整个库也不会记住上一条对话每一次交互都是独立的、基于当前文档的。所以正确用法是“三步法”3.1 文档准备给 AI 一个清晰的“阅读范围”WorkBuddy 默认读取整个当前文件。但一篇 3000 字的技术笔记里可能只有 200 字是你要分析的核心段落。这时候你需要用 Obsidian 的“块引用”功能开头把目标内容框出来。例如你在写模型调优记录其中一段参数对比表格很重要 | 参数 | v1.0 | v2.0 | v3.0 | |------|------|------|------| | learning_rate | 0.01 | 0.005 | 0.001 | | batch_size | 32 | 64 | 128 | | dropout | 0.3 | 0.2 | 0.1 |然后点击 WorkBuddy 的“Ask about selection”按钮不是“Ask about page”它就会只分析这个表格回答诸如“v2.0 相比 v1.0哪些参数调整了调整幅度是多少”这种精准问题。如果直接问“帮我总结这篇笔记”它会把开头的日期、结尾的待办事项全塞进上下文反而稀释重点。3.2 提问设计用“角色任务约束”框架WorkBuddy 对模糊提问容忍度极低。问“这个怎么理解”它大概率返回教科书定义但问“假设你是一名有五年 PyTorch 经验的工程师请用不超过 3 句话向刚学完线性代数的新手解释 dropout 层的作用并指出表格中 v2.0 的 dropout0.2 比 v1.0 的 0.3 更合理的两个原因”它就能给出切中要害的回答。我总结出最有效的提问模板“请以 [角色] 身份完成 [具体任务]要求 [明确约束]。”角色决定视角如“资深运维”“初中数学老师”“专利律师”任务决定输出形式如“生成 5 个测试用例”“重写为口语化表达”“提取所有 API 端点”约束保证可用性如“不超过 100 字”“用表格呈现”“避免专业术语”。3.3 结果处理别直接复制要“二次加工”WorkBuddy 的回答是初稿不是终稿。我有个铁律所有 AI 生成内容必须经过“三查”才能存入笔记查事实它说“ResNet-50 有 50 层”我要打开 PyTorch 官方文档确认查逻辑它推导“学习率降低导致收敛变慢”我要看自己的训练曲线图验证查归属它引用“某论文指出...”我必须找到原文补全引用格式如[[Paper-2023-Attention]]并在笔记末尾的## References区域添加完整条目。这看起来麻烦但恰恰是知识沉淀的关键。AI 是加速器不是替代者你才是知识的最终校验者和责任者。我曾因跳过“查事实”一步在笔记里记错了一个损失函数公式结果调试三天找不到 bug最后发现是 AI 把log(1-p)错写成log(p)——这种错误只有你自己能兜底。4. Gitee不只是代码托管而是知识演进的“时间机器”把 Obsidian 库推到 Gitee不是为了“备份”而是为了激活知识的“时间维度”。很多人以为 Git 就是防误删其实它更大的价值在于把知识的每一次微小进化都变成可检索、可比较、可回溯的原子事件。4.1 仓库初始化必须手动创建空仓库禁用 README这是最容易踩的坑。如果你在 Gitee 上点“新建仓库”时勾选了“初始化 README”Gitee 会自动生成一个含README.md的初始提交。但 Obsidian 库的根目录下README.md是非法文件——它不属于笔记也不属于配置Git 会把它当成普通文件跟踪导致后续git push时提示“non-fast-forward”必须强制推送git push --force而强制推送会覆盖他人提交协作时灾难性。正确做法Gitee 新建仓库绝对不勾选任何初始化选项得到一个纯空仓库在本地 Obsidian 库根目录打开终端执行git init git remote add origin https://gitee.com/yourname/your-kb.git git add . git commit -m chore(notes): init knowledge base git push -u origin master这样第一次提交就是你完整的 Obsidian 库结构干净利落。4.2 分支策略master 是“已发布知识”dev 是“实验区”Obsidian 库不需要复杂分支模型但必须区分两类内容master分支存放所有经过验证、可公开引用的知识。比如已完成的项目文档、定稿的技术方案、确认无误的实验结论。它应该保持高度稳定每次合并都需人工审查。dev分支存放草稿、未验证想法、临时分析。比如“尝试用 Llama-3 替换当前模型的可行性分析”“新采集的用户反馈原始记录”。它允许频繁提交甚至可以每天git push --force覆盖。我配置了 Gitee 的“保护分支”规则master分支禁止直接推送必须通过 Pull RequestPR合并且 PR 需满足两个条件至少一人 approve我自己就是审核者CI 流水线通过用 Gitee Pages 的构建检查确保所有 Markdown 链接有效、YAML Frontmatter 格式正确。这样master就成了知识的“黄金标准”而dev是安全的“沙盒”。某次我在dev分支里重构整个标签体系改了 200 多个文件的#tag测试没问题才合入master全程不影响他人使用。4.3 历史追溯用 Git 命令读懂知识的“生长日记”Gitee 网页端的提交列表只显示时间、作者、消息。但真正的知识演进线索藏在 Git 命令里。我每天晨会前必做三件事看谁改了什么git log --oneline --graph --all --simplify-by-decoration这条命令生成一个树状图一眼看出master和dev的分叉合并关系以及每次提交影响了哪些文件。查某次修改的细节比如看到一条提交chore(notes): refine api-spec for auth module我想知道具体改了哪几个接口就执行git show 9a3b4c5 -- api/auth.mdGit 会高亮显示新增/删除的行比如- POST /v1/login { username: string, password: string } POST /v1/login { email: string, password_hash: string }这比在网页上点开文件逐行对比快十倍。回溯某个概念的起源某天我发现笔记里频繁出现#zero-shot标签但不记得是谁、什么时候引入的。用git log -S #zero-shot --onelineGit 瞬间定位到首次添加该标签的提交2d1e8f9 feat(notes): introduce zero-shot prompting concept再git show 2d1e8f9就能看到当时的完整上下文——原来是在读一篇 ACL 论文时做的批注。提示Gitee 的“仓库统计”页面有个隐藏宝藏——“贡献图”。它不只显示代码提交也统计 Markdown 文件的修改次数。我把团队成员的贡献图并列展示能直观看出谁在深耕架构设计高频修改system-design.md谁在专注用户研究集中修改user-feedback.md这比 KPI 报表更真实反映知识贡献。5. 三联协同一个真实工作流的完整拆解现在我们把 Obsidian、WorkBuddy、Gitee 串成一条流水线。以下是我处理“某图像处理 Demo 性能优化”任务的完整过程不省略任何细节包括那些看似琐碎但决定成败的操作5.1 场景接到需求要将 Demo 的推理速度从 1200ms 降到 800ms 以内第一步我在 Obsidian 里新建笔记2024-06-15-image-optimize.md用 QuickAdd 的Meeting Note模板填入需求背景、当前瓶颈、验收标准。保存后Git 插件自动暂存。第二步我打开src/processor.pyDemo 的核心处理脚本在 Obsidian 中用Open with External App插件关联 VS Code边调试边在笔记里记录关键发现。比如发现cv2.resize()调用耗时占比 45%我就在笔记中写 cv2.resize() 占用 45% 时间输入尺寸 1920x1080 → 输出 640x480是否可改为 nearest neighbor 插值这段文字被标记成为 WorkBuddy 的专属处理范围。第三步我聚焦这段文字点击 WorkBuddy 的 “Ask about selection”输入“请以 OpenCV 高级开发者的身份分析 cv2.resize() 中 INTER_NEAREST、INTER_LINEAR、INTER_CUBIC 三种插值算法的计算复杂度和内存带宽消耗差异并针对 1920x1080→640x480 的降采样场景推荐最优插值方式及理由要求用表格对比。”WorkBuddy 返回一个三行表格指出INTER_NEAREST是 O(1) 复杂度无浮点运算最适合降采样且明确给出替换代码# 原代码 resized cv2.resize(img, (640, 480), interpolationcv2.INTER_LINEAR) # 替换为 resized cv2.resize(img, (640, 480), interpolationcv2.INTER_NEAREST)我立刻在 VS Code 中修改运行测试耗时降至 980ms——离目标还差 180ms。第四步我回到笔记在刚才的块下方追加新发现 替换为 INTER_NEAREST 后耗时 980ms。瓶颈转移至 model.forward()占时 65%。输入 tensor shape: torch.Size([1, 3, 480, 640])。再次聚焦问 WorkBuddy“请以 PyTorch 性能优化专家的身份分析 torch.Size([1, 3, 480, 640]) 输入张量在 forward 过程中可能的内存瓶颈并给出 3 种无需修改模型结构的优化手段如 dtype 转换、算子融合等要求说明每种手段的预期收益和风险。”它列出torch.float16推理、torch.compile()、batch size 调整三种方案并警告float16可能导致精度损失。我选择torch.compile()实测后耗时 760ms达标。第五步我更新笔记在## Conclusion区域写下最终方案和效果在## References添加两篇 PyTorch 官方文档链接用 Dataview 查询所有#action标签确认“更新 README 中性能参数”这条行动项已打勾。最后点击 Obsidian 的 Git 插件“Push”按钮。Gitee 收到提交CI 流水线自动运行检查链接有效性通过后master分支更新。整个过程从需求接收到知识固化历时 2 小时所有中间思考、试错、验证都留在 Git 历史里随时可查。5.2 关键协同点解析为什么缺一不可Obsidian 缺失则无结构没有双向链接2024-06-15-image-optimize.md就是一篇孤立文档无法关联到src/processor.py的代码位置、model-arch.md的架构图、perf-benchmark.md的历史数据。知识变成碎片。WorkBuddy 缺失则无智能没有它我得自己查 OpenCV 文档、翻 PyTorch GitHub Issues、手动计算内存带宽效率至少降 5 倍。它把“查资料”时间压缩到秒级让我专注“做判断”。Gitee 缺失则无传承没有 Git这次优化的完整思路、试错路径、参数对比只存在我本地硬盘。换台电脑或同事想复现一切归零。Gitee 让知识从“个人记忆”变成“团队资产”。这个工作流不是理想化的蓝图而是我踩过三次“忘记暂存导致重做半天”、两次“WorkBuddy 提问模糊导致答案无用”、一次“Gitee 分支混乱引发冲突”后用血泪换来的最小可行闭环。它不追求一步到位而是确保每一步操作都让知识更可靠一分、更易用一分、更可传承一分。6. 避坑指南那些官方文档绝不会告诉你的实战陷阱这套组合用起来很顺但有五个深坑每个都曾让我停工两小时以上。它们不在任何教程里全是实操中撞出来的6.1 Obsidian 的“自动保存”与 Git 的“暂存”冲突Obsidian 默认开启“Auto save”每 3 秒保存一次。而 Git 插件的 “Auto commit on save” 如果也开着就会导致你刚打完半句话Git 就提交了一次“不完整”的修改。比如你写实验发现INTER_NEAREST 速度更快但...还没写完“但”后面的内容Git 已提交。后续git diff里全是这种半截句子历史变得不可读。解决方案关闭 Obsidian 的 Auto save设置 → Files Links → Auto save changes改用快捷键CtrlSWin/CmdSMac手动保存。Git 插件的 “Auto commit on save” 保留这样你按一次CtrlS就完成“保存暂存提交”三连节奏可控。6.2 WorkBuddy 的“上下文长度”限制被严重低估WorkBuddy 官方说支持 32K tokens 上下文但这是指纯文本。实际测试发现一旦笔记里有大量 YAML Frontmatter、代码块、表格它的有效处理长度锐减。我有一篇含 20 个代码块的笔记总字符数 8000WorkBuddy 却报错“context too long”。解决方案用 Obsidian 的“折叠”功能%%注释包裹。把非核心内容如冗长的错误堆栈、完整日志用%%包裹WorkBuddy 默认忽略折叠内容。例如%% [ERROR] Failed to load model: ... Traceback (most recent call last): ... %%这样WorkBuddy 只处理可见部分上下文压力骤降。6.3 Gitee 的“大文件”检测误伤正常笔记Gitee 对单文件超过 100MB 的上传会拦截。但 Obsidian 库里.obsidian/plugins/下某些插件如 Canvas会生成缓存文件偶尔膨胀到 150MB。Git 提交时失败错误信息却是“remote rejected”完全不提文件大小。解决方案在库根目录创建.gitattributes文件明确声明忽略.obsidian/plugins/**/* filterlfs difflfs mergelfs -text assets/large-images/**/* filterlfs difflfs mergelfs -text然后安装 Git LFSLarge File Storage把大文件转为指针存储。Gitee 原生支持 LFS无需额外配置。6.4 Dataview 查询的“时间字段”陷阱Dataview 的file.mtime是文件修改时间但 Obsidian 的“修改”包含元数据更新比如你只是给笔记换个图标。这会导致WHERE file.mtime date(today) - dur(1 day)查出一堆无关笔记。解决方案改用file.cday创建日期或自定义 YAML 字段。我在所有笔记顶部强制添加--- created: 2024-06-15 updated: 2024-06-15 ---然后 Dataview 查询用WHERE this.updated date(today) - dur(1 day)精准锁定真正更新的内容。6.5 三端同步时的“Git 冲突”高频场景当你在公司电脑、家里笔记本、平板上同时编辑同一个笔记Git 推送时必然冲突。Obsidian 的冲突提示是灰色文字极易忽略导致你误以为“同步成功”实则本地修改被覆盖。解决方案启用 Gitee 的“Webhook”配置一个极简通知。在 Gitee 仓库设置 → WebhookURL 填你手机短信网关如国内某云服务商提供的 HTTP 短信接口触发事件选“Push Events”。每次有推送手机立刻收到短信“[KB] master updated by A同学”。看到短信立刻打开 Obsidian点 Git 插件的 “Pull” 按钮再点 “Resolve Conflicts”手动合并。这个习惯养成了冲突不再是灾难而是知识协同的自然心跳。注意所有这些坑都不是工具的缺陷而是它们各自设计哲学碰撞的结果。Obsidian 强调本地掌控WorkBuddy 强调上下文聚焦Gitee 强调分布式协作——把三个“强个性”的工具捏合本身就是一场精密的工程。接受它们的不完美比追求无缝更务实。7. 进阶扩展从个人知识库到轻量级团队中枢这套组合稳定运行三个月后我开始把它从“个人工具”升级为“小团队知识中枢”。核心原则不变不增加新工具只深化现有工具的用法。7.1 Obsidian用“社区插件”构建团队视图我启用了两个插件Outliner把所有带#team-meeting标签的笔记按时间倒序聚合在一个面板里自动生成会议纪要索引Excalidraw在笔记中直接手绘架构图、流程图保存为.excalidraw文件本质是 JSONGit 可 diff团队成员能直接在 Obsidian 里编辑无需导出导入。最关键的是我把团队共享的README.md放在库根目录用 Dataview 生成动态导航TABLE status, assignee, due FROM #project SORT due ASC这样打开库首页所有项目状态一目了然比 Jira 看板更轻量比 Excel 表格更可追溯。7.2 WorkBuddy为团队定制“知识问答”入口我导出 WorkBuddy 的常用提问模板存为templates/qa-templates.md里面预置“向新成员介绍本项目核心模块”“提取本次 PR 中所有 API 变更”“对比 v1.2 和 v2.0 文档列出所有废弃接口”新成员入职只需打开这个模板文件点击对应按钮WorkBuddy 就自动加载最新文档生成答案。它把“知识传递”从“人工讲解”变成了“自助服务”。7.3 Gitee用“Pages”发布可搜索的知识站Gitee Pages 免费支持静态网站托管。我用 Obsidian 的obsidian-export插件把master分支的笔记导出为 HTML部署到 Gitee Pages。网站自带全文搜索基于 Lunr.js支持按标签、日期、作者筛选。外部合作方无需安装 Obsidian打开网址就能查所有公开文档。更重要的是每次master有新提交Pages 自动重建知识永远最新。这个轻量级中枢没有买服务器没有搭后台没写一行后端代码却实现了✅ 知识集中存储Gitee✅ 知识智能检索WorkBuddy Pages 搜索✅ 知识可视化呈现Obsidian Excalidraw Dataview✅ 知识权限管控Gitee 仓库私有/公开设置它证明了一件事知识管理的天花板不在工具多强大而在你能否把已有工具用到极致。Obsidian、WorkBuddy、Gitee每一个都是成熟、稳定、被千人验证过的工具它们组合起来的力量远超任何标榜“AI 知识库”的黑盒产品。我在实际使用中发现最珍贵的不是某次 AI 给出的惊艳答案而是某天深夜调试失败翻看 Git 历史发现三个月前自己在同样位置写过一句批注“此处 buffer size 可能溢出待验证”——那一刻你不是在和 AI 合作而是在和过去的自己隔空击掌。