Envie ao Qwen 3.7 Plus uma captura de tela de uma interface de usuário e ele poderá escrever o código front-end para recriá-la. O modelo lê imagens e códigos ao mesmo tempo, então um mockup de design, uma página de um concorrente ou uma exportação do Figma se tornam um componente React ou HTML inicial em uma única chamada. Este guia mostra o fluxo de trabalho e como obter uma saída que você realmente possa usar.
Abordaremos a chamada básica, os detalhes importantes do prompt, o ciclo de feedback visual que elimina a diferença para a precisão de pixel e como transformar a UI gerada em um aplicativo funcional. Para o contexto do modelo, consulte nossa visão geral do Qwen 3.7 Plus, e para o formato da requisição, o guia da API Qwen 3.7 Plus. Você testará a API e os endpoints que sua UI chama no Apidog ao longo do processo.
TL;DR
Envie uma captura de tela mais um prompt preciso para o Qwen 3.7 Plus e peça o código em seu framework de destino. A primeira tentativa aproxima você; você refina renderizando o resultado, tirando uma captura de tela e pedindo ao modelo para corrigir as diferenças em relação ao original. O Plus se encaixa nisso porque combina uma visão forte com uma codificação sólida, possui um contexto de 1M de tokens para designs grandes e custa pouco por chamada. O trabalho está no prompt e na iteração, não na API.
Por que Qwen 3.7 Plus para isso
Captura de tela para código precisa de duas coisas ao mesmo tempo: ler a imagem com precisão e, em seguida, escrever o código correto. O Plus atinge cerca de 60% no SWE-Bench Pro e 70,3 no Terminal-Bench, então a codificação se sustenta, e sua visão lida com layouts de UI densos. O contexto de 1M de tokens permite que você envie um design alto e de alta resolução sem truncar, e a US$ 0,40 por milhão de tokens de entrada, você pode iterar de forma barata. Para o primo agêntico desta tarefa, conduzindo uma UI em vez de reconstruí-la, consulte nosso guia do agente de uso de computador.
A chamada básica
Envie a imagem como uma parte `image_url` junto com uma instrução de texto. Aqui está um gerador mínimo:
import os, base64
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DASHSCOPE_API_KEY"],
base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)
def screenshot_to_code(png_path, prompt):
b64 = base64.b64encode(open(png_path, "rb").read()).decode()
resp = client.chat.completions.create(
model="qwen3.7-plus",
messages=[{
"role": "user",
"content": [
{"type": "text", "text": prompt},
{"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{b64}"}},
],
}],
)
return resp.choices[0].message.content
print(screenshot_to_code("mockup.png", "Reconstrua esta UI como um componente React."))
Confirme o ID do modelo atual na documentação do Model Studio antes de implantar. Isso funciona, mas um prompt de uma linha gera um resultado de qualidade de uma linha. O prompt é onde a qualidade reside.
Escrevendo um prompt que gera código utilizável
Prompts vagos produzem marcação genérica. Seja específico sobre a pilha e as restrições:
Converta esta captura de tela da UI em um único componente React usando Tailwind CSS.
Requisitos:
- Corresponda ao layout, espaçamento e paleta de cores o mais próximo possível.
- Torne-o responsivo até uma largura móvel de 375px.
- Use HTML semântico e rótulos acessíveis para entradas e botões.
- Use dados de espaço reservado onde a captura de tela mostra conteúdo dinâmico.
- Retorne apenas o código do componente, sem prosa.
Nomeie o framework, o sistema de estilo, os pontos de interrupção e a barra de acessibilidade. Diga como lidar com o conteúdo dinâmico para que ele não invente um backend. A documentação do Tailwind CSS é uma boa referência para as classes de utilidade que ele emitirá. Se você der ao modelo uma especificação de componente ou um breve resumo de design, a saída se aproxima ainda mais; nosso artigo sobre o que um design.md faz pelos agentes de codificação explica por que uma especificação escrita muda os resultados.
Fechando a lacuna com um ciclo de feedback visual
A primeira tentativa raramente acerta o espaçamento e a cor. É aqui que a visão do Plus compensa uma segunda vez. Renderize o componente gerado, tire uma captura de tela e, em seguida, envie ambas as imagens de volta e peça ao modelo para reconciliá-las:
Aqui está o design alvo (imagem 1) e minha renderização atual (imagem 2).
Liste as diferenças visuais e, em seguida, retorne o código do componente corrigido
que corresponde à imagem 1 mais de perto.
Duas ou três dessas rodadas geralmente resultam em um resultado difícil de distinguir do original. É a mesma ideia de perceber e corrigir por trás de um agente de uso de computador, aplicada ao código em vez de cliques.
Lidando com designs reais
Mockups de produção são grandes e detalhados, o que tem duas consequências:
- Custo de token. Uma imagem de página inteira e alta resolução pode consumir milhares de tokens. Reduza a escala para o menor tamanho onde o texto no design ainda seja legível e corte para a seção que você está construindo.
- Escopo. Não peça um painel inteiro em uma única chamada. Divida a página em seções, cabeçalho, barra lateral, tabela, e gere cada uma, depois as combine. O contexto de 1M ajuda, mas solicitações menores produzem código mais limpo.
Obtendo uma saída melhor
Alguns ajustes no prompt corrigem os problemas mais comuns:
- Cores erradas. O modelo aproxima as tonalidades. Cole os valores hexadecimais exatos do seu design e peça para usá-los.
- Ícones inventados. Ele tenta adivinhar as formas dos ícones. Nomeie um conjunto de ícones, como Lucide ou Heroicons, e peça para usar esses componentes.
- Conteúdo textual inventado. Se ele preencher com texto que parece real, diga para usar conteúdo de espaço reservado claramente marcado.
- Sopa de divs. Peça explicitamente por elementos semânticos e uma estrutura plana, ou ele tende a aninhar divs de wrapper em excesso.
Cada um é uma adição de uma linha ao prompt, e juntos eles reduzem notavelmente suas rodadas de refinamento.
De UI para um aplicativo funcional
O código front-end gerado é apenas metade de um recurso. O componente buscará dados, enviará formulários e chamará endpoints que devem existir e funcionar. É aqui que o atalho de captura de tela para código encontra a engenharia real.
Projete esses endpoints primeiro e a UI gerada terá algo sólido para conversar. O Apidog permite que você defina o contrato da API, o simule para que o novo componente seja renderizado com dados realistas imediatamente e teste as respostas antes que o backend seja construído. Nosso guia de modo "spec-first" detalha esse fluxo, e a abordagem combina bem com front-ends construídos por IA, da mesma forma que com APIs construídas no Cursor.
Baixe o Apidog para simular e testar as APIs por trás da UI que o Qwen 3.7 Plus gera.
FAQ
Quais frameworks o Qwen 3.7 Plus pode ter como alvo? Qualquer um que você nomeie no prompt: React, Vue, Svelte, HTML e CSS puro, Tailwind ou uma biblioteca de componentes. Seja explícito, pois o padrão é uma marcação genérica.
Qual a precisão da primeira tentativa? Próximo na estrutura, mas impreciso no espaçamento e na cor exata. O ciclo de feedback visual, renderizando e reenviando, é o que o leva à precisão quase pixelada.
Pode funcionar a partir de um design Figma? Sim, se você exportar o frame como uma imagem. O modelo lê o design renderizado, não o arquivo Figma em si.
Como mantenho o custo do token baixo? Reduza a escala da imagem para o menor tamanho legível, corte para a seção que você está construindo e gere a página em partes, em vez de tudo de uma vez.
Ele também constrói o backend? Não. Ele produz código front-end que espera APIs. Projete e simule-as separadamente, que é a parte que o Apidog lida.
O resultado final
Captura de tela para código com Qwen 3.7 Plus é um prompt preciso, uma chamada multimodal barata e um curto ciclo de feedback visual. Ele te dá um componente funcional rapidamente, mas a UI ainda precisa de APIs reais por baixo. Gere o front-end com o Plus, então projete, simule e teste os endpoints no Apidog para que o recurso final se mantenha.