企业官网建设流程全解析

1. 为什么我要折腾这套组合拳

1.1 从"笔记坟场"说起

我用了差不多五年的笔记软件，从最早的印象笔记到后来的语雀、飞书文档，再到Notion，几乎每一款都深度用过至少半年。但说实话，大部分人的笔记最后都变成了"坟场"——记的时候很爽，找的时候找不到，用的时候想不起来。我自己也不例外，最多的时候有三千多条笔记散落在四五个平台里，真正能被我二次调用的可能不到百分之五。

这个问题的本质不是"记不记"，而是"知识有没有被激活"。传统笔记软件的问题在于，它们是"存储导向"的，你写进去的东西就是死的，除非你主动去翻。而AI时代最大的机会，就是让知识库从"静态仓库"变成"动态助手"——你问它，它能答；你写东西，它能补；你整理，它能帮你归类。

我最终选定的方案是Obsidian + WorkBuddy + Gitee这个三联组合。Obsidian负责本地知识库的存储和双链管理，WorkBuddy负责AI能力的接入和自动化处理，Gitee负责版本管理和多端同步。三个工具各司其职，组合起来就是一个完全属于自己、不依赖任何平台、还能被AI驱动的个人知识库。

1.2 这套组合到底解决了什么问题

先说清楚这套方案适合谁。如果你是以下几类人，这套组合会非常合适：

• 笔记量大但利用率低的人：有几百上千条笔记，但基本不回看，需要AI帮你激活
• 对数据隐私有要求的人：不想把笔记放在别人的服务器上，希望本地存储
• 多设备用户：办公室电脑、家里台式机、笔记本、手机都要能访问
• 喜欢折腾的技术人：愿意花一两个小时配置，换来长期的生产力提升

它解决的核心问题有三个。第一是数据主权，所有笔记以Markdown纯文本存在本地，就算哪天Obsidian倒闭了，你的笔记照样能用任何编辑器打开。第二是AI激活，通过WorkBuddy把大模型能力接进来，让知识库能问答、能总结、能自动打标签。第三是版本可控，用Gitee做Git仓库，每次改动都有记录，误删了能回滚，多设备冲突能合并。

我实测下来，这套方案配置一次大概需要一到两个小时，之后基本就是"无感使用"——你只管写，同步和AI处理都在后台自动完成。

1.3 三个工具的分工逻辑

很多人会问，为什么不用Notion AI或者飞书知识库这种"一体化"方案？原因很简单：一体化方案意味着你把所有鸡蛋放在一个篮子里，平台改政策、涨价、甚至关停，你都无能为力。而且一体化方案的AI能力往往是"通用型"的，没法针对你的个人知识做深度定制。

三联组合的分工是这样的：

Obsidian的强项是"本地优先+插件生态"，它的双链和标签系统是目前笔记软件里最灵活的。WorkBuddy的强项是"工作流编排"，你可以把"读取笔记→调用大模型→写回笔记"这一整套流程做成自动化。Gitee的强项是"国内访问稳定+免费私有仓库"，对于不想折腾网络环境的用户来说是最省心的选择。

提示：这三个工具都是可以独立使用的，组合起来是"1+1+1>3"的效果。如果你只想先试试水，建议从Obsidian开始，用顺了再加AI和同步。

2. 环境准备与工具选型细节

2.1 Obsidian 的安装与初始配置

Obsidian的下载很直接，官网就能拿到各平台安装包。Windows用户建议下载exe安装版而不是便携版，因为安装版会自动注册系统级的文件关联，双击md文件就能直接打开。Mac用户注意区分Intel和Apple Silicon版本，M系列芯片一定要下arm64版本，否则会通过Rosetta转译运行，插件加载速度会明显变慢。

安装完成后第一件事是创建仓库（Vault）。这里有个关键决策：仓库放在哪里？我的建议是放在一个路径中不含中文和空格的目录下，比如D:\KnowledgeBase或者~/Documents/kb。原因后面讲Gitee同步的时候会说到，Git对中文路径的处理在某些场景下会出问题，提前避开能省很多麻烦。

初始配置我建议做这几件事：

1. 关闭安全模式：设置→第三方插件→关闭安全模式，这样才能装社区插件
2. 开启核心插件：把"标签面板""大纲""反向链接""日记"这几个核心插件打开
3. 设置附件目录：设置→文件与链接→附件默认位置，改成"在指定文件夹中"，路径填attachments，这样图片和附件不会和笔记混在一起
4. 开启Wiki链接：设置→文件与链接→使用Wiki链接，打开后[[笔记名]]这种写法才能生效

关于主题，热词里提到的Anuppuccin确实是个很漂亮的主题，但安装失败通常是因为网络问题或者Obsidian版本不匹配。我的建议是先用默认主题把功能跑通，主题这种东西属于"锦上添花"，不影响核心使用。

2.2 WorkBuddy 的部署方式选择

WorkBuddy的部署有两种方式：本地部署和云端部署。本地部署适合对数据隐私要求极高的用户，所有AI调用都在自己机器上完成，但需要一定的硬件配置（至少16G内存，最好有独立显卡）。云端部署则更省事，配置简单，但需要把笔记内容发送到云端处理。

我个人的选择是混合模式：敏感笔记用本地模型处理，普通笔记用云端API。WorkBuddy支持配置多个模型源，你可以在工作流里根据笔记的标签或者目录来决定用哪个模型。

安装WorkBuddy的时候有几个坑要注意：

• 缓存目录：默认缓存目录在C盘，如果你的C盘空间紧张，一定要在设置里改成其他盘。我见过有人因为缓存把C盘塞满导致系统卡死的。
• 端口占用：WorkBuddy默认占用几个端口，如果和你机器上其他服务冲突，需要在配置文件里改。常见的冲突是3000端口（很多前端开发工具默认用这个）。
• 国际版和国内版：如果你主要用国内的模型API，装国内版就行；如果需要调用一些国外的模型，国际版的兼容性更好。两个版本可以共存，但要注意端口不要冲突。

2.3 Gitee 仓库的创建与密钥配置

Gitee的注册很简单，重点说仓库创建和密钥配置。

创建仓库的时候，一定要选私有仓库。知识库这种东西包含大量个人信息，公开仓库等于把自己的笔记摊开给所有人看。Gitee的私有仓库对个人用户是免费的，容量也够用。

仓库创建后，关键是配置SSH密钥。很多人图省事用HTTPS方式，每次push都要输密码，非常烦。SSH密钥配置一次，之后就是无感的。

配置步骤：

# 1. 生成密钥对（如果已有可以跳过） ssh-keygen -t ed25519 -C "your_email@example.com" # 2. 查看公钥内容 cat ~/.ssh/id_ed25519.pub # 3. 复制输出的内容，粘贴到 Gitee 的 SSH 公钥设置页面

Windows用户注意，密钥文件在C:\Users\你的用户名\.ssh\目录下。如果这个目录不存在，说明你还没生成过密钥，需要先执行上面的生成命令。

配置完成后测试连接：

ssh -T git@gitee.com

看到欢迎信息就说明配置成功了。如果提示权限拒绝，检查一下公钥有没有正确粘贴，以及Gitee账户有没有绑定邮箱。

注意：SSH密钥是绑定设备的，如果你在多台电脑上使用，每台电脑都需要生成自己的密钥并添加到Gitee。不要图省事把同一份密钥复制到多台机器，这样一旦某台机器泄露，所有设备都不安全。

3. 核心架构设计与数据流拆解

3.1 整体数据流向

这套系统的数据流可以概括为"本地写入→AI处理→Git同步"三个环节。理解这个流向很重要，因为它决定了你遇到问题时该从哪里排查。

写入环节：你在Obsidian里写笔记，笔记以md文件形式存在本地仓库目录。这个环节完全离线，不依赖任何网络。

处理环节：WorkBuddy监听仓库目录的变化，当检测到新笔记或者笔记修改时，触发预设的工作流。工作流可能包括：自动打标签、生成摘要、提取关键概念、建立双链建议等。处理结果写回笔记的frontmatter或者追加到笔记末尾。

同步环节：Gitee作为远程仓库，通过Git的push/pull实现多端同步。你可以设置定时自动同步，也可以手动触发。同步的内容包括笔记本身和Obsidian的配置文件（插件配置、主题设置等）。

这个架构的关键设计点是处理环节和同步环节解耦。也就是说，AI处理失败不影响同步，同步失败也不影响AI处理。这样任何一个环节出问题，都不会导致整个系统瘫痪。

3.2 目录结构设计

目录结构是知识库的骨架，设计得好，后期维护成本极低；设计得差，笔记一多就乱成一锅粥。我踩过几次坑之后，总结出这套结构：

KnowledgeBase/ ├── 00-Inbox/ # 收集箱，所有新笔记先放这里 ├── 10-Notes/ # 永久笔记，经过整理的知识 ├── 20-Projects/ # 项目相关笔记 ├── 30-Areas/ # 领域知识，长期维护 ├── 40-Archive/ # 归档，不再活跃的笔记 ├── 90-Templates/ # 模板文件 ├── 99-Attachments/ # 附件（图片、PDF等） └── .obsidian/ # Obsidian 配置目录

这个结构借鉴了PARA方法（Projects、Areas、Resources、Archives），但做了简化。数字前缀是为了让文件夹在文件管理器里按顺序排列，视觉上更清晰。

Inbox机制是这套结构的关键。你写任何新笔记，第一站都是Inbox，不要纠结放哪里。等周末整理的时候，再决定这条笔记是变成永久笔记、归入某个项目、还是直接删掉。这个机制能极大降低"记录时的心理负担"，让你更愿意写。

3.3 AI 处理工作流的设计原则

WorkBuddy的工作流设计有几个原则，我按重要性排序：

原则一：AI只做建议，不做决策。比如自动打标签，AI给出建议标签，但最终是否采纳由你决定。我见过有人让AI全自动整理笔记，结果标签体系越来越乱，最后完全没法用。

原则二：处理结果可追溯。AI对笔记做的任何修改，都要在笔记里留下记录，比如在frontmatter里加一个ai_processed: 2024-01-15字段。这样你回看笔记时，知道哪些内容是AI加的，哪些是自己写的。

原则三：批量处理要限流。如果你有几千条笔记，不要让AI一次性全部处理，那样既费钱又容易出错。建议按目录分批处理，每次处理50-100条，处理完检查一下效果再继续。

原则四：保留原始版本。AI处理前，先让Gitee做一次commit，这样如果AI处理结果不理想，可以随时回滚。

3.4 多端同步的冲突处理策略

多端同步是这套系统里最容易出问题的环节。核心矛盾是：你在A设备改了笔记，还没同步，又在B设备改了同一条笔记，两边一同步就冲突了。

我的策略是**"单写多读"**：同一时间只在一台设备上写笔记，其他设备只读。具体做法是，主力写作设备（比如办公室电脑）开启自动同步，其他设备（手机、平板）只做查看，需要编辑时先手动pull一次。

如果确实需要多设备同时写，那就要接受偶尔的冲突。Git处理冲突的方式是生成冲突标记，你需要手动解决。Obsidian本身没有内置的冲突解决界面，所以冲突多了会很烦。我的建议是配合Obsidian Git插件，设置成"启动时自动pull，关闭时自动push"，能减少大部分冲突。

4. 实操过程与关键环节实现

4.1 Obsidian 仓库初始化实操

假设你已经装好了Obsidian，现在从零开始建仓库。

第一步，打开Obsidian，点击"创建新仓库"，仓库名称填KnowledgeBase，位置选D:\KnowledgeBase（Windows）或~/KnowledgeBase（Mac/Linux）。创建完成后，Obsidian会自动生成.obsidian配置目录。

第二步，按3.2节的目录结构创建文件夹。你可以手动创建，也可以在Obsidian里用命令面板（Ctrl+P）输入"新建文件夹"逐个创建。我建议手动在文件管理器里创建，更快。

第三步，安装必备插件。打开设置→第三方插件→浏览，搜索并安装以下插件：

• Obsidian Git：Git同步的核心插件
• Dataview：用类SQL语法查询笔记，做知识库仪表盘
• Templater：高级模板功能，比核心模板插件强很多
• Tag Wrangler：标签管理，批量重命名标签
• Advanced Tables：表格编辑增强

安装完插件后，每个插件都需要在设置里单独配置。Obsidian Git的配置后面会详细讲，其他插件用默认配置就能跑。

第四步，创建模板文件。在90-Templates目录下创建note-template.md，内容如下：

--- created: {{date:YYYY-MM-DD}} tags: [] status: inbox ai_processed: --- # {{title}} ## 核心内容 ## 相关链接

这个模板会在你新建笔记时自动填充日期和标题，status: inbox标记这条笔记还在收集箱里，ai_processed留空表示还没被AI处理过。

4.2 Gitee 仓库关联与首次推送

仓库初始化完成后，接下来把它和Gitee关联起来。

第一步，在Gitee上创建私有仓库，仓库名建议和本地一致，叫KnowledgeBase。创建时不要勾选"使用Readme初始化仓库"，因为我们要推送本地已有的内容，远程仓库如果有初始文件会导致冲突。

第二步，在本地仓库目录打开终端（Windows用Git Bash，Mac用Terminal），执行：

cd /d/KnowledgeBase # Windows # 或 cd ~/KnowledgeBase # Mac/Linux git init git add . git commit -m "初始化知识库" git remote add origin git@gitee.com:你的用户名/KnowledgeBase.git git push -u origin master

如果Gitee默认分支是main而不是master，把最后一行改成git push -u origin main。

第三步，配置Obsidian Git插件。打开插件设置，关键配置项：

• Auto backup：开启，间隔设为10分钟
• Auto backup after file change：开启
• Auto pull on boot：开启
• Pull before push：开启
• Commit message：vault backup: {{date}}

这样配置后，Obsidian每10分钟自动commit一次，启动时自动pull，关闭时自动push。日常使用基本不用管Git。

注意：首次push可能会因为仓库里有大文件（比如附件目录里的图片）而失败。Gitee对单文件大小有限制，超过100M的文件会被拒绝。如果你的附件目录很大，建议在.gitignore里排除掉，或者用Git LFS。

4.3 WorkBuddy 工作流配置详解

WorkBuddy的核心是工作流（Workflow），一个工作流由多个节点组成，节点之间用连线表示数据流向。我配置了三个核心工作流，分别对应不同的使用场景。

工作流一：新笔记自动处理

触发条件：Inbox目录下有新文件创建。

节点流程：

1. 文件监听节点：监听00-Inbox目录
2. 读取文件节点：读取新笔记的完整内容
3. 大模型节点：调用大模型，提示词如下：

你是一个知识管理助手。请阅读以下笔记内容，完成三件事： 1. 生成一句话摘要（不超过50字） 2. 建议3-5个标签（用英文，小写，连字符分隔） 3. 提取笔记中提到的关键概念（如果有的话） 笔记内容： {{content}} 请以JSON格式输出，字段为：summary, tags, concepts

4. 解析JSON节点：解析大模型返回的结果
5. 更新frontmatter节点：把摘要、标签、概念写回笔记的frontmatter

这个工作流跑通后，你写完笔记保存，几秒钟后frontmatter里就会自动出现摘要和标签。

工作流二：知识库问答

触发条件：手动触发（在WorkBuddy界面输入问题）。

节点流程：

1. 输入节点：接收用户问题
2. 向量检索节点：在知识库中检索相关笔记（需要先建立向量索引）
3. 大模型节点：把检索到的笔记作为上下文，让大模型回答问题
4. 输出节点：返回答案

这个工作流的关键是向量检索。WorkBuddy支持多种向量数据库，我推荐用本地的ChromaDB，配置简单，不需要额外部署服务。建立索引的时候，建议按目录分批建立，不要一次性索引整个仓库。

工作流三：定期知识整理

触发条件：定时触发（每周日晚上）。

节点流程：

1. 查询节点：查询所有status: inbox的笔记
2. 大模型节点：让大模型分析这些笔记，给出归类建议
3. 输出节点：生成一份整理报告，保存到00-Inbox/整理报告-{{date}}.md

这个工作流帮你做"周回顾"，把收集箱里的笔记过一遍，决定哪些该归档、哪些该删除、哪些该进一步加工。

4.4 向量索引的建立与更新

向量索引是AI问答的基础。没有索引，大模型只能靠"猜"来回答你的问题；有了索引，大模型能基于你的实际笔记内容来回答。

建立索引的步骤：

第一步，在WorkBuddy里配置向量数据库。选择ChromaDB，数据目录设为D:\KnowledgeBase\.vectorstore（注意这个目录要加到.gitignore里，不要同步到Gitee）。

第二步，配置嵌入模型。嵌入模型负责把文本转成向量，我推荐用bge-small-zh这个模型，体积小、速度快、中文效果好。如果你有GPU，可以用bge-large-zh，效果更好但更吃资源。

第三步，执行索引建立。在WorkBuddy里选择"建立索引"，选择要索引的目录（建议先索引10-Notes和30-Areas），点击开始。索引过程会遍历目录下所有md文件，分块、向量化、存入数据库。

索引建立的时间取决于笔记数量和硬件配置。我实测下来，1000条笔记用CPU大概需要10-15分钟，用GPU大概2-3分钟。

第四步，配置增量更新。索引不需要每次全量重建，WorkBuddy支持增量更新。配置一个定时任务，每天凌晨跑一次，只索引新增和修改过的笔记。

提示：向量索引的质量很大程度上取决于分块策略。默认的分块是按固定字数切分，但更好的做法是按语义切分——比如按标题层级切分，每个二级标题下的内容作为一个块。WorkBuddy支持自定义分块规则，建议花点时间调一下。

5. 常见问题与排查技巧实录

5.1 同步类问题排查

问题一：push被拒绝，提示"non-fast-forward"

这是最常见的问题，原因是远程仓库有你本地没有的提交。解决方法：

git pull --rebase origin master git push origin master

--rebase参数的作用是把你的本地提交"挪"到远程提交之后，避免产生合并提交。如果pull的时候有冲突，需要手动解决冲突后再继续。

问题二：Obsidian Git插件不自动同步

排查顺序：

1. 检查插件是否启用（设置→第三方插件→已安装插件）
2. 检查自动备份间隔是否设置（默认可能是关闭的）
3. 检查是否有未解决的冲突（打开终端执行git status）
4. 检查SSH密钥是否有效（执行ssh -T git@gitee.com）

我遇到过一次插件不工作的情况，最后发现是仓库路径里有中文，Git命令执行失败。改成纯英文路径后就正常了。

问题三：多设备同步后笔记内容错乱

这通常是冲突没有正确解决导致的。Git在冲突时会生成这样的标记：

<<<<<<< HEAD 你本地的内容 ======= 远程的内容 >>>>>>> origin/master

你需要手动编辑文件，决定保留哪部分，然后删除这些标记，再commit。如果冲突文件很多，建议用VS Code打开仓库目录，它的Git集成界面能可视化解决冲突。

5.2 AI 处理类问题排查

问题一：大模型返回格式不对，JSON解析失败

大模型有时候会"自由发挥"，返回的JSON格式不标准。解决方法是在提示词里加一句"只输出JSON，不要有任何其他文字"，并且在WorkBuddy的解析节点里开启"容错模式"，能自动修正常见的JSON格式错误。

问题二：AI处理速度慢

影响因素有三个：模型选择、笔记长度、并发数。如果用的是云端API，换一个更快的模型（比如从GPT-4换成GPT-3.5）；如果笔记很长，先做摘要再处理；如果并发数设置太高，降低一点，避免触发API限流。

问题三：AI打的标签不符合预期

这是提示词的问题。我一开始的提示词只说"建议标签"，结果AI给了一堆很泛的标签（比如"知识""学习"）。后来改成"建议3-5个具体、有区分度的标签，避免使用过于宽泛的词汇"，效果就好多了。提示词工程是个迭代的过程，需要根据实际效果不断调整。

5.3 性能与存储类问题

问题一：Obsidian打开慢

原因通常是插件太多或者笔记太多。解决方法：

• 禁用不常用的插件
• 关闭"显示反向链接"等实时计算功能
• 如果笔记超过5000条，考虑拆分仓库

问题二：Gitee仓库容量不够

Gitee免费私有仓库有容量限制，如果附件太多容易超。解决方法：

• 在.gitignore里排除附件目录
• 用图床替代本地图片（比如PicGo+SM.MS）
• 定期清理历史提交（用git gc或者重建仓库）

问题三：向量索引占用空间大

向量索引的大小和笔记数量成正比。如果空间紧张，可以：

• 只索引核心目录，不索引Inbox和Archive
• 用更小的嵌入模型
• 定期重建索引，删除过期数据

5.4 常见问题速查表

5.5 我踩过的几个坑

第一个坑是过早引入AI。我一开始就把AI处理接入了所有笔记，结果标签体系被AI搞得乱七八糟，花了两周才清理干净。后来改成只对Inbox里的新笔记做AI处理，整理后再归入正式目录，问题就解决了。

第二个坑是忽略.gitignore。我一开始没配置.gitignore，把.obsidian/workspace这种临时文件也同步了，导致每次切换设备都要重新调整界面布局。后来在.gitignore里加了：

.obsidian/workspace .obsidian/workspace.json .vectorstore/ .trash/

第三个坑是用同一个模型处理所有任务。摘要、打标签、问答，这三个任务对模型的要求不一样。摘要需要概括能力强的，打标签需要分类能力强的，问答需要推理能力强的。后来我在WorkBuddy里配置了多个模型，按任务类型路由，效果明显提升。

6. 进阶玩法与扩展方向

6.1 用 Dataview 做知识库仪表盘

Dataview是Obsidian最强大的插件之一，它能让你用类SQL的语法查询笔记。我建了一个Dashboard.md文件，放在仓库根目录，内容如下：

# 知识库仪表盘 ## 收集箱待处理 ```dataview TABLE created, summary FROM "00-Inbox" WHERE status = "inbox" SORT created DESC

最近修改的笔记

TABLE file.mtime as "修改时间" FROM "10-Notes" SORT file.mtime DESC LIMIT 10

标签统计

TABLE length(rows) as "数量" FROM "10-Notes" FLATTEN file.tags as tag GROUP BY tag SORT length(rows) DESC

这个仪表盘让你一眼看到知识库的状态：有多少笔记待处理、最近改了什么、标签分布如何。配合Obsidian的"固定标签页"功能，可以把它常驻在侧边栏。 ### 6.2 多AI协作的配置思路 热词里提到了"多AI协作"，这在WorkBuddy里是可以实现的。核心思路是让不同的模型负责不同的环节，形成"流水线"。 比如处理一条新笔记： 1. 用快速模型（如GPT-3.5）做初步分类 2. 用强模型（如GPT-4）做深度摘要和概念提取 3. 用嵌入模型做向量化 4. 用另一个模型做质量检查 这样配置的好处是成本和效果的平衡——简单任务用便宜模型，复杂任务用贵模型。WorkBuddy的工作流支持条件分支，可以根据笔记的长度、标签等条件决定走哪条路径。 ### 6.3 知识库的长期维护策略 知识库不是建好就完事了，它需要持续维护。我的维护策略是"日清周结月回顾"： **日清**：每天花5分钟，把Inbox里的笔记快速过一遍，能归类的归类，能删的删。 **周结**：每周日花30分钟，跑一次"定期知识整理"工作流，处理本周积累的笔记，更新仪表盘。 **月回顾**：每月最后一天，做一次全库检查——删除过时笔记、合并重复笔记、重构标签体系、重建向量索引。 这套维护策略听起来麻烦，但实际执行下来，每天5分钟、每周30分钟、每月1小时，总投入并不大。关键是养成习惯，让知识库保持"活"的状态。 ### 6.4 从个人知识库到团队知识库 如果你想把个人知识库扩展成团队知识库，这套架构也能支撑，但需要做一些调整： - **Gitee仓库改为团队仓库**：添加团队成员为开发者，设置分支保护规则 - **目录结构增加协作区**：比如加一个 `50-Team` 目录，存放团队共享的笔记 - **AI处理增加权限控制**：不同成员看到的AI处理结果可能不同 - **同步策略改为分支模式**：每个人在自己的分支上工作，定期合并到主分支 不过说实话，团队知识库用这套方案会比较折腾，Git的冲突处理对非技术成员不友好。如果团队规模超过5人，建议考虑更专业的协作平台。 ### 6.5 数据备份的兜底方案 最后说一个很多人忽略的问题：备份。Gitee虽然可靠，但不能把备份完全寄托在它身上。我的做法是"三副本"： - **本地副本**：Obsidian仓库本身 - **远程副本**：Gitee仓库 - **离线副本**：每月一次，把整个仓库打包压缩，存到移动硬盘 离线副本是最重要的兜底。我见过有人因为误操作把远程仓库清空了，本地又刚好重装了系统，结果几年的笔记全没了。这种悲剧完全可以避免，一个月花5分钟做个离线备份，成本极低。 我个人在实际操作中的体会是，这套组合最大的价值不是"AI有多强"，而是"数据完全属于自己"。你可以随时换掉AI模型、换掉同步方案，但笔记本身永远是纯文本，永远能被任何工具读取。这种"数据主权"带来的安全感，是任何一体化平台都给不了的。 最后再分享一个小技巧：如果你觉得配置太复杂，可以先只做Obsidian+Gitee的同步，把AI部分放一放。等笔记积累到一定量、真正感受到"找不到东西"的痛点了，再引入WorkBuddy做AI处理。工具是为人服务的，不要为了用工具而用工具。