使用 qwen-image-2.1-pro 生成电商产品图：API 用法与提示词配方

为什么电商产品图值得选用 qwen-image-2.1-pro

电商图片工作很少只做一件事。它可能是为新 SKU 做一次目录拍摄，为市场平台商品页做一张抠图，为落地页做一张生活场景图，再做一张带促销角标的横幅——通常都要在同一周内交付。qwen-image-2.1-pro 值得评估之处在于：当你的流程需要从同一份产品数据出发产出上述所有内容时，它能在同一个模型里完成生成、对现有资产进行编辑、输出透明 PNG 以及渲染图上文字，而不是依赖一串专用工具。

三类任务形态覆盖了大部分工作量：

• 透明抠图 —— 产品被干净地分离在透明背景上，可直接放入 CMS 的任意版位。
• 场景合成 —— 产品被置于可信的生活或影棚环境中，由文本描述加参考图生成。
• 带文字的版式 —— 标签、角标和横幅，其中的文字必须清晰可读且位置正确。

它不能替代影棚的地方：有严格品牌布光要求的主视觉图，以及产品几何外形受法规约束的任何资产（例如受监管包装）。把生成视为扩大覆盖范围、加快迭代的手段，然后保留人工审批关口——这正是本指南后面那套复核流程的用途。

需要尽早决策的实际原因是提示词架构。如果你一开始就知道同一个模型要服务抠图、场景和文字版式，你就可以建立一小组带版本号的提示词模板，而不是每次请求都临时写提示词。这个决定前期不花成本，却能避免日后返工重写。

可运行的请求：curl 与 Python

在设计提示词之前，先成功拿回一张图。HiAPI 上各模型的请求形态一致：一个 API key、一个模型名，以及请求体中的输入参数。qwen-image-2.1-pro 所需的最小参数是提示词，另外如果任务是编辑而非全新生成，还要加上你要编辑的输入图像。

curl

curl -X POST "https://api.hiapi.ai/v1/images/generations" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen-image-2.1-pro",
    "prompt": "哑光黑色陶瓷咖啡杯的影棚产品照，四分之三视角，柔和漫射主光来自左侧，浅灰色无缝背景上有轻微倒影，无文字",
    "size": "1024x1024"
  }'

Python requests

import os
import requests

resp = requests.post(
    "https://api.hiapi.ai/v1/images/generations",
    headers={
        "Authorization": f"Bearer {os.environ['HIAPI_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={
        "model": "qwen-image-2.1-pro",
        "prompt": "哑光黑色陶瓷咖啡杯的影棚产品照，"
                  "四分之三视角，柔和漫射主光来自左侧，"
                  "浅灰色无缝背景上有轻微倒影，无文字",
        "size": "1024x1024",
    },
    timeout=120,
)
resp.raise_for_status()
print(resp.json())

这个阶段值得养成两个习惯。第一，从环境变量读取 API key，绝不硬编码——你很快就会从批处理任务里运行它。第二，记录日志时保留完整的响应体，包括端点返回的任何用量字段；这正是你之后用来衡量“每张获批资产的成本”的依据，而不是靠猜。

先用上面那种通用提示词运行一次请求。确认你拿到了图片，并且响应结构符合下游代码的预期。然后才进入配方——提示词设计是慢工，你不会想在中途才发现管道问题。

透明 PNG 与产品场景的提示词配方

临时提示词容易漂移。目录团队通过维护一小组带显式变量槽的模板、将其与调用 API 的代码一起在仓库中做版本管理、每次只按 SKU 替换槽位，来获得一致的结果。

配方 1：透明抠图

{product_name}的产品抠图，{distinguishing_detail}，完全分离在透明背景上。
{view_angle}视角，产品居中且完整入画，四周留有少量边距。
柔和均匀的影棚布光，背景上不投射硬阴影，仅在产品正下方保留轻微接触阴影。
照片级真实，边缘锐利，无文字，无道具，无背景元素。

槽位：{product_name}（“一只哑光黑色陶瓷咖啡杯”）、{distinguishing_detail}（“可见的杯沿厚度和一个小把手”）、{view_angle}（“四分之三”、“正面”、“俯视”）。透明条款和“不向背景投射阴影”条款要原样保留；这两行在抠图任务里承担了大部分工作。

配方 2：生活场景

{product_name}在{scene_description}中的生活产品照。
产品是主体：焦点锐利、比例正确，{brand_color_note}。
{lighting_note}。浅景深，背景柔和虚化。
自然、编辑风格。无文字，无标志，背景上没有可见品牌标记。

槽位：{scene_description}（“明亮极简的厨房台面，配一块亚麻餐巾和一扇清晨的窗户”）、{brand_color_note}（“颜色未改动，未施加色偏”）、{lighting_note}（“来自右侧的温暖定向晨光”）。

配方 3：影棚主视觉

{product_name}的影棚产品照，{view_angle}视角。
{background_description}。主光来自{key_light_direction}，柔和补光，反射受控。
照片级真实，材质与表面质感细节丰富。无文字。

两条规则能让模板库保持健康。绝不在脚本里直接改模板——修改模板文件、升版本号并重新生成。并记录每张获批资产由哪个配方版本产出，这样当模板变更时，你能判断旧的审批是否仍然有效。

编辑现有产品图

编辑请求是大多数质量问题出现的地方，因为含糊的提示词会让模型重新生成产品，而不是修改它周围的场景。把每条编辑提示词都明确分为三部分：

1. 要改什么 —— 场景、背景、布光或添加的道具。
2. 要保留什么 —— 产品的形状、比例、标签图案、材质和颜色。
3. 要避免什么 —— 新文字、新标志、扭曲的几何形状、重复的部件。

一个可用的模板：

编辑这张产品照。
更改：把背景替换为{new_background}；把布光调整为{new_lighting}。
保留：产品的确切形状、比例、表面材质以及任何标签图案，完全保持原样。
不要：添加文字、添加标志、改变产品颜色或改动其几何形状。
照片级真实的结果，看起来像一张连续拍摄的照片。

填入示例：{new_background} = “干净的暖灰色无缝背景”，{new_lighting} = “柔和的顶部漫射光，产品后方有柔和渐变”。

保留条款并非保证。长编辑——一条提示词里同时做背景替换、布光调整和添加道具——会给模型更多在产品本身上漂移的空间。拆开做：先做背景替换，复核它，再在已批准的中间结果上做后续编辑来施加次要改动。每一步都是复核者真正能判断的一次对比。

同时为每个 SKU 保留一张标准参考图。当复核者不确定产品是否发生变化时，参考图才是基准真相，而不是上一次的生成结果。

文字渲染与版式控制

图上文字是最容易因随意提示而令人失望的功能。必须出现在最终资产中的文字需要被引号包裹、定位并加以约束。

{product_name}的电商横幅。
版式：产品放在右侧三分之一，文字块放在左侧三分之二，留出充裕边距。
文字：以粗体无衬线字体准确渲染“{headline}”作为主标题，并在其下方以较轻字重准确渲染“{subline}”。
风格：{color_scheme}，干净现代，高对比度以保证可读性。
图中其他任何位置不得出现文字。所有单词严格按照所写内容拼写。

每一行为什么重要：

• 被引号包裹的文字加上明确的“准确”指令可减少改写和生造词语。
• 位置与比例（“右侧三分之一”、“左侧三分之二”）能阻止模型把产品埋在标题之下。
• “图中其他任何位置不得出现文字”是抑制常见失败模式的条款：角落里出现看似合理的填充文字。
• 一条短标题加一条短副标题远比一段文字可靠。如果你的版式需要一段文案，先生成不含该文案的图片，再在 CMS 或设计工具中排版文案。

对于角标和标签（“New”标记、尺码标识），把它们当作各自的小提示词处理，而不是附加到主视觉图上——一条包含单个引号词的小角标提示词，在复核时比整张横幅容易验证得多。审批前务必在全分辨率下检查拼写；文字错误发现成本低、上线代价高。

复核输出：对比与审批循环

生成资产未经人工过目不应上架到店铺。成本最低且可靠的循环是逐资产的前后对比：把输入照片（或全新生成时的规格说明）放在生成输出旁边，并记录提示词配方版本和变量取值。

适合小团队的可操作循环：

1. 生成一小批——每个 SKU 几个变体，而不是整个目录。
2. 渲染一张并排对比表：左侧为源图，右侧为候选图，下方记录提示词。
3. 按一份简短固定的检查清单复核：产品形状未变、标签图案完好、背景干净、文字拼写正确、边距足够。
4. 把每个候选项标记为通过或拒绝，并记录产生通过结果的配方版本。
5. 只有这时才铺开到整批，复用已批准的配方。如果配方在批准后发生变更，在重新检查之前把现有批准视为临时有效。

让检查清单保持简短并每次都一模一样。一份始终如一的四项清单，比一份执行不均的长表单更能发现问题。被拒绝的候选也要保存——它们是某个配方版本为何被淘汰的证据，也能让下一个人不必重新发现同样的失败。

这个循环也是你的成本控制手段。因为审批与配方绑定，你可以计算每张获批资产需要多少次生成，并针对耗费尝试最多的模板进行迭代。

成本、延迟与批处理考量

用自己的测量值来规划，而不是假设。对于 HiAPI 上的图像模型，计费按输出图片计，因此主导支出的变量是“每张获批资产的尝试次数”——这完全取决于提示词质量和复核严格程度。当前的每图价格在网站的定价页上；不要把数字写死到代码或预算文档里。

一套合理的工作方法：

• 测量基线。 用已批准的配方跑十个 SKU，统计总生成次数和总批准数，推导出每张获批资产的尝试次数。这个比值比任何基准测试都更能说明问题。
• 单个迭代，批准后成批。 提示词迭代应一次一张图。配方获批后，再以适度的并发和记录失败而非静默重复计费的重试策略进行批处理。
• 把延迟当作调度参数。 图像生成以秒计，而非毫秒。异步启动作业，把结果写入队列，让复核者从队列中处理，而不是阻塞在每次调用上。
• 按比值做预算，而非按单价。 手上有每张获批资产的尝试次数后，目录估算就是基于你自己测量值的简单算术。

最后一条卫生习惯：给你的配方做版本管理，并在每次请求中记录配方版本。只花一个字段，却能把“为什么上个月这张资产看起来不一样？”从一次调查变成一次查询。

构建能让你通过 API 跑通抠图、场景和文字版式的最小流程，让提示词库保持版本化，并让复核循环——而不是指望——来决定什么能上线。