企业官网建设流程全解析

1. 为什么是“Obsidian + WorkBuddy + Gitee”这个三角组合

先说一个我自己亲历的场景。两年前我开始用 Obsidian 记笔记，一开始很爽——本地 Markdown、双向链接、标签分层，每篇笔记都有归宿。但半年后库越来越大，问题也来了：笔记堆了 1200 多篇，很多内容在记完那一刻就“死”了，我根本想不起来自己写过什么，更别说让它们互相产生关联。想靠手动整理维护双链，根本不现实。后来我陆续尝试了几种自动化方案，最后沉淀下来一套真正能跑的组合：Obsidian 负责存储与写作，WorkBuddy 负责把 AI 能力编排进知识库的工作流，Gitee 负责版本管理与跨设备同步。这三者合在一起，才叫“AI 驱动的个人知识库”。

1.1 我过去踩过的知识管理陷阱

在讲到具体组合之前，先说说为什么单打独斗都不行。

我一开始只用 Obsidian 自带的手动功能。每天花 15 分钟打标签、做双链、归档文件，坚持了不到一个月就放弃了。原因很简单：人工整理的节奏永远赶不上信息进来的速度。后来我想“也许该上个 AI 工具”，装了几个笔记类 AI 插件，但它们大多只干一件事——选中文字后总结。这种单点功能撑不起整个知识库，而且云端传输把我的本地笔记往别人的服务器上送，我心里其实不太踏实。

再后来又试过普通网盘同步，但它只解决“多设备能看到同一个文件夹”的问题，不解决“多设备改冲突了怎么办”，更不解决“哪条笔记是今天新增、哪条被我删错了”这种版本问题。知识库一旦出问题，你连“回到昨天”的能力都没有。

也就是说：存储缺智能、智能缺版本管理、版本管理又缺存储的灵活性。这三件事拆开看都不难，难的是怎么在一个系统里同时成立。

1.2 三件套各自的角色与组合逻辑

这套组合里每个工具只干自己最擅长的一件事。

Obsidian 是底座。它把知识全部存成.md纯文本文件，不锁格式，不搞私有数据库。你的知识资产就是一个个普通文件，任何工具都能读、能改、能备份。这一点是整个方案成立的根基——如果知识被锁在某个软件的私有格式里，后面的 AI 编排和 Git 版本控制全都无从谈起。

WorkBuddy 是编排层。它相当于一个 AI 自动化工作台，可以调用大模型接口，把你写好的技能（Skill）绑定到 Obsidian 的某个库目录上，实现“新增笔记后自动打标签”“定时扫描未分类内容”“基于全库内容回答提问”这类操作。通俗点说，WorkBuddy 是从外部伸进知识库的一只手，手里拿着 AI 这个大脑。

Gitee 是保险丝与时间机器。知识库本质上是一堆文本文件，那最适合的版本工具就是 Git。Gitee 作为国内平台，访问快、支持私有仓库、操作方式与 GitHub 一致，我用它做远程备份和版本回滚，同时在多台设备间拉取同一个库。它让知识库有了“后悔药”。

1.3 这套方案的适用人群

如果你符合下面任何一条，这套组合值得一试：笔记量大且已经明显失去秩序、经常在电脑和手机之间切换记录场景、希望用 AI 做“总结 / 标签 / 问答”但又不想把全库明文上传给第三方、或者只是受够了某一天误删文件后找不回来的痛。

需要特别说明的是：这不是一个开箱即用的一键方案，需要花半小时左右做配置。但它配置完之后，日常维护成本非常低，几乎不需要你再手动整理笔记。

2. Obsidian 侧的库结构设计与基础配置

2.1 安装与建库：从空目录开始

安装 Obsidian 没什么好说的，官网下载对应版本即可。关键是“建库”这一步，很多人会顺手选一个已经有大量文件的目录，结果进来就是一片混乱。我的建议是：新建一个空目录，比如D:\KnowledgeBase，然后让 Obsidian 以“库”的身份打开它。这个目录将来就是你的知识库根目录，所有笔记、附件、配置都在里面。

打开空库后先别急着写笔记。第一步是关掉 Obsidian 默认的“新笔记存放位置”那种自由散漫模式，把库结构先立起来。我目前用的目录结构长这样：

KnowledgeBase/ ├── 00_INBOX/ # 收集箱：一切未处理的内容先进这里 ├── 10_AREAS/ # 领域笔记：长期维护的知识领域 ├── 20_PROJECTS/ # 项目笔记：有明确起止时间的任务 ├── 30_RESOURCES/ # 资源库：文章摘录、书籍笔记、资料剪藏 ├── 90_ARCHIVE/ # 归档：已失效或暂时不用的内容 ├── _templates/ # 模板目录 └── .obsidian/ # Obsidian 自己的配置文件

这套结构参考了 PARA 方法，但做了一点本地化调整。核心原则只有一条：未处理信息必须先进收集箱，不允许直接在领域目录东一篇西一篇地乱建。收集箱是入口，AI 的很多任务也是从这里开始的，后面你会看到它的价值。

2.2 用 Frontmatter 给笔记加“身份证”

Obsidian 里的每篇笔记本质上是一个 Markdown 文件。想要让 AI 和脚本能高效识别笔记属性，强烈建议给每篇笔记加上 YAML Frontmatter——就是文件最开头用---包裹的元数据区域。我常用的字段如下：

--- title: "笔记标题" tags: [AI, Obsidian] aliases: - 别名1 status: published # published / draft / archived created: 2025-01-12 updated: 2025-01-15 source: "https://example.com" ---

为什么非加不可？有两个原因。第一，WorkBuddy 这种 AI 编排工具读取本地文件时，Frontmatter 是结构化最清晰的信息，它可以据此判断一篇笔记的主题、状态、时间，而不是从正文里靠猜。第二，Obsidian 生态里的 Dataview 等插件也依赖这些字段做动态查询，比如“列出本月所有 status 为 draft 的笔记”，前端字段不到位，查询就是空转。

2.3 两个帮我省时间的核心插件

插件这里我只挑两个对“三联组合”有直接帮助的，绝不贪多。

第一个是Templater。它用来生成笔记模板。我在_templates目录里放了一个标准笔记.md，里面已经写好了 Frontmatter 框架和常用章节。配合 Obsidian 的核心命令“插入模板”，新建收集箱笔记时按下快捷键，模板自动填充。这个插件解决的是“格式统一”问题，AI 后续处理时能看到稳定的结构，而不是每篇笔记一个样。

第二个是Dataview。它用来做动态查询。举个例子，我想看本周收集箱里还有哪些笔记没归档，就可以写一个查询：

```dataview TABLE file.mtime as 修改时间 FROM "00_INBOX" WHERE status != "archived" SORT file.mtime DESC LIMIT 30 ```

它不产生新文件，只是实时渲染查询结果。这套查询可以对接 WorkBuddy 的结果——比如 AI 打分后给某篇笔记标记了状态，Dataview 表格里马上就能看到变化。这是“AI 干活、人只看板”的理想状态。

2.4 设置 Frontmatter 默认模板文件

模板文件的具体内容，我分享一份可直接用的版本。放在_templates/标准笔记.md里：

--- title: "{{title}}" tags: [] aliases: [] status: draft created: "{{date}}" updated: "{{date}}" source: "" --- # {{title}} ## 摘要 ## 核心观点 ## 我的想法 ## 关联笔记 - [[]] ## 行动项 - [ ]

注意，tags数组默认留空。我希望 AI 来填标签，而不是我自己填——后面 WorkBuddy 的技能会做到这件事。模板里留出了“摘要”“核心观点”“我的想法”“关联笔记”“行动项”这几个区域，因为这些都是知识库后期检索和复用时最常看的信息。

3. 把 WorkBuddy 变成知识库的“AI 管家”

3.1 WorkBuddy 到底解决什么问题

WorkBuddy 这类工具，本质上是把大模型的能力从一个“聊天窗口”变成一个“可编排的工作流”。我见过很多人用 AI 的方式是：复制一段笔记内容，粘贴到网页对话框，让它总结，再把结果贴回来。这种方式效率极低，而且每次都要重复复制粘贴。

WorkBuddy 的思路不一样。它允许你定义一个“技能”（Skill），技能里写明：要读哪些文件、按什么逻辑处理、结果写到哪里。然后你可以手动触发、也可以设置定时任务触发，让 AI 自动在 Obsidian 库的指定目录里干活。换句话说，它把“人找 AI”变成了“AI 找活干”。

3.2 接入大模型并创建第一个技能

首次使用 WorkBuddy 时，需要配置大模型接口。这里不限定具体厂家——不管是国内大模型还是国外大模型，只要能提供 API 接口和密钥，就都能接入。我建议先选择上下文窗口比较大的模型，因为知识库笔记动不动就几千字，上下文小了很容易截断。

创建技能时，核心要填三样东西：输入源、处理逻辑、输出位置。

我用一个具体例子解释。第一个技能叫“收集箱自动打标归档”，配置思路如下：

技能名称: 收集箱自动打标归档 输入源: - 目录: 00_INBOX 匹配: "*.md" 处理逻辑: - 读取 Frontmatter（如果缺失则跳过） - 根据正文内容生成 3~5 个标签 - 判断正文主题，映射到 10_AREAS / 20_PROJECTS / 30_RESOURCES 等一级目录 - 更新 Frontmatter 中的 tags、status、aliases 输出位置: - 按判断结果移动到对应目录 - 保留原文件名

创建时不需要写代码，界面上通常有表单和流程节点，拖拽组合即可。我把这个技能命名为inbox-archiver，并且设置了运行条件：“只处理 status 为 draft 的笔记”。这样能防止 AI 反复处理已经归档过的内容，省 token 也省心。

3.3 技能实操：自动为收集箱笔记打标签和归档

前面那个技能创建好之后，第一次运行我就尝到了甜头。那几天我在收集箱里堆了 18 篇零散笔记——有关于“LangChain 的 Agent 设计”的、有关于“GTD 时间管理”的、还有几篇影评和食谱。人工整理这些大概需要一中午，WorkBuddy 处理完用了不到三分钟。

处理完之后我随手打开一篇，看到 Frontmatter 变成了这样：

--- title: "用 Retriever 模式优化 LangChain Agent 的上下文" tags: [LangChain, AI-Agent, RAG] aliases: - "LangChain Retriever" status: published created: 2025-01-12 updated: 2025-01-12 source: "" ---

标签的准确率出乎意料地高，目录也被自动移到了10_AREAS/技术/AI框架下面。这里要提醒一句：AI 不会 100% 正确，偶尔也会把影评分到技术领域去。所以不要让它“直接移动文件”，最好先把结果写进 Frontmatter，人工扫一眼再归档。我后来把技能的“移动文件”步骤从自动执行改成了“仅生成本地标记”，Obsidian 的 Dataview 表格里能看到每篇笔记的建议位置，点一下就能确认。

3.4 技能实操：基于库内容的问答与总结

第二个更常用的技能是“知识库问答”。这个技能读取全库索引（一般用文件名 + Frontmatter + 各笔记前 500 字做索引），然后结合问题做匹配生成回答。我在 WorkBuddy 里给它配置了一条 Prompt，核心意思如下：

你现在是一个知识库助手。我会给你一批笔记的标题、标签和摘要。 请基于这些内容，用简洁、准确的语言回答问题。如果笔记中没有相关信息， 明确说“当前知识库中没有找到相关内容”，不要编造。 回答末尾列出引用到的笔记文件名，以双链形式 [[笔记名]] 输出。

这个技能让我真正摆脱了“我记过什么来着？”的焦虑。以前搜笔记要靠文件名和标签猜关键词，现在直接用自然语言问：“我去年关于 Obsidian 插件性能有做笔记吗？”它会立刻定位到相关笔记文件，并给出答案和双链引用。而且由于所有内容都存在本地，我也可以把敏感问题交给它处理，不必担心全文被上传到公开模型服务。

3.5 设置定时任务，让管家“主动干活”

WorkBuddy 最有用的一个功能是定时触发。它能让技能在无人值守的情况下运行，比如每天晚上 22 点自动执行inbox-archiver，每周一早上生成一次知识库“上周新增内容摘要”。

我目前设置了三类定时任务：

定时任务的意义不在于让 AI 替你思考，而在于不让知识在角落腐烂。以前我每周整理一次笔记都嫌累，现在这个环节全部转移给了机器，我只需要在早晨通勤时打开 Obsidian 看看 Dataview 表格，确认 AI 的建议是否正确。

4. 用 Gitee 给知识库上“版本保险”

4.1 为什么选 Gitee 而不是 GitHub

聊版本管理，绕不开 Git，而国内用户马上会有个选择：用 GitHub 还是 Gitee。我的答案是 Gitee，理由很实际。

第一是速度。GitHub 在国内的访问情况不稳定，动不动就超时，push 失败会让人想砸电脑。Gitee 的服务器在国内，推送和拉取都快得多，知识库原本就是频繁小改动，体验差距非常大。

第二是私有仓库。个人知识库里有大量隐私内容，不适合公开。Gitee 的私有仓库免费额度对个人用户完全够用，访问权限控制在你自己手里。

第三是门槛一致。用过 GitHub 的人转 Gitee 零成本，一样的 Git 命令、一样的 SSH 密钥方式、一样的仓库管理界面。所以完全没有纠结的必要。

4.2 Git 环境配置与 SSH 密钥：一次性搞定

假设你的电脑还没装 Git，先去官网安装，Windows 用户注意安装时勾选“添加到 PATH”，否则后面命令行输入git会报错。

装好后打开终端，先设置身份信息：

git config --global user.name "你的用户名" git config --global user.email "你的邮箱"

然后是生成 SSH 密钥。这一步很多人卡住，其实命令很简单：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

一路默认回车即可。密钥会生成在用户目录的.ssh文件夹里，其中id_rsa.pub是公钥，id_rsa是私钥。用下面的命令打开公钥内容：

cat ~/.ssh/id_rsa.pub # 或者用记事本打开

然后登录 Gitee，进入“设置 -> SSH 公钥”，把公钥内容粘贴进去保存。这个密钥是电脑与 Gitee 服务器之间的“通行证”，配好之后推送代码不再需要输密码。

4.3 初始化远程仓库并配置 .gitignore

在 Gitee 网页端新建一个私有仓库，名字随意，比如my-knowledge-base，不要勾选“初始化仓库”选项，让它是空仓库。然后回到本地知识库根目录执行：

git init git remote add origin git@gitee.com:你的用户名/my-knowledge-base.git

接下来做一件非常重要的事：配置.gitignore，避免把 Obsidian 的临时配置和缓存推到远程。我目前的内容如下：

.obsidian/workspace.json .obsidian/cache .obsidian/plugins/obsidian-git/data.json .trash/ .DS_Store

关键是不忽略整个.obsidian目录，而是只忽略掉workspace.json这种本机界面状态文件。因为插件列表和快捷键配置其实值得做版本管理，换了设备拉下来，插件自动就恢复了。

第一次完整推送：

git add . git commit -m "init knowledge base" git push -u origin master

如果你在 Gitee 建仓库时默认分支是master，上面就用的 master；如果后端默认是main，就相应把命令改成git push -u origin main，具体看远程的提示。

4.4 自动化定时推送与误删恢复实战

手动执行git add && commit && push这件事，十个人里有九个会忘。所以我把它做成了定时任务。

Windows 下可以用“任务计划程序”，创建基本任务，触发器选“每天”，操作选“启动程序”，程序填powershell.exe，参数填下面这行：

cd D:\KnowledgeBase; git add -A; git commit -m "daily auto backup $(Get-Date -Format yyyy-MM-dd)"; git push origin master

Mac 或 Linux 用户可以用 cron，这里给一个示例：编辑当前用户的 crontab（crontab -e），加入一行：

0 22 * * * cd /Users/你的用户名/KnowledgeBase && /usr/bin/git add -A && /usr/bin/git commit -m "daily backup $(date +%Y-%m-%d)" && /usr/bin/git push origin master

这样每晚 10 点自动备份一次。万一当天没有改动，commit 会报“nothing to commit”，不影响后续 push 的正常运行。

再来说一个我真实经历过的恢复场景。有一次我手滑，把一个整理了一周的领域笔记目录整个删了。Obsidian 的回收站功能有延迟，而且我电脑上没开系统回收站。当时我心想完蛋了，后来冷静下来打开终端：

cd D:\KnowledgeBase git log --oneline -5

找到昨天自动备份的 commit 编号，然后：

git restore --source=HEAD~1 "10_AREAS/某个子目录"

目录瞬间恢复原样。那个瞬间我确定了一件事：知识库的版本保险必须配置，它不是锦上添花，而是底线保障。顺便提一句，如果你用 Obsidian 的官方同步服务，能解决跨设备同步，但解决不了版本回溯；Gitee 这套方案是双重保险，而且数据始终在你掌控之中。

5. 三联组合的日常 AI 工作流参考

工具组合搭好之后，最重要的是形成一个真正能跑通的工作流。我分享四个我每天都在用的场景，你可以照搬，也可以按自己的习惯改造。

5.1 场景一：读文章、收料、自动归档

浏览网页时看到好文章，我的习惯已经不是“复制全文粘贴到笔记”了，而是只复制文章核心段落和链接，新建一条收集箱笔记。笔记正文里只放链接、原文摘录和两三句我的即时想法，标题随手起，Frontmatter 留白。

WorkBuddy 每晚会自动处理这批笔记：把标题润色成更有信息量的格式，补上标签，提取摘要，给出建议的归档目录。第二天我在 Obsidian 里打开 Dataview 表格，按“建议目录”排序，逐个确认归档。整条流水线上，我只做最后一道闸门。

5.2 场景二：向知识库提问，AI 基于本地笔记回答

这个功能是我使用频率最高的。我的提问方式通常比较口语化，比如说“我最近研究笔记里关于 RAG 的几篇，有没有提到 Hybrid Search？” WorkBuddy 会先构建库内索引，再匹配相关笔记，最后引用双链给出回答。而且关键是它回答时会列出信息来源，也就是[[笔记名]]链接，我点进去就能判断这个答案可靠不可靠。

这里有个细节值得注意：不要把全库全部塞进一次模型请求，因为上下文长度有限。WorkBuddy 的技能里最好设置一个“取前 N 条相关笔记摘要”的步骤，我一般设定 5 条，既能覆盖主要信息，又不会把请求撑爆。

5.3 场景三：自动生成周报 / 月度回顾

我还有一个周期性习惯：每周日晚上看一遍本周知识库新增了什么。这个动作以前需要手动翻 7 天的文件，现在用一个技能搞定。它的逻辑是：

1. 获取本周新建/修改的笔记列表 2. 对每篇笔记提取三行摘要 3. 聚类出一个“本周关注主题清单” 4. 输出到 10_AREAS/周回顾/2025-W03.md

生成的周回顾文件是一个新笔记，我用它来调整下周精力分配。月底的时候，四篇周回顾会再汇总成月度知识资产报告。效果就是：我不再需要刻意复盘，因为 AI 已经把知识库里的变化整理成了一份结构化的“投资报告”。

5.4 场景四：用 Gitee Pages 做只读知识站点（可选）

如果你有一些笔记是愿意公开分享的，可以把一个单独的公开目录推到另一个 Gitee 仓库，然后开启 Gitee Pages 服务，生成一个静态网站。注意这里的关键是“隔离”：不要把整个知识库公开，而是单独维护一个public/目录，里面只放你挑好的文章，再配合 Jekyll 之类把 Markdown 渲染成网页。

这个场景适合做技术博客或者作品集，但对大多数人不是必须的。如果不想折腾，跳过没有任何影响。

6. 实测中遇到的坑与最终建议

这套组合我用了几个月，总体上相当稳定，但也不是没踩过坑。下面几个问题最有代表性，提前知道能省很多时间。

6.1 AI 输出不稳定时的兜底策略

WorkBuddy 的标签生成和文章分类，大方向上靠谱，但偶尔会翻车。最常见的问题是：它把标签生成得过于细碎，比如同一主题生成 8 个标签，导致标签体系爆炸。我的解决方法是给技能加一条硬性约束：“标签数量限制在 3~5 个，且必须使用知识库中已有的标签词表，如果新词表不存在，淘汰次优标签”。加了这条之后，标签质量提升非常明显。

另外，AI 处理长文时可能截断。只要发现某篇笔记的摘要不完整，我就把它加入“待重新处理”队列，在技能里设置重试次数为 1，并显式附加上下文窗口要求。遇到反复出问题的模型接口，就换备选模型。这里的原则是：AI 是助手，不是决定者，所以涉及移动文件、删除文件、修改正文的操作，尽量让 AI 只输出建议，由人来做最终确认。

6.2 文件同步冲突与乱码问题

多个设备同时打开同一个库，偶尔会出现 Git 冲突。比如笔记在电脑 A 和电脑 B 上同时被修改，push 的时候就会收到冲突提示。我的经验是：设置定时任务后，尽量保持“睡前电脑 A 提交一次，醒来电脑 B 拉取一次”的习惯。Obsidian 读写本地文件几乎无锁，冲突更多发生在并发提交时，控制好节奏可以把冲突概率降到很低。

如果真遇到冲突文件，Obsidian 里不会显示红色提示，但你会看到 Git 状态里出现CONFLICT字样的临时文件。解决方式很简单：用git status看看是哪几个文件冲突，手动选择一个版本保留，然后重新 add、commit、push。

中文乱码的问题也遇到过，一般出现在 Windows 下的终端编码设置。解决办法是让 Git 默认使用 UTF-8：

git config --global core.quotepath false

这一条配置对包含中文文件名的仓库尤其重要，配置后 git 输出里就不会把中文文件名转成八进制转义字符了。

6.3 私有仓库容量与多端同步的边界

Gitee 私有仓库的免费容量对纯文本知识库来说非常充裕，但如果你的库里有大量图片、PDF、音频附件，体积会膨胀得很快。我的建议是：尽量把大附件放到库外，用文件和笔记分离的方式，笔记里只保存链接。Obsidian 可以配置附件默认目录，我专门建了一个00_ATTACHMENTS目录放图片，但如果某个附件超过 10MB，就直接放到本地外部存储，不纳入 Git 管理。原因很简单：考虑到 Git 仓库体积和推送速度，纯文本以外的内容少进为妙。

如果你确实需要带附件的知识库同步，那就得做好体积规划，比如限制仓库总量不超过几百 MB，或者用 Gitee 的 LFS 功能管理二进制文件。只是对个人知识管理来说，让知识库保持“纯文本为主”是最省心的路线。

6.4 给新手的起步路线图

如果你第一次接触这套组合，我不建议一次性把所有配置全铺开，容易半途而废。我建议按下面的顺序来：

1. 先装好 Obsidian，建一个库目录，把模板和收集箱搭起来，用一周时间养成“任何内容先进收集箱”的习惯。
2. 第二周把 Gitee 仓库配上，实现每日自动推送。从这一刻起你的知识库就有备份了。
3. 第三周再上 WorkBuddy，先只配一个“收集箱自动打标”技能，别的都别碰。用两周时间观察它的输出质量，再逐步加“知识库问答”和“周回顾”。

这套节奏慢是慢一点，但每一步都稳。我自己的经验是：一次性把所有自动化都配完，前三天很兴奋，后面维护成本反而会让你放弃。从最小闭环开始，把每个环节用顺手了再加，这才是不吃灰的关键。

最后再分享一个小技巧：WorkBuddy 的技能配置是可以用 YAML 或 JSON 导出的，换新电脑时别手忙脚乱地重新配，直接把导出文件导入新环境就能恢复。Obsidian 的插件列表也可以用 Git 追踪，加上 Gitee 的版本管理，整台电脑重装之后半小时内就能还原完整知识库环境。这套组合说到底就一句话：让存储、智能化、备份各司其职，知识库才能真正“活”起来，而不是堆在那里吃灰。