企业官网建设流程全解析

先抛个结论：我用 Obsidian 记了快 2000 条笔记后才发现，真正让知识库“活”起来的不是笔记软件本身，而是背后那条链路。一条链路里，要有一个人负责存储和整理，一个 AI 负责理解和生成，一个远端仓库负责同步和备份。落到具体工具上，就是 Obsidian + WorkBuddy + Gitee 这套三联组合。

这套组合解决的三个问题很具体：第一，笔记永远以本地 Markdown 文件存在，可控、可迁移、不依赖任何在线服务的续费；第二，知识库不再是你单向查看的旧文本，而是能随时被 AI 检索、问答、总结、成文的新资产；第三，Gitee 作为私有远端仓库，让多设备同步变成标准 Git 操作，任何一台电脑出问题，笔记都不会消失。

这篇文章不讲虚的，直接从我实际跑的这套体系出发，把选型思路、目录规划、密钥配置、自动同步、AI 接入、排障经验全部拆开讲。适合已经有 Obsidian 基础、想把 AI 能力真正用起来、又对数据安全比较在意的朋友。

1. 为什么是这三件套：定位与选型逻辑

1.1 Obsidian 当底座，不是因为它好看，而是因为它“不过期”

笔记类工具我用过非常多，从系统自带备忘录到各类云笔记，最后都停了。原因很一致：文件格式封闭、导出麻烦、速度越来越慢、厂商策略不确定。Obsidian 让我放心的是它把一切建立在纯文本 Markdown 上，你的库本质上就是一个本地文件夹，里面躺着一个个 .md 文件。

这点对 AI 时代非常关键。WorkBuddy 这类工具能直接读取本地纯文本文件，不需要经过云端同步中转。你可以想象，如果你的笔记都在一个私有云数据库里，AI 要取数据就得先过一层 API，权限和隐私都不可控；但本地 Markdown 文件可以直接被程序读取、索引和检索。我甚至做过一个极端测试：把 Obsidian 的文件夹直接打包放到另一台电脑上，解压打开，所有笔记、链接、标签全部原样出现。这种“不过期”的底层特性，让我敢把上千条笔记继续往里堆。

Obsidian 的双向链接和标签系统也十分关键。单纯给笔记建文件夹，本质上还是传统文件柜思维，知识之间很难产生关联。而在 Obsidian 里，每条笔记可以通过 [[]] 语法指向另一条笔记，比如你写了一条关于“RAG 召回机制”的笔记，再写一条“个人知识库设计”时，直接用链接把它们串起来，知识图谱里就会出现一条边。AI 在读取这些文件时，也能顺着链接找到上下文，回答问题时精度明显更高。

1.2 WorkBuddy 不是花瓶，它把“死笔记”变成“活知识”

很多人对大模型工具的印象还停留在网页聊天框：把文字复制进去，问一句，得到一段回答。但个人知识库场景里，最大的痛点是上下文太分散，你总不能把 2000 条笔记一次性塞进对话框。WorkBuddy 这类 AI 工作台工具解决的就是这个问题：它允许你把一个本地项目或笔记文件夹作为工作区加载，AI 能直接读取其中的文件内容，并基于这些内容和你对话。

我当时搭这套体系时，最直接的使用场景有三个。第一，问答式检索：不再用关键词在 Obsidian 的搜索框里翻半天，而是直接用大白话问“我之前整理过哪些关于任务管理的方法论”，它会先搜索库内相关文件，再把答案组织出来，附带出处。第二，内容生成：周报、月度总结、读书笔记、项目复盘，它可以根据我的笔记记录自动起草。第三，Skill 工作流：把固定动作固化成技能，比如“weekly-report”这个 Skill，每次我只要触发它，它就会自动扫描本周日记，按模板生成一份周报草案。

我举个具体例子。以前我每个月末写总结，至少要花一个半小时翻日记、翻工作记录、回忆项目进展。现在我把写总结的规范，包括覆盖维度、引用格式、输出长度，全部写进一个 Skill 里。每次月末，我只需要让 WorkBuddy 运行这个 Skill，它会把一个月内的相关笔记先扫一遍，然后按规范生成初稿。我再花十五分钟改改重点和措辞就够了。这就是 AI 在知识库体系里真正的价值：不是替你想，而是把检索、归纳、起草这些体力活全部替你干了。

1.3 Gitee 在这一环里承担什么，为什么我用它不用别的

在选定 Gitee 之前，我尝试过把 Obsidian 库放到网盘里同步，也试过官方付费同步服务。网盘的问题在于，文件锁和版本冲突几乎无解，笔记本端的同步目录偶尔还会出现幽灵冲突文件。官方同步服务体验确实顺滑，但对本地文件依赖强、价格也不便宜，而且要额外考虑数据留在哪里的问题。综合下来，我最终选择了 Gitee 作为远端仓库，本质上就是把知识库当作一个代码仓库来管理。

选择 Gitee 而不是其他境外平台，最直接的原因是速度和可用性。知识库的同步频次虽然不高，但每次 push 和 pull 都希望干脆利落。Gitee 在国内服务器上，命令行操作时几乎没有等待感，这对日常维护体验很重要。另外，Gitee 个人空间的私有仓库是免费的，对个人知识库这种规模完全够用。虽然协作人数有限制，但我的场景就是自己多台设备之间同步，不是团队协作，所以没有影响。

Git 作为同步协议还有一个网盘给不了的优势：版本历史。每一次提交都意味着某个时间点的完整快照。比如我某次重构笔记目录，原来整理了三天，结果发现新分类方式不好用，想回退。网盘系统基本没法做到这种程度的历史回滚，但 Git 一条命令就解决了。Gitee 在这里充当的角色其实就是“远程保险柜”，我本地一份，远端一份，永远不会出现“电脑坏了，笔记全没了”的情况。

2. 搭建之前，先把这四件事定下来

2.1 仓库结构：先“分类”还是先“链接”

很多人搭建知识库的第一步是建一堆文件夹：生活、工作、学习、项目、灵感……结果不到半年，目录结构就乱了，同一个主题的知识被拆到多个地方，笔记越来越多，但查找效率越来越低。我的建议是放弃复杂的目录分类，用一个足够简单、带临时入口的结构。

我在 Obsidian 里的目录结构是下面这样：

your-vault/ ├── 00_inbox/ # 临时收件箱，快速记录 ├── 01_notes/ # 常驻笔记，按主题写，不建子文件夹 ├── 02_daily/ # 日记，按日期命名 ├── 03_projects/ # 项目相关，一个项目一个文件夹 ├── 04_assets/ # 图片、PDF 等附件 ├── 05_archive/ # 归档的旧笔记 └── .obsidian/ # Obsidian 配置文件

这套结构的核心逻辑是：分类只分到一级，知识之间的网状关联全部交给双向链接。比如我有一条笔记叫“如何构建 RAG 知识库”，它不需要同时出现在“AI”和“开发”两个文件夹里，我只要在笔记正文中用 [[]] 链接关联到“Embedding 模型选型”“向量数据库对比”等笔记即可。搜索时，我靠 Obsidian 的图谱和 WorkBuddy 的语义检索，而不是靠文件夹层级去找内容。

inbox 的设计特别重要。人脑在快速记录时是不适合做分类决策的。过去我强迫自己每次记录前先想，这条该放到哪个文件夹，结果很多想法因为没有立刻归档而丢失。现在我不管三七二十一，先在收件箱里丢下一段文字，每周固定时间统一整理，该链接的链接，该归档的归档。你可以把这个过程理解成座舱里的临时储物格，先保底再分拣，这套机制比强制分类靠谱得多。

2.2 私有仓库与开源许可证：这一步一开始就要想清楚

在 Gitee 上创建仓库时，有一项“选择开源许可证”的选项，很多人容易卡住。其实判断标准非常简单：你的知识库准备公开分享吗？

如果不是，那就选择“私有仓库”，开源许可证那一项可以直接跳过。私有仓库意味着只有你自己能访问，你的笔记不会出现在别人的搜索里，这个对个人隐私来说是最核心的保障。我强烈建议，个人笔记默认全部走私有，哪怕你觉得“里面好像也没什么见不得人的”，也建议先私有。因为笔记里很可能包含朋友的联系方式、项目未公开信息、工作中的临时判断，这些内容一旦公开，影响很难控制。

如果将来你真的想把某一部分整理成公开内容分享，再单独建一个公开库，把要分享的笔记复制过去，然后重新选一个许可证。知识库公开时许可证怎么选也有门道：如果你希望别人能用你的内容做商业用途，选 MIT 或 Apache-2.0；如果你希望别人修改后也必须以同样方式共享，选 GPL；如果仅仅是个人分享不想管那么多，选 CC BY 也可以。但这是“分享用”的选择，和“个人存储”是两套逻辑，不要混在一开始就纠结。

2.3 SSH 密钥配置：一次性做好，之后免密推送

整个组合里，Gitee 连接配置是最容易劝退新人的一环。其实核心就两步：生成本地密钥，把公钥加到 Gitee。在 Windows 上如果已经装好了 Git for Windows，直接打开 Git Bash；macOS 上打开终端即可。

先检查是否已有密钥：

ls -al ~/.ssh

如果看到了 id_ed25519.pub 或 id_rsa.pub 文件，说明之前生成过，可以跳过生成步骤。如果没有，执行：

ssh-keygen -t ed25519 -C "your_email@example.com"

执行过程中会让你指定保存路径和解锁密码，默认路径直接回车，解锁密码不设置也行，密码留空意味着每次推送不需要额外输入，方便很多。生成完成后，查看公钥：

cat ~/.ssh/id_ed25519.pub

把这端内容完整复制下来，然后打开 Gitee 的“设置 → SSH 公钥”，粘贴并保存。最后测试连接：

ssh -T git@gitee.com

如果返回类似欢迎信息，说明密钥已经生效。这一步做完，后面所有的 git push 和 git pull 都是丝滑的。需要提示的是，如果你有多台设备，每台设备都可以生成独立的密钥对，把各自的公钥都加到同一个 Gitee 账号下即可。我自己的电脑和笔记本各配了一把，这样两边都能直接推送和拉取，不需要反复输入密码。

2.4 冲突处理策略：这件事必须提前摆到桌面上

用 Git 做笔记同步，最大的风险不是丢数据，而是冲突。冲突本质上是因为同一个文件在两个不同的时间点被两台不同的设备分别修改了，git 不知道以谁为准。拿笔记场景来说，你下午在笔记本上改了一条“Python 学习路线”，晚上又用台式机对同一条笔记做了完全不同的修改，下一次 push 或者 pull 时，git 就会报冲突。

解决冲突的策略不需要懂很深奥的 Git 原理，最有效的经验其实就三条。第一条，尽量保持“一个时间点只在一台设备上写”。出门前把当前电脑上的修改先 push 掉，回家后先 pull 再动笔。第二条，冲突发生时不要慌，git 会把冲突标记注在文件里，Obsidian 打开后你能看到以 <<<<<<< 和 >>>>>>> 包裹的两份内容，手动保留想要的那个版本，重新提交一次就行。第三条，如果自己搞不定，先把冲突文件复制出来单独备份，然后把库回退到没有冲突的那个版本，再把你备份里的新增内容手动粘贴回去。这招虽然原始，但永远不会把内容搞丢。

我最开始用这套同步时，经历过一次比较痛苦的冲突恢复，从那以后就立了规定：提交前看一眼有没有未同步的修改，pull 和 push 之间不要隔太久。把这两条养成习惯，冲突出现的概率会直线下降。

3. 实操：把三联真正打通

3.1 Obsidian 端准备：目录、附件路径、核心插件

在把库交给 Git 管理之前，有几步 Obsidian 端的设置可以先做好，否则后面会出很多奇怪问题。

第一步是设置附件路径。默认 Obsidian 会把粘贴进来的图片放在与笔记相同的目录，时间一长，notes 目录里会杂七杂八堆满图片和 PDF，不但 Git 提交体积变大，库的结构也变得混乱。按我上面给的目录结构，建议打开“设置 → 文件与链接”，将“新附件位置”改为“附件文件夹”，并指定为 04_assets 目录。这样所有图片默认归档到一起，提交和回滚时边界更清楚。

第二步是开启核心插件里的“日记”和“模板”。日记插件可以让我用快捷键随时新建当天的日记，模板插件则是为了让日记格式统一。日记的命名我建议用 YYYY-MM-DD 格式，比如 2025-06-10.md，这样文件在文件系统里按名称排序时，天然就是时间轴顺序，WorkBuddy 扫描日记时也更容易按日期筛选。

第三步是关键，也就是安装 Git 管理插件。Obsidian 的社区插件中心里有一个叫 Obsidian Git 的插件，它本质上把 Git 的核心操作拉到了 Obsidian 界面里，比如一键提交、一键拉取、定时自动备份。你不需要在 Obsidian 里配置复杂的 SSH，因为它在你的电脑上调用的是系统里的 Git 命令，而你已经在第 2.3 节配置好密钥了。安装后，在插件设置里开启“自动备份”，并设置间隔时间，比如每四十分钟提交一次。

这一步实际用下来非常稳定。Obsidian Git 插件在后台运行，完全不用你手动操作。我也试过它偶尔在笔记本合盖睡眠时没有执行备份，但下次打开时会自动补上，不影响整体体验。需要注意的是，插件会把 Git 仓库入口默认指向当前库所在的根目录，只要你的库本身是 Git 仓库，它就能直接识别。

3.2 在 Gitee 建仓库并推送首批笔记

推送到 Gitee 的流程和推送代码项目几乎一模一样。用浏览器打开 Gitee 新建仓库页面，填写仓库名称，比如 knowledge-base，仓库设置为“私有”，创建时相关 README 文件先不勾选，保持一个空仓库。这样做的目的是避免生成初始提交和本地库的历史冲突，后面接起来干净。

随后打开终端或 Git Bash，进入你的 Obsidian 库目录：

cd /path/to/your-vault git init git add -A git commit -m "init: 初始化个人知识库" git remote add origin git@gitee.com:你的用户名/knowledge-base.git git push -u origin master

如果你是第一次在这个仓库上使用 Git，注意看 Gitee 仓库首页提示的远程地址。如果页面提示分支是 main，而你本地推的是 master，也没有问题，可以在推送前执行git branch -M master统一分支名，或者直接用页面提示的默认分支名。

推送完成后，建议到 Gitee 网页端刷新一下，能看到笔记文件已经出现在远端。这一步做完，你的本地 Obsidian 库就正式拥有了“远端保险柜”。随后在另一台设备上，只需要执行git clone git@gitee.com:你的用户名/knowledge-base.git，就可以把整个库拉到另一台电脑上。仓库里出现的“备份还原点”概念，从此就成了你知识库管理的基本操作。

3.3 WorkBuddy 接入知识库：让它真正“看得懂”你的笔记

WorkBuddy 接入本地知识库，本质上就是你把本地项目目录加载给它，然后让它基于这些文件来对话和生成。以我实际使用的流程来看，操作路径大概是：启动 WorkBuddy，选择“打开项目”或“添加工作区”，定位到你 Obsidian 库的根目录；随后 WorkBuddy 会扫描目录内文件，建立索引；扫描完成后再进入对话界面，请它“阅读这个目录下所有与 RAG 相关的笔记”，它就能基于库内内容回答了。

我踩过的一个坑是，一开始我把整个库直接丢给它所有文件，它确实能读取，但当库文件数量变多后，它回答时偶尔会把不同笔记里相似但不同的概念混在一起。比如我有两条笔记，一条讲“向量数据库选型”，一条讲“图数据库选型”，AI 回答时可能会把它们当成同一个主题来混着讲。后来我的做法是，在提问时主动给它限定搜索范围，比如“先扫 01_notes 里标题或内容包含数据库对比的文件，再回答我的问题”。把边界划清楚之后，准确率明显提升。

另外，Skill 是知识库场景里提升工作效率的大杀器。我举个我自己写的周报 Skill 的结构作为参考：

• 触发条件：用户说“生成本周周报”
• 执行步骤：先检查当前日期，再扫描 02_daily 目录下最近七天的日记
• 输出要求：按“本周工作成果”“问题与风险”“下周计划”三部分输出，引用笔记中具体事实
• 个性化规则：陈述尽量使用“完成”“推进”“确认”这类动词，避免模糊描述

你可以在 WorkBuddy 的技能管理界面把上述规则结构化填写。自此以后，每次我只要说“生成本周周报”，它就会自动扫描我的日记目录，并按固定格式生成内容，省去了我反复粘贴笔记、整理日报的时间。这种能力不是网页聊天框能给到的，因为网页聊天框没有上下文基础，而工作台类工具天然拥有“项目上下文”这个概念。

3.4 自动同步的落地方法：别让手动提交成为负担

如果每次同步都要手动执行 git add 和 git commit，那么时间一长，维护成本一定会感人，尤其是工作忙起来的时候，很容易就忘了。我在实际操作中用到了两层自动化，第一层是 Obsidian Git 插件的自动备份，第二层是一个终端脚本，双保险。

Obsidian Git 插件的自动备份在设置里可以配置提交间隔，我建议设置得不要过于激进，比如 30 到 60 分钟一次就足够了。因为知识库不像代码项目，不需要每一次按键都留历史，太频繁的提交只会让 Git 历史变得冗长，也会给远端仓库增加不必要的压力。设置完间隔后，只要你开着 Obsidian，修改过的笔记会在后台自动提交并推送，整个过程不需要打开终端。

如果想更进一步，或者你不希望每次都要打开 Obsidian 才触发备份，可以用一个简单脚本挂到系统的定时任务里：

#!/bin/bash cd /path/to/your-vault git add -A if git diff --cached --quiet; then echo "没有变化，跳过提交" else git commit -m "auto backup $(date +'%Y-%m-%d %H:%M:%S')" git push origin master fi

在 macOS 上，你可以把这个脚本保存为 backup.sh，并给它执行权限，然后用 crontab 设置每天定时执行。在 Windows 上，可以把脚本适配为 PowerShell 版本，然后使用任务计划程序定时触发。

我自己的习惯是，Obsidian Git 插件负责平时工作时的频繁备份，crontab 脚本负责兜底，即使某天我没有打开 Obsidian，只要电脑开着，每天至少也会有一个版本推送到 Gitee。用这套机制跑了几个月，我从未因为忘记同步而丢过笔记。

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

4.1 提交冲突导致的笔记内容错乱

这是我在多设备同步中遇到的最高频问题。场景很常见：白天在公司电脑上改了好几条笔记，下班回家后打开笔记本，忘了先拉取远端更新就直接继续写。笔记本上弹出“合并冲突”的提示，打开笔记一看，文件里多了几段以 <<<<<<< HEAD 和 >>>>>>> 开头的标记内容。

遇到这个情况，第一步先不要急着删标记。用 Obsidian 打开文件，你会看到两个版本的内容都被保留在文件里，中间用分隔线分开。你需要做的是手动判断，保留真正需要的那一版，把另外一版的对应内容删掉，同时把 <<<<<<<、=======、>>>>>>> 这些标记全部删除，让文件恢复成一条干净的内容。处理好之后，执行一次 git add 和 git commit，冲突状态就会被解除。

预防这件事，我后来给自己定了一条铁律：换设备前，至少执行一次同步。比如我离开公司前，会在 Obsidian Git 面板里点一下“提交并推送”；到家后，第一件事就是“拉取”。五分钟的动作，换来的是再也不用在半夜处理乱七八糟的冲突标记，这笔账非常划算。

4.2 图片和 PDF 附件到底要不要纳入 Git 管理

知识库跑一段时间后，04_assets 目录里会有大量图片，比如 PDF、截图、扫描件、导出素材等。这些文件不会影响到 Markdown 内容的版本管理，但会让 Git 仓库的体积快速膨胀，导致每次 clone 和 pull 的时候数据量很大，远端仓库空间也会告急。

我对附件的策略是区分对待。小于几 MB 的图片，比如截图、图表，直接放在 04_assets 里随笔记一起提交，因为它们是笔记内容的一部分，版本回滚时需要一起恢复。大文件，比如动辄几十 MB 的 PDF、视频、设计源文件，建议不要进入 Git 仓库。这些内容可以通过本地目录或者其他文件同步方式单独保存，知识库里只保留链接或引用说明。

如果你不想让大文件纳入 Git 管理，可以在 .gitignore 里把包含大文件的目录排除掉。比如你单独建了一个 04_assets_big 目录来放大文件，就在 .gitignore 里加一行/04_assets_big/。这样 Git 仓库保持轻量，敏感大文件也不会上传到远端，双保险。

4.3 AI 回答总答错或者答不到点子上，问题出在哪

接入 WorkBuddy 之后，最让人挫败的不是它不会用，而是它看着你的库却答不到点子上。遇到这类问题，大多数情况不是 AI 的问题，而是你的笔记结构不够“机器可读”。AI 检索的本质是先通过文件名、标题、标签或者文件片段来锁定候选内容，如果你的笔记通篇没有小标题，也没有任何标签，全文就是一个没有结构的文本框，那么再强的模型也很难准确找到你想要的内容。

我自己在修正这个问题时，做了一件很笨但很有效的事：给每个长期使用的常驻笔记，在开头加了一个“摘要区”。摘要区里用两到三句话概括这条笔记的核心观点，然后列出三个左右的关键标签。比如一条笔记叫“RAG 知识库的构建”，摘要区可能长这样：“本文整理 RAG 知识库的组成模块，包括文档解析、向量化、检索、生成四个环节，适用于个人知识库与项目文档问答场景。标签：#RAG #知识库 #向量检索”。

你别小看这个改动，它让 AI 的召回精度直接上升了一个量级。因为摘要区相当于给每条笔记做了一个简明的“推荐位”，AI 在检索时能迅速命中摘内容，再根据摘要决定是否深入阅读全文。这个方法比单纯堆标签好用得多，实测下来错答率下降明显。做这项工作虽然需要一点维护成本，但它也正是知识库沉淀的过程中，最有复利效应的部分。

4.4 同步节奏和频率：不是越勤越好

很多人刚开始用 Git 管理笔记时，会把自动提交间隔设得极短，比如每五分钟一次，导致 Git 历史里全是“小碎步”式的提交记录，实际回滚时反而看不出哪个时间点是重要的。我在前期也犯过这个毛病，后来把间隔调整到三十到六十分钟一次，同时保留手动提交入口，用于标记重要节点，比如完成一次大规模整理、一篇完整的文章初稿，或一个阶段性的知识梳理。

同步频率的把握有一些经验性的判断标准。如果你处于一场快速输入的会议中，随手记了很多碎片内容，这些内容不需要立刻推送到远端，等到会议结束、整理成文后再提交一次，历史记录会更干净。如果你有几小时的大块时间在做知识梳理，中间可以有少量自动提交，但最重要的提交一定是在你完成某一阶段清理、确认内容质量不错之后手动触发的那一次。

这里的底层逻辑是，Git 历史的真正价值是提供“有意义的还原点”，而不是记录每一次击键。把提交节奏从“疯狂快进”调成“按阶段走”之后，你回看历史时能快速找到“上周五那一版整理得不错”之类的关键时间点，使用体验会好很多。

最后再分享一个我实际沉淀下来的体会：无论工具组合怎么变，知识库的核心永远是“你敢不敢放心地往里面存”。存储、检索、同步、AI 回答，所有这些能力本质上都是为了降低你记录和调用的阻力。当你有了一套本地纯文本兜底、Gitee 版本守护、AI 随时可读的体系之后，笔记就不再是堆积的文字，而是一块能反复生长、可被检索、甚至能替你产出的私人知识土壤。我这套组合跑了大半年最明显的感受是：打开笔记的动作变少了，真正用知识产出的时间变多了。后续我还在尝试把更多重复性整理动作做进 Skill 里，比如自动合并同主题笔记、定期清理收件箱，一步步让这套体系离“第二大脑”更近一点。