企业官网建设流程全解析

聊一个很普遍的现象：你收藏了几百篇“先码后看”的文章，下载了不止一个笔记软件，但真到写总结、做汇报、复现某个技术方案时，还是什么都找不到。这不是你不够自律，也不是笔记软件不够好用，而是大多数人的知识管理流程卡在“存放”这一步，没有进入“加工”这一步。

Obsidian 和 Codex 的组合，解决的正是这个问题。Obsidian 负责本地化、结构化地存放你的笔记，让知识之间有连接；Codex 则是一个能直接读文件、写文件、跑命令的 AI 编程助手，可以把零散资料加工成真正能复用的内容。换句话说，Obsidian 是仓库，Codex 是生产线。两者放在一起，你就有了一个“对外收集、内部加工、随时检索”的个人 AI 知识库雏形。

这篇文章不会讲太多云里雾里的架构概念，而是从新手视角完整拆解：为什么需要这两款工具、各自解决什么问题、如何安装配置、如何把第一批资料整理成结构化笔记，以及最常见的报错怎么排查。读完你可以直接上手，把 Obsidian + Codex 组合跑起来。

1. 这篇文章真正要解决的问题

先别急着下载软件，想清楚一个问题：你做知识库，到底卡在哪一步？

从大量反馈看，新手最常见的三个阶段是：

第一，采集阶段。看到好文章先收藏，网页存了一堆书签，微信里转发了无数条“以后用得上”。问题是“以后”永远不会来，收藏夹越来越乱。

第二，整理阶段。终于抽时间打开笔记软件，想把资料整理成文，却不知道从哪开始：是复制原文，还是写摘要？要不要分类？分类分几层？结果整理了 20 分钟，只整理出一篇格式漂亮的“搬运文”。

第三，检索阶段。等真的要写技术方案了，在笔记里搜索关键词，发现要么搜出来的内容太多，要么根本搜不到。因为当初整理的时候，你根本没给它打标签、做摘要、建立引用关系。

Obsidian + Codex 这套组合，刚好对应这三个阶段分别给出方案：

• Obsidian 用本地 Markdown 文件保存所有笔记，双链机制可以让笔记之间自然关联，图谱功能让你看到知识之间的关系。
• Codex 可以在命令行里读你指定的 Markdown 文件，按你的要求生成摘要、提炼要点、批量改写，把“收藏的资料”变成“可复用的笔记”。

所以核心判断是：不要只把 Obsidian 当成“又一个记笔记的软件”，也不要只把 Codex 当成“能聊天的命令行版本 ChatGPT”。它们组合起来，改变的其实是你的知识处理流程——从“人肉整理”变成“人做决策，AI 做初稿”。

这篇文章适合这几类读者：正在尝试搭建个人知识库，但被各种双链、标签、插件劝退的新手；需要处理大量技术资料，经常整理笔记但效率不高的人；以及想了解 AI Agent 类工具怎么落地到日常文档工作流的开发者。

2. Obsidian 与 Codex 核心概念与适用场景

在开始安装之前，先把这两个工具的本质讲清楚。理解不了本质，配置完也只是多两个软件图标。

2.1 Obsidian：本地优先的 Markdown 知识库

Obsidian 本质上不是一个数据库，不是一个云笔记应用，而是一个“以本地 Markdown 文件为存储单元”的笔记前端。你创建的每一篇笔记，都是一个 .md 文件，存放在你自己指定的文件夹里。

它有几个关键设计，决定了它适合做知识库底座：

第一，本地存储。笔记文件完全在你自己的电脑上，不依赖云端。不会出现平台倒闭、内容被删、数据被强制格式化的风险。对写技术博客、存代码笔记、整理研究资料的人来说，这是最底层的安全感。

第二，Markdown 格式。所有内容都是纯文本，任何编辑器都能打开。以后你不想用 Obsidian 了，文件还在，迁移成本几乎为零。这一点很多云笔记做不到。

第三，双向链接。你用[[笔记名]]这种语法，就能把两篇笔记关联起来。Obsidian 会生成关系图谱，你能直观看到哪些主题互相引用。这个机制会逼着你建立知识连接，而不是把笔记写成一个个信息孤岛。

第四，插件生态。Obsidian 有 Dataview、Templater、Excalidraw 等插件，能把纯手写笔记变成半自动化的知识管理系统。后面我会用 Dataview 举个例子。

它适用什么场景？个人知识库、技术文档库、学习笔记、写作素材库、项目记录。不适合做什么？不适合多人实时协作的团队知识库，不适合需要精细权限管理的企业文档系统。Obsidian 个人使用免费，商业环境中按官方要求需要购买许可证，这一点要留意。

2.2 Codex：命令行里的 AI 编程助手

Codex 是 OpenAI 推出的 CLI 工具。简单说，它是一个跑在终端里的 AI Agent：你给它一个任务描述，它能读取你指定的文件、搜索代码、执行命令，然后产出结果。

很多新手会把 Codex 和 ChatGPT 网页版搞混。区别在于：网页版是你问它答，它看不到你电脑上的文件；而 Codex 在命令行里运行，可以访问当前目录下的文件，可以调用 Shell 命令，可以在项目里生成代码或修改文件。用知识库的场景来说，它不只是“帮你写一段文字”，而是“帮你直接处理本地笔记文件”。

需要注意，Codex 有几种形态。一个是通过 npm 安装的独立 CLI 工具，另一个是 ChatGPT 桌面应用里集成的 Codex 功能。正常情况下两者共用同一套认证机制，但桌面版在启动时可能会去找 CLI 对应的二进制路径，这也是后面高频报错“unable to locate the codex cli binary”的来源。

2.3 什么是 AI 知识库

“AI 知识库”这个词这两年出现频率很高，但它不是只有一个定义。最轻量级的 AI 知识库，就是把笔记放在 Obsidian 里，然后让 AI 工具能读取这些笔记，基于笔记内容做问答、做总结、做进一步加工。更重一点的方案是 RAG（检索增强生成）：把文档切片、向量化，存到向量数据库，用户提问时先检索相关内容，再把检索结果交给大模型生成答案。

这篇文章做的是轻量级方案：不引入向量数据库，直接用 Codex 读文件、写文件，完成个人知识库的整理与沉淀。好处是门槛低、速度快、成本可控；局限是当笔记量非常大、需要语义检索时，还是得引入 RAG 工具链。

3. Obsidian 与 Codex 环境准备与安装配置

下面进入实操。先说清楚环境要求，再一步步安装。

3.1 安装 Obsidian 并创建知识库

Obsidian 支持 Windows、macOS、Linux，官方提供安装包。有用户反馈从官网下载速度不稳定，这里建议：优先访问 Obsidian 官网下载对应系统安装包；下载较慢时，也可以选择可信的国内软件源，但注意核对软件校验信息，避免来源不明的安装包。

安装完成后，创建一个 Vault，也就是你的知识库文件夹。这里建议不要一个 Vault 装所有内容，而是按用途拆分：个人学习一个 Vault，工作项目一个 Vault，写作素材一个 Vault，互不干扰。

创建后，Obsidian 会自动生成一个.obsidian文件夹，用来存插件和设置。这个文件夹是隐藏的，不用手动修改，但你要知道它的存在。

3.2 安装 Codex CLI

Codex CLI 通过 npm 分发，需要先安装 Node.js 环境。版本要求以官方 README 为准，一般建议 Node.js 18 及以上，部分较新版本可能要求 20 以上。如果你还没安装 Node.js，可以去官方 LTS 版本页面下载。

确认 Node.js 和 npm 就绪后，在终端执行：

node -v npm -v

然后全局安装 Codex：

npm install -g @openai/codex

安装完成后，验证版本：

codex --version

如果出现codex: command not found，说明 npm 的全局 bin 目录没有加入系统的 PATH 环境变量，在排查章节会专门说明。

3.3 配置 Codex 认证与模型供应商

Codex 使用 OpenAI 账号体系做认证。两种方式选一种即可：

方式一，使用官方登录流程：

codex login

执行后终端会输出一个链接，让你在浏览器完成授权。

方式二，直接配置 API Key。在终端里设置环境变量：

export OPENAI_API_KEY="你的API Key"

如果你用的是第三方兼容 OpenAI 接口的服务，比如 DeepSeek，可以修改 Codex 的配置文件。Codex 的配置文件路径默认为~/.codex/config.toml，Windows 下为%USERPROFILE%\.codex\config.toml。

下面是一个以 DeepSeek 为例的配置片段。实际配置时，模型名称、接口地址、环境变量名以对应服务商文档为准：

# 文件路径：~/.codex/config.toml model = "deepseek-chat" model_provider = "deepseek" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY" wire_api = "chat"

这里base_url是服务商的 API 地址，env_key表示 Codex 会从这里读取服务商对应的环境变量。修改后，在终端设置DEEPSEEK_API_KEY，再运行codex exec "测试一下"，确认链路通不通。

需要提醒一点：使用第三方模型时，Codex 有些功能可能不完全兼容。报错信息里如果出现endpoint /responses之类的字样，说明当前 provider 默认走的是 Responses API，而第三方服务可能只兼容 Chat Completions。此时在 provider 配置中加一行wire_api = "chat"，通常能解决问题。

3.4 验证环境

运行一条最简单的命令，确认能正常工作：

codex exec "用一句话说明 Obsidian 是什么"

正常时，命令会调用模型并输出一句话。如果这里就失败了，先不要继续往后做，先解决环境问题，否则后面的流程都得返工。

4. 核心流程拆解：从收集资料到 AI 整理笔记

环境就绪后，我们要把整个知识处理流程跑通。流程可以用四步概括：建立结构、收集素材、AI 加工、人工校验。

4.1 第一步：建立 Vault 目录结构

很多新手一上来就建几十个分类文件夹，结果笔记没写几篇，目录已经乱得没法看。更推荐的做法是“宽进严出”：

00-Inbox/ # 收集箱，所有新资料先扔这里 10-Projects/ # 项目笔记 20-Areas/ # 长期关注领域 30-Resources/ # 主题资源库 90-Attachments/ # 图片、附件、导入的 PDF

这个结构参考了常见的“信息收集箱”思路，但做了简化。原则只有一个：任何新资料先进00-Inbox，不急着分类。分类是整理阶段做的事，不是收集阶段做的事。这能最大程度降低写笔记的心理门槛。

4.2 第二步：用双链制造知识连接

在 Obsidian 里写笔记时，一定要用双链。比如你写了一篇关于 RAG 的笔记，里面提到向量数据库，就写成[[向量数据库]]。Obsidian 会在右侧图谱中生成一条线，把两篇笔记连起来。

双链的价值不是好看，而是让 AI 加工时能顺着链接找到相关内容。Codex 读取一篇笔记时，如果它发现笔记里有[[其他笔记]]，你可以要求它同时读取链接指向的笔记，整理出来的内容就更有上下文，而不是只看孤立的一篇。

4.3 第三步：把 AI 生成的内容放进草稿区

这一步最容易被新手误解：以为 AI 写出来的东西可以直接进正式知识库。更好的做法是，AI 生成的内容先存到草稿区，由你判断后再归入正式目录。

这样做的原因是：大模型生成的内容可能有事实偏差，也可能不符合你的表达习惯。知识库是给你未来自己看的，准确性和可读性都重要。让 AI 负责“从无到有”，你负责“从有到对”。

在实践中，可以让 Codex 把整理结果输出到一个指定目录：

10-Projects/drafts/ # AI 生成的草稿 10-Projects/ # 人工确认后的正式笔记

4.4 第四步：固定你的 AI 指令模板

Codex 不认人心，只认指令。想要稳定的输出质量，就要写成固定的指令模板。你可以把项目规则写进.codex/AGENTS.md文件，让 Codex 在项目目录里运行时自动读取。

比如这个项目规则文件：

# 文件路径：你的Vault根目录/.codex/AGENTS.md ## 项目目标 这是一个 Obsidian 知识库。Codex 的职责是辅助整理笔记，不要主动删除既有内容。 ## 笔记整理要求 1. 读取 00-Inbox 下的 Markdown 文件。 2. 生成结构化笔记，包含：摘要、关键要点、待办事项。 3. 输出到 10-Projects/drafts/ 目录，文件名加上“整理-”前缀。 4. 不要修改原始文件。 5. 保留笔记中的原始链接 `[[...]]` 格式。

这样你后续运行 Codex 时，它会自动带上这些约束，输出格式更稳定。

5. 完整示例与代码实现

下面给出一套可以直接复制使用的最小可运行示例。

5.1 示例 1：单篇资料整理

假设你在00-Inbox里存了一篇技术资料rag-notes.md，内容很散，你希望 Codex 整理成结构化笔记。

codex exec "请读取 00-Inbox/rag-notes.md，整理成一篇结构化笔记，包含摘要、核心概念、优缺点、应用场景四个小节。输出到 10-Projects/drafts/整理-rag-notes.md，不要修改原文件。"

运行逻辑：Codex 读取指定文件 → 按照 prompt 中的要求生成内容 → 写入目标路径。这里建议加上“不要修改原文件”，避免 AI 把原始资料改得面目全非。

5.2 示例 2：批量整理收集箱

Inbox 里可能躺着几十篇资料，一篇篇跑太慢。可以用一个简单的 shell 脚本批量处理：

#!/usr/bin/env bash # 文件路径：scripts/batch-organize.sh INBOX_DIR="00-Inbox" OUT_DIR="10-Projects/drafts" mkdir -p "$OUT_DIR" for file in "$INBOX_DIR"/*.md; do # 如果目录为空，跳过 [ -e "$file" ] || continue filename=$(basename "$file" .md) echo "正在整理: $filename" codex exec --full-auto \ "请读取 $file，整理成结构化笔记，包括摘要、关键要点、待办事项。输出为 $OUT_DIR/整理-$filename.md，不要修改原文件。" done

这里用到了--full-auto参数，表示执行过程中不需要人工确认。批量执行前，建议先用一条命令做一次测试，确认输出内容符合预期，再跑整个循环。

5.3 示例 3：用 Templater 建立笔记模板

Obsidian 的 Templater 插件可以让你新建笔记时自动带入固定模板。先安装插件，然后在插件设置里配置模板目录，再新建一个模板文件：

--- title: "{{title}}" date: "{{date}}" tags: [] source: "" status: draft --- # {{title}} ## 摘要 ## 关键要点 ## 待办事项 ## 参考资料

这样你每次新建笔记，都自动生成统一结构的文档，后续 Codex 整理时也有规律可循。

5.4 示例 4：用 Dataview 做知识库视图

Dataview 插件可以按条件筛选笔记，展示成表格、列表或卡片。安装 Dataview 后，在任意一篇笔记里写：

TABLE file.name AS 笔记, dateformat(file.mtime, "yyyy-MM-dd") AS 修改时间 FROM "10-Projects" WHERE contains(tags, "AI知识库") SORT file.mtime DESC

运行后，Obsidian 会把10-Projects目录下所有带AI知识库标签的笔记列成表格，按修改时间排序。这样你的知识库就有了一个动态视图，不用手动维护索引。

5.5 代码文件结构说明

完整的最小结构如下：

你的Vault/ ├── .codex/ │ └── AGENTS.md ├── 00-Inbox/ │ └── rag-notes.md ├── 10-Projects/ │ └── drafts/ ├── 90-Attachments/ ├── scripts/ │ └── batch-organize.sh └── 模板/ └── 默认笔记模板.md

把规则、脚本、模板放在对应目录下，Claude 就能很快理解你的项目结构。

6. 运行结果与效果验证

跑完上述流程后，怎么判断是否成功？不要只看“命令没有报错”就算完。

6.1 检查生成文件

先看10-Projects/drafts/下是否生成了新的 Markdown 文件。打开文件检查三个点：

• 结构是否符合要求：有没有摘要、关键要点、待办事项或者其他指定小节。
• 内容是否准确：对比原始资料，看看 AI 是否漏掉关键信息，或者擅自添加了原文不存在的结论。
• 格式是否规范：代码块、列表、链接是否完好，尤其是[[双链]]是否被 AI 误删或改写。

6.2 在 Obsidian 中验证检索效果

打开 Obsidian，进入10-Projects/drafts/，确认文件能正常显示。然后在 Obsidian 全局搜索框里输入某个关键词，看能否搜到 AI 整理后的内容。

如果安装了 Dataview，再检查一下查询是否能正常渲染。常见的失败是标签不匹配，比如查询条件写的是AI知识库，但笔记里的标签是AI知识库/AI，需要统一。

6.3 验证流程是否可重复

真正的知识库流程应该能重复跑。你可以再往00-Inbox里放一篇新资料，重新运行批量整理脚本，确认第二批文件也能正确生成。如果第二次结果明显变差，优先检查是不是触发了模型上下文限制，或者提示词里给的信息不够明确。

7. 常见问题与排查思路

新手上路，下面这些报错和现象大概率会遇到。整理成表格，方便对照排查。

需要强调一点：任何批量操作首次执行前，都建议先手动备份 Vault 目录。尤其涉及修改、覆盖文件时，先用一张小的资料集做测试，确认无异常后再跑全量。

8. 最佳实践与工程建议

到这里，工具链已经能跑通了。但如果只是“能跑通”还不够，下面这几条建议能让你避免后续返工。

8.1 让 AI 负责初稿，你负责终稿

知识库是长期资产，里面的内容会被未来的你反复引用。AI 生成的初稿可以快，但人工校验这一步不能省。特别涉及技术结论、版本号、代码片段时，一定以实际验证结果为准。

8.2 用 Git 做笔记版本管理

Obsidian 的 Vault 本质是文件夹，天然适合放进 Git 仓库。建议在 Vault 根目录初始化 Git，每完成一批整理就提交一次。好处有两个：发生误删或批量生成内容污染仓库时，可以方便回滚；同一知识库在不同电脑之间同步时，Git 是稳定可靠的方式。

git init git add . git commit -m "初始化知识库"

8.3 不要把密钥写进笔记

API Key、登录凭证这类敏感信息绝不能出现在 Vault 里，也不要让 Codex 读取包含密钥的文件。前面说过用环境变量方式配置密钥，这样既安全，又不会污染知识库内容。如果笔记里已经不小心存了敏感信息，尽快删除并修改对应密钥。

8.4 明确安全边界

知识库很可能包含个人隐私、公司内部资料或未公开的研究内容。把这类资料交给第三方 AI 服务前，要确认服务商的数据处理条款，评估风险。企业项目建议优先走私有化部署或已审批的合规模型服务，而不是直接把全部笔记交给外部 API。这个原则比任何工具技巧都重要。

8.5 目录结构保持简洁，不要过度设计

知识库目录本质上用得顺手比“分类科学”重要。如果一个星期内你用不到某个分类，就不要提前建好。等笔记量增长到当前结构无法容纳时，再调整目录也不迟。Obsidian 的移动文件成本很低，因为笔记之间的链接不会因为文件位置变化而失效。

8.6 给 AI 设置项目规则

再次强调.codex/AGENTS.md的价值。这个文件相当于项目的“说明书”，让 Codex 每次运行都知道知识库的约定。团队协作时，这份文件也能让其他人快速理解知识库的整理规范。

8.7 控制调用成本

批量整理几百篇笔记会产生大量模型调用。建议先统计 Inbox 里的笔记总量和平均长度，估算大概的 token 消耗，再决定一次跑多少。不要为了省事一次性把所有资料丢给模型处理，分批处理并设置 sleep 间隔，也能降低超时和限流的概率。

9. 总结与后续学习方向

这篇文章从“知识管理卡在整理环节”这个痛点出发，把 Obsidian 和 Codex 组合成一条可落地的知识处理流水线：Obsidian 负责本地存储和双链连接，Codex 负责读取文件、生成初稿、批量整理，人工负责最终判断。整套流程不需要引入向量数据库，不需要写复杂后端代码，一个本地目录加一个命令行工具就能起步。

你接下来可以沿着两个方向继续深入。第一个方向是继续优化现有流程：调整.codex/AGENTS.md里的整理规则，让它更贴合你的笔记习惯；给笔记补充更细致的标签；用 Dataview 做出更丰富的动态视图。第二个方向是探索更重的 RAG 方案：当笔记量大到几百上千篇，全文搜索和人工整理已经跟不上时，可以了解 Dify、RAGFlow 这类开源知识库工具，把文档切片、向量化、检索增强生成引入进来，做一个更完整的 AI 知识库系统。

最后留一句提醒：工具只是起点，真正让知识库产生价值的，是你持续往里写、持续让 AI 帮你归纳、持续回头检索的过程。现在就可以装好 Obsidian，装好 Codex，往 Inbox 里丢三篇你一直想整理的资料，跑一遍上面第 5 节的命令。跑通之后，你的个人 AI 知识库就算真正开始了。