序言

我的博客已经使用butterfly这个主题很长一段时间了，虽然期间做了很多样式微调，但也难免产生了一点审美疲劳，一直想换一个新的风格。恰逢最近挺无聊的，于是重新搭建一套属于自己的博客系统。

其实重写博客的想法，早在两三年前就已经萌生。当时我特别倾向于前后端分离的动态博客，认为这种动态博客更加的灵活。为此我还专门用 SpringBoot3 + Vue3 实现了一版butterfly版本的动态博客与后台管理系统，但在实际体验了一会Halo这种比我写的更完善的博客后，我发现这种动态博客并不完全适合我的使用场景。我只是想设计实现一套系统罢了，就下意识认为这种动态博客更好，却忽略了我的习惯和强行让自己自适应。最终就放弃了继续优化和完善这套方案，也一直使用butterfly至今。

用AI重写博客

过去一年多，自从DeepSeek-R1发布以后，AI就像打了鸡血一样，发展的更快了。相较于其他的生成式AI，在本就推崇开源的行业，大模型的编程能力更是迎来了爆发式的提升，大模型已经可以高效完成大量的编码工作，十几分钟就可以完成一天的代码量。于是这次重构，就打算尝试全程不手动修改代码，完全由AI完成开发。

在让 AI 编码之前，首先要确定技术栈，毕竟AI可以提供建议，但最终方向还需自己把控。

我最先确定的事情，就是刚刚提到的，继续采用纯前端静态博客，放弃带服务端的动态博客。

很多人都偏爱Halo，WordPress这类动态博客，甚至为静态博客额外接入服务端。更有甚者逐步把博客做成社区形态，引入登录、发帖、权限等复杂功能，不仅开发和维护成本高，备案也会变得麻烦。

有部分人是小白，这种动态博客适合他们，但是我更习惯用 Typora 本地写作，不喜欢在网页编辑器里写，因此静态博客是更适合我习惯的选择。

确定方向后，我看了很多静态站点生成器后，选择了扩展性更好的 Astro负责页面构建；样式与脚本则直接使用原生 CSS + TypeScript，没有引入 Tailwind CSS 这类框架。既然代码都是由 AI 完成，不如回归简洁，大道至简。

整个开发过程，除了反复思考设计风格耗费了太多的时间外，主体功能用几天就全部完成。

实践

设计工具

设计阶段我仅短暂试用了 Figma。它主要的功能就是把自然语言转换成可预览的界面框架，我觉得应该不是生成的代码在后台跑，就只是简单的框架加上图片交互，有点类似墨刀吧。我感觉更偏向产品与设计师的协作工具。

对我这种全干来说，先让 AI 生成设计图再实现，反而不如直接脑补设计，再让 AI 直接生成更高效，毕竟AI生成代码很快，不用考虑花半天时间实现代码后发现不符合心意的问题。而且这样也能更清楚实现成本与取舍，快速更改设计和技术方案吧。

代码生成

代码环节我主要使用了两款AI吧

• 主力：codex (GPT-5.4)
• 简单任务和设计： Gemini3.1

虽然很多人都说Gemini写前端最好，codex写前端一言难尽，但是就我的实际体验来看，Gemini仅仅在设计审美方向上更好，生成代码的稳定性、逻辑准确性等等很多方面都不如codex。使用Gemini的时候，我经常会碰到修改一个功能，组件的样式直接错乱，或者代码生成到一半就中断了，还说已经完成了。而我用codex，在使用同个提示词的情况下，基本可以一次通过，就算不通过，也不会出现样式错乱和逻辑冲突的问题。

skill

我不喜欢安装过多的skill，既占用上下文，又可能导致提示词之间互相干扰，导致一加一小于一的情况。本次只使用了两个：

• superpowers
  ，提供实现方案与测试工作流
• impeccable: 提高设计审美

impeccable就不评价了，让你风格和色彩统一，设计审美更好一点。

superpowers 能让简单项目的开发更规范，但缺点也很明显Token 消耗极高，很多输出冗长。最影响效率的是它会无差别触发完整工作流，哪怕只是修改一个颜色，也会自动生成一整套单元测试，大量时间被无效测试浪费，只能去更新他很多的提示词做矫正，但这也很难阻止大多情况的故意复杂化了。也不是说测试不好，但这个skill是无法判断是否需要启动这个工作流，也无法判断是否需要进行测试，容易导致大量Token被浪费掉。使用Gemini就是这样，有时候会假模假样的加个单元测试，测试成功了样式也会错落，功能也没有实现。

所以当发现AI输出的内容，处理问题的方向出错了，偏离了预期，就要立即中断，重新引导或者重新开另一个会话，避免白白浪费Token或者把逻辑思路引导到更难解决的方向。

工程管理

AI写代码一开始就要设计整体的架构和组件的设计和调用，最好就是有想法了，就让AI去判断这个设计行不行，不然越到后面越难改。总体架构设计好后，直接让AI协助生成一份项目的提示词，把架构，边界，代码处理都写好，避免AI乱改代码。经过大改动的话，就让AI优化一下AGENTS.md和GEMINI.md就行。

虽然这么说，但是开发到后面，代码写的太快，加上不经常写样式和脚本，于是review就及其痛苦，你也不知道写的是不是最好的方案，写的是不是有问题，看不过来的，即使是让AI开高推理去review，这个项目也难免变成半个黑盒，反正是没出现过怎么修都修不好的bug，只是有些心里负担罢了。

除了项目文档，还写了一些其他的辅组skill。比如风格色彩，git规范提交，文档处理等等，原本想写成command的，发现command已经被codex和claude code淘汰了，功能合并到skill里面，只有gemini还保存这个管理command的功能，没几个月就成为时代的眼泪了。

结尾

现在AI发展的很快，感觉博客和Stack Overflow一样，越来越少人写东西，问问题了，遇事不决就问AI。

搞的我也不知道要写什么了，除了比较冗长不好问到的东西，基本都是问AI了。

可能后面随缘写点其他东西吧hh。