第一篇博文

两天半，我用 AI agents 搭了一个 Notion 博客系统

2026 年 3 月 4 日，博客正式上线。

这篇文章不讲“怎么从零学 Next.js”，而是记录一个更实际的问题：

当你对框架并不熟，怎么在两天半内把一个想法做成可部署、可维护的系统。

为什么要自己搭

我一直想写博客，但不想完全依赖现成平台。

核心原因很简单：数据和内容结构我希望自己掌控。

我平时本来就在 Notion 里写笔记，所以思路很自然：

技术栈定得很快：Next.js + Notion API + Vercel。

说实话，开工时我对 App Router 和服务端数据流并不熟，很多地方是边做边补。

我怎么做“vibe coding”

这次最大的体会是：

vibe coding 不是“让 AI 把代码写出来就结束”，而是“让整个过程可控”。

我把流程固定成了 3 个文件：

对我来说，这比“写了多少代码”更关键。因为它决定了后面能不能改、能不能查问题、能不能继续迭代。

并行协作是怎么跑起来的

在中段开发里，我把互不依赖的任务拆开并行：

每个 agent 只负责自己的小块，完成后回填 Implement.md。

等同一阶段都到“待提交”后，再统一提交，统一审阅。

这个约束我一直在坚持：一个阶段一个 commit。

好处是回滚和复查都很清楚，不会被一堆碎提交淹没。

审阅环节帮我挡下了不少坑

我把代码审阅当成硬门槛，不是走流程。

有几个问题就是在审阅阶段被及时拦下来的：

这些问题如果带到线上，后面会很难排查。

越早修，成本越低。

这次踩过的坑

1) Notion API 版本和调用方式

新版 Notion API 对 Database / Data Source 的处理和旧资料不完全一致。

一开始按旧习惯写，结果线上和本地行为对不上。

2) ID 格式

Notion 返回的 ID 可能是带连字符 UUID，而本地配置常见的是 32 位紧凑格式。

后来在代码里做了统一格式化，避免这类低级错反复出现。

3) Token 校验

新旧 Token 前缀不同（例如 ntn_），老逻辑只认旧格式会误判。

4) 中文字段名匹配

数据库字段是中文（标题、类型、标签、状态），代码里一旦写错一个字，查询就会直接出问题。

这个坑其实最耗时，因为看起来像“接口偶发不稳定”，实际是字段名不一致。

我最后用到的技术栈

5 条对我最有用的经验

最后

这个项目代码量不算大，但协作方式对我帮助很大。

我负责目标和验收，AI 负责执行，审阅机制负责兜底。

两天半做完一版能上线的博客，这个节奏我满意。

下一版会继续优化内容工作流和线上观测。