Prompt em JSON para foto profissional: o que a estrutura resolve (e o que não)

Prompt em JSON funciona? A resposta curta, com os três números

Você achou um bloco de JSON pronto, com "lighting", "camera_angle" e "negative_prompt" alinhados em colunas, e a promessa que vem junto é sempre a mesma: escrito assim, a IA obedece. A pergunta prática é uma só: um prompt em JSON para foto profissional entrega mais do que a frase que você já sabe escrever?

A resposta honesta tem duas metades. Sim, funciona, no sentido de que o modelo entende: chaves e aspas não quebram nada e o conteúdo passa inteiro. E não, não é superior, no sentido de que a estrutura não sobrevive ao caminho. Em 21/08/2026 escrevi o mesmo pedido de foto profissional, doze campos com o mesmo significado, em três formatos diferentes, rodei nove execuções e li o texto que de fato chegou ao gerador. Em 9 de 9 o que chegou foi um parágrafo corrido, sem uma única chaveta, inclusive quando o que eu tinha enviado era um objeto de dezoito chaves.

Três medições resumem o teste, e o método completo está mais abaixo:

• 0 chavetas e 0 pares "campo": "valor" no texto final, em 9 de 9 execuções, nos três formatos, inclusive no braço que recebeu JSON puro.
• 12 de 12 valores semânticos preservados em todas as execuções, também nos três formatos. Nenhum campo se perdeu por causa do formato, e nenhum se salvou por causa dele.
• 214 tokens contra 131: o mesmo conteúdo custou 214 tokens em JSON, 141 em linhas rotuladas e 131 em frase corrida. Dentro do JSON, só os valores somam 95 tokens, ou seja 56% do custo é pontuação e nome de campo.

Este artigo decide uma coisa só: a forma do texto. Ele não escolhe entre prompts candidatos, e essa comparação tem rubrica própria: quando o problema não é o formato, e sim qual prompt escolher. Ele também não republica a biblioteca de prompts prontos, que tem casa própria: os seis componentes que a linha rotulada precisa cobrir. E não promete que um formato faça a mesma foto sair duas vezes. Ele responde uma pergunta posterior a todas essas: já que você sabe o que quer dizer, em que forma escrever para conseguir revisar, comparar e corrigir depois?

O conversor: 12 campos do JSON e a linha que substitui cada um

Os campos abaixo não foram inventados: eu baixei as sete páginas em português que ranqueiam hoje para "prompt em JSON" (18.330 palavras somadas, medidas em 21/08/2026) e extraí as chaves que aparecem em mais de um site. lighting aparece em três, style, composition, camera_angle, negative_prompt, resolution e focus em dois cada. É esse o objeto que circula.

A conversão é mecânica: cada par vira uma linha declarativa em inglês, o valor sobrevive inteiro e a pontuação some. Duas regras valem para a tabela toda. A primeira: a identidade vai na linha de cima, sempre, porque é a decisão que todas as outras podem contaminar. A segunda: campo vazio ou genérico é pior do que campo ausente, porque um valor como "profissional" ocupa espaço sem tirar nenhuma decisão do modelo.

Duas linhas da tabela merecem cuidado extra. A de lente é o arquétipo que este blog já mediu e chamou de decoração de câmera: palavras como 8k e DSLR ocupam tokens e não retiram nenhuma decisão do modelo, e o que cada termo de câmera realmente pede ao modelo é um assunto com regras próprias. A de negative_prompt é a mais mal entendida: proibir não é preencher um campo, e a força da proibição muda conforme onde ela é escrita, como mostram os cinco lugares onde uma proibição pode ser escrita.

O prompt-modelo depois da conversão, linha a linha

Este é o objeto inteiro da tabela acima, já convertido. É o formato canônico deste blog, linhas Campo: valor, e agora ele tem um número atrás: custa 141 tokens contra 214 do mesmo conteúdo em JSON. Cole com a sua foto anexada.

Use the attached photo as the only identity reference.
Preserve face shape, skin tone, age, hair and natural asymmetries.
Do not beautify, do not de-age, do not slim my face or jaw.
Framing: chest-up, eye-level camera, relaxed shoulders, hands outside frame.
Expression: calm and approachable, closed-lip natural expression.
Outfit: navy blazer over a white shirt, no tie.
Setting: plain light grey seamless background, no furniture, four corners empty.
Lighting: soft window daylight from camera left, gentle fill, realistic shadows.
Lens: 85mm portrait perspective, shallow depth of field.
Colour: neutral, low saturation, no colour cast.
Style: realistic corporate photography with visible pores and flyaway hairs, no beauty retouching.
Do not add text, logos or watermark.
Output: square 1:1, 1024x1024.

Em português, resumido: use a foto anexada como única referência de identidade e preserve formato do rosto, tom de pele, idade, cabelo e assimetrias naturais; não embeleze, não rejuvenesça, não afine o rosto nem a mandíbula; enquadramento do peito para cima, câmera na altura dos olhos, ombros relaxados, mãos fora do quadro; expressão calma e acessível, de boca fechada; blazer azul-marinho sobre camisa branca, sem gravata; fundo cinza-claro liso, sem móveis, quatro cantos vazios; luz suave de janela vindo da esquerda da câmera, com preenchimento leve e sombras realistas; perspectiva de 85 mm com pouca profundidade de campo; cor neutra e pouco saturada; fotografia corporativa realista com poros e fios soltos visíveis, sem retoque de beleza; nada de texto, logo ou marca-d'água; saída quadrada 1:1, 1024 x 1024.

Por que cada bloco de linhas existe, e o que acontece se você apagar:

• Linhas 1 a 3, identidade. Elas vêm primeiro porque tudo o que vem depois pode competir com o seu rosto. Sem a proibição explícita de embelezar, o comportamento padrão do modelo é afinar, alisar e rejuvenescer, e aí a foto fica boa e deixa de ser você.
• Linhas 4 e 5, recorte e expressão. Enquadramento e altura de câmera são as duas decisões que a média do treino toma sozinha quando você cala: costuma vir meio corpo e câmera um pouco acima dos olhos. Boca fechada é escolha deliberada, e é o que evita o sorriso de propaganda.
• Linhas 6 e 7, roupa e cenário. Peça, cor e detalhe. Os quatro cantos vazios não são preciosismo: eles é que sobrevivem quando a foto vira um círculo pequeno no topo do perfil.
• Linhas 8 e 9, luz e lente. Direção, qualidade e preenchimento numa linha só. A lente entra depois de tudo porque é sugestão de perspectiva, não de conteúdo.
• Linhas 10 a 13, textura, proibição e saída. Poros e fios soltos combatem a pele plástica. A proibição de texto existe porque um gerador que resolve escrever inventa logo e marca-d'água. E a saída fica por último porque é a única linha que não descreve a foto, e sim o arquivo.

Repare no que sumiu na conversão: aspas, chavetas, vírgulas de fim de linha e os nomes de campo. Sumiu 34% do custo em tokens e não sumiu um único valor. O que ficou é auditável linha a linha, que é exatamente o que você precisa quando a foto sai errada e você tem que descobrir qual linha causou o defeito.

O que acontece com as chaves: o teste de nove execuções

A tese que a busca em português vende é que o modelo lê o JSON como uma ficha de cadastro, campo por campo. Dá para testar isso, porque em algumas superfícies o texto que chega ao gerador volta para você num campo próprio da resposta. Foi o que eu fiz em 21/08/2026.

O método, em quatro linhas:

1. Um conteúdo só, doze campos semânticos, escrito de três formas com o mesmo significado: objeto JSON de dezoito chaves (no formato que a busca brasileira publica, com dois objetos aninhados), linhas rotuladas no formato deste blog e parágrafo descritivo no estilo dos templates oficiais dos fornecedores.
2. Três braços vezes três execuções, nove chamadas à API de Respostas da OpenAI com a ferramenta de imagem, modelo gpt-5.5, qualidade baixa, 1024 x 1024, todas entre 17h08 e 17h11 do mesmo dia, na mesma conta.
3. De cada resposta eu li duas coisas: o texto revisado que a camada escreveu e a contagem de tokens de entrada cobrada pela API.
4. Prompts em inglês, sem foto anexada, personas sintéticas. As imagens não foram publicadas: o objeto medido é o texto, não a foto.

Resultado principal. Em 9 de 9 execuções o texto revisado voltou como parágrafo corrido, com zero chavetas e zero pares "campo": "valor", inclusive nas três execuções em que eu enviei JSON puro. Os comprimentos convergiram: 83 a 87 palavras no braço JSON, 81 a 85 no braço de linhas rotuladas, 84 a 96 no braço de frase. Foi este o texto que o gerador recebeu na segunda execução do braço JSON:

Create a 1024x1024 square ultra-realistic DSLR chest-up portrait of an adult
professional person at eye-level. Calm expression, closed lips, no smile. Wearing a navy
blazer over a white shirt, no tie. Plain light grey seamless background with no furniture.
Soft window light from camera left with gentle fill. Shot with an 85mm lens at f/2.0,
shallow depth of field. Neutral low-saturation color palette. Natural skin texture with
visible pores, no beauty retouching, do not beautify, do not de-age. No text, no logos,
no watermark.

Você escreveu um objeto e o gerador recebeu uma frase. É a prova direta contra a metáfora da planilha: o campo de prompt de imagem recebe texto, e chave, aspas e vírgula são caracteres dentro desse texto. Quem quiser entender por que existe um segundo texto entre você e o gerador encontra o mecanismo completo em artigo próprio, com as superfícies em que ele acontece e as em que a documentação silencia.

Resultado dois, o custo. Contado com o tokenizador o200k_base: 214 tokens para o JSON, 141 para as linhas rotuladas, 131 para a frase. O JSON é 1,63 vez a frase para dizer a mesma coisa, e a diferença não é conteúdo: somando só os valores dentro do objeto dá 95 tokens, então 119 dos 214, ou 56%, são chave, chaveta, aspas, dois-pontos e vírgula. Do lado da API a conta bate: a média de tokens de entrada foi 1.939,7 no braço JSON contra 1.869,3 nas linhas rotuladas e 1.866,0 na frase, cerca de 74 tokens a mais por execução para não dizer nada de novo.

Resultado três, o conteúdo. Dos doze valores rastreados (enquadramento, altura da câmera, ausência de sorriso, blazer, sem gravata, fundo cinza, direção da luz, 85 mm, poros, sem retoque, sem texto e proporção 1:1), sobreviveram 12 de 12 em 9 de 9 execuções, nos três braços. É o resultado que fecha o assunto nos dois sentidos: nenhum campo se perdeu por causa do formato, e nenhum se salvou por causa dele.

JSON existe como recurso oficial, mas do outro lado do modelo

A confusão que sustenta a técnica é real e tem origem legítima: JSON é um recurso documentado de IA, com nome próprio, parâmetro e página oficial. Só que ele descreve a resposta de um modelo de texto, e não o pedido a um modelo de imagem.

A página de saídas estruturadas da OpenAI, consultada em 21/08/2026, se apresenta assim, em tradução livre: garantir que as respostas de texto do modelo sigam um esquema JSON que você define. O texto original diz que o recurso faz o modelo gerar sempre respostas aderentes ao esquema fornecido, "so you don't need to worry about the model omitting a required key", e declara disponibilidade "in our latest large language models, starting with GPT-4o". A lista de onde ele funciona está escrita na própria página: Responses, Chat Completions, Assistants, Fine-tuning e Batch. A API de imagens não aparece nessa lista.

Isso não é o fornecedor dizendo que JSON não funciona em imagem. Ele não diz isso. O que existe é ausência, e ausência se mede. Foi o que eu fiz nos dois guias de imagem, no mesmo dia: no guia de geração de imagem da OpenAI a palavra json aparece 38 vezes, e eu classifiquei uma a uma: 18 são b64_json, o campo que devolve a imagem em base64; 10 são código de parsing nos exemplos; 1 é o cabeçalho Content-Type: application/json; 9 são menu de navegação. Nenhuma descreve JSON como forma de escrever o pedido. No guia de geração de imagem da API Gemini são 25 ocorrências, todas do mesmo cabeçalho HTTP nos exemplos de chamada.

Some a isso a medição das sete páginas que ranqueiam em português para o termo: zero links para openai.com ou ai.google.dev, zero ocorrências da palavra estudo e zero comparações com qualquer outra forma de serializar texto. A palavra json aparece 223 vezes nessas páginas, e a palavra string, uma. É esse o desequilíbrio que este artigo tenta corrigir.

O que a documentação recomenda quando o assunto é imagem

Se o fornecedor não recomenda JSON para prompt de imagem, o que ele recomenda? A resposta mais próxima de um objeto estruturado está no guia de prompts do Imagen, no Google Cloud, e é justamente onde a ironia mora: a anatomia oficial tem três campos, sujeito, contexto e estilo, e a página escreve os três dentro de uma frase, com os papéis entre parênteses. O exemplo canônico é este: "A sketch (style) of a modern apartment building (subject) surrounded by skyscrapers (context and background)."

A mesma página, lida em 21/08/2026, avisa antes: "Prompts don't need to be long or complex, but most good prompts are descriptive and clear", e recomenda linguagem descritiva, com adjetivos detalhados. A palavra JSON não aparece nenhuma vez no guia inteiro, que tem 4.626 palavras.

Do lado do Gemini, as boas práticas publicadas para prompt de imagem são seis: ser hiperespecífico, fornecer contexto e intenção, iterar e refinar, usar instruções passo a passo em cenas complexas, usar negativas semânticas (em vez de "sem carros", descrever positivamente a cena pretendida) e controlar a câmera com linguagem fotográfica. As seis são sobre o que dizer. Nenhuma é sobre em que formato escrever.

Uma nota de honestidade que nenhum concorrente tem

Circula em vários textos, inclusive em versões antigas do material deste nicho, a citação de que o Google recomendaria descrever a cena em vez de listar palavras-chave. Essa frase não está mais na página do Gemini: a palavra keyword tem zero ocorrência nas 14.805 palavras que eu baixei em 21/08/2026, e a mesma checagem em 20/08/2026 deu o mesmo resultado. Quem quiser o argumento com literal vigente usa o guia do Imagen, que continua publicando a anatomia dentro de uma sentença. Documentação de fornecedor muda de versão em semanas, e é por isso que toda citação aqui vem com data de consulta.

Vale registrar quem fez o melhor trabalho do outro lado. O tutorial do TechTudo assinado por Giulya Vasconcellos em 29/05/2026 é o mais bem feito do recorte: pede à IA um JSON detalhado da imagem de referência, descreve o resultado como um mapa daquela imagem, registra que a geração levou cerca de dois minutos, aponta distorções em cadeiras e objetos do escritório e usa fotos de banco livre para não esbarrar em direito de imagem de terceiros. O que ele descreve funciona, e funciona por um motivo diferente do anunciado, que tem artigo próprio: de onde vem a descrição quando a IA olha uma foto que você gostou. O ganho está aí, e não no fato de a descrição estar entre chavetas.

Ordem pesa mais que formato: o que a pesquisa publicada mediu

Existe uma pesquisa com método publicado sobre obrigar um modelo a trabalhar em JSON. É o estudo de restrição de formato de Tam e colegas, da Appier AI Research com a Universidade Nacional de Taiwan (versão 3, de 14/10/2024). O limite dela precisa vir na mesma frase, e não em rodapé: ela mede modelo de texto produzindo JSON como saída, com modelos de 2024. Não testou modelo de imagem recebendo JSON como entrada. É a evidência mais próxima que existe, e ela aponta para o lado contrário do que a busca em português vende.

O resumo do próprio estudo diz que houve queda significativa na capacidade de raciocínio sob restrição de formato, e que restrições mais estritas geram degradação maior em tarefas de raciocínio. A conclusão do estudo acrescenta o outro lado: o modo JSON atrapalha raciocínio enquanto melhora a acurácia em tarefas de classificação. E o sinal muda conforme o modelo.

O achado mais transferível para o nosso caso não é nenhum desses números, e sim um detalhe de ordem: os autores observaram que 100% das respostas em modo JSON do GPT-3.5 Turbo colocaram a chave da resposta antes da chave da justificativa, e isso sozinho fez o modelo responder direto em vez de raciocinar antes. A ordem dos campos mudou o comportamento em todas as respostas.

Traduzido para prompt de foto, vira uma regra de escrita que vale em qualquer formato: o que decide identidade vem primeiro, o que decide o arquivo de saída vem por último, e duas linhas que disputam a mesma decisão são contradição, não detalhe. O caso clássico deste blog é o prompt que pede textura de pele preservada num campo e correção de imperfeições em outro, trinta linhas adiante. Em JSON esse conflito fica mais fácil de esconder, porque os dois campos parecem organizados e distantes um do outro.

Onde a estrutura ganha: ela é para você, não para o modelo

Se a estrutura morre antes do gerador, por que este blog escreve prompt em linhas rotuladas há mais de cem artigos? Porque o ganho existe, só que ele é do lado de cá. Um prompt organizado em linhas nomeadas permite quatro coisas que um parágrafo corrido dificulta:

• Mudar uma variável por vez. Você troca a linha de luz e mantém as outras doze idênticas. Num parágrafo, mexer na luz costuma reescrever meia frase e mudar duas coisas sem querer.
• Comparar duas versões. Lado a lado, linha por linha, você vê o que mudou em cinco segundos.
• Localizar a linha culpada. Saiu sorriso que você não pediu? A linha de expressão está lá, nomeada, e você sabe onde olhar.
• Montar uma biblioteca. Blocos nomeados são reaproveitáveis entre pedidos: o bloco de identidade não muda nunca, o de cenário muda a cada uso.

Isso é reprodutibilidade de processo, não obediência do modelo. E a diferença entre as duas coisas é o que a busca em português não escreve. JSON entrega esse mesmo ganho, com um custo de 63% mais tokens e a desvantagem prática de esconder contradição entre campos distantes. Linhas rotuladas entregam o mesmo, mais barato e mais legível para quem vai revisar, que é você. Existe um caso em que o objeto é a escolha certa, e ele não tem nada a ver com o modelo: quando alguém depois de você lê aquele texto por programa, um script seu que preenche o mesmo molde para trinta pessoas, uma planilha que guarda uma variação por linha. Aí o JSON é estrutura de dados para o seu código, e a string que sai dele é que vai para o gerador.

Três fronteiras, para não confundir esse ganho com outros. Repetir a mesma foto entre duas execuções não tem nada a ver com formato de texto, e o que muda entre duas execuções do mesmo pedido tem causa e resposta próprias. Escolher entre dois prompts candidatos é uma decisão de conteúdo, com rubrica própria. E transformar uma foto alheia em descrição é outro fluxo ainda, que começa antes de qualquer decisão sobre chaves e aspas.

Colei um JSON e deu errado: sintoma, causa e correção

Quatro reclamações concentram quase tudo o que dá errado quando alguém copia um objeto pronto da internet. As causas abaixo são documentadas ou medidas, não palpite.

O que este teste não mediu

Antes dos limites do meu teste, o limite da fonte alheia. O ganho de 40% a 60% que circula tem uma origem verificável em português: a página de uma ferramenta que converte imagem em prompt JSON, que promete essa faixa de precisão nos principais modelos do mercado. É material de produto, sem estudo, sem N, sem modelo testado e sem data. Quem publicar um estudo de verdade sobre isso vai encontrar aqui um leitor interessado, desde que venha com esses três.

Os limites do meu próprio teste, escritos no corpo e não em rodapé:

• Um fornecedor, um modelo principal, uma superfície (a API de Respostas), qualidade baixa, um dia, nove execuções. Não mede aplicativo de consumidor e não mede Gemini.
• Prompts em inglês e sem foto de referência anexada. Com foto anexada o comportamento da camada de reescrita muda, e isso é assunto de outro artigo.
• Não é taxa de erro nem comparação de qualidade de imagem: as imagens não foram pontuadas. O objeto medido foi o texto que chega ao gerador.
• Ficou uma pista aberta, e ela precisa do aviso na frente: comparando as três reescritas de cada braço palavra a palavra, 10 das 80 palavras distintas do braço JSON, 8 das 80 do braço de linhas rotuladas e 13 das 87 do braço de frase faltaram em pelo menos uma das três execuções. A frase corrida foi a que mais variou. Três execuções por braço não medem estabilidade: isso é convite para quem quiser repetir com N maior, e não conclusão.

E uma consequência prática do próprio limite: se você usa uma ferramenta diferente da que eu testei, o caminho para checar é o mesmo. Procure na resposta um campo com o texto revisado. Se existir, leia. Se não existir, rode o mesmo pedido três vezes e liste o que apareceu na foto sem ter sido escrito por você. Foi assim que eu descobri que o objeto não chega inteiro do outro lado.

Resumo e próximos passos

• O modelo de imagem recebe uma string. Chave, chaveta e aspas são caracteres dentro dela, e não campos de um formulário.
• Medido em 21/08/2026, em 9 execuções: zero chavetas chegaram ao gerador, e nos três formatos voltou um parágrafo de 81 a 96 palavras com o mesmo conteúdo.
• O mesmo pedido custou 214 tokens em JSON, 141 em linhas rotuladas e 131 em frase, e 56% dos tokens do JSON são pontuação e nome de campo.
• Estrutura vale para versionar, comparar e diagnosticar. Isso é organização sua, não obediência do modelo.
• Nenhum número de eficácia de JSON em prompt de imagem tem estudo por trás. Se você publicar um, cite o N, o modelo e a data.

O próximo passo depende de onde você travou. Se o problema é o que escrever em cada linha, vá para o pilar que organiza a anatomia e a biblioteca de prompts prontos. Se o problema é decidir entre duas versões que você já tem, existe uma rubrica com pesos para isso. E se a foto continua saindo diferente a cada rodada, o assunto não é o formato do texto, é o que acontece entre uma execução e outra.