Por que a Auto-Correção de UI por IA Falha e a Solução Definitiva

@Lonely__MH
CHINÊS13/09/2026
185K
241
36
58
483

TL;DR

O autor explora por que a auto-correção de UI baseada em IA frequentemente leva à degradação e propõe um fluxo de trabalho envolvendo diffs visuais, diagnósticos estruturados e a preservação das melhores versões históricas para estabilizar os resultados.

Este artigo registra alguns percalços que enfrentei recentemente ao usar IA para replicar páginas. Depois, criei um fluxo de trabalho para resolver esses problemas e organizei todo o processo como referência.

Você provavelmente já passou por isso também.

Às vezes, você envia uma captura de tela para uma IA e pede que ela construa uma página baseada nela. A primeira versão parece mais ou menos certa, mas, numa inspeção mais detalhada, algo está estranho: os cards estão ligeiramente mais largos, as fontes menores, as sombras erradas—apenas pequenos detalhes.

Então você precisa descrever verbalmente o que precisa ser ajustado e como. Iterar várias vezes leva bastante tempo.

Por isso, pensei em encadear renderização, capturas de tela, comparação e modificação em um fluxo de trabalho, permitindo que o modelo se verifique e corrija sozinho. Essa abordagem parecia sólida.

Mas, na prática, as coisas não saíram como planejado. Às vezes, após corrigir a segunda rodada, a terceira reverteu as mudanças; os resultados flutuavam e a página podia até piorar a cada iteração.

Vamos direto ao ponto.

Como Fazer a Auto-Correção Funcionar

O processo não é complexo:

text
1Captura de Tela Alvo ──▶ Modelo escreve HTML ──▶ Navegador renderiza captura 1:1 ──▶ Geração de diff pixel a pixel
2
3Mantém Melhor Histórico ◀── Re-renderiza ◀── Modelo diagnostica e edita código ◀── Original + Renderizado + Diff

O Diff não conserta a página pelo modelo. Ele apenas transforma "não parece certo" em um mapa visual de desvios específicos, que é então enviado de volta ao modelo para decidir os próximos passos.

Para impedir que o modelo chute aleatoriamente com base no Diff, antes de cada modificação, exijo que ele responda a três perguntas:

  1. Onde está o maior problema?
  2. Qual elemento ou propriedade CSS provavelmente causou isso?
  3. Como ele planeja corrigir?

Só depois de responder é que tocamos no código.

Para este teste, usei o Ling-3.0-flash-VL e selecionei dois cards para uma demonstração simples: um card amarelo com fundo claro, borda preta grossa e sombra dura; o outro, um card escuro de preços SaaS com botões em gradiente, tags e listas de recursos.

Acho que cards são perfeitos. Não têm muitos elementos, mas largura, espaçamento, direção dos botões e sombras—se qualquer um estiver errado, fica imediatamente perceptível.

Primeira Execução

Vamos começar com o card amarelo.

Após a primeira versão, o resultado geral foi realmente muito bom.

A estrutura, esquema de cores, texto e posições dos botões foram majoritariamente replicados. Sem comparar lado a lado com o original, você poderia pensar que está perto o suficiente.

Mas, colocados juntos, surgem diferenças sutis: o card está ligeiramente maior, os pesos das fontes diferem e o espaçamento/tamanho dos botões não estão perfeitamente alinhados.

Em seguida, enviei a imagem original, o resultado da primeira rodada e o Diff de volta para o Ling, pedindo que identificasse esses problemas de detalhe.

Do diagnóstico, ele não diz apenas "não é parecido o suficiente". Ele aponta problemas como tamanho do card, fontes e botões, e então modifica o CSS correspondente.

Lonely - inline image

Comparação de três rodadas do card amarelo: A Rodada 2 melhorou, a Rodada 3 regrediu, então mantivemos a Rodada 2 como o melhor histórico.

No entanto, uma boa primeira rodada não garante melhoria contínua.

Este vídeo captura o problema: A Rodada 2 estava mais próxima do original, mas a Rodada 3 recuou ligeiramente. Felizmente, o fluxo de trabalho não assumiu a última rodada como resposta, mas preservou o melhor histórico da Rodada 2.

Portanto, alimentar o Diff de volta não significa que o modelo subitamente ficou mais inteligente. Ele consegue identificar muitos problemas de detalhe e mapear julgamentos para CSS específico, mas ainda fica confuso às vezes.

Para detalhes sobre como o fluxo de trabalho roda, assista à gravação de tela abaixo.

Lonely - inline image

Demonstração completa do card de preços escuro: seleção de ativos, geração inicial, comparação com slider, e execução de duas rodadas de auto-cura.

As mudanças aqui não foram dramáticas porque a primeira rodada já estava próxima. As rodadas subsequentes continuaram melhorando, focando no tamanho do card, cantos arredondados, botões e gradientes.

Comparando as duas gravações, vemos tendências diferentes:

Lonely - inline image

O card amarelo melhorou na Rodada 2, mas regrediu na Rodada 3; o card escuro mostrou pequenas melhorias constantes nas três rodadas. Embora duas gravações não provem regras estatísticas, elas mostram que o mesmo fluxo de trabalho nem sempre produz melhores resultados a cada rodada.

Problemas óbvios geralmente são corrigidos na primeira ou segunda rodada. As iterações posteriores envolvem ajustes finos de tamanhos de fonte, cantos arredondados e deslocamentos de sombra, onde corrigir uma coisa frequentemente quebra outra. Por isso, salvo o melhor histórico em vez de assumir que a última rodada é a resposta.

O Que Ele Realmente Consegue Fazer?

Desses resultados, a primeira versão é o padrão Captura-de-Tela-para-Código. O interessante é que, após ver a saída renderizada, ele consegue apontar problemas para elementos e propriedades CSS específicos, em vez de apenas dizer "deixe mais parecido".

Mesmo sem auto-correção, essa etapa de diagnóstico serve como uma checklist útil.

Muitos problemas visuais não geram erros. Se o modelo pode ver a página real renderizada pelo navegador, ele tem a chance de continuar se corrigindo.

Outro ponto prático: este fluxo de trabalho requer chamadas repetidas ao modelo, então a velocidade importa. Minha geração única de HTML de página inteira gravada levou cerca de 7 segundos. Dados públicos mostram que o Ling-3.0-flash-VL tem 124B de parâmetros totais, ativando 5.5B por inferência, com capacidades adicionais de compreensão visual e Agente Visual.

A figura de 7 segundos é baseada na minha interface e configurações específicas. Não fiz comparações horizontais nem derivarei velocidade/custo apenas pelos parâmetros ativos.

Onde Estão os Percalços?

O verdadeiro desperdício de tempo não foi conectar o modelo, mas obter feedback preciso. Inicialmente, achei que as flutuações significavam instabilidade do modelo. Após verificar os Diffs um por um, percebi que parte do problema estava no meu loop de feedback.

1. Primeiro percalço: Tamanho

Se a imagem alvo fosse escalada e o navegador tirasse a captura em um tamanho diferente, as imagens nunca estariam alinhadas desde o início. Mesmo com a resposta correta, o Diff mostraria grandes discrepâncias.

Para diffs de pixels, estar fora por alguns pixels globalmente cria zonas de erro massivas.

2. Segundo percalço: Animação

Uma vez, o modelo adicionou efeitos de fade-in às listas de recursos. Capturas de tela feitas no meio da animação deixaram o conteúdo transparente.

Após remover as animações, a página parecia normal visualmente, mas as pontuações de comparação automatizadas pioraram.

Razão: Conteúdo transparente revelava o fundo, fazendo os algoritmos de pixels pensarem que "parecia mais parecido".

3. Terceiro percalço: Versionamento

Se uma rodada quebrasse o design, continuar a aplicar patches sobre código ruim empilha erros. É como construir sobre uma fundação torta—quanto mais você tenta, mais bagunçado fica.

Em resumo, o Diff é uma ferramenta, não um juiz.

Se o feedback estiver errado, o modelo não perceberá. Ele diligentemente corrigirá a direção errada com base em entradas falhas.

Conclusão

Destilei as regras em três pontos:

  1. Use dimensões idênticas para capturas originais e do navegador; sem escalonamento secundário.
  2. Fixe viewport, fontes, estados de animação e momento da captura de tela.
  3. Continue a partir da melhor versão histórica a cada rodada; não aplique patches em código degradado.

Código funcional é apenas o primeiro passo. Problemas que não geram erros, mas parecem errados, podem de fato ser verificados por modelos visuais. No entanto, ver desvios não garante correções certas toda vez.

Por isso, não assumo mais que mais rodadas significam melhores resultados. Corrija problemas óbvios primeiro, pare quando as melhorias estabilizarem—isso é suficiente para mim.

O modelo é open-source e gratuito por 2 semanas. Para executá-lo você mesmo, use estes links 👇🏻:

Ps: Este artigo foi ditado e polido por IA, então tem alma ✌🏻

Guardar com um clique

Faça leitura aprofundada de artigos virais com IA no YouMind

Guarde a fonte, faça perguntas específicas, resuma o argumento e transforme um artigo viral em notas reutilizáveis num único espaço de trabalho com IA.

Explorar o YouMind
Para criadores

Transforme o seu Markdown num artigo 𝕏 impecável

Quando publica os seus próprios textos longos, formatar imagens, tabelas e blocos de código para o 𝕏 é uma dor de cabeça. O YouMind transforma um rascunho completo em Markdown num artigo 𝕏 impecável e pronto a publicar.

Experimente Markdown para 𝕏

Mais padrões para decifrar

Artigos virais recentes

Explorar mais artigos virais