---
url: https://www.myls.top/posts/2026-03-28-obsidian-codex-vitepress-esa-blog.md
description: 一套更适合 AI 时代开发者的博客写作与发布方案：Obsidian 写作、Codex 辅助、VitePress 构建、ESA 部署。
---

# 我为什么放弃 NotionNext，转向 Obsidian + Codex + VitePress + ESA

过去一段时间，我一直在用 NotionNext 写博客。
它并不是不能用，但越往后用，越能感觉到一个问题：

**它更像"内容同步方案"，而不是"源码优先的博客方案"。**

尤其是现在已经进入 AI 编码时代，像 Codex 这样的工具真正发挥价值的前提，不是内容放在哪里都行，而是：

* 内容最好是纯文本
* 结构最好稳定
* AI 能直接批量改
* 发布链路尽量短
* 工程化能力要足够强

从这个角度看，NotionNext 并不算最合适的选择。
所以我最后把博客方案切换成了：

> **Obsidian 写作 + Codex 辅助 + VitePress 构建 + 阿里云 ESA 部署**

这套组合用下来，最大的感受就是：**AI 终于能真正参与博客生产，而不是只能帮我写一段文案。**

***

## 为什么我觉得 NotionNext 不够顺手

NotionNext 的优点很明显：

* 上手快
* Notion 写作体验还不错
* 对非技术用户友好
* 主题和现成方案很多

但它的问题也很明显。

### 1. 内容不是"真正的源码资产"

虽然最终博客会生成静态页面，但平时写作的内容核心还是在 Notion 里。
这意味着：

* 内容结构依赖 Notion block
* 迁移成本不算低
* AI 很难精确修改
* 批量处理文章不方便

对于普通写作者，这可能不是大问题。
但对于开发者来说，这会越来越别扭。

因为开发者真正想要的是：

> **文章就是 Markdown 文件，文件就是资产，Git 就是版本历史。**

***

### 2. AI 不适合改 block 型内容

现在很多人都在说 AI 写作很强，但这句话有个前提：

> **AI 最擅长处理的是"结构清晰、纯文本、规则明确"的内容。**

Markdown 就非常符合这个特点。

Notion 的 block 结构更适合"编辑器体验"，但不适合 AI 精细化地做这些事：

* 批量补 frontmatter
* 统一 tags
* 统一标题层级
* 修复图片路径
* 自动生成归档页
* 自动生成 RSS
* 自动做 SEO 优化

这些操作一旦换成 Markdown 文件，Codex 的发挥空间会大很多。

***

### 3. 发布链路长，调试不够直接

NotionNext 的工作流通常会变成这样：

```text
Notion
→ API 拉取内容
→ 转换
→ 构建
→ 发布
```

这个链路不是不能接受，但一旦哪一步有问题，排查起来就不够"源码直觉"。

而我更喜欢的是：

```text
Markdown
→ Git
→ 构建
→ 发布
```

简单、明确、可控。

***

## 我最后选择的博客方案

最后我定下来的方案是：

```text
Obsidian（写作）
+ Codex（生成、优化、批量处理）
+ VitePress（站点构建）
+ TailwindCSS（界面样式）
+ 阿里云 ESA（部署）
```

这套方案不是为了"追新"，而是因为它刚好解决了我最在意的几个问题：

* 写作要舒服
* AI 要能参与
* 页面要能改
* 部署要简单
* 后期要能持续扩展

***

## 为什么是 Obsidian，而不是继续用 Notion

我现在更愿意把 Obsidian 理解成：

> **本地 Markdown 写作 IDE**

它最适合的地方，不是"知识管理有多强"，而是它天然兼容 Git 和文本工作流。

### 对我来说，Obsidian 有几个好处

#### 1. 写的就是 Markdown 源文件

这一点特别重要。

文章不是"同步出来的结果"，而是从一开始就是博客源码的一部分。

#### 2. 本地写作速度快

没有网络依赖，没有 block 层层嵌套，也没有复杂的内容同步。

#### 3. 和 AI 配合更自然

我可以直接让 Codex：

* 帮我扩写大纲
* 帮我补 frontmatter
* 帮我统一格式
* 批量扫描 `docs/posts/*.md`
* 自动生成标签页、分类页、RSS

这一套放在 Notion 里会非常拧巴，放在 Obsidian + Markdown 里就非常顺。

***

## 为什么是 VitePress，而不是其他博客框架

我不是没看过别的方案，比如 Astro、Rspress、Docusaurus。
但最后还是选了 VitePress，原因很简单：

> **它是我现阶段最稳、最轻、最适合 AI 改造的方案。**

### VitePress 最适合我的几个点

#### 1. Markdown 驱动，非常适合博客

文章天然就是 Markdown，不需要额外心智负担。

#### 2. 上手快

你不需要一上来就进入完整前端框架开发状态。
配置和目录结构都比较轻。

#### 3. 支持 Vue 组件嵌入 Markdown

这点很关键。
它意味着首页、文章列表、标签页这些地方，我可以：

* 继续写 Markdown
* 但在需要的时候插入 Vue 组件

这让博客不会"死板"，又不至于太重。

#### 4. AI 很容易理解和修改

VitePress 的项目结构通常很清晰：

```text
docs/
  .vitepress/
  posts/
  index.md
  about.md
```

Codex 非常容易理解这种目录结构，也很适合做批量修改。

***

## 为什么还要加 TailwindCSS

VitePress 默认主题是够用的，但如果你想把博客做得更像"自己的站"，就需要做一层样式增强。

我最后没有选 Element 这种组件库，而是用 TailwindCSS，原因也很明确：

> **博客站的核心需求是"样式定制"，不是"重型业务组件"。**

博客真正需要的是：

* 卡片列表
* Hero 区
* 标签样式
* 分类区块
* 深色模式兼容
* 内容页细节优化

这些事情，TailwindCSS 比组件库更灵活，也更适合 AI 生成和修改。

对 Codex 来说，下面这种代码是很好处理的：

```html
<div class="rounded-2xl border bg-white p-5 shadow-sm dark:bg-slate-900">...</div>
```

它比"套一层组件库 API 再二次改样式"更直接。

***

## 这套方案里，Codex 到底解决了什么问题

很多人说 AI 可以写博客，但我现在更在意的是：

> **AI 能不能参与整个博客工程，而不是只写段正文。**

在这套方案里，Codex 最有价值的地方，不是"帮我凭空写一篇文章"，而是能真正承担这些工作：

### 1. 生成文章初稿

我给一个主题和结构，它可以先出完整 Markdown。

### 2. 批量补 frontmatter

比如统一补：

* `title`
* `description`
* `tags`
* `category`
* `draft`

### 3. 改博客模板

比如直接让它：

* 增加标签页
* 增加分类页
* 增加 RSS
* 增加评论系统
* 增加搜索
* 优化首页布局

### 4. 批量整理历史文章

像这些机械活，AI 非常适合：

* 统一标题层级
* 检查文章摘要
* 修复路径
* 过滤草稿
* 归类标签

所以我越来越觉得，AI 对博客最大的价值，不是"代写"，而是：

> **把博客从"手工维护"变成"可工程化维护"。**

***

## 我现在的博客项目长什么样

我现在更倾向于这样的结构：

```text
blog/
├─ docs/
│  ├─ .vitepress/
│  │  ├─ config.mts
│  │  ├─ data/
│  │  │  ├─ posts.data.ts
│  │  │  ├─ tags.data.ts
│  │  │  └─ categories.data.ts
│  │  └─ theme/
│  │     ├─ index.ts
│  │     ├─ style.css
│  │     └─ components/
│  ├─ index.md
│  ├─ about.md
│  ├─ posts/
│  ├─ tags/
│  └─ categories/
├─ scripts/
│  └─ gen-rss.mjs
├─ package.json
└─ esa.jsonc
```

这个结构最大的好处就是：

* 文章层很清晰
* 主题层很清晰
* 数据层很清晰
* 构建脚本很清晰

不管是我自己维护，还是让 Codex 介入，都不容易乱。

***

## 为什么部署选阿里云 ESA

部署这一层，我最后更倾向于选边缘静态托管，而不是继续折腾一堆中间环节。

VitePress 的产物本质上就是静态文件：

```text
docs/.vitepress/dist
```

这意味着它非常适合直接部署到边缘 Pages 平台。

我现在更喜欢的链路是：

```text
Git Push
→ ESA 自动构建
→ 边缘节点发布
→ 域名访问
```

这样做的好处是：

* 不需要单独维护服务器
* 不需要自己手工上传静态文件
* 发布流程短
* 静态站点和 CDN 模式天然契合

这和我想要的博客形态是匹配的：

> **博客应该轻、快、稳定，而不是再养一个服务端系统。**

***

## 这套方案的真正优势，不是"新"，而是"顺"

回头看这次切换，我觉得最大的收获不是换了工具，而是整个博客链路终于顺了。

以前更像是：

* 我在内容平台里写
* 再想办法同步成博客
* AI 只能帮一点点局部内容

现在变成了：

* 我在 Obsidian 里直接写 Markdown
* Codex 可以直接读写文章和站点代码
* VitePress 直接构建
* ESA 直接发布

整条链路都更贴近"开发者工作流"。

这时候 AI 才不再是一个"会聊天的辅助工具"，而是真的成了项目协作者。

***

## 适合谁用这套方案

如果你符合下面这些情况，这套方案大概率会比 NotionNext 更适合你：

* 你本身就是开发者
* 你愿意把博客当成代码仓库维护
* 你希望 AI 能参与批量处理和工程化工作
* 你想要更高的页面可控性
* 你不想让内容绑定在某个平台结构里

反过来说，如果你更看重的是：

* 零门槛
* 完全不碰代码
* 团队协作式文档编辑
* 所见即所得编辑体验

那 Notion 系方案依然有它的合理性。

所以这不是谁一定更高级，而是：

> **你到底是把博客当"内容平台"，还是当"可维护的项目"。**

***

## 我接下来会继续补的东西

目前这套方案已经能满足日常写作和发布，但还有几个方向很值得继续补：

### 1. Pagefind 搜索

让博客具备静态全文搜索能力。

### 2. sitemap 和 SEO 细节

方便搜索引擎收录和社交平台展示。

### 3. OG 图自动生成

让每篇文章都能有更统一的分享封面。

### 4. Obsidian 模板 + Codex Prompt 模板

把"写一篇博客"进一步流程化。

这些东西一旦继续补齐，这套博客就不只是"能用"，而是真正能长期维护。

***

## 最后的结论

我不是单纯因为 NotionNext 不好，才转向这套方案。

更准确地说，是因为当我开始真正把 AI 纳入日常写作和站点维护之后，我发现：

> **Markdown、Git、静态站点、可脚本化，这些东西的重要性一下子被放大了。**

所以最后我选择了：

* **Obsidian** 负责写作
* **Codex** 负责生成、整理、改造
* **VitePress** 负责构建
* **TailwindCSS** 负责样式
* **ESA** 负责部署

这套方案未必适合所有人，但对一个希望把博客做成"长期项目"的开发者来说，它确实比 NotionNext 更舒服，也更适合 AI 时代。

如果你也正在折腾博客，而且已经开始用 Codex、Claude Code 这类工具，那我很建议你试一次：

**把博客彻底 Markdown 化、Git 化、工程化。**

你会发现，整个写作和发布过程都会轻很多。