Ir para o conteúdo
21 de julho de 2026 · Manual

Manual: a biblioteca de imagens e as definições de imagem de IA

Este artigo descreve o produto na data de publicação. Consulte AI Builder e Equipas de Agentes para as funcionalidades atuais.

Manual: a biblioteca de imagens e as definições de imagem de IA

Aqui está a tese: "carregue sempre as suas fotos reais" é um mau conselho, pelo menos como regra geral, e segui-la sem espírito crítico produz resultados piores do que confiar mais vezes no gerador. Uma foto de produto de 480px retirada de um site com cinco anos, mal iluminada e descentrada, não é automaticamente melhor do que uma imagem gerada limpa só por ser "real". O instinto de que a autenticidade vence sempre a fabricação só é verdadeiro acima de um patamar de qualidade que a maioria das fotos carregadas não atinge. Já vi pessoas insistirem em usar uma foto de telemóvel tirada num armazém mal iluminado por ser "o produto real", quando uma foto gerada na direção artística real do projeto teria resultado melhor para todos os visitantes que nunca viram o produto pessoalmente.

Essa é a parte contrarian. Aqui está o mecanismo que a torna verdadeira e — já que não estou realmente a tentar demovê-lo de usar a sua própria fotografia — onde a regra se inverte no final.

Porque "real" não é o mesmo que "melhor"

A biblioteca de imagens, acessível a partir do menu + no chat do builder, é uma superfície de upload simples: arraste fotos, logótipos, fotos de produtos, capturas de ecrã, e marque cada uma com um âmbito — apenas este chat, ou todas as sessões na sua conta. No momento da construção, um resolvedor percorre a biblioteca e decide onde cada imagem deve ficar, não por comparação de nomes de ficheiros, mas lendo o que a imagem realmente representa — montra, produto em fundo branco, retrato, textura — comparando com o que cada secção precisa. É genuinamente bom nisto. Carregue seis fotos de produtos contra uma secção de menu com seis itens e elas ficam nos cartões certos na maioria das vezes.

Mas o resolvedor só pode posicionar o que lhe é dado, e o que lhe é dado traz limitações reais que a geração não tem:

  • Resolução de entrada, resolução de saída — o builder nunca faz upscale, por isso essa relíquia de 480px sai em 480px, esbatida e pixelizada ao lado de tudo o resto na página.
  • Proporções fixas — uma foto quadrada de produto colocada num espaço de banner largo é recortada ao centro em vez de esticada, o que é o comportamento correto, mas implacável se o seu motivo não estava centrado à partida.
  • Elementos indesejados acidentais — as pessoas carregam "fotos" que são na verdade capturas de ecrã de telemóvel, barra de estado e interface da app incluídas, com muito mais frequência do que se imagina; o resolvedor coloca-as na mesma, porque ainda são reconhecidas como uma imagem do assunto certo, e agora há uma barra de sinal incrustada no seu hero.

Nada disto é uma crítica ao resolvedor. É um argumento para ser honesto sobre o seu material de origem. Uma imagem gerada, criada dentro da direção artística já definida do projeto, não tem nenhum destes problemas — sem resolução esbatida, sem recorte descentrado, sem elementos acidentais. Se a sua foto real é má, a escolha "autêntica" não é, na verdade, a melhor.

As definições que tornam a geração coerente

Também no menu +: dois controlos que regem tudo o que a biblioteca não cobre — fundos de hero, divisores, elementos decorativos, tudo o que não forneceu. Primeiro, um nível de qualidade, e é uma verdadeira troca, não uma opção predefinida para o máximo.

NívelUse para
EconómicoFundos e tudo o que fica atrás de texto — itera rapidamente, útil quando está a dizer "mais quente, menos carregado" quatro vezes seguidas enquanto define um estilo.
PremiumImagens à escala de hero, onde os artefactos são visíveis.

A minha regra: fazer o rascunho de todo o projeto no nível económico e depois subir as duas ou três imagens hero para o nível superior assim que a direção estiver fechada. Fazer o contrário significa pagar o custo premium por rascunhos que serão descartados três iterações depois.

Em segundo lugar, as preferências de estilo — fotográfico versus plano, quente versus frio, carregado versus minimalista — que persistem sem ser necessário repeti-las em cada prompt, e cujo âmbito funciona exatamente como o das imagens: predefinição para toda a conta, substituição ao nível do chat para um projeto que precise de divergir. Uma conta de agência não devia partilhar a mesma preferência de estilo entre um projeto de escritório de advogados e uma loja de skate na mesma semana.

O que realmente produz um conjunto coerente, no entanto, não é apenas o controlo de estilo — é o facto de a arte gerada seguir a direção artística já definida do projeto, a mesma que rege o layout, a tipografia e a cor (abordada em o design director). Peça um hero e três ilustrações de secção num projeto com direção fechada, e elas partilham uma paleta e um estilo de renderização sem ter de especificar isso três vezes. Peça num projeto sem direção ainda definida, e obtém resultados plausíveis mas desalinhados — um sinal de que a direção ainda não está assente, não um erro.

O que quem defende "carregue sempre imagens reais" acerta

E aqui está a concessão, porque a regra geral está errada, mas o instinto por trás dela não. Há uma categoria de imagens onde a geração falha independentemente do nível de qualidade ou da direção artística, e é exatamente a categoria a que as pessoas se referem quando dizem "carregue as suas coisas reais": rostos, comida e logótipos.

Um site de pastelaria com fotos reais de doces e um exterior de loja gerado funciona perfeitamente bem — ninguém espera que um edifício gerado seja fotorrealisticamente exato, e está a preencher uma lacuna genuína onde não existia foto nenhuma. O mesmo site com um croissant gerado a substituir o real no balcão parece errado em cerca de dois segundos, porque o olho está calibrado para comida real de uma forma que simplesmente não está calibrado para arquitetura. Pode não notar isso — está a olhar para o projeto há uma hora — mas um visitante pela primeira vez vai notar, e é esse o público que importa.

Os logótipos são piores, e aqui vou mais longe do que "prefira o real": uma marca com aspeto de logótipo gerado colocada no cabeçalho de um negócio real está perto de ser a pior coisa que o resolvedor pode produzir, e quase sempre acontece porque ninguém carregou o logótipo real. Se não tiver um ficheiro de logótipo limpo, diga-o em voz alta em vez de deixar o projeto avançar — a alternativa é uma marca de substituição plausível o suficiente para ninguém detetar antes do lançamento.

Portanto, a versão corrigida da regra não é "sempre real" nem "a geração está bem, não se preocupe". É mais restrita do que ambas: carregue rostos, comida, produtos, lugares e logótipos quando existem e têm boa qualidade — o resolvedor recompensa generosamente boas fontes. Tudo o resto, incluindo uma foto real má, é território válido para o gerador, e fingir o contrário só porque um ficheiro é uma fotografia é como se acaba a lançar uma foto de produto de 480px que ninguém teria escolhido de propósito.

Mais uma coisa importante: as imagens de referência são uma funcionalidade separada que orienta o estilo em vez de aparecer na página — abordada em Ensinar ao builder o seu mundo. Não coloque uma foto de moodboard na biblioteca de imagens à espera que apareça no projeto; não vai aparecer, por design. E as imagens têm versões como tudo o resto — "trocar o hero pelo que acabei de carregar" custa-lhe um rollback se estiver errado, não uma reconstrução.
Manual
PartilharXLinkedInFacebookRedditQuoraWhatsAppTelegramEmail
← Todos os artigos