当你向 Codex 请求生成一张图片时，为什么它有时会返回一个扁平的、类似 SVG 的图形，而不是真正的插图？
你原本期望得到一张照片或插图，但实际得到的却是一堆简单的几何形状。
“这是 Codex 图像生成能力的极限吗？”
一开始我也这么想。我怀疑是使用了像“图标”或“logo”这样的词，导致 Codex 选择用 SVG、HTML 或 CSS 来绘制，而不是真正的图像生成。
于是，我亲自测试了 Codex。
我从 Claude Code 调用 Codex，并比较了以下前后结果：
- 之前：简单地要求“创建一个简单的猫图标”。
- 之后：指定了图像生成工具、主体、颜色、纹理、禁止项和保存位置。
结果证实了我的怀疑。
简短请求返回了一个扁平的猫图标，它实际上是一个栅格化后的 SVG，尽管扩展名是 PNG。
另一方面，明确指定了图像生成工具和完成条件的请求生成了一个丰富的图像，图中有一只拿着麦克风的猫、一个蓝色圆形边框、黄色背景，甚至还有散景效果。
简而言之，这次验证揭示了以下内容：
通过不仅传达主体，还传达使用图像生成模型、避免使用 SVG 替代方案以及颜色和纹理等细节，你可以改变 Codex 创建图像的方式。
在本文中，我将根据 OpenAI 官方信息以及 2026 年 7 月 13 日的实际测量结果，整理如何在 Codex 中创建你想要的图像。
结论先行
以下是关键要点：
- Codex 可以生成照片和插图，但也可以使用 SVG、HTML 和 CSS 创建视觉效果。
- 即使扩展名是 PNG，内容也可能是从 SVG 转换而来的图像。
- 当你想要一张照片或插图时，在提示中添加
$imagegen可以显式调用图像生成技能。 - 质量差异来自于“目的、主体、风格、构图和约束”，而不是提示的长度。
- 详细说明的价值在于使构图更容易按其预期用途再现，而不仅仅是让它看起来很花哨。
- 不要试图一次就完美，通过指定要更改和保留的内容来逐个修复元素。
如果你想立即尝试，请在请求的开头添加以下句子：
──────── 复制粘贴 ────────
使用 $imagegen 通过图像生成模型生成栅格图像。不要用 SVG、HTML、CSS 或 Canvas 替代。
──────────────────────
然而，并不是只有这一句话起作用。通过传达“图像用于什么”以及“什么才算合格”，Codex 最终可以按照与你相同的标准来检查图像。
为什么它输出 SVG 而不是图像？
Codex 不是一个专门的图像生成服务。它编写代码、读取现有文件、修复网站，并根据需要处理 SVG、HTML、CSS 和 Canvas。这是一个很大的优势。
例如，如果一个网站有一个现有的 SVG 图标集，并且你想添加一个具有相同线宽、颜色和大小的新图标，那么编辑现有的 SVG 比使用图像生成模型创建 PNG 更准确。
另一方面，文章的头图、照片风格的视觉元素、有纹理的角色和广告横幅更适合使用图像生成而不是代码。
Codex 当前的 imagegen 技能也区分了这两种情况：
- 对于适合位图图像的任务，如照片、插图、纹理、精灵图和模型，它使用图像生成。
- 对于更适合编辑现有 SVG、矢量或代码资产的任务，它优先选择编辑。
关键的是，这并不是仅凭“图标”或“logo”这个词就能机械决定的。
即使是同一个图标，也有两种用途：
- 用于 UI 的可缩放矢量组件。
- 用于社交媒体的带有纹理和阴影的装饰性单张图像。
如果请求不明确，Codex 会根据项目中现有的文件或周围上下文来猜测你想要哪一个。当猜测偏离你的意图时，就会出现“想要照片却得到类似 SVG 的东西”的现象。
因此，问题的本质不是“禁止使用图标这个词”。而是没有向 Codex 传达所需输出的格式。
从官方信息中可以确认什么
在 Codex 图像生成中，出现了三个相似的名字，但它们的含义不同：
$imagegen：显式调用 Codex 图像生成技能的名称。image_gen：Codex 内置的图像生成工具的名称。gpt-image-2：通过 API 或回退 CLI 直接指定模型时的模型 ID。- “Image 2.0”或“GPT Image 2 equivalent”：用于传达质量图像的术语，而不是运行时的正式模型 ID。
对于正常的图像生成，基本方法是使用 $imagegen 调用技能，并使用内置的 image_gen 工具。在这个路径下，你不需要单独的 OPENAI_API_KEY。
直接指定 gpt-image-2 作为模型 ID 适用于你显式使用 API 或回退 CLI 的情况。这个路径需要 OPENAI_API_KEY。
此外，有效的图像提示遵循以下原则：
- 具体传达目的、主体、背景、构图、风格和约束。
- 写具体的细节，如光线方向和位置，而不是像“漂亮”或“时尚”这样的抽象术语。
- 修正时，一次只改变一个元素，并重复你想要保持的条件。
- 将图像中的文本用引号括起来，并指定字体、颜色、大小和位置。
我们从中了解到，$imagegen 是官方提供的显式调用技能的方式。这并不意味着“没有它你绝对无法创建图像”。然而，在我们的“之前”案例中，选择了创建 SVG 而不是图像生成的路径。它的作用是明确表达使用图像生成的意图，而不是将其交给自动判断。
实际前后对比
以下是实际测量结果。我从 Claude Code 调用 Codex。使用的 Codex CLI 版本是 0.144.1，通过登录 ChatGPT 账户执行，没有添加 API 密钥。
需要明确的是，这不是一个只改变一个条件的严格对比实验。在“之前”中，我只简要说明了要制作什么。在“之后”中，我指定了生成工具、存储格式、主体、颜色、构图、禁止项和质量。
换句话说，这是对在经历失败后指定请求时结果变化程度的前后对比。
之前：只要求“简单的猫”
发送给 Claude Code 的初始请求只有这个：
──────── 复制粘贴 ────────
创建一个简单的猫图标
──────────────────────
我没有指定图像生成模型、PNG、SVG、颜色、纹理、背景或保存位置。
这是返回的结果：
检查文件后发现了以下信息：
- 文件名：
cat-icon.png - 格式：PNG, RGBA
- 尺寸：1024x1024 像素
- 位深度：16 位
- 文件大小：约 121KB
- 外观：一个由重叠的简单形状组成的扁平棕色虎斑猫脸。
构图是一只大猫脸在浅黄色圆形背景上。表情很可爱，并且遵循了“简单猫图标”的要求。
换句话说，Codex 并没有忽略指令。相反，问题在于请求太短，无法传达我所期望的“由图像生成模型完成的带有纹理的插图”。
同一文件夹中还创建了一个 cat-icon.svg。此外，PNG 元数据中包含 SVG 组件，如 svg:title 为“Cute brown tabby cat face icon”，svg:comment 为“background”、“ears”、“face”、“eyes”和“collar”。
这意味着 Codex 将“简单图标”解释为对矢量素材的请求，创建了 SVG 并将其转换为 PNG。
“之前”的结果不是失败，而是过于字面化。 因为我只说了“简单”，Codex 就用易于编辑的几何形状简单地制作了它。
之后：修复生成方法和最终图像
接下来，我使用以下内容从 Claude Code 调用 Codex：
──────── 复制粘贴 ────────
mkdir -p ./images
codex exec -C "$(pwd)" -s workspace-write --skip-git-repo-check \
"使用图像生成工具 (image_gen / gpt-image-2) 生成一张可爱的猫拿着麦克风的插图，保存为 PNG 到 ./images/cat-mic.png。使用扁平可爱的配色、柔和的阴影和高光、蓝色圆形边框、背景色 #FDE68A 带有小星星和散景、强调色 #2563EB，猫的颜色为奶油色到橙色。作为单张插图创建，不要用 SVG 或 HTML/CSS 替代。不要包含文字或水印。质量高。"
──────────────────────
这是实际使用的命令。然而，image_gen 和 gpt-image-2 并不是同一事物的别名。如果你使用 Codex 的内置功能，现在推荐这样写：
──────── 复制粘贴 ────────
mkdir -p ./images
codex exec -C "$(pwd)" -s workspace-write --skip-git-repo-check \
'使用 $imagegen 调用内置的 image_gen 工具，生成一张可爱的猫拿着麦克风的插图，保存为 PNG。使用扁平可爱的配色、柔和的阴影和高光、蓝色圆形边框、背景色 #FDE68A 带有小星星和散景、强调色 #2563EB，猫的颜色为奶油色到橙色。不要用 SVG 或 HTML/CSS 替代。不要包含文字或水印。完成后，将生成的图像保存到 ./images/cat-mic.png。以高质量完成。'
──────────────────────
整个提示用单引号括起来的原因是为了防止 $imagegen 中的 $ 被 shell 展开为变量，从而直接传递给 Codex。
与“之前”的区别不仅仅是文本更长：
- 明确指定了图像生成工具
- 保存为 PNG
- 不用 SVG 或 HTML/CSS 替代
- 主体是拿着麦克风的猫
- 扁平可爱的配色，带有柔和的阴影和高光
- 包含蓝色圆形边框
- 背景色设置为 #FDE68A
- 包含星星和散景
- 强调色设置为 #2563EB
- 猫的颜色设置为奶油色/橙色
- 没有文字或水印
- 质量设置为高
- 保存位置固定为
./images/cat-mic.png
这是生成的图像：
实际文件如下：
- 文件名：
cat-mic.png - 生成路径：Codex 内置图像生成工具
- 格式：PNG, RGB
- 尺寸：1254x1254 像素
- 位深度：8 位
- 文件大小：约 1.74MB
图像反映了奶油色到橙色的猫拿着麦克风、蓝色圆形边框、黄色背景、蓝色星星和散景。猫的毛发和麦克风上有柔和的阴影和高光，作为完成的插图，比“之前”版本提供了更多的信息。没有文字或水印。
比较两个结果所学到的
即使扩展名相同为 PNG，内容也完全不同。
“之前”和“之后”都有 .png 扩展名。然而，“之前”是从 SVG 转换为 PNG 的图像，而“之后”是图像生成工具直接创建的栅格图像。你不能仅凭“以 PNG 形式交付”来判断是否是预期的生成方法。
“之前”的结果对于提示来说是正确的。
我在“之前”要求的是“简单的猫图标”。出来的确实是一个简单的猫图标。并不是 Codex 的能力低，而是我的语言没有限定最终图像。
“之后”则指示了生成路径。
在“之后”中起作用的，不是像“让它更漂亮”这样的模糊要求。而是指定了使用图像生成工具、不替代 SVG、颜色、主体、背景、纹理和保存位置。
质量差异不能仅仅归因于 image_gen。
在“之后”中，我同时改变了主体、配色方案、阴影、背景和质量，以及生成工具。因此，视觉上的改进不能单独归因于 image_gen 这个词。但它至少明确了避免“SVG 到 PNG 转换路径”并进入图像生成模型的意图。
不仅要传达你想要什么，还要传达你希望如何制作它。 这是从这个前后对比中学到的最大的教训。
添加 $imagegen 的目的是什么？
查看这些结果，你可能会想：“如果没有它也能生成 PNG，那 $imagegen 是不是就没必要了？”
确实，如果请求明确是照片或插图，Codex 可能会自动选择图像生成。然而，明确说明有三个理由：
- 减少路径混淆：在包含许多现有 SVG 或 UI 资产的项目中，Codex 可能会判断编辑代码更合适。如果你需要单张图像，明确说明图像生成可以减少意图偏差。
- 标准化团队间的请求：如果“图像”、“图标”和“横幅”的含义因人而异，输出也会不同。通过将
$imagegen和目的作为通用规则，即使提出请求的人不同，也更容易选择相同的路径。
- 更容易隔离失败原因：如果你明确说明了图像生成但结果很差，接下来要检查的是构图、风格和约束。如果路径未知，你就不知道是“图像生成模型不好”、“是用 SVG 制作的”还是“提示不明确”。
将 $imagegen 视为一种提高图像质量的魔法咒语，不如把它看作一个固定执行方法的开关。
最短可用提示
首先，请复制粘贴这个格式：
──────── 复制粘贴 ────────
使用 $imagegen 通过图像生成模型创建以下图像。不要用 SVG、HTML、CSS 或 Canvas 替代；将其生成为单张栅格图像。
目的：X 个人资料图片
主体：拿着麦克风的猫
风格：友好的 3D 插图，有深度感
构图：方形，居中，即使裁剪成圆形，主体也保持完整
约束：无文字、logo 或水印
──────────────────────
你不需要把所有内容都写得很详细。OpenAI 的官方指南也说明，对于图像提示，1-3 个清晰的句子通常就足够了。重要的不是长度，而是包含决定成功的条件。
稳定图像质量的 5 个要素
如果你不确定提示怎么写，只需写下这五个方面：
- 目的：写明图像将用于何处。例如：X 帖子、个人资料图片、博客头图、落地页主视觉、产品介绍。当你写明目的时，Codex 可以更容易地判断所需的构图和边距。
- 主体：写明要画什么以及处于什么状态。例如：一只拿着麦克风的棕色虎斑猫、一个在笔记本电脑上工作的女性、放在桌子上的咖啡。
- 风格：指定所需的纹理，如照片、插图或 3D。例如：自然光下的真实照片、杂志风格编辑插图、柔和的水彩、有深度的 3D。
- 构图：写明宽高比、主体位置和所需的边距。例如：横向，人物在左侧，右侧留出宽边距用于标题。在我们的“之后”示例中，“蓝色圆形边框”的指令导致构图将猫和麦克风包含在圆圈内。
- 约束：写明你不希望包含的内容以及需要遵守的条件。例如：无文字、无 logo、无水印、背景不要复杂。
有了这五个方面，Codex 不仅可以“制作图片”，还可以检查“是否适合目的”。
按用途分类的复制粘贴示例
文章头图
──────── 复制粘贴 ────────
使用 $imagegen 生成一张博客文章的横向头图。制作一张真实照片，画面显示笔记本电脑和咖啡放在木桌上，在柔和的自然晨光中拍摄。主体左对齐，右侧留出宽边距用于标题。不要包含文字、logo 或水印。不要用 SVG、HTML 或 CSS 替代。
──────────────────────
X 帖子方形图片
──────── 复制粘贴 ────────
使用 $imagegen 生成一张 X 帖子的方形插图。用友好的编辑插图风格表达 AI 和一个人在同一张桌子上合作制定计划的场景。将人物和 AI 设备放在中心，构图要在智能手机时间线上查看时主体清晰。使用蓝色和橙色作为基础色，不要包含文字、logo 或水印。
──────────────────────
落地页主视觉
──────── 复制粘贴 ────────
使用 $imagegen 生成一张在线商业工具落地页的主视觉。制作一张自然照片，画面显示一个小团队在明亮的办公室里看着大屏幕交谈。横向，人物右对齐，左侧留出边距用于标题和按钮。不要包含过于未来主义的表达、文字、公司 logo 或水印。
──────────────────────
带有日文文字的图片
──────── 复制粘贴 ────────
使用 $imagegen 生成一张 X 帖子的方形图片。仅在顶部居中放置文字“AIで仕事が変わる”（AI 改变工作），使用大号、粗体、白色哥特字体。文字排成一行，居中对齐。不要添加任何其他文字、logo 或水印。背景为深蓝色到紫色的渐变，设计沉稳，适合商务用途。
──────────────────────
在图像中放置文字时，遵循以下三点：
- 将要显示的文字用引号括起来。
- 指定字体、颜色、大小和位置。
- 告知不要添加任何其他字符。生成后，发布前检查每个字符。
修正时，写明“要改什么”和“要保留什么”
当第一张图像接近目标时，你不需要从头重写整个提示。事实上，一次性改变太多会改变你喜欢的部分。一次只修正一个元素。
- 保持构图不变，但让背景更亮。
- 保持人物和桌子不变，但将马克杯换成室内植物。
- 保持颜色和光线不变，但加宽右侧边距。
- 保持猫的表情和毛色不变，但让麦克风稍微小一点。
OpenAI 的官方指南也建议在编辑时明确“要改什么”和“要保留什么”。这是一个可用的格式：
──────── 复制粘贴 ────────
请编辑附带的图像。只改变背景。将背景改为浅灰色。保持人物、服装、表情、构图、光线和色调完全不变。不要添加文字或 logo。
──────────────────────
通过写明“只改这个，其他不要动”，可以减少整体图像的飘移。
如果每次都写很麻烦，就固定规则
当从 Claude Code 调用 Codex 时，每次都输入相同的注意事项很麻烦。在这种操作中，建议首先将图像生成规则放在项目的 CLAUDE.md 中。由于 Claude Code 会读取 CLAUDE.md，你可以在这里固定“当被要求创建图像时如何向 Codex 请求”。
如果是在直接使用 Codex 的项目中，将同样的想法放在 AGENTS.md 中。AGENTS.md 是 Codex 端读取的项目规则。
──────── 复制粘贴 ────────
图像生成规则
- 创建照片、插图、横幅、主视觉或社交媒体帖子图片时，使用
$imagegen。 - 如果请求的是栅格图像，不要用 SVG、HTML、CSS 或 Canvas 替代。
- 生成前，整理好目的、主体、风格、构图和约束。
- 仅在向现有 SVG 图标集添加新元素时，才编辑 SVG 以匹配现有格式。
- 将完成的图像保存在项目内，并报告存储位置。
──────────────────────
这条规则的目的不是总是禁止 SVG。而是根据目的选择：UI 组件用 SVG，完成的单张图像用图像生成。
有必要将其做成技能吗？
不需要仅仅为了生成图像而创建新技能。Codex 已经有了 imagegen 技能。当你希望跨多个项目标准化流程时，创建自定义技能才有价值，例如：
- 每次应用品牌颜色或艺术风格。
- 根据目的自动选择构图，例如用于 X、文章或落地页。
- 生成后检查文字、边距、大小和禁止项。
- 统一文件名和保存位置。
- 如果失败，基于相同标准应用修正。
判断很简单：
- 单个项目使用的规则：
CLAUDE.md - Codex 直接遵循的项目规则：
AGENTS.md - 跨多个项目复用“生成 -> 确认 -> 保存”的机制：自定义技能
你不需要一开始就构建技能。从 CLAUDE.md 开始就足够了，当你发现自己重复相同流程三次以上时，再考虑将其做成技能。
SVG 是正确答案的情况
虽然我解释了如何调用图像生成，但 SVG 本身并不坏。SVG 更适合以下用途：
- 向现有 UI 图标集添加新图标。
- 缩放时保持线条清晰。
- 使用 CSS 更改颜色。
- 用数值精确管理形状和线宽。
- 作为代码审查差异。
相反，图像生成适合：
- 照片风格的视觉元素。
- 需要毛皮、布料或金属等纹理的插图。
- 广告或文章的吸引眼球的元素。
- 具有角色或故事性的单张图像。
- 传达氛围或情感的视觉效果。
标准不是“SVG 还是 PNG”。而是“是确定性管理的组件，还是优先考虑表现力的单张图像？” 在向 Codex 请求之前决定这一点，将减少路径不匹配。
本次验证纠正的 3 个误解
最后，这是因为我实际尝试而得以纠正的要点。
误解 1：如果是 PNG，就是用图像生成模型制作的。
这次最初的图像是 PNG，但元数据中包含 SVG 标题和组件。外观也是简单形状的组合，导致判断它是从 SVG 转换为 PNG 的图像。你应该检查的不仅仅是扩展名，而是它通过什么路径创建以及实际外观。
误解 2：添加 `$imagegen` 会提高图像质量。
这次“之后”的外观比“之前”信息丰富得多。然而，我同时指定了麦克风、配色方案、阴影、背景、构图和质量。明确指出图像生成工具可以固定生成路径，但仅凭这一点并不能保证达到你满意的效果。你还需要决定外观的条件以及判断是否适合目的的通过条件。
误解 3：提示越长越好。
“之后”变得更好的原因不是字数增加了。而是因为它包含了决定结果的条件：图像生成工具、禁止 SVG、主体、配色方案、背景、纹理和保存位置。写的是判断所需的条件，而不是长度。
总结
当 Codex 返回简单图像时，首先要怀疑的不是图像生成模型的性能。检查你的意图是否传达清楚：是想要一个用于代码的矢量组件，还是想要一张作为照片或插图的完成的单张图像。
如果你想要单张图像，首先添加这句话：
──────── 复制粘贴 ────────
使用 $imagegen 通过图像生成模型生成栅格图像。不要用 SVG、HTML、CSS 或 Canvas 替代。
──────────────────────
在此基础上，写明目的、主体、风格、构图和约束。
在这个实际测试中，当我只要求 Claude Code 生成一个“简单的猫图标”时，Codex 将其理解为矢量素材需求，并创建了一个基于 SVG 衍生的扁平 PNG。而通过调用 $imagegen 图像生成技能，使用内置的 image_gen 工具，不依赖 SVG 替代，并明确指定主题、配色方案、纹理、背景和质量，就更容易生成符合这些要求的成品插画。
决定图像质量的关键并非提示词的长度。关键在于你是否不仅说明了要造什么，还说明了它的用途以及什么状态才算合格。 当你传达这么多信息后，Codex 就不仅仅是图像生成器，而是一个能根据目的创建和检查图像的生产伙伴。
开始尝试时，在你日常的图像请求中多加一个“用途”和一个“合格条件”。仅此一步，就能让你从“碰运气”的图像生成，迈向“可复现预期结果”的图像生产。
参考资料：
