你的第一张图
从一句话到一张能用的图,中间只隔着四步。这一章照做即可:把需求说清楚、让它出图、用五条标准检查、再把成品妥善落地——并把"画好的图到底存到了哪儿"彻底讲明白。
上一章我们认清了这支画笔——两种模式、意图与执行。这一章把它真正握在手里:走通一条最短、最稳的生成流程,从一句中文需求到一个躺在工作区里、随时可用的 PNG。新手照着做就能成。
全程我们都待在内置 image_gen 里:不需要 API Key,不需要命令行,对话框里一句话即可。请记住一个基调——慢一点、稳一点:先把话说清楚,再出图;先看清楚,再落地。
四步最小流程:说清楚 → 出图 → 看 → 落地
无论需求大小,第一张图的骨架都是这四步。把它们当成肌肉记忆,后面再复杂的活,也不过是这条主干的展开。
-
说清楚 · 把需求整理成一份 spec
不要只丢一句"画个杯子"。在心里(或写下来)把它结构化:用途、主体、风格、构图、光线、配色。话说清一半,图就成了一半。下一节的配方卡,就是这份 spec 的现成模板。
-
出图 · 发一次内置 image_gen 调用
把整理好的提示词交给内置工具,一次调用出一张图。默认就是新图(generate),除非你明显是在改一张已有的图。先别纠结尺寸像素,先把主体和气质做对。
-
看 · 用五条标准校验
图出来了,不等于做完了。逐项过一遍:主体对不对、风格对不对、构图对不对、文字准不准、该保留的有没有被破坏。第 5 节会展开这五条。
-
落地 · 决定预览还是搬进工作区
只是看看?留在默认路径、内联预览即可。项目要用?move/copy 进工作区再收尾。这一步决定了你交付的,到底是"一张图"还是"一句空话"。
一个完整示例:陶瓷马克杯的 landing hero
空谈无益,我们走一遍真实的活:为一个手工陶瓷品牌的落地页,做一张主视觉(hero)产品图。先把需求落成一张配方卡——它的字段就是上一章提到的 shared prompt schema,逐项填好,提示词自然水到渠成。
陶瓷马克杯 · Landing Hero 产品图
注意 Asset type 和 Scene · backdrop 是给你梳理思路的脚手架字段,不是 CLI 的命令行标志;Scene/backdrop 也不等于 CLI 的 background 参数。这里同样没有用到 quality、size 这类只属于 CLI 的东西——我们全程在内置模式,把心思放在"画面本身"上即可。
把这份配方卡转成实际发给内置工具的一句话,就是下面这张提示词卡。注意它不是字段的机械堆砌,而是顺成一段可执行的描述:
这句话发出去,内置工具会生成一张图并内联展示给你看。先别急着用——它现在还躺在默认路径里。下面两节,就来解决"看了之后怎么办"。
预览,还是落地?
每生成一张图,你都要做一个二选一的判断:这张图是只给你看一眼的草稿,还是项目真要用的资产?两者的处理截然不同。
只是预览 / 头脑风暴
内联看就好。文件留在默认路径无妨,不必搬动。这一档适合比稿、试风格、找感觉——你只是想"看一眼对不对"。
项目 / 发布要用
必须 move/copy 进工作区再收尾。落地页、文章配图、要交付的物料都属于这一档。只留在默认路径 = 没交付。
我们这只马克杯是要进落地页的,显然属于右边。把这条判断画成一张流程图,它就是你每次出图后,脑中该走的那条线:
保存路径策略:默认在哪、该往哪搬
内置工具不会问你"存哪儿",它有一套默认行为。把这套行为搞清楚,你才不会把图弄丢,或把该交付的资产忘在角落。
| 情形 | 该怎么做 |
|---|---|
| 默认落点 | 内置生成的图默认存到 $CODEX_HOME/generated_images/...。不要把系统临时目录当默认,也不要依赖内置工具的"目标路径参数"一步到位——稳妥做法是先生成,再 move/copy。 |
| 用户指定了目标 | 生成后 move/copy 到用户给的位置。 |
| 项目要用 | 收尾前把成品 move/copy 进工作区(如项目的 assets/ 目录)。 |
| 仅预览 | 内联展示即可,文件可以留在默认路径。 |
其一:绝不把"项目要用的资产"只留在 $CODEX_HOME。那个目录是内置工具的"暂存抽屉",不是你的项目。图再好,没搬进工作区,对交付而言就等于不存在。
其二:绝不覆盖已有资产(除非用户明确要求替换)。需要新一版,就用版本化的兄弟文件名——例如已有 hero.png,新版另存为 hero-v2.png;编辑过的图存成 item-icon-edited.png。宁可多一个文件,也别毁掉旧的。
把马克杯这张图落地,动作就这么朴素:先让内置工具出图(落在默认路径),确认满意后,把它复制进项目的资源目录,并给一个稳定、有描述性的文件名。如果你愿意用命令行收尾,大致是下面这样——注意这只是文件搬运,不是切到 CLI 出图:
校验与迭代:每次只改一处
图出来了,进入第三步"看"。新手最常见的错误,是看一眼"还行"就用了,或者一次把提示词改得面目全非。正确做法是逐条校验、单点迭代。
每张图都过这五条标准:
- 主体——画的是不是你要的那个东西?(一只陶瓷马克杯,不是玻璃杯、不是两只)
- 风格——气质对吗?(写实产品摄影,而非插画或 3D 渲染)
- 构图——取景、留白、主体位置对吗?(杯子在左、右侧留白够不够干净)
- 文字准确——若有要逐字渲染的文案,一个字母都不能错(本例不放文字,这条天然通过)
- 不变量与避免项——该保留的有没有保住、该避免的有没有混进来?(有没有冒出水印、杂乱道具、刺眼高光)
如果某一条不达标,每次只改一个变量,然后重新校验。右侧留白不够干净 → 只调"留白"那一句,别顺手把光线、配色、构图一起动。一次只动一处,你才说得清"是哪句话起了作用";一次改五处,等于把迭代变成了重新抽奖。
举例:第一版若右侧留白被背景道具占满,你不必重写整段提示词,只需把"右侧留出大面积干净留白"说得更硬——比如强调"右侧约 40% 区域保持空净,仅有柔和背景虚化"——其余原样不动,再发一次。这就是一次干净的迭代。
收尾汇报三件套
一张图真正"做完"的标志,不是图出来了,而是你能清清楚楚交代三件事。养成习惯,每次收尾都把它们说全:
图最后落在哪里(如 ./assets/mug-hero.png)
真正生成它的那句完整描述
本例:内置 image_gen
为什么这三件套重要?路径让协作者找得到资产;提示词让这张图可复现、可微调;模式让人一眼知道它是怎么来的、要不要 API Key、能不能照样再来一张。三句话,把一次性的"出了张图",变成可追溯、可复用的工程产物。
说清楚(spec)→ 出图(一次内置调用)→ 看(五条标准)→ 落地(预览内联 / 项目搬进工作区)→ 汇报(路径 + 提示词 + 模式)。第一张图照此走通,后面所有复杂场景,都只是这条主干的展开。
第一张图只需四步:说清楚 → 出图 → 看 → 落地。先把需求填成一张配方卡(shared prompt schema),用一次内置 image_gen 调用出图;图默认存到 $CODEX_HOME/generated_images,仅预览可留在那儿、项目要用就 move/copy 进工作区——绝不只留默认路径,也绝不覆盖已有资产(改用 hero-v2.png 这样的版本化兄弟名)。校验过主体 / 风格 / 构图 / 文字 / 不变量,每次只改一处再复检。收尾报全三件套:最终路径 + 最终提示词 + 用了哪种模式。