企业官网建设流程全解析

1. 我为什么把知识库从"搜集箱"升级成"AI加工厂"

先交代一下背景。我用了两年多的 Obsidian，插件装了四十多个，Markdown 文件攒了快 8000 个。表面上看起来，双链、标签、Dataview 样样都上了，数据资产也算丰厚。可真正到了要用的时候，问题全暴露了：

• 收藏夹里躺着大量"当时觉得有用、后来再也没打开过"的文章；
• 笔记全是碎片，没有二次加工，等于把网上的内容原样搬回家，只是换了个地方吃灰；
• 想查一个跨领域的结论时，得自己翻十几个文件，手动拼信息；
• 手机、电脑、iPad 三端不同步，很多时候灵感记在某台设备上，换设备就失踪。

普通的插件组合解决不了这些问题，因为它们做的都是"整理"的活，不是"加工"的活。真正让我的知识库活过来的，是 Obsidian + Claude + Skills + 云同步这套组合：Obsidian 管存储和连接，Claude 管理解和生成，Skills 管动作和流程，云同步管多端流通。四个组件各管一摊，合起来就是一条完整的"知识加工流水线"。

很多人以为这类方案很复杂，其实拆开看，每一层都不难，难的是把它们正确地拼起来。这篇文章把我在实践中验证过的组合方式和完整细节全部写出来，覆盖云同步选型、Claude 接入、Skills 机制、目录设计、插件配置、采集加工流程、以及我踩过的坑。适合已经用过 Obsidian、想进一步让 AI 深度参与知识管理的人，也适合还没建库、想一步到位的新手。

先说一个反直觉的结论：这套方案里最不值钱的是 AI 模型本身，最值钱的是你给 AI 定义的那套"动作规则"，也就是 Skills。后面我会专门解释为什么。

2. 云同步方案选型：先想清楚数据放哪，再动手建库

很多教程一上来就教你装插件、配模板，这在我看来顺序反了。知识库的地基是多端同步，如果同步方案没想清楚，后面文档一多，光解决冲突就能耗掉你一半热情。

2.1 三类主流同步方案的实际表现

第一类：官方 Obsidian Sync。配置最简单，设置里点两下就完成，加密、历史版本、端到端同步都内置。缺点是收费，一年价格不便宜，而且国内访问官方服务器偶尔延迟。如果你的笔记量不大、预算宽松、不想折腾，这是体验最省心的选择。我刚开始也试过，后来因为笔记量大、同步频率高，官方方案的性价比逐渐变得不划算。

第二类：Git 加 Obsidian Git 插件。这是程序员最熟悉的路线，每次改动自动提交，天然有版本历史，还能顺带备份到远端仓库。但它的短板很明显：移动端体验很差，手机上难以顺畅地拉取和提交；仓库大了之后 Git 操作会变慢；如果你不懂 Git 原理，冲突解决起来会很痛苦。适合个人电脑端为主、且本身会 Git 操作的场景。

第三类：Remotely Save 配合 WebDAV 或 S3 协议。这是我现在在用的方案。Remotely Save 是 Obsidian 社区里非常高频的同步插件，本身不带存储，只负责把 Vault 里的文件同步到任意兼容 WebDAV 或 S3 协议的存储服务。好处是存储服务你可以自己选，数据完全掌握在自己手里；文件以原始 Markdown 形态存在云端，不锁定格式；多端客户端都有插件支持，移动端适配不错。

2.2 我最终选择的同步架构

我把 Vault 里约 8000 个 Markdown 文件同步到对象存储服务，走了 S3 协议，用 Remotely Save 实现：

• 一台主力电脑上开启自动同步，文件改动后 30 秒内推送到云端；
• 手机和平板端 On-demand 拉取，需要时下载对应文件；
• 附件（图片、PDF 等）也一起同步，但做了目录隔离，避免附件拖慢笔记同步速度。

如果你没有对象存储，用坚果云这类支持 WebDAV 的国内服务也行，配置逻辑几乎一样，只是不同服务商对请求频率有限制，同步千万级文件时要做分批处理。

提示：无论选哪种存储，强烈建议在 Remotely Save 设置里开启"仅通过 Wi-Fi 同步"，否则移动端流量消耗会让你措手不及。

2.3 Remotely Save 配置的关键步骤

1. 在 Obsidian 社区插件市场搜索 "Remotely Save"，安装并启用。
2. 打开插件设置，切换到 S3 或 WebDAV 标签。
3. S3 方式需要填写 Endpoint、Access Key ID、Secret Access Key、Bucket 名称；WebDAV 方式需要填写服务器地址、账号、密码。
4. 设置里勾选"自动同步"，选择间隔时间；
5. 点击"测试连接"，确认返回成功；
6. 首次同步前，先检查本地 Vault 状态，最好在还没有大量文件时初始化。

这里有个容易忽略的操作：把附件目录（比如assets）和笔记目录做分级同步，Remotely Save 支持"同步指定目录"过滤，我只让核心笔记库全量同步，附件这种大文件按需拉取，手机端的流畅度会明显提升。

2.4 为什么不推荐直接同步整个电脑文件夹

也有人问我："我直接用网盘客户端同步整个 Vault 文件夹不行吗？" 行，但会踩两个坑。第一，网盘客户端通常按文件修改时间全量扫描，Obsidian 的数据库及临时文件频繁变更，会产生大量的同步请求和版本碎片。第二，Obsidian 的 Vault 配置目录里包含工作台缓存，多端同步时容易导致插件设置、工作区布局互相覆盖。最终一个简单配置问题会变成严重冲突问题。

Remotely Save 的高明之处在于它只同步data.json和 Markdown 文件，过滤掉 Obsidian 运行时的瞬态数据，这也是我换掉网盘方案之后，同步稳定度显著提升的根本原因。

3. Claude 接入与 Skills 机制：给模型装一套"职业动作"

要说清楚 Claude 怎么和 Obsidian 打通，先得弄明白 Skills 是什么。

3.1 Claude 和 Claude Code 的分工

现在大家常说的 Claude 其实有两层含义：

• 一是模型本身，你可以通过网页对话、API 接口等方式调用；
• 二是以 Claude 为代表的 Agent 开发环境（比如 Claude Code），它不只是一个聊天窗口，而是能读取你的文件目录、执行命令、调用工具、按步骤完成任务的"数字员工"。

要让 AI 真正干知识库的活，你需要的是后者——能让模型读到 Obsidian 的 Markdown 文件、能按你的规则输出规范笔记、能自动归档整理的能力。

以 Claude Code 为例，它的安装方式比较直接：先准备一个 Node.js 环境，然后通过 npm 全局安装命令行工具，装完后再在终端里登录账号，授权读取本地目录。这个过程在网上有丰富的公开资料，按官方文档走就行。装好之后，你在任意目录下启动它，它就能"看到"该目录下的文件结构。

3.2 Skills 的核心机制，别把它当成普通提示词

Skills 是 Claude Code 一类 Agent 工具支持的能力扩展机制。它的本质是：在项目目录下建立一个约定的文件夹结构，把一个完整的工作流封装成"技能包"，让 Agent 在遇到特定任务时自动加载并执行。

一个最简 Skills 包的结构长这样：

.claude/ └── skills/ └── note-processor/ ├── SKILL.md └── scripts/ └── process.py

其中SKILL.md是这个技能包的说明文件，采用 Markdown 格式写明触发条件、执行步骤、输入输出规范。Agent 会根据 SKILL.md 判断何时调用这个技能，以及如何调用。

真正的关键区别在这里：普通提示词只是给你一段话，再让 AI "尽量按这个做"，主观性很强；Skills 则把动作拆成了可执行的子步骤，每个步骤有明确输出格式，甚至可以调用外部脚本做数据处理，然后把结果返回给模型继续加工。这意味着 AI 的行为是可预期、可复现、可批量执行的，不再靠"随机发挥"。

3.3 从热门 Skills 集合到自建技能包

现在网上的 Skills 资源已经很多，最出名的一类开源 Skills 合集，把前端开发、代码审查、文档撰写等领域的 Agent 工作流整理成了一整套可直接导入的技能包。这类集合的价值在于，它把"怎么让 Claude 干活"从零散的实践变成了一套工程化的方法论。你不需要自己从零发明工作流，直接借鉴它的组织方式，再针对自己的知识库场景改造，效率翻倍。

我自己的知识库里常驻了三个自建 Skill：

第一个叫"笔记提炼器"。输入一篇原始资料（网页剪藏、PDF、会议记录），它执行这些动作：提取核心论点、列出关键证据、生成双链关键词、输出统一格式的永久笔记。处理完的笔记会自动规整到既定目录，并补充 YAML Frontmatter（标题、日期、来源、标签等结构化信息）。

第二个叫"知识问答索引器"。它扫描整个 Vault 的 Frontmatter 和正文标题，为每篇文档生成一句话摘要，汇总成总索引。这样后面用 Dataview 或全局搜索时，定位内容的速度会快得多。

第三个叫"周报生成器"。每周五下午我触发一次，它读取一周内新增修改的笔记，按主题归类，产出周报草稿。这功能看似简单，但没有 Skills 前，AI 经常抓错范围；有了明确指令后，准确性大幅改善。

4. 建库实操：目录、模板、插件三件套一次配齐

下面这部分是纯实操，照着做就行。

4.1 目录结构设计原则

知识库最忌讳的是把所有文件堆在根目录。我现在的 Vault 结构是这样的：

ObsidianVault/ ├── 00-Inbox/ # 收集箱，所有新内容先进这里 ├── 10-Project/ # 项目笔记，按项目建子文件夹 ├── 20-Area/ # 长期关注的领域笔记 ├── 30-Resource/ # 知识原料：文章摘录、文献笔记、书籍笔记 ├── 40-Archive/ # 归档，只读区，不再更新的内容 ├── 90-System/ # 系统文件：模板、设置、脚本 └── assets/ # 附件：图片、PDF

这套结构借鉴了 PARA 方法的思路，但按中文使用习惯做了调整。收集箱放最前面，编号越小越靠近日常操作；归档放在后面，避免误写入。你不需要严格照搬，但至少要有"收集区、处理区、归档区"三层的概念。

4.2 模板系统：让 AI 输出有章可循

没有模板，AI 生成的笔记格式会千奇百怪。我在90-System/templates下维护了 5 个核心模板：

图书笔记模板：

--- type: book-note title: author: status: reading rating: tags: - book created: --- ## 核心论点 ## 关键概念 ## 与我已有知识的连接 ## 行动项

文章剪藏模板：

--- type: article source: author: created: tags: - article --- ## 这篇文章在说什么 ## 我为什么收藏它 ## 三个月后这个内容还有用吗 ## 延伸思考

模板的作用不只是规范格式，更重要的是给 Claude 提供了结构化的"输出契约"。我在 Skills 里明确了"输出必须符合对应模板字段"，这样 AI 处理出来的笔记可以直接纳入知识体系，不用二次手工整理。

4.3 必装插件的功能边界

围绕这套工作流，真正高频率使用的插件其实只有几个：

Dataview。这是 Obsidian 的灵魂插件。它可以把 Markdown 库当数据库查询，按 Frontmatter 字段动态生成列表。我在很多页面嵌入了 Dataview 查询块，比如"所有正在阅读的书籍"、"本周新建的笔记"等。配合 Skills 生成的规范 Frontmatter，查询结果非常干净。

Templater。负责在新建笔记时自动填充模板内容，还能执行脚本、读取元数据。我的 Inbox 是配合 Templater 的快捷指令创建的：按一个快捷键，自动生成带时间戳、待处理标记的捕捉笔记。

自定义文件资源管理器样式。这只是锦上添花，让移动端操作更顺手。

插件间有个容易犯的错误：Dataview 查询速度和库大小强相关，如果你把所有文件都塞进一个文件夹，即便有索引也会变慢。按目录分区之后，查询范围可以限定，速度显著改善。

4.4 附件图片的嵌入策略

热搜词里"obsidian 图片怎么嵌入"问的人很多。Obsidian 默认的图片嵌入语法是：

![[image.png]]

直接把图片文件放在 Vault 里的某个路径，然后拖进笔记就会生成这种嵌入语法。如果你按我的目录结构走，建议把图片统一放到assets文件夹，并在设置里把"新附件位置"改成assets，这样多篇笔记可以共用同一图片资源，也便于同步时做大小分级。不要在笔记正文里粘贴大段 Base64 编码的图片，那样会把 Markdown 文件撑爆，同步和加载都会受影响。

5. 智能加工链路：从收集箱到永久笔记的完整流程

皮都准备好了，下面看真正的价值在哪。

5.1 采集阶段：把一切收进 Inbox

采集动作分了三种渠道：

• 电脑端看到长文，用浏览器插件快速剪藏，直接存到00-Inbox；
• 手机端看到有价值的内容，用系统的"共享-存储到 Obsidian"快捷方式，新增一条带时间戳的捕捉笔记；
• 阅读纸质书或开会时，用 Templater 快速建一条空白笔记，记录碎片想法。

我的原则是：任何新内容先进 Inbox，不在采集阶段做筛选判断。因为判断会打断记录的心流，而且很多内容当时觉得没用、后面会变有用。

Inbox 里的文件不追求格式，只要求"内容本身在"。这些原始材料会在后续加工阶段被 Claude 批量处理。

5.2 加工阶段：Claude 按 Skills 逐批消化

我每天或隔天会打开终端，在 Vault 目录下启动 Claude Code，告诉它："处理 Inbox 里所有标着status: captured的笔记，按各自类型套用对应模板，输出到 Resource 目录，处理完更新状态。"

这个过程通过自建 Skill 的编排，实际执行了四步：

1. 扫描00-Inbox，识别每条笔记的类型（文章摘录、会议记录、想法碎片等）；
2. 根据类型调用对应模板，抽取结构化字段；
3. 为笔记生成双链：在正文尾部补充"相关笔记"区，挂接 Vault 中已有主题词条；
4. 将成品移动到30-Resource对应子目录，并在原 Inbox 文件里记录处理状态。

看起来简单，但这里正是 Skills 发挥作用的地方。之前我在普通对话框里也给过类似指令，模型经常"记错"模板、漏掉字段，或者擅自改标题。一旦把规则固化到 SKILL.md 里，模型每次执行都遵循同一套流程，输出质量稳定得多。

5.3 查询阶段：让知识库自己"浮出水面"

加工完的笔记最终服务的是查询。我的查询入口有三级：

• 第一级是 Obsidian 的全局搜索，原生速度很快，适合精确检索；
• 第二级是 Dataview 查询块，适合结构化筛选，比如按标签、按状态、按时间范围；
• 第三级是 AI 问答，直接在 Claude Code 里问"我过去记录的关于习惯养成的观点有哪些"，它能跨文件检索并生成综合答案。

这里有个细节值得单列：AI 问答的质量取决于你的笔记里"结构化字段"的质量。同样问"哪些书对我影响最大"，如果 Frontmatter 里没有rating字段，AI 只能瞎猜；如果每本书都认真记录了这个字段，AI 的回答才是有依据的。

5.4 完整例子：从一段播客内容到体系内笔记

为了把整个链路串起来，我举个真实案例。

某天我听到一档播客讲"知识管理中的工作区与档案区之分"，很有共鸣。手机端随手创建一条捕捉笔记，只写了几个关键词："工作区 vs 档案区，区分标准 = 是否还会主动处理"。

第二天在 Claude Code 里执行"处理 Inbox"技能，这条笔记被标记为"想法碎片"类型。Claude 自动做了这些事：

• 补全了一条读后随笔，把"工作区/档案区"对照我的库结构做了映射；
• 识别到现有笔记里有一篇"PARA 方法实践"，于是自动加上了双链；
• 生成一条行动项："考虑清理 10-Project 中三个月未更新的项目，移入 40-Archive"；
• 把成品移动到30-Resource/知识管理子目录。

整个过程我只需要输入一句话，剩下的由 Skills 完成。这就是"知识加工厂"和"垃圾桶"的区别：内容进入知识库时就带了结构、连接和行动指向，而不是躺在里面吃灰。

6. 云同步冲突与附件图片：实测踩坑记录

再顺的工具，用久了都会遇到问题。这块我实打实踩了不少坑，写出来希望你绕开。

6.1 冲突文件的根因和应对

Remotely Save 这类同步工具的本质是"最后一次写入覆盖旧版本"。如果你两台设备同时打开同一篇笔记并先后保存，后者会覆盖前者的修改。有些插件检测到冲突会保留一份冲突副本，例如：

我的笔记 (conflict 2025-01-07 12-30-22).md

避免冲突的核心原则是：同一时间尽量只在同一台设备上编辑同一篇笔记。听起来像废话，但实际很容易踩。我惯用的缓解手段有两个：

• 移动端只负责记录新想法和查看，不在手机上进行大段改写；
• 每天开始处理前，先做一次手动同步，确保所有设备处于同一状态。

如果已经产生了冲突文件，也不用慌。按修改时间把两边内容合并即可，大部分冲突只是个别段落不同。

6.2 图片同步带来的两个隐蔽问题

第一个问题是"附件目录混乱"。很多人一开始把图片分散在笔记同级目录，同步后到处是图片文件，题目都对应不上。我后来统一到assets目录，并启用 Obsidian 的"自动更新附件链接"功能，图片引用基本不会断。

第二个问题是"大图拖慢同步"。手机拍照上传、截图、PDF 扫描件动辄几 MB，同步体验会很差。我现在对入库图片做了压缩：黑白截图用工具转成 WebP 或压缩 JPG，单张控制在 300KB 以内。知识库里放的是信息载体，不是原图仓库，原图可以放网盘，库内只保留引用所需版本。

6.3 Dataview 查询慢和失效问题

另一个高频问题：Dataview 页面显示过期数据。多数情况不是脚本写错，而是宽限期缓存没刷新。我现在的处理方式是在任意有 Dataview 查询块的页面顶部加一个手动刷新按钮，配合快捷键，强迫自己养成"改完元数据就刷新"的习惯。

Dataview 还有一个细节：查询中使用的字段名必须和 Frontmatter 里完全一致，注意大小写和全角半角符号。我见过太多人把created写成Created，结果查询结果永远为空，还以为是插件问题。

7. 长期运营视角：成本、安全与使用习惯的经验谈

工具链跑通只是起点，真正决定知识库价值的，是你能不能长期稳定地维护这套系统。

7.1 Claude API 成本怎么控制

很多人一听到"让 AI 批量处理知识库"，第一反应是贵。实测下来，处理 8000 条笔记级的内容，日常按量消耗远没有想象的那么夸张。日常增量处理 Inbox 的消耗更低，一个月下来可以控制在相当可观的预算内。关键是别让 AI 反复处理同一批文件，我会在 Frontmatter 里加status字段，已处理的内容直接跳过，避免重复消耗。

7.2 数据安全底线

知识库里的内容可能涉及个人思考、工作细节，不是所有东西都适合放云端。我的安全策略就三条：

• 云端同步仅同步"加工后的可公开笔记"，Inbox 里未处理的敏感内容不同步，仅存本地；
• 涉及账号密码、身份证号、银行信息的内容，坚决不进 Obsidian，任何 AI 工具都不该接触这类纯敏感数据；
• API 密钥、Token 等凭据务必放在环境变量中，绝不写进 Markdown 文件或者 Skill 脚本里。一旦库被同步到公共存储，密钥泄露的后果我经历过一次，教训深刻。

当然，如果你依赖云同步，最好给 Vault 整体加密，或至少加密敏感子目录。第三方工具可以做到单文件加密，成本很低。

7.3 让系统保持"每天可用"的三个习惯

我维持这套系统两年多，总结出三个对稳定性影响最大的习惯：

第一个：Inbox 每日清零。每天结束前，要么让 Claude 处理完 Inbox 里的内容，要么手动移动到待办区。绝不允许收集箱堆积超过一周，因为堆积会让你产生"这系统太乱了"的挫败感，然后逐渐放弃。

第二个：每周跑一次结构巡检。我会写一个简单的脚本，扫描所有笔记的 Frontmatter 字段是否完整、链接是否有断链、是否有长时间未更新的项目笔记。这个动作能在小问题变成大乱子之前把它解决。

第三个：定期给 Skills 做减法。技能包不是越多越好。我在初期试过十个八个 Skills，最后真正高频使用的只有那几个。技能包太多，AI 在选择调用时会犹豫，输出风格也容易漂移。保留核心技能，定期淘汰低频技能，是知识库保持稳定的重要策略。

8. 从"知识收集者"到"知识生产者"：我的真实感受

最后聊聊这套系统给我带来的本质改变，因为技术细节无论多完备，如果方向不对，也只是在加固一个错误的流程。

以前我的知识管理有一个隐蔽的问题：所有工具都在帮我"存东西"，但很少帮我"想东西"。我把大量时间花在收藏、整理、分类上，误以为这就是"知识管理"。直到 AI 参与进来，我才发现，真正有价值的部分是把信息放到自己的认知体系里重新连接、推演、应用的过程。

现在的流程是这样的：看到新信息，快速放进 Inbox；Claude 在 Skills 的约束下帮我完成信息结构化的脏活累活；我只需要做最关键的思考——它和我已有的知识有什么关系？我认同还是反对？我可以拿去做什么？这种思考频率变高了，知识库才真正开始反哺我的工作和创作。

每次我给朋友展示这套系统，总有人感叹"太复杂，学不来"。实际上，拆到最简版本，只有三件事：选好同步方案、装好插件和 Skills、每天让 Claude 处理一轮 Inbox。前两件事花一个周末就能配完，第三件事只需要每天十分钟。

如果你打算尝试，我建议不要一上来就复刻我这套完整配置。先用一个小 Vault，装 Remotely Save 和 Dataview，建一个简单的 Inbox 结构，再把 Claude Code 跑起来，写一个最简单的"笔记提炼"Skills。跑通之后再逐渐加模板、加技能、加同步策略。这个过程本身也是你理解自己知识管理需求的过程，远比直接抄别人的配置有用。