FFFCX Blog Publisher skill：把发博客这件事做成一套可复用的工作流

为什么要做这个 skill

博主作为一个非专业人士，在并不是很掌握各种编程技能（belike markdown的语法，html的开发）的情况下，想要更高效的更新我的blog，用好CodeX成为了我的突破口。

最开始我想解决的不是“让 Codex 帮我写一篇文章”这么单一的问题，而是更长期一点：如果之后我经常要写博客、整理课程复习资料、发布 HTML 小作品、做项目展示，那么每次都从零说明一遍规则，会很消耗注意力。

更麻烦的是，Blog并不是一个空白项目。它已经有 Hexo 的目录结构、Redefine 的主题配置、自己的图片路径、评论系统、文章风格和一些我不希望被随手碰到的正式文件。一个能用的写作助手，不应该只会生成 Markdown，它还应该知道什么时候先问、什么时候只读、什么时候该停下来等我确认。

所以 FFFCX Blog Publisher skill的目标就变成了：把“我如何和 Codex 一起发博客”这件事，沉淀成一套明确的工作流。

总的来说，它像是一个小型编辑部规范：知道站点事实，知道写作风格，知道哪些目录是正式发布区，知道 HTML 作品要先考虑手机端，也知道不能在没有授权的时候直接改 Hexo 项目。

现在它能做什么

FFFCX Blog Publisher 现在覆盖的是一整套博客生产流程，而不只是某一种文章模板。

它会先区分内容类型。比如普通文章、项目展示、课程/复习资料、网站资源共享、个人随笔、摄影作品集、读书笔记、生活记录，这些内容的结构不应该长得一模一样。项目展示要讲动机、功能、技术与设计；课程复习要强调知识地图、公式、例题和易错点；生活记录则需要更克制地选择细节，而不是把时间线原样倒出来。

它也知道这个站点的 Hexo + Redefine 约定：文章进入 source/_posts，图片优先放在 source/images 并用 /images/... 引用，正文标题从 ## 开始，文章标题只放在 Front Matter 里，不在正文重复写一个 # Title。如果文章里有公式，它会记得加上：

1	mathjax: true

这件事看起来很小，但对长期写作很重要。真正节省精力的往往不是一个巨大自动化，而是这些细节不再反复漏掉。

HTML 相关的规则也被放进了 skill。以后如果要做网页作品，它会先确认形态：是独立网页作品、博客内嵌内容块，还是一篇介绍文章配一个独立页面。它也会默认把手机端当成重要的访问源，而不是最后用一个媒体查询仓促补救。

这部分还会结合 web-design-engineer 的流程：先确认叙事角色、视觉温度、内容容量、设计系统，再做 v0；如果是更完整的网页，还要检查交互状态、文字溢出、移动端布局和整体视觉质量。

搭建经过

这个 skill 不是一开始就写出来的。它更像是从一段协作里自然长出来的。

第一步是划清边界。

我一开始提出过复制 Hexo 项目到 codex workplace 的方案，但这很快被修正了。真正需要的不是一个项目副本，而是一个隔离的工作区：用来放草稿、模板、规范和实验；正式 Hexo 文件保持不动，除非我明确授权。

这个边界后来变成了整个 workflow 的核心规则：

每次开始前先给方案。
codex workplace 之外的文件都视作受保护区域。
草稿先写在工作区里。
只有经过审阅和授权，才写入 source/_posts 或其他正式目录。
不复制 Hexo 项目，也不把工作台变成第二个项目。

第二步是只读学习站点。

Codex 先阅读了 Hexo 和 Redefine 的官方文档，再只读检查我的站点配置和目录结构。这里确认了几个关键事实：博客使用 Redefine，站点身份是 FFFCX's Blog，主题主色是 #A31F34，文章目录是 source/_posts，post_asset_folder 当前是关闭的，独立 HTML 项目现有目录是 source/poject/<slug>/。

这里还有一个小小但实际的判断：source/poject 很像拼写错误，但因为它已经承载了现有内容，所以 skill 里选择“保留现状”，而不是擅自迁移路径。这个选择很符合我希望它拥有的性格：少一点自作聪明，多一点对既有系统的尊重。

第三步是把规则写成工作台文档。

最早的一版 codex workplace 里有六个文件：workflow、Markdown style guide、HTML style guide、普通文章模板、项目模板和发布检查清单。它们先解决底线问题：Front Matter 怎么写，哪些目录可以碰，什么时候需要 mathjax: true，图片路径怎么处理。

后来我继续补充了几个重要要求：

内容类型里要加入“课程/复习资料”。
写作气质固定为“聪慧的，温暖但不矫情、清楚但不教条、个人但不流水账”。
HTML 更偏向独立网页作品，但保留博客内漂亮内容块的能力。
做 HTML 时结合 web-design-engineer 的设计流程。
手机端必须提前考虑，不能最后再补。

这些要求让它不再只是“Hexo 发布助手”，而更像是为这个博客定制的内容系统。

第四步是打包成正式 skill。

一开始的 skill 草稿偏“轻量入口 + references”，优点是触发时不占太多上下文，但问题也明显：如果 references 只是摘要，以后单独触发时可能丢失细节。于是我们把方向改成了完整规范版。

最终结构大致是这样：

fffcx-blog-publisher/
├── SKILL.md
├── agents/
│   └── openai.yaml
└── references/
    ├── workflow.md
    ├── hexo-redefine-reference.md
    ├── writing-style.md
    ├── markdown-patterns.md
    ├── content-types.md
    ├── html-web-artifact.md
    ├── templates.md
    ├── design-critique.md
    └── publish-checklist.md

SKILL.md 负责触发、总原则和工作流；references/ 负责承载完整细则。这样它既能被 Codex 自动识别，又不会把所有规则挤在一个入口文件里。

最后安装到正式 skill 目录时，还遇到一个 Windows 小问题：官方校验脚本第一次因为缺少 yaml 模块跑不起来；安装 PyYAML 后，又遇到了默认 gbk 解码读中文失败。改用 UTF-8 模式运行后，校验通过：

1	Skill is valid!

这个过程反而让我更安心。一个工具只有经过这些边缘问题，才开始像真的可以长期使用。

这次触发后的实际效果

这篇文章本身就是一次小测试。

我在请求里显式调用了 fffcx-blog-publisher 和 web-design-engineer。实际触发后，Codex 先读取了两个 skill 的说明，再读取博客发布 skill 里与本任务相关的 references，包括 workflow、Hexo/Redefine 约定、写作风格、Markdown 规范、内容类型、模板和发布检查清单。

这带来了几个很明显的效果。

首先，它没有直接开始写正式文章，也没有碰 source/_posts。它先给出计划，说明内容类型、目标路径、Front Matter、是否需要 MathJax，以及会先写到 codex workplace。

其次，它会主动尊重受保护目录。即使当前 workspace 对 source/_posts 有写权限，它也不会把“技术上能写”误认为“流程上应该写”。

第三，它能利用之前那条 Codex 线程作为素材，回看从只读学习、工作台建立、规范迭代、skill 打包、安装校验到本次实际触发的全过程。换句话说，这篇文章不是凭空编出来的，而是从真实协作记录里整理出来的复盘。

最后，文章的写作方向也被约束住了：不是宣传稿，不是工具说明书，也不是完整流水账，而是一篇带有项目展示性质的博客文章。它需要解释为什么做、怎么做、现在有什么效果，以及哪些设计选择值得保留。

我最喜欢的几个设计选择

我最喜欢的第一个选择，是把审批流写进 skill。

很多自动化的危险不在于它不够强，而在于它太快。对博客这种带有个人表达和长期积累意味的系统来说，“先给方案，等我确认”不是效率损失，而是质量控制。它让我保留最后的判断权，也让 Codex 的动作更可预期。

第二个选择，是把 codex workplace 定义成草稿区，而不是项目副本。

这让整个系统轻了很多。工作台只承载协作过程：草稿、规范、模板、检查清单、skill 草稿。正式 Hexo 项目仍然是唯一的发布来源，不会因为复制、同步和临时实验变得混乱。

第三个选择，是把写作气质明确下来。

GPT 5.5 给出的“聪慧的，温暖但不矫情、清楚但不教条、个人但不流水账”这句话很有用。它不是规定每一句话怎么写，而是给了一个判断坐标：什么时候太硬，什么时候太泛，什么时候个人细节变成了无效记录，什么时候又太像冷冰冰的文档。

第四个选择，是把 HTML 作品也纳入博客工作流。

我的博客不只会有 Markdown。在这几天的ai使用的过程中，我发现很多时候，一个项目、一份复习资料、一个交互式整理页面，最好的形态可能就是 HTML。把这一点提前写进 skill，就避免了之后每次重新解释“我要的不是普通文章，而是一个可看的网页作品”。

它还可以继续长大

现在的 FFFCX Blog Publisher 已经能稳定覆盖写作、草稿、审阅和发布前检查。但它还可以继续长大。

下一步比较自然的是给它增加更强的发布前检查，比如自动检查 Front Matter、链接、图片路径、是否误用 # Title、是否有公式但缺少 mathjax: true。这类检查不需要很花哨，但会非常实用。

另一个方向是沉淀更多“站点专属组件”。比如资料卡片、项目入口、课程复习路线、照片组说明、阅读笔记摘要块。Redefine 已经提供了 callout、button、grid、tabs 等模块，skill 可以逐渐学会在合适的时候使用它们，而不是每次都从空白 Markdown 开始。

如果以后独立 HTML 作品变多，也可以为 source/poject/<slug>/ 建立更明确的命名、资源、预览和移动端检查流程。这里暂时保留 poject 的现有拼写，是为了兼容已有路径；如果未来要迁移，也应该作为一次单独的站点维护来做。

小结

FFFCX Blog Publisher 对我来说最有价值的地方，不是它能让 Codex “更会写”，成为我的blog写作助手，同时也让 Codex 更知道边界。

它知道这不是一个随便生成内容的地方，而是一个已经有风格、有历史、有目录秩序的个人博客。它知道草稿和发布之间需要审阅，知道 HTML 和 Markdown 是不同的创作形态，知道有些文件可以读但不能随便改，也知道写作气质的作用。

把这些东西做成 skill 之后，博客写作的起点就不再是“我重新解释一遍规则”，而是“我们已经有一套共同记住的工作方式”。

长期的创作里，最有价值的的往往就是这种可复用的默契。

Welcome to FFFCX's Blog