通过这篇文章我们要解决：让 OpenClaw 不只是“帮忙写一段草稿”，而是真的能代写博客，并把文章自动推进到可发布状态。

读完你会拿到三样东西：

  1. 一条能实际落地的 Hexo 写作流：起草 / 改稿 → 本地预览 → SSH 检查 → 当次确认 → 推送发布
  2. 一套可以直接照着搭的 skill 结构、配置方式和脚本职责划分
  3. 一组在日常使用里更重要的经验：哪些步骤适合自动化，哪些步骤必须保留人工门禁

一、我说的“代写博客”，不是只给我一段正文

很多 AI 写作工具所谓的“代写”，本质上只是把正文吐出来，剩下的工作还得自己补：

  • 标题要不要重写
  • front-matter 是否完整
  • description 是否能概括文章
  • cover / top_img 有没有配上
  • 配图和代码块排版是否正常
  • 页面渲染出来到底能不能发

这也是我把博客自动化单独做成一个 skill 的原因。

我想要的不是“AI 帮我写一段文章”，而是：

我给出主题，OpenClaw 负责把文章往前推，直到它变成一篇结构完整、可预览、可检查、随时可以发布的 Hexo 文章。

这两者差别很大。

前者只是在节省打字时间；后者是在重构整条写作流水线。

如果你也在用 Hexo，这一步尤其有价值，因为 Hexo 文章从来不只是 Markdown 文本，还包括：

  • 文章元数据
  • 主题渲染结果
  • 页面配图
  • 本地预览状态
  • 最终 Git 发布动作

所以这套 skill 的目标很明确：让 OpenClaw 代写博客，但不让发布流程失控。

二、整条自动发布流到底长什么样

先看流程图：

OpenClaw × Hexo 发布流总览

这张图想表达的重点不是“步骤很多”，而是三件更关键的事：

  1. 写稿和发布是两段，不是一件事
  2. 预览看的不是 Markdown 原文，而是 Hexo 真正渲染后的页面
  3. 最终 push 必须保留当次确认，不能默认放行

也就是说，这条流程的设计重点不是“一键跑到底”，而是：

能自动推进的步骤尽量自动推进；会影响外部世界的步骤，必须留下明确门禁。

如果只用一句话概括，就是：

OpenClaw 负责提效，人负责拍板。

三、OpenClaw 在这条链路里到底自动做了什么

如果把它拆开看，OpenClaw 实际接管的是下面这些重复劳动。

1）起草正文与整理结构

给出主题后，OpenClaw 会先把文章主体搭起来，包括：

  • 标题
  • 开头的问题定义
  • 章节结构
  • 代码示例
  • 总结段

这里最重要的不是“写得快”，而是它能直接按技术文结构产出，而不是只给一坨散文式段落。

2）补齐 front-matter

Hexo 文章可发布与否，很大程度取决于 front-matter 是否齐全。

这一步里，OpenClaw 会把这些字段一起处理掉：

  • title
  • date / updated
  • categories
  • tags
  • description
  • cover
  • top_img
  • published

这样文章不是“写好了正文”，而是已经具备了进入博客仓库的完整形态。

3）把文章放到正确仓库和正确目录

文章不会丢在聊天窗口里，而是直接落到 Hexo 仓库：

1
~/project/blog/source/_posts/

这点很关键，因为真正可复用的流程，必须把“内容生成”和“仓库落盘”连起来。

4）启动本地预览

OpenClaw 不会只把 .md 文件塞给你看，而是会启动本地 Hexo 预览，让你直接看页面：

1
http://localhost:4000

这一步比“导出 Markdown 草稿”实用得多，因为最终影响发布质量的，往往不是正文有没有字，而是：

  • 标题层级对不对
  • 代码块高亮对不对
  • 图片位置是否合适
  • cover / top_img 是否跑偏
  • 主题排版是否正常

5）在 push 前先做 SSH 检查

很多发布流程的问题，不是文章没写好，而是最后一步才发现远端连不上。

所以我把 SSH 检查前置了。

这样一来，发布失败不会发生在“已经准备发出去”的最后时刻，而是在真正 push 之前就被拦住。

6）只有收到当次确认，才允许推送

这一步是整条自动化里最重要的边界。

本地改稿、补图、预览，这些都还是低风险动作；但 git push 是对外动作，一旦执行，可能直接触发：

  • 远端仓库更新
  • Pages / CI 自动部署
  • 线上文章内容变化
  • 半成品或错稿被公开

所以这套流程的原则一直很简单：

OpenClaw 可以把文章推进到“随时能发”，但不能默认替你决定“现在就发”。

四、仓库里哪些文件分别负责什么

如果你想自己搭一套，最值得先看的不是长篇说明，而是文件职责。

hexo-blog-publisher 结构与职责

对应到仓库，我现在把职责拆成四层。

SKILL.md：负责流程和门禁

这一层定义的是顺序，不是实现细节。

它会明确：

  • 什么时候生成或修改文章
  • 什么时候必须先预览
  • 什么时候才能进入 push
  • 为什么最终发布必须保留当次授权

它解决的是协作问题，而不是脚本执行问题。

scripts/start_preview.sh：负责把预览变成稳定动作

这一步不是单纯跑一句 hexo s，而是把预览前后最容易忘、最容易错的步骤都包起来：

  1. 检查 4000 端口是否被占用
  2. 清理旧进程
  3. 在博客目录执行 hexo clean && hexo g && hexo s
  4. 返回预览地址、进程号和日志路径

它解决的是：让本地预览变成一个稳定步骤，而不是一堆零散手工动作。

scripts/check_ssh.sh：负责把远端问题前置暴露

很多时候，文章已经改好了，最后才发现：

  • SSH key 不对
  • 远端地址写错
  • Git 配置缺失

check_ssh.sh 的价值就在这里：先检查，再发布。这样失败会发生在“还可以从容修”的阶段，而不是临门一脚的时候。

scripts/push_post.sh：负责收紧发布范围

真正 push 的脚本不能做成“顺手把整个仓库都提交掉”。

一个更稳的实现应该只处理目标文章，并对常见异常给出明确返回，比如：

  • NO_CHANGES
  • POST_NOT_FOUND
  • POST_OUTSIDE_REPO
  • PUSH_OK

这样它就不只是“能 push”，而是“能在受控范围内 push”。

如果你想直接看实现，我把这套 skill 开源在这里：

五、配置怎么写，才能真的让它跑起来

这套 skill 的配置并不复杂，最小示例如下：

1
2
3
4
5
6
7
8
BLOG_REPO_PATH=~/project/blog
POSTS_SUBDIR=source/_posts
PREVIEW_HOST=localhost
PREVIEW_PORT=4000
PREVIEW_LOG_DIR=~/tmp
REPO_SSH_URL=git@github.com:yourname/your-blog.git
REMOTE_NAME=origin
BRANCH=master

这些字段表面不多，但每一个都对应一段关键行为。

BLOG_REPO_PATH

1
BLOG_REPO_PATH=~/project/blog

它决定文章写到哪个仓库，也决定预览和发布脚本在哪里执行。

路径一旦写错，后面的自动化全都会跑偏。

POSTS_SUBDIR

1
POSTS_SUBDIR=source/_posts

它定义文章目录。最终文章会落到：

1
$BLOG_REPO_PATH/$POSTS_SUBDIR/<slug>.md

这一步其实是在告诉 OpenClaw：正文最终应该成为仓库里的哪个文件。

PREVIEW_HOST / PREVIEW_PORT

1
2
PREVIEW_HOST=localhost
PREVIEW_PORT=4000

我把默认值放在 localhost:4000，原因不是习惯问题，而是它最符合实际：

  • 本机预览最直接
  • 不会默认暴露到局域网或公网
  • 和 Hexo 默认使用方式一致

PREVIEW_LOG_DIR

1
PREVIEW_LOG_DIR=~/tmp

预览服务的日志和 pid 文件放到 ~/tmp，而不是博客仓库里。

原因很简单：这些属于运行时文件，不属于内容资产。把它们和正式仓库隔离，目录会干净很多。

REPO_SSH_URL / REMOTE_NAME / BRANCH

1
2
3
REPO_SSH_URL=git@github.com:yourname/your-blog.git
REMOTE_NAME=origin
BRANCH=master

这三个字段一起决定发布目标。

其中 REPO_SSH_URL 不只是写着好看，它会直接影响：

  • SSH 连通性检查
  • 仓库不存在时的 clone 提示
  • push 的最终目的地

所以这里最好按你自己的仓库实际情况写，尤其不要无脑照抄示例里的分支名。

六、最小可运行示例：怎样让它真的代写并自动推进发布

这一节不讲概念，只讲一条能跑通的最小链路。

第一步：直接把写作任务交给 OpenClaw

比如我会这样下达任务：

1
围绕“让 OpenClaw 代写博客并自动发布”写一篇文章，保存到 Hexo 的 source/_posts，标题具体一点，开头先讲解决什么问题和读完能得到什么。

如果是改现有文章，也可以直接说：

1
精修 hexo_blog_publisher_skill_guide.md，把主题收紧到“让 OpenClaw 代写博客并自动发布”，删掉版本说明和偏题内容，直接按现在的流程重写。

这一步里，OpenClaw 负责的是：

  • 改标题
  • 重搭结构
  • 重写正文
  • 更新摘要和标签
  • 把文章保存到正确路径

第二步：启动本地预览

然后执行：

1
bash skills/hexo-blog-publisher/scripts/start_preview.sh

正常情况下会拿到类似结果：

1
PREVIEW_OK|http://localhost:4000|<pid>|~/tmp/hexo-preview-4000.log

接着直接打开：

1
http://localhost:4000

去看最终页面，而不是只盯着 Markdown 原文。

本地预览运行结果示意

这张图最有用的地方在于，它把预览前最烦的三件小事都固化掉了：

  • 清理端口占用
  • 重新生成静态内容
  • 启动本地服务

第三步：预览时重点看什么

我通常不会只“扫一眼”，而是重点看这几个地方：

  • 标题是否具体
  • 开头是否把问题说清楚
  • 代码块和命令行排版是否正常
  • 图片是否真的在服务正文
  • 小标题层级是否顺
  • 总结段有没有把核心观点收住

如果这一步看着别扭，就继续让 OpenClaw 改，不急着发布。

第四步：通过 SSH 检查

页面确认没问题之后，再执行：

1
bash skills/hexo-blog-publisher/scripts/check_ssh.sh

只有当结果是：

1
SSH_OK|...

才说明发布链路本身也是通的。

第五步：收到明确授权后，再 push

最后一步才是：

1
bash skills/hexo-blog-publisher/scripts/push_post.sh hexo_blog_publisher_skill_guide.md "docs: refine auto-writing and auto-publish guide"

注意，这里真正重要的不是命令本身，而是它前面那三道门禁：

  1. 文章已经在本地页面里看过了
  2. SSH 检查已经通过了
  3. 当前这一次明确允许发布

这三条缺任何一条，都不应该继续。

七、为什么我坚持“先预览，再发布”

如果只是写草稿，直接看 Markdown 没什么问题。

但如果目标是“让 OpenClaw 代写博客并自动发布”，那就不能只停留在草稿视角。

真正会影响发布质量的，往往是这些页面级问题：

  • 主题下的字体层级是否合理
  • 代码高亮是否异常
  • 图片是否过大或过窄
  • cover 和 top_img 是否与正文一致
  • 摘要是否在列表页可读

这些问题，你不看最终页面，是看不出来的。

所以我现在把预览节点固定在 localhost:4000，本质上是在把检查对象从“文本文件”升级成“最终页面”。

这一步会多花几十秒，但能少掉很多发布后的返工。

八、为什么自动发布必须有门禁，而不是彻底放开

“自动发布”这四个字很容易让人误解成：

AI 写完以后，自动 commit、自动 push、自动上线。

听起来很爽，但在真实博客里，这其实是事故高发区。

原因也不复杂。

1）AI 能写，不代表它知道这篇文章现在就适合公开

文章是否该发，往往不仅是文本质量问题，还包括：

  • 观点有没有说透
  • 例子会不会引起误解
  • 配图是不是合适
  • 时机上是不是应该晚点发

这些判断，天然更适合人来做最后决定。

2）git push 是真正的外部动作

本地改稿失败，最多是本地再改。

但 push 一旦发生，外部世界就变了：

  • 远端仓库状态改变
  • 博客可能自动部署
  • 错误内容可能被读者看见

所以我的做法不是阻止自动化，而是明确边界：

自动化负责把文章推进到高完成度；发布动作必须经过当次确认。

3）有门禁的自动化，长期更稳

真正能长时间用下去的流程，不是最猛的那种，而是最稳的那种。

一条总要人工兜底、总会偶尔翻车的“全自动发布链”，往往用不了多久就会被停掉。

反过来，一条把风险节点收住的半自动链路，反而更容易成为日常工作流。

九、实践里最容易踩的坑

坑 1：把“代写”理解成“只写正文”

如果只让 AI 负责正文，剩下 front-matter、配图、预览、发布还是全手工，那你得到的只是一个高级输入法，不是一条自动发布流。

真正值得自动化的，是一整段重复动作，而不是单一写作动作。

坑 2：只看 Markdown，不看最终页面

技术文里很多问题都属于“渲染后才出现”：

  • 标题层级不顺
  • 代码块样式异常
  • 图片尺寸失衡
  • 摘要在列表页里太长

如果不走本地预览，这些问题很容易在发布后才暴露。

坑 3：把 push 当成本地动作

这点最危险。

本地修改可以反复试，但 git push 本质上是对外发布动作，必须和“本地编辑”区别开。

一旦这条边界模糊掉，自动化就会从提效工具变成事故放大器。

坑 4：脚本能跑，不等于流程能长期用

很多自动化脚本第一次跑通时看起来很漂亮，但只要多用几轮，问题就会冒出来：

  • 端口占用没人清
  • 预览日志到处乱放
  • SSH 失败只能到最后一步才看见
  • 推送范围收不住

所以一个真正能用的 skill，重点不是“秀一段脚本”，而是把这些低级重复问题提前处理掉。

十、总结：我想要的不是会写稿的 AI，而是会推进发布流程的助手

回到最开始，这篇文章真正想解决的，不是“怎样让 AI 多写几段字”，而是：

怎样让 OpenClaw 从接到主题开始，一路把文章推进到可发布状态，同时把真正危险的对外动作稳稳拦在门内。

如果把这套流程的核心价值压缩成五点，我会这样总结：

  1. 给出主题后，OpenClaw 可以直接起草并改完整篇文章
  2. front-matter、摘要、标签、配图可以一起纳入生成流程
  3. 文章会被写入 Hexo 仓库，而不是停留在聊天窗口
  4. 本地预览、SSH 检查、推送脚本把发布前步骤串成稳定流水线
  5. 最终 push 保留当次确认，让自动化提效而不越权

一句话概括：

不是让 OpenClaw “随便帮我写一篇”，而是让它真正代写博客，并把发布这件事自动推进到只差你最后点头。

如果你也在维护 Hexo 博客，我很建议先把这三件事固定下来：

  • 用 skill 固化写作到发布的顺序
  • 用 localhost:4000 检查最终页面
  • 用当次授权守住最后的对外动作

这样你得到的就不是一个“会写字的 AI”，而是一条真的能长期使用的博客自动发布流。
定下来：

  • 用 skill 固化写作到发布的顺序
  • 用 localhost:4000 检查最终页面
  • 用当次授权守住最后的对外动作

这样你得到的就不是一个“会写字的 AI”，而是一条真的能长期使用的博客自动发布流。