企业官网建设流程全解析

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

先说结论：我用了大半年时间，把散落在微信收藏、浏览器书签、本地 Markdown 文件夹和各类笔记软件里的东西，全部收拢到一套以 Obsidian 为前端、WorkBuddy 为 AI 处理层、Gitee 为版本同步底座的个人知识库里。这套组合不是拍脑袋选的，是我试过七八种方案之后留下来的最稳解。

Obsidian 的核心价值在于本地优先。所有笔记都是纯 Markdown 文件，存在你自己的硬盘上，不依赖任何厂商的服务器。这意味着哪怕某天某个笔记软件倒闭了，你的数据还在，用记事本都能打开。这个特性对于要长期积累知识的人来说，是底线级别的安全感。

但光有 Obsidian 不够。它本身不具备 AI 能力，你往里塞了几百篇笔记之后，找起来、用起来、串起来全靠手动，效率会急剧下降。这时候就需要 WorkBuddy 这类 AI 工具介入，帮你做摘要、打标签、建立笔记之间的关联、甚至根据你的知识库内容回答问题。WorkBuddy 的定位是一个 AI 工作台，可以接入多种模型，支持自定义技能，能跟本地文件系统交互，这就让它天然适合跟 Obsidian 搭配。

最后一个环节是 Gitee。Obsidian 的笔记是纯文本，体积极小，天然适合用 Git 做版本管理。Gitee 作为国内的代码托管平台，访问速度快，私有仓库免费，拿来同步知识库再合适不过。你写完一篇笔记，commit 一下，push 到 Gitee，换台电脑 pull 下来就能继续写。版本历史清清楚楚，误删了也能找回来。

这套组合适合谁？适合那些已经有一定笔记积累、但觉得管理起来越来越吃力的人；适合对数据隐私有要求、不想把笔记全放在云端的人；也适合想用 AI 提升知识处理效率、但不想被某个平台绑死的人。如果你刚开始做笔记，这套方案同样适用，从一开始就建立好习惯，后面会省很多事。

2. 三件套各自的角色与选型逻辑

2.1 Obsidian 为什么是知识库前端的最优解

Obsidian 最打动我的一点是它的双链机制。你在笔记 A 里写 [[笔记 B]]，Obsidian 就会自动建立 A 到 B 的链接，同时在 B 的反向链接面板里显示 A。这个看似简单的功能，实际上改变了你组织知识的方式。传统文件夹是树状结构，一篇笔记只能放在一个文件夹里。但双链是网状结构，一篇笔记可以同时跟多个主题产生关联，更接近人脑的联想方式。

另外，Obsidian 的插件生态极其丰富。Dataview 插件可以让你用类 SQL 的语法查询笔记，比如列出所有未完成的待办事项、按标签聚合笔记、生成阅读清单。Templater 插件可以定义模板，新建笔记时自动填充日期、标题、标签等元数据。这些插件让 Obsidian 从一个简单的 Markdown 编辑器变成了一个可编程的知识管理平台。

还有一点容易被忽略：Obsidian 的文件结构就是文件夹和 Markdown 文件，没有任何私有格式。这意味着你可以用任何文本编辑器打开、用任何脚本处理、用任何工具同步。这种开放性是我选择它的根本原因。

2.2 WorkBuddy 在知识库中扮演什么角色

WorkBuddy 在这套组合里的定位是 AI 处理层。它不存储笔记，但能读取你的笔记文件，然后做各种智能处理。我主要用它做四件事：

第一是自动摘要。一篇几千字的长文，丢给 WorkBuddy，几秒钟就能生成一段两百字以内的摘要，我直接把这个摘要贴到笔记开头，以后回顾时一眼就能知道这篇讲什么。

第二是自动打标签。WorkBuddy 能根据笔记内容推荐标签，我确认后批量写入 frontmatter。这样后续用 Dataview 查询时，标签体系就是一致的，不会出现同一种内容打了不同标签的情况。

第三是知识关联。WorkBuddy 能分析两篇笔记的内容相似度，推荐可能相关的笔记，我手动确认后加上双链。这个功能帮我发现了很多自己都没意识到的知识连接。

第四是问答。把知识库目录挂载给 WorkBuddy，它就能基于你的笔记内容回答问题。比如我问“我之前记录的那个 Python 装饰器的用法是什么”，它会检索相关笔记并给出答案，还会附上来源笔记的链接。

WorkBuddy 支持自定义技能这一点很关键。你可以写一个技能，定义“读取指定目录下的所有 Markdown 文件，提取标题和摘要，生成一个索引页”。这种自动化能力是通用聊天机器人不具备的。

2.3 Gitee 做同步底座的几个实际考量

用 Gitee 而不是其他平台，主要基于三个原因。第一是访问速度，国内直接访问 Gitee 基本没有延迟，clone 和 push 都很快。第二是私有仓库免费，知识库这种东西肯定要放私有仓库，Gitee 在这方面没有限制。第三是操作简单，不需要复杂的配置，注册完就能用。

Git 做版本管理的好处，用过的人都知道。每次 commit 就是一个快照，你可以清楚地看到每篇笔记的修改历史。写错了想回退？git revert 就行。想看看三个月前某篇笔记长什么样？git log 找到对应的 commit，checkout 出来就行。这种安全感是网盘同步给不了的。

而且 Git 的分支功能可以用来做实验。比如你想大规模重构笔记结构，可以开一个分支慢慢改，改好了再合并回主分支。改废了直接删分支，主分支不受影响。

3. 从零搭建的完整实操流程

3.1 Obsidian 的安装与基础配置

Obsidian 的安装没什么好说的，官网下载对应系统的安装包，一路下一步就行。安装完成后，选择“创建新仓库”，指定一个本地文件夹作为仓库位置。这个文件夹就是你的知识库根目录，所有笔记都会存在这里。

我建议在仓库根目录下建立几个基础文件夹：00-Inbox放临时收集的内容，01-Notes放正式笔记，02-Projects放项目相关文档，03-Areas放长期关注的领域笔记，04-Archive放归档内容。这个结构参考了 PARA 方法，但不用死板照搬，根据自己的习惯调整就行。

接下来配置几个必装插件。在设置里找到“第三方插件”，关闭安全模式，然后浏览社区插件。我推荐先装这几个：

• Dataview：用查询语言动态生成笔记列表，比如自动列出所有未完成的待办。
• Templater：定义笔记模板，新建笔记时自动填充日期、标题等。
• Calendar：在侧边栏显示日历，点击日期就能创建当天的日记。
• Tag Wrangler：批量重命名、合并标签，维护标签体系时很有用。

装完插件后，在设置里配置一下模板文件夹和日记文件夹的路径。我习惯把模板放在99-Templates，日记放在00-Inbox/Daily。

3.2 WorkBuddy 的接入与技能配置

WorkBuddy 的安装根据你用的版本有所不同。我用的桌面版，下载安装包后直接安装，首次启动需要登录账号。登录后在设置里配置模型，可以选择接入不同的 AI 模型，我一般用默认的就行，响应速度和效果都够用。

关键的一步是配置工作目录。在 WorkBuddy 的设置里，把 Obsidian 仓库的根目录添加为工作目录。这样 WorkBuddy 就能读取和写入这个目录下的文件。注意要给它读写权限，否则只能读不能写。

然后配置技能。WorkBuddy 内置了一些常用技能，比如文件摘要、内容分类、关键词提取。我建议先试试内置技能，熟悉了之后再自定义。自定义技能的写法是写一个 Markdown 文件，定义技能名称、触发方式、输入输出格式和处理逻辑。比如我写了一个“生成笔记索引”的技能，逻辑是读取01-Notes目录下所有 Markdown 文件，提取标题和 frontmatter 里的摘要，生成一个按修改时间排序的索引页。

这里有个细节要注意：WorkBuddy 处理文件时，默认可能不会递归读取子目录。如果你的笔记分散在多层文件夹里，需要在技能配置里明确指定递归深度，或者用通配符匹配所有层级的文件。

3.3 Gitee 仓库的创建与本地关联

先在 Gitee 上注册账号，然后创建一个新仓库。仓库名称随意，比如my-knowledge-base。关键是要选“私有”，知识库内容不适合公开。初始化仓库时可以不勾选 README，因为我们要把本地已有的 Obsidian 仓库推上去。

创建完仓库后，Gitee 会显示仓库地址，格式是https://gitee.com/你的用户名/仓库名.git。复制这个地址。

回到本地，打开终端，进入 Obsidian 仓库根目录。执行以下命令：

git init git add . git commit -m "初始化知识库" git remote add origin https://gitee.com/你的用户名/仓库名.git git push -u origin master

如果推送时提示需要认证，输入 Gitee 的用户名和密码即可。但更推荐用 SSH 密钥，这样不用每次输入密码。生成 SSH 密钥的命令是ssh-keygen -t rsa -b 4096 -C "你的邮箱"，一路回车就行。然后把~/.ssh/id_rsa.pub文件的内容复制到 Gitee 的 SSH 公钥设置里。之后把 remote 地址改成 SSH 格式：git@gitee.com:你的用户名/仓库名.git。

3.4 三者的联动配置与自动化

三者各自配置好之后，需要把它们串起来。我的做法是写一个简单的脚本，每天定时执行。脚本做三件事：调用 WorkBuddy 处理当天新增的笔记，生成摘要和标签；用 Git 提交所有变更；推送到 Gitee。

在 Windows 上可以用任务计划程序，在 macOS 或 Linux 上可以用 cron。脚本内容大致如下：

#!/bin/bash # 进入知识库目录 cd /path/to/your/vault # 调用 WorkBuddy 处理新笔记 workbuddy process --dir ./00-Inbox --recursive --output-summary --output-tags # 提交变更 git add . git commit -m "自动同步 $(date +%Y-%m-%d)" # 推送到 Gitee git push origin master

WorkBuddy 的命令行调用方式需要参考它的文档，不同版本可能略有差异。如果它不支持命令行，也可以用它的 API 来触发处理流程。

这个脚本跑通之后，你每天只需要专注写笔记，剩下的摘要、标签、同步全部自动完成。我实测下来，这套流程每天处理几十篇笔记毫无压力，Git 仓库的体积增长也非常缓慢，因为纯文本的压缩率极高。

4. 实操中踩过的坑与解决方案

4.1 Obsidian 同步冲突的处理

用 Git 同步 Obsidian 仓库，最常遇到的问题就是冲突。比如你在电脑 A 上改了笔记，还没 push，又在电脑 B 上改了同一篇笔记并 push 了。等回到电脑 A 上 pull 时，Git 就会报冲突。

我的处理原则是：每次开始写笔记之前先 pull，写完笔记之后立刻 push。这样能把冲突概率降到最低。如果还是冲突了，Git 会在文件里插入冲突标记，你需要手动编辑文件，决定保留哪个版本。Obsidian 本身不处理冲突标记，但你可以用 VS Code 打开冲突文件，它的冲突解决界面更直观。

另一个坑是.obsidian文件夹。这个文件夹里存的是 Obsidian 的配置和插件，不同电脑上的配置可能不一样。如果把它也纳入 Git 管理，每次同步都会产生大量无意义的变更。我的做法是在.gitignore里加上.obsidian/workspace和.obsidian/cache，只跟踪插件列表和核心配置。

4.2 WorkBuddy 处理中文笔记的注意事项

WorkBuddy 处理中文内容时，偶尔会出现摘要不准确或者标签推荐不合理的情况。我分析下来，主要原因是笔记里中英文混排、专业术语多、或者有大量代码块。针对这些问题，我总结了几个技巧：

第一，在笔记的 frontmatter 里手动加一个summary字段，如果 WorkBuddy 生成的摘要不满意，就手动改掉。下次它处理时，会优先参考已有的 summary。

第二，对于技术笔记，在 frontmatter 里加tags字段，手动指定几个核心标签。WorkBuddy 会基于这些标签做扩展推荐，比完全从零开始推荐要准得多。

第三，如果笔记里有大段代码，建议用代码块包裹，并在代码块前面加一行注释说明这段代码的用途。WorkBuddy 能识别代码块，不会把代码内容当成正文来摘要。

4.3 Gitee 仓库体积增长的应对

虽然纯文本笔记体积很小，但如果你往仓库里放图片、PDF 附件，仓库体积会快速增长。Gitee 对单仓库有容量限制，超过之后 push 会失败。

我的解决方案是：图片和附件不放 Git 仓库，改用图床。Obsidian 有多个图床插件，比如Obsidian Image Auto Upload，可以配置为自动把粘贴的图片上传到图床，然后在笔记里插入图床链接。这样仓库里只有纯文本，体积增长极慢。

如果有些附件必须本地保存，比如 PDF 文献，我建议单独建一个文件夹，用 Gitee 的“发行版”功能来管理。发行版附件不计入仓库体积，但需要手动上传，适合不经常变动的文件。

还有一个技巧是定期清理 Git 历史。如果仓库里曾经提交过大文件，即使后来删除了，历史记录里仍然存在。可以用git filter-branch或者BFG Repo-Cleaner来清理历史，但这属于高级操作，操作前务必备份。

4.4 常见问题速查表

5. 进阶玩法：让知识库真正活起来

5.1 用 Dataview 做动态仪表盘

Obsidian 的 Dataview 插件可以把你的知识库变成一个动态数据库。我建了一个Dashboard.md文件，里面用 Dataview 查询语句生成了几个视图：

第一个视图是“最近修改的笔记”，列出最近七天内有修改的笔记，按修改时间倒序排列。这样我每天打开 Obsidian，第一眼就能看到最近在关注什么。

第二个视图是“未完成的待办”，扫描所有笔记里的- [ ]标记，汇总成一个待办列表。我写笔记时随手记的待办事项，都会自动出现在这里。

第三个视图是“按标签聚合”，把某个标签下的所有笔记列出来。比如我有个#project/知识库标签，所有跟这个项目相关的笔记都会聚合在一起。

Dataview 的查询语法不难，官方文档看半小时就能上手。关键是你要先规范笔记的 frontmatter，确保有tags、date、status这些字段，Dataview 才能正确查询。

5.2 用 WorkBuddy 做知识库问答

WorkBuddy 的知识库问答功能，本质上是一个 RAG（检索增强生成）流程。它先把你的笔记切分成小块，建立向量索引，然后当你提问时，先检索最相关的笔记片段，再把这些片段作为上下文交给 AI 生成答案。

要让这个流程效果好，有几个关键点。第一是笔记的切分粒度要合理，太长了检索不精准，太短了上下文不完整。我一般把笔记控制在 500 到 2000 字之间，超过就拆成多篇。第二是笔记的标题要清晰，WorkBuddy 在检索时会参考标题，标题写得好，检索准确率会高很多。第三是定期更新索引，每次批量修改笔记后，记得让 WorkBuddy 重建索引。

我实测下来，对于技术笔记和读书笔记，问答准确率能到八成以上。对于日记这种口语化、信息密度低的内容，效果会差一些，因为检索时容易匹配到无关的片段。

5.3 用 Git 分支做知识库实验

Git 的分支功能在知识库管理里被严重低估了。我经常用分支来做一些实验性的操作，比如：

• 想大规模调整文件夹结构？开一个restructure分支，改完之后对比一下，满意就合并，不满意就删掉。
• 想试试新的标签体系？开一个new-tags分支，跑一段时间，看看效果再决定是否合并。
• 想写一个系列文章？开一个series/xxx分支，写完再合并回主分支。

这种工作流的好处是，主分支始终保持稳定可用，实验性的改动不会影响日常使用。而且每个分支的提交历史都是独立的，你可以清楚地看到每次实验的完整过程。

5.4 移动端的使用方案

Obsidian 有移动端 App，但移动端跟 Git 的配合比较麻烦。我的方案是：移动端只用来快速记录，不做复杂编辑。在手机上装 Obsidian App，打开同一个仓库（通过同步工具把仓库同步到手机），随手记的内容放在00-Inbox文件夹里。回到电脑后再统一整理、打标签、提交到 Git。

同步工具的选择上，我试过几种方案。最简单的是用 Syncthing，在两台设备之间直接同步文件夹，不经过云端。配置稍微麻烦一点，但胜在免费且隐私性好。另一种方案是用坚果云，它支持 WebDAV，Obsidian 有对应的同步插件。这个方案配置简单，但免费版有流量限制。

不管用哪种同步方案，都要注意跟 Git 的配合。我的原则是：Git 只在电脑上操作，移动端只负责产生内容，不执行 Git 命令。这样可以避免移动端产生复杂的合并冲突。

6. 这套组合的边界与适用场景

6.1 什么情况下不适合这套方案

这套组合虽然强大，但也不是万能的。如果你符合以下情况，可能需要考虑其他方案：

第一，你完全不写 Markdown，习惯用富文本编辑器。Obsidian 虽然支持实时预览，但底层还是 Markdown，如果你对 Markdown 语法很抵触，用起来会很痛苦。

第二，你的笔记里有大量手写内容或复杂表格。Obsidian 对手写支持很弱，复杂表格在 Markdown 里也很难维护。这种情况可能 Notion 或 OneNote 更合适。

第三，你不想碰命令行。这套方案里 Git 操作需要用到命令行，虽然也有图形化工具，但总归要学一些基本概念。如果你完全不想学，那用网盘同步加单机笔记软件会更省心。

第四，你的知识库需要多人协作。Obsidian 加 Git 的协作体验并不好，冲突处理很麻烦。多人协作场景下，Notion 或飞书文档这类在线协作工具更合适。

6.2 这套方案的核心优势总结

反过来，如果你符合以下情况，这套方案会非常合适：

你需要长期积累知识，希望数据能保存几十年甚至更久。纯文本加 Git 的组合，是目前已知的最耐久的数字信息保存方案之一。

你对数据隐私有要求，不想把笔记内容交给任何云端服务。这套方案里，笔记始终存在你自己的硬盘上，Gitee 仓库也是私有的。

你想用 AI 提升知识处理效率，但不想被某个 AI 平台绑死。WorkBuddy 支持多种模型，你可以随时切换，笔记数据始终在你手里。

你愿意花一点时间学习工具的使用方法，换取长期的效率提升。这套方案的学习曲线不算陡峭，但确实需要一些投入。一旦跑通，后面的收益是持续的。

6.3 后续可以扩展的方向

这套组合搭好之后，还有很多可以扩展的方向。比如接入 Zotero 做文献管理，把文献笔记自动导入 Obsidian。比如用 Obsidian 的 Canvas 功能做可视化知识图谱。比如写更多的 WorkBuddy 技能，自动化处理特定类型的笔记。

我最近在尝试的一个方向是用 WorkBuddy 做专利相关的辅助分析。把专利文档导入知识库，让 WorkBuddy 提取技术要点、对比不同专利的差异、生成技术演进路线。这个场景对 AI 的理解能力要求比较高，目前还在调优阶段，但初步效果已经不错了。

另一个方向是用小模型做本地化的知识库问答。WorkBuddy 支持接入本地模型，如果你的电脑配置够好，可以跑一个 7B 或 13B 的模型，完全离线做问答。这样连 AI 服务的费用都省了，隐私性也更好。不过本地模型的效果跟云端大模型还有差距，适合对隐私要求极高、对效果要求不那么极致的场景。

我个人在实际操作中的体会是，这套组合最大的价值不在于某个单一工具多强大，而在于它们之间的配合产生的化学反应。Obsidian 提供结构化的存储，WorkBuddy 提供智能化的处理，Gitee 提供可靠的版本管理。三者各司其职，又无缝衔接，形成了一个完整的知识管理闭环。你不需要一开始就把所有功能都用上，可以先从 Obsidian 加 Gitee 开始，跑顺了再接入 WorkBuddy。循序渐进，每一步都扎实，最后得到的才是一个真正能用、好用、长期可用的个人知识库。