让 AI 生成一张图，这个需求几乎每个做产品的人都有过。OpenAI 官方在 openai/skills 仓库里维护了一个叫 imagegen 的技能，同时发布在 Smithery 平台，目前累计 7,309 次浏览和 29 次安装。它做的事情一句话能说清：通过 OpenAI Image API 生成或编辑图像，默认模型是 gpt-image-1.5。
安装量不算高，但这个技能值得拆，因为它代表了一种新的思路：OpenAI 自己是怎么规范”AI 画图”这件事的。它覆盖的范围很广，生成、编辑、批量三块都管。表面看是个工具箱，实际读下来，功夫全花在流程设计上。
-
生成：概念艺术、产品图、UI mockup、封面、hero 图 -
编辑：inpainting 遮罩编辑、背景移除替换、透明背景 -
批量：多 prompt 变体并发生产
我最初以为它就是个”给个 prompt 出图”的封装。把 SKILL.md 从头读完之后才发现，它的核心不是生成，而是控制：用决策树决定该走哪条路径，用分类法约束 prompt 的写法，用校验清单兜住输出质量。这跟市面上大多数图像生成工具根本不是一个思路。
这篇文章会带你拆开它的双模式架构，走一遍从请求到落盘的完整链路，再聊聊那套 16 类用例分类法和 prompt 增强规范。读完你应该能判断，这个技能的设计哪些值得直接抄进自己的 Agent 工作流。
架构解析
imagegen 最值得研究的是它的双模式设计。顶层只有两条路：默认走内置 image_gen 工具，不需要 OPENAI_API_KEY；CLI 回退模式跑 scripts/image_gen.py，必须显式请求才启用，且要求设置 OPENAI_API_KEY。文档把这两者写得非常硬：内置工具优先，CLI 永不自动切换，只在用户明确要求时才走 CLI。
这个设计的背景是这个技能主要服务 Codex 这类 Agent，而 Codex 本身内置了 image_gen 工具。既然宿主环境已经有原生能力，skill 就没必要再造轮子，直接声明”默认用内置工具”就行。CLI 存在的意义是确定性：同样一条 prompt，走同一个脚本，结果可复现，这正好补上内置工具在可审计性上的短板。
CLI 回退路径下有三个子命令，每个对应一种执行方式。依赖也刻意做轻，必装只有 openai 一个包，pillow 是可选，仅用于生成降采样副本，作者想让它能塞进任何 uv 管理的环境。
-
generate：从 prompt 生成新图 -
edit：编辑一张或多张现有图 -
generate-batch：从 JSONL 文件批量跑任务
输出路径策略同样值得看。内置工具模式下，图像默认落在 $CODEX_HOME/generated_images/ 下，但文档给了明确的优先级：用户指定了位置就移过去，图像属于当前项目就移进工作区，只是预览就留在原地。项目引用的资产绝不允许只待在默认路径，否则换个环境就找不到了。
这套架构想得很明白：能走原生通道就走原生，要确定性就显式切 CLI，两条路共享同一套 prompt 规范。它没有把能力做成二选一，而是让用户在体验和可控之间自己选，这种设计在 skill 生态里相当少见。
工作流分析
整个流程的入口是一棵决策树，两个问题定生死。第一个问题是意图：用户要新图还是改图，给了输入图且要保留部分内容就算 edit，图片只作参考就算 generate，没给图默认 generate。第二个问题是执行策略：只要一个资产还是多个变体，多个就进批量通道。两个问题一交叉，路径就确定了。
定了路径之后是 8 步工作流，前四步全是分流，后四步才是干活。输入收集是最花心思的一环，五类输入前置收齐才动手：
-
分流：模式判定、意图判定、预览还是项目资产、单资产还是批量 -
干活：收集输入、给每张输入图标角色、按 specificity policy 增强 prompt、生成后校验迭代 -
输入：prompt 主需求、逐字文本、约束清单与 avoid 列表、输入图像及其角色
prompt 增强规范是文档里最见功力的一节。核心原则叫 specificity policy：用户的 prompt 已经具体，就只做规范化，不加戏；用户给得笼统，才允许补充构图、氛围这类能实质提升质量的细节。同时划了明确的禁区，禁止凭空给 prompt 加戏：
-
加角色、品牌名、调色板等未暗示的内容 -
擅自指定画面位置，除非周围布局确实需要
生成之后的校验也不是走过场。文档要求逐项核对六个维度，复杂编辑尤其如此。迭代规则很克制：一次只改一个点，改完重跑重查，禁止一次堆多个修改。对编辑类任务，还要求每一轮都重复声明 invariants，防止模型越改越漂。
-
主题与主体是否一致 -
风格与构图是否符合预期 -
文字是否逐字准确 -
invariants 与 avoid 项是否守住
使用场景
imagegen 把用例收敛成了一套 16 类的分类法，每个请求都要归入一个 slug。生成侧 8 类：
-
写实自然场景、产品 mockup、UI mockup -
信息图、logo 品牌、插画故事 -
风格化概念、历史场景
编辑侧 8 类：
-
文本本地化、身份保持、精准物体编辑 -
光照天气变换、背景提取、风格迁移 -
多图合成、素描转渲染
slug 全程保持一致，prompt 和参考文档对得上号。
产品 mockup 是最典型的用法。给一个陶瓷咖啡杯的 hero 图需求，标准 prompt 会把 labeled spec 逐字段拆开，每个字段单独成行：
-
场景与主体 -
风格与构图 -
光照与氛围 -
约束与 avoid 项
负空间留给页面文案，明确禁止 logo、文字和水印。编辑场景里，invariants 是灵魂，比如”只换背景，产品及其边缘保持不变”，这类约束要写进 prompt 并且反复强调。
CLI 模式下参数控制相当细，编辑和批量各有专属开关：
-
–quality：low / medium / high / auto 四档 -
–input-fidelity：编辑专属，low 或 high -
–mask：编辑专属，用 PNG 遮罩指定区域 -
–concurrency：批量并发数，默认 5
批量场景用 JSONL 写任务，每行一个 job，还能逐项覆盖尺寸、质量与输出格式。透明背景必须配 png 或 webp。尺寸支持 1024×1024、1536×1024 与 1024×1536 三种横竖规格，也可以直接传 auto。
边界划分同样明确。凡是应该直接改代码原生资产的场景，它都明确说不归自己管：
-
扩展已有图标库或 logo 系统 -
在 HTML/CSS 里画形状 -
小改动直接改原生格式源文件
判断标准就一条：用户要的是位图资产，还是确定性更强的代码原生输出，后者就别用它。
洞察与反思
通读整份文档，最反直觉的一点是：这个技能最强调的从来不是”怎么画得好看”，而是”怎么控制画出来的东西”。控制权散在四处，全部指向同一个目标，让图像生成的每一步都可预期、可解释：
-
决策树管意图分流 -
分类法管 prompt 口径 -
specificity policy 管增强边界 -
校验清单管质量收口
双模式架构放在整个 Agent 生态里看特别有意思。内置工具优先是纯用户体验决策，用户少装依赖少配 key；CLI 显式回退是纯工程决策，要确定性、要批量、要复现才用。两个模式共享同一套 prompt 规范和决策树，说明设计者把”能力”和”流程”彻底解耦了，这是它和那些一把梭的封装工具最本质的区别。
局限也摆在明面上。CLI 模式绕不开 OPENAI_API_KEY 和网络访问，离线环境直接不可用；模型固定走 gpt-image 系列，对老模型的参数行为不兼容；路径策略深度绑定 $CODEX_HOME，本质上是为 Codex 生态设计的，换到别的 Agent 环境要自己适配。29 次安装也说明它还没走出早期阶段。
我的结论是，它的价值不在图像质量本身，而在把那套流程规范带给了所有人。对已经在用 Codex 的开发者，装一个就能获得标准化的图像资产流水线；对做 Agent 工具的人，它的决策树、分类法和 prompt 增强规范，本身就是一份可以照抄的设计参考。
资源地址
| 资源 | 链接 |
|---|---|
| Smithery 技能页 | https://smithery.ai/skills/openai/imagegen |
| GitHub 源码仓库 | https://github.com/openai/skills |
| SKILL.md 原始文件 | https://github.com/openai/skills/tree/main/skills/.system/imagegen |
| OpenAI API Keys | https://platform.openai.com/api-keys |
总结
回头梳理这个技能，核心就三件事：双模式让体验和可控兼得，16 类分类法统一了 prompt 口径，校验与迭代把质量兜在了流程里。每一步单看都不复杂，组合在一起恰好解决了 AI 图像生成最缺的东西：确定性和可复现性。
如果你在用 Codex 且经常需要生成产品图、概念图或批量变体，这个技能值得直接装进环境。如果只是偶尔让 AI 画张图，内置工具已经够用，但决策树和 prompt 规范依然值得读一遍，它能让你少走很多调 prompt 的弯路。
AI 画图最大的问题从来不是模型画得不够好，而是结果不可控。imagegen 给出的答案是把控制权前置到流程里，让每一步都有据可查。这个思路本身，比这个技能更值得带走。