企业官网建设流程全解析

最近不少朋友问我：“AI都这么强了，为什么还要用Obsidian这类笔记软件？” 甚至有人因为AI工具的兴起，觉得本地笔记是多余的，逐渐删掉了自己维护多年的知识库。我在几个实际项目里尝试“AI + 笔记”的组合方式后，反而得出一个相反的结论：AI 越强，Obsidian 这种“本地优先”的知识库就越值得保留。原因很简单——AI 模型本身没有记忆，它只在你提问的那一刻根据上下文工作；而 Obsidian 可以充当一个长期、稳定、可检索且归属于你自己的“外部记忆系统”。

这篇文章不会劝你把Obsidian当作唯一的知识管理工具，也不会神话某个AI插件。我会从实际落地角度，讲清楚为什么AI时代不该删除Obsidian，以及如何用Obsidian构建一套完整的AI工作流，包含环境准备、核心概念、插件方案、Python 自动化脚本示例、常见问题排查，以及我实践中沉淀出的工程化建议。如果你是 Obsidian 新手，能照着搭出第一条流程；如果你已经用了很久，也能从“如何让 AI 更懂你的笔记”这个视角，重新审视自己的知识库结构。

1. AI时代，为什么还要坚持用Obsidian？

1.1 大模型没有记忆，这是最核心的痛点

无论是 ChatGPT、Claude、DeepSeek，还是本地部署的 Llama、Qwen，它们本质上都是“无状态”的模型。你打开一个新的对话窗口，它就忘掉了上一轮聊了什么；就算在同一个窗口里，超过上下文窗口长度之后，较早的内容也会被截断或压缩。要想让AI长期理解你的项目背景、个人习惯、团队规范，就必须在外部构造一个“长期记忆仓库”。

这个仓库放在哪里最合适？用数据库太重，用普通的文档目录太散，用云笔记又担心数据隐私和迁移成本。Obsidian 的所有数据都以 Markdown 文件形式保存在本地目录里，天然适合作为AI的“记忆底座”。你可以把任意一段资料喂给AI，AI基于它做摘要、翻译、问答，最终得到的产出又可以写回 Obsidian，形成闭环。

1.2 Obsidian 解决的是“信息沉淀”问题，不是“信息获取”问题

很多人理解错了AI知识库的方向，以为接入了大模型就等于知识管理。实际上，AI的能力在于“处理”，而不在于“保存”。哪怕强大的云端知识库产品，其答案质量也高度依赖上传文档的结构化程度。Obsidian 的优势恰恰在于，它提供了非常成熟的双向链接、属性、标签、模板和全文检索能力，能帮助你把零散信息整理成适合被AI消费的文档结构。

通俗一点讲：AI 是加工厂，而 Obsidian 是原料仓库。没有仓库，工厂就无米下锅；仓库太乱，工厂也生产不出好产品。很多人得到AI没用，不是模型不行，而是喂给它的资料太乱。所以 Obsidian 非但不能删，反而应该在 AI 时代重新重视起来。

1.3 本地优先、数据主权，是AI时代不可忽视的底线

现在很多AI工具都要求上传数据到云端。对于个人笔记、公司内部技术文档、客户信息，这并不总是可以接受的。Obsidian 的核心设计是“本地优先”，笔记存在你自己电脑的文件夹里，即使没有任何网络，也可以全文检索、查看、修改。这一特性让它成为AI时代少有的“数据主权”型工具。你最终把哪部分数据交给AI，完全由你决定，而不是被动交给某个平台。

2. 环境准备：安装 Obsidian 与基础配置

2.1 安装 Obsidian 与创建 Vault

Obsidian 官方支持 Windows、macOS、Linux、Android 和 iOS，并在官网提供了安装包。安装完成后，第一次打开会让你选择“Create new vault”或“Open folder as vault”。Vault 是 Obsidian 中的知识仓库概念，本质上就是一个目录。建议在本地磁盘单独建立一个主目录，例如：

D:\KnowledgeBase\MyBrain

这个目录就是你的“大脑”所在。目录内部建议再建立几个基础子目录：

MyBrain/ ├── 00-Inbox/ # 临时收集的碎片信息 ├── 01-Projects/ # 某个具体项目或任务相关笔记 ├── 02-Areas/ # 持续维护的领域知识 ├── 03-Resources/ # 读书笔记、文章摘录、技术资料 ├── 04-Archive/ # 已不再活跃但需要保留的笔记 └── Templates/ # 模板目录

这套结构参考了 PARA 方法，但不是必须照搬。Obsidian 的好处就是不限制目录结构，你完全可以根据自己习惯调整。

2.2 基础设置建议

打开“设置 → 编辑器”，几项建议开启：

• 默认编辑视图：源码模式，方便看到 Markdown 原始结构。
• 显示行号：便于定位长文档中的段落。
• 严格换行：让换行符在阅读视图中生效，生成 AI 提示词或模板时更可控。

在“设置 → 文件与链接”中，建议开启“自动更新内部链接”，这样重命名笔记时，所有指向该笔记的链接都会自动更新。这一点在知识库变大后非常重要，否则很多链接会因为重命名而失效。

Obsidian 默认支持中文界面，但插件商店中的插件的描述、说明不一定有中文，需要有一定英文阅读基础。

2.3 关于 Obsidian 下载慢的问题

如果你所在网络访问 Obsidian 官网或社区插件商店较慢，这是不少国内用户遇到过的痛点。这里给几个安全、合理的方向：

• 优先从 Obsidian 官网下载安装包，文件本身不大。
• 社区插件在线安装失败时，可以检查网络、重试，或从插件 GitHub 仓库获取安装包，手动放入 Vault 的.obsidian/plugins/目录。
• 不要在插件安装过程中强制中断，容易导致插件目录不完整。

需要说明的是：这些操作都不涉及代理或特殊网络，仅是常规的网络重试与手动安装思路。

3. Obsidian 的核心概念：链接、图谱、属性与模板

3.1 双向链接

双向链接是 Obsidian 最基础也最核心的功能。如果一篇笔记中写了[[Python]]，Obsidian 会创建一个指向“Python”这篇笔记的链接，同时“Python”笔记的“反向链接”面板中会出现来自当前笔记的引用。这给了知识库一种超越目录树关系的组织方式：同一份资料可以被不同场景引用，但文件实体只需要保存一份。

在 AI 工作流中，双向链接的意义在于：它可以为 AI 提供一个接近人类思维的“上下文关联”线索。当你让 AI 总结某篇笔记时，如果笔记内部有链接，你可以在输入提示词中带上相关链接笔记的标题与摘要，让AI获得更完整的背景信息。

3.2 图谱视图

图谱视图可以把所有笔记以及笔记之间的链接关系可视化为一张网络图。很多新人喜欢追求“满天繁星”的图谱效果，但图谱只是结果，不是目的。真正有价值的是：当一篇新笔记插入时，你能否在图谱上看到它连接到了哪些已有概念；如果没有连接，说明这条笔记是孤立的，那么后续检索和 AI 问答时，它很可能被遗漏。

3.3 属性（Properties）与 YAML Front Matter

Obsidian 现在的属性功能基于 Markdown 文件头部的一段 YAML 数据。每篇笔记可以定义以下字段：

--- title: 如何用 Obsidian 搭建知识库 tags: [obsidian, 知识管理, AI] created: 2025-01-15 status: 已完成 author: 你的名字 source: https://example.com ---

这些字段在渲染时不会直接展示，但可以被插件、Dataview、Python 脚本读取。属性是让 AI 理解笔记“身份”的关键一环。例如，当你写一个自动化脚本，把笔记批量交给大模型做摘要时，脚本可以通过tags字段判断笔记属于哪个领域，进而调用不同的提示词策略。

3.4 模板系统

Obsidian 原生支持核心插件“模板”，也可以使用功能更强大的 Templater 模板插件。模板可以理解为“笔记的出生设置”：当你需要新建一篇读书笔记时，可以先写好模板，包括书名、作者、阅读状态、核心观点、AI 总结等字段，新建笔记时直接填充。

模板对于 AI 工作流的价值是保证一致性。批量喂给 AI 的笔记结构越统一，AI 提取信息的成功率越高。反之，如果每篇笔记字段完全随意，AI 在处理时就会频繁“猜测”，输出结果的质量很难保证。

4. 让 Obsidian 接入 AI 的几种路径

4.1 直接用 AI 插件（最轻量）

Obsidian 社区目前有一些很受欢迎的 AI 插件，例如：

• Copilot for Obsidian：在 Obsidian 内提供一个类似 ChatGPT 的对话窗口，可以基于当前笔记、指定文件夹或整个 Vault 做问答。
• Text Generator：用模板调用大模型完成摘要、重写、翻译等任务，适合批量化操作。
• Smart Connections：为笔记生成向量索引，然后根据语义相似度自动推荐相关笔记，并支持基于知识库的问答。

这些插件大多需要配置大模型 API Key，或者支持接入本地模型（如 Ollama）。不同类型插件的配置方式差异较大，建议以插件官方文档为准，重点在于理解思路：插件把内容和 Prompt 组合起来，调用模型 API 返回结果，再写回笔记。

4.2 本地模型路径（数据不出本地）

如果你对数据隐私要求较高，可以选择在本地运行大模型，然后通过 Ollama 等工具暴露本地 API，让 Obsidian 插件或自研脚本调用。这种方式的优点是数据完全不出内网或本机，缺点是本地模型对硬件有要求，生成速度和质量往往不如云端 API。

Ollama 的安装和启动相对简单。安装完成后，在命令行执行：

ollama run qwen2.5:7b

即可启动一个本地模型服务。之后你可以在 Python 中通过 HTTP 请求访问它。

4.3 外部工作流路径（n8n / Dify / Coze）

除了在 Obsidian 内部使用插件，还可以把 Obsidian 接入到更完整的自动化工作流平台，比如 n8n、Dify、Coze 等。思路通常是：某个触发器（例如定时任务、新文件生成、Webhook 调用）触发工作流，从 Obsidian Vault 读取文件，调用大模型处理，再把结果写入 Obsidian 或推送到其他系统。

这种路径适合团队或较复杂的业务场景，本文第5章会用一个 Python 脚本作为轻量替代方案，避免过多依赖外部平台配置。

5. 实战：搭建一条“采集 → 整理 → 沉淀 → 输出”的 AI 工作流

5.1 信息采集：在 Obsidian 中收集原始素材

信息采集的第一步是把碎片内容收进 Vault 的00-Inbox目录。日常来源包括网页文章、微信文章、PDF 笔记、随手想法。Obsidian 自带的 Web Clipper（浏览器扩展）可以一键截取网页正文并保存为 Markdown 笔记，你也可以通过移动端快捷指令或第三方剪藏工具来实现。

这里关键的不是工具，而是“先收进 Inbox，不立即分类”的习惯。很多人在采集阶段就担心笔记放错文件夹，结果大量内容没有保存。更好的策略是：先把一切丢进00-Inbox，后续统一通过模板和 AI 做整理。

5.2 用 Text Generator 自动生成摘要与标签

当 Inbox 积累了一批笔记后，可以做一个批处理：让 AI 为每篇笔记生成摘要、提取关键词、补充标签。Text Generator 插件支持自定义 Prompt，你可以在插件设置里新建一个 Prompt 模板，例如：

你是一个技术知识库管理员。请阅读下面的笔记内容，完成三项任务： 1. 用 3 句话概括全文核心观点。 2. 抽取 5~8 个关键词。 3. 生成 3~6 个 YAML tags。 请严格使用以下格式输出： 摘要： 关键词： tags:

然后选中某篇笔记，运行该 Prompt，插件会把模型返回的结果插入到笔记指定位置。你只需要人工确认一遍即可，避免AI产生事实性偏差。

5.3 用 Smart Connections 建立语义关联

Smart Connections 插件会自动为笔记创建向量索引，然后在你的笔记列表里，根据当前笔记的语义内容，推荐与之最相关的其他笔记。它的价值在于帮助你发现“自己没有意识到的关联”。

举个实际例子：如果你有一条笔记记录了“怎么用 Python 读取 PDF”，而另一条笔记记录了“某次项目里客户抱怨 PDF 导出乱码”，按关键词检索很难想到它们之间有关系，但语义向量可以让这两篇笔记产生关联。这样你在回顾时会更容易从项目经验迁移到新的技术方案中。

5.4 用 Copilot 进行问答检索

当知识库整理得差不多时，就可以使用 Copilot 类插件进行基于知识库的问答。你可以指定一个文件夹作为范围，例如“请基于03-Resources/AI/文件夹下的笔记，回答：适合本地部署的中文大模型有哪些？” 插件会先检索相关笔记，再连同上下文一起发送给模型。

注意，问答效果依赖两件事：一是你的笔记本身信息是否全面、准确；二是你是否给定了足够的范围，让插件可以缩小检索面。

5.5 用模板生成周报 / 文章草稿

最后一步是输出。很多人在知识管理上“只进不出”，导致笔记越积越多，但实际价值没有转化。养成“每周从笔记中提炼一次产出”的习惯，非常有用。

你可以写一个模板，固定结构为：本周新增了几个项目、每篇文章的核心结论、遇到的问题与解决方案。然后让 AI 基于01-Projects和00-Inbox的笔记内容生成初稿，再在这个基础上修改。这比从空白页开始写周报高效很多。

6. 进阶：用 Python 把 Obsidian 变成 AI Agent 的“记忆库”

6.1 为什么需要用代码来做

插件方案适合 Obsidian 重度用户，但如果是做团队级工具或自动化流程，则需要更灵活的方式。通过 Python 脚本读取 Vault 中的 Markdown 文件，调用大模型接口，最后把结果写回文件，可以让你完全自定义流程，不依赖某个插件是否更新、是否兼容。

6.2 实现一个简单的本地知识库问答脚本

假设你已经有一个 Vault，目录中的笔记都是 Markdown 文件。下面这个 Python 示例展示了一个基础流程：读取最新笔记、生成摘要、保存到笔记头部或单独文件。

# -*- coding: utf-8 -*- """ 示例：读取 Obsidian Vault 中的最新一篇 Markdown 笔记， 调用大模型接口生成摘要，并追加到笔记中。 使用前需要安装 requests 库： pip install requests """ import os import glob import datetime import requests # 配置区 VAULT_PATH = r"D:\KnowledgeBase\MyBrain" INBOX_DIR = os.path.join(VAULT_PATH, "00-Inbox") API_URL = "https://api.example.com/v1/chat/completions" # 替换成你的模型 API 地址 API_KEY = "your-api-key-here" MODEL_NAME = "qwen-plus" # 按实际使用的模型调整 def get_latest_markdown_file(directory: str) -> str: """获取目录中创建时间最新的 Markdown 文件""" files = glob.glob(os.path.join(directory, "*.md")) if not files: raise FileNotFoundError("目录中没有 Markdown 文件") latest = max(files, key=os.path.getmtime) return latest def read_markdown_content(file_path: str) -> str: """读取 Markdown 文件内容""" with open(file_path, "r", encoding="utf-8") as f: return f.read() def generate_summary(content: str) -> str: """调用大模型 API 生成摘要""" prompt = f"请用三句话总结以下笔记内容：\n\n{content[:3000]}" headers = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"} payload = { "model": MODEL_NAME, "messages": [{"role": "user", "content": prompt}], "temperature": 0.3, } resp = requests.post(API_URL, json=payload, headers=headers, timeout=60) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"].strip() def append_summary_to_file(file_path: str, summary: str): """将摘要追加到 Markdown 文件末尾，并写入日期""" with open(file_path, "a", encoding="utf-8") as f: f.write(f"\n\n---\n### AI 摘要\n\n{summary}\n\n> 生成时间：{datetime.datetime.now().isoformat()}\n") if __name__ == "__main__": target = get_latest_markdown_file(INBOX_DIR) print(f"处理文件：{target}") content = read_markdown_content(target) summary = generate_summary(content) append_summary_to_file(target, summary) print(f"摘要已写入：{target}")

这个脚本本身很简单，但它体现了三个关键思想：

1. 目录约定：不同目录放不同阶段的笔记，脚本可以只扫某个目录，避免处理范围过大。
2. API 请求方式统一：无论使用哪个模型供应商，只要兼容 OpenAI 风格接口，代码可以平滑切换。
3. 人工确认高于自动覆盖：脚本只追加不删除，最终内容是否采纳，由人决定。

6.3 向量化检索：为更复杂的 RAG 应用打基础

如果你希望 AI 能基于整个 Vault 内容回答问题时，需要为笔记建立向量索引，再使用向量检索召回相关片段。常见的做法是：

• 将每篇 Markdown 按标题或段落切块。
• 调用 Embedding 模型为每个文本块生成向量。
• 把向量和源文件路径存入本地向量数据库（如 Chroma、FAISS、LanceDB）。
• 用户提问时，先把问题转成向量，再检索 top-k 块，拼进 Prompt 发给大模型回答。

这种 RAG（检索增强生成）架构，在工程上比把全部笔记塞进 Prompt 更可行。Obsidian 笔记本身文本干净、结构清晰、原子化程度高，非常适合直接作为 RAG 的数据源。这也是 Obsidian 在 AI 时代最有工程价值的地方：你积累的知识可以低成本地转化为大模型可用的知识资产。

7. 常见问题与排查

排查时，建议遵循“从简到繁”的顺序：先用少数几篇笔记测试，确认插件或脚本基本可用后，再逐步放开范围。很多人一上来就让 AI 处理几千篇笔记，出了问题很难定位到底哪一步出错了。

8. 最佳实践：AI 时代的 Obsidian 笔记管理原则

可能你会觉得，AI 都已经能自动写摘要了，那是不是不用认真记笔记了？我觉得恰恰相反。AI 可以帮你整理、概括、翻译，但没有能力代替你判断什么值得记。下面这些原则，是我实践后认为最有效的几条。

第一，笔记尽量原子化。一篇笔记只讲一个核心主题，避免“大杂烩”。原子化的笔记便于链接、便于检索、也便于向量切块。如果一个文档超过几千字，AI 在处理时也会因为上下文被截断而丢失关键信息，需要人为切分成多篇并用链接关联。

第二，善用属性字段，但不要过度设计。每次新建笔记时，至少保有title、created、tags、source四个字段。这能让你的数据在交给 AI 时有一个相对标准的轮廓。属性字段越多，维护成本越高，建议从少到多逐步增加，不要一开始就设计一个庞大的元数据体系。

第三，把 Prompt 当作一等公民。在 Obsidian 里建立一个Templates/Prompts/目录，把常用的 AI 提示词保存为 Markdown 文件。这样你在使用 Text Generator 或外部脚本时，可以方便地复制和修改。只要积累 20 个高质量 Prompt，你的工作效率就会有明显提升。

第四，不要盲目追求插件数量。Obsidian 插件生态非常丰富，但每装一个插件都可能带来性能开销和版本兼容问题。建议只保留几个核心插件，然后用 Python 或外部工具处理复杂逻辑。保持 Vault 本身轻量，长期来看更稳健。

第五，注意备份与同步。Obsidian 是本地文件，这意味着你对自己的数据负有直接责任。建议至少每周做一次全量备份到外部设备或私有云，也可以配合 Git 做版本管理。不要把 Obsidian 的数据同步交给一个完全封闭的第三方平台，否则就失去了本地优先的意义。

第六，安全边界要清晰。在把笔记发送给 AI 服务之前，自己先做一次“保密性巡检”。包含密钥、密码、身份证号、客户隐私等信息，应当从笔记中剥离出来。可以设置一个专用目录用于存放敏感资料，并确保该目录永远不会被同步组件或 AI 插件扫描到。

9. 总结与下一步

Obsidian 在 AI 时代的定位，不是被替代的旧工具，而是一个值得长期经营的知识基建。它承接了采集、整理、关联、检索、输出的完整闭环，而 AI 则负责摘要、补全、翻译、问答这些高耗能的文本处理任务。两者相互配合，比单纯依赖某个“AI 笔记应用”更可靠，也更可控。

下一步的学习路线，建议这样走：先熟练使用 Obsidian 的链接、属性、模板三个核心功能；然后挑一款 AI 插件（比如 Text Generator 或 Copilot）跑通“摘要—问答”流程；再尝试用 Python 脚本读取笔记、调用模型 API、保存结果；最后可以根据业务需求接入外部工作流平台，做定时任务或团队级应用。

如果在动手过程中遇到问题，不妨先回到最基础的目录结构和 Markdown 语法上检查。知识库质量是 AI 应用效果的上限，这个看似老旧的原则，在 AI 时代反而变得更加明显。我的建议是：别急着删 Obsidian，先用它把知识沉淀下来。未来无论大模型换成什么版本，这个本地知识库始终是你可以信任的起点。