Codex 最新玩法：从写代码到多媒体工作台，Skills 正在变成真正的生产力杠杆

最近 Codex 最值得关注的变化，不是它又能多写几行代码，而是它正在从 coding agent 变成一个多媒体工作台。

这个变化很重要。

过去我们使用 AI Coding 工具，核心动作通常是：描述需求，生成代码，运行测试，修 bug，提交 PR。它的工作对象主要是代码仓库，输出物也主要是代码。

但现在 Codex 的能力边界明显变宽了。它可以看网页、操作浏览器、生成图片、处理 PDF/表格/文档/幻灯片、读取截图、控制桌面 App、调用插件、通过 Sites 发布网站，还可以把一套复杂流程沉淀成可复用的 Skills。

我的判断是：

未来 Codex 的核心竞争力，不只是“模型会不会写代码”，而是“它能不能把混乱的多媒体材料、图形界面和真实工作流，变成可验证、可复用、可交付的生产系统”。

其中最关键的杠杆，就是 Skills。

这张图概括了我理解中的 Codex 多媒体工作流：

Codex 的多媒体能力真正有价值的地方，是把分散步骤沉淀成可复用的 Skills。

教程类内容也不应该先想着最终成片，而应该先拆结构：

教程脚本 Skill 的关键价值，是把录屏前的目标、分镜、旁白、字幕和验收点先固定下来。

多媒体内容进入文章前，还需要一张发布检查清单：

媒体内容进入文章前，需要检查素材路径、说明文字、响应式布局和发布边界。

Codex 的新形态：不是 IDE 插件，而是工作台

如果只把 Codex 理解成 IDE 里的代码补全工具，会低估它正在发生的变化。

现在 Codex 至少有几类很关键的能力：

• Appshots：把当前 Mac 前台窗口作为视觉上下文发给 Codex，比如设计稿、网页、错误弹窗、图片编辑器、资料页面。
• In-app Browser：在 Codex 线程里打开网页或本地开发页面，直接预览、标注、验证视觉效果。
• Browser Use / Developer Mode：让 Codex 操作浏览器、点击页面、检查 DOM、看 console、看 network、做性能诊断。
• Computer Use：让 Codex 操作 macOS 或 Windows 上的图形界面 App，比如桌面应用、模拟器、浏览器、设计工具。
• Image Generation：直接在 Codex 线程中生成或编辑图片，用于封面图、插画、UI 占位图、sprite sheet、banner、背景图。
• Documents / PDF / Spreadsheets / Presentations：处理非代码产物，让 Codex 能做报告、表格、演示文稿和文档整理。
• Sites：把提示词或已有项目变成可部署的网站、Web App 或小游戏，还可以保存版本和发布生产 URL。
• Skills / Plugins：把上面这些能力组织成可复用流程，而不是每次重新写 prompt。

这意味着 Codex 的位置变了。

它不再只是“帮我改这个函数”，而是可以变成一个把内容生产、视觉验证、素材生成、网页开发、文档交付和发布流程串起来的工作台。

这也是我觉得多媒体领域会率先出现明显突破的原因：多媒体工作本来就很碎，涉及图片、截图、录屏素材、文案、页面、文件格式、视觉检查和发布渠道。过去这些环节之间靠人手工搬运，现在 Codex 有机会把它们连起来。

Skills 到底解决了什么问题

Skills 不是“更长的 prompt”。

更准确地说，Skills 是把一套稳定工作方式打包给 Codex 的机制。一个 Skill 通常包含：

• SKILL.md：告诉 Codex 什么时候使用这个 Skill、按什么步骤做、什么事情不能做。
• references/：放规范、示例、品牌指南、教程、检查清单、API 文档。
• scripts/：放可执行脚本，比如渲染 PDF、压缩图片、校验表格、生成缩略图、检查媒体元数据。
• assets/：放模板、样式、封面素材、示例图片、PPT 母版、文档模板。

它的价值是把经验从“人脑里的偏好”变成“Agent 可以执行的流程”。

这件事在多媒体任务里尤其重要。

因为多媒体任务不是单纯生成内容。它还需要风格一致、尺寸正确、格式可用、文件能打开、图片不糊、素材可用、字幕不溢出、页面不穿帮、移动端不炸版。

这些要求如果每次都靠 prompt 临时描述，很容易漏。写成 Skill 以后，Codex 每次遇到类似任务都能自动进入同一套流程。

我的理解是：

Prompt 是一次性表达意图；Skill 是把意图变成组织资产。

最适合沉淀成 Skill 的多媒体工作流

不是所有事情都值得写 Skill。

如果只是一次性让 Codex 生成一张图，用普通 prompt 就够了。真正适合做 Skill 的，是那些你会反复做、步骤固定、容易漏检查、输出质量有要求的流程。

我觉得最值得沉淀的是下面几类。

1. 文章配图 Skill：从主题到封面图和插图

比如个人博客、产品文章、技术长文，都经常需要配图。

普通做法是：写文章，想图，找素材，裁剪，压缩，改文件名，插入 MDX，检查页面。

更好的做法是写一个 article-visuals Skill，让 Codex 固定执行：

1. 阅读文章标题、摘要和核心观点。
2. 判断图片类型：封面图、章节插图、概念图、流程图、对比图。
3. 生成图片 prompt，避免空泛的“科技感”“赛博风”。
4. 生成或挑选图片。
5. 输出 Web 友好的尺寸，比如 1600x900、1200x630、960x540。
6. 压缩图片，写入 public/images/writing/...。
7. 在 MDX 中插入图片。
8. 启动页面预览，检查移动端是否裁切过狠。

文章里可以这样插图：

![图片说明](/images/writing/article-slug/example-image.svg)

如果希望图片自带说明，就在图片下方直接写一句说明文字：

![图片说明](/images/writing/article-slug/example-image.svg)

*这里写一句和图片匹配的说明文字。*

这个 Skill 的效果不是“省一张图的时间”，而是让文章的视觉质量变得稳定。它会提醒你图片尺寸、alt 文案、压缩、移动端显示和主题一致性。

这就是 Skills 的核心价值：把容易忘的细节变成默认流程。

2. 教程脚本 Skill：从操作流程到分镜、旁白和字幕

多媒体里另一个高价值场景是教程脚本。

比如你想做一段“如何用 Codex 给文章配图”的教程。传统流程需要自己写脚本、规划录屏、整理字幕、导出素材、压缩文件、上传资源、插入页面。每一步都不难，但很碎。

可以写一个 tutorial-script Skill，让 Codex 固定产出：

• 目标观众是谁。
• 这段教程解决什么问题。
• 录屏分几段。
• 每段屏幕上应该展示什么。
• 旁白怎么说。
• 字幕文案怎么切。
• 导出格式用什么。
• 插入网页时如何配合图片、说明文字和资源路径。

对应的文章配图可以这样插入：

![教程脚本规划示意图](/images/writing/article-slug/tutorial-script.svg)

*教程脚本 Skill 的关键价值，是把录屏前的结构先固定下来。*

如果文章要解释“嵌入与发布检查”，可以用结构图说明检查点：

![媒体发布检查清单](/images/writing/article-slug/embed-checklist.svg)

*媒体内容进入文章前，需要检查素材路径、说明文字、响应式布局和发布边界。*

这个 Skill 最有用的地方，是把教程从“随手录一段”变成“可复用的教学资产”。

它会逼你先想清楚：观众看完以后能学会什么？屏幕上哪一步必须放大？哪些地方需要字幕？哪些操作需要暂停 1 秒？结尾要给什么可执行模板？

教程内容的质量差距，往往不在模型生成能力，而在前期结构。Skills 刚好适合沉淀这种结构。

3. Browser Review Skill：让视觉验收变成标准动作

很多前端问题，代码里看不出来。

按钮是否溢出、卡片是否拥挤、标题是否压住图片、深色模式是否刺眼、移动端是否错位，这些都必须看真实页面。

Codex 的 In-app Browser 和 Browser Use 很适合这类任务。你可以让 Codex 打开本地页面，操作页面，截图，检查 console 和 network，然后回到代码里修。

更进一步，可以把这套动作写成 browser-review Skill：

1. 启动本地 dev server。
2. 打开指定 route。
3. 分别检查 desktop、tablet、mobile 视口。
4. 检查 loading、empty、error、success 状态。
5. 检查 console error。
6. 检查图片是否加载、媒体说明是否匹配、布局是否溢出。
7. 截图保存到临时目录。
8. 修复问题后再次打开页面验证。

你可以这样要求 Codex：

使用 browser-review Skill 检查 /writing/codex-multimedia-skills-workflow-2026，
重点看移动端文章标题、图片宽度、说明文字和代码块横向滚动。
发现问题后直接修复，并重新截图验证。

这类 Skill 对前端和内容站特别有价值。

因为它把“我感觉页面还行”变成了“多个视口、多个状态、可复查截图”的验收流程。对多媒体页面来说，这一步几乎必不可少：图片、说明文字和代码块比纯文本更容易让布局出问题。

4. Appshots Skill：把屏幕变成上下文入口

Appshots 的价值在于降低描述成本。

很多时候，你不想花 5 分钟描述一个窗口里发生了什么。你只是想说：“就这个页面，这里不对，帮我改。”

Appshots 可以把当前前台窗口作为截图和可读文本发给 Codex。它适合这些场景：

• 把设计工具里的页面截图给 Codex，让它改前端实现。
• 把浏览器里的错误页面给 Codex，让它定位问题。
• 把图片编辑器里的效果给 Codex，让它生成相似风格素材。
• 把一份 PDF、表格或文档预览给 Codex，让它指出排版问题。
• 把移动端模拟器状态给 Codex，让它复现 UI bug。

如果要沉淀成 Skill，可以写一个 appshot-review：

1. 先要求用户提供 Appshot。
2. 识别画面中的关键区域。
3. 把视觉问题拆成可执行修改项。
4. 如果是代码问题，定位到对应组件。
5. 如果是素材问题，生成图片或修改建议。
6. 如果是文档问题，输出排版修订清单。

这个流程的效果很直接：它让 Codex 从“听你描述”变成“看见现场”。

我觉得这会改变很多产品、设计、前端、内容生产的协作方式。以前人类要把视觉问题翻译成文字，再让工程师理解；现在可以把视觉现场直接交给 Agent，然后让它反向推导代码、样式或素材问题。

当然，这不代表可以完全相信视觉判断。Appshot 更像一个入口，最后仍然需要浏览器、截图、测试或人工 review 来确认。

5. Computer Use Skill：处理那些没有 API 的真实世界

Computer Use 是另一个很有想象力的能力。

它让 Codex 可以操作 macOS 或 Windows 上的图形界面 App：看屏幕、点击、输入、切换窗口、复现流程。

这对多媒体尤其重要，因为很多工具不是纯代码工具：

• 图片编辑器。
• 剪辑工具。
• 浏览器。
• 桌面客户端。
• iOS/Android 模拟器。
• 设计软件。
• 内部后台。
• 只能通过 GUI 操作的设置页。

如果把它写成 Skill，我会把重点放在“安全边界”和“验证闭环”上。

比如 gui-media-check Skill：

1. 明确只操作哪个 App。
2. 明确要检查哪个流程。
3. 每一步操作前先描述预期。
4. 遇到账号、支付、安全、隐私、系统权限页面时停下来。
5. 操作后保存截图或输出可复查结果。
6. 如果修改了文件，确认文件路径和导出结果。

这个能力不应该被滥用。它能碰到真实桌面环境，所以边界必须收紧。

但一旦用对，它非常强。因为现实工作里大量问题没有 API，也没有命令行，只能靠人眼和鼠标完成。Computer Use 给了 Codex 一双“手”。

我的观点是：Browser Use 适合网页，Computer Use 适合 GUI 世界。前者更可控，后者更强但更需要人看着。

6. Sites Skill：把多媒体内容直接发布成可访问作品

Sites 的意义在于把 Codex 生成的东西变成可访问的交付物。

如果只是写一个本地 demo，它还停留在工程目录里。Sites 可以把网站、Web App、小游戏、内容页发布出来，并保存版本、部署版本、控制访问范围。

这对多媒体文章、交互教程、产品 demo、数据报告很有价值。

比如你可以做一个 multimedia-site Skill：

1. 根据主题生成一个内容型网站或交互教程。
2. 准备图片、录屏素材、代码示例和交互片段。
3. 判断是否需要持久化数据。
4. 本地构建。
5. 保存一个可 review 的版本。
6. 用户确认后再部署。
7. 部署后检查生产 URL 和访问权限。

这里最重要的是：保存版本和部署版本要分开。

我不建议让 Codex 一上来就直接发布。更好的流程是先保存可审查版本，确认内容、图片、录屏素材、权限、密钥、隐私没有问题，再部署给目标用户。

这也是 Skills 很适合介入的地方。它可以把“发布前检查清单”写死，避免因为兴奋而把半成品直接发出去。

一套完整的 Codex 多媒体工作流

如果把上面的能力串起来，一套完整流程可能是这样：

1. 用 research-writing Skill 搜集资料、整理观点、写文章大纲。
2. 用 article-writing Skill 写成 MDX，包含标题、摘要、tags、related、引用链接。
3. 用 article-visuals Skill 生成封面图和章节插图。
4. 用 tutorial-script Skill 生成录屏脚本、分镜、字幕和素材插入说明。
5. 用 browser-review Skill 打开文章页面，检查桌面端和移动端显示。
6. 用 appshot-review Skill 根据设计稿或预览截图做局部修订。
7. 用 gui-media-check Skill 检查桌面工具导出的录屏素材或图片文件。
8. 用 content-release Skill 跑 content、lint、typecheck，最后提交和发布。

这套流程听起来复杂，但它其实是在替代人类过去一直在做的碎片劳动。

真正的变化是：以前你在不同工具之间切换，脑子里记住检查清单；现在你把检查清单写成 Skills，让 Codex 按流程推进。

这就是“工作流化”的意义。

一个 Skill 可以怎么写

如果我要为博客文章配图写一个 Skill，最小版本大概是这样：

---
name: article-visuals
description: 为技术博客、AI 评论和产品文章生成或整理配图，并检查图片在 MDX 页面中的展示效果。
---

当用户要求为文章配图、生成封面、插入图片、优化文章视觉效果时使用本 Skill。

流程：
1. 读取目标文章的标题、description、核心观点和小标题。
2. 判断需要的视觉资产：封面图、章节插图、概念图、流程图或截图。
3. 为每张图片写出清晰 prompt，避免空泛风格词。
4. 生成或整理图片后，保存到 `public/images/writing/article-slug/`。
5. 使用 Web 友好的文件名、alt 文案和合理尺寸。
6. 将图片插入 MDX。
7. 启动本地页面，在 desktop 和 mobile 下检查图片是否显示、是否过大、是否影响阅读。
8. 输出最终修改文件和验证结果。

限制：
- 不要使用无来源的真实人物照片。
- 不要插入会破坏文章阅读节奏的大图。
- 不要让图片替代核心观点，图片只做解释和增强。

这个 Skill 看起来很普通，但它的效果会非常稳定。

因为 Codex 下次看到“给这篇文章配图”，就不会只生成一张图完事，而是会进入完整流程：读文章、定资产、生成、落盘、插入、预览、验证。

这才是 Skills 的真正威力。

Skills 的效果：把个人经验变成可执行系统

我觉得 Skills 有三个层次的价值。

第一层是省时间。

重复流程不用每次重新说。比如每篇文章都要 title、description、tags、related、图片 alt、移动端检查，这些都可以写进 Skill。

第二层是防漏。

多媒体工作最怕漏细节：图片没有 alt、说明文字和图片不匹配、移动端横向滚动、字幕素材遮挡重点、封面图太大、引用链接失效。Skill 可以把这些检查变成默认步骤。

第三层是风格一致。

一个人写十篇文章，如果每次状态不同，风格会飘。一个团队做十个教程，如果没有流程，质量会散。Skill 可以把风格、语气、尺寸、文件结构、检查标准固定下来。

这也是我最看重的一点。

AI 生成内容并不难，难的是持续稳定地生成符合你标准的内容。Skills 解决的不是“生成”本身，而是“持续稳定地按你的方式生成”。

乐观面：个人创作者会拥有小团队能力

乐观看，Codex + Skills 会让个人创作者拥有类似小团队的能力。

一个人可以完成以前需要多角色协作的流程：

• 作者：写观点和结构。
• 编辑：检查逻辑和标题。
• 设计：生成封面和插图。
• 前端：把文章页面做好。
• 教程策划：拆分脚本、分镜和字幕。
• 测试：检查多端显示。
• 发布：构建、提交、部署。

Codex 不会让每个人都变成专业设计师或导演，但它会把很多“够用且稳定”的产出能力下放给个人。

这对独立开发者、技术博主、产品经理、教育创作者、小团队非常有价值。

尤其是技术内容。很多工程师不是没有观点，而是懒得做图、懒得录屏、懒得排版、懒得发布。Codex 如果能把这些摩擦降下来，内容生产会明显变多。

悲观面：低质量多媒体内容会更多

但悲观面也很明显。

当生成图片、生成录屏脚本、生成网页、生成教程都变得容易，低质量内容也会变多。

最危险的是一种“看起来很完整，但没有真实经验”的内容：

• 图片很精致，但和观点没关系。
• 包装很流畅，但没有解决问题。
• 教程步骤很多，但关键地方讲错。
• 页面很漂亮，但只是模板堆砌。
• 文章很长，但没有判断。

这会让互联网上出现更多“多媒体包装过的空内容”。

所以我觉得未来内容的差距不会只在制作能力，而在判断能力。

Codex 可以帮你做图、写脚本、组织素材、检查页面，但它不能替你拥有真实经验。一个没有观点的人，用 Codex 只会更快地产生包装精致的废话。

客观看：Codex 还需要人的审美、边界和验收

客观看，Codex 在多媒体领域很强，但还不能完全放飞。

视觉理解会有误判。它可能看错截图中的层级，也可能误解设计意图。

图片生成需要审美。它能生成“看起来不错”的图，但不一定适合你的品牌和文章。

教程内容需要节奏。脚本可以自动写，但哪里该停、哪里该放大、哪里该跳过，仍然需要人判断。

Computer Use 需要安全边界。它能点真实 App，就必须明确哪些地方不能碰。

Sites 需要发布审查。它能部署网站，但访问权限、隐私、密钥、内容版权都要检查。

所以最好的使用方式不是“让 Codex 全自动做完”，而是：

让 Codex 承担流程，让人负责判断。

这句话很关键。

Codex 适合做那些可描述、可检查、可重复的环节。人应该保留方向、品味、边界、责任和最后验收。

我会怎么用 Codex 做这类文章

如果我以后持续写 AI、工程和产品方向的文章，我会把 Codex 用成一个内容工作流系统：

1. 先让 Codex 查最新资料，但要求引用来源。
2. 再让 Codex 提炼观点，但我自己决定核心立场。
3. 写第一版 MDX。
4. 用 Skill 检查标题、摘要、tags、related 和文章结构。
5. 生成一张封面图和一到两张解释图。
6. 如果文章适合教程，再生成 3 分钟录屏脚本。
7. 插入图片、说明文字和素材位置。
8. 本地打开页面，检查移动端阅读体验。
9. 跑内容生成、lint、typecheck。
10. 最后 commit 和 push。

这套流程的目标不是让文章“AI 味更重”，恰恰相反，是把机械环节交给 AI，让作者把时间留给观点。

我越来越觉得，未来个人网站、博客、技术内容会出现一个新分水岭：

不是谁会不会用 AI 写文章，而是谁能不能把 AI 组织成稳定的内容生产系统。

结论：Codex 的突破，是让工作流拥有视觉和动作

Codex 最新玩法的重点，不是它能不能替你写一个 React 组件。

真正的新东西是：它开始拥有视觉上下文、浏览器操作、桌面操作、图片生成、文档处理、站点发布和可复用 Skills。

这些能力合在一起，会让 Codex 从“写代码的助手”变成“处理真实工作流的工作台”。

而 Skills 是其中最值得重视的部分。

因为单个能力只是工具，Skills 才能把工具变成流程；单次 prompt 只是请求，Skills 才能把请求变成可复用资产。

我的核心判断很直接：

未来优秀的 Codex 用户，不只是会写 prompt 的人，而是会设计 Skills 的人。

他们会把自己的经验、审美、检查清单、脚本、模板和发布流程，一点点沉淀进 Codex。久而久之，Codex 就不只是一个模型入口，而会变成一个带有个人工作方式的生产系统。

这才是 Codex 在多媒体领域最值得期待的突破。

它不是让人少思考，而是让人把思考沉淀成系统。