让 Codex 真正生成图片：从 SVG 平面图到高质量图像的提示词方法

当你让 Codex 生成一张图片，却得到像 SVG 转成 PNG 一样扁平的结果时，问题未必在模型能力。很多时候，Codex 只是根据模糊的任务描述，选择了更适合代码和矢量资产的制作路径。

这篇文章整理了一次实际的 Before／After 测试：只说“做一个简单的猫图标”，得到的是平面猫脸；明确调用图像生成工具、指定题材、颜色、质感、构图、禁止事项和保存位置后，结果才更接近一张完整插画。重点不在把提示词写得更长，而在把用途和合格条件说清楚。

原文记录的实测在 2026 年 7 月 13 日进行：从 Claude Code 调用 Codex CLI 0.144.1，使用 ChatGPT 账号登录，没有额外配置 API 密钥。这里保留测试条件与限制，但不把它当作严格的单变量实验。

先给结论

先把最值得记住的判断列出来：

Codex 可以生成照片和插画，也可以用 SVG、HTML、CSS 等方式制作视觉资产。

文件扩展名是 PNG，不代表文件一定由图像生成模型直接生成；它也可能是 SVG 转成的栅格图。

需要照片或插画时，可以在请求中加入 $imagegen，明确要求走图像生成路径。

结果差异主要来自用途、主体、风格、构图和限制条件，而不是提示词的字数。

详细说明的价值，不是让画面看起来更“豪华”，而是更容易复现符合使用场景的构图。

第一次不必追求完美；指出要改变的元素和必须保留的元素，一次只改一个地方。

如果只想先做一个最短测试，可以在请求开头加上这句话：

不过，这句话只是固定生成方式。真正决定结果是否可用的，仍然是“这张图要用在哪里”“主角是谁”“什么状态才算完成”。

为什么会得到 SVG 风格的图片

Codex 并不是只会生成图片的工具。它还会写代码、读取项目文件、修改网站，并在合适时使用 SVG、HTML、CSS 或 canvas。对工程任务来说，这种灵活性反而是优点。

例如，网站里已经有一套 SVG 图标，需要新增一个相同线宽、颜色和尺寸的图标。此时直接编辑已有 SVG，通常比用图像生成模型做一张 PNG 更准确，也更容易继续维护。

但文章头图、照片风格的画面、有材质的角色、广告横幅等任务，需要的是一张有光影和质感的完整图像，图像生成更合适。

照片、插画、纹理、精灵图、模型图等适合位图表达的任务，优先使用图像生成。

需要编辑既有 SVG、矢量或代码资产时，优先沿用原有资产格式。

“图标”和“Logo”本身并不是决定因素。同一个图标，可能是需要无限缩放的 UI 矢量部件，也可能是要发布到社交媒体上的、有阴影和材质的装饰性单幅画。

当请求足够模糊时，Codex 会根据项目文件和上下文推测你想要哪一种。真正的问题不是这些词被禁止，而是你没有把成果物的形式传达清楚。

先分清三个相似的名字

原文把 Codex 图像生成相关的三个名称分开说明，避免把技能、工具和模型 ID 混为一谈：

$imagegen：Codex 的图像生成技能名，用来明确触发这条工作路径。

image_gen：Codex 内置的图像生成工具名。

gpt-image-2：在 API 或明确使用备用 CLI 时，直接指定的模型 ID。

“Image 2.0”或“GPT Image 2 相当”更像质量预期的说法，不是执行时的正式模型 ID。

通常在 Codex 内直接生成图片时，用 $imagegen 调用技能，再使用内置的 image_gen 工具即可，不需要另外准备 OPENAI_API_KEY。只有明确走 API 或备用 CLI、直接指定 gpt-image-2 时，才需要相应的 API 密钥。

官方提示词原则也很直接：说明用途、主体、背景、构图、风格和限制；用光线方向、位置等具体条件替代“好看一点”“高级一点”这样的抽象形容；编辑时一次只改一个元素，并重复需要保持的条件；如果图片中要出现文字，使用引号标出文字内容，同时说明字体、颜色、大小和位置。

实际的 Before／After 测试

这不是只改变一个变量的对照实验。Before 只描述想要的东西；After 同时指定了生成工具、输出格式、题材、颜色、构图、禁止事项、质量和保存位置。它回答的是一个更实际的问题：把请求写得足够具体后，结果会不会改变。

Before：只说“做一个简单的猫”

第一次给 Claude Code 的请求只有这一句：

这里没有指定图像生成模型、PNG、SVG、颜色、质感、背景或保存位置。最终文件的记录是：

文件名：cat-icon.png。

格式：PNG、RGBA。

尺寸：1024×1024 像素。

色深：16 位。

容量：约 121KB。

外观：用简单图形叠加出的扁平茶色虎斑猫脸。

Before：请求只强调“简单的猫图标”，结果是扁平的图形化猫脸。

画面是浅黄色圆形背景，猫脸占据主要位置，表情可爱，完全符合“简单的猫图标”这句话。问题在于，提问者期待的是由图像生成模型制作、带有材质的完成插画，而这层期待并没有写进请求。

同一文件夹还生成了 cat-icon.svg。PNG 的元数据里也保留了 SVG 标题和“背景、耳朵、脸、眼睛、项圈”等构成要素。由此可以判断，Codex 把“简单图标”理解成矢量素材，先做 SVG，再转换成 PNG。

所以 Before 与其说是失败，不如说是过于忠实地执行了“简单”二字：为了便于编辑，Codex 用简单图形做出了简单结果。

After：把生成方式和完成条件固定下来

第二次请求同时固定了生成路径和画面要求。原文实际使用过下面这条命令：

如果使用 Codex 内置能力，原文建议改成显式调用 $imagegen 的写法：

这里的差异不只是“文字变长”了，而是补齐了会改变结果的条件：

明确使用图像生成工具。

要求输出 PNG。

禁止用 SVG、HTML 或 CSS 代替。

主体是拿着麦克风的猫。

使用可爱的扁平画法，同时加入柔和阴影和高光。

加入蓝色圆形框。

背景使用 #FDE68A。

加入星星和圆形散景。

用 #2563EB 做强调色。

猫使用奶油色到橙色的配色。

不加入文字和水印。

质量设为 high。

固定输出文件名和保存路径。

After：明确生成工具、主体、配色、质感和限制后，得到信息量更丰富的完整插画。

After 的实际文件记录为：由 Codex 内置图像生成工具生成，PNG、RGB，尺寸 1254×1254 像素，8 位色深，容量约 1.74MB。画面包含奶油到橙色的猫、麦克风、蓝色圆框、黄色背景、蓝色星星和圆形散景；毛发与麦克风有柔和阴影和高光，没有文字或水印。

从两次结果中能确定什么

同样是 PNG，生成路径可能完全不同

Before 和 After 的扩展名都是 .png，但前者是 SVG 转成的图，后者是图像生成工具直接输出的栅格图。只看交付格式，无法判断期待的生成路径是否真的发生。

Before 其实符合原始请求

“简单的猫图标”本来就可以由简单图形组成。Codex 并不是无视指令，而是按照这句请求中最明确的部分完成了任务。缺少的是对“质感完成插画”的描述。

After 指定了制作方式，而不只是说“更好看”

真正起作用的是：指定使用图像生成工具、禁止 SVG 代替，同时给出主体、背景、配色、质感、构图和保存位置。它把结果从“做什么”推进到了“怎么做”和“什么算完成”。

不能把全部画质提升归因于 `$imagegen` 一个词

After 同时改变了主体、配色、阴影、背景、构图和质量设置，因此不能把视觉改善严格归因于 $imagegen 单独一个词。可以确定的是，它明确表达了要走图像生成模型、不要走 SVG 转换路径的意图。

不要只说想要什么图，也要说希望它通过什么方式生成，以及什么状态才算合格。

`$imagegen` 到底解决什么问题

如果照片或插画的需求已经非常明显，Codex 有时会自动选择图像生成。但在拥有大量既有 SVG 和 UI 资产的项目中，明确写出 $imagegen 仍然有三个实际作用：

减少路径误判：当你需要一张完整单幅画时，明确图像生成可以降低 Codex 选择代码编辑路径的概率。

统一团队的表达：让“图片、图标、横幅”在团队里对应更清楚的生成规则，减少人员变化带来的结果波动。

便于定位失败原因：生成路径确定后，如果结果仍不理想，就能继续检查构图、风格和限制条件。

因此，$imagegen 更像是固定执行方式的开关，而不是提升画质的咒语。

一份可以直接复制的最短模板

不用每次都写到这么细。官方指南也认为，清晰的 1 到 3 句描述往往就够用。重点是让影响成功与否的条件出现在请求里，而不是堆很多形容词。

稳定图片质量的 5 个字段

用途：写清楚是 X 帖子、头像、博客头图、LP Hero 还是商品介绍图。用途会影响比例、留白和信息密度。

主役：说明要画什么，以及它处于什么状态，例如“拿着麦克风的茶色虎斑猫”。

风格：指定照片、插画、3D、水彩或杂志编辑风等具体质感。

构图：说明比例、主体位置和需要保留的留白，例如横图、人物靠左、右侧留出标题空间。

限制：明确不要出现的内容，以及必须遵守的条件，例如无文字、无 Logo、无水印、背景不要过于复杂。

这五项能让 Codex 不只是“画一个东西”，还要判断它是否适合使用场景。原测试中，“蓝色圆形框”就帮助模型把猫和麦克风收进了明确的构图。

按用途准备的提示词模板

文章头图

这里不说“做得时髦一点”，而是直接给出木桌、自然光、主体左移和右侧留白。

X 帖子的正方形图片

LP 的 Hero 图

需要在图片里放中文时

图片中出现文字时，原文建议把要显示的文字放进引号，指定字体、颜色、大小和位置，并明确禁止添加其他文字。生成后还要逐字检查。

修改时写清楚“改变什么”和“保留什么”

第一版只差一点时，不必把提示词全部推倒重写。一次改很多条件，会连喜欢的部分也一起改变。更稳妥的做法是只改一个元素，同时写出必须保持不变的部分。

构图保持不变，只把背景调亮。

人物和桌子保持不变，只把马克杯替换成观叶植物。

颜色和光线保持不变，只扩大右侧留白。

猫的表情和毛色保持不变，只把麦克风缩小一点。

“只改这里，其他都不要动”能减少整张图的漂移，也让失败后的修正更容易判断。

把规则固定在项目文件里

如果每次都重复输入同一套限制，可以把规则写进项目文件。由 Claude Code 调用 Codex 时，可放在 CLAUDE.md；直接使用 Codex 的项目，可放在 AGENTS.md。这不是永远禁止 SVG，而是让不同用途使用不同路径。

如果只是一个项目内的固定规则，先用 CLAUDE.md 或 AGENTS.md 就够了。只有当“生成、检查、保存”这整套流程要跨多个项目复用时，才值得进一步做成独立 Skill。

哪些场景反而应该用 SVG

SVG 并不是低质量方案。关键是区分“需要确定性维护的部件”和“优先表达力的单幅图”。

给既有 UI 图标集新增图标。

需要无限缩放仍保持清晰。

需要用 CSS 修改颜色。

需要用数值精确管理形状和线宽。

需要把代码差异纳入 Review。

相反，下面这些任务通常更适合图像生成：

照片风格的视觉。

需要毛发、布料或金属质感的插画。

广告或文章的引导图。

有角色和故事性的单幅画。

需要传达氛围和情绪的视觉。

判断标准不是 SVG 还是 PNG，而是这件东西需要被确定性地管理，还是应该优先保留表现力。先做这个判断，再告诉 Codex 生成路径，能减少形式错配。

这次测试修正了 3 个常见误解

误解一：PNG 就代表由图像生成模型制作

初次结果确实是 PNG，但元数据里留下了 SVG 标题和构成要素，画面也呈现出简单图形的组合。要确认的不是扩展名，而是生成路径和实际外观。

误解二：加上 `$imagegen`，画质就会自动提高

After 的信息量明显更高，但它同时指定了麦克风、配色、阴影、背景、构图和质量。因此 $imagegen 的主要作用是固定图像生成路径，不会单独保证你喜欢的成片效果。还需要写清楚画面条件和验收标准。

误解三：提示词越长越好

After 变好不是因为字数更多，而是因为写入了图像生成工具、禁止 SVG、主体、配色、背景、质感和保存路径等会真正改变结果的条件。关键是写出判断所需的信息，而不是把所有想到的形容词都加进去。

总结：让 Codex 知道什么叫“合格”

当 Codex 返回一张过于简单的图时，先别急着怀疑模型性能。先判断：你要的是代码里使用的矢量部件，还是照片或插画形式的完整单幅图？再检查这个意图是否被写进请求。

然后补上用途、主体、风格、构图和限制。原测试中，只说“简单的猫图标”时，Codex 选择了 SVG 生成后转 PNG 的平面结果；明确使用图像生成工具、禁止 SVG 代替，并写出题材、配色、质感、背景和质量后，才更容易得到符合预期的完整插画。

决定图片质量的不是提示词长度，而是你是否共享了使用场景和合格条件。把“用途”和“验收标准”各补充一条，就能从等待偶然命中，走向更可复现的图像制作。