太长不看：用 AI 助手加一个脚本，把「写完到发布」整段自动化：AI 按 frontmatter 规范写 Markdown，脚本自动传自建图床、换公网外链、调博客接口发布，再对文章页和每张图做 200 校验，超过 300KB 的图片自动转 WebP。适合被「登录后台传图点发布」这最后一步劝退的独立博主；文末有三个真实联调坑（防盗链虚惊、HEAD 全 404、代码块语言标注）的排查记录。

草稿箱里的「差一步」选手

说来惭愧，我博客的草稿箱比正文更新得勤。好多文章其实早写完了，一直卡在最后一步：登录后台、传封面、把本地图片一张张换成外链、点发布，再开一遍页面确认图没挂。一套下来十几分钟，写作热情就在这些机械动作里凉透了。

所以这次我干脆把整件事交给 AI 助手加一个脚本：我对它说「把某某主题写成博客发出去」，剩下的它全包。

现在发一篇文章长什么样

一句话。然后 AI 按我定好的规矩写 Markdown——标题、链接、摘要、标签都放在文件头的 frontmatter 里，配图丢进本地目录用相对路径引用，写完交给脚本。

脚本接手后：把本地图片传到自建的对象存储，顺手把正文里的本地路径换成公网链接；调博客的开放接口建文章、挂标签；frontmatter 里写了 publish: true 就直接发布；最后挨个去请求文章页和每一张图，全是 200 才算交差。中途任何一步翻车，它都会停下来把错误原样端给我看，而不是假装成功。

这篇文章就是这么发出来的——下面这张配图就躺在自家对象存储里，正文是被脚本推上线的：

发布流水线：AI 写文、自建图床、一条命令上线

还有个白赚的小福利：超过 300KB 的图片会自动转成 WebP。实测一张 1.4MB 的 PNG 压完只剩 167KB，肉眼基本看不出差别，流量和加载速度双丰收。

踩坑小剧场

这次联调排掉的坑，个个都挺有戏剧性。

虚惊一场的「防盗链」。 第一版跑完，图片校验全军覆没。我盯着满屏 403 脑补了半天：图床是不是开了防盗链把我拦了？一层层对比之后才发现，图片好好的、链路好好的，是我拼的地址少了一段路径，请求压根没落到对的地方。虚惊一场，但排查姿势记下了：先分层验证，别一上来就给自己加戏。

HEAD 的大乌龙。 做存活校验时我顺手用了 HEAD 请求，结果全部 404。查了才知道，这个博客框架对 HEAD 一律回 404，是框架行为，不是站点挂了。教训：校验永远用 GET，别省那一个响应体。

代码块语言的小告警。 之前有几篇文章把代码块的语言标注写成了文件名，前台的高亮组件每次渲染都默默报错。这回直接把「语言必须是合法的高亮名，或者干脆留空」写进了写作规范，让 AI 每次落笔前自查一遍。

后悔药也是标配

脚本对重复执行很友好：图片先查再传，传过就跳过；改文章走更新接口，不会一口气发出两篇。每篇文章传了哪些图、线上地址是什么，都记在本地一个小台账里，翻起来比登后台快。

真发错了也不慌：后台随时能撤，图床上的文件按目录整段清理，不留孤儿文件。

接下来

想让它更「自动」一点：定时从自己的运维笔记里挑题目，攒够一篇就写成草稿等我把关；图床的权限也准备再收一收。至于写作质量嘛——工具能保证的是「发得出去」，「值得读」还是得自己把关，这个偷不了懒。

如果你也被「最后一步」劝退过，真心建议把发布流程也当成一个可以折腾的系统。代码量不大，回报很持续：毕竟按下回车就能上线的快乐，谁用谁知道。