升级blog & Vibe Coding 随笔

缘起

这个博客陪我走过了不少年头了。

最早是 Hexo，然后是 Gatsby，现在又折腾到了 Next.js。每次翻新都像是给自己的一亩三分地松松土，虽然种的东西差不多，但锄头换了，心情也不太一样。

其实旧版也不是不能用，Gatsby 那版跑了挺久，文章能看、评论能发、构建也没啥大毛病。但人嘛，看到新的工具总会手痒。

这次升级的动力其实很简单 —— 我就想把博客弄干净点。

旧版的依赖越积越多，一些插件年久失修，每次 npm install 都要和 peer dependency 打架。加上 Next.js 15 出了，React 19 也稳定了，TailwindCSS 4 的响应式写法也比以前舒服不少。于是就动手了。

当前架构

先说说现在的技术栈，算是个快照。

框架 & 构建

Next.js 15 (App Router) — 从 Gatsby 的 SSG 切过来，App Router 的文件约定和 Server Components 确实让项目结构清爽了不少。虽然不是冲着 SSR 来的，但多一个选项总没坏处。
React 19 — 没什么特别要说的，就是新，稳。
TypeScript — 全程 TS，类型覆盖比之前那版好太多了，主要是 contentlayer 的类型推导帮了大忙。

内容 & 渲染

Contentlayer2 — 这是这次升级最满意的一环。所有文章都是 MDX，放在 data/blog/ 下面，contentlayer 自动生成类型、slug、TOC、阅读时间，构建时一并算好。写文章只需要一个 .mdx 文件加个 frontmatter，其他什么也不用管。
Remark + Rehype 全家桶 — GFM 表格和任务列表、数学公式 (KaTeX)、代码高亮 (Prism)、自动 heading link…… 基本开箱即用，调了一下 heading 的锚点样式就差不多了。

样式 & 交互

TailwindCSS 4 — v4 的 @theme 和 CSS-first 配置方式比 v3 的 tailwind.config 直观太多了。博客这种内容站用 Tailwind 恰到好处，不用写太多自定义样式。
motion (原 framer-motion) — 给页面加了点过渡动画，主要在导航和文章列表的进出场。不花哨，就是那种"看着舒服但不会注意到"的程度。
Headless UI / Base UI — 用了几个无样式组件，主要是处理焦点管理和无障碍。自己写这些太麻烦了。
Gitalk — 评论系统，基于 GitHub Issues，够用。本来想过换 Giscus，但 Gitalk 的数据都在，懒了。
Kbar — 本地搜索，按 cmd+k 弹出来，contentlayer 生成 search.json 给它喂数据，速度很快。

工程化

ESLint 9 + Prettier + Husky — flat config + 自动格式化，提交前自动检查。
自定义迁移脚本 — 从旧 Gatsby 博客迁移数据的脚本是 AI 帮我写的，把 frontmatter 和图片路径做了一轮转换（这个后面再说）。

从 Gatsby 到 Next.js

为什么要换？说白了就是 Gatsby 太重了。

Gatsby 的 GraphQL 数据层在博客这种场景下显得有点过度设计。几十篇文章而已，犯不着搞一层 GraphQL 中间层。加上 Gatsby 的插件体系虽然强大，但插件之间的兼容性是个持续的维护负担。

选 Next.js 的原因也很简单：

App Router 的文件即路由，直觉上比 Gatsby 的 createPage 好理解
Server Components 让大部分页面可以静态预渲染
Contentlayer2 完美替代了 Gatsby 的 GraphQL 数据层，类型还更友好
社区大，踩坑好找答案

整个过程大概花了一个周末的零碎时间，不算太折腾。

Vibe Coding 这件事

这次升级绝大多数的代码都是 AI 帮我写的。对，你没看错。

具体来说，我同时在用两个工具：Claude Code 和 Codex。它们给我的体验不太一样，趁这个机会记一下真实感受。

Claude Code

Claude Code 是那种"你很放心把活交给它"的感觉。

比如我说："帮我把 Gatsby 博客的 MDX 数据全部迁移过来，frontmatter 格式转成 contentlayer 的 schema"，它能先把两边格式看一遍，然后直接写迁移脚本。中间有几个图片路径的边界情况我提了一嘴，它改完就通了，基本没怎么返工。

Claude 让我最舒服的地方是：它不会盲目写代码，而是先理解上下文再动手。

比如升级动画的时候，我说"加点过渡效果"，它会先读我的 layout.tsx，看看现有结构，然后给出针对性的方案，而不是直接甩一坨代码过来。这种"带着脑子干活"的感觉，确实和一年前的 AI 体验天差地别。

它还擅长一些我不太想动脑子的事情：

改 ESLint flat config。这玩意儿语法别扭，自己研究至少一小时，丢给 Claude 五分钟搞定。
写 TypeScript 类型。contentlayer 的类型推导有些边缘 case，它帮我把 computedFields 的类型补得明明白白。
批量重命名和重构。几十个文件的路由调整，一句描述的事。

Codex

Codex 的体验更偏"探索型"。我更多用它来做一些试水的事情，比如：

快速搭一个 prototype 的页面结构
对比不同技术方案的实现（"这个组件用 Headless UI 和直接用 Radix 分别怎么写？"）
查阅一些新 API 的用法

Codex 给我的感觉更像一个"很能写的同事"，节奏快、产出多，但有时候需要自己把关。

两个工具串起来用的体验其实是最好的：Claude 干扎实的工程活，Codex 用来快速探索和 prototype。感觉像是有了两个风格不同的搭档。

关于 AI，我目前的看法

不吹不黑，说点接地气的。

AI 写代码的效率，不用我多说了。 这次升级如果纯手写，保守估计 2-3 倍的开发时间。那些配置文件、迁移脚本、模板代码，放在以前就是对着一堆文档搬运，现在一句话的事。这部分的时间节省是实打实的。

但 AI 不是替代，是放大器。

用了一个多月，我最大的感受是：AI 让好的开发者更好，但它很难让不懂的人变懂。原因是这样的 ——

你至少需要知道：

你要什么 — 能清晰地描述需求和预期结果，这本身就是一种能力。说"帮我升级博客"和"帮我把 contentlayer 的 computedFields 调通"是两种完全不同的效果。
它给的对不对 — AI 生成的代码你得能看懂、能判断好坏。如果自己都不懂 React，AI 写出来的东西你敢直接上生产吗？
什么时候该停下来 — AI 容易让人上瘾，什么都想让它写。但有些事情，比如文章的内容、设计的品味、代码的架构取舍，这些还是得自己来。

我的切身感受：AI 帮我解决了 80% 的体力活，但剩下 20% 的决策 —— 比如选哪个动画库、路由怎么组织、要不要上 SSR —— 这些才是真正决定项目质量的东西。

也别把 AI 想得太神。它写出来的代码有时候会有一种"AI 味"—— 语法没问题、逻辑也没毛病，但就是感觉哪里不对。比如过度的错误处理、不必要的抽象、或者那种"教科书式但完全不符合项目风格"的命名。这些东西如果你自己不把关，日积月累就是一堆技术债。

你始终得知道自己要什么，以及它给你的到底是什么。

一些碎碎念

这次升级还有一些小收获：

动画别贪多。motion 加动画是好用，但我一开始加多了，整个页面花里胡哨的，看着累。后来删了一大半，只保留导航和文章列表的淡入，一下舒服了。
TailwindCSS 4 值得升级。v4 的 CSS-first 配置 + @theme 真的比 v3 好太多，以前的 tailwind.config.js 臃肿得不行，现在清爽多了。
blog 这种东西，静态就够了。Next.js 能跑 SSR，但我最终都是走的静态导出。个人博客没那么多动态内容，静态文件又快又省事，CDN 一挂，稳得很。
少即是多。这次升级最大的目标其实是"做减法"：删掉了用不上的插件、去掉了多余的动画、简化了配置。效果反而比之前好。

博客这东西，就像一个老朋友。可能一年也说不了几句话，但每次看到他，还是觉得挺踏实的。

祝好。

缘起