HiAPI
Blogue

Guia de uso

Gerar imagens de produtos de e-commerce com wan2.7-image/text-to-image via API HiAPI

Guia para desenvolvedores: composição de prompts, avaliação de resultados e lançamento de packshots de produtos com uma única chamada de API

Oct 31, 2026
抽象封面图:淡紫灰色块与墨黑色块以一条锐利斜边相接,边缘有一道细紫缝。

Por que modelos de texto para imagem devem entrar no seu fluxo de trabalho de packshot

Equipes de catálogo de produtos geralmente não enfrentam um problema de fotografia, mas de capacidade produtiva. Um único SKU exige uma packshot frontal limpa, às vezes variações de diferentes ângulos, e frequentemente versões que atendam às especificações da plataforma de marketplace. Para o material visual principal e qualquer conteúdo que precise ser idêntico pixel a pixel ao produto físico, a fotografia real continua sendo superior. O packshot generativo resolve um conjunto mais restrito e prático de cenários: imagens provisórias de produtos aguardando sessão fotográfica, variações de fundo para testes A/B em páginas de detalhe do produto, renderizações conceituais durante o planejamento de categorias, e composições consistentes para os SKUs de cauda longa que nunca justificariam ocupar a agenda do estúdio.

O modelo mental útil é: a geração fica entre os dados do produto e a publicação na loja, e não substitui o fotógrafo. Seu catálogo já contém fatos estruturados — nome do produto, material, cor, formato, embalagem. O modelo de texto para imagem converte esses fatos em candidatos a imagem. A questão do pipeline é como fazer isso de forma repetível na escala do catálogo, sem reescrever manualmente os prompts para cada SKU.

Este guia aborda exatamente isso. Veremos como estruturar prompts para que um catálogo inteiro produza packshots visualmente consistentes; como diagnosticar desvios de prompt; quando a saída em 4K realmente vale a pena; e como encapsular todo o processo em um serviço leve, de modo que o código do produto nunca interaja diretamente com o modelo de imagem. O modelo usado aqui é wan2.7-image/text-to-image na HiAPI, por meio de uma chamada de API unificada.

Dados e materiais do produto cruzam um único limiar rígido para a etapa de geração, e então se resolvem em blocos prontos para publicação.

Configurar wan2.7-image/text-to-image na HiAPI

wan2.7-image/text-to-image é o endpoint de texto para imagem na HiAPI: você envia o payload do prompt e recebe uma imagem. Sem abrir conta separada para cada modelo, sem instalar SDKs de cada fornecedor, sem gerenciar um segundo conjunto de credenciais — a HiAPI cuida do roteamento, então a superfície de integração permanece a mesma quer você adicione ou troque modelos.

O caminho do zero à primeira renderização é assim:

Obter a chave de API e confirmar o nome do modelo

Crie uma chave na sua conta HiAPI e confirme o identificador exato do modelo na lista de modelos: wan2.7-image/text-to-image. Trate o identificador como configuração, não como string embutida no código — coloque-o em uma variável de ambiente ou arquivo de configuração, para poder apontar para outro modelo de imagem no futuro sem alterar o ponto de chamada.

Enviar uma requisição mínima

A forma de chamada é deliberadamente simples: um prompt e o nome do modelo. Comece com uma frase única descrevendo um produto sobre fundo sólido e verifique o resultado. Não monte templates neste momento — primeiro confirme que a autenticação funciona, que a resposta contém dados de imagem decodificáveis ou acessíveis, e que você sabe quais metadados a resposta carrega (dimensões, formato).

Armazenar a resposta como artefato

Grave a imagem retornada no armazenamento de objetos, com nomes de chave determinísticos, em vez de manter os bytes em memória ou em banco de dados. Desde a primeira chamada, trate cada renderização como um ativo com nome, versão de prompt e timestamp — fazer isso depois é muito doloroso.

Registrar o prompt junto com a imagem

O metadado mais valioso é a string exata do prompt que produziu a imagem aceita. Registre-a. Quando um revisor perguntar "por que esta ficou diferente", o prompt é a resposta.

O endpoint é como uma única costura decisiva: o payload do prompt atravessa uma vez e volta como imagem finalizada.

A anatomia de um prompt de packshot

Um prompt de packshot que funciona é acidental; o que funciona em todo o catálogo é estrutural. Use cinco componentes, sempre na mesma ordem, de modo que a única coisa que muda entre SKUs sejam os dados injetados:

Assunto

O objeto concreto, incluindo sua categoria e uma ou duas propriedades que definem seu contorno. "Porta-filtro de café coado em cerâmica fosca" comunica mais ao modelo do que "máquina de café". Diga o tipo de produto, não o nome de marketing.

Material e acabamento

O comportamento da superfície determina o realismo da imagem do produto. Declare material e acabamento explicitamente: fosco, escovado, brilhante, vidro jateado, papel não revestido, metal anodizado. Se o produto real tem textura sutil, diga também — o desvio costuma começar aqui.

Iluminação

Packshots de produto exigem iluminação previsível. Escolha um vocabulário pequeno e mantenha-o em todo o catálogo: luz de estúdio suave e uniforme, luz principal suave única vinda do canto superior esquerdo, queda suave em gradiente. Evite linguagem dramática a menos que queira resultados dramáticos; para listagens de produto, consistência vence artisticidade.

Fundo

Especifique cor sólida e neutra, e diga a cor: branco infinito, cinza quente claro, neutro aparentemente transparente. Fundos vagos produzem fundos confusos. Se o marketplace exige branco, escreva branco.

Composição

Descreva o enquadramento e a posição da câmera: centralizado, produto ocupando cerca de dois terços do quadro, vista frontal na altura dos olhos, leve ângulo de três quartos, sem cortar nenhuma parte. A composição decide se a grade de SKUs parece um conjunto de produtos ou uma pilha de itens variados.

Um template construído com esses cinco slots permite gerar uma categoria inteira a partir de uma tabela de linhas de produtos estruturadas, e transforma a próxima seção — corrigir desvios — em edição de slot por slot.

Um prompt como cinco camadas estruturais: assunto, material, iluminação, fundo, composição — empilhadas e unidas por uma única costura.

Melhorar a aderência ao prompt

Quando a renderização se afasta da descrição do produto, o instinto é reescrever o prompt. Resista. O caminho eficaz é identificar qual componente falhou e mudar apenas essa variável em cada iteração.

Diagnosticar antes de reescrever

Compare a renderização com seus cinco slots. Material errado mas composição certa? Então só a frase de material precisa de ajuste. Produto correto mas flutuando em uma cena confusa? A cláusula de fundo está fraca. Apontar o slot que falhou transforma o vago "não está bem" em uma edição concreta.

Declarar restrições explicitamente, inclusive as negativas

Modelos respondem ao que você diz, então diga o que importa. Se o produto não pode ter logo visível, não pode ter reflexos feios, não pode estar na mão de alguém, escreva essas exclusões no prompt. Restrições explícitas reduzem o espaço de renderizações plausíveis, e é exatamente isso que significa aderência.

Reduzir o número de ideias por prompt

Cada elemento adicional — adereços, sombras de outros objetos, superfícies decorativas — disputa a atenção do modelo. Para packshot, elimine totalmente os adereços. Um prompt que descreve um objeto em uma cena é muito mais confiável em aderência do que um que também pede uma cena estilizada.

Manter um pequeno conjunto de testes e uma referência fixa de comparação

Escolha cinco SKUs representativos no catálogo — um material difícil, um material reflexivo, um tamanho pequeno, um tamanho grande, um com embalagem impressa. Ao alterar o template, renderize esses cinco novamente e compare. Isso revela a falha comum: uma correção para um tipo de produto quebra silenciosamente outro. Registre a versão do template em cada renderização, para atribuir mudanças de qualidade da saída a mudanças no prompt.

Melhorar a estrutura, não os adjetivos

Se um slot falha persistentemente, a correção geralmente exige mais estrutura, não mais adjetivos. Substitua "iluminação de estúdio bonita" pela configuração de luz específica que você quer. Substitua "fundo agradável" por cor e superfície. A aderência melhora quando o prompt se parece com uma ficha técnica em vez de um desejo.

Usar saída em 4K

Resolução mais alta é uma decisão de veiculação, não um padrão. wan2.7-image/text-to-image suporta saída de alta resolução, mas cada renderização em 4K consome mais tempo, mais armazenamento e mais processamento downstream do que uma renderização padrão. Trate essa escolha como uma regra de roteamento por local de exibição da imagem.

Mapear resolução para caso de uso

A imagem principal da página de detalhe do produto e qualquer imagem usada para zoom merecem o nível mais alto — é onde o comprador examina costuras, texturas e etiquetas. Miniaturas de grade, blocos de categoria e resultados de busca não precisam; gerar em 4K e depois reduzir é desperdício. As fichas de especificação de marketplaces geralmente publicam seu próprio tamanho mínimo, então defina o limite inferior pela exigência do marketplace, não pelo máximo do modelo. Todo o resto — renderizações para revisão interna, variações de teste A/B, imagens provisórias — fica no nível padrão.

Planejar para o ciclo de vida do ativo, não apenas para a requisição

Imagens 4K são arquivos grandes. Decida antecipadamente se armazena o original em resolução máxima e deriva variantes menores na entrega, ou se armazena apenas o nível necessário para cada local de exibição. Armazenar o original e gerar derivados costuma ser mais fácil de entender e permite re-renderizar tamanhos de entrega sem chamar o modelo novamente. Dimensione armazenamento e tráfego de saída do CDN com base nisso, e garanta que a nomenclatura dos ativos codifique o nível de resolução, para que serviços downstream não enviem acidentalmente um original 4K para um slot de miniatura.

Renderizar em alta resolução mais tarde

Durante a iteração de prompts, renderize em resolução padrão. Problemas de aderência são visíveis em qualquer tamanho, e iterar em 4K multiplica o tempo de ciclo sem ganho diagnóstico. Só eleve para alta resolução depois que a variante de prompt for aprovada — uma renderização em alta resolução por ativo aprovado, não por experimento.

Fazer a chamada de API no pipeline de produtos

A chamada em si tem uma linha de lógica. O trabalho está em mantê-la longe do código do produto. Encapsule-a em um serviço interno leve com quatro responsabilidades:

Templates de prompt como dados versionados

Armazene o template de cinco slots fora da aplicação, com chave por categoria. O serviço recebe dados estruturados do produto, preenche os slots e registra a versão do template que produziu a renderização. Ao editar um template, os ativos antigos continuam rastreáveis até a versão que os gerou.

Função de geração com entradas e saídas explícitas

O serviço expõe algo como generatePackshot(productId, category, options), retornando uma referência de ativo — não bytes brutos. As opções incluem o nível de resolução e a versão do template. Tudo relacionado à chamada da HiAPI — autenticação, identificador de modelo, forma da requisição — vive dentro dessa fronteira. Se você mudar a string do modelo ou adicionar outro modelo de imagem no futuro, o código do produto não muda. Equipes que usam a HiAPI para outras modalidades seguem a mesma lógica: um padrão de integração, um conjunto de credenciais.

Retentativas com orçamento limitado

Geração é uma chamada de rede a um modelo remoto. Repita falhas transitórias, mas limite o número de tentativas e use backoff com jitter. Mais importante, diferencie falhas retentáveis de requisições que nunca terão sucesso — um template malformado deve falhar rápido e visivelmente, em vez de consumir o orçamento de retentativas. Registre o número de tentativas no ativo, para observar com que frequência uma renderização precisou de segunda tentativa.

Nomenclatura previsível de ativos

Nomeie ativos com os dados que você já tem: ID do produto, categoria, versão do template, nível de resolução e um hash curto de conteúdo. Nomes determinísticos possibilitam idempotência — tarefas de retentativa de ativos já produzidos podem pular a regeneração — e tornam trivial localizar cada renderização de um determinado SKU.

Mantenha o serviço sem estado. Enfileire a tarefa, processe a tarefa, grave o ativo, emita o evento. Assim, o backfill em nível de catálogo e a requisição de um único produto seguem o mesmo caminho.

Controle de qualidade das imagens antes de entrarem na loja

Imagens geradas devem passar por etapas sequenciais antes da publicação. Automatize verificações de baixo custo; deixe os itens de julgamento para revisão humana.

Etapa 1: validade técnica

O arquivo deve ser decodificável, estar no formato esperado e atingir pelo menos o nível de resolução solicitado. Rejeite qualquer arquivo com tamanho insuficiente ou corrompido antes de entrar no armazenamento. Esta etapa é totalmente automatizada e nunca deve falhar silenciosamente.

Etapa 2: conformidade com requisitos da listagem

Verifique a imagem com base nas regras reais da plataforma de destino: tamanho mínimo, proporção, tolerância de cor de fundo quando branco é exigido e limite de tamanho de arquivo. Codifique as especificações do marketplace como dados, de modo que mudanças de especificação sejam mudanças de configuração. É a etapa que captura a falha mais embaraçosa — uma renderização bonita rejeitada pelo marketplace por causa do tamanho.

Etapa 3: razoabilidade de conteúdo

As verificações automatizadas aqui são mais fracas, mas heurísticas baratas ajudam: confirme que a imagem não está em branco ou quase uniforme, que o fundo dominante corresponde à cor solicitada, e que o assunto ocupa uma proporção razoável do quadro. Encaminhe falhas para uma fila de revisão, em vez de descartar; um falso positivo heurístico deve merecer uma olhada humana, não a perda do ativo.

Etapa 4: amostragem manual

Selecione uma proporção de renderizações por versão de template e categoria para revisão humana, e revise 100% das primeiras de qualquer template novo. Depois que o template for aprovado, reduza para amostragem. O revisor deve ver a imagem, o prompt e o registro do produto lado a lado — esse contexto torna a verificação rápida.

Só depois de passar por todas as quatro etapas o ativo é marcado como publicável. Armazene os resultados das etapas junto com o ativo, para que auditorias não precisem executar as verificações novamente.

Por onde começar esta semana

Escolha uma categoria com pelo menos uma dúzia de SKUs e um local de exibição que tolere imagens geradas. Escreva o template de cinco slots para essa categoria, construa o serviço leve de geração em torno de wan2.7-image/text-to-image na HiAPI, e rode a categoria inteira em resolução padrão. Antes de automatizar qualquer etapa, passe as saídas manualmente pelas quatro etapas — você aprenderá mais com a revisão das primeiras levas do que com qualquer teoria de prompt.

Quando um template estiver aprovado em uma varredura do catálogo e a aderência for aceitável, versione-o, conecte as etapas automatizadas, e só então decida quais locais de exibição merecem renderização em alta resolução.

Artigos relacionados

Ver todos os artigos →

Comece a criar com artefactos de IA persistentes

Obtenha a sua chave de API e chame modelos de imagem, vídeo e áudio através de uma única API baseada em tasks.

Ler a documentação da API