企业官网建设流程全解析

最近我一直在折腾一套 AI 驱动的个人知识库方案：Obsidian 管理本地 Markdown 笔记，WorkBuddy 作为 AI 工作台，Gitee 负责多端同步与备份，三个工具各司其职。这套组合不是一时兴起，而是我换过 Notion、语雀、Typora 之后沉淀下来的最终形态。它能解决一个非常具体的痛点：你辛辛苦苦记录的笔记，大多躺在文件夹里被遗忘，而 AI 时代最好的救法，不是换个更漂亮的编辑器，而是让 AI 能直接读懂你的知识库，并在你提问时基于你自己的内容给出答案。如果你和我一样，既想要本地文件的完全掌控感，又想把 AI 用在自己的笔记上，这套流程值得花一小时搭一次。

1. 先理清思路：三联组合为什么成立

1.1 三个工具的分工逻辑

简单说，这套方案可以拆成三层：记录层、智能层、同步层。

• Obsidian是记录层，负责所有笔记的落盘、编辑、双链和可视化图谱。它最大的价值是把知识库做成纯本地 Markdown 文件，而不是绑死在某个私有格式里。Obsidian 的插件生态也足够丰富，后面要用到的 Git 同步、模板管理都能实现。
• WorkBuddy是智能层，也就是 AI 工作台。它能把 AI 能力直接接到本地目录上，让 AI 读取你的笔记、对话、总结、改写，甚至直接修改文件。可以把它理解成一个"懂你知识库的助手"，而不是那种只能泛泛而谈的聊天窗口。
• Gitee是同步层。因为 Obsidian 自带的多端同步是付费服务，而 Gitee 提供免费私有仓库，配合 Git 插件，就能实现自动备份、多端拉取和历史版本回滚。如果你愿意公开部分内容，还能用 Gitee Pages 搭建一个简单的数字花园。

打个比方：Obsidian 是书房，WorkBuddy 是图书管理员，Gitee 是放在城外保险库里的备份箱。书房负责存储，管理员负责帮你找书、整理书，备份箱负责让你即使烧了书房也能还原。

1.2 它到底解决了什么痛点

我见过太多人记笔记坚持不下去，核心原因是"输入容易、输出太难"。你用 Obsidian 写了半年笔记，真到找的时候靠全文搜索，关键词对不上就一片空白。这本质上是把知识库做成了"数字囤积"，而不是"可用资产"。

这套组合的第一重价值，是把笔记变成 AI 的上下文。我可以在 WorkBuddy 里问"我之前在哪篇笔记里记录过知识管理的 Rename 操作？"它能直接扫描本地文件，给出笔记路径和原文片段，而不是像普通聊天 AI 那样瞎编。第二重价值是同步不再费心。Gitee 私有仓库绑定 SSH 后，Obsidian Git 插件每 15 分钟自动 backup，笔记历史被完整保留，误删、误改都能找回。第三重价值是更新知识库的方式变得更自然。AI 帮你整理、补标签、建链接的过程，其实就是一种持续的深度复习。

当然，这套组合也有限制。它更适合以个人笔记为主、以 Markdown 为核心的重度使用者；如果你需要多人实时协作、复杂权限控制，那还是得用在线文档。搞清楚适合场景，才不会盲目上手。

1.3 为什么不直接用在线笔记

很多人会问：Notion 也有 AI，语雀也有 AI，为什么非要绕一圈？

关键在于两点：数据归属和灵活性。在线笔记的数据在别人服务器上，导出格式往往不完整，双链关系、附件路径、模板结构都可能丢失。而本地 Markdown 文件永远在你手里，任何编辑器都能打开，AI 工具也能直接按文件读取。更重要的是，本地库可以被 WorkBuddy、CodeBuddy 这类工具直接操作，而在线笔记的 API 权限通常都很受限，AI 往往只能读取不能顺畅地写回。

在线笔记另一个问题是上下文隔离。你在 Notion 里粘贴一堆笔记片段让它总结，它只能基于粘贴内容回答；而 WorkBuddy 是直接站在整个 vault 目录上回答，能综合多篇笔记的信息。用表格对比更清楚：

所以这套组合不是"花活"，而是从数据主权和 AI 可控性出发做出的选择。

2. 环境准备：安装三件套并把链路打通

2.1 Obsidian 安装与知识库初始化

从 Obsidian 官网下载安装包，不同平台都有安装器，装完后第一步是选择 vault 文件夹。我会建议专门建一个目录，比如D:\KnowledgeBase，后续所有笔记都放在里面。路径尽量简单，避免中文目录或中间带空格，虽然大多数情况没问题，但 Git 命令在特殊路径下偶尔会有奇怪报错。

首次打开后，进入"设置 → 第三方插件"，关闭安全模式，这样后面才能装社区插件。有一个小细节容易被忽略：Obsidian 默认会创建.obsidian配置目录，里面包含你自己的设置、快捷键、已启用插件列表，这个目录应该在 Git 里提交，因为它能让新设备打开时快速恢复环境。

接下来先装三个社区插件：

• Obsidian Git：负责自动提交和推送，是同步的核心。
• Templater：模板引擎，后面记录灵感时会非常有用。
• Dataview：元数据查询插件，可以按标签、文件夹、属性生成动态列表。

安装方法和大多数 Obsidian 插件一样：设置 → 第三方插件 → 浏览 → 搜名字 → 安装并启用。

2.2 创建 Gitee 私有仓库并配置 SSH 密钥

这是整套方案里最容易被新手卡住的地方，其实流程很固定。先在 Gitee 注册登录，点击右上角"新建仓库"，仓库名建议knowledge-base，权限选私有（如果只是自己笔记用，别选公开）。有一个关键点：创建仓库时不要勾选初始化 README，否则远程仓库有了初始提交，本地 push 时会冲突，还要先 pull 一次，麻烦。

接着在你本机生成 SSH 密钥。Windows 建议用 Git Bash 打开终端，执行：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

执行后连续回车即可，密钥默认保存在~/.ssh/id_rsa.pub。然后读取公钥内容并复制：

cat ~/.ssh/id_rsa.pub

到 Gitee 的"管理后台 → 安全设置 → SSH 公钥"里粘贴公钥，起个名字比如"我的笔记本"。验证是否生效：

ssh -T git@gitee.com

看到欢迎语就说明密钥配置成功。为什么坚持用 SSH 而不是 HTTPS？因为 HTTPS 推送时每次都要验证账号和密码，开启双重验证后还需要私人令牌；SSH 一次配置长期有效，也方便后面 Obsidian Git 插件后台自动运行，不会因为弹密码框而中断同步。

2.3 安装 WorkBuddy，把本地知识库交给 AI

WorkBuddy 是 AI 工作台/智能体类工具，不同版本的操作入口可能略有差异，但核心流程一致。第一步是从官方渠道下载安装包并登录账号；第二步找到"工作台/知识库/本地目录"相关入口，把 Obsidian 的 vault 路径添加进去；第三步给 WorkBuddy 系统授权，让它有权限读取你选择的文件夹。在 macOS 上通常是"完全磁盘访问权限"，在 Windows 上是存储权限，这些授权设置经常被忽略，而它恰恰是 AI 找不到笔记的头号原因。

添加好目录后，你可以先做一个 OpenAI 式的测试：在 WorkBuddy 对话框问一句"这个知识库里有哪些文件夹？"看它能否正确列出结构。如果可以，说明目录已经可用；如果它回答模糊或列不出来，基本就是授权没给到位，或者路径选错了。

有一点提醒：WorkBuddy 的"知识库"不是把文件上传到云端，而是建立与本地目录的连接，AI 在需要时读取相关文件。因此知识库目录不要塞大文件附件，比如几百兆的视频或压缩包，否则每次扫描都会拖慢速度。笔记库以 Markdown 文件为主，图像音频能压缩就压缩。

2.4 接入 Obsidian Git 插件，让同步自动化

现在要做的是把 Obsidian 插件和 Gitee 仓库真正连起来。我推荐先在本地 vault 目录做 Git 初始化，而不是反过来克隆远程仓库。

打开 Obsidian 的命令面板，运行"Git: Open Source Control View"查看 git 窗口；或者直接用 Git Bash 到 vault 目录执行：

cd /d/KnowledgeBase git init git add . git commit -m "init knowledge base" git branch -M main git remote add origin git@gitee.com:你的用户名/knowledge-base.git git push -u origin main

推送成功后，把 Obsidian Git 插件的设置调一下：Auto backup interval改成 15 分钟，Auto pull interval改成 30 分钟。这样 Gitee 上的私有仓库会自动收到你的笔记提交。如果多端设备在同时编辑，可能会出现自动 pull 和 push 互相打架的情况，所以我的习惯是：桌面端作为主要写入端，其他设备以读取和快速记录为主，减少冲突面。

3. 打造 AI 驱动的记录与处理闭环

3.1 用模板把散装灵感变成结构化输入

AI 处理笔记的效率，很大程度上取决于你的笔记结构是否整齐。如果没有模板，随手写的碎片笔记往往没标题、没标签、没结论，AI 即使读了也难以理解。我建议在99-Templates下建两个 Templater 模板：日记模板和灵感速记模板。

日记模板大致长这样：

--- 日期: {{date}} 周次: 情绪: --- ## 今日三件事 1. 2. 3. ## 工作日志 - ## 碎片想法 - ## 待跟进 -

灵感速记模板：

--- 标题: {{title}} 日期: {{date}} 标签: [想法] 来源: --- ## 当时的上下文 - ## 核心内容/结论 - ## 可能的行动 -

这些字段的用途很明确：日期帮助 AI 按时间检索；标签帮助它做主题聚类；"结论"字段是 AI 后续生成总结时最值得依赖的材料。模板设置好后，在 Obsidian 命令面板执行 "Templater: Open insert template" 就能选取模板插入，非常方便。

3.2 让 WorkBuddy 干活：盘点、问答、补全

WorkBuddy 装上后，你会有几种典型的 AI 工作方式。

第一种是时间维度总结。比如周五下班前可以问："请分析日记目录下最近一周的笔记，提取出 5 个关键工作项，并列出每项的完成状态和下一步建议。"它会在读取多个文件后输出结构化周报，比你自己翻笔记快得多。

第二种是跨笔记检索。问法要具体："我之前在哪篇笔记里写过 Python 装饰器相关的使用心得？请给出笔记路径和原文要点。"注意让它给出路径，既方便你对照，也能避免它胡编。

第三种是补全元数据。我常做的一件事是：把一篇旧笔记丢给 WorkBuddy，"请扫描这篇文章的核心思想，在 frontmatter 里补上合适的标签和 aliases，并在末尾补一句 100 字以内的摘要"。它可以直接写回文件，但我的习惯是先让它输出"将要修改的内容"，确认无误后再让它执行写回，这样能避免 AI 改动你原有的结构。

还有一种是提炼双链。比如我有一批关于知识管理的笔记，彼此没有关联，我会让 WorkBuddy 扫描整个02-Areas目录，找到主题相似的三组笔记，并为每组建议互相引用的理由。它列出来之后，我手动到 Obsidian 里添加[[双链]]，知识图谱一下就活了。

3.3 写一个 Skill，稳定输出"知识库助手"

WorkBuddy 这类 AI 工作台常用"Skill"机制来固化某个场景的指令。你可以把它理解成给 AI 设定一个稳定的人设和工作流程，避免每次都要重复叮嘱。

我在自己环境里建了一个knowledge-base-assistantskill，内容大致如下：

名称：knowledge-base-assistant 适用场景：Obsidian 知识库通用助手 角色：你是我的知识库管家，回答必须基于库内已有内容，不臆造、不编造笔记名。 工作流程： 1. 回答前先读取 _AI_GUIDE.md，了解目录结构。 2. 根据问题定位到相关笔记，优先引用原文。 3. 回答时列出参考笔记的完整路径，便于我核对。 4. 如果库内没有找到相关信息，明确说"未在知识库中找到"，再给出通用建议。 输出要求： - 使用 Markdown 格式。 - 输出顺序：结论 -> 依据 -> 建议。 - 不得虚构标签、标签名或笔记标题。

这个 skill 文件在电脑上的保存位置可能因版本而异，有的是在用户目录下的.workbuddy/skills/，有的可以在应用内直接编辑。不必太纠结具体目录，关键是内容本身。设置后，我的提问质量明显提升，尤其是"回答必须基于库内内容"这条，能挡住 AI 绝大多数幻觉问题。

3.4 自动同步与版本回滚

有了 Obsidian Git 插件之后，Gitee 私有仓库会持续积累每次修改的历史版本。这就给 AI 自动改文件提供了安全网：即使 WorkBuddy 写坏了一篇文章，也能随时从 Git 历史里恢复。

需要做版本恢复时，打开 vault 目录的 Git 命令行：

git log --oneline

找到想回退的提交哈希，然后执行：

git checkout <commit> -- 路径/文件名.md

这条命令只恢复指定文件，不影响其他内容，比整体回滚安全。恢复完成后，如果你想把这个回滚同步到云端，再执行git add、git commit、git push；如果只想本地改回，不 push 就可以了。也可以在 Gitee 网页端直接查看提交记录和文件历史，某些时候网页端看 diff 反而更方便。

一个小经验：自动备份时间设太短会频繁产生提交，信息噪音太大；设太长又失去保护意义。我实测 15 分钟比较合适，工作日持续写作时一天大概会生成三四十个提交，回查历史时粒度刚好。

4. 知识库架构：让 AI 回答更准确的底层设计

4.1 目录结构与命名规则

很多人的知识库是从"一个文件夹堆到底"开始的，AI 接手后很难分清不同笔记之间的关系。我后来改成了简化版 PARA 结构，目录专门做成：

KnowledgeBase/ 00-Inbox/ # 临时收件箱，未整理的想法 01-Projects/ # 有明确目标和截止日期的事项 02-Areas/ # 长期关注的领域，比如知识管理、健康、理财 03-Resources/ # 参考资料、书摘、主题收集 04-Archive/ # 不再活跃但需要保留的内容 99-Templates/ # Obsidian 模板

这个结构的核心思想是：按"行动状态"而不是"主题类型"归档。比如"AI 工作流"属于长期关注，放02-Areas；"本月读书笔记"如果只是阶段性项目，可以放01-Projects之后归档。AI 读取时，目录名本身就提供了重要的语义信号，比让它在几百个无规则文件里猜要准确得多。

文件命名也有诀窍。我的规则是：文件名尽量简短、唯一、用短横线连接。比如obsidian-git-sync.md、workbuddy-skill-guide.md。文件名避免日期开头，否则同一天塞多条笔记还得加序号，反而不利检索。标签建议保持粗粒度，不要造出一堆从未用过的标签；每篇笔记最好有一个"结论摘要"段，这是 AI 回答时最直接的信息来源。

4.2 给 AI 的说明书：_AI_GUIDE.md

如果你希望 WorkBuddy 每次回答都符合你的预期，最好在知识库根目录放一个专门给 AI 读的说明文件，也就是前面 skill 里提到的_AI_GUIDE.md。它相当于知识库的"使用说明书"，AI 在读库时优先参考。

我写的_AI_GUIDE.md内容大致是这样：

# 知识库使用说明（供 AI 参考） 1. 本库全部是我的个人笔记，回答需忠实于原文，不能编造笔记标题。 2. 目录结构采用 PARA 简化版： - 00-Inbox：临时想法，整理前内容可能不完整。 - 01-Projects：有明确目标和截止日期。 - 02-Areas：长期关注的领域。 - 03-Resources：参考资料。 - 04-Archive：已归档内容。 3. 标签规则：优先使用 #ai、#workflow、#reading 等粗粒度标签。 4. 常用术语：双链指 [[]] 形式；vault 指整个知识库目录。 5. 当用户询问"我有没有写过..."，应先在 02-Areas 和 03-Resources 中搜索。 6. 回复格式：结论 -> 参考笔记路径 -> 补充建议。

这个文件不需要多长，但非常管用。它让 AI 在每次对话开始时就理解库的结构，不用我在每次提问时重复背景信息。实测下来，回答的准确率和文件路径引用率都明显提高。

4.3 定期用 AI 做知识库健康度检查

知识库维护不能只在写作时进行，最好每月做一次健康度检查，而这个检查完全可以交给 WorkBuddy。我常用的提示词是：

"请扫描整个知识库，找出孤立的笔记（没有被任何笔记通过双链引用），按文件夹分组列出；再找出三个月内未更新的02-Areas笔记；最后检查标签使用频率，列出使用次数少于 2 次的标签。"

AI 输出的结果就是一份现成的维护清单。我拿着它去 Obsidian 里逐项处理：孤立笔记该补充双链的补，不再有价值的移入归档；低频标签要么删除、要么统一成一个更通用的标签。这个过程不需要写脚本，只需要提示词和人工确认，每个月花十几分钟，知识库就不会腐烂成一堆死文件。

5. 常见问题与排查实录

5.1 启动、链接和插件类问题

先说两个最常踩的坑。第一个是 Obsidian 突然打不开。大多数情况是组件配置损坏，尤其是.obsidian/workspace.json这个文件记录了工作区布局，偶尔会损坏导致启动卡死。处理方式是关闭 Obsidian，打开 vault 目录，把.obsidian/workspace.json临时转移到别处，再启动 Obsidian，它会重新生成一个默认工作区。如果还不行，在 Windows 上检查任务管理器里是否残留 Obsidian 进程，全部结束后再启动。

第二个坑是关于 Typora 读不出 Obsidian 附件。Obsidian 默认插入附件用的是![[图片.png]]这种 wiki 链接，Typora 根本不识别这种语法，而且附件默认可能放在 vault 根目录，超出了 Typora 的相对路径范围。解决办法是在 Obsidian 设置里把"附件默认存放路径"改为"当前文件所在文件夹下的指定附件文件夹"，同时把新插入图片的链接格式从 wiki 改为 Markdown 标准链接。已经存在的旧附件可以统一移动目录后再批量替换。

插件页面还可能出现"Git commit failed"之类的报错，绝大多数是因为 Git 没配置用户信息。在 vault 目录执行：

git config user.name "你的名字" git config user.email "你的邮箱"

如果 Windows 下路径过长，Git 会报"Filename too long"，执行git config --system core.longpaths true即可。

5.2 Git 与 Gitee 操作失误

第一次推送时最常遇到的，就是远程仓库已经初始化过 README，导致本地git push被拒绝。解决方法是先执行git pull --rebase origin main，把远程初始提交拉下来再推。为了避免这种麻烦，我在前面强调过：创建仓库时不要勾选初始化 README。如果你已经创建了，直接在 Gitee 删除仓库重建一个也可以，反正私有库没有历史负担。

SSH 认证失败也出现过。检查步骤很简单：确认公钥已经粘贴在 Gitee 的 SSH 公钥列表里；确认你复制的是.pub文件而不是私钥文件；如果在 Windows 多账号环境，最好在~/.ssh/config里给gitee.com指定独立的IdentityFile。执行ssh -T git@gitee.com出现 Welcome 信息，就说明认证没问题。

还有一个跟分支名有关的问题。Gitee 仓库默认分支可能是master，而我在本地初始化时习惯git branch -M main，推送前要确认分支名一致。如果不一致，可以在 Gitee 仓库设置里修改默认分支，或强制把本地分支名改成 master。

关于 Gitee 开源许可证怎么选，这是很多人建公开仓库时会纠结的。如果只是私人备份，什么都不用选；如果将来要公开，且你希望任何人都能自由使用、修改、商用，选 MIT 最省事；如果还希望包含专利保护和免责声明，选 Apache-2.0；如果你不希望别人直接抄去做闭源商业项目，才会考虑 GPL-3.0，但它的"传染性"比较强，不适合普通知识笔记类仓库。知识文档类内容如果想要"署名-非商用-相同方式共享"，可以手动添加 CC BY-NC-SA 4.0 的 LICENSE 文件，Gitee 创建时不一定列出这个选项，但仓库内直接放文件即可。

5.3 WorkBuddy 连接异常与回答跑偏

WorkBuddy 最常见的问题是说我"找不到知识库"。先看两处：一是添加目录时用的路径是否就是 Obsidian 的 vault 根目录；二是系统授权里是否给了它读取该目录的权限。macOS 如果第一次授权时点了拒绝，要去系统设置里重新打开权限再重启应用，光重启钱包不解决。

回答跑偏则大概率是上下文没收紧。如果你问它"我有哪些待办"，它可能从各种文件里猜。正确做法是明确限定路径："请只读取00-Inbox和日记/本周目录下的内容，列出待办事项。"还有就是把_AI_GUIDE.md的规则写得再具体一点，比如明确告诉它哪些目录优先、哪些目录只是归档，AI 的检索行为会明显改善。

修改笔记后没保存，或者保存的格式乱了，这也需要排查。先确认 WorkBuddy 是否有写权限；然后建议在 skill 里加上一条"写回前先输出将要修改的文件路径和变更摘要"，让我确认。毕竟 AI 改文件是顺手的事，但改坏结构也是顺手的事，这个确认步骤不能省。

5.4 安全、隐私与开源许可证选择

这套方案把笔记推到 Gitee 私有仓库，安全级别比纯本地低了一层，所以有几条红线必须守住。第一，不要在知识库里明文存放账号、密码、API 密钥、私钥这类敏感信息；即使仓库是私有的，也最好不要。第二，在 vault 根目录添加.gitignore文件，把.env、secrets.md这类文件排除在 Git 之外。第三，Gitee Pages 如果开启，意味着仓库内容会被公开访问，千万不要把整个知识库直接发布，尤其不能包含日记和隐私笔记。

如果你想公开知识库的一部分，我的建议是建一个单独的"发布仓库"，用脚本把03-Resources里精选内容复制过去，再单独管理这个公开仓库。这样既不影响私人知识库的完整性，也方便维护。

WorkBuddy 这类 AI 工作台在调用大模型接口时，可能会把部分内容作为上下文发送到模型服务端。所以在往知识库里放难以公开的资料之前，先确认你使用的工具和服务的数据政策。我的原则是：公开场合可以写的，放知识库；真正敏感的，只用纸笔或者专业加密方案。不要因为本地路径看起来安全就掉以轻心。

多说两句我自己的体会。这套组合真正让我留下来的，不是某个炫酷插件，而是"记录-提问-修正-备份"这个循环变得特别顺。以前我写完全靠回忆，现在我会顺手给 WorkBuddy 发一句：把今天这条新想法和02-Areas/知识管理里那篇旧笔记做个对比，如果冲突，在笔记底部写一句差异说明。它真的会帮我改文件，我只需要在 Obsidian 里 review。最后分享一个小技巧：每次让 WorkBuddy 改文件前，我都会先让它输出 diff 或"将要修改哪些文件"，确认后再执行写回；这个习惯能避免 AI 顺手改坏你好不容易整理的结构。知识库这件事，坚持比完美更重要，AI 只是让坚持变得更轻松。