我最近逐渐把 Codex 当成一个“工作流编排器”来用，而不只是一个代码助手。

这篇文章记录一套完整链路：先通过 Codex 创建自动化流程，再调用“东方美人导演 Skill”生成图像提示词与示例图，最后交给 blog-publisher-skill 自动整理成 Hexo 博客、生成静态页面、压缩图片并部署上线。

Codex 自动化内容发布工作流

这套流程解决什么问题

单独看，每个环节都不复杂：

  • 想一个选题。
  • 写一组 AI 绘图提示词。
  • 生成几张图。
  • 整理成博客。
  • 执行 Hexo 发布。

真正麻烦的是这些动作之间的衔接。图像提示词要有风格一致性，图片要能被文章解释，博客要符合 Hexo 规范，文件名和 subtitle 要匹配站点规则，发布前还要生成、压缩、部署、提交源文件。

我希望 Codex 做的不是“帮我写一段文字”，而是把这一整套流程变成可重复执行的自动化管线。

工作流总览

这套自动化流程可以拆成五步：

步骤 角色 产物
1 用户 提出主题、方向或发布目标
2 Codex 拆解任务，选择合适 skill
3 东方美人导演 Skill 生成图像提示词、风格设定、负面提示词
4 GPT-Image 2 根据提示词生成示例图或流程图
5 Blog Publisher Skill 写文章、插图、Hexo 生成、压缩、部署、提交源文件

这不是单个 prompt 能解决的问题，而是让不同 skill 各自负责自己最擅长的部分。

第一步：让 Codex 成为编排器

Codex 的核心价值不只是生成代码，而是能读懂当前上下文、读取本地文件、执行命令、修改仓库，并根据任务选择不同能力。

在这套流程里，Codex 做三件事：

  1. 判断用户到底要的是图片、文章、流程，还是发布结果。
  2. 调用合适的 skill，并把前一个环节的产物交给下一个环节。
  3. 在真正发布前做验证，例如检查 Hexo 生成是否成功、图片路径是否正确、Git 状态是否干净。

这让“创作”不再只是一次模型输出，而是一个可检查、可回滚、可复用的工程流程。

第二步：用东方美人导演 Skill 生成图像素材

“东方美人导演 Skill”的价值在于，它不会只给出“美女、汉服、好看背景”这种泛泛关键词，而是会先做导演级设定：角色身份、视觉钩子、服装系统、场景、色彩、构图、光线和负面提示词。

例如，一个可用于系列图像的提示词方向可以这样设计：

主题：东方美人图像创作流程示例
角色：青瓷月下的东方美人，成人女性，清冷、温婉、有故事感
场景：月色下的茶室与青瓷器物，窗外竹影，室内有微弱烛光
视觉钩子：月光落在青瓷茶盏上，形成一圈淡淡的水纹光晕
色彩：青瓷绿、月白、淡金、墨色阴影
构图：三分之二半身像，脸部优先，手部轻扶茶盏
负面：廉价影楼风、塑料皮肤、过度磨皮、手指错误、现代杂物、文字水印

这类提示词的关键不是堆砌形容词，而是把“画面为什么成立”讲清楚。

下面这张图可以作为这类流程中的东方美人示例素材：

青瓷月下的东方美人示例

第三步：用 GPT-Image 2 生成流程图

博客不只有审美图，也需要解释系统如何工作。对于这类文章，我更适合用 GPT-Image 2 生成一张清晰的流程图，而不是再放一张装饰性封面。

这次流程图的目标很明确：

  • 16:9 横图，适合技术博客正文展示。
  • 中文节点清晰可读。
  • 展示从“用户想法”到“Codex 编排”，再到“图像 Skill”“GPT-Image 2”“Blog Publisher Skill”的完整链路。
  • 风格要像文档插图，而不是海报。

这种图的作用是降低读者理解成本。读者先看图，就能知道后面文章在讲一条自动化管线，而不是单点技巧。

第四步：交给 Blog Publisher Skill 写作与发布

当素材准备好后，blog-publisher-skill 接手后半段工作。

它现在的规则包括：

  1. 先检查 Hexo 项目已有文章的命名习惯。
  2. 中文标题也使用英文 slug 文件名，保证 URL 稳定。
  3. 自动生成 Hexo front matter，包括 title、subtitle、tags、date、categories 和 description。
  4. 将图片放入合适的 source/assets/ 目录。
  5. 运行 hexo clean && hexo generate。
  6. 如果根目录存在 compress-images.mjs，则在生成后执行 node compress-images.mjs 压缩图片。
  7. 压缩成功后执行 hexo deploy。
  8. 发布成功后，只提交本次文章相关的 Markdown 和图片资源，再 push 到源仓库。

这套规则解决了两个很实际的问题：站点能成功发布，源文件也不会忘记提交。

关键细节：不要让自动化变成失控

自动化越长，越需要边界。

这里有几个我觉得必须写进 skill 的规则：

  • 不要直接 git add .，只添加本次文章相关的 Markdown 和图片。
  • compress-images.mjs 只有存在时才执行。
  • 图片压缩失败时停止部署，而不是继续 hexo deploy。
  • hexo deploy 成功和源仓库 push 成功要分开报告。
  • 如果已有文章使用英文文件名，就不要发布中文文件名。

这些规则看起来琐碎，但它们决定了这个流程能不能长期稳定运行。

这套流程的价值

对我来说，这套工作流的价值不在于“AI 帮我写了一篇博客”，而在于它把内容生产拆成了几个明确角色：

角色 负责内容
用户 提出方向、判断品味、确认结果
Codex 编排任务、读写文件、执行命令
东方美人导演 Skill 提供图像审美系统和提示词结构
GPT-Image 2 生成视觉素材
Blog Publisher Skill 完成文章写作、Hexo 发布和源文件同步

每个角色都相对清晰，流程就不容易混乱。

后续可以继续扩展什么

现在这套流程仍然是 Hexo-first，但它已经有了扩展空间：

  • 将发布目标扩展到 Hugo。
  • 将文章同步到知乎、飞书、语雀等平台。
  • 给不同平台维护不同 front matter 或格式转换规则。
  • 在图像生成后自动生成 alt text、封面图、缩略图。
  • 为每篇文章自动记录使用过的 prompt、模型和素材来源。

真正重要的是：不要把这些能力全部塞进一个大 prompt，而是把它们拆成可维护的 skill 和步骤。

小结

这套流程把一次内容创作变成了一个完整系统：Codex 负责调度，东方美人导演 Skill 负责图像审美，GPT-Image 2 负责视觉生成，Blog Publisher Skill 负责文章组织与 Hexo 发布。

当这些环节串起来后，AI 不只是“回答问题”，而是在帮我把想法、图像和文字沉淀成可以长期访问的博客内容。

这才是我真正想要的自动化：不是替代创作，而是让创作结果稳定留下来。