尧图网页设计 
1. 为什么“Obsidian WorkBuddy Gitee”不是又一个工具堆砌方案而是知识闭环的最小可行结构你可能已经看过太多“用XX搭建个人知识库”的教程Obsidian打底、加几个插件、再连个Notion或语雀同步——结果三个月后笔记散落在五个地方搜索失效双链断裂本地文件夹里躺着十几个没命名的.md草稿。我试过七种组合最后停在这三样上不是因为它们最炫而是因为只有这组能同时守住三个不可妥协的底线本地主权、AI可介入性、跨设备确定性同步。Obsidian 是骨架——它不联网、不上传、不锁死你的数据所有笔记就是纯文本文件存在你电脑硬盘某个文件夹里。WorkBuddy 是神经——它不是另一个聊天框而是直接嵌在 Obsidian 里的本地 AI 工作台能读你当前打开的笔记、调用你本地安装的 LLM比如 Ollama 上的 Qwen2 或 Phi-3、生成摘要、扩写段落、甚至帮你重写技术文档的语气。Gitee 不是“备份”而是唯一被验证过的、对中文用户零摩擦的 Git 同步中枢它不像 GitHub 那样偶尔抽风导致git pull卡住也不像 iCloud 那样把.obsidian/plugins/文件夹同步成乱码更不像 Syncthing 那样需要手动配端口和防火墙。它就老老实实跑在你自己的 Git 客户端里每次git push都返回一行绿色的To https://gitee.com/xxx/xxx.git稳得像电饭锅跳闸。这三个工具之间没有“集成 SDK”没有“官方 API 对接”全靠 Unix 哲学式的松耦合Obsidian 把笔记存成 MarkdownWorkBuddy 通过 Obsidian 的 Plugin API 读取当前编辑器内容Gitee 只管把整个 Vault 文件夹当普通 Git 仓库推拉。这种“不亲密”的关系反而让它抗折腾——去年 Obsidian 更新 1.6.0 时砍掉了旧版插件 APIWorkBuddy 没崩因为它的核心逻辑压根不依赖 Obsidian 的 UI 层Gitee 服务器维护升级那两天我照样在本地写笔记、用 WorkBuddy 生成周报等网络恢复git push一下全同步过去。提示很多人卡在第一步——以为要“配置 WorkBuddy 连接 Gitee”。根本不需要。WorkBuddy 只和 Obsidian 交互Gitee 只和你的命令行或 VS Code Git 插件交互。它们之间唯一的“连接线”是你自己每天按下的CtrlS保存和CtrlShiftP → Git: Push推送。这个设计不是偷懒是刻意为之任何中间层都会成为单点故障源。关键词“Obsidian”“WorkBuddy”“Gitee”在这里不是并列的工具名而是代表三种能力维度数据主权Obsidian、智能增强WorkBuddy、协同基座Gitee。少一个知识流就断一环——没有 ObsidianAI 处理的就是云端黑盒数据没有 WorkBuddyObsidian 只是高级记事本没有 Gitee你的知识库永远困在一台电脑里谈不上“个人”更谈不上“库”。2. Obsidian Vault 的底层结构设计不是文件夹堆砌而是知识拓扑的物理映射很多人把 Obsidian 当成 Word 替代品建个Daily Notes文件夹再建个Projects文件夹最后塞一堆Untitled.md。这样用三个月你会发现自己根本找不到上周写的那个接口设计思路——它可能在Projects/Backend/2024-05-12.md也可能在Daily Notes/2024-05-12.md里被当成随笔记了一笔。Obsidian 的威力不在“双链”而在文件系统即数据库。我们真正要设计的不是笔记怎么写而是 Vault 的目录骨架怎么长。我现在的 Vault 结构只有 4 个一级文件夹且全部小写、无空格、无中文vault/ ├── 00-index/ # 全局索引页只放 [[00-index/README]] 和 [[00-index/Navigation]] ├── 10-domain/ # 领域知识编程语言、协议标准、设计模式等按主题分而非按项目分 ├── 20-project/ # 项目快照每个子文件夹对应一个已交付/暂停的项目含需求、设计、复盘 └── 30-personal/ # 个人日志非事务性记录如学习心得、会议纪要、灵感碎片关键不是目录名而是每个文件夹的 README.md 承担着“领域地图”功能。比如10-domain/python/README.md里不写 Python 教程而是这样组织# Python 知识域地图 ## 核心锚点 - [[10-domain/python/asyncio]] - [[10-domain/python/type-hinting]] - [[10-domain/python/venv-vs-poetry]] ## 边界界定 - ✅ 包含CPython 实现细节、标准库模块行为、PEP 规范解读 - ❌ 不含Django 框架用法归入 20-project/ 下具体项目、Jupyter Notebook 技巧归入 30-personal/ ## 最近更新 - 2024-06-15补充 asyncio.run() 与 asyncio.create_task() 的调度差异 - 2024-06-10修订 typing.Union 在 Python 3.10 的新语法这个 README 不是目录列表而是该知识域的宪法。它定义了什么该放进来、什么该踢出去、哪些笔记是权威参考。WorkBuddy 后续做知识图谱分析时会优先扫描这类README.md获取领域边界Gitee 同步时这些文件天然成为 Pull Request 的审查焦点——如果有人改了10-domain/python/README.md我们就知道他在动 Python 领域的认知框架必须人工确认。注意绝对不要在00-index/下放“所有笔记链接”。真正的索引是动态生成的。我用 Obsidian 内置的Dataview插件写了一行查询TABLE file.ctime AS 创建时间, file.mtime AS 修改时间 FROM 10-domain AND !README SORT file.mtime DESC LIMIT 10它自动列出最近更新的 10 个领域笔记比手维护的链接列表准确十倍且永不 stale。文件命名规则同样重要。拒绝接口设计_v2_final_really.md这种名字。采用YYYYMMDD-主题-关键词.md格式例如20240615-api-design-restful-constraints.md。好处有三文件系统排序即时间线ls 10-domain/api/直接看到按时间倒序排列的设计演进WorkBuddy 可精准定位当它分析“RESTful 约束”时能直接匹配文件名中的restful-constraints比全文扫描快 3 倍Gitee 提交历史可读git log --oneline显示a1b2c3d 20240615-api-design-restful-constraints: add HATEOAS 示例比update api notes清晰百倍。3. WorkBuddy 的本地 AI 工作流绕过 API Key 陷阱构建真正属于你的智能体WorkBuddy 最常被误解为“Obsidian 版 ChatGPT”。错。它的价值不在“能聊”而在把大模型变成你知识库的肌肉记忆延伸。当你写完一段技术方案不用切到浏览器问“这段描述是否准确”WorkBuddy 能直接读取你当前编辑的 Markdown 文件、结合10-domain/下相关笔记、调用你本地运行的 Qwen2-7B 模型给出带引用的修订建议——所有数据不出你的电脑。实现这个的前提是彻底放弃“在线 API 模式”。我见过太多人填了 OpenAI Key结果发现模型回复里混着 Obsidian 笔记里没有的虚构引用处理 2000 字技术文档时API 调用超时返回半截句子更致命的是你刚写完的未提交代码设计被发到远端服务器违背了 Obsidian 的本地主权原则。WorkBuddy 的正确打开方式是把它当作Ollama 的前端指挥官。步骤极简本地部署模型以 macOS 为例brew install ollama ollama pull qwen2:7b # 7B 模型在 M2 Mac 上推理速度 12 tokens/sec足够日常 ollama run qwen2:7b # 首次运行会下载约 4GB 模型文件WorkBuddy 配置指向本地 Ollama在 Obsidian 设置 → WorkBuddy → Model Settings 中Provider:OllamaModel Name:qwen2:7bBase URL:http://localhost:11434Ollama 默认监听地址关键参数temperature0.3降低随机性保证技术表述稳定、num_ctx8192上下文窗口设满避免截断长文档创建专属 Skill技术文档校验器WorkBuddy 的 Skill 不是预设功能而是你用 YAML 写的指令模板。新建vault/.workbuddy/skills/tech-review.yamlname: 技术文档校验 description: 检查当前笔记的技术准确性引用本地知识库 prompt: | 你是一名资深 [{{domain}}] 工程师。请严格基于以下材料分析当前文档 - 当前笔记内容{{current_content}} - 相关领域知识来自 vault/10-domain/{{domain}}/{{domain_context}} - 要求 1. 指出所有与事实不符的表述标注原文位置如第3段第2行 2. 对模糊术语如“高性能”给出可量化定义建议 3. 补充 1-2 个本地知识库中已有的最佳实践案例链接 输出格式仅用 Markdown 列表不加解释性文字。当我在写20240615-api-design-restful-constraints.md时选中全文 → 右键 →WorkBuddy: Run Skill → 技术文档校验→ domain 填api几秒后得到❌ 第2段“RESTful 接口应避免使用 POST 更新资源” —— 错误。RFC 7231 明确允许 POST 用于非幂等更新PUT 才要求幂等。见 [[10-domain/api/http-methods]]。⚠️ 第4段“响应时间需控制在 200ms 内” —— “高性能”需量化建议改为“P95 响应时间 ≤ 200ms基于生产环境 30 天监控数据”。✅ 补充案例[[20-project/payment-gateway/20240322-optimization]] 中的异步回调降级方案可复用。这个过程没有 API Key 泄露风险没有网络延迟所有引用都来自你本地 Vault。WorkBuddy 的本质是让你把“查文档、比规范、找案例”这三步操作压缩成一次右键点击。实操心得模型选型上Qwen2-7B 比 Llama3-8B 在中文技术文档理解上更准尤其对 RFC、ISO 标准编号识别率高Phi-3-mini3.8B适合 M1/M2 Mac 做快速草稿润色但处理复杂逻辑易幻觉。别迷信参数越大越好——在本地推理速度和准确性平衡点往往在 4B~7B 区间。4. Gitee 同步的确定性保障从“能推上去”到“敢放心推”的工程化实践很多人用 Gitee 同步 Obsidian遇到的第一个问题是git push成功了但另一台电脑git pull后Obsidian 打开报错“插件配置损坏”。根源在于Obsidian 的.obsidian/文件夹里混着绝对路径、临时缓存、GUI 状态数据这些根本不该进 Git。Gitee 同步的从来不是“整个 Vault”而是“可重现的知识状态”。我的.gitignore经过 17 次迭代现在精简为 12 行每行都有明确工程依据# Obsidian 运行时状态绝对不进 Git .obsidian/workspace.json .obsidian/workspace-mobile.json .obsidian/app.json .obsidian/launcher.json # 插件缓存与临时文件由插件自身管理 .obsidian/plugins/**/cache/ .obsidian/plugins/**/temp/ .obsidian/plugins/**/node_modules/ # 用户生成的二进制附件图片/PDF 用 Git LFS 管理见下文 *.png *.jpg *.pdf # WorkBuddy 本地模型缓存Ollama 自己管 ~/.ollama/关键在最后三行图片和 PDF 不是简单忽略而是用Git LFSLarge File Storage管理。Gitee 原生支持 LFS配置只需两步# 1. 安装 git-lfsmacOS brew install git-lfs git lfs install # 2. 声明大文件类型在 Vault 根目录执行 git lfs track *.png git lfs track *.pdf git add .gitattributes这样做的好处是普通git clone时LFS 文件只下载轻量指针Vault 秒开需要查看 PDF 时git lfs pull单独下载不拖慢日常同步Gitee Web 界面能直接预览 PNGPDF 点击下载比丢网盘靠谱。同步流程必须固化为原子操作。我写了个sync.sh放在 Vault 根目录#!/bin/bash # 1. 保存所有未保存笔记Obsidian 必须关闭或启用 Auto Save osascript -e tell app Obsidian to activate \ -e delay 0.5 \ -e tell app System Events to keystroke s using command down # 2. 等待 Obsidian 写入磁盘实测需 1.2 秒 sleep 1.2 # 3. Git 提交 git add . git commit -m Sync $(date %Y-%m-%d_%H:%M) git push origin main echo ✅ Sync completed at $(date)每天下班前双击运行或绑定 Alfred 快捷键cmdopts。这个脚本的价值不在自动化而在强制建立“保存→等待→提交”的心智节奏。Obsidian 的 Auto Save 有 1.5 秒延迟如果没等完就git add会提交半个写入的文件导致另一台电脑解析失败。这个 1.2 秒是实测出来的——在 M2 Mac 上touch test.md sleep 0.1 echo a test.md的磁盘写入完成时间中位数。踩坑实录曾因忘记git lfs install导致 PDF 文件被当作文本提交Gitee 显示乱码git push失败。修复方法不是删仓库重来而是git lfs installgit lfs migrate import --include*.pdf,*.pnggit push --force仅第一次需强推这个操作会重写历史但 Gitee 支持且只影响 LFS 文件Markdown 内容完全保留。5. 三联组合的日常工作流从“写笔记”到“知识自生长”的闭环设计这套组合的价值不在搭建时的炫技而在每日使用的“无感增强”。我把它拆解为四个原子动作每个动作都由三者协同完成且全部在 Obsidian 界面内闭环5.1 新建领域笔记CtrlN触发的智能 scaffolding当我按下CtrlN新建笔记Obsidian 的Templater插件自动填充模板--- created: {{date:YYYY-MM-DD HH:mm:ss}} updated: {{date:YYYY-MM-DD HH:mm:ss}} tags: [{{tp.user.tag_prompt}}] --- # {{tp.user.title_prompt}} ## 背景动机 为什么需要这个知识点解决什么问题 ## 核心定义 - 关键术语 1 - 关键术语 2 ## 参考链接 - [[10-domain/{{tp.user.domain}}/README]] - RFC XXXX: {{tp.user.rfc_number}}此时 WorkBuddy 的Domain Context LoaderSkill 自动运行它扫描10-domain/下所有README.md提取## 核心锚点链接生成一个侧边栏面板显示“当前领域已知知识图谱”。我不用翻文件直接看到[[10-domain/python/asyncio]]和[[10-domain/python/type-hinting]]已存在避免重复造轮子。5.2 编辑中增强AltEnter呼出上下文感知助手光标停在某句话末尾按AltEnterWorkBuddy 弹出菜单“扩写技术细节” → 调用 Qwen2提示词为“基于 [[10-domain/api/http-methods]] 和 [[20-project/payment-gateway/20240322-optimization]]扩写当前句增加 HTTP 状态码选择依据”“生成类比解释” → 调用 Phi-3提示词为“用快递物流类比 RESTful 资源操作要求包含 GET/POST/PUT/DELETE 对应场景”“检查术语一致性” → 扫描全文对比10-domain/下术语定义表标红所有未定义的缩写如首次出现JWT时提醒“请链接 [[10-domain/security/jwt]]”5.3 每日收尾CmdShiftP → Sync Vault的确定性交付触发sync.sh后Gitee 返回成功日志同时 Obsidian 的Git Graph插件自动刷新显示本次提交的 diff。我一眼看到修改了10-domain/api/README.md新增了 HATEOAS 锚点新增了20240615-api-design-restful-constraints.md未改动30-personal/下任何文件说明今日专注领域建设这个可视化反馈比任何 KPI 都真实——知识库的成长就刻在 Git 提交图谱里。5.4 跨设备激活新电脑上的 3 分钟重生在新 MacBook 上git clone https://gitee.com/yourname/obsidian-vault.gitcd obsidian-vault git lfs pull下载 PDF/PNG打开 Obsidian → 打开此文件夹 → 安装 WorkBuddy 插件 → 配置 Ollama 地址所有笔记、双链、插件设置、Skill 模板全部就位。没有账号绑定没有云同步等待没有“正在加载 127 个插件”的焦虑。Vault 就是 Git 仓库知识就是可执行的代码。这套流程跑顺后知识生产不再是“写完存好就结束”而是进入自生长循环新笔记 → 触发 WorkBuddy 校验 → 发现知识缺口 → 自动生成待办[[00-index/TODO]]→ 同步到 Gitee → 另一台电脑上看到待办 → 点击跳转 → 开始补全。Obsidian 是土壤WorkBuddy 是雨露Gitee 是阳光——三者缺一植物就长不成。6. 避坑指南那些让三联组合失效的“温柔陷阱”即使严格按上述配置仍有几个看似合理实则危险的实践会让整个体系在 3 个月内退化为“又一个失败的知识库项目”。这些都是我亲手踩过的坑按严重程度排序6.1 “用 Obsidian Sync 服务替代 Gitee”——主权让渡的甜蜜毒药Obsidian 官方 Sync 服务每月 $8承诺“端到端加密”。但它的加密密钥由 Obsidian Inc. 控制你无法审计其客户端加密实现。更实际的问题是当你的 Vault 超过 5GB常见于存大量 PDF/截图Sync 服务会频繁中断同步错误日志只显示Sync failed: unknown error。而 Gitee 的git push失败时会明确告诉你error: RPC failed; curl 56 LibreSSL SSL_read: SSL_ERROR_SYSCALL意味着网络抖动重试即可。真正的数据主权体现在你能读懂每一个错误代码并有 100% 把握修复它。Gitee 给你这个能力Obsidian Sync 不给。6.2 “把 WorkBuddy 当搜索引擎用”——注意力稀释的加速器很多人喜欢用 WorkBuddy 的/search命令全局搜笔记。但实测发现当 Vault 超过 2000 个文件/search响应时间从 0.8 秒升至 4.2 秒且返回结果常包含无关的30-personal/日志。正确做法是用 Obsidian 内置搜索CmdP查文件名用 Dataview 查结构化内容WorkBuddy 只处理“当前上下文”。它不该是 Google而该是你的副驾驶——只在你写到一半卡壳时才递上精准的参考资料。6.3 “在 Gitee 创建私有仓库后开启‘私有部署’”——过度工程的典型Gitee 企业版提供“私有部署”选项听起来很安全。但 Obsidian Vault 同步根本不需要服务器端逻辑——它只是 Git 仓库。私有部署反而引入新故障点你需要维护 Nginx 配置、SSL 证书更新、数据库备份。而 Gitee 公共版的私有仓库通过 SSH Key 认证传输全程加密且 Gitee 的 SLA 99.95% 比你自建服务器靠谱得多。简单性本身就是最高级的安全。别为不存在的风险制造真实的运维负担。6.4 “用 WorkBuddy 自动生成所有笔记”——知识失真的温床WorkBuddy 能根据20-project/payment-gateway/自动生成20240615-payment-api-spec.md但初稿常混淆“支付通道”和“清算通道”概念。我的修正流程是WorkBuddy 生成初稿 → 存为20240615-payment-api-spec-draft.md手动对照10-domain/finance/payment-systems/README.md逐条核对将修正后的版本存为20240615-payment-api-spec.md在 draft 文件末尾添加[[20240615-payment-api-spec]]双链这个“AI 初稿 → 人工校验 → 正式发布”的三步法确保知识源头可控。WorkBuddy 是产科医生不是父母——它帮你把知识“生”出来但养育责任永远在你。最后分享一个硬核技巧Gitee 的Webhook可以触发自动化。我在 Gitee 仓库设置里添加 WebhookPayload URL 指向本地ngrok http 8000当有push事件时一个 Python 脚本自动运行# 检查是否修改了 10-domain/ 下的 README.md if 10-domain/*/README.md in changed_files: # 调用 WorkBuddy CLI 重新生成领域知识图谱 subprocess.run([obsidian-workbuddy, generate-graph, --domainall])这样每次更新领域定义知识图谱自动刷新无需手动操作。技术细节可展开但核心思想不变让工具链自己运转你只负责思考。 Obsidian+WorkBuddy+Gitee构建本地知识闭环
1. 为什么“Obsidian WorkBuddy Gitee”不是又一个工具堆砌方案而是知识闭环的最小可行结构你可能已经看过太多“用XX搭建个人知识库”的教程Obsidian打底、加几个插件、再连个Notion或语雀同步——结果三个月后笔记散落在五个地方搜索失效双链断裂本地文件夹里躺着十几个没命名的.md草稿。我试过七种组合最后停在这三样上不是因为它们最炫而是因为只有这组能同时守住三个不可妥协的底线本地主权、AI可介入性、跨设备确定性同步。Obsidian 是骨架——它不联网、不上传、不锁死你的数据所有笔记就是纯文本文件存在你电脑硬盘某个文件夹里。WorkBuddy 是神经——它不是另一个聊天框而是直接嵌在 Obsidian 里的本地 AI 工作台能读你当前打开的笔记、调用你本地安装的 LLM比如 Ollama 上的 Qwen2 或 Phi-3、生成摘要、扩写段落、甚至帮你重写技术文档的语气。Gitee 不是“备份”而是唯一被验证过的、对中文用户零摩擦的 Git 同步中枢它不像 GitHub 那样偶尔抽风导致git pull卡住也不像 iCloud 那样把.obsidian/plugins/文件夹同步成乱码更不像 Syncthing 那样需要手动配端口和防火墙。它就老老实实跑在你自己的 Git 客户端里每次git push都返回一行绿色的To https://gitee.com/xxx/xxx.git稳得像电饭锅跳闸。这三个工具之间没有“集成 SDK”没有“官方 API 对接”全靠 Unix 哲学式的松耦合Obsidian 把笔记存成 MarkdownWorkBuddy 通过 Obsidian 的 Plugin API 读取当前编辑器内容Gitee 只管把整个 Vault 文件夹当普通 Git 仓库推拉。这种“不亲密”的关系反而让它抗折腾——去年 Obsidian 更新 1.6.0 时砍掉了旧版插件 APIWorkBuddy 没崩因为它的核心逻辑压根不依赖 Obsidian 的 UI 层Gitee 服务器维护升级那两天我照样在本地写笔记、用 WorkBuddy 生成周报等网络恢复git push一下全同步过去。提示很多人卡在第一步——以为要“配置 WorkBuddy 连接 Gitee”。根本不需要。WorkBuddy 只和 Obsidian 交互Gitee 只和你的命令行或 VS Code Git 插件交互。它们之间唯一的“连接线”是你自己每天按下的CtrlS保存和CtrlShiftP → Git: Push推送。这个设计不是偷懒是刻意为之任何中间层都会成为单点故障源。关键词“Obsidian”“WorkBuddy”“Gitee”在这里不是并列的工具名而是代表三种能力维度数据主权Obsidian、智能增强WorkBuddy、协同基座Gitee。少一个知识流就断一环——没有 ObsidianAI 处理的就是云端黑盒数据没有 WorkBuddyObsidian 只是高级记事本没有 Gitee你的知识库永远困在一台电脑里谈不上“个人”更谈不上“库”。2. Obsidian Vault 的底层结构设计不是文件夹堆砌而是知识拓扑的物理映射很多人把 Obsidian 当成 Word 替代品建个Daily Notes文件夹再建个Projects文件夹最后塞一堆Untitled.md。这样用三个月你会发现自己根本找不到上周写的那个接口设计思路——它可能在Projects/Backend/2024-05-12.md也可能在Daily Notes/2024-05-12.md里被当成随笔记了一笔。Obsidian 的威力不在“双链”而在文件系统即数据库。我们真正要设计的不是笔记怎么写而是 Vault 的目录骨架怎么长。我现在的 Vault 结构只有 4 个一级文件夹且全部小写、无空格、无中文vault/ ├── 00-index/ # 全局索引页只放 [[00-index/README]] 和 [[00-index/Navigation]] ├── 10-domain/ # 领域知识编程语言、协议标准、设计模式等按主题分而非按项目分 ├── 20-project/ # 项目快照每个子文件夹对应一个已交付/暂停的项目含需求、设计、复盘 └── 30-personal/ # 个人日志非事务性记录如学习心得、会议纪要、灵感碎片关键不是目录名而是每个文件夹的 README.md 承担着“领域地图”功能。比如10-domain/python/README.md里不写 Python 教程而是这样组织# Python 知识域地图 ## 核心锚点 - [[10-domain/python/asyncio]] - [[10-domain/python/type-hinting]] - [[10-domain/python/venv-vs-poetry]] ## 边界界定 - ✅ 包含CPython 实现细节、标准库模块行为、PEP 规范解读 - ❌ 不含Django 框架用法归入 20-project/ 下具体项目、Jupyter Notebook 技巧归入 30-personal/ ## 最近更新 - 2024-06-15补充 asyncio.run() 与 asyncio.create_task() 的调度差异 - 2024-06-10修订 typing.Union 在 Python 3.10 的新语法这个 README 不是目录列表而是该知识域的宪法。它定义了什么该放进来、什么该踢出去、哪些笔记是权威参考。WorkBuddy 后续做知识图谱分析时会优先扫描这类README.md获取领域边界Gitee 同步时这些文件天然成为 Pull Request 的审查焦点——如果有人改了10-domain/python/README.md我们就知道他在动 Python 领域的认知框架必须人工确认。注意绝对不要在00-index/下放“所有笔记链接”。真正的索引是动态生成的。我用 Obsidian 内置的Dataview插件写了一行查询TABLE file.ctime AS 创建时间, file.mtime AS 修改时间 FROM 10-domain AND !README SORT file.mtime DESC LIMIT 10它自动列出最近更新的 10 个领域笔记比手维护的链接列表准确十倍且永不 stale。文件命名规则同样重要。拒绝接口设计_v2_final_really.md这种名字。采用YYYYMMDD-主题-关键词.md格式例如20240615-api-design-restful-constraints.md。好处有三文件系统排序即时间线ls 10-domain/api/直接看到按时间倒序排列的设计演进WorkBuddy 可精准定位当它分析“RESTful 约束”时能直接匹配文件名中的restful-constraints比全文扫描快 3 倍Gitee 提交历史可读git log --oneline显示a1b2c3d 20240615-api-design-restful-constraints: add HATEOAS 示例比update api notes清晰百倍。3. WorkBuddy 的本地 AI 工作流绕过 API Key 陷阱构建真正属于你的智能体WorkBuddy 最常被误解为“Obsidian 版 ChatGPT”。错。它的价值不在“能聊”而在把大模型变成你知识库的肌肉记忆延伸。当你写完一段技术方案不用切到浏览器问“这段描述是否准确”WorkBuddy 能直接读取你当前编辑的 Markdown 文件、结合10-domain/下相关笔记、调用你本地运行的 Qwen2-7B 模型给出带引用的修订建议——所有数据不出你的电脑。实现这个的前提是彻底放弃“在线 API 模式”。我见过太多人填了 OpenAI Key结果发现模型回复里混着 Obsidian 笔记里没有的虚构引用处理 2000 字技术文档时API 调用超时返回半截句子更致命的是你刚写完的未提交代码设计被发到远端服务器违背了 Obsidian 的本地主权原则。WorkBuddy 的正确打开方式是把它当作Ollama 的前端指挥官。步骤极简本地部署模型以 macOS 为例brew install ollama ollama pull qwen2:7b # 7B 模型在 M2 Mac 上推理速度 12 tokens/sec足够日常 ollama run qwen2:7b # 首次运行会下载约 4GB 模型文件WorkBuddy 配置指向本地 Ollama在 Obsidian 设置 → WorkBuddy → Model Settings 中Provider:OllamaModel Name:qwen2:7bBase URL:http://localhost:11434Ollama 默认监听地址关键参数temperature0.3降低随机性保证技术表述稳定、num_ctx8192上下文窗口设满避免截断长文档创建专属 Skill技术文档校验器WorkBuddy 的 Skill 不是预设功能而是你用 YAML 写的指令模板。新建vault/.workbuddy/skills/tech-review.yamlname: 技术文档校验 description: 检查当前笔记的技术准确性引用本地知识库 prompt: | 你是一名资深 [{{domain}}] 工程师。请严格基于以下材料分析当前文档 - 当前笔记内容{{current_content}} - 相关领域知识来自 vault/10-domain/{{domain}}/{{domain_context}} - 要求 1. 指出所有与事实不符的表述标注原文位置如第3段第2行 2. 对模糊术语如“高性能”给出可量化定义建议 3. 补充 1-2 个本地知识库中已有的最佳实践案例链接 输出格式仅用 Markdown 列表不加解释性文字。当我在写20240615-api-design-restful-constraints.md时选中全文 → 右键 →WorkBuddy: Run Skill → 技术文档校验→ domain 填api几秒后得到❌ 第2段“RESTful 接口应避免使用 POST 更新资源” —— 错误。RFC 7231 明确允许 POST 用于非幂等更新PUT 才要求幂等。见 [[10-domain/api/http-methods]]。⚠️ 第4段“响应时间需控制在 200ms 内” —— “高性能”需量化建议改为“P95 响应时间 ≤ 200ms基于生产环境 30 天监控数据”。✅ 补充案例[[20-project/payment-gateway/20240322-optimization]] 中的异步回调降级方案可复用。这个过程没有 API Key 泄露风险没有网络延迟所有引用都来自你本地 Vault。WorkBuddy 的本质是让你把“查文档、比规范、找案例”这三步操作压缩成一次右键点击。实操心得模型选型上Qwen2-7B 比 Llama3-8B 在中文技术文档理解上更准尤其对 RFC、ISO 标准编号识别率高Phi-3-mini3.8B适合 M1/M2 Mac 做快速草稿润色但处理复杂逻辑易幻觉。别迷信参数越大越好——在本地推理速度和准确性平衡点往往在 4B~7B 区间。4. Gitee 同步的确定性保障从“能推上去”到“敢放心推”的工程化实践很多人用 Gitee 同步 Obsidian遇到的第一个问题是git push成功了但另一台电脑git pull后Obsidian 打开报错“插件配置损坏”。根源在于Obsidian 的.obsidian/文件夹里混着绝对路径、临时缓存、GUI 状态数据这些根本不该进 Git。Gitee 同步的从来不是“整个 Vault”而是“可重现的知识状态”。我的.gitignore经过 17 次迭代现在精简为 12 行每行都有明确工程依据# Obsidian 运行时状态绝对不进 Git .obsidian/workspace.json .obsidian/workspace-mobile.json .obsidian/app.json .obsidian/launcher.json # 插件缓存与临时文件由插件自身管理 .obsidian/plugins/**/cache/ .obsidian/plugins/**/temp/ .obsidian/plugins/**/node_modules/ # 用户生成的二进制附件图片/PDF 用 Git LFS 管理见下文 *.png *.jpg *.pdf # WorkBuddy 本地模型缓存Ollama 自己管 ~/.ollama/关键在最后三行图片和 PDF 不是简单忽略而是用Git LFSLarge File Storage管理。Gitee 原生支持 LFS配置只需两步# 1. 安装 git-lfsmacOS brew install git-lfs git lfs install # 2. 声明大文件类型在 Vault 根目录执行 git lfs track *.png git lfs track *.pdf git add .gitattributes这样做的好处是普通git clone时LFS 文件只下载轻量指针Vault 秒开需要查看 PDF 时git lfs pull单独下载不拖慢日常同步Gitee Web 界面能直接预览 PNGPDF 点击下载比丢网盘靠谱。同步流程必须固化为原子操作。我写了个sync.sh放在 Vault 根目录#!/bin/bash # 1. 保存所有未保存笔记Obsidian 必须关闭或启用 Auto Save osascript -e tell app Obsidian to activate \ -e delay 0.5 \ -e tell app System Events to keystroke s using command down # 2. 等待 Obsidian 写入磁盘实测需 1.2 秒 sleep 1.2 # 3. Git 提交 git add . git commit -m Sync $(date %Y-%m-%d_%H:%M) git push origin main echo ✅ Sync completed at $(date)每天下班前双击运行或绑定 Alfred 快捷键cmdopts。这个脚本的价值不在自动化而在强制建立“保存→等待→提交”的心智节奏。Obsidian 的 Auto Save 有 1.5 秒延迟如果没等完就git add会提交半个写入的文件导致另一台电脑解析失败。这个 1.2 秒是实测出来的——在 M2 Mac 上touch test.md sleep 0.1 echo a test.md的磁盘写入完成时间中位数。踩坑实录曾因忘记git lfs install导致 PDF 文件被当作文本提交Gitee 显示乱码git push失败。修复方法不是删仓库重来而是git lfs installgit lfs migrate import --include*.pdf,*.pnggit push --force仅第一次需强推这个操作会重写历史但 Gitee 支持且只影响 LFS 文件Markdown 内容完全保留。5. 三联组合的日常工作流从“写笔记”到“知识自生长”的闭环设计这套组合的价值不在搭建时的炫技而在每日使用的“无感增强”。我把它拆解为四个原子动作每个动作都由三者协同完成且全部在 Obsidian 界面内闭环5.1 新建领域笔记CtrlN触发的智能 scaffolding当我按下CtrlN新建笔记Obsidian 的Templater插件自动填充模板--- created: {{date:YYYY-MM-DD HH:mm:ss}} updated: {{date:YYYY-MM-DD HH:mm:ss}} tags: [{{tp.user.tag_prompt}}] --- # {{tp.user.title_prompt}} ## 背景动机 为什么需要这个知识点解决什么问题 ## 核心定义 - 关键术语 1 - 关键术语 2 ## 参考链接 - [[10-domain/{{tp.user.domain}}/README]] - RFC XXXX: {{tp.user.rfc_number}}此时 WorkBuddy 的Domain Context LoaderSkill 自动运行它扫描10-domain/下所有README.md提取## 核心锚点链接生成一个侧边栏面板显示“当前领域已知知识图谱”。我不用翻文件直接看到[[10-domain/python/asyncio]]和[[10-domain/python/type-hinting]]已存在避免重复造轮子。5.2 编辑中增强AltEnter呼出上下文感知助手光标停在某句话末尾按AltEnterWorkBuddy 弹出菜单“扩写技术细节” → 调用 Qwen2提示词为“基于 [[10-domain/api/http-methods]] 和 [[20-project/payment-gateway/20240322-optimization]]扩写当前句增加 HTTP 状态码选择依据”“生成类比解释” → 调用 Phi-3提示词为“用快递物流类比 RESTful 资源操作要求包含 GET/POST/PUT/DELETE 对应场景”“检查术语一致性” → 扫描全文对比10-domain/下术语定义表标红所有未定义的缩写如首次出现JWT时提醒“请链接 [[10-domain/security/jwt]]”5.3 每日收尾CmdShiftP → Sync Vault的确定性交付触发sync.sh后Gitee 返回成功日志同时 Obsidian 的Git Graph插件自动刷新显示本次提交的 diff。我一眼看到修改了10-domain/api/README.md新增了 HATEOAS 锚点新增了20240615-api-design-restful-constraints.md未改动30-personal/下任何文件说明今日专注领域建设这个可视化反馈比任何 KPI 都真实——知识库的成长就刻在 Git 提交图谱里。5.4 跨设备激活新电脑上的 3 分钟重生在新 MacBook 上git clone https://gitee.com/yourname/obsidian-vault.gitcd obsidian-vault git lfs pull下载 PDF/PNG打开 Obsidian → 打开此文件夹 → 安装 WorkBuddy 插件 → 配置 Ollama 地址所有笔记、双链、插件设置、Skill 模板全部就位。没有账号绑定没有云同步等待没有“正在加载 127 个插件”的焦虑。Vault 就是 Git 仓库知识就是可执行的代码。这套流程跑顺后知识生产不再是“写完存好就结束”而是进入自生长循环新笔记 → 触发 WorkBuddy 校验 → 发现知识缺口 → 自动生成待办[[00-index/TODO]]→ 同步到 Gitee → 另一台电脑上看到待办 → 点击跳转 → 开始补全。Obsidian 是土壤WorkBuddy 是雨露Gitee 是阳光——三者缺一植物就长不成。6. 避坑指南那些让三联组合失效的“温柔陷阱”即使严格按上述配置仍有几个看似合理实则危险的实践会让整个体系在 3 个月内退化为“又一个失败的知识库项目”。这些都是我亲手踩过的坑按严重程度排序6.1 “用 Obsidian Sync 服务替代 Gitee”——主权让渡的甜蜜毒药Obsidian 官方 Sync 服务每月 $8承诺“端到端加密”。但它的加密密钥由 Obsidian Inc. 控制你无法审计其客户端加密实现。更实际的问题是当你的 Vault 超过 5GB常见于存大量 PDF/截图Sync 服务会频繁中断同步错误日志只显示Sync failed: unknown error。而 Gitee 的git push失败时会明确告诉你error: RPC failed; curl 56 LibreSSL SSL_read: SSL_ERROR_SYSCALL意味着网络抖动重试即可。真正的数据主权体现在你能读懂每一个错误代码并有 100% 把握修复它。Gitee 给你这个能力Obsidian Sync 不给。6.2 “把 WorkBuddy 当搜索引擎用”——注意力稀释的加速器很多人喜欢用 WorkBuddy 的/search命令全局搜笔记。但实测发现当 Vault 超过 2000 个文件/search响应时间从 0.8 秒升至 4.2 秒且返回结果常包含无关的30-personal/日志。正确做法是用 Obsidian 内置搜索CmdP查文件名用 Dataview 查结构化内容WorkBuddy 只处理“当前上下文”。它不该是 Google而该是你的副驾驶——只在你写到一半卡壳时才递上精准的参考资料。6.3 “在 Gitee 创建私有仓库后开启‘私有部署’”——过度工程的典型Gitee 企业版提供“私有部署”选项听起来很安全。但 Obsidian Vault 同步根本不需要服务器端逻辑——它只是 Git 仓库。私有部署反而引入新故障点你需要维护 Nginx 配置、SSL 证书更新、数据库备份。而 Gitee 公共版的私有仓库通过 SSH Key 认证传输全程加密且 Gitee 的 SLA 99.95% 比你自建服务器靠谱得多。简单性本身就是最高级的安全。别为不存在的风险制造真实的运维负担。6.4 “用 WorkBuddy 自动生成所有笔记”——知识失真的温床WorkBuddy 能根据20-project/payment-gateway/自动生成20240615-payment-api-spec.md但初稿常混淆“支付通道”和“清算通道”概念。我的修正流程是WorkBuddy 生成初稿 → 存为20240615-payment-api-spec-draft.md手动对照10-domain/finance/payment-systems/README.md逐条核对将修正后的版本存为20240615-payment-api-spec.md在 draft 文件末尾添加[[20240615-payment-api-spec]]双链这个“AI 初稿 → 人工校验 → 正式发布”的三步法确保知识源头可控。WorkBuddy 是产科医生不是父母——它帮你把知识“生”出来但养育责任永远在你。最后分享一个硬核技巧Gitee 的Webhook可以触发自动化。我在 Gitee 仓库设置里添加 WebhookPayload URL 指向本地ngrok http 8000当有push事件时一个 Python 脚本自动运行# 检查是否修改了 10-domain/ 下的 README.md if 10-domain/*/README.md in changed_files: # 调用 WorkBuddy CLI 重新生成领域知识图谱 subprocess.run([obsidian-workbuddy, generate-graph, --domainall])这样每次更新领域定义知识图谱自动刷新无需手动操作。技术细节可展开但核心思想不变让工具链自己运转你只负责思考。