一篇文章写完，创作者的工作往往才做了一半。
接下来还要挑配图、裁公众号封面、拆成小红书卡片；碰上汇报，还得再做一版 PPT。每个平台尺寸不同，风格要统一，文字不能溢出，最后的文件最好还能继续改。换一篇文章，又要从头向 AI 解释一遍。
最近一批 Codex Skill 瞄准的，正是这段反复发生的“发布前收尾”。创作者看到的是一组配图、一套社媒卡片或一个可编辑 PPT；开发者看到的则是被保存下来的规则、模板、脚本、渲染工具和检查流程。
这篇真正想讨论的不是“又多了几个 AI 项目”，而是同一条内容生产线的两面：它替用户省掉了什么，开发者又为稳定交付搭了什么，以及它离真正的一键内容工厂还有多远。
用户要的不是“AI 会不会画”
假设我刚写完一篇长文，对 Codex 说：
按我平时的风格，做三张正文配图、一张公众号封面，再拆成一组小红书卡片。
从用户视角看，这句话并不复杂。我关心的只有几件事：不用每次重讲审美，几个渠道看起来像同一套作品，文字没有被裁掉，最后拿到的是可以发布或继续修改的文件。
但开发者听到的是另一串问题：
| 用户说的话 | 真正的验收标准 | 开发者要补上的工程合同 |
|---|---|---|
| “按我平时的风格” | 配色、留白、语气和构图稳定 | 参考图、模板、禁用项与版本化规则 |
| “做成一组卡片” | 尺寸正确、信息连续、顺序可读 | 平台规格、内容拆分、版式选择与批量渲染 |
| “不要有文字溢出” | 手机端预览没有裁切和遮挡 | DOM 检查、截图对比或人工确认门 |
| “给我一个 PPT” | 标题能改、图形能挪，不是一张大截图 | 对象级重建、重新渲染和文件打开验证 |
| “以后都这样做” | 新任务不必重发整套规则 | 可安装、可版本化、能再次读取的工作流 |
这正是普通聊天和 Skill 开始拉开差距的地方。好 prompt 当然也能调用工具，轻量 Skill 也可能只有一份说明；区别不在于名字，而在于有没有把复用、工具顺序、失败条件和交付格式一起保存下来。
开发者搭的不是一个更长的 prompt
从 Codex 的自定义机制 来看，Skill 更接近一个可复用工作流。一个典型目录可能长这样：
1 | social-card-skill/ |
SKILL.md 是入口：名称和描述帮助 Codex 判断什么时候该用它，正文规定先读什么、做什么、哪里必须停下来确认。细节资料不必全塞进上下文，可以在需要时再读；确定性的转换交给脚本；模板和样例则作为稳定起点。
这也意味着 Skill 本身不会凭空获得新能力。它不能凭一份说明变出 Playwright、图像模型或 PowerPoint 运行时，而是规定如何使用当前环境里已有的工具。环境没有装依赖、没有权限或没有对应模型，生产线照样会停。
所以 Skill 也不是“记住上次对话”。更准确的说法是：它把规则写进文件并版本化，让下一次新任务可以重新读取，而不用用户再手动粘贴整套要求。
第一条生产线：把文章变成发布包
内容创作者最容易感知的，是从文章到配图和社媒卡片这一段。
ian-xiaohei-illustrations 的目标，是把中文文章里的判断、流程、结构和隐喻，转成统一的小黑 IP、16:9 白底手绘正文图。对用户来说，价值不是“偶尔生成一张好看的图”，而是下一篇文章还能沿用相同的留白、线条和批注方式。
开发者视角则完全不同。要稳定复用这种风格，需要先从文章里挑出值得可视化的句子，再约束构图、颜色、文字量和禁止项；生成后还要检查画面是不是在解释观点，而不是只做装饰。所谓“风格一致”，实际是参考素材、规则和人工判断共同作用的结果，不是模型天然记住了审美。
guizang-social-card-skill 把链路又往前推了一步。它面向小红书图文、公众号封面和 Live Photo，公开规则里包括 3 种画板尺寸、28 个版式、10 套主题，以及从单文件 HTML 到 Playwright 截图的流程。
用户看到的是“同一篇文章输出不同平台的发布包”。开发者看到的却是：识别发布意图，读取平台尺寸，选择模板和图片来源，生成 HTML，调用浏览器渲染 PNG，再决定是否运行 9 条 DOM 版式校验。这里还有一个很重要的真实边界：仓库默认先交付 PNG，再询问用户要不要自动校验，并不是每次都会默默跑完检查。
模板在这里没有被 Skill 淘汰。模板负责提供稳定起点，Skill 负责决定什么时候选哪一套、如何填充内容、用什么工具渲染、失败以后怎样返工。对用户来说，这些细节最好都看不见；对开发者来说，它们才是“以后还能再做一次”的原因。
第二条生产线：从只能看的截图到能改的 PPT
PPT 是更能暴露“交付合同”的案例。
用户说“帮我复刻这页”，通常不是想得到一张图片塞进 .pptx，而是希望标题真的能改、卡片真的能挪、图表还能换数据。只有截图、扫描 PDF 或图片版旧 PPT 时，这个需求尤其真实。
image-to-editable-ppt-skill 就围绕这件事展开。它会尽量把可读文字重建为原生文本框，把简单几何重建为形状，复杂视觉则保留成独立图片资产。对用户来说，结果从“只能看”变成“还能接着做”；对开发者来说，“可编辑”必须被拆成能验证的对象清单、页面状态、渲染对照和最终文件检查。
这条生产线远没有标题听起来轻松。项目 README 明确提醒：单页可能超过 10 分钟，10 页任务可能耗尽 5 小时额度，还会消耗 OCR、图片 API、多智能体和大量 token。它也不承诺 100% 还原。把这些成本写出来，比一句“AI 自动转 PPT”更接近用户真正会遇到的体验。
CyberPPT 处理的是另一类需求：高密度、咨询风、可编辑的正式汇报。它把证据底稿、故事线、风格确认、逐页视觉蓝图、可编辑层和多轮质量检查接进流程。仓库自己的建议也很诚实：让 AI 完成约 90%，剩下 10% 由人收尾；复杂曲线和图标容易有偏差，追求 100% 会显著增加 token 与调试成本。
“生成了”不等于“交付了”。真正的终点是能打开、能修改、符合尺寸，并且知道哪些部分仍需要人工复核。
第三类 Skill 其实不太像工厂
并不是带着 SKILL.md 的项目都会形成完整生产线。
Awesome-Journal-Skills 更像期刊与会议写作规则的索引。它的深度包可以覆盖选题、识别策略、表图规范、投稿和审稿回复；另一些广度合集主要提供 venue fit、写作风格和路由信息。
截至 2026 年 7 月 10 日，项目 README 报告了 289 个 pack、4030 个 SKILL.md。这个规模说明 Agent Skill 生态增长很快，却不代表 4030 份内容都经过了学术事实审查。它当前也更偏 Claude Code marketplace 和通用 Agent Skill，并非 Codex 专属项目。
对研究者来说，这类 Skill 可以少翻几遍投稿规范；对开发者来说，它的核心更接近知识路由和上下文选择，而不是浏览器渲染、文件验证与失败恢复。引用是否真实、方法是否适用、数据能否交给外部模型，仍然需要研究者自己负责。
把它和前两个案例放在一起，反而能看清一个光谱：有的 Skill 主要保存审美与规则，有的连接模板、渲染器和校验器，还有的已经带着状态文件与失败恢复。把它们统称为“内容工厂”很方便，但工程成熟度并不一样。
它不是一键魔法
从用户视角看，好的 Skill 应该让操作越来越短；从开发者视角看，稳定性来自更多明确约束，而不是更强烈的承诺。
真正使用时，至少还有这些成本：
- 安装与环境：浏览器、字体、Office 运行时、Python 或 Node 依赖缺一项，都可能卡住流程。
- 时间与费用：图片生成、OCR、多智能体和长文档重建会消耗额度，也可能比手工改一页更慢。
- 随机性：同一套风格规则能提高一致性，不能保证每次构图都合格。
- 人工复核：事实、引用、版权、错字、复杂图表和最终审美不能只靠“脚本通过”。
- 隐私与权限：论文数据、客户材料和未公开方案进入哪些模型、脚本和外部服务，需要在运行前说清楚。
一条生产线真正成熟的标志，不是它永远不失败，而是失败能被看见：知道停在哪一步，保留了哪些中间文件，修正后能否续跑，错误产物会不会被误当成最终交付。
什么最值得做成自己的 Skill
我现在不会再用“公共知识还是私人偏好”来区分价值。代码工作流同样值得 Skill 化：项目入口、迁移命令、测试、回滚和发布验收，和内容工作流里的尺寸、审美、渲染与校验，本质上都是稳定约束。
更实用的判断方法是“三次法”：同一类任务连续做三次，如果每次都在重复解释相同规则、整理相同文件、执行相同步骤，就值得考虑封装。
动手前，我会先回答六个问题：
- 什么样的请求应该触发它，什么请求不该触发？
- 用户需要提供哪些输入，缺少什么就必须停下来问？
- 哪些步骤交给模型判断，哪些更适合确定性脚本？
- 中间文件和状态写在哪里，失败后怎样继续？
- 什么算完成，哪些检查能自动做，哪些必须让人确认？
- 用户最终拿到什么：一张预览图，还是可继续编辑和发布的文件？
这六个问题答不清，Skill 很可能只是一个收藏起来的长 prompt。答清以后，它才开始像工作流。
所以，Codex Skill 被“玩成内容工厂”真正有意思的地方，不是 AI 突然更会写、更会画了。创作者想要的是少说几遍、少做几轮机械整理，最后拿到能用的东西；开发者要做的是让这份“能用”变成可重复、可观察、可验证的交付合同。
两种视角合在一起，内容工厂才不只是一个好听的比喻。
评论