我为什么放弃 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 的工作流通常会变成这样：

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

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

而我更喜欢的是：

Markdown
→ Git
→ 构建
→ 发布

简单、明确、可控。

---

我最后选择的博客方案

最后我定下来的方案是：

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 的项目结构通常很清晰：

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

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

---

为什么还要加 TailwindCSS

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

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

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

博客真正需要的是：

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

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

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

<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 对博客最大的价值，不是"代写"，而是：

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

---

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

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

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 的产物本质上就是静态文件：

docs/.vitepress/dist

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

我现在更喜欢的链路是：

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 化、工程化。

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