企业官网建设流程全解析

Codex + Cowart 这套流程，表面看是“用 AI 批量生成商品图”，实际拆开是三段独立任务：Codex 负责生成脚本、整理提示词和调用接口，Cowart 负责画布编排和批量结果对比，真正的生图模型负责出图。如果只让 Codex 写一句提示词然后丢给图片接口，等于没用到画布工具的管理能力；如果只在 Cowart 里手动拖节点，又处理不了几十上百个商品 SKU 的批量命名和重跑。把两者串起来之后，才能做到一次定义风格，批量产出统一风格商品图。这篇文章按我实际跑的流程拆一遍，重点讲环境配置、批量参数、结果验收和报错排查，适合正在做电商商品图、详情页配图、社媒素材的运营、设计和技术同学参考。

1. 先把流程拆清：Codex、Cowart、图像模型各管哪一段

1.1 为什么不是“让 Codex 直接生成商品图”

Codex 本质上是一个命令行 AI 编程助手，处理的是文本、代码、文件，不负责像素渲染。它能帮你写 Python 脚本、整理提示词模板、读取商品表格、调用图像生成接口、保存返回图片、统一命名，但这些事的终点还是“调用其他图像模型”。如果有人说“用 Codex 生成商品图”，更准确的说法是：用 Codex 把生成商品图的整套流程自动化。

这个区别非常重要，因为排错思路完全不一样。出图效果差，先查图像模型和提示词；任务没跑完，先查 Codex 写的脚本、API 地址和参数；图保存不了，先查返回值格式和文件写入方式。如果你一开始就以为 Codex 能直接出图，后面遇到问题会根本不知道从哪里下手。

一个最小例子是：先让 Codex 读商品表，再生成提示词文件。这不是“生成商品图”，但却是整条流水线的起点。

请读取 products.csv，每个商品输出一行提示词，要求固定场景、光线、构图，只替换产品名称和卖点，输出到 prompts.json。

Codex 最适合干这类重复、可靠、可校验的活。真正图像生成，建议交给平台上的专用图像模型，不要拿代码模型硬凑。

1.2 Cowart 在流程里解决什么问题

Cowart 这类无限画布工具，最大的价值不是“画”，而是把整个生图流程摊开来看。普通工具一个输入框只能做单张生成，画布上可以同时放风格参考图、产品原图、提示词模板、输出预览区，还能把上一批结果拖回参考区继续迭代。它解决的核心问题，是“统一风格商品图”里的“统一”二字。

实际做商品图时，最难的不是生成一张好看的图，而是让二十张、五十张图看起来来自同一套拍摄方案。参考图放聊天记录里会被刷走，提示词散在各处会越改越乱。用画布把视觉资产固定下来，等于给整条批量流程一个稳定的工作台。

不过要提醒一句：画布只负责组织和预览，不负责模型推理。最终结果是否稳定，仍然取决于后端图像模型的支持情况、尺寸参数、提示词模板和批量脚本。不要因为画布看起来专业，就忽略接口侧的配置。

1.3 API 平台兼容到底指什么

“兼容所有 API 平台”这个说法太绝对，更稳妥的理解是“兼容 OpenAI 兼容接口的平台”。现在大多数模型服务商都提供 OpenAI 风格的 base_url、密钥和模型名，Codex 接入第三方模型的基础也是这一点：给它一个可访问的服务地址，再指定一个当前平台支持、且适合任务的模型。

具体到商品图流程，至少分两种兼容：

• 调用 Codex 的模型兼容：需要一个能处理代码生成和文本推理的模型。
• 调用生图接口的模型兼容：需要一个能处理文生图任务的专用图像模型。

不要以为同一把 API Key 就能用一个模型做所有事情。有些平台提供代码模型，有些提供图像模型，有些兼而有之。实际配置时，要把 Codex 用的模型和生图接口用的模型分开填。比如 Codex 接入 DeepSeek 这类提供 OpenAI 兼容接口的服务商时，要看平台文档里有哪些模型名、是否支持 Codex 默认的 responses 端点；而生图任务，还要单独确认图像模型的 size、n、quality 参数。

如果平台只支持 chat/completions 这种文本端点，不支持 responses 端点，Codex 调用时就可能报端点错误。这个差异不是“平台不行”，而是协议兼容程度不同。落地时先看文档，再写配置，能省掉大量试错时间。

2. 环境准备：Codex 安装、接入配置与命令验证

2.1 安装 Codex CLI 并确认 PATH

先装 Codex CLI，再谈自动化。安装方式主要有两种：

• 用 npm 安装：npm install -g @openai/codex
• 从官方发布渠道下载安装包，按系统提示安装

安装完成后的第一件事，不是马上写提示词，而是在终端验证：

codex --version

如果能正常输出版本号，说明 CLI 已经在 PATH 里。如果提示command not found，优先检查 PATH 是否包含 npm 全局安装目录。macOS 上常见路径是/usr/local/bin或/opt/homebrew/bin，Windows 上常见路径是%APPDATA%\npm。

这一步值得多花几分钟。因为后面所有批量脚本、文件操作和 API 调用都依赖 CLI 能正常启动。如果 Codex 桌面端报“unable to locate the codex cli binary”，本质就是应用找不到 codex 可执行文件。解决方向有两个：一是安装 CLI 并保证 PATH 正确；二是设置CODEX_CLI_PATH指向 codex 二进制所在路径。这个报错通常和模型能力无关，先别急着换模型。

2.2 配置 OpenAI 兼容接口与第三方模型

CLI 启动后，需要让 Codex 知道自己调用哪个模型服务。如果使用官方接口，设置环境变量即可：

export OPENAI_API_KEY="你的密钥"

如果走 OpenAI 兼容接口，一般需要在 Codex 配置里增加一个自定义 provider。不同版本字段略有差异，下面的配置只作为参考：

model = "模型名" model_provider = "custom" [model_providers.custom] name = "Custom OpenAI Compatible" base_url = "https://api.example.com/v1" env_key = "THIRD_PARTY_API_KEY"

配置时注意三点：

• 模型名必须真实存在于目标平台，否则会报 model not supported。
• base_url 是否需要带/v1，要看服务商文档。
• 有些平台要求指定 wire_api 为 responses 或 chat，Codex 新版默认走 responses 接口，但部分第三方平台只支持 chat/completions。这个差异是报错高发区。

接入第三方模型服务商的正确步骤是：先看平台文档，把可用的模型名、端点地址、认证方式抄下来，再填进配置。不要靠猜。

2.3 用一条最小任务验证 Codex

配置完成后，建议用一个最小的任务先测：

codex "输出 hello codex，并告诉我当前目录完整路径"

这个任务包含两件事：一是 Codex 能否正常返回文字，二是它能否理解并执行环境信息。如果这一步卡住，不要急着继续。先确认密钥、模型名、base_url 三项是否都正确。

还可以再测一个文件操作：

codex "在当前目录生成一个 test.txt，内容写入 hello"

跑通之后，说明 Codex 的代码生成、文件读写能力都正常。这比一上来就让它跑上百张图的批量任务要稳得多。

3. 先定风格再批量：在 Cowart 画布上搭商品图工作区

3.1 统一风格的本质是固定视觉基线

商品图最怕“一张一个风格”。产品是同一个，第一张暖白光，第二张冷灰背景，第三张又变成多角度 3D 渲染，用户一看就知道不是一套图。“统一风格”的关键，是先定视觉基线，而不是靠每次现场发挥。

我一般会先建一个style_baseline文件夹，收集 5 到 8 张目标风格参考图。参考图里要覆盖背景色、光影方向、构图比例、材质表现、产品摆放角度等信息。随后在 Cowart 画布上把这三样东西放上去：风格参考图、产品原图、输出预览图。每次改模板时，都对照画布左侧的参考图，不看参考图直接改提示词，很容易越改越偏。

视觉基线的本质，是把“好看”翻译成可复用的参数。比如：

• 背景：浅灰渐变，底部轻微阴影。
• 光线：柔光箱主光，左前侧辅光。
• 构图：产品居中，占画面 60%，顶部留白 25%。
• 镜头：50mm，F8，平视角度，商品摄影风格。

这些描述越具体，批量结果越稳定。

3.2 画布布局：参考图区、提示词区、输出区怎么排

无限画布不是用来画无限角落的，而是方便你把流程固定成“可复用布局”。建议这样排：

• 左侧放风格参考图和产品原图，固定不动。
• 中间放提示词模板，每个商品一个节点。
• 右侧放生成结果预览，并把每批结果直接回贴到画布。

这样安排的原因很直接：批量生成通常不是一次成功，需要反复调整。如果每次调整都在聊天窗口或单张生成页面里，根本看不出批次之间的差异。画布上把上一轮和下一轮并排放在一起，哪里偏色、哪里构图变了，一眼就能看出来。

如果你用的画布工具不是 Cowart，只要保留“参考图区、提示词区、输出区”三个模块，同样能复现这套流程。工具本身不是重点，稳定的工作区布局才是。

3.3 提示词模板怎么写才能批量复用

统一风格的根在提示词模板。我给商品类生图任务常用这个结构：

产品主体：{product_name} 产品描述：{product_desc} 场景：纯色背景，浅灰渐变，底部轻微阴影 光线：柔光箱主光，左前侧辅光，高光集中在产品正面 构图：产品居中，占画面 60%，顶部留白 25% 镜头：50mm，F8，平视角度，商品摄影风格 风格参考：参考图中浅灰背景与磨砂质感，不使用文字水印 负面提示：文字、水印、透视畸变、多人、杂乱背景

模板里的变量越少，稳定性越好。如果产品本身差异很大，只替换产品名称和描述，固定场景、光线、镜头和风格参考。变量一多，模型就会开始自由发挥，结果很难控制。

另外，产品原图的质量也会直接影响结果。如果原图背景很乱、光线很暗、角度歪斜，提示词再怎么强调统一，图像模型也很难凭空修正。批量前先把产品图清理一遍，比批量后修一百张图更省时间。

3.4 用 Codex 把商品表变成批量提示词 JSON

这里才体现 Codex 的真正价值。比如你有一张商品表，列是商品 ID、产品名称、卖点、输出文件名。可以让 Codex 写一个脚本，读取表格，套用提示词模板，生成 JSON 文件供生图接口调用。

import csv, json rows = list(csv.DictReader(open("products.csv", encoding="utf-8"))) prompts = [] for r in rows: prompt = f""" 产品主体：{r['产品名称']} 产品描述：{r['卖点']} 场景：纯色背景，浅灰渐变，底部轻微阴影 光线：柔光箱主光，左前侧辅光，高光集中在产品正面 构图：产品居中，占画面 60%，顶部留白 25% 镜头：50mm，F8，平视角度，商品摄影风格 风格参考：参考图中浅灰背景与磨砂质感，不使用文字水印 负面提示：文字、水印、透视畸变、多人、杂乱背景 """ prompts.append({ "id": r["商品ID"], "filename": r["输出文件名"], "prompt": prompt }) json.dump(prompts, open("batch_prompts.json", "w", encoding="utf-8"), ensure_ascii=False)

不要把几十条完全不同的描述一次性丢给模型生成。正确做法是：先让 Codex 处理 3 条，人工检查模板是否稳定，再扩大到全部商品。批量任务最忌讳的是“错误重复一百遍”。

4. 批量生图任务编排：从单张到上百张

4.1 单张跑通是批量之前的最小验证

进入批量之前，先只跑一张。端到端验证四件事：

1. 提示词能正常提交到生图接口。
2. 接口返回的图片能保存到本地。
3. 输出文件名和商品 ID 对应。
4. 图片打开后风格符合预期。

这一步不要节省时间。我见过很多团队直接跑到第二十张才发现问题，最后发现要么文件名全错，要么背景色不一致，要么图片比例不对。单张跑通后再开批量，平均速度反而更快。

如果单张就失败，优先看命令行返回的错误信息。不要把错误信息截图发给同事看，而是直接复制出来搜索关键词，比如模型名、端点、认证头。错误信息里通常已经写清楚了问题方向。

4.2 输出目录、命名规则和批次记录

批量任务只要涉及 20 张以上，命名就是第一个管理风险。建议固定这套规则：

output/ 20250201/ sku001_cover.jpg sku001_detail_01.jpg sku002_cover.jpg

命名规则要包含商品 ID 和用途，避免只写1.jpg、2.jpg。同时，每跑一批就生成一份 json 记录，内容尽量完整：

{ "sku": "SKU001", "prompt": "产品主体：不锈钢保温杯...", "filename": "output/20250201/sku001_cover.jpg", "status": "success", "model": "图像模型名", "size": "1024x1024", "created_at": "2025-02-01T10:00:00Z" }

为什么要留记录？因为批量生图不是一锤子买卖。后续换模型、改参数、重新生成某几张，都需要知道上一轮用的什么提示词、什么尺寸。没有记录，就只能凭感觉重跑。

4.3 并发、重试与限流：速度不是唯一指标

调用图像接口时，很多人第一反应是开高并发。但从实际经验看，图像生成接口通常更吃平台限流，开 10 个并发可能不是更快，而是换来一堆 429 或超时。

稳妥做法：

• 先 1 个并发跑 3 张，统计单张耗时。
• 如果稳定，再提到 2 到 3 个并发。
• 每一批结束后统计失败率；失败率超过 10%，先降并发。

批量脚本里可以加重试逻辑，但重试次数控制在 2 次以内。图像生成比文本接口更消耗资源，无限重试只会浪费额度。建议把失败任务单独记录到failed.json，跑完一批后再统一补跑，不要中途反复打断主流程。

4.4 生图接口参数要按平台能力调整

不同平台的文生图接口支持程度不完全一样。常见字段如下：

seed是统一风格的好帮手。如果平台支持固定 seed，可以在同样提示词下重跑，得到更接近的结果。但注意：不同模型对 seed 的解释不完全一致，不要假设 seed 相同结果就完全相同。

我一般会在单张跑通后，用同一组提示词改 size、quality、seed 各测一次，把结果并排放在 Cowart 画布上，再决定正式批量参数。这个过程看起来慢，但能避免大批量生成后才发现参数不适合。

5. 验收与回归：风格一致性不能靠感觉

5.1 制定可执行的验收标准

批量生图之后，最常见的问题是“看起来差不多，放一起又不统一”。所以生成前就要定可执行标准，不能等图片出来后凭感觉宣布“可以”。

建议按这套维度检查：

• 背景色是否一致。
• 产品摆放角度是否一致。
• 光线方向和阴影方向是否一致。
• 图片尺寸和文件格式是否一致。
• 是否出现文字、水印、乱码。
• 是否出现透视畸变或多产品干扰。

人工抽检时，把第一批结果贴回 Cowart 画布，缩放到同一大小，横排对比。单张看都挺漂亮，并排才能看出风格是否统一。这个环节最好叫上另一个同事一起看，自己连续看完几十张图后，容易失去对“跑偏”的判断力。

5.2 风格飘移先查输入，再怀疑模型

如果 30 张里出现三五张明显跑偏的，不要先怪模型。按顺序排查：

1. 这五张的提示词是否误写了不同场景、光线或相机参数。
2. 五张产品图本身的原始背景是否差异很大。
3. 后端图像模型是否有尺寸或比例限制，导致构图被裁切。
4. 有没有触发平台内容限制，导致返回兜底图或错误提示。

大部分风格飘移不是模型随机的锅，而是输入没有完全模板化。比如商品名里带了“红色特别版”这种描述，就会覆盖模板里固定的浅灰背景语义。所以批量生成时，产品卖点字段要尽量只写与外观、材质、功能相关的信息，不要放会改变视觉风格的长句。

5.3 用 bad_cases 做回归样本

每次批量任务留下的问题图不要直接删。把它们单独放到bad_cases/目录，记录对应提示词和参数。下次调模板时，直接用这些样本做回归：如果新模板能避开这些问题，说明模板更稳；如果又复现，说明是模型或接口层面的限制，要么换模型，要么降低预期。

这个习惯比任何参数调优都实用，因为生图模型更新很频繁。上个月不支持的参数，这个月可能就支持了；但问题图样本能一直提醒你哪些方向不能走。我自己的bad_cases目录里，积累最多的就是“文字乱码”和“多手指”，这类问题靠提示词很难完全解决，只能靠固定 seed、增加负面提示或后期裁剪来缓解。

6. 高频报错排查：按顺序来，少走弯路

6.1 unable to locate the codex cli binary

这个报错出现概率最高，通常不是模型问题，是环境问题。

先确认三件事：

1. 命令行里执行codex --version是否正常。
2. 如果正常，看桌面端或编辑器插件使用的 PATH 是否和终端一致。
3. 如果仍找不到，设置CODEX_CLI_PATH指向 codex 可执行文件。

在 macOS 和 Linux 上，npm 全局包通常装在/usr/local/bin/codex或/opt/homebrew/bin/codex。Windows 上可能是%APPDATA%\npm\codex.cmd。不同电脑路径不一样，所以更可靠的方法是先确认二进制位置，再把它配置到能识别的地方。

如果桌面端一直启动失败，还有一种常见原因：CLI 版本过旧，和桌面端要求的版本不匹配。可以先升级 Codex，再重启。

6.2 端点失败与 base_url 问题

类似failed while handling codex endpoint /responses的报错，重点查两点：

• 所填 base_url 是否正确，是否需要带/v1。
• 平台是否支持/responses这个端点。很多 OpenAI 兼容服务只支持/chat/completions，但 Codex 部分版本默认用 responses 接口。这时需要在配置里调整 wire_api 或改用支持 responses 的服务商，而不是反复重试。

如果看到的是本地网络转发相关报错，正确做法是先关闭本地链路配置，回到服务商原地址排查。先不要怀疑模型能力，很多端点问题只是地址写错或协议不支持。

6.3 模型名不支持

比如报the 'gpt-5.6-sol' model is not supported，含义很明确：代码或配置里写的模型名，在目标平台上不可用。解决方式：

1. 去平台查看可用模型列表。
2. 在 Codex 配置里改成实际存在的模型名。
3. 确认文本模型和图像模型分开配置。

这里容易产生一个误解：以为只要平台号称“兼容 OpenAI”，任何模型名都能传。实际兼容只代表协议风格接近，不代表模型列表一致。配置时最好把平台文档里的模型名原样复制，不要自己补版本号或后缀。

6.4 文件保存异常与输出为空

图片接口返回成功，但文件打不开，优先检查：

• 返回的到底是图片 URL 还是 JSON 里的 base64 字段。
• 保存时是否以二进制方式写入文件。
• 文件后缀和实际编码是否匹配。

如果是批量脚本统一保存，这类问题通常一个错误会覆盖所有文件。先跑最小样例，能避免把错误复制到一百张图。还有一个常见坑：接口返回的b64_json字段很长，直接 print 会把终端刷爆，建议先取字段长度再确认。

如果输出为空但状态码是 200，可能是内容过滤导致返回了空结果。这时要看接口返回的finish_reason或content_filter_results，而不是反复重试。

7. 从“能跑”到“稳定用”的落地建议

7.1 把整个流程固化成项目模板

建议把第一次跑通后的所有配置保存成项目级文件：

project/ products.csv prompts_template.json generate_batch.py output/ bad_cases/

下次换一批产品，只需要改products.csv，不要每次临时写提示词。效率提升来自“复用”，而不是“这次少花多少时间”。Codex 在这里的职责是维护流程脚本，Cowart 的职责是维护视觉一致性，图像接口则负责真正出图。三者各管一段，才能长期稳定运行。

7.2 分清 Codex 和 Cowart 的职责边界

Codex 的强项是稳定执行流程，Cowart 的强项是可视化对比。两者配合能提高效率，但不存在“一键生成完美商品图”的魔法。真正的效率来自：先定标准、再跑批量、最后复盘。

不要为了让 Codex 显得“智能”，让它每次随机改提示词。反而应该把提示词模板当代码来管理：每次改动都记录，产生跑偏时能回滚。画布上的参考图区也不要频繁更换，尽量保持同一种视觉基线。

7.3 哪些场景适合，哪些场景不适合

这套流程适合：需要给几十个 SKU 生成同风格图、并且有基本命令行操作能力的人。比如电商详情页配图、广告投放素材、社媒批量配图、包装效果图初稿，都很适合。

不适合：只想点一个按钮就出完美成片、或者只有两三张需求、单张成本不敏感的人。如果只是少量示意图，直接在生图工具里手动生成更快，没必要搭一套流程。还有一类情况要谨慎：产品本身有严格的外观还原要求，比如药盒、包装文字必须准确，这批场景目前更适合设计师手工修图，而不是全自动批量生成。

我自己的体会是，这类任务最花时间的不是出图，而是定义风格、调整模板、排查失败批次。Codex 和 Cowart 能帮你把这三件事固定下来，但前提是你先把第一张图跑稳。单条流程稳定之后，批量只是水到渠成。