Codex生成可编辑PSD：提示词工程与图层契约实战

1. 为什么“让 Codex 生成 PSD”这件事值得单独聊

先把结论摆在前面：让 Codex 直接吐出一个能用的 PSD，本身不难，难的是很多人把提示词写成了“许愿池”，指望一句话就换来一个分层清晰、命名规范、还能继续编辑的工程文件。我前后试过几十次，从最开始只能拿到一张扁平图，到后来能稳定产出带图层组、带蒙版、带文字层的 PSD，中间踩的坑基本都集中在提示词结构和输出约束上，而不是模型能力本身。

这里说的 Codex，指的是那类能读写文件、能执行脚本的编程智能体形态。它和纯聊天式模型最大的区别在于：它不只是“说”，它还能“做”——能写 Python、能调库、能在你的机器上跑出一条完整的生成链路。PSD 这种格式恰好是“说”不出来的，你没法用自然语言直接描述二进制结构，但你可以让 Codex 写一段用psd-tools、pytoshop或者直接调 Photoshop 脚本的代码，把图层一层层搭出来。所以整件事的本质是：提示词负责描述结构，Codex 负责把结构翻译成代码，代码负责把代码翻译成 PSD。

这套流程适合谁？一是做设计自动化的人，比如要批量产出电商主图、学术海报、社媒配图的；二是做 AI 工作流的人，想把文生图的结果进一步拆成可编辑分层文件的；三是单纯想搞明白“提示词工程在文件生成场景下到底怎么落地”的开发者。哪怕你之前没碰过 PSD 的二进制结构，只要提示词写对了，Codex 能帮你把大部分脏活干掉。

我先把最容易翻车的地方点出来：绝大多数人失败，不是因为模型不会写代码，而是因为提示词里没有定义“图层契约”。你只说“生成一个海报 PSD”，Codex 只能猜；你如果说“生成一个 1080x1440 的 PSD，包含背景层、主标题文字层、副标题文字层、产品图占位层、装饰元素组，每层命名用英文下划线，文字层保留可编辑属性”，它就能给你一个像样的东西。差别就在这。

2. 提示词到底该怎么写：从“许愿”到“契约”

2.1 先搞清楚 Codex 拿到提示词后会发生什么

很多人写提示词是站在“跟人说话”的角度，但 Codex 拿到提示词后，实际执行路径是这样的：先解析你的意图，判断这件事能不能用代码实现；然后选择技术路线，比如是用psd-tools从零构建，还是先合成一张图再反向分层；接着写脚本、装依赖、跑脚本；最后检查产物是否存在、尺寸对不对。你写的每一个模糊词，都会在这个链条里被放大成一次猜测，而猜测越多，产物越偏离预期。

所以提示词的第一原则是：把“我要什么”翻译成“代码能验证什么”。“好看”没法验证，“1080x1440、RGB、72dpi”可以验证；“分层清晰”没法验证，“图层数量为 6、命名匹配正则^[a-z_]+$”可以验证。你不需要懂 PSD 格式，但你需要懂“可验证”这件事。

我自己的习惯是，提示词里永远包含三块：产物规格、图层结构、验收标准。产物规格管尺寸、色彩模式、位深；图层结构管有哪些层、什么类型、什么顺序；验收标准管跑完之后怎么判断成功。这三块写全了，Codex 的产出稳定性会有肉眼可见的提升。

2.2 一个能直接抄的提示词骨架

下面这个骨架我用了很多次，改改参数就能复用。注意它不是让你一次性全填满，而是给你一个结构参考：

任务：生成一个 PSD 文件 产物规格： - 画布尺寸：1080 x 1440 px - 色彩模式：RGB - 位深：8 bit - 分辨率：72 dpi - 输出路径：./output/poster.psd 图层结构（从下到上）： 1. 背景层，命名 background，纯色填充 #0F172A 2. 装饰组，命名 decor_group，包含 3 个矩形形状层 3. 主视觉占位层，命名 hero_placeholder，尺寸 800x600，居中 4. 主标题文字层，命名 title_text，内容 "YOUR TITLE"，字号 96，颜色 #FFFFFF 5. 副标题文字层，命名 subtitle_text，内容 "subtitle here"，字号 36，颜色 #94A3B8 技术要求： - 使用 Python 的 psd-tools 或 pytoshop 库 - 文字层必须保留可编辑属性，不要栅格化 - 每个图层必须有明确的 name 属性 - 脚本执行完成后打印图层清单 验收标准： - 文件存在且大小大于 10KB - 用 psd-tools 打开后图层数量等于 5 - 图层名称与上述命名完全一致

这个骨架的关键在于最后那段“验收标准”。它逼着 Codex 在生成之后自己验证一遍，而不是写完脚本就交差。我实测下来，加了验收标准的任务，返工率能降一半以上。

2.3 为什么“分层”比“生成”更难

这里要展开讲一个很多人忽略的点：生成一张图很容易，生成一个分层结构很难。因为图像生成模型输出的是像素，而 PSD 的核心价值在于“结构”。你要的不是一张好看的图，而是一个能继续编辑的工程文件。这两件事在技术上是两条路。

Codex 处理这件事有两条常见路线。第一条是“从零构建”，直接用psd-tools创建图层、设置属性、写入文件。这条路可控性最高，但要求提示词把结构描述得非常细。第二条是“先合成再拆分”，先用文生图产出一张底图，再用分割或抠图把元素拆成图层。这条路视觉效果好，但分层质量取决于分割精度，而且文字层基本没法保留可编辑性。

我的建议是：如果你的核心诉求是“可编辑”，走第一条路；如果核心诉求是“好看”，走第二条路，但别指望文字能编辑。提示词里要明确告诉 Codex 走哪条路，否则它会自己选，而它选的那条未必是你想要的。我见过太多人抱怨“生成的 PSD 打开只有一层”，一问提示词，压根没提分层要求，Codex 自然就给你一张扁平图。

3. 实操全流程：从零跑通一个可编辑 PSD

3.1 环境准备与依赖选择

先解决环境问题。Codex 要跑 Python 脚本，你本地得有 Python 环境，建议 3.9 以上。核心依赖是psd-tools，它读取和写入都支持，虽然写入能力不如读取那么完善，但应付基础图层结构足够了。如果你需要更底层的控制，可以上pytoshop，它更接近 PSD 的原始结构，但 API 没那么友好。

安装命令很简单：

pip install psd-tools pillow

如果你打算走“先合成再拆分”的路线，还得加上图像处理相关的库，比如opencv-python、rembg之类。但我不建议一上来就搞那么复杂，先把最基础的“从零构建分层 PSD”跑通，再考虑加视觉元素。

这里有个坑要提前说：psd-tools在写入文字层时的支持是有限的。它能把文字层写进去，但字体、行距这些属性的保留程度取决于版本。如果你对文字排版要求很高，可能得考虑用 Photoshop 的脚本接口，或者干脆用pytoshop手动构造文字层描述。我个人的经验是，先用psd-tools把结构跑通，文字层能保留内容就行，精细排版后期在 PS 里调。别一上来就追求完美，那样容易卡在细节里出不来。

3.2 提示词里必须写死的几个参数

在真正让 Codex 动手之前，提示词里有几个参数我建议你写死，不要留给它猜：

这张表里的每一项，我都因为没写而翻过车。最典型的一次是没写色彩模式，Codex 默认给了 RGB，结果拿去印刷颜色完全不对，返工重做。还有一次没写图层命名规则，生成出来一堆Layer 1、Layer 2，后期想批量处理根本没法下手。

3.3 完整实操：让 Codex 生成一个海报 PSD

现在把前面的东西串起来，走一遍完整流程。假设我要生成一个学术海报的 PSD 模板，尺寸 A4 竖版，300 dpi，CMYK 模式，包含标题、作者、正文占位、图表占位、页脚几个区域。

第一步，把提示词写清楚。我会这样组织：

任务：生成一个学术海报 PSD 模板 产物规格： - 画布：2480 x 3508 px（A4 300dpi） - 色彩模式：CMYK - 位深：8 bit - 分辨率：300 dpi - 输出：./output/academic_poster.psd 图层结构（从下到上）： 1. background，纯白填充 2. header_block，矩形形状层，高度 400px，填充 #1E3A8A 3. title_text，文字层，内容 "PAPER TITLE"，字号 120，颜色 #FFFFFF，位于 header 内 4. author_text，文字层，内容 "Author Name, Affiliation"，字号 48，颜色 #E2E8F0 5. body_placeholder，矩形形状层，填充 #F1F5F9，用于正文 6. figure_placeholder，矩形形状层，填充 #E2E8F0，用于图表 7. footer_text，文字层，内容 "Conference Name 2025"，字号 36，颜色 #64748B 技术要求： - 使用 psd-tools 构建 - 文字层不栅格化 - 所有图层命名严格按上述英文名 - 脚本末尾打印图层树 验收标准： - 文件存在，大小 > 50KB - 图层数量为 7 - 用 psd-tools 读取后，每个图层的 name 与预期一致 - 画布尺寸和色彩模式与规格一致

第二步，把这段提示词交给 Codex，让它生成脚本并执行。正常情况下，它会写出一段类似这样的代码：

from psd_tools import PSDImage from psd_tools.api.layers import PixelLayer, ShapeLayer, TypeLayer # 创建画布 psd = PSDImage.new(mode='CMYK', size=(2480, 3508), depth=8) # 背景层 bg = PixelLayer.frompil(Image.new('CMYK', (2480, 3508), (0, 0, 0, 0)), psd, name='background') psd.append(bg) # 后续图层依次 append # ... psd.save('./output/academic_poster.psd')

实际代码会比这个长很多，因为要处理每个图层的定位、填充、文字属性。但核心逻辑就是这样：创建画布、逐层追加、保存文件。Codex 的价值在于它能把每个图层的属性都填对，你只需要在提示词里把结构描述清楚。

第三步，跑完之后验证。我会让 Codex 自己跑一段验证脚本：

from psd_tools import PSDImage psd = PSDImage.open('./output/academic_poster.psd') print('size:', psd.size) print('mode:', psd.color_mode) for layer in psd: print(layer.name, layer.kind, layer.bbox)

如果输出的图层清单和提示词里的结构对得上，这事就成了。对不上，就把差异点补进提示词，再跑一遍。通常两三轮之内就能收敛。

3.4 文字层保留可编辑属性的关键操作

这里单独拎出来讲，因为文字层是翻车重灾区。psd-tools写文字层时，如果你只是塞一个字符串进去，它可能给你生成一个栅格化的像素层，打开 PS 一看就是一张图，没法改字。要保留可编辑属性，提示词里必须明确要求“使用 TypeLayer”或者“保留文字引擎数据”。

我实测下来，比较稳的做法是让 Codex 用psd-tools的TypeLayer接口，并且在提示词里加一句：“文字层必须包含 engine_dict 数据，确保在 Photoshop 中可编辑。” 这句话看起来技术性很强，但它确实能引导 Codex 走正确的代码路径。如果不加，它很可能图省事直接给你栅格化。

还有一个细节：字体。PSD 里的文字层会记录字体名称，如果你指定的字体本地没有，PS 打开时会提示替换。提示词里最好写一个通用字体，比如 Arial 或 Helvetica，别写太冷门的。我试过写“思源黑体”，结果 Codex 生成的 PSD 在没装这个字体的机器上打开全是替换提示，体验很差。

4. 常见问题与排查技巧实录

4.1 生成的 PSD 打开只有一层怎么办

这是最高频的问题。原因基本只有一个：提示词里没有明确要求分层，或者要求了但不够具体。Codex 在不确定的时候，倾向于走最简单的路径——生成一张扁平图然后包成 PSD。解决办法是把图层结构写成有序列表，每一层都给出名称、类型、内容、位置。越具体越好。

如果已经写得很具体了还是只有一层，那可能是库的限制。psd-tools在某些版本下写入多层时会有兼容问题，建议升级到最新版，或者换pytoshop试试。我遇到过psd-tools1.9.x 写入多层后 PS 打不开的情况，升到 1.9.24 之后就好了。

4.2 文字层变成图片了怎么救

前面提过，核心是提示词里明确“不栅格化”和“使用 TypeLayer”。如果已经生成了栅格化的版本，没法直接救回来，只能重新生成。所以这事重在预防，别等出了问题再想办法。

另外，即使提示词写对了，不同版本的psd-tools对文字层的支持也不一样。我建议在验收标准里加一条：“用 psd-tools 读取时，文字层的 kind 应为 type。” 这样跑完就能立刻发现是不是被栅格化了。

4.3 文件打不开或提示损坏

这种情况通常是写入过程中出了问题，比如图层数据不完整、色彩模式不匹配、或者文件头写错了。排查思路是：先用psd-tools自己读一遍，看能不能正常打开。如果psd-tools能读但 PS 打不开，那多半是兼容性问题，试试降低位深或者换 RGB 模式。如果psd-tools也读不了，那就是写入逻辑有 bug，让 Codex 检查脚本里的 save 部分。

我踩过的一个坑是：CMYK 模式下某些图层属性写得不完整，导致 PS 报错。后来改成先 RGB 生成，再用 PS 转 CMYK，反而更稳。所以如果你不是非要一步到位，可以分两步走。

4.4 图层位置全乱了怎么调

位置问题通常是因为提示词里没给坐标。Codex 不知道你要把标题放哪，就只能猜。解决办法是在图层结构里加上位置描述，比如“title_text 位于画布顶部居中，距顶边 200px”。有了这个约束，Codex 就能算出正确的 bbox。

如果已经生成了但位置不对，不用重新生成整个文件，可以让 Codex 写一段脚本单独调整某个图层的 bbox，然后保存。这样比重跑一遍快得多。

4.5 常见问题速查表

这张表里的每一条，都是我实际遇到过的。你可以把它当成一个排查清单，出问题的时候对着看，基本能定位到原因。

5. 进阶玩法：把 PSD 生成接入更大的工作流

5.1 批量生成：一次产出多个变体

单次生成跑通之后，下一步自然是批量。思路很简单：把提示词里的可变部分抽成参数，让 Codex 写一个循环，每次改参数、生成一个 PSD。比如做电商主图，你可以准备一个 CSV，里面是不同产品的标题、副标题、价格，然后让 Codex 读 CSV、循环生成。

这里的关键是把提示词模板化。你可以写一个prompt_template.txt，里面用占位符标记可变部分，然后让 Codex 读模板、替换占位符、执行生成。这样你改需求只需要改模板，不用每次重写提示词。

批量生成时要注意文件命名和输出目录的管理，否则跑完一堆文件混在一起，找都找不到。我一般让 Codex 按{产品ID}_{日期}.psd的规则命名，输出到按日期分的子目录里。

5.2 与文生图结合：先出图再分层

如果你需要视觉丰富的 PSD，纯代码构建的图层会显得很“素”。这时候可以结合文生图：先用图像模型生成一张底图，再让 Codex 写脚本把底图导入 PSD 作为背景层，然后在上面叠加文字层和形状层。这样既有视觉冲击力，又保留了关键元素的可编辑性。

提示词里要写清楚：“背景层使用 ./assets/bg.png，其余图层用代码构建。” Codex 会处理好图片导入和图层叠加的逻辑。注意图片的分辨率要和画布匹配，否则会被拉伸变形。

5.3 反向操作：把现有 PSD 拆解成提示词

这个玩法比较有意思：你手里有一个设计好的 PSD，想让 Codex 学会它的结构，以后按类似结构生成。做法是让 Codex 写脚本读取这个 PSD，输出图层树、每个图层的属性、文字内容，然后你把这些信息整理成提示词模板。相当于用现有文件“教”Codex 你的设计规范。

我试过用这个方法把一个学术海报模板拆成提示词，之后生成同系列的海报就非常快，结构完全一致，只需要改文字内容。这比每次从零描述结构高效得多。

6. 我个人的几条实操心得

第一，提示词里的验收标准比生成指令更重要。很多人把精力全花在描述“我要什么”上，却忘了描述“怎么算成功”。加上验收标准之后，Codex 会自己检查一遍，很多低级错误在交付前就被它自己修掉了。

第二，别追求一次完美。我现在的习惯是先跑一个最小可用的版本，确认分层结构对了，再逐步加细节。一上来就写一个几百行的提示词，反而容易因为某个细节没写对导致整体失败，排查起来也痛苦。

第三，图层命名一定要规范。这不是洁癖，是实用需求。后期你要批量改文字、批量换图，全靠图层名称来定位。命名乱了，脚本就没法写。我一般用全小写加下划线，语义清晰，比如title_text、hero_image、footer_logo。

第四，文字层能少则少。每多一个文字层，就多一份字体兼容风险。如果某些文字不需要编辑，直接栅格化反而更稳。只有真正需要后期改的内容，才保留为文字层。

第五，保存中间产物。让 Codex 在生成 PSD 的同时，也输出一份图层结构的 JSON。这样即使 PSD 出了问题，你还能从 JSON 里恢复结构信息，不用重新分析。

这套流程我跑了小半年，从最开始十次有八次翻车，到现在基本两三次就能出一个能用的文件。核心变化不是模型变强了，而是提示词从“许愿”变成了“契约”。你把结构描述清楚，把验收标准写明白，Codex 就能稳定地把你的意图翻译成可编辑的 PSD。这件事的门槛不在技术，在于你愿不愿意花十分钟把需求写清楚。