在 Codex 中使用 GPT Image 2：生成图片、修改参考图与保存文件

Codex 可以直接用 GPT Image 2 生成和修改图片。 在具备该功能的桌面端、CLI 或 IDE 扩展中，用自然语言说明要做什么，也可以在消息里加上 $imagegen，明确调用生图技能。官方说明内置生图使用 gpt-image-2；无需为了这一操作先把对话模型改成图片模型。OpenAI 生图文档提供了各客户端的对应入口。

这篇教程适用于已经能正常使用 Codex、希望拿到封面、插图或项目素材的用户。截至 2026 年 9 月 7 日，Codex 的 Free 方案不提供内置生图；能打开 Codex 或能在 ChatGPT 网页生成图片，都不能单独证明当前 Codex 账户有这项权限。先以自己的方案、工作区和实际提示为准。当前生图额度说明

先完成一张能用的图片

打开要使用的 Codex 任务。如果图片要放进现有项目，先选择对应项目，再说明用途；单独制作图片则直接描述需要的文件。下面是一条可改写后使用的请求，尺寸和保存位置都是你的交付要求：

text
$imagegen 请为一篇介绍家庭咖啡入门的文章生成一张横向封面。
画面主体是窗边木桌上的手冲咖啡器具，采用自然摄影风格，
给文章标题留出清楚的空白区域，图片里不要直接写标题。
目标比例为 16:9。请生成实际图片，完成后展示成图，
把文件复制到当前项目的 public/images/coffee-cover.png，
并告诉我实际像素尺寸和保存位置。

好的请求不需要很长，但要让 Codex 知道这张图将如何使用。“做一张好看的图片”把用途和判断标准都留空；“文章封面、手冲器具、横图、标题留白”就足以帮助它选择主体和构图。你还可以补上品牌颜色、必须出现的产品、需要避开的内容，前提是这些要求确实影响使用。

发送后，等待实际图片结果。如果回复只是构思、提示词或一段生成脚本，任务还没有完成。可以继续说：“请使用当前可用的内置生图工具生成实际图片，并展示生成后的文件；如果工具不可用，请说明当前缺少什么。”这能区分它尚未执行生图，还是当前环境确实没有可用工具。

生成器可能先把文件放在自己的输出目录。让 Codex 将成品复制到你指定的位置，再打开该文件确认能正常显示。请求里写了一个文件名，并不表示那个位置已经出现了图片；需要核对最终返回的位置。若你用的客户端只提供附件下载，就先下载到本地，再放入目标文件夹。

桌面端、CLI 和 IDE 分别怎么操作

三种环境都可以描述图片需求，但参考图的添加方式不同。以下操作对应官方文档的客户端说明，不要把某一种客户端的按钮或快捷键套到另一种。

CLI 用户可以在项目目录中启动会话：

bash
codex

进入后，直接发送上一节那样的生图请求。要带着参考图开始，则可以使用：

bash
codex -i ./reference.png

将 ./reference.png 换成实际存在的文件，随后在交互会话中说明如何修改。路径里有空格时，把路径用引号括起来；--image 是 -i 的长写法。参数随安装版本确认即可：

bash
codex --help

这里使用的是交互会话和图片附件参数，不需要拼出一个 codex image 子命令。-m 或 --model 控制 Codex 对话所用的模型；图片生成由内置工具执行，二者不要混用。需要检查命令参数时，可查看官方 CLI 参考。

改参考图：把“改哪里”和“保留什么”一起说清

修改已有图片时，先把正确的原图附上，再描述变化。只写“换成更高级的风格”，容易让主体、背景和布局一起变化。若任务只是换背景，可以这样说：

text
$imagegen 修改我刚附上的咖啡器具照片：只把背景换成浅米色墙面。
保留器具的数量、外形、摆放位置、拍摄角度和原来的裁切范围。
不要增加文字。请保留原文件，把修改结果另存为 coffee-cover-v2.png，
展示结果并告诉我文件位置。

这些保留要求是在约束修改方向，并不保证生成结果每处都保持不变。收到结果后，按你的用途查看关键主体是否仍可接受；如果还有需要调整的地方，继续指出具体对象和变化，避免每轮同时重写所有条件。

桌面图片查看器中的 Focused view 适合查看单张图片，Canvas view 用来查看同一任务生成的图片。在提供这些功能的版本里，可以通过 Comment 添加具体反馈，或用 Multi-select 选中多张图，再把评论与修改要求一起发送。没有 Canvas 的 CLI 或 IDE 环境，可以继续用图片附件和文字说明。查看与修改图片的官方说明

如果用了多张参考图，说明每张的作用，例如“第一张是要修改的产品图，第二张只参考配色”。这样比笼统地要求“融合两张”更容易表达哪些内容必须留下。交付时保留原图和新版本，便于比较，也方便发现某次修改不合适后回到上一版。

拿到文件之后，还差哪一步

能在对话里看到图片，是交付的一部分。要把它用于网站、文章或设计文件，还应确认实际文件和使用位置。这些是素材处理建议，不能由一句“已经生成成功”代替：

1. 文件确实存在且能打开。 点击返回文件，或从本地文件夹打开；如果只有路径文字而没有文件，让 Codex 检查并重新提供真实文件。
2. 实际尺寸符合用途。 让 Codex 读取像素宽高和格式。请求里的“16:9”“4K”是目标，不是最终文件属性；需要精确尺寸时，另存一份适配版本，并说明是否经过缩放或裁切。
3. 项目引用指向这份素材。 网页需要使用项目里的图片路径，不能仅依赖生成器输出目录。可以继续要求 Codex 放到正确目录、替换对应引用，并在页面中打开查看。

例如，接续前面的咖啡封面任务，可以发送：

text
请检查刚才生成的文件是否存在、能否解码，报告实际格式、像素宽高和文件大小。
保留原图，将适合网页使用的副本放到本项目的图片目录，
告诉我页面应该引用哪个路径。如果做了缩放、裁切或格式转换，请说明。

对于网站，图片里画出的按钮和表单仍然只是像素。要让按钮能点击、表单能输入，需要继续实现页面代码；封面和插图则通常只需要正确引入素材。把这两种任务说清楚，可以避免拿到一张界面图片后，误以为页面功能也已经完成。

生图用什么额度，为什么会提示 API 密钥

内置生图与一般 Codex 任务共用使用额度。官方给出的比较是：在质量和尺寸等因素影响下，带生图的任务消耗包含额度的速度，平均约为类似非生图任务的 3–5 倍。它不是“每张图扣 3–5 条消息”，也不能据此换算出某个方案每天固定生成多少张。官方消耗说明

查看自己还剩多少额度、什么时候重置，应打开 Codex 使用量页面。CLI 用户可以在当前交互会话中输入 /status。如果额度已经用完，根据页面显示的重置时间或当前可用的 credits 选项处理，不要靠反复发送同一请求判断能否恢复。当前限额的查看方式

要求设置 OPENAI_API_KEY，通常意味着当前建议涉及 API 调用。 官方也把较大批量的 API 生图单独列出，使用 API 价格计费；这与消耗 Codex 包含额度的内置生图有所区别。先让 Codex 说明准备调用内置工具还是运行 API 脚本，以及为什么需要密钥，再决定是否采用。不要因为普通生图请求没有成功，就默认必须改走 API。

如果确实需要把图片生成接进自己的程序，可转到 GPT Image 2 API 使用方式；如果主要关心不同产品里的限额差别，可查看 GPT Image 2 使用限制。这两项是完成当前单张图片任务之后的独立选择。

遇到问题时，先分清停在哪一步

如果确认账户与客户端条件后仍无法生成，保留完整错误文本、客户端版本、登录方式和发生时间，以便进一步排查。重新措辞可以澄清任务，却不能恢复被限额或权限阻止的功能。先让当前环境完成一张图片并拿到文件，再扩展到更多素材，后续的修改、保存与复用就有了明确起点。