企业官网建设流程全解析

记笔记这件事，我坚持了快十年。从最早的纯文本文件夹，到后来用各种在线笔记，再到三年前全面迁回 Obsidian。工具换了一轮，最核心的痛点始终没变：记进去的多，用起来的少。三千多篇笔记躺在文件夹里，搜索靠关键词，回顾靠回忆，知识库更像一个"数字仓库"，而不是能帮我思考的东西。

直到我把 Obsidian、WorkBuddy、Gitee 三件事串在一起，情况才真正改变。这套组合做的事情很朴素：Obsidian 负责承载一切笔记内容，Gitee 负责给所有笔记做异地备份和版本管理，WorkBuddy 负责把 AI 能力接进本地笔记，让它能回答问题、批量整理、自动补摘要。三个角色各管一段，拼起来就是一个"AI 驱动的个人知识库"完整闭环。

这篇文章适合所有正在用 Obsidian、但对"怎么让笔记真正被用起来"还不太满意的人；也适合刚接触这类工具、想一步到位搭一套靠谱知识库体系的新手。我会把分工逻辑、配置步骤、结构设计、实战工作流，以及我踩过的坑完整讲一遍，你可以照着搭，也可以在这个框架上改成自己的玩法。

1. 为什么是这三件套：Obsidian、WorkBuddy、Gitee 的分工逻辑

1.1 Obsidian：一切内容留在本地，这是一切的前提

我用来用去，最终还是回到 Obsidian，原因只有一个：它把笔记当成普通文件放在本地文件夹里。Markdown 纯文本，不锁格式，不锁平台，不锁数据库。今天用 Obsidian 打开，明天用 VS Code 打开，后天写个脚本直接批量处理，都行。我的笔记主权在我自己手里，这才是知识库能被 AI 驱动的前提。

相比之下，在线笔记工具的问题不在功能，而在数据流动性。笔记存在别人服务器上，格式私有化，导出经常丢三落四。AI 要处理你的知识库，第一步得能读到原始内容——本地 Markdown 文件夹天然是最容易让程序读取的数据形态。

另外一个隐藏优势是插件生态。Obsidian 的社区插件里，Dataview 能做结构化查询，Templater 能自动化模板，Obsidian Git 能直接把仓库和远端代码平台打通。这些插件让"知识库"不再只是一个文件夹，而是一套可以被脚本和 AI 驱动的工作台。

1.2 WorkBuddy：给静态笔记装上一双"会干活的手"

Obsidian 擅长存，不擅长"想"。你问它"我半年前记的那个关于浏览器插件性能对比的结论是什么"，它能做的只是把包含关键词的笔记列出来，然后让你自己翻。这个缺口需要 AI 来补，WorkBuddy 就是补这个缺口的角色。

WorkBuddy 是一款以 LLM 为核心的 AI 工作台工具。你可以把它理解成一个能读写本地文件、执行多步任务的 AI 助手：它把大模型的对话能力、工具调用能力、Skill 技能机制组合在一起，让 AI 不是停留在聊天窗口里，而是真正可以操作你指定的文件夹。对个人知识库的场景来说，这就意味着：

• 你可以问它："根据 2025 年项目笔记，我上半年遇到的最多问题是什么？"
• 它可以帮你给一堆旧笔记自动生成摘要，再写回每篇笔记的元数据里。
• 它可以按你的要求，把某个 MOC（内容地图）索引页重新整理成带链接结构的文档。

用一句话概括：Obsidian 负责"记住"，WorkBuddy 负责"理解"和"干活"。

需要注意，WorkBuddy 本身不内置大模型能力，它需要对接可用的模型服务或本地模型。具体用哪个模型，取决于你对隐私、成本、效果的权衡。我后面会在 4.4 专门讲这部分。

1.3 Gitee：给知识库一份带时光机的异地副本

个人知识库最怕的不是记不全，而是丢。硬盘会坏，电脑会丢，云盘可能出问题。所以知识库必须有一个"异地副本"。挑来挑去，我用的是 Gitee 私有仓库。

选择 Gitee，核心理由有三个。第一，国内访问速度快，push 和 clone 都稳定，不像某些境外托管平台经常连不上；第二，私有仓库免费额度足够个人笔记使用，你的笔记不需要暴露在公网上；第三，它兼容标准 Git 协议，Obsidian Git 插件可以直接对接，手机网页端也能随时浏览。

Git 平台给知识库带来的，不只是备份，还有版本管理。我误删过笔记，改坏过结构，最后都是靠 git log 找回来的。那种"任何时刻都有后悔药"的安全感，是普通文件夹同步工具给不了的。

这套组合我还想再强调一个边界：Obsidian 管内容形态，WorkBuddy 管智能处理，Gitee 管安全兜底，三者各司其职，互不替代。想用 Obsidian 的插件硬做 AI，或者用 Git 硬做桌面端管理，都会很难受。分工清楚，后面所有流程才顺。

2. 从零搭建：最小可用闭环的完整配置

这一节我按实际操作顺序写，目标是让你在一小时内跑通"本地笔记 → Gitee 云端 → 多端同步"这条链路。配置部分我只保留真正必要的项，避免一上来就被插件淹没。

2.1 本地侧：Obsidian 仓库初始化清单

第一步，安装 Obsidian。打开官网下载对应系统版本，安装后选择"创建新库"，指定一个本地文件夹作为 Vault。我建议直接放在一个专门的数据目录，比如~/Documents/KnowledgeBase，路径里尽量不要有中文和空格，后面接脚本、接 Git 都会省事。

第二步，进入 Vault 后打开"设置 → 第三方插件 → 关闭安全模式"，启用社区插件。先装三个，它们是这个体系的地基：

这三个插件装完先不急着配，Obsidian Git 要等远端仓库建好之后再配置。

2.2 远端侧：Gitee 仓库创建与 SSH 密钥配置

登录 Gitee（gitee.com），点右上角"新建仓库"。仓库名我建议和本地 Vault 名保持一致，比如knowledge-base。关键一步是路径选私有，个人知识库任何情况下都不该设成公开。初始化仓库时不要勾选"初始化仓库"，因为本地已经有内容了，直接从空仓库开始最干净。

接下来配置 SSH 密钥。打开终端，执行：

ssh-keygen -t ed25519 -C "你的邮箱@example.com"

一路回车即可。生成的公钥在~/.ssh/id_ed25519.pub，复制出来。回到 Gitee 页面，进"设置 → 安全设置 → SSH 公钥"，把公钥粘贴进去，标题随便填。

验证是否配置成功：

ssh -T git@gitee.com

看到类似Hi your_name! You've successfully authenticated的提示就说明通了。这一步如果失败，先检查公钥有没有复制完整，再检查本地 SSH 客户端是否有代理干扰。很多第一次配置的人问题都出在复制时漏了结尾的邮箱注释。

2.3 打通双向同步：Obsidian Git 的保存与拉取细节

打开 Obsidian，"设置 → 第三方插件 → Obsidian Git"，做四件事：

1. 在"备份仓库路径"里填远端地址，用 SSH 格式：git@gitee.com:你的用户名/knowledge-base.git。
2. 勾选"保存时自动提交并推送"，提交间隔默认即可。
3. 设置"自动拉取间隔"为 15 分钟，这决定了多端编辑时能多快拿到最新版本。
4. 配置.gitignore，建议至少排除：
   • .obsidian/workspace.json（界面状态，不需要版本管理）
   • .obsidian/cache相关目录
   • node_modules如果存在的话

在 Obsidian 里直接拉取可能因网络原因偶发失败，我会在"Obsidian Git"插件的命令面板里手动执行Git: Pull，看输出信息判断是网络问题还是密钥问题，比干等智能提示更靠谱。

2.4 验证闭环：一条笔记走完整个链路

新建一篇测试笔记，内容随便写点，Obsidian Git 会自动把它提交并推送到 Gitee。打开 Gitee 仓库页面，看到main分支上出现了刚才的提交记录，说明闭环已经通了。

此时再模拟"另一台设备"：在另一台电脑上git clone git@gitee.com:你的用户名/knowledge-base.git，用 Obsidian 打开这个文件夹，你会发现所有笔记都在。至此，最小可用的"Obsidian + Gitee"同步体系建立完成。接下来才轮到 AI 的接入。

3. 让 AI 真正"读懂"你的知识库：笔记结构设计

工具配好了，如果笔记本身是一团浆糊，AI 再好也白搭。很多人忽略这件事：AI 能发挥多少作用，取决于你的笔记有没有给它足够的结构信息。这一节讲我如何设计笔记结构，让 AI 读懂。

3.1 机器可读与人类可读的统一

人类读笔记，靠标题、排版、上下文联想。AI 读笔记，靠的是结构。同一个文件夹里，一篇纯散文的笔记和一篇带元数据、带标题层级的笔记，AI 处理起来效果差很多。

我并不是说每篇笔记都要写得像论文。我的做法是"正文随意，元数据严谨"：正文保持自然记录的状态，但每篇笔记开头都有一段机器可读的元数据，告诉 AI 这篇笔记是什么主题、什么类型、创建时间、关联标签。这部分数据我接下来用 frontmatter 实现。

3.2 用 YAML frontmatter 给笔记加"身份信息"

在 Obsidian 里，每篇 Markdown 笔记的最顶部可以写一段 YAML 格式的属性区，这叫 frontmatter。Obsidian 原生支持，Dataview 插件也能读。我的每篇笔记至少包含这样的字段：

--- title: "Obsidian Git 插件同步失败排查" date: 2025-06-10 type: note tags: [obsidian, git, 排错] status: permanent source: "" summary: "" ---

具体解释一下每个字段的用意：

• title：笔记标题，避免 AI 依赖文件名做判断。
• date：创建日期，方便按时间维度筛选。
• type：笔记类型。我用note表示日常记录，moc表示索引页，project表示项目相关，archive表示归档。这个字段让 AI 一眼就能判断笔记在知识库里的"身份"。
• status：状态。fleeting表示临时想法，permanent表示已整理过的长期笔记。有了它，AI 可以优先处理permanent的笔记做知识问答，忽略fleeting的内容。
• summary：摘要。初期留空，后面让 WorkBuddy 自动生成回填。这就是 AI 驱动的价值点。

有了这套 frontmatter，AI 处理知识库时就有了"筛选条件"和"回写位置"，所有批量操作都变得可行。

3.3 目录与命名：短文件名比好看更重要

知识库的目录结构我建议浅而清晰，三到四层即可。比如：

KnowledgeBase/ 00-收件箱/ # 临时想法，未处理内容 10-项目/ # 按项目划分的笔记 20-领域/ # 按知识领域划分，比如 AI、效率、写作 30-资源/ # 书摘、文章摘录、工具对比 90-归档/ # 已失效或不再使用的笔记

数字前缀的作用是让文件夹排序可控。收件箱只有这一个入口，所有快速记录先进那里，处理完毕再移动位置。这种"Inbox 模式"在实际使用中非常有用，保证 AI 扫描的时候不会把大量半成品当成成品内容。

文件命名我坚持三条规则：全小写、短横线分隔、不用空格和中文。比如obsidian-git-sync-troubleshooting.md，而不是Obsidian Git 同步问题记录.md。理由是 Git 对特殊字符和中文文件名的处理在不同平台上有差异，空格更是所有命令行操作的噩梦。给 AI 处理时，干净的英文文件名也便于脚本匹配。

3.4 双链与 MOC：AI 的"上下文跳板"

Obsidian 的双链语法[[笔记名]]不只是人类导航工具，它给 AI 提供了天然的关联信息。当 AI 读一篇关于"Obsidian Git 插件"的笔记时，如果里面链接着[[Gitee私有仓库配置]]和[[SSH密钥管理]]，它就知道这个话题还有两个相关延伸点，回答问题时可以把它们纳入上下文。

MOC（Map of Content，内容地图）是更高一层的结构。我每周会维护一到两个 MOC 页，比如[[AI知识库总览]]，里面用列表组织当前知识库的核心主题和对应笔记链接。这个页面像是 AI 的"目录文件"——它不用扫描全部三千篇笔记，只要先读总览，就能按图索骥找到相关内容。

4. WorkBuddy 实战：把 AI 接进知识库工作流

4.1 安装与核心概念：Skill 机制是关键

WorkBuddy 的安装方式按官方说明操作即可，支持桌面端环境。装好之后，先理解它的三个核心概念：

• 会话：你和 AI 的一次连续对话，可以临时指定工作目录。
• Skill 技能：把一段固定指令、工具调用、参数定义打包成一个可复用的技能。这是最核心的部分。
• 文件系统访问：WorkBuddy 可以授权读写指定文件夹，这是它和普通聊天 AI 的本质区别。

对知识库场景，绝大多数能力都通过 Skill 实现。我配置了三个自用的 Skill：知识库问答、笔记摘要回填、MOC 索引更新。下面分别讲。

4.2 配置"知识库问答"Skill

这个 Skill 的目标是：让 WorkBuddy 基于你指定目录里的 Markdown 笔记回答问题，并明确标注答案来源笔记。技能配置大致是这个结构：

{ "name": "kb_query", "description": "基于个人知识库指定目录的Markdown笔记回答用户问题，并返回引用来源。", "tools": ["read_file", "list_files", "search_files"], "instructions": "用户提问时，先扫描目录下所有.md文件，按问题关键词筛选候选笔记；对候选笔记逐个读取，综合内容给出回答；回答末尾列出引用笔记的相对路径。若没有找到相关内容，明确说明知识库中无该信息，不要编造。" }

具体字段格式会随 WorkBuddy 版本迭代变化，但这个"先扫描、再筛选、后引用"的逻辑是核心。它确保 AI 回答时有据可依，而不是凭空发挥。

使用场景举例：我在做一份季度总结前，直接问 WorkBuddy："根据知识库里 10-项目 目录下的笔记，整理出我这个季度完成的三件主要事项。" 它会把相关项目笔记全部读一遍，再按时间线输出结果。过去我要手动翻半天，现在几分钟就拿到草稿。

这里有一个重要原则：AI 的回答质量上限，取决于你喂给它的笔记质量。如果知识库里全是碎片化的临时记录，AI 也只能给你碎片化的答案。所以我在第 3 节强调的结构设计，是整套体系能跑通的真正前提。

4.3 批量任务：自动摘要与标签补全

比问答收益更大的是批量处理。我每个月跑一次"旧笔记清理"，让 WorkBuddy 做三件事：

1. 扫描00-收件箱里超过 30 天未修改的笔记。
2. 为每篇生成一句摘要，回填到 frontmatter 的summary字段。
3. 根据内容自动补充tags标签。

这个 Skill 的核心指令可以这样写：

扫描指定目录下的所有.md文件。 对每个文件，执行以下步骤： 1. 读取全文内容。 2. 识别主题和关键结论，用不超过50字的中文写摘要。 3. 提取3个以内的主题标签。 4. 将摘要和标签更新到文件开头的frontmatter中，保留其他字段不变。 处理完毕后，输出一个清单，列出所有处理过的文件名和包含的原始字段。

最让我惊喜的是"回填 frontmatter"这个操作。因为笔记的元数据是结构化的，AI 把摘要写回summary字段之后，Dataview 插件立刻就能用这些元数据生成漂亮的索引表格，整个知识库的可检索性跨了一个台阶。这形成了正循环：越整洁的知识库，AI 处理效果越好；AI 处理得越好，知识库越整洁。

4.4 模型选择与成本考量

WorkBuddy 需要对接模型服务，这里有几个方向：

云端大模型：效果好，理解能力强，适合高质量的问答和复杂整理。但需要注意两点：一是按 token 计费，如果让 AI 大批量扫描几千篇笔记，成本不低；二是隐私边界，个人日记、工作机密等敏感内容传到云端，要有这个意识。我的做法是：只有public字段标记的可公开内容才交给云端模型处理，私密内容用本地模型。

本地模型：通过 Ollama 这类工具跑量化小模型，速度慢一些，完全免费且内容不出本机。适合批量摘要这种不需要深度理解的重复劳动。我实际测试下来，7B 级别的模型做标签补全和短摘要足够，做复杂的多步推理还是云端模型更强。

我的经验是分层使用：日常知识问答走云端模型，批量摘要和标签提取走本地模型。这样既控制了成本，也保护了最私密的内容。WorkBuddy 支持多模型配置，切换成本很低，建议你两种都试试再定自己的策略。

5. 日常闭环与跨设备协同：我的实际操作流

结构设计得再漂亮，如果每天用起来太繁琐，这套体系很快就会被抛弃。这一节我会还原一天的真实操作流，以及多端协同中的关键细节。

5.1 一天的工作流：记录、榨取、同步

我的日常流程可以用一句话总结：随时随地记录，定时批量榨取，退出前自动同步。

早上开始工作前，我会打开 Obsidian。新想法直接扔进00-收件箱，用 Templater 创建的模板自动带上前面的 frontmatter 结构。这个动作只需要十秒，不需要任何格式上的纠结。

下午如果写文档或者做研究，相关素材按项目归档到10-项目或20-领域对应目录。边写边用的中间过程不用管 Git，Obsidian 的自动提交会在后台处理。

工作收尾前，我会打开 WorkBuddy，针对当天新增的笔记问一两个问题，比如"今天记录的笔记里，有哪些可以合并到已有的领域笔记？"AI 给出合并建议，有时候直接生成合并后的大纲。这相当于每天让知识库重新"梳理"一遍。

最后留意 Obsidian Git 插件的自动推送是否成功。如果失败，我会手动执行一次推送，避免笔记只在本地、云端没有最新版本。

这一天的流程里，AI 不是主角，但它是最关键的执行者：它把"我记的内容"转化为"我能用的资产"。

5.2 多端编辑：冲突处理

我在台式机和笔记本之间切换编辑，遇到过不少冲突。Obsidian Git 自动拉取 15 分钟一次，如果两台设备同时编辑同一篇笔记，就可能产生冲突文件，内容里出现<<<<<<< HEAD这样的标记。

处理冲突的正确顺序是这样的：

1. 先不要盲目点保存，否则可能把冲突标记一起存进去。
2. 在 Obsidian 里搜索冲突标记，定位到冲突文件。
3. 手动选择要保留的内容，删除冲突标记。
4. 在 Obsidian Git 命令面板执行Git: Commit，把解决结果提交覆盖。

这个问题的本质是 Git 对同一文件不同分支的合并策略。多端协同最常见的冲突场景是"两台设备在同一段时间内修改了同一篇笔记"，所以我的经验策略是：编辑之前先手动 pull 一次，形成"先拉后改"的习惯，可以规避大部分冲突。Obsidian Git 的自动拉取是兜底，不是保险箱。

5.3 版本回滚：误删笔记的后悔药

我曾经误删了一整篇写了三天的项目复盘，当时脑子里嗡的一声。幸运的是，Obsidian Git 在保存时已经把它提交到了 Gitee 仓库。恢复流程如下：

# 查看提交历史，找到删除前的最后一次提交 git log --all --oneline -- 路径/被删笔记.md # 从指定提交中恢复该文件 git checkout 提交哈希 -- 路径/被删笔记.md

文件立刻出现在本地目录，Obsidian 刷新后完好如初。这种"回滚到任意时刻"的能力，是知识库用 Git 托管最大的附加价值。没有版本控制的知识库，一次手误可能就是永久损失；有了版本控制，你随时可以回到过去。

5.4 手机上随时查：Gitee 网页端兜底

手机上我一般不编辑 Obsidian，太难受。但需要临时查一篇笔记时，方案很简单：打开手机浏览器访问 Gitee 仓库页面，直接预览任意 Markdown 文件的渲染效果。这虽然不如 Obsidian 移动端方便，但胜在零配置、永远可用，应急完全够。

如果想要更完整的手机端方案，可以考虑用第三方 Git 客户端配合 Obsidian 移动端。但我的建议是：初期不要折腾这个，真实知识管理需求大部分集中在电脑前，手机端能看就行。等你确认体系稳定了，再考虑移动端编辑的体验优化，避免一上来被配置成本劝退。

6. 踩过的坑与优化思路

任何工具组合，用一段时间之后一定会暴露问题。这节记录我踩过的坑，以及对应的解决思路，可以帮你少走弯路。

6.1 仓库体积膨胀：附件和二进制文件怎么办

用了一段时间，我遇到过一个明确警告：Gitee 仓库体积逼近限制。原因是我的知识库被塞进了大量截图和 PDF。Git 对文本文件极其高效，但对二进制文件毫无办法，每一份图片改动都会产生全新的副本，仓库体积迅速膨胀。

解决办法分三层：

1. 附件外移：图片统一放到 Vault 外的专用附件目录，或者干脆用图床。Obsidian 可以设置附件默认路径，在设置里把图片保存位置指向 Vault 外即可。
2. 大文件不进 Git：超过几十 MB 的 PDF、压缩包、视频，不要放知识库仓库。用网盘或对象存储托管，在笔记里留链接。
3. 定期瘦身：如果仓库已经很大了，用 git 过滤历史大文件重写提交历史，但这一步操作有风险，建议先备份再动手。或者更稳妥的方式：开一个新仓库，把当前内容重新初始化，旧仓库存保留档。

6.2 同步节奏不当导致的"云端漂移"

Obsidian Git 插件配置了自动推拉，但它的定时任务依赖 Obsidian 应用处于运行状态。如果你长时间不打开 Obsidian，笔记自然不会被推送。可能发生的情况是：你一周后打开 Obsidian，发现插件一次性推了数百个提交，或者自动拉取时和本地产生大量冲突。

我的解决思路是：给同步设置"固定检查点"。每天收工时，手动执行一次Git: Backup（Obsidian Git 插件提供的完整备份命令），确保当天内容全部入仓。周末再做一次全量查看。不要依赖插件定时的后台任务，定时任务只是保险，主动备份才是纪律。

6.3 WorkBuddy 对超长上下文的妥协

让 WorkBuddy 一口气处理几百篇笔记时，我发现一个现实问题：上下文窗口再大也有极限，指令目标过大会导致 AI 丢失前文信息、中间结果失真。比如让它批量更新整个知识库的标签，跑到后面它会"忘记"最初的规则。

解决方案是分块处理。一次只处理一个目录，或者一次只处理 30 篇笔记，处理完一批先验证效果，再继续下一批。把一个大任务拆成若干小任务，看起来效率低了，实际结果反而更可靠。这跟软件工程里"小步提交"是一个道理。

还有个细节：WorkBuddy 处理大量小文件时，我建议先在 Skill 指令里明确"跳过 frontmatter 中已有 summary 字段且 status 为 permanent 的笔记"，避免重复劳动，也避免 AI 反复改写已稳定的内容。

6.4 备份不能只靠同步：异地双仓库加定期导出

最后一条，也是我这两年最深刻的教训：同步不等于备份。如果你的 Gitee 账号被盗、仓库被误删，或者 Gitee 服务本身出问题，本地和云端会同时失去数据。所以我现在的策略是在同步之外，再加一层真正的备份：

• 每个月把 Vault 目录用压缩工具打包一次，传到独立的对象存储或网盘。
• 有条件的话，在另一个 Git 托管平台建一个私有镜像仓库，定期 push 过去。
• 重要程度极高的工作笔记，我会单独导出 PDF 存档。

这套体系的核心思想永远是"本地一份、同步一份、冷备一份"的备份架构。Obsidian、WorkBuddy、Gitee 都只是支撑这一架构的工具，知识库的安全底线不能寄托在任何一个单点上。

还有一个容易被忽略的点：Gitee 私有仓库也建议设置强密码和二次验证，SSH 密钥的私钥文件不要随意同步到云盘。你的知识库包含了你多年的思考脉络，它的价值不亚于任何重要资产，安全等级应该匹配得上。

最后说点实际操作中的体会

搭完这套系统后，我最明显的感觉不是"我的笔记变多了"，而是"我的笔记开始主动产生价值"。以前每次打开知识库都是负担——内容多到不知道从哪里下手。现在有了 WorkBuddy 这个执行层，我可以让它去整理、摘要、关联、回答，知识库从被动的存储空间变成了真正会思考的工作伙伴。

如果让我给刚接触这套组合的人一个建议，我不会建议你一开始就配齐所有插件、所有 Skill、所有自动化流程。先用最朴素的方式跑起来：Obsidian 记笔记，Gitee 做同步，WorkBuddy 只做问答。等这三个环节都稳定运转了，再逐步把批量摘要、标签补全、MOC 自动维护这些高级玩法加进来。知识库建设是一个持续积累的过程，工具只是放大器，你的持续记录才是原动力。

最后分享一个我每周都会做的小仪式：周五下午，让 WorkBuddy 随便挑三篇三个月前的旧笔记，重新阅读、重新整理。这短短十分钟让我发现，很多当时记录时觉得普通的内容，回头再看全是宝贵的经验。AI 驱动的个人知识库，最迷人的地方就在这里——它帮你把过去的自己，重新变成现在的自己的智囊。