企业官网建设流程全解析

1. 为什么我要折腾这套组合：从信息焦虑到知识复利

我大概是从三年前开始认真对待个人知识管理的。在那之前，我的信息散落在浏览器书签、微信收藏、备忘录、各种云文档里，找一条三个月前看过的技术方案要翻半小时。后来我用了 Obsidian，本地 Markdown 存储、双向链接、图谱视图，确实把笔记这件事理顺了。但新的问题很快出现：笔记越攒越多，检索靠关键词，关联靠手动，真正要用的时候还是得一条条翻。说白了，我建的是一个“仓库”，不是一个“大脑”。

这个项目的出发点很直接：让 AI 帮我管理和调用知识，而不是我自己去记。具体做法是把三个东西串起来——Obsidian作为本地知识载体，WorkBuddy作为 AI 协作与自动化层，Gitee作为版本管理与同步中枢。三者各司其职：Obsidian 负责“存”，WorkBuddy 负责“想”和“做”，Gitee 负责“稳”和“同步”。这套组合解决的核心问题是：知识库从静态存储变成可被 AI 检索、总结、生成、回写的动态系统。

适合谁来参考？如果你已经在用 Obsidian 但觉得检索效率低，或者你手头有一堆文档想接入 AI 能力，又或者你单纯想搞一套不依赖单一平台、数据完全自控的知识系统，这套方案都能直接抄。不需要你是程序员，但需要你愿意花一个下午把环境搭起来。下面我会把每个环节的选型理由、配置细节、踩过的坑全部摊开讲。

2. 整体架构设计与选型逻辑拆解

2.1 三个组件各自解决什么问题

先把角色分清楚，不然后面配置容易乱。

Obsidian的定位是“知识底座”。它用纯 Markdown 文件存储，意味着你的数据永远是纯文本，不被任何平台绑架。它的双链和标签系统让笔记之间形成网络，而不是孤立的文件。选它而不是 Notion、语雀，核心原因是本地优先和格式开放——AI 要读取和写入，纯文本是最友好的格式。

WorkBuddy的定位是“AI 协作层”。它负责把自然语言指令翻译成对知识库的操作：检索、总结、生成新笔记、批量打标签、甚至定时任务。它和 Obsidian 的关系是“读写分离”——WorkBuddy 不直接改你的笔记结构，而是通过约定的目录和格式来交互。

Gitee的定位是“同步与版本中枢”。Obsidian 本身有同步方案，但要么收费要么依赖第三方。用 Gitee 做 Git 仓库，你获得的是：完整的版本历史（每次改动可回溯）、多设备同步（手机、电脑、平板）、以及一个天然的备份。选 Gitee 而不是其他托管平台，主要是国内访问速度和免费私有仓库的稳定性。

2.2 为什么是“三联”而不是“二联”或“单点”

有人会问：Obsidian 加 AI 插件不就行了？为什么要多一个 WorkBuddy 和一个 Gitee？

单靠 Obsidian 插件做 AI，问题在于插件生态碎片化，每个插件只管一小块，且很多依赖外部 API 配置，换设备就要重配。WorkBuddy 作为独立层，把 AI 能力集中管理，指令和配置可以跟着仓库走。而 Gitee 的存在，让“配置”本身也变成可版本化的东西——你的 AI 提示词、目录结构、脚本，全部纳入 Git 管理，换电脑 clone 下来就能用。

另一个关键考量是数据流向的可控性。这套架构里，数据从 Obsidian 出发，经 WorkBuddy 处理，结果回写到 Obsidian，Gitee 全程记录。没有任何一步强制上云，你可以选择哪些目录同步、哪些留在本地。对于有隐私顾虑的知识内容，这个分层设计很关键。

2.3 目录结构设计：让 AI 能“看懂”你的知识库

这是整套方案里最容易被忽略但最重要的一步。AI 要高效工作，前提是知识库有可预测的结构。我试过几种方案，最后稳定下来的结构是这样的：

knowledge-base/ ├── 00-Inbox/ # 临时收集，未整理 ├── 10-Notes/ # 永久笔记，按主题分 │ ├── tech/ │ ├── reading/ │ └── life/ ├── 20-Projects/ # 项目相关，有明确起止 ├── 30-Areas/ # 长期关注的领域 ├── 40-Archive/ # 归档，不再活跃 ├── 90-Meta/ # 模板、脚本、AI配置 │ ├── templates/ │ ├── prompts/ │ └── scripts/ └── 99-Attachments/ # 图片、附件

这个结构借鉴了 PARA 方法，但做了简化。关键是90-Meta目录，WorkBuddy 的提示词模板、处理脚本、配置文件都放这里，跟着 Git 走。AI 处理时，默认只读00-Inbox和10-Notes，写入也只写到这两个区域，避免误改重要内容。

注意：目录名用数字前缀是为了排序稳定，不要用中文或空格，Git 和脚本处理时容易出编码问题。

3. 环境搭建与核心配置实操

3.1 Obsidian 安装与基础设置

Obsidian 下载直接去官网，选对应系统版本。安装后第一件事不是装插件，而是设置仓库位置。我的建议是放在一个专门的路径下，比如~/Documents/knowledge-base，不要放在桌面或下载文件夹，避免误删和同步冲突。

基础设置里几个关键项：

• 文件与链接：开启“自动更新内部链接”，关闭“使用 Wiki 链接”（用标准 Markdown 链接，兼容性更好）。
• 编辑器：开启“折叠标题”和“折叠缩进”，长笔记阅读体验好很多。
• 外观：字体大小调到 16px 以上，长时间看笔记不累。
• 核心插件：开启“模板”、“日记”、“标签面板”、“大纲”。其他按需。

插件方面，必装的就几个：Dataview（用查询语言动态生成列表）、Templater（比自带模板强，支持脚本）、Git（后面同步用）。其他 AI 相关插件先不装，我们用 WorkBuddy 统一处理。

3.2 WorkBuddy 的接入方式与配置要点

WorkBuddy 的安装方式取决于你用的版本。核心思路是让它能访问你的本地文件系统，并且有一个明确的“工作目录”指向 Obsidian 仓库。

配置分三步：

1. 指定工作目录：在 WorkBuddy 的设置里，把工作目录设为 Obsidian 仓库的根路径。这样它读写文件时用的相对路径就和 Obsidian 一致。
2. 配置模型接入：根据你用的模型服务，填入对应的接口地址和密钥。这里不展开具体服务商，原则是选一个响应稳定、支持长文本的。
3. 定义技能（Skill）：WorkBuddy 的 Skill 机制是它的核心。你可以理解为“预设指令集”。比如定义一个“总结今日笔记”的 Skill，里面写清楚：读取00-Inbox下今天修改的文件，生成摘要，写入10-Notes/daily/对应日期文件。

我实际用下来，Skill 的提示词要写得非常具体。模糊的指令比如“帮我整理笔记”效果很差，要写成“读取 00-Inbox 下所有 .md 文件，提取每个文件的标题和前三行，按修改时间倒序，生成一个 Markdown 表格写入 00-Inbox/index.md”。越具体，输出越稳定。

3.3 Gitee 仓库创建与 SSH 密钥配置

Gitee 这边要做两件事：建仓库、配密钥。

建仓库时，开源许可证选什么？如果是个人知识库，选“私有”仓库，许可证不用选。如果打算公开分享，选 MIT 或 CC-BY-4.0 都行，后者更适合文档类内容。仓库名建议和本地目录名一致，比如knowledge-base。

SSH 密钥配置是新手最容易卡住的地方。步骤：

# 1. 生成密钥对（如果已有可跳过） ssh-keygen -t ed25519 -C "your_email@example.com" # 一路回车，默认保存在 ~/.ssh/id_ed25519 # 2. 查看公钥内容 cat ~/.ssh/id_ed25519.pub

复制输出的内容，到 Gitee 的“设置 - SSH 公钥”里添加。然后测试连接：

ssh -T git@gitee.com

看到欢迎信息就说明配置成功。如果报错，检查~/.ssh/config里是否有冲突配置，或者用ssh -v看详细日志。

提示：Windows 用户如果用 PowerShell，路径是C:\Users\你的用户名\.ssh\。如果之前配过其他平台的密钥，注意不要覆盖，可以生成不同文件名的密钥并在 config 里指定。

3.4 本地仓库初始化与首次推送

在 Obsidian 仓库根目录执行：

cd ~/Documents/knowledge-base git init git remote add origin git@gitee.com:你的用户名/knowledge-base.git # 创建 .gitignore，排除不需要同步的内容 cat > .gitignore << 'EOF' .obsidian/workspace.json .obsidian/workspace-mobile.json .trash/ .DS_Store *.tmp EOF git add . git commit -m "init: 知识库首次提交" git push -u origin master

.gitignore里排除 workspace 文件是因为它记录的是窗口布局，不同设备会冲突。.trash是 Obsidian 的回收站，没必要同步。

4. AI 驱动知识库的核心工作流实现

4.1 自动摘要与标签生成流水线

这是最基础也最实用的功能。场景：你在手机上看到一篇好文章，复制到00-Inbox里，晚上回家希望 AI 自动处理。

WorkBuddy 的 Skill 配置大致逻辑：

触发条件：00-Inbox 目录下有新文件 处理步骤： 1. 读取文件内容 2. 调用模型生成 100 字以内摘要 3. 提取 3-5 个关键词作为标签 4. 在文件头部插入 YAML frontmatter： --- summary: [摘要] tags: [标签] processed: true --- 5. 将文件移动到 10-Notes/ 对应子目录

这里有个细节：标签的命名规范要提前定好。我吃过亏，早期标签随便打，后来有“AI”、“ai”、“人工智能”三种写法，检索时全乱。建议在90-Meta/prompts/里放一个tag-taxonomy.md，列出允许的标签列表，让 AI 从中选，而不是自由生成。

4.2 基于 RAG 思路的语义检索实现

Obsidian 自带的搜索是关键词匹配，找“讲缓存策略的那篇”这种模糊需求很吃力。RAG（检索增强生成）的思路是：先把笔记切块、向量化，检索时用语义相似度找相关内容，再交给模型生成答案。

在本地实现简化版 RAG 的步骤：

1. 切块：把每篇笔记按标题层级切成 200-500 字的块。WorkBuddy 可以写个脚本遍历10-Notes，按##标题分割。
2. 向量化：调用嵌入模型把每个块转成向量。这一步需要模型支持 embedding 接口。
3. 存储：向量存本地文件（比如 JSON 或 SQLite），不要存外部服务，保持数据自控。
4. 检索：用户提问时，把问题也向量化，计算余弦相似度，取 Top 5 块。
5. 生成：把检索到的块作为上下文，让模型回答。

这套流程听起来复杂，但 WorkBuddy 的 Skill 可以把它封装成一条指令。我实测下来，几百篇笔记的规模，本地检索响应在秒级，完全可用。

注意：RAG 知识库能存储图片吗？可以，但图片本身不参与向量检索。常见做法是图片 OCR 后把文字纳入索引，或者用图片描述模型生成文字描述再索引。纯图片检索目前还是难点。

4.3 多 AI 协作与任务分发

“多 AI 协作”这个词听起来玄乎，实际落地就是：不同任务用不同模型。比如摘要用便宜快速的模型，深度分析用能力强的模型，格式整理用本地小模型。

WorkBuddy 里可以配置多个模型端点，然后在 Skill 里指定用哪个。我的配置：

这种分发策略让整体成本降下来，同时关键任务质量不降。

4.4 定时任务与自动化触发

WorkBuddy 支持定时任务的话，可以设置：

• 每天早上 8 点：处理00-Inbox新文件
• 每周日晚：生成本周笔记摘要和周报
• 每月 1 号：归档超过 90 天未修改的笔记到40-Archive

这些任务用 cron 表达式配置。如果 WorkBuddy 本身不支持定时，可以用系统级的 cron 或计划任务调用它的命令行接口。

5. 同步、备份与多设备协同

5.1 Git 同步的冲突处理策略

多设备用 Git 同步，冲突是必然的。Obsidian 的 Git 插件可以设置自动 commit 和 pull，但冲突时它不会自动合并。

我的策略是：每次开始工作前先 pull，结束工作后 commit + push。养成习惯后冲突很少。如果真冲突了，Git 会标记冲突文件，打开手动解决——通常是同一段文字两边都改了，选一个或合并即可。

对于00-Inbox这种高频写入的目录，建议每台设备用不同的子目录名，比如00-Inbox/desktop/和00-Inbox/mobile/，避免同时写同一个文件。

5.2 移动端接入方案

手机上用 Obsidian 移动版，配合 Git 插件同步。但移动端 Git 操作体验一般，我的做法是：手机只负责“收集”，把内容丢进00-Inbox/mobile/，不做复杂编辑。回家后在电脑上统一处理。

如果不想在手机上装 Obsidian，也可以用 Gitee 的网页版直接编辑文件，或者用支持 Git 的 Markdown 编辑器。核心是数据格式统一，工具可以换。

5.3 备份的“3-2-1”原则落地

3-2-1 原则：3 份副本，2 种介质，1 份异地。

• 副本 1：本地 Obsidian 仓库
• 副本 2：Gitee 远程仓库
• 副本 3：定期导出到移动硬盘或另一台设备

Gitee 本身是异地，但依赖网络。我每月会手动 clone 一份到移动硬盘，作为冷备份。这个习惯救过我一次——有次误操作删了一个目录，Git 历史里找回来了，但如果没有远程仓库，本地又刚好没 commit，就真丢了。

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

6.1 Obsidian 打不开或卡顿怎么办

这是高频问题。排查顺序：

1. 安全模式启动：Obsidian 启动时按住 Shift，禁用所有插件。如果能打开，说明是某个插件的问题，逐个启用排查。
2. 检查仓库大小：附件目录过大（比如几个 G 的图片）会导致索引慢。把附件移到外部，用链接引用。
3. 清理缓存：删除.obsidian/cache目录，重启。
4. 显卡加速：设置里关闭“硬件加速”，有些老显卡驱动会导致渲染问题。

6.2 Git 推送失败常见原因

6.3 WorkBuddy 处理结果不稳定的调优

AI 输出不稳定是常态。我的调优经验：

• 降低温度参数：摘要、标签类任务，温度设 0.1-0.3，输出更确定。
• 提供示例：在提示词里给 1-2 个输入输出示例，模型会模仿格式。
• 分步执行：不要一个 Skill 干太多事，拆成多个小 Skill 串联。
• 加校验步骤：生成后让模型自己检查一遍格式是否符合要求。

6.4 知识库规模变大后的性能优化

笔记超过 1000 篇后，Obsidian 的图谱视图会变卡，Dataview 查询变慢。应对：

• 图谱视图限制显示范围，不要全库渲染。
• Dataview 查询加LIMIT，避免全表扫描。
• 把不活跃的笔记移到40-Archive，并从索引中排除。
• 定期重建索引（删除.obsidian/plugins/dataview/cache）。

7. 我踩过的坑与独家经验

第一个坑是过早追求自动化。一开始就想让 AI 全自动整理，结果标签乱、摘要不准，反而增加了清理成本。后来改成“AI 建议 + 人工确认”的半自动模式，质量才稳定。建议新手也从这个模式开始，跑顺了再逐步放开。

第二个坑是目录结构频繁变动。早期我改了三次目录结构，每次都要批量改链接，非常痛苦。教训是：结构设计时多花时间，定下来后至少用三个月再评估。

第三个坑是忽视 Git 提交粒度。有段时间我一周才 commit 一次，结果想回滚某个改动时发现混在一大堆变更里。现在养成习惯：完成一个逻辑单元就 commit，message 写清楚改了什么。

最后一个经验：知识库的价值在于“用”，不在于“建”。我见过太多人花大量时间折腾工具和插件，笔记却没写几篇。这套组合再强大，也只是工具。真正让知识产生复利的，是你持续输入、定期回顾、在实际问题中调用它。工具帮你降低摩擦，但替代不了思考本身。

如果你也在搭类似系统，我的建议是先跑通最小闭环：Obsidian 建库、Gitee 同步、WorkBuddy 做一个最简单的摘要 Skill。跑通后再逐步加功能。别一上来就追求完美架构，那只会让你停在配置阶段。