Vibe Coding之Notion To Blog

Created At: Sep 15, 2025

别问我为什么几年都不写一个文章

显然 Notion 是一个很好用的笔记软件，毕竟，在上面写东西的体验还行。但是直接把它用作博客的话，就很难绷了，毕竟作为一个博客怎么能接受他™连个主题和域名都没有呢。同时也不是没调研过现在的 NotionNext 什么的项目，毕竟支持的主题有限，而审美又 match 不到。那么不如为啥不直接用 Hugo 来处理 Notion 的 Markdown 文档，再去生成文本捏？虽然网上有各种 Notion 转 markdown 项目，但是支持的 block 类型不够，而且几年也不更新了，那么不如我们来吧这个屎坑给他占过来。

既然是为了造轮子，那么不妨也来尝试下 Vibe Coding ，让 AI 帮我们把 Notion 变为 Blog。

image.png

第一关：折腾 notion-to-markdown 的血泪史

Step 1: MVP

以我期待的 AIGC，它能直接帮我把这个项目实现完，我只需要给他我的需求就好。建立在把 Notion 文章转成 Markdown 内容的这个基础上，它认为任务有这么几个，并且搞了个 TODO list：

  1. 连上 Notion：用 NOTION_TOKEN 读到我的数据库。
  2. 转换基本内容：先把段落、标题、列表这些最简单的东西变成 Hugo 能用的文本。
  3. 搞定 Frontmatter：把文章的 Title, Date, Tags 这些属性抓出来，拼成静态博客需要的元数据。
  graph TD
    subgraph "MVP 阶段"
        A[配置 Notion Token] --> B[查询Database];
        B --> C[遍历页面Block];
        C --> D[基础Block转Markdown];
        B --> E[提取Properties转Frontmatter];
        D & E --> F[生成带Frontmatter的.md文件];
    end

没花多少人力~~（指直接开启了 Auto-Approval ，让它全自动开转了半个小时）~~，第一个版本就跑通了。不过，在我试着把网上找到的另一个很复杂的 doc 直接丢到我的 db 之后，现实就开始教我做人了。

Step 2: 填坑

第一个坑：图片给你个 404

看Markdown文档的时候发现，Notion 给的图片 URL 是 AWS S3 的临时链接，而且 AI 显然也不知道这个事情。。。。

那么，不能惯着它，告诉他缓存！于是 AI 立马改了逻辑，在转换时，把所有图片都下载到本地，再把链接替换成相对路径。

在这个过程中，AI 能实现很多我想到的，但是在我 MVP 过程中绝对不会写的功能，比如它顺便做了个缓存（代码在 internal/renderer/file_cache.go ）（这也是为啥直接想把它改成通用的 notion-to-markdown 的动力，毕竟 AI 的代码完善度还挺好？）

第二个坑：站内链接当场跑路

Database 中的文章可以互相引用，但在 Blog 中的链接是完全不一样的，总不能看着看着博客直接跳回 Notion 吧，于是准备让 AI 自己去把问题解决掉。

默默看着它开始分析 Notion 的链接格式，在正式处理每篇文章内容前，遍历一遍整个 Database，创一个 Page ID (UUID) 到 Slug 的 map。

看着挺好对吧？然而这个狗东西（Claude 4）不知道 Notion 链接里面的实际上是个去掉了 - 的 UUID，于是又要教他做人，把这个横杠先处理掉，再放到 Map 里面，才能搞得定。

第三个坑：复杂内容

我在文章里用 KaTeX 写了公式，用 Mermaid 画了流程图。结果发现，不同框架对这些东西的语法要求五花八门：

  • Hugo 用的是 {\{< shortcode >}}
  • Hexo 用的是 {% tag %}
  • 还有些用的是通用的 $$...$$

于是开始让 AI 把里面这堆破烂玩意的渲染流程给改掉，我告诉它我不想每次都改代码，于是它帮我写了一个 config.go 文件。。。

于是我告诉它用 yaml，结果他这次确实是动态加载了，但是把之前设计的用 Template 渲染的逻辑改成了用 Prefix ， Middle ， Suffix 来特么处理，这我哪忍得了，直接开始在让它改成 Template。

Step 3: 出成果（大厂黑话） - 把它变成一个谁都能用的 GitHub Action

填了这么多坑，这个 Go 程序已经相当靠谱了？？？我突然觉得，这东西不应该只躺在我的电脑里（有史大家一起吃）。于是我决定把它打包成一个 GitHub Action。

处理工程化过程的 AI 还是很靠谱的（也有可能是 Github 的文档写的好？）。整个需求其实就是从 main 里面找参数，然后按 Github Action 的格式封装一个 yaml，（顺便再帮我写个文档），结果不知道是不是知识库不够新，它写完了发现还得自己查文档帮它改版本改参数，难绷。。。

到这里，notion-to-markdown 完成了（暂时）。

第二章：lvm.me

本来想的好好的，AI 写完了 notion-to-markdown 这个苦力（3天啊！那可是3天啊！），我的博客 lvm.me 应该就轻松了吧，于是开始了第二次的 AIGC。

Step 1: 改改主题

感谢 AI 教会了我一点都不会的 css，整个这个流程就是复制 css 官方的 Template（不然 AI 一点审美都没用），把 css 加 context，然后开始让 AI 打黑工写主题。

那么流程就变成了，苦逼的我找 Template，手动把代码切分成若干个块，然后开始逐条 AIGC。。。干了多少呢。。

  1. Equation
  2. Mermaid
  3. TOC
  4. Friend Links
  5. Archive
  6. Nav bar
  7. Giscuz（本来还想给他写个主题，但是发现 AI 完全没有审美，我也懒得教了。。）
  8. Single Page
  9. List Page

这样一点一点把东西让它帮我攒出来，终于能看了。。。

Step 2: 自动发布

最后一步，也是最顺利的一步，毕竟没有“代码”了，都是工程化的 yaml 工程，AIGC 的很开心.

这个 GitHub Action 会定时跑，拉最新的文章，用 Wrangler 构建，然后部署到 Cloudflare Workers。（你能看到这个文章说明构建成功了）

  graph TD
    subgraph "lvm.me 自动化发布流程"
        A[在Notion写作或修改] --> B{Action 定时触发};
        B --> C[Invoke ManassehZhou/notion-to-markdown@main];
        C --> D[同步最新内容到 content];
        D --> E[Wrangler deploy!];
        E --> F[网站更新];
    end

总结

从一个想法到最终实现，AI 在这个过程中扮演了一个写代码的黑工，但是这个黑工还需要你来指导，而不是可以默认他能全知全能。

AI 的优势：

  1. Quick MVP：在 AI 的帮助下，整个工程的效率极高，它能够根据你给的输入（连接 Notion、转换基础内容、生成 Frontmatter）迅速从 go mod init 开始一步一步把能工作的代码弄出来，并且自己去解决里面的bug，消灭了鸽子的理由。
  2. 工程化能力：在处理工程化任务时，AI 依旧效率极高。比如，接着官方文档把 Golang 程序封装成 GitHub Action、写 Github Action 的 Workflow这些简单任务的时候。
  3. 出乎意料：感谢大数据喂给 AI 的语料，AI 有时会根据全民创作人的经验，把一些你没提需求，明显是优化性质的功能给加上，比如在下载图片的这个功能里面，它自己加了缓存。

为什么我觉得程序员还有的活：

  1. 缺乏领域知识：AI 不了解 Notion API 的一些“潜规则”，比如链接的 UUID 需要特殊处理（虽然有可能是我没让它写testcase，或者没真给它 database 让它测试导致的）。这些问题都需要人去debug，再教给 AI 解决。
  2. 设计能力欠佳：AI 的第一反应往往是“naive”的。让它写一个可配置的公式渲染模板时，它直接给了我这个不想改代码的人一份 config.go。那么人就需要及时指出它不合理的逻辑，让它去改改改，这样才能完成一个Well Architecture。
  3. 过时知识库：在生成 GitHub Action 的配置文件时，AI 使用了旧的 action 版本，甚至有些已经deprecated 掉的逻辑（毕竟语料截止到 xxxx 时），这个时候就需要人工查文档 + 更正（毕竟现在在写代码的时候不能开web search）。
  4. 审美Emm & 网上资料很少的场景：在设计博客主题任务上，虽然给了它整个我要用到的 css 框架的文本，但是 AI 并不能理解这种看不见摸不到的前端（coding 这种任务默认是纯语言模型）。那么就导致最终变成了人去寻找模板、拆分模块，然后让 AI 填充代码的活。

但是嘛，自从OpenAI开始把整个互联网的屎坑都喂给了显卡，概率学的暴力美学开始展示它独到的泛化能力之时开始，AI的能力一直在不断提升。谁知道未来还需不需要我们这群写代码的人？抑或是原来需要一群人写的代码变成了一个人去给AI做Code Review？怎么说呢，骑驴找马，边走边看，希望有一天可解释的LLM出现，希望有一天LLM可以开始解决创造性的问题。

Tags:
mzzzz © Powered by Hugo.