我用 AI 为 Hugo 打造了博客文章发布平台

自从去年 10 月将博客从 Typecho 迁移到 Hugo 之后，静态博客在访问速度、数据安全和服务器资源占用上的优势让我非常满意。

但不得不面对静态博客最大的痛点：没有成熟的文章后台发布系统。我一直采用手动创建文件夹并新建 markdown 文件的方式来写博客，特别是我还用到了一些关于图片方面的 Shortcode……

AI 这么成熟的今天，特别是龙虾🦞近期也是非常火爆。那我就把这个想法告诉了 Gemini，让其帮我实现：

帮我写一个纯前端的“无头 CMS”，直接挂载在我的博客域名下，随时随地打开网页就能写

我把我的需求、Markdown 模板以及复杂的文件树结构一股脑喂给了 AI，要求它以“高级产品经理 + 程序员”的身份帮我实现。下面把关键节点记录如下：

第一阶段：Node.js 方案

最开始，AI 给出了一个常规解法：用 Express 跑一个本地服务，前端写页面，后端直接操作本地文件系统。

但这完全背离了我的初衷。我的博客代码托管在 GitHub 上，由 GitHub Actions 自动构建部署到云服务器。如果每次写文章还得在本地打开终端运行 node server.js，这和在终端敲 hugo new 没什么本质区别。

于是立刻否决这个方案，向 AI 提出了进一步要求：我要纯前端实现，没有服务器，直接通过 GitHub API 读写仓库！。

最终给我一份纯 html 的前端文档，满足要求。

第二阶段：安全性与便捷性

纯前端方案确立后，最大的难题是​鉴权​。

AI 给出了以下方案：

系统内置了一套基于 crypto-js 的 AES-256 军事级加密引擎。首次使用时，我输入真实的 Token 和一个​自定义的短密码​，系统将 Token 加密成一串绝对安全的乱码，这串乱码被硬编码在 HTML 文件里并推送到线上。

访问后台时，系统只会弹出一个极简的密码框，输入自定义的短密码即可登录。

第三阶段：重塑文件流与防灾机制

解决了底层连通问题，接下来就是用户体验方面的问题。

1. 打破 GitHub API 限流的标签提取

为了在侧边栏显示真正的中文标题，并在下拉框里提供全量的历史标签，系统需要读取以前的所有文章。一开始，几百篇文章的并发请求差点触发 GitHub 的接口熔断限制，导致界面假死。

经过优化，​利用 Hugo 自身生成的 /tags/index.xml RSS 文件​，通过 while 循环突破 RSS 的分页限制，几乎瞬间即可遍历目前存在标签。

2. 引入 IndexedDB 的离线图库与草稿箱

在使用网页编辑器时，最怕的就是断网或手滑刷新导致排版好的图片和文字全部丢失。

起初想过用第三方图床中转，但存在跨域和失效风险。最终，利用了浏览器自带的 IndexedDB 数据库。

目前实现了：选好 1-3 张图片，系统会自动将它们重命名、转存进浏览器的本地数据库，并在 Markdown 中生成 Shortcode 格式的图片引用，且具体使用的引用短代码跟图片数量相关。

只有最终点击“同步至 GitHub”时，这些图片才会和文字一起被打包 push 到指定仓库。

3. 修改时间记录管理

我对于博客的修改时间尤为关注，之前手搓 markdown 文件时，都会将之前的修改时间在 Frontmatter 中以注释的方式进行保存。

这次也指定了 Frontmatter 的解析逻辑：如果在后台勾选了“本次记录修改时间”，系统会将最新的时间写入 lastmod，并将之前的历史修改时间自动加上 # 号变成注释永久保留。

结语

从最初简陋的本地脚手架，到最后集成了 Vditor 编辑器、AES 前端加密、IndexedDB 离线图库、RSS 极速抓取引擎、三级折叠目录树 的文章发布平台，agent 没有 token 了，只能通过网页端与 AI 聊了大概二十多个回合，终于算是弥补了静态博客的最大短板。再次感叹下，AI 真强。

另外，这篇博客就是使用这个平台发布的第一篇博客……