企业官网建设流程全解析

最近很多人都在讨论“是否还要继续使用 Obsidian”。我的观点很直接：不要删，而且应该把它放到 AI 工作流的中心位置。Obsidian 可能不是最花哨的笔记软件，但它最大的价值是——你所有笔记都是本地 Markdown 文件，这个特性在 AI 时代反而是最稀缺的。你的知识库是开放的、可控的、可编程的，这正是接入 AI 的最佳底座。

这篇文章会从实际使用角度出发，讲清楚 Obsidian 在 AI 时代的工作流定位，包含 Obsidian 的 AI 插件选型、本地模型接入、外部工作流编排、批量任务处理、API 接口调用等。内容偏实操，建议收藏后按步骤配置。

1. 核心能力速览

先说清楚 Obsidian 本身的定位和它在 AI 工作流中的能力边界。

需要说明的是，Obsidian 本身不包含 AI 功能。它提供的是数据存储、组织和扩展能力，AI 能力通过插件、脚本或外部工作流工具接入。这是理解整个工作流的关键。

2. 适用场景与使用边界

2.1 适合谁

• 知识库深度用户：已经有大量 Markdown 笔记，想把笔记内容和 AI 结合起来做问答、摘要、标签推荐。
• AI 应用开发者：需要给自己的 AI 应用准备结构化语料，Obsidian 是一个很好的语料管理界面。
• 内容创作者：用 AI 辅助写作时，需要本地素材库支撑，Obsidian 的模板和链接机制可以减少重复整理。
• 自动化爱好者：已经使用 n8n、Dify、Coze 等工具，想把 Obsidian 作为知识存储节点接入。

2.2 不适合谁

• 需要云端多人实时协作的场景，Obsidian 的同步能力不如 Notion、飞书。
• 需要复杂数据库视图和权限管理的团队知识库。
• 完全不想折腾本地插件和脚本的用户，Obsidian 的 AI 集成需要一定动手能力。

2.3 使用边界与合规提醒

这里必须强调几点：

• 如果你的笔记中包含他人隐私、公司内部信息、受版权保护的资料，不要直接把这些内容发送到外部大模型 API，优先使用本地模型或私有化部署模型。
• 使用 AI 辅助写作时，AI 生成的内容可能涉及版权风险，商用前需要人工复核。
• 本地知识库的备份仍然需要自己做，Obsidian 默认不做云同步，删除笔记前务必确认 Git 或备份工具已经配置好。
• 使用第三方 AI 插件时，注意插件权限，不随意将整个 Vault 的文件内容发送给不确定的服务商。

3. 环境准备与前置条件

以 Windows 和 macOS 为主，准备一套可运行的 Obsidian AI 工作流环境。没有具体版本锁死，按通用流程来。

3.1 操作系统与基础软件

• Windows 10/11 或 macOS 12+，Linux 也可以但部分插件支持稍弱。
• Obsidian 本体，建议安装最新稳定版，Vault 路径建议使用纯英文路径，避免部分 Python 脚本解析路径出错。
• Git（可选），用于知识库版本管理。
• Python 3.10+（可选），用于批量脚本处理。
• Node.js 18+（可选），部分插件依赖 Node 环境运行辅助脚本。

3.2 AI 模型通道

根据你的隐私需求和硬件条件，二选一：

方案 A：本地模型（推荐）

使用 Ollama 或 LM Studio 部署本地大模型，优点是数据不出本机、免费、离线可用；缺点是模型能力上限受硬件限制。

# 安装 Ollama 后，拉取一个适合知识库问答的中小模型示例 ollama pull qwen2.5:7b ollama run qwen2.5:7b

方案 B：云端模型 API

使用 OpenAI 兼容接口、国内大模型 API 或其他兼容服务，优点是模型能力强、无需本地 GPU；缺点是需要联网，注意数据合规。

关键点：选择支持 OpenAI API 格式的服务，后面插件配置会简单很多。

3.3 磁盘与端口

• Obsidian 本身占用很小，但模型文件较大。本地模型 7B 量化版大约需要 5GB 到 8GB 磁盘空间。
• 常用端口检查：Obsidian Local REST API 默认端口是 27123，外部工作流工具 Dify/n8n 端口以各自默认端口为准，如果冲突需要提前调整。

4. Obsidian 的 AI 插件生态选型

目前 Obsidian 社区里，以下几类插件是工作流里最常用的，按用途分类。

4.1 Copilot 类插件（对话问答）

核心功能：在 Obsidian 内部唤起对话面板，可以把当前笔记、选定内容、整个 Vault 内容作为上下文，调用大模型 API 进行问答。

配置注意点：

• 在插件设置里填入 API 地址、API Key、模型名称。
• 如果使用 OpenAI 兼容的本地服务，API 地址填写本地服务地址，例如http://127.0.0.1:11434/v1。
• 如果使用云端服务，按服务商提供地址填写。

4.2 Smart Connections 类插件（语义检索）

核心功能：对笔记内容做向量化处理，当你打开一篇笔记时，自动推荐内容关联的笔记，并可以通过语义检索找到相关内容。

使用这个插件前需要确认本地环境能否运行 Python 脚本或 Node 服务，因为这个插件依赖本机嵌入模型进行向量提取。

4.3 自动标签与元数据补全

核心功能：读取笔记正文，调用 LLM 生成标签、摘要、关键词，写入 frontmatter。这类插件适合批量整理旧笔记。

4.4 Local REST API 插件

核心功能：给 Obsidian 启用一个本地 HTTP 接口，外部程序可以读取、创建、修改 Vault 内的 Markdown 文件。

这个插件是工作流自动化的关键桥梁，后面单独讲。

4.5 模板与自动化插件

• Templater：支持类似代码模板的笔记创建，可以嵌入 AI 请求脚本。
• QuickAdd：一键捕获输入内容，并执行自定义脚本。
• Obsidian URI：通过 URL 唤起 Obsidian 并执行命令，适合从外部工具跳转。

5. Obsidian 与 AI 工作流的使用场景示例

下面按真实工作流顺序演示。

场景一：每日笔记 + AI 摘要

目标：写一篇每日笔记，保存后自动生成摘要、提取待办事项。

思路：通过 QuickAdd 或 Templater 创建模板，在模板中配置脚本调用本地大模型 API，将生成的摘要写入 Properties 字段。

示例模板片段：

--- date: {{date}} summary: "{{date}}" tags: - daily --- # {{date}} 工作日志 ## 今日重点 ## 待办事项 ## 记录

假设你想用脚本自动生成摘要，可以在笔记创建后运行一个 Python 脚本读取当前笔记内容并调用本地 API 写入 frontmatter。具体脚本可参考后续章节。

场景二：知识库问答

目标：不使用外部向量数据库，直接用 Obsidian 中的 Markdown 文件作为检索源进行问答。

一个轻量方案是：

1. 用 Smart Connections 插件做语义索引，快速定位相关笔记。
2. 将相关笔记内容复制或通过 API 传给大模型，获取答案。

如果追求自动化，可以把 Obsidian 的 Local REST API 接到 Dify 工作流里，Dify 通过 API 定期拉取笔记或由用户触发检索，大模型基于检索结果生成答案。

场景三：AI 辅助写作与博客生成

目标：利用 Obsidian 管理素材，AI 补全初稿。

流程是：

1. 在 Obsidian 里记录素材、灵感片段。
2. 通过 Templater 生成文章框架，包含标题、目录、素材链接。
3. 用 Copilot 类插件对选中素材做扩展和整理，生成初稿。
4. 人工校对后发布。

场景四：批量标签补全和内容清洗

目标：老笔记清洗。比如有 500 篇没有标签的笔记，不需要手动慢慢整理。

思路：编写脚本读取 Vault 下所有 Markdown 文件的 frontmatter，检测到缺少 tags 字段时，调用大模型 API 生成标签并回写文件。

import os import requests import re vault_path = "D:/MyObsidianVault" def get_tags_from_llm(content): prompt = "请从下面的内容中提取3到5个标签，只输出标签列表，用英文逗号分隔。\n\n" + content[:2000] payload = { "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": prompt} ], "stream": False } try: response = requests.post("http://127.0.0.1:11434/v1/chat/completions", json=payload, timeout=60) data = response.json() result = data["choices"][0]["message"]["content"].strip() return result except Exception as e: print("调用失败:", e) return None for root, dirs, files in os.walk(vault_path): for name in files: if not name.endswith(".md"): continue file_path = os.path.join(root, name) with open(file_path, "r", encoding="utf-8") as f: text = f.read() if "tags:" in text: continue tags_text = get_tags_from_llm(text) if not tags_text: continue # 简单写入 frontmatter，实际使用请检查是否已有 frontmatter 块 if text.startswith("---"): # 保留已有 frontmatter，追加 tags 字段 parts = text.split("---", 2) parts[1] = parts[1] + f"tags: [{tags_text}]\n" new_text = "---".join(parts) else: new_text = f"---\ntags: [{tags_text}]\n---\n\n" + text with open(file_path, "w", encoding="utf-8") as f: f.write(new_text) print("已处理:", file_path)

这段代码的思路是遍历 Markdown 文件，只处理没有 tags 字段的笔记，一次调用本地模型生成标签。实际使用时要先在小范围内测试，避免批量误改。

场景五：使用 Local REST API 将 Obsidian 接入 n8n/Dify

目标：把 Obsidian 当作知识库读写接口，外部工作流编排工具可以读取笔记、创建笔记。

前提是安装 Local REST API 插件并启用服务。

常用接口示例：

# 获取当前活跃笔记内容 curl -X GET "http://127.0.0.1:27123/current" \ -H "Authorization: Bearer YOUR_API_KEY"

# 创建新笔记 curl -X POST "http://127.0.0.1:27123/notes" \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"filename": "test-note", "content": "hello world"}'

拿到这个接口后，n8n 或 Dify 就能把 Obsidian 当成一个可读写的“文件系统节点”来编排工作流。比如：用户在飞书或群聊里发送一条消息，n8n 接收后调用 Obsidian API 搜索相关笔记，再把结果发给大模型生成回复，最后回写到 Obsidian 作为对话记录。

6. 本地模型接入与 API 调用示例

如果你的机器配置一般，本地模型推荐从 7B 或 8B 量化版开始，不盲目追求大模型。日常知识库摘要、标签生成和中等难度的问答，7B 级别模型够用。

下面用一个简单的 Python 示例演示如何调用本地模型 API 参考 Obsidian 笔记内容。

import requests import json # 假设已经通过 Local REST API 或直接读取文件拿到笔记内容 note_content = """ # 项目复盘 这次迭代最大的问题是需求变更频繁，导致开发排期被打乱。 """ prompt = f""" 你是一个项目复盘助手。请根据以下内容总结出三个关键问题和两个改进建议。 内容： {note_content} """ payload = { "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": prompt} ], "temperature": 0.3, "stream": False } response = requests.post( "http://127.0.0.1:11434/v1/chat/completions", json=payload, timeout=120 ) if response.status_code == 200: result = response.json() content = result["choices"][0]["message"]["content"] print("AI 分析结果：") print(content) else: print("请求失败:", response.status_code, response.text)

调用模型 API 后，可以将结果追加回笔记底部，或者写入 frontmatter 的 summary 字段。

7. 批量任务与自动化脚本实践

Obsidian 在批量任务上有天然优势，因为每个笔记都是纯文本文件。下面给两个通用实践方向。

7.1 批量处理笔记内容

可以用 Python 脚本对 Vault 做全量分析：

• 统计所有笔记的标签分布。
• 识别没有建立双向链接的孤立笔记。
• 检查哪些笔记超过 3000 字，需要拆分。
• 找出所有 Markdown 链接指向不存在文件的断链。

脚本可以结合os.walk遍历 Markdown 文件和requests调用 AI，整体思路并不复杂，但要注意做好备份。

7.2 批量生成文章草稿

可以准备一个 CSV，里面包含 50 个标题和对应素材，然后写脚本逐条调用大模型生成段落初稿，保存为 Markdown 文件到 Vault 的指定文件夹。这种方式适合需要批量产内容草稿的场景。

示例批量生成脚本模板：

import csv import os import requests output_dir = "D:/MyObsidianVault/AI Drafts" os.makedirs(output_dir, exist_ok=True) with open("topics.csv", "r", encoding="utf-8") as f: reader = csv.DictReader(f) for row in reader: title = row["title"] source = row["source"] prompt = f"基于以下资料，写一篇技术博客草稿，语言中文，结构清晰。\n标题：{title}\n资料：{source}" response = requests.post( "http://127.0.0.1:11434/v1/chat/completions", json={ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": prompt}], "temperature": 0.7 }, timeout=180 ) if response.status_code == 200: content = response.json()["choices"][0]["message"]["content"] file_path = os.path.join(output_dir, title.replace("/", "-") + ".md") with open(file_path, "w", encoding="utf-8") as out: out.write(f"# {title}\n\n{content}") print("生成:", file_path) else: print("失败:", title, response.status_code)

批量任务建议加日志和失败重试，比如把失败的标题保存到一个文件里，方便二次处理。

8. 资源占用与性能观察

8.1 Obsidian 本身占用

Obsidian 本体的 CPU 和内存占用很低，启动后空载大约几百 MB 内存。但是如果你开启了大量插件、且 Vault 中文件很多，启动速度会变慢，图谱视图渲染也可能卡顿。这是正常现象，重点看插件数量而不是笔记数量。

8.2 本地模型显存和内存占用

以 7B 量化模型为例：

• CPU 推理：内存占用通常在 6GB 到 10GB，速度偏慢，但可接受。
• GPU 推理：显存占用通常在 5GB 到 8GB，具体看量化等级和上下文长度。
• 如果显存不足，可以减小上下文长度、调低num_ctx、使用更小模型或者量化等级更高的模型。

这里的数字是通用经验，实际请按本机测试为准。可以用任务管理器或nvidia-smi观察占用。

8.3 如何降低资源占用

• 不要同时开启多个 AI 插件，需要哪个开哪个。
• 本地模型选择量化版本，而不是满精度版本。
• 批量任务时控制并发数量，避免同时多个请求压爆内存。
• 如果 Obsidian 启动变慢，检查是否有插件在启动时执行索引任务，比如 Smart Connections 这类向量化插件。

9. 常见问题与排查方法

以下表格是常遇到的问题和排查思路。

10. 最佳实践与使用建议

10.1 建立一套最小可运行配置

在开始折腾所有功能之前，先建立一套最小配置：

• 一个专门的测试 Vault，不要直接在主 Vault 里测试插件。
• 安装 Copilot 类插件和 Local REST API 插件，配置好 API 地址。
• 创建一篇测试笔记，验证对话、摘要、标签生成功能。
• 确认 API 能正常读写笔记。

10.2 目录和文件命名规范

把 Vault 按功能分区：

Vault/ ├── 00_Inbox/ # 临时捕获 ├── 01_Projects/ # 项目笔记 ├── 02_Areas/ # 领域知识 ├── 03_Resources/ # 素材与资料 ├── 04_Archive/ # 归档 └── Templates/ # 模板

AI 批量生成的文件统一放入一个带日期的子目录，避免污染主目录。脚本生成的草稿和人工审核后的文件用不同文件夹区分。

10.3 备份策略

AI 批量处理脚本可能会误改文件，必须做备份：

• 使用 Git 管理 Vault，每次批量修改前提交一次。
• 或者使用文件夹同步工具，保留多版本快照。
• 生成类脚本先输出到新文件夹，不要直接覆盖原文件。

10.4 提示词沉淀

把常用的 AI 提示词保存为 Obsidian 笔记或模板，后续可以复用。例如：

• 总结摘要提示词。
• 标签生成提示词。
• 文章初稿提示词。
• 会议纪要提取提示词。

10.5 合规与安全实践

• 涉及人脸、声音、非公开资料的 AI 处理必须确认授权，Obsidian 工作流也一样。
• 外部 API 服务要限制访问范围，不要把你的 API Key 写死在公开脚本里。
• 对于公司内部知识库，优先使用本地模型方案，数据不出机器。
• 定期检查插件是否有更新，旧插件可能存在兼容性和安全问题。

11. 总结与下一步

如果你在纠结“要不要删 Obsidian”，我的建议是：不要删，但也不要把它当成普通笔记软件用。它最值得尝试的点是作为 AI 工作流的本地知识底座，先把 Local REST API 和本地模型通道跑通，之后无论是接 Dify、n8n 还是自己写脚本，都能有一个统一的知识存取入口。

最先应该验证的功能是：在 Obsidian 里打开一篇笔记，调用本地模型生成摘要和标签，观察输出质量和响应时间。这个场景最容易上手，也能最快判断你的硬件配置是否能支撑后续更多 AI 功能。

最容易踩的坑是两个：一是把云端 API Key 直接写在插件配置或脚本里，导致密钥泄露；二是批量脚本没有备份直接覆盖了 Vault 文件。

后续可以继续扩展的方向包括：

• 用快照版本控制加 Obsidian 搭建个人知识版本管理。
• 把 Obsidian 笔记通过 API 接入 Coze、Dify 或 n8n 构建自动写作流程。
• 使用本地嵌入模型构建个人知识库语义检索。
• 将 Obsidian 与 Cursor 或 Codex 结合使用，用代码解释和生成脚本处理批量笔记任务。

如果你还没安装 Obsidian，可以先去官网下载。如果下载太慢，可以从常规镜像渠道获取安装包进行安装，注意从可信来源下载。安装后创建本地 Vault，再按本文顺序开通 AI 通道，整个工作流半小时内可以跑通。建议收藏备用，后面需要时可以按步骤查阅。