用 Codex 自动生成 Hexo 博客文章并一键部署

每天写技术博客最容易卡住的地方，往往不是不会写，而是流程太碎：选题、确认仓库格式、创建 Markdown、补 front matter、检查构建、再执行部署。每一步都不复杂，但合在一起就会变成一种阻力。

Codex CLI 适合处理这类重复性内容工作。它可以在当前仓库里阅读已有文章，理解 Hexo 的目录结构和 front matter 约定，然后按同样的风格新增文章。再配合一个小脚本，就可以把“生成今日文章”和“部署到 GitHub Pages”合成一个稳定入口。

一、适合自动化的部分

博客写作不能完全交给脚本，因为选题判断、经验取舍、事实准确性仍然需要人负责。但下面这些步骤非常适合自动化：

按日期生成唯一文件名。
沿用已有文章的 front matter 格式。
统一分类、标签、封面图。
根据主题生成初稿。
避免覆盖已有文章。
生成后执行 Hexo 构建检查。
构建通过后调用部署脚本。

这类自动化的重点不是让 AI “随便写一篇”，而是把仓库约束写清楚，让 Codex 在一个明确边界内工作。

二、仓库需要先具备的基础

以 Hexo 博客为例，最小可用结构通常是：

source/_posts/
package.json
deploy.sh
_config.yml

其中 source/_posts/ 存放文章，package.json 提供构建命令，deploy.sh 封装清理、生成和发布流程。

当前仓库里的部署脚本已经足够清晰：

1
2
3

npm run clean
npm run build
npm run deploy

所以新的自动化脚本不需要重新实现部署，只要在文章生成完成后调用现有 deploy.sh 即可。这样做的好处是职责清楚：Codex 负责内容和文件修改，部署脚本负责发布。

三、Codex 调用方式

Codex CLI 的非交互模式可以用 codex exec 执行一次性任务。脚本里推荐用 stdin 传入 prompt，这样长提示词更容易维护，也避免 shell 引号把内容弄乱。

核心调用形态如下：

codex exec \
  -C /path/to/blog \
  --sandbox workspace-write \
  --ask-for-approval never \
  "生成今天的 Hexo 博客文章"

几个参数的含义：

-C：指定 Codex 在哪个仓库工作。
--sandbox workspace-write：允许它修改当前工作区文件。
--ask-for-approval never：适合非交互脚本，失败就直接返回错误。
--search：需要实时信息时再打开，比如写当天 GitHub 热门项目观察。

如果文章不依赖实时数据，就不应该默认开启搜索。这样生成速度更稳定，也能减少不必要的外部依赖。

四、prompt 要写清楚什么

给 Codex 的提示词应该像任务说明，而不是一句“帮我写篇文章”。至少要包含：

今天的日期和目标文件名规则。
文章目录：source/_posts/。
不允许覆盖已有文件。
front matter 的字段和缩进风格。
文章主题、分类、标签、封面。
是否需要实时搜索。
完成后需要运行什么检查。

例如：

请在 source/_posts 中新增一篇今天的 Hexo 博客文章。
要求：
1. 文件名使用英文、数字和下划线。
2. front matter 必须包含 title、date、cover、categories、tags。
3. 不要修改无关文件。
4. 写完后运行 npm run build 验证。

这类约束越明确，自动化越稳定。Codex 的优势是能读懂上下文，但脚本不应该依赖“它猜得对”。

五、一键脚本的设计

一个实用脚本至少要做这些事：

切换到博客根目录。
检查 codex 命令是否存在。
解析用户传入的主题。
生成明确 prompt。
调用 codex exec。
根据参数决定是否部署。

为了避免误发，脚本最好支持 --no-deploy：

1	tools/codex-daily-post.sh --no-deploy "写一篇关于 Android 离线优先同步的文章"

检查没问题后再执行默认部署：

1	tools/codex-daily-post.sh "写一篇关于 Android 离线优先同步的文章"

如果选题需要实时数据，可以打开搜索：

1	tools/codex-daily-post.sh --search "观察今天 GitHub 上增长最快的 AI 工具"

六、自动化后的工作方式

有了脚本后，每天的流程可以简化成一句命令：

1	tools/codex-daily-post.sh

默认主题可以写成“根据仓库已有内容延续技术博客风格，生成今天的文章”。如果当天有明确方向，就把主题作为参数传进去。

这种方式比较适合持续写作：

没有选题时，让 Codex 根据已有文章延续系列。
有选题时，用一句话指定方向。
内容生成后自动构建。
构建通过再部署。

真正需要人工投入的地方，变成了检查文章观点、补充个人经验、确认事实和决定是否发布。

七、需要注意的边界

自动化写博客不能忽视几个问题：

涉及“今日”“最新”“排名”时，需要开启实时搜索，并在文中写明抓取时间。
涉及第三方项目、价格、版本、政策时，要优先查官方来源。
不要让脚本默认修改历史文章。
不要把部署逻辑散落在多个脚本里，统一复用 deploy.sh。
发布前最好保留一次构建检查。

最稳妥的方式是：生成文章和部署可以自动化，但最终是否发布，仍然由人通过命令开关控制。

八、总结

Codex CLI 不只适合写代码，也适合处理技术博客这种“结构明确、上下文固定、重复步骤多”的内容工作。

把文章生成和 Hexo 部署串起来之后，日常写作会从一串零散操作变成一个明确入口：

1	tools/codex-daily-post.sh "今天想写的主题"

这个脚本的价值不在于替代作者，而是把机械流程压缩掉，让精力回到选题、判断和表达上。

用 Codex 自动生成 Hexo 博客文章并一键部署

Zihuatanejo