最近越折腾越觉得，博客不该只是“写完发出去”的地方。把 VanBlog 接上 Codex 后，文章、头图、标签和摘要都能进入一条半自动流水线，很多零散经验终于有机会沉下来。

---

一、为什么是 VanBlog + Codex？

VanBlog 对个人博客来说已经足够顺手：后台写作、Markdown、图片管理、分类标签、RSS、Sitemap 都有，部署也比较省心。

Codex 的价值则不只是“帮我写字”。更准确地说，它适合做这几件事：

• 读旧文章，整理现有内容结构。
• 根据主题生成新文章草稿。
• 优化标题、导语、分类、标签和摘要。
• 根据文章内容生成头图提示词。
• 调用 VanBlog API 上传图片、创建草稿、更新文章。
• 每次改动前后生成审阅清单，避免批量翻车。

也就是说，VanBlog 负责承载内容，Codex 负责把散落的信息加工成内容。

---

二、整体架构：让博客多一个“自动化助手”

这套方案不打算一上来做成全自动发布。我的目标是 半自动：Codex 可以批量处理，但最后发布前必须经过人工确认。

整体链路可以拆成六步：

text
素材输入
  ↓
Codex 整理文章结构
  ↓
生成或优化 Markdown 草稿
  ↓
生成匹配文章主题的头图
  ↓
通过 VanBlog API 上传图片并创建草稿
  ↓
后台预览，人工确认后发布

这个模式的好处是安全：AI 可以提高产出速度，但不会直接越过我把文章发出去。

---

三、VanBlog API 能做什么？

VanBlog 自带 Swagger 文档，访问：

text
https://你的域名/swagger

后台生成 API Token 后，请求时把 token 放进请求头：

bash
token: 你的 API Token

常用接口大概有三类。

1. 读取文章

公开文章可以直接读：

bash
GET /api/public/article/{id}

后台完整读取需要 token：

bash
GET /api/admin/article/{id}

这一步可以让 Codex 拿到原始 Markdown、分类、标签、发布时间等信息，然后做文章体检。

2. 上传图片

头图生成后，通过图片接口上传：

bash
POST /api/admin/img/upload?withWaterMark=true

表单字段是：

text
file: 图片文件

上传成功后，VanBlog 会返回类似这样的站内路径：

text
/static/img/xxxx.webp

之后只要把 Markdown 第一行替换成：

md
![文章头图](/static/img/xxxx.webp)

文章头图就完成了。

3. 创建草稿或更新文章

创建草稿：

bash
POST /api/admin/draft

更新正式文章：

bash
PUT /api/admin/article/{id}

我更倾向于让 Codex 先创建草稿，而不是直接更新正式文章。这样后台可以先预览，确认没问题再发布。

---

四、我准备怎么用 Codex 优化旧文章？

我的博客里已经有不少折腾记录，比如 Docker、极空间、旁路由、内网穿透、本地 AI、Windows/Linux 工具等。它们的问题不是没价值，而是有些文章还停留在“当时能看懂”的状态。

Codex 可以按文章逐篇做这几类优化。

1. 标题优化

标题不一定要夸张，但要让读者一眼知道解决什么问题。

比如：

text
Docker部署mihomo

可以优化成：

text
Docker 部署 Mihomo：从配置文件到 Web 面板的一次完整记录

这样搜索和阅读体验都会更好。

2. 标签补全

很多文章其实应该有明确标签：

text
docker / nas / 组网 / 个人网站 / AI / windows / Linux

标签不是为了好看，而是为了以后能把文章串成专题。

比如未来可以整理出：

• 极空间折腾路线
• Docker 自部署路线
• 家庭网络与旁路由路线
• 本地 AI 工作站路线
• 个人网站部署路线

这些专题比单篇文章更像知识资产。

3. 正文结构重排

技术文章最怕两件事：

• 命令是对的，但读者不知道为什么这样做。
• 坑点很重要，但被埋在段落里。

所以 Codex 优化正文时，重点不是“润色得更文艺”，而是把文章整理成更容易照着操作的结构：

text
背景
环境
目标
操作步骤
关键配置
验证方法
常见问题
总结

代码块、端口号、路径、配置参数默认不乱改，只做格式和上下文说明。

---

五、头图应该怎么自动化？

这次试出来一个比较适合本站的方向：萌系二次元技术信息图。

不是单纯的漂亮角色图，而是：

• 白发蓝眼技术助手作为固定视觉锚点。
• 文章主题设备占主体，比如 NAS、Docker、路由器、服务器、终端。
• 画面里有分镜、箭头、中文标签。
• 每张图都能概括文章解决的问题。

这样头图不只是装饰，而是文章的视觉摘要。

我会给每篇文章生成类似这样的提示词结构：

text
文章标题：
核心场景：
必须出现的设备：
必须出现的中文标签：
要表达的故障或结果：
整体风格：二次元技术漫画信息图

批量生成时，就能保持统一风格，同时每篇又能贴合主题。

---

六、最重要的避坑：不要全自动发布

这套流程最危险的地方不是 API，而是“AI 看起来很自信”。

技术教程里有些内容不能随便改：

• 命令参数
• 配置文件缩进
• 镜像名
• 端口
• 路径
• IP 段
• Token 和密钥示例

所以我的安全策略是：

1. AI 可以创建草稿。
2. AI 可以上传头图。
3. AI 可以生成修改建议。
4. 正式发布前必须人工预览。
5. 批量更新旧文章前先处理 3-5 篇样板。

这样既能吃到自动化红利，又不至于把博客变成“看着漂亮但不能抄作业”的内容农场。

---

七、下一步计划

我准备先用最近几篇文章做试点：

• 补标签。
• 重写导语。
• 优化标题。
• 生成统一风格头图。
• 创建后台草稿预览。

等风格稳定后，再扩展到全站文章。

如果这套流程跑顺，博客以后就不只是“写完发布”的地方，而会变成一个持续进化的技术档案库。每一次折腾、每一段对话、每一个配置文件，都可以被 Codex 接住，再整理成一篇能被未来的自己搜到、看懂、继续使用的文章。

这大概就是我想要的博客自动化：不是让 AI 替我表达，而是让它帮我把折腾过的东西留下来。