1. 项目概述为什么一个“三联组合”能真正解决知识管理的顽疾Obsidian、WorkBuddy、Gitee 这三个工具单独拿出来你可能都见过——Obsidian 是那个被无数人称为“第二大脑”的本地笔记神器WorkBuddy 是近年在开发者圈里悄悄走红的轻量级 AI 工作台Gitee 则是国内最成熟、最稳定的代码托管平台。但把它们串成一条链不是简单拼凑而是构建了一套闭环式、可演进、有主权的知识操作系统。我从去年初开始用这套组合搭建自己的技术知识库到现在累计沉淀了 1200 篇结构化笔记、37 个可复用的 AI 提示模板、8 类高频工作流比如“读论文→摘核心→生成摘要→关联已有知识→输出技术方案”整个过程没有依赖任何中心化 SaaS 服务所有数据都在本地加密存储同步靠 GitAI 调用走本地或私有 API连网络请求都可控可审计。这个组合的核心价值不在于“炫技”而在于它直击当前知识管理三大断层第一是输入断层——我们每天刷公众号、看 PDF、听会议录音但这些信息像沙子一样从指缝漏走没人帮我们自动提取关键实体、识别逻辑关系、打上语义标签第二是连接断层——Obsidian 的双向链接很强大但手动建 link 是反人性的90% 的人建到第 5 篇笔记就放弃了第三是活化断层——知识沉在硬盘里不调用就不产生价值。你写了一篇关于“RAG 检索优化”的笔记但当同事问“怎么解决 query 扩展不准的问题”时你根本想不起自己写过什么更别说让系统主动推给你。WorkBuddy 在这里扮演的是“知识神经中枢”的角色。它不像 Dify 那样需要你搭 pipeline、配向量库、调 embedding 模型而是以极低门槛的方式把 Obsidian 的纯文本笔记变成可理解、可推理、可响应的“活知识”。它不替代 Obsidian 的编辑体验也不抢 Gitee 的版本控制能力而是站在它们肩膀上做它们做不到的事比如你选中一段关于“BM25 和稠密检索融合策略”的文字右键点“让 WorkBuddy 解释”它立刻基于你本地已有的全部笔记上下文给出带引用来源的解读并自动建议 3 个可能相关的笔记标题比如《Elasticsearch 相关性调优实录》《向量检索失败的 7 种典型 case》再比如你新建一篇空白笔记输入标题“设计一个支持多模态 RAG 的知识库架构”WorkBuddy 不是泛泛而谈而是直接调用你 Gitee 仓库里已有的rag-arch-diagram.mermaid文件、config.yaml示例、以及 3 篇相关笔记中的技术约束条件生成一份贴合你真实技术栈的架构草稿。Gitee 的角色常被低估。很多人用它只是“备份一下笔记”这完全浪费了它的能力。Gitee Pages 可以一键发布你的知识库为静态网站供团队查阅Gitee 的 Issue 系统天然适合作为“知识缺口追踪器”——当你发现某类问题反复出现却无对应笔记时直接提个 Issue 标记为knowledge-gap下次 Review 笔记时集中补全更重要的是Gitee 的分支模型让你能安全地做知识实验main分支存稳定知识draft/rag-v2分支试跑新提示词review/2024q3分支做季度知识审计。这种工程化思维是把知识从“个人备忘录”升级为“可维护资产”的关键分水岭。所以这不是一个“Obsidian 插件教程”也不是“WorkBuddy 安装指南”更不是“Gitee 同步技巧”。这是一个面向真实工作流的、可落地、可迭代、有数据主权的知识基建方案。适合三类人一是技术文档工程师需要把零散的技术决策沉淀为可追溯的知识资产二是独立开发者或小团队技术负责人既要快速响应需求又要避免知识随人员流动而流失三是深度学习者希望自己的读书笔记、论文精读、源码分析能真正形成认知网络而不是一堆孤立的 Markdown 文件。接下来我会带你从零开始把这套组合真正装进你的工作流里每一步都附带我踩过的坑和验证过的参数。2. 整体架构设计与工具链选型逻辑2.1 为什么是 Obsidian 而不是 Notion 或 LogseqObsidian 的核心优势在于它是一个“纯文本 开放协议”的知识容器。Notion 的数据库视图很酷但它的数据锁死在云端导出为 Markdown 会丢失所有关系元数据比如 Relation 字段、Rollup 公式Logseq 的大纲嵌套很适合会议记录但它对长文本的块级引用Block ID支持不稳定导致 WorkBuddy 基于块的 AI 操作容易失效。而 Obsidian 的每个笔记都是一个.md文件每行文本都有唯一的 Block ID形如^a1b2c3这为 WorkBuddy 的精准上下文锚定提供了原子级支持。更重要的是Obsidian 的插件生态是“协议优先”的。它不强制你用某个云同步服务而是通过core plugin: File Sync或社区插件Obsidian Git把同步逻辑完全交给你控制。这意味着你可以把 Gitee 当作唯一的可信源所有设备都只从 Gitee 拉取最新快照而不是像 Notion 那样在多个客户端间做冲突合并——后者在处理 500 篇笔记、平均每天 20 次编辑的场景下几乎必然出现元数据错乱。我实测过当我在 iPad 上用 Obsidian 编辑一篇笔记同时在 MacBook 上用 VS Code 修改同一文件的 YAML frontmatterObsidian Git 插件能准确识别出这是“同一文件的两个修改”并提示你选择保留哪个版本而 Notion 的“最后编辑者胜出”机制会让你 iPad 上刚写的 300 字技术要点被 MacBook 上一次误触的 frontmatter 清空操作彻底覆盖。还有一个常被忽略的细节Obsidian 的搜索是本地全文索引毫秒级响应。当你用 WorkBuddy 发起一个“查找所有提到 BM25 参数调优的笔记”请求时它底层调用的就是 Obsidian 的searchAPI而不是去调用一个外部向量数据库。这省去了 embedding 模型加载、向量计算、近似最近邻搜索的整套开销对于 10GB 以内的笔记库响应时间稳定在 80ms 以内。相比之下Dify 的 RAG 流水线光是 embedding 这一步在 CPU 上就要耗时 2~5 秒这对需要高频交互的知识探索来说体验是断层的。2.2 为什么 WorkBuddy 是比 CodeBuddy 更合适的选择网络热词里频繁出现 “codebuddy 和 workbuddy”这说明很多人混淆了它们的定位。CodeBuddy 是一个 IDE 插件它的设计目标是“在写代码时提供上下文感知的补全和解释”比如你在写 Python 函数时它能根据你 import 的模块提示你可能用到的函数签名。而 WorkBuddy 是一个独立的、跨应用的 AI 工作台它的设计哲学是“知识即服务Knowledge as a Service”。它不绑定 VS Code 或 JetBrains而是通过系统级 Hook监听你在任何应用里的文本选择、剪贴板内容、甚至窗口标题然后触发预设的 AI 工作流。举个具体例子当你在 Chrome 里阅读一篇关于 Hermes Agent 的技术博客选中其中一段描述其调度策略的文字按下快捷键CmdShiftWWorkBuddy 会立刻启动它做的第一件事不是调大模型而是先解析你当前选中的文本提取出关键实体Hermes、调度策略、Agent、LLM Orchestrator然后去你的 Obsidian 笔记库中搜索所有包含这些实体的笔记按相似度排序生成一个“上下文摘要包”。这个包会作为 system prompt 的一部分再喂给本地运行的 Qwen2-7B 模型最终输出的回答天然就带着你个人知识库的烙印而不是通用网页的泛泛之谈。CodeBuddy 做不到这一点因为它没有权限访问你的 Obsidian 数据库也无法跨应用获取上下文。WorkBuddy 的另一个杀手锏是它的 Skill 系统。它不像传统 AI 工具那样只提供“聊天”界面而是允许你用 YAML 定义一套完整的技能Skill。比如我定义了一个rag-sql技能当检测到用户输入中包含“SQL”、“查询”、“字段”等关键词且当前焦点在 Obsidian 的代码块中时自动将该代码块内容作为 schema结合你笔记中关于“MySQL 索引优化”的 5 篇笔记生成一个带注释的 SQL 查询优化建议。这个 Skill 的触发逻辑、上下文注入、结果渲染全部由 WorkBuddy 管理你只需要维护 YAML 文件和对应的提示词模板。这种“声明式 AI 工作流”的能力是 CodeBuddy 这种命令式补全工具无法企及的。2.3 为什么 Gitee 是比 GitHub 或 GitLab 更优的基础设施选择 Gitee不是出于情怀而是基于三个硬性指标同步稳定性、国内访问速度、企业级功能完备度。GitHub 的私有仓库虽然免费但它的 Actions 在国内触发成功率低于 60%我曾为一个自动同步 Obsidian 笔记的 workflow 配置了 3 天最终放弃因为每次git push后Actions 总是卡在“Waiting for status to be reported”GitLab 自建虽然可控但一台 4C8G 的服务器光是跑 GitLab CE 就要吃掉 3.2G 内存留给 Obsidian 同步脚本的资源所剩无几。Gitee 的表现则非常扎实。它的 Webhook 响应延迟稳定在 200ms 以内git clone速度在 100MB/s 以上实测北京联通千兆宽带更重要的是它原生支持“仓库镜像”功能。这意味着你可以把 Gitee 作为主仓库同时配置一个 GitHub 的镜像仓库实现双备份。当 Gitee 出现临时维护时你的 CI/CD 流程可以无缝切换到 GitHub 镜像而无需修改任何代码。这个能力在知识库这种对连续性要求极高的场景里是真正的保险绳。另外Gitee 的 Pages 功能被严重低估。它不像 GitHub Pages 那样强制要求gh-pages分支而是允许你指定任意分支的任意目录比如main/docs/knowledge作为发布源。这让你可以轻松实现“知识库双模式”main分支的/docs目录存放经过人工审核的、面向团队的知识文档用 Jekyll 渲染为专业网站而/notes目录则存放原始的 Obsidian 笔记用obsidian-html工具转换为静态 HTML发布为内部可搜索的知识地图。这种灵活性是单一平台无法提供的。3. 核心组件部署与关键配置详解3.1 Obsidian 环境初始化从零构建可扩展的知识基座Obsidian 的初始化绝不是下载安装包、创建 vault 就完事。一个健壮的知识基座必须从第一天就规划好数据结构、元数据规范和自动化流水线。我的做法是用 Gitee 仓库驱动 Obsidian 初始化。第一步创建一个名为knowledge-base的私有 Gitee 仓库。不要直接在本地建 vault而是先在 Gitee 上初始化一个空仓库然后执行git clone https://gitee.com/yourname/knowledge-base.git cd knowledge-base # 创建标准目录结构 mkdir -p docs/{articles,reference,templates} notes/{tech,learn,meeting} assets/{images,diagrams} # 初始化必备配置文件 touch obsidian.json # 这是自定义的配置清单非 Obsidian 官方文件 echo {vault_name: my-kb, default_template: notes/templates/standard.md} obsidian.json git add . git commit -m chore: init standard dir structure git push第二步在 Obsidian 中“打开文件夹”指向knowledge-base目录。此时 Obsidian 会自动识别为 vault。关键来了禁用所有默认插件只启用 4 个核心插件Core Plugin: Templates用于快速插入标准化笔记模板Core Plugin: Tag Pane标签是轻量级分类的基石比文件夹更灵活Community Plugin: Obsidian Git这是同步的命脉配置如下{ autoPull: true, autoPush: true, commitMessage: chore: auto-sync from $(hostname), pushOnStartup: true, pullBeforePush: true, disablePopups: true }注意disablePopups必须设为true。否则每次同步都会弹窗打断工作流。我曾因没关这个选项在一次重要会议中Obsidian 连续弹出 7 个同步确认框差点误操作。Community Plugin: Dataview这是让知识“活起来”的引擎。它允许你用类似 SQL 的语法动态查询笔记。比如在dashboard.md里写TABLE file.ctime AS Created, file.mtime AS Updated FROM notes/tech WHERE contains(tags, rag) AND !contains(file.name, draft) SORT file.mtime DESC LIMIT 10这行代码会实时列出你所有标记为rag且非草稿的笔记按修改时间倒序排列。Dataview 的查询是即时的不需要重建索引这才是真正的“活知识”。第三步建立元数据规范。在notes/templates/standard.md中我定义了强制字段--- title: date: {{date}} tags: [] aliases: [] status: draft # draft | review | published source: # 来源链接如公众号文章 URL author: ---这个 YAML frontmatter 不是摆设。status字段驱动着我的 Gitee Pages 发布流程只有status: published的笔记才会被obsidian-html工具收录进公开文档站source字段则被 Dataview 用来生成“知识溯源图谱”你可以一键查看某篇笔记的所有原始出处。3.2 WorkBuddy 的本地化部署与 Skill 开发实战WorkBuddy 的安装官方推荐用brew install workbuddy但这在 M1/M2 Mac 上会遇到 Rosetta 兼容性问题。我的实操方案是跳过 Homebrew直接编译二进制。首先确保你已安装 Rustrustup install stable然后git clone https://gitee.com/workbuddy-org/workbuddy.git cd workbuddy # 修改配置禁用 telemetry sed -i s/telemetry_enabled: true/telemetry_enabled: false/g src/config.rs # 编译为本地架构 cargo build --release --target aarch64-apple-darwin # 复制到 PATH sudo cp target/aarch64-apple-darwin/release/workbuddy /usr/local/bin/提示telemetry_enabled: false这一行必须加。WorkBuddy 默认会上传匿名使用数据虽然不传笔记内容但会传触发的 Skill 名称和频率。对于知识库这种敏感场景关闭是底线。编译完成后启动 WorkBuddy 并配置其核心路径workbuddy config set --key obsidian.vault_path --value /path/to/knowledge-base workbuddy config set --key model.api_base --value http://localhost:11434/api/chat # Ollama 服务地址 workbuddy config set --key model.model_name --value qwen2:7b # 本地模型这里的关键是模型选择。网络热词里有人问“卡帕西的知识库可以用小模型做吗”答案是肯定的但必须选对模型。Qwen2-7B 在 8GB 显存的 M2 Max 上能跑满 24 token/s而 Llama3-8B 在同样硬件上只有 12 token/s且幻觉率高 37%这是我用 100 个测试用例统计的结果。Qwen2 的中文理解、代码生成、技术文档摘要能力是目前开源小模型里最均衡的。接下来是 Skill 开发。以我最常用的rag-pdfSkill 为例它解决的是“如何把微信公众号看到文章保存到知识库”这个高频痛点。创建文件~/.workbuddy/skills/rag-pdf.yamlname: rag-pdf description: Extract key insights from selected PDF text and link to relevant notes trigger: type: selection keywords: [pdf, document, article] context: - type: obsidian_notes query: tag:tech OR tag:learn limit: 5 - type: clipboard name: selected_text action: prompt: | You are an expert technical knowledge curator. Based on the following selected text from a PDF document and the context of my existing notes, please: 1. Extract the core technical claim or innovation. 2. Identify 3 key terms that should be used as tags. 3. Suggest 2 existing notes from my vault that this content should link to (provide exact filenames). Selected text: {{selected_text}} My relevant notes: {{obsidian_notes}} model: qwen2:7b output_format: markdown这个 Skill 的精妙之处在于context部分。它没有一股脑把整个知识库塞给模型而是用 Dataview 式的查询tag:tech OR tag:learn只拉取最相关的 5 篇笔记作为上下文。这既保证了回答质量又把 token 消耗控制在 2000 以内响应时间稳定在 1.8 秒。我测试过如果去掉limit: 5让它拉取全部笔记响应时间会飙升到 8 秒以上且模型开始胡编乱造笔记名。3.3 Gitee 仓库的精细化配置与自动化流水线Gitee 仓库的配置远不止设置 SSH 密钥那么简单。一个生产级的知识库仓库必须配置 5 层防护和 3 条自动化流水线。第一层SSH 密钥与 Git 配置# 生成专用密钥不与 GitHub 共用 ssh-keygen -t ed25519 -C kbyourname -f ~/.ssh/id_ed25519_kb # 添加到 Gitee 的 SSH Keys 设置页 # 配置 Git 全局规则让 knowledge-base 仓库走专用密钥 echo Host gitee.com-kb ~/.ssh/config echo HostName gitee.com ~/.ssh/config echo User git ~/.ssh/config echo IdentityFile ~/.ssh/id_ed25519_kb ~/.ssh/config # 在 knowledge-base 目录下重写 remote url git remote set-url origin gitgitee.com-kb:yourname/knowledge-base.git第二层Protected Branches在 Gitee 仓库的Settings Branch Protection Rules中为main分支设置Require pull request before merging强制所有修改必须经 PRRequire status checks to pass before merging勾选CI: sync-checkInclude administrators管理员也必须遵守规则Allow force pushesfalse绝对禁止Require linear historytrue避免 merge commit 污染历史。第三层Webhook 自动化在Settings Webhooks中添加一个 WebhookPayload URL 指向你的内网服务器如http://192.168.1.100:8080/webhookContent type 选application/jsonTrigger 选Push events和Pull request events。这个 Webhook 会触发一个轻量级服务做两件事1检查新提交是否包含notes/目录下的.md文件如果是自动触发obsidian-html生成静态站2检查 PR 的 title 是否包含[KB-UPDATE]如果是自动在 Gitee Issue 中创建一个knowledge-gap任务关联 PR。第四层Pages 发布配置在Settings Pages中Source 选Branch: mainFolder 选/docs。关键点是不要勾选“Build with Jekyll”。Jekyll 对中文支持差且编译慢。改用obsidian-html# 在本地安装 npm install -g obsidian-html # 生成配置 obsidian-html gen-config --vault /path/to/knowledge-base --output ./obsidian-html-config.yml # 修改配置指定输出目录为 /docs # 运行生成 obsidian-html compile -c obsidian-html-config.yml这样生成的/docs目录就是一个纯静态、SEO 友好、支持全文搜索的知识站。第五层License 选择网络热词里有“gitee开源许可证选什么”对于知识库我强烈推荐CC BY-NC-SA 4.0署名-非商业性使用-相同方式共享。它允许他人学习、引用你的知识但禁止商用且要求衍生作品必须采用相同许可。这比 MIT 或 Apache 更契合知识共享的精神也比 GPL 更宽松GPL 要求所有衍生作品开源而知识库的“衍生”很难界定。4. 实操工作流从信息摄入到知识产出的完整闭环4.1 信息摄入阶段公众号文章、PDF、会议录音的一键入库信息摄入是知识库的源头活水但手动复制粘贴是效率黑洞。我的解决方案是用浏览器插件 WorkBuddy Skill 构建零摩擦入口。首先在 Chrome 安装官方插件Obsidian Web Clipper。它的强大之处在于不仅能保存网页正文还能自动提取meta标签里的og:title、og:description、article:published_time并填充到 Obsidian 模板的 YAML frontmatter 中。但它的短板是无法处理 PDF。这时WorkBuddy 的pdf-clipSkill 就派上用场了。我为pdf-clipSkill 设计了双触发模式鼠标右键模式在 PDF.js 渲览器Chrome 默认 PDF 查看器中选中一段文字右键 →WorkBuddy: Clip to KB全局快捷键模式CmdShiftP自动捕获当前活动窗口的标题和剪贴板内容。Skill 的 YAML 配置核心是contextcontext: - type: pdf_text name: pdf_content max_pages: 3 # 只提取当前页及前后各一页避免 token 爆炸 - type: obsidian_notes query: source::{{pdf_url}} OR title::{{pdf_title}} # 先查重 limit: 1当 Skill 检测到obsidian_notes返回非空结果时它会自动进入“更新模式”而不是新建笔记。它会把新选中的文本追加到已有笔记的## Key Insights区域并在 YAML 中更新file.mtime。这解决了“同一篇文章被多次阅读产生多篇重复笔记”的顽疾。对于会议录音我用Whisper.cpp本地转录不上传云端生成.srt字幕文件然后用一个 Python 脚本把字幕按发言者切分成段每段生成一个.md笔记标题为Meeting-20240520-Product-Planning-{{speaker}}YAML 中source字段记录原始.srt文件路径。这个脚本会自动扫描assets/meetings/目录发现新文件就触发处理全程无人值守。4.2 知识加工阶段用 AI 主动发现连接而非手动打标签Obsidian 的手动打标签和双向链接是反人性的。我的实践是让 WorkBuddy 成为你的“知识连接器”每天自动运行一次发现隐藏关系。我创建了一个daily-link-finder的 Cron Job# 每天凌晨 2:00 执行 0 2 * * * cd /path/to/knowledge-base /usr/local/bin/workbuddy run --skill daily-link-finder --quiet /var/log/kb-link.log 21daily-link-finderSkill 的逻辑是用 Dataview 查询过去 7 天内status: draft的笔记对每篇笔记提取其tags和title中的名词短语用 spaCy 的中文模型在整个知识库中搜索tags或title包含这些名词短语且status: published的笔记计算语义相似度用 Sentence-BERT 的paraphrase-multilingual-MiniLM-L12-v2模型阈值设为 0.65如果找到相似度 0.65 的笔记则在 draft 笔记末尾自动生成[[Related: filename]]链接并在 YAML 中添加related_to: [filename1, filename2]。这个流程的效果惊人。上周我写了一篇关于“农业知识库构建”的 draft 笔记daily-link-finder自动发现了 3 篇旧笔记《领域知识图谱构建实践》《RAG 在垂直领域的挑战》《小模型微调的数据准备》并生成了精准链接。我点开一看果然都是相关主题而且其中一篇《RAG 在垂直领域的挑战》里有一段话直接预言了我 draft 中提到的“数据稀疏性问题”。这种跨时间、跨主题的连接是人脑无法持续维持的。4.3 知识输出阶段从个人笔记到团队可交付物的自动化转化知识库的价值最终要体现在可交付物上。我的输出工作流是用 Gitee Pages Obsidian HTML 自定义 CSS把笔记库变成团队知识站。obsidian-html的默认主题太简陋我做了三处关键定制搜索增强替换默认的 Lunr.js 搜索为flexsearch它支持中文分词和模糊匹配。在obsidian-html-config.yml中search: engine: flexsearch options: tokenize: full resolution: 9导航重构默认的侧边栏是文件树我把它换成 Dataview 生成的动态视图。在docs/index.html的head中加入script // 加载 Dataview 生成的 JSON 数据 fetch(/dataview.json).then(r r.json()).then(data { // 渲染为带图标和状态的卡片网格 }); /script权限隔离/docs下的public/目录存放所有人可见的文档/docs/internal/目录用 Nginx 的auth_basic保护只有团队成员能访问。Gitee Pages 会自动发布这两个目录无需额外配置。最关键的输出是“知识缺口报告”。每周一上午我运行一个脚本它会查询 Gitee Issues 中所有label: knowledge-gap的未关闭 Issue统计每个arealabel如area:backend,area:ml的数量生成一个 Markdown 报告用 Dataview 表格展示自动推送到docs/reports/weekly-gap-report.md触发 Gitee Pages 重新构建。这个报告就是我们团队周会的固定议程。它让知识建设从“个人爱好”变成了“团队 OKR”效果立竿见影。上个月我们根据报告集中补全了 12 篇关于“AI 测试开发”的笔记现在新入职的测试工程师入职第一周就能通过知识站独立完成 80% 的自动化测试脚本编写。5. 常见问题排查与独家避坑指南5.1 Obsidian 同步冲突当 Git 说“Your local changes would be overwritten”这是新手最常遇到的噩梦。现象是Obsidian Git 插件报错error: Your local changes to the following files would be overwritten by merge然后整个 vault 锁死。根本原因不是 Git 有问题而是 Obsidian 的“自动保存”和 Git 的“文件锁定”发生了竞态。正确解法非暴力 reset立即关闭 Obsidian在终端进入 vault 目录执行git status你会看到一堆modified: xxx.md执行git stash把所有未提交的修改暂存执行git pull --rebase拉取远程最新执行git stash pop把暂存的修改应用回来重新打开 Obsidian它会自动检测到文件变更提示你“Reload”最关键一步在 Obsidian 设置中关闭Core Plugin: Auto save改为手动CtrlS。Obsidian 的自动保存间隔是 3 秒而 Git 操作通常要 5~8 秒这个时间差就是冲突的根源。注意永远不要在 Obsidian 打开时执行git reset --hard。这会导致 Obsidian 的内部索引.obsidian/workspace与文件系统状态不一致轻则笔记预览错乱重则整个 vault 无法加载。5.2 WorkBuddy 响应迟缓当 AI 回答慢得像在思考人生WorkBuddy 卡顿90% 的情况不是模型慢而是上下文注入出了问题。我总结了三个必查点第一检查obsidian.vault_path配置是否指向正确的根目录。很多人把路径设成了/path/to/knowledge-base/.obsidian这是错误的。WorkBuddy 需要的是 vault 的根即/path/to/knowledge-base。如果路径错了它会遍历整个.obsidian目录里面有大量缓存文件导致obsidian_notescontext 加载超时。第二检查 Skill 的context查询是否过于宽泛。比如一个 Skill 的query是status: draft而你有 200 篇 draft 笔记WorkBuddy 就要把这 200 篇的全文都读入内存再交给模型。正确的做法是用limit: 5加上sort: file.mtime DESC只取最新的 5 篇。第三检查本地模型服务是否健康。在终端执行curl http://localhost:11434/api/tags如果返回{models:[]}说明 Ollama 没有加载模型。执行ollama run qwen2:7b等待它下载完成约 4.2GB再执行ollama list确认状态为loaded。5.3 Gitee Pages 构建失败当你的知识站变成 404Gitee Pages 构建失败最常见的原因是docs/目录下存在非法文件。Gitee Pages 的构建器会扫描docs/下所有文件如果遇到文件名包含..如../secret.txt文件权限不是644如755文件大小超过 10MB如一个未压缩的.png 构建就会静默失败页面显示 404。排查步骤在docs/目录下执行find . -name *.* -type f -size 10M删除所有超大文件执行find . -type f ! -perm 644 -exec chmod 644 {} \;统一文件权限执行find . -name *..* -delete清理非法文件名最后执行git add docs/ git commit -m fix: pages build constraints强制触发一次构建。实操心得我养成了一个习惯在每次obsidian-html compile后立即运行一个校验脚本它会自动执行上述 4 步并生成docs/_build-report.md记录本次构建的合规性。这个报告就是我的“知识站健康证明”。5.4 知识库“假活跃”为什么你写了 1000 篇笔记却感觉没用这是最隐蔽、也最致命的问题。现象是笔记数量暴涨但当你真正需要某个知识点时还是得 Google。根源在于笔记之间没有形成“认知网络”只有“信息孤岛”。我的诊断方法是用 Dataview 运行一个“连接度分析”TABLE length(outlinks) AS Outgoing, length(inlinks) AS Incoming, length(file.tags) AS Tags FROM notes WHERE length(outlinks) 0 AND length(inlinks) 0 SORT file.mtime DESC LIMIT 20这个查询会列出所有“零连接”的笔记。如果结果超过 15%说明你的知识库正在退化。我的修复策略是“三日连接行动”Day 1针对查询结果用 WorkBuddy 的link-suggestorSkill为每篇笔记生成 3 个[[Related: ]]链接Day 2打开 Obsidian 的 Graph View放大到 200%手动拖拽那些“离群”的笔记节点靠近它们语义相关的集群Day 3