第一篇博文

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

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

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

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

为什么要自己搭

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

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

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

• 内容在 Notion 管
• 前端自己搭
• 部署交给 Vercel

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

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

我怎么做“vibe coding”

这次最大的体会是：

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

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

• plan.md：拆解阶段和任务
• Implement.md：记录每个任务状态、负责人、耗时和提交
• code review 规范：每个阶段必须过审才能算完成

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

并行协作是怎么跑起来的

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

• Notion 数据访问层
• 内容转换和领域模型
• 前端页面与组件

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

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

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

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

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

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

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

• 客户端调用敏感接口，存在 Token 暴露风险
• 点赞逻辑有竞态条件
• 部分 API 错误码不符合语义，导致前端降级行为混乱

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

越早修，成本越低。

这次踩过的坑

1) Notion API 版本和调用方式

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

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

2) ID 格式

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

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

3) Token 校验

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

4) 中文字段名匹配

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

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

我最后用到的技术栈

• Next.js 15 + TypeScript + App Router
• Notion API（按当前版本适配）
• Vercel（ISR + Serverless）
• Tailwind CSS + shadcn/ui
• FlexSearch（站内搜索）
• Giscus（评论）
• Upstash Redis（点赞）

5 条对我最有用的经验

1. 任务一定要拆小，最好半天内能闭环
2. 状态必须落盘，不要只靠聊天记录
3. 审阅要独立，别让“能跑”替代“能维护”
4. 提交粒度按阶段收敛，后期排错会轻松很多
5. 接受 AI 会犯错，把修正流程标准化

最后

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

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

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

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

• 个人博客（生产环境）： https://blog-three-gilt-7yh9tj7yxv.vercel.app/
• 代码仓库（GitHub）： https://github.com/ddong0417lin-prog/blog