通过 HiAPI API 使用 gpt-image-2/text-to-image 生成电商产品图片

为什么用文生图为电商产品视觉素材服务

产品图片是商品目录流水线中最大的瓶颈之一。单个 SKU 通常需要一张干净的列表图、一张生活场景图、一张横幅裁切图，以及多个社交平台变体——而一旦包装变更，每一张都要重拍或重新修图。文生图模型为开发者团队提供了一种可编程的方式，利用已有数据来填充这些位置。

值得将现实可行的用例与不切实际的用例区分开来：

• 补充变体。 围绕你已有参考图的产品生成生活场景、季节性或情境化背景，而不是为每个投放位都安排一次影棚拍摄。
• 目录脚手架。 在发布早期生成草稿图像，让商品运营和营销团队在最终素材到位前就能审视版式和裁切效果。
• 本地化与个性化。 通过提示词变量替换场景、季节或风格，同时保持产品描述固定不变。
• 占位符与测试素材。 为预发布环境生成确定性的填充画面图像，让店铺模板能够用看起来真实的内容进行测试。

文生图不能替代的是权威的产品记录。生成的视觉素材绝不能凭空捏造实际产品并不具备的功能、材质、颜色或配件。应将模型视为产品数据之上的渲染层，而非产品事实的来源。如果生成的图片展示了不真实的表面处理或组件，那属于缺陷，而不是创意发挥。

本指南余下部分均基于这一框架：你的产品数据和现有参考摄影仍是事实来源，模型在其周围生成情境层和构图层。有了这一边界，API 集成问题就变得直截了当——一个请求模板、每个 SKU 一组提示词变量，以及一个你可以验证的输出。

gpt-image-2/text-to-image 如何融入 HiAPI 工作流

在 HiAPI 上，gpt-image-2/text-to-image 是单一模型端点，位于你用于其他生成任务的同一统一 API 界面之后。你不需要单独的供应商集成、单独的凭据存储，也不需要为每种模态使用不同的 SDK——你的应用向 HiAPI 发送请求，并在响应中接收生成的图像。

最低限度的心智模型包含三个部分：

请求

文生图请求携带你的提示词以及控制画面的参数，其中最重要的是宽高比。模型对期望输出的所有认知都来自该提示词，因此提示词才是真正的接口——干净地对它进行参数化才是工程工作。

模型标识符

你在请求中按名称指定模型：gpt-image-2/text-to-image。将模型标识符保留为配置值而非硬编码字面量，可以让你日后轻松替换或进行 A/B 测试，而无需触碰调用点。

响应

调用返回生成的图像数据。你如何处理它——写入对象存储、流式传输给工作进程，或返回临时 URL——取决于你的流水线，但集成的形态保持不变：构建请求、发送请求、持久化结果、记录元数据。

在编写代码之前，先确定三件事：提示词存放在哪里（使用带变量的模板，而非散落在代码库各处的字符串拼接）、输出存放在哪里，以及你的验证步骤是什么样。跳过第三项的团队最终会手动审查每一张生成的图像，这从一开始就违背了自动化生成的目的。

设计提示词以实现产品准确的输出

一致的目录图像来自一致的提示词结构。与其为每个 SKU 写一句全新的描述，不如定义一个带固定槽位的模板，只替换那些确实不同的值。一个在产品工作中表现良好的结构包含五个部分，按此顺序：

1. 主体

平实而具体地说明产品是什么：品类、形态，以及产品确实具备的任何材质或表面处理。从你的产品记录中提取这些值，而不是手工转述——这正是保持 SKU 之间可比较的关键。

2. 场景

描述产品所处的环境：纯色影棚背景、厨房台面、户外表面。场景应该是整个目录中大部分差异的来源，因为它改变成本低，且不会带来歪曲产品的风险。

3. 光照

明确光线：柔和的漫射日光、带补光的定向影棚主光、温暖的室内光。光照对感知质量有巨大影响，也是整个目录中最容易标准化的项目之一，以实现视觉一致性。

4. 构图

说明产品在画面中的位置、相对大小以及拍摄角度。正面居中、四分之三视角、顶部表面的特写裁切。你在这里编码下一节将介绍的店铺版式要求。

5. 风格

以渲染意图收尾：干净的商业产品摄影、极简的编辑风格、柔和的中性色调。风格描述词应简短，并在一批图像中保持一致。

几条实用规则可以避免大多数糟糕的输出：

• 不要添加产品没有的细节。 不要虚构标志、额外按钮或配件。如果某个细节不在你的产品数据中，它就不应出现在提示词中。
• 保持否定项明确但简短。 “无文字叠加、无额外物体、无人物倒影”比一长串禁止事项更可靠。
• 固定模板，变化变量。 如果每个 SKU 的提示词措辞都不同，你的输出就会因你无法调试的原因而变化。
• 对模板进行版本管理。 将模板版本与每个生成的素材一同存储，以便你能将输出追溯回产生它的提示词。

一个最小模板如下所示，方括号中的槽位从产品数据填充：

[产品描述]，[场景]，[光照]，
[构图与角度]，[风格描述词]，
无文字叠加，无额外物体

为店铺版式选择宽高比

根据投放位选择宽高比，而不是反过来。如果你生成一张正方形图像，然后将其裁切成宽横幅，你就失去了对构图的控制——模型是按正方形来构图的，裁切决定了其余部分。按目标比例生成，才能让你提示词中的构图指令真正发挥作用。

先梳理店铺的图像位，然后分配比例：

正方形（1:1）

产品网格瓦片、市场平台列表以及任何使用统一卡片网格版式的默认选择。居中、正面的构图在这里效果最好，因为画面是对称的，且懒加载场景中的裁切往往很小。

竖版（4:5、2:3）

常见于产品主详情图、移动优先的信息流和画册式版式。竖版画面为竖长产品留出呼吸空间，并在主体上方或下方留出空间，供前端叠加商品运营元素。

横版（16:9、3:2）

品类横幅、首屏位、邮件头图和系列封面。横版画面更适合场景而非单个物体——产品置于情境中、一侧留白，比居中的物体放在宽阔空旷的画面中更具可读性。

高窄版（9:16、4:5 故事格式）

故事格式和竖版推广位。这里的构图应明确为竖版：主体位置偏低或居中、顶部留出充足空间、不包含宽大的水平元素。

两条工作流注意事项。第一，按投放位分别生成，而不是将一张母图调整尺寸嵌入每个位置——提示词的构图条款应随比例变化，这意味着要分别发起请求。第二，为每个 SKU 保留一张标准的正方形或竖版母图，用于存档以及你尚未列举的投放位，并将派生的比例视为可重新生成的输出，而非需要保存的素材。

一旦你的投放位到比例的映射表存在，它就应该和提示词模板一起放在配置中。商品运营变更版式，你改一个值，该投放位的下一次生成就使用新画面——无需改动代码。

通过 HiAPI 发起一个可用的文生图请求

模板和比例确定后，请求本身是机械性的。下面的工作流是你构建一次、每个 SKU 复用的流程。

步骤 1——组装提示词

加载模板，从产品记录填充主体槽位，从目标投放位的投放位配置填充场景、光照、构图和风格槽位。将模板版本和变量值与请求一同记录，以便输出可复现。

步骤 2——设置画面

传入与目标投放位对应的宽高比。提示词中的构图措辞与比例应保持一致——在 16:9 画面中的“居中产品、充足顶部空间”条款与在 4:5 中的同一条款会产生不同结果。

步骤 3——发送请求

通过 HiAPI API 向 gpt-image-2/text-to-image 模型发送文生图请求，使用你的 HiAPI 凭据进行认证。将模型标识符、比例和提示词模板作为配置输入，使同一代码路径服务于每个 SKU 和投放位。

向 HiAPI 图像生成端点发送 POST 请求
  model:  gpt-image-2/text-to-image
  prompt: <组装好的模板>
  aspect_ratio: <目标投放位对应的比例>

在将此接入你的服务之前，请参阅 HiAPI 文档以了解确切的端点路径、认证头格式和参数名称——这些细节就是契约，而从博客文章中复制它们正是集成漂移的开始。

步骤 4——处理响应

接收生成的图像，然后立即持久化。将二进制写入你的对象存储，键名编码 SKU、投放位和模板版本，并在素材表中记录一行，包含请求元数据：提示词文本、比例、模型和时间戳。在请求处理器内部而非旁路任务中执行此操作，可以使素材与其来源保持在一起。

步骤 5——把关输出

在生成图像到达店铺之前，将其送经审核步骤。至少检查：产品是否与记录相符、画面是否为请求的比例、是否存在虚构细节或文字伪影。尽可能自动化（比例检查、基本图像合理性检查），并在早期运行期间将其余部分排入人工审核队列。

步骤 6——返回引用

交给店铺一个稳定的存储键或 URL，而不是原始响应载荷。你的前端不应知道也不关心图像来自生成请求；它应看到与其他任何目录图像相同的素材契约。

跨产品目录扩展生成

一个可用的请求是演示；目录流水线是一个队列。从前者的转变主要在于隔离性和可观测性。

让每个 SKU 成为一个作业

将请求工作流包装在一个作业中，具有明确的输入——SKU、投放位、模板版本——和明确的输出——存储的素材键、状态、请求元数据。某个 SKU 的作业失败不应阻塞整批。重试应是安全的：由于每次运行都参数化，重新运行失败的作业会产生可比较的结果，而不是一个重复的神秘素材。

将提示词编写与执行分离

提示词模板和投放位到比例的映射应是数据，经过版本管理和审核，而不是埋在 worker 中的代码。这使商品运营和营销团队无需部署即可迭代措辞和构图，并在输出质量变化时，让你能够针对同一组 SKU 比较模板版本。

预算与速率纪律

生成成本随流量增长，因此要跟踪每批发出多少请求，并有意识地选择投放位——不要默认对每个 SKU 生成每个比例。计费遵循生成端点的用量，当前费率位于你 HiAPI 账户的定价面板中，而非本指南中。一个只组装并记录提示词而不发送的试运行模式值得尽早构建；它能在模板错误产生成本之前捕获它们。

审计你生成的内容

将请求元数据永久附加到每个素材上。当商品运营人员问为什么某个产品在某个投放位看起来不对时，你希望能用一次查询调出确切的提示词、比例和模板版本，而不是从日志中重建。

事前定义验收标准

在大规模生成之前，先明确“对店铺而言足够好”意味着什么：产品相对记录的真实性、正确的画面、无虚假文字、一批内光照一致。将可自动化的检查编码，并将人工审核队列视为一个逐步缩小的环节，而非永久性负担。

把模板、比例映射和作业包装器做对之后，扩展到完整目录就是吞吐量工作，而非重新设计工作。从单个 SKU 和单个投放位开始，端到端确认请求工作流，然后跨越你的目录扩展该作业。