很多 AI 对话当时很有用，结束后却很快消散。真正值得保存的不是聊天记录，而是其中被验证过的方法、规则和工具。

这次我做的事情，就是把“让 AI 自动写 Hexo 博客并发布”这个想法，整理成一个可以长期复用的 Codex Skill：当前专注 Hexo，未来可以扩展到 Hugo、知乎、飞书、语雀等更多发布目标。

从一次需求到一个 Skill

最初的需求很直接：希望 AI 能把当前会话内容浓缩成一篇有价值的博客，并通过 Hexo 自动创建、生成和部署。

但真正做起来后，需求很快变得更清晰：它不应该只服务于“当前会话”。很多值得发布的内容，可能只是一个突然冒出的想法、一段需求描述、一份笔记、一个代码变更，甚至是一句还没展开的问题。

所以这个 Skill 最终被设计成四种输入模式：

模式 输入来源 输出目标
Conversation mode 当前 Codex/GPT 会话 蒸馏成读者可读的文章
Idea mode 一个想法、标题、问题或方向 扩展成完整博客
Requirement mode 需求、功能设想、工作流 整理成文档或文章
Source mode 文件、笔记、草稿、截图、代码变更 综合成结构化内容

这一步很关键。一个自动写博客的 Skill，如果只能“总结会话”，就很容易变成聊天记录整理器；如果能从任意输入主动思考，就更像一个发布助理。

核心原则：提炼，而不是搬运

AI 写博客最容易犯的错误，是把上下文完整复述一遍。这样的内容对参与者有意义，但对读者通常没有价值。

这个 Skill 的写作规则是：

  1. 先判断输入类型，而不是马上写正文。
  2. 提炼长期价值：方法、决策、坑点、流程、示例、可复用规则。
  3. 删除对话噪音：确认、闲聊、工具输出、重复尝试和只在当时有意义的细节。
  4. 主动补全结构：读者是谁、文章承诺是什么、标题怎么取、分类和标签怎么设计。
  5. 最后才进入 Hexo 创建、写入、生成和部署。

这让 Skill 的目标从“帮我写一篇”变成“帮我把输入变成值得发布的内容”。

为什么仓库叫 blog-publisher-skill

一开始它很自然地叫 hexo-blog-publisher-skill。这个名字清楚，但也有局限：它会让人以为这个项目永远只服务 Hexo。

后来我把 GitHub 仓库名调整为：

blog-publisher-skill

但内部 Skill 调用名仍然保持：

$hexo-blog-publisher

这样做有一个明确边界：

  • 仓库名保持通用，为未来扩展留下空间。
  • 当前实现仍然 Hexo-first，不假装支持尚未实现的平台。
  • 调用名继续保留 Hexo 语义，避免误导使用者。

换句话说，项目愿景可以更大，但当前能力必须诚实。

Hexo-first 的发布链路

当前版本围绕 Hexo 做了完整约束：

环节 规则
创建文章 优先使用 hexo new post
写入内容 保留 Hexo front matter 和主题约定
分类标签 分类少而稳定，标签具体而可检索
图片 优先使用已有素材或真实截图，不强行装饰
校验 部署前运行 hexo clean && hexo generate
部署 只有用户明确要求发布时才执行 hexo deploy

这套规则看起来保守，但它解决的是自动化发布里最重要的问题：不要把不确定的内容推到线上。

安装方式也要面向 AI Agent

传统 README 往往只写：

git clone ...

这当然能用，但如果这个项目本身就是给 AI agent 使用的，那么安装文档也应该面向 agent。

因此 README 里加入了更符合实际使用方式的安装提示：

请从 https://github.com/Litreily/blog-publisher-skill.git 安装这个 Codex skill。
把它 clone 或复制到我的 Codex skills 目录，并命名为 hexo-blog-publisher，
这样我可以用 $hexo-blog-publisher 调用。
安装后请确认 SKILL.md 和 agents/openai.yaml 都存在。

这个变化很小，但方向很重要：文档不只是给人看的，也可以直接成为给 AI 执行的任务说明。

Push 也需要边界

在这个过程中还有一个细节：自动化并不意味着所有动作都应该自动完成。

一开始可以设想为“修改、提交、直接 push”。但更稳的流程是：

  1. AI 根据需求修改。
  2. 本地验证。
  3. 创建 commit。
  4. 停在本地。
  5. 只有用户明确说“push”或“推送”时，才推到远程。

这条规则同样适用于博客发布。生成和部署可以自动化，但关键外部动作最好保留明确确认。

这次沉淀出的东西

最终得到的不只是一篇文章，而是一套可以复用的工作方式：

  • 把模糊需求先变成 Skill 的输入模式。
  • 把写作标准写进 SKILL.md，而不是每次重新提示。
  • 把详细写作规则放进 references/article-guidelines.md，按需加载。
  • 把 Hexo 命令、图片路径、部署保护写进 references/hexo-operations.md。
  • README 同时服务人和 AI agent。
  • 当前能力保持 Hexo-only，未来扩展方向保持清晰但不越界。

这也是我觉得 AI 协作最值得沉淀的地方：不是让 AI 替你完成一次任务，而是把一次任务中形成的判断力，变成下一次可以直接调用的能力。

小结

blog-publisher-skill 当前只是一个 Hexo-first 的 Codex Skill，但它背后的思路更通用：让 AI 不只是回答问题，而是把想法、需求、笔记和会话转化成可发布、可维护、可演进的内容资产。

当一个会话结束时，真正有价值的不是“我们聊了什么”，而是“哪些东西值得被留下”。这个 Skill 做的，就是把这一步变成一个稳定流程。