从优化到创造——我的VibeCoding初体验
本来只想改个页脚，最后做了一款写博客的应用
配图为本次优化历程的概念插画。
这次折腾博客，一开始真的只是一些很小的问题。
先确认 Git 结构，再看看网页底部的「Hexo ♥ Fluid」在哪里修改。顺着这些问题，我让 Codex 把整个博客文件夹分析了一遍：现在是怎么生成网页的？源码放在哪里？部署流程还有哪些可以优化？
然后，对话里开始反复出现几个词：
「一步一步来。」「下一步。」「部署。」
等这轮优化结束，我得到的除了一个更好维护的 Hexo 博客，还有一款可以双击打开的桌面应用：Blog Studio。写文章、放图片、看预览、推送源码、部署网站，都逐渐被装进了同一个界面。
回头看，整个过程的变化，比最初预想的大得多。
先把博客的底子理清楚
我的博客用的是 Hexo 和 Fluid，内容主要是摄影、胶片和日常生活。
网页能打开，不代表它背后的文件和发布方式已经足够清晰。第一步，我先把源码、生成的网站和部署仓库的关系弄明白，再把源码同步到 GitHub 的 blog-source 仓库。
文章、主题配置和维护工具有了可追溯的记录；依赖目录、生成的网页、本机配置和原图备份，也有了各自的边界。
接着修的都是看起来不大、却影响日常使用的问题：新建文章模板的占位符、部署前是否重新生成网站、构建失败后是否还会继续执行。
发布顺序也明确下来：先构建，确认成功，再部署。
Fluid 配置则从 170 行精简到 55 行，去掉混在里面的站点配置，把首页横幅等设置放回正确的位置。以后再改一项外观，不用先在一大段配置里猜它到底归谁管。
摄影博客，图片值得认真处理
这一轮最直观的数字变化，来自图片。
仓库中 16 张已有的 WebP 图片经过尺寸和压缩参数优化，总体积从 **15.42 MiB 降到 6.78 MiB，减少约 56%**。原图保留在本机，必要时可以恢复。
这里有一个容易忽略的点：这些照片原本就已经是 WebP。换成某种格式，并不等于图片已经适合网页；尺寸和压缩方式同样会影响文件大小。
这次没有做完整的访问速度对照测试，所以我能确定的是图片体积变小了，不能直接把它写成“网站快了 56%”。但对以照片为主的博客来说，少传输这么多数据，是一项很实在的改善。
优化过程中，也要知道什么时候停下来
依赖更新进行到一定阶段，我明确提出：暂时不升级 Hexo 核心，继续做其他优化。
最后 Hexo 仍保持在 6.3.0，先更新相对低风险的周边依赖，清理不再使用的部分。与此同时，构建入口被统一，GitHub Actions 也加了进来：每次推送或提交拉取请求，都在干净环境里安装锁定依赖、检查博客能否成功生成。
这让我多了一层把握：项目的构建条件开始变得可重复、可检查。
内容层面的细节也慢慢补齐。站点描述从笼统的“个人博客”，改成更贴近摄影、胶片和日常生活的介绍；补上搜索引擎相关配置，启用规范链接，让页面明确自己的标准地址。
对于旧图片的 alt 文本，我当时选择先不批量处理。浏览器标签页的图标则反复确认了一遍，从 avatar 的想法，最终统一到了 me.jpg。
这些事情大小不同，但每一步都对应一个具体问题。优化做到这里，我已经不想继续无限加项目了。
然后，我提出了一个新的需求。
我想通过界面完成发布
优化到此结束。接下来给我一个方案，能够通过界面发布新文章、部署和推送。
接着，我又补了一句很关键的要求：
目标是给我一个应用程序，不需要命令行启动服务器之类的操作。
这句话决定了后面的方向。
过去那些由人依次完成的步骤，需要被整理成一套可以从界面触发、也能从界面看见结果的流程。于是，Blog Studio 的第一期开始了。
它被做成一款 Windows 桌面应用。双击 EXE，就能进入本地博客工作区，管理文章、编辑正文、启动预览、查看日志并发布。
发布流程示意：草稿保留在本机，正式发布内容经过构建和校验后上线。
发布按钮背后串起了这些动作：
保存文章 → 优化图片 → 本地构建 → 提交并推送源码 → 等待这次提交的 Actions 检查通过 → 部署网站。
这里的 GitHub Actions 负责构建验证，后续部署由应用接着执行。等待的也是这次提交的结果，而不是看到仓库里曾经有一次绿色通过就继续发布。
我还明确了一个习惯：相关检查确认通过后，可以继续部署，不用在每个环节重新问一遍。
当然，应用仍然依赖电脑上已有的 Node.js、Git 和博客环境。它把这些操作收进了后台，日常写作时，我不必再手动输入命令。
第二期，开始关心写文章时的每个小动作
能发布之后，我的注意力转向了写作过程。
照片能不能直接拖进去？能不能自动转 WebP？图片链接还要不要自己敲？封面、横幅和摘要能不能在界面里选？
这些需求逐个落地：
- 拖入 JPG、PNG、WebP 或 AVIF，自动转换为 WebP；
- 确认图片说明后，自动插入 Markdown；
- 从本文图片中选择封面和横幅；
- 从正文选区或首段快速生成摘要；
- 新文章默认保存为本机草稿；
- 已发布文章归档并默认收起，打开软件直接进入新建页面。
旧图没有批量补 alt，但新上传的图片开始有了说明提示。这样，新增内容可以从写作时就逐步养成更完整的习惯。
草稿也有了明确的状态：先留在本机，准备好之后再切换为已发布。未保存提醒、保存冲突保护这些不太显眼的功能，也一起补上了。
对我来说，软件打开时先出现一张新文章页面，是一个很合心意的细节。过去的文章依然能找到，而“开始写点什么”变成了最直接的动作。
最后，让 Markdown 真正显示出来
写作界面有了，我又提出一个很自然的要求：
「能不能把 Markdown 渲染出来？」
于是，正文区域增加了编辑、分屏、预览三种模式。标题、列表、引用、代码块、表格和本地图片，都能随着输入即时显示。
写作体验概念插画，并非应用实机截图。
即时预览解决的是边写边看的需要；要确认完整的 Fluid 页面效果，仍然可以使用“保存并预览”。
在实现过程中，也处理了本地图片的读取边界、危险 HTML 的过滤，以及快速切换文章时旧请求覆盖新内容的问题。最后还用打包后的应用实际打开文章，确认本地照片能够正常显示。
等应用可以正常用了，我又补上最后一个要求：
「打包出来的应用不要用默认图标，用你设计的。」
于是，暖陶土色底、象牙色纸张和墨绿色笔尖组成了 Blog Studio 自己的图标。到 0.3.0 这一版，它已经有了比较完整的写作、预览和发布体验，也有了自己的样子。
回头看，这次优化改变了什么
从最初的页脚和 Git 问题，到图片、配置、构建检查，再到桌面应用，这次迭代始终是一步一步推进的。
我负责把使用时的需求说清楚，也决定哪些先做、哪些暂缓；Codex 负责分析、实现和验证。一个功能做完，实际用起来，新的问题就会浮现，下一步也因此变得具体。
图片体积减少约 56%，是最容易展示的成果。另一项变化则发生在每天准备写文章的时候：原本分散在文件夹、命令行和网页里的操作，现在有了一个连续的入口。
我终于可以双击打开自己的写作工具，把照片拖进去，写几段文字，看看排版，再把它发布到博客上。
折腾这些东西的起点，还是想好好记录摄影、胶片和日常。现在，通往下一篇文章的步骤少了一些。
博客：小菜籽油
源码：xiaocaiziyou/blog-source
#个人博客 #Hexo #Fluid #BlogStudio #AI编程 #独立开发 #工作流优化