Por que a autocorreção de UI por IA falha e a solução definitiva

@Lonely__MH
CHINÊS13 de set. de 2026
185K
241
36
58
483

TL;DR

O autor explora por que a autocorreçã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 para 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 crie uma página com base nela. A primeira versão parece mais ou menos certa, mas, ao olhar de perto, algo está estranho: os cards estão ligeiramente mais largos, as fontes menores, as sombras erradas—apenas 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 evitar que o modelo chute às cegas 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 respondermos 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á próximo o suficiente.

Mas colocados juntos, surgem diferenças sutis: o card é 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, enviar 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 específicos e propriedades CSS, em vez de apenas dizer "deixe mais parecido".

Mesmo sem auto-correção, essa etapa de diagnóstico serve como uma lista de verificação ú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: esse fluxo de trabalho requer chamadas repetidas ao modelo, então a velocidade importa. Minha geração única de HTML de página inteira registrada 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 consumo 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 residia no meu loop de feedback.

1. Primeiro percalço: Tamanho

Se a imagem alvo fosse escalonada e a captura de tela do navegador feita em um tamanho diferente, as imagens nunca se alinham desde o início. Mesmo com a resposta correta, o Diff mostrava grandes discrepâncias.

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

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 deixavam o conteúdo transparente.

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

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

3. Terceiro percalço: Versionamento

Se uma rodada quebrava o design, continuar corrigindo em cima de 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á na direção errada com base em entrada defeituosa.

Conclusão

Destilei as regras em três pontos:

  1. Use dimensões idênticas para capturas de tela 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 corrija 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.

Portanto, não assumo mais que mais rodadas equivalem a melhores resultados. Corrija problemas óbvios primeiro, pare quando as melhorias estagnarem—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 ✌🏻

Salvar com um clique

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

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

Explorar o YouMind
Para criadores

Transforme seu Markdown em um artigo 𝕏 impecável

Quando você publica 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 em um artigo 𝕏 impecável e pronto para publicar.

Experimente Markdown para 𝕏

Mais padrões para decifrar

Artigos virais recentes

Explorar mais artigos virais