Este artículo registra algunos de los problemas que encontré recientemente al usar IA para replicar páginas. Más tarde, creé un flujo de trabajo para abordar estos issues y organicé todo el proceso como referencia.
Seguramente te ha pasado también.
A veces le pasas una captura de pantalla a una IA y le pides que construya una página basada en ella. La primera versión parece más o menos correcta, pero al mirar con detalle, algo no cuadra: las tarjetas son ligeramente más anchas, las fuentes son más pequeñas, las sombras están mal... solo detalles menores.
Entonces tienes que describir verbalmente qué hay que ajustar y cómo. Iterar varias rondas lleva bastante tiempo.
Así que pensé en encadenar renderizado, capturas, comparación y modificación en un flujo de trabajo, dejando que el modelo se revise y corrija solo. Este enfoque parecía sólido.
Pero en la práctica, las cosas no salieron según lo previsto. A veces, tras corregir la segunda ronda, la tercera revertía los cambios; los resultados fluctuaban e incluso la página podía empeorar con cada iteración.
Vamos al grano.
Cómo hacer que se autocorrija
El proceso no es complejo:
1Captura objetivo ──▶ El modelo escribe HTML ──▶ Renderizado 1:1 en navegador ──▶ Generación de diff pixel a pixel2 │3Mantener mejor histórico ◀── Re-renderizar ◀── El modelo diagnostica y edita código ◀── Original + Renderizado + Diff
El Diff no arregla la página por el modelo. Solo convierte "no se ve bien del todo" en un mapa visual de desviaciones específicas, que luego se devuelve al modelo para decidir los siguientes pasos.
Para evitar que el modelo adivine ciegamente basándose en el Diff, antes de cada modificación, exijo que responda tres preguntas:
- ¿Dónde está el mayor problema?
- ¿Qué elemento o propiedad CSS probablemente lo causó?
- ¿Cómo planea solucionarlo?
Solo después de responder tocamos el código.
Para esta prueba, usé Ling-3.0-flash-VL y seleccioné dos tarjetas para una demo sencilla: una tarjeta amarilla con fondo brillante, borde negro grueso y sombra dura; la otra, una tarjeta oscura de precios SaaS con botones degradados, etiquetas y listas de características.
Creo que las tarjetas son perfectas. No tienen demasiados elementos, pero el ancho, el espacio en blanco, la dirección de los botones y las sombras... si uno falla, se nota inmediatamente.
Primera ejecución
Empecemos con la tarjeta amarilla.
Tras la primera versión, el resultado general fue bastante bueno.
La estructura, la paleta de colores, el texto y las posiciones de los botones se replicaron casi por completo. Sin comparar lado a lado con el original, podrías pensar que es suficientemente cercano.
Pero al ponerlas juntas, surgen diferencias sutiles: la tarjeta es ligeramente más grande, los pesos de fuente difieren y el espaciado/tamaño de botones no está perfectamente alineado.
Luego alimenté a Ling con la imagen original, el resultado de la primera ronda y el Diff, pidiéndole que identificara estos problemas de detalle.
Del diagnóstico, no solo dice "no es lo suficientemente similar". Señala problemas como el tamaño de la tarjeta, las fuentes y los botones, y luego modifica el CSS correspondiente.
Comparación de tres rondas de la tarjeta amarilla: La Ronda 2 mejoró, la Ronda 3 retrocedió, así que mantuvimos la Ronda 2 como la mejor histórica.
Sin embargo, una buena primera ronda no garantiza mejoras continuas.
Este video captura el problema: La Ronda 2 estaba más cerca del original, pero la Ronda 3 se deslizó ligeramente hacia atrás. Afortunadamente, el flujo de trabajo no asumió por defecto la última ronda como la respuesta, sino que preservó la mejor histórica de la Ronda 2.
Así que alimentar el Diff no significa que el modelo se vuelva repentinamente más inteligente. Puede detectar muchos problemas de detalle y mapear juicios a CSS específico, pero aún se confunde a veces.
Para detalles sobre cómo funciona el flujo de trabajo, mira la grabación de pantalla abajo.
Demo completa de la tarjeta de precios oscura: selección de activos, generación inicial, comparación con slider, luego ejecutando dos rondas de auto-reparación.
Los cambios aquí no fueron dramáticos porque la primera ronda ya estaba cerca. Las rondas subsiguientes continuaron mejorando, enfocándose en el tamaño de la tarjeta, esquinas redondeadas, botones y degradados.
Comparando ambas grabaciones muestra tendencias diferentes:
La tarjeta amarilla mejoró hasta la Ronda 2 pero retrocedió en la Ronda 3; la tarjeta oscura mostró pequeñas mejoras constantes a través de las tres rondas. Aunque dos grabaciones no prueban reglas estadísticas, muestran que el mismo flujo de trabajo no siempre produce mejores resultados en cada ronda.
Los problemas obvios suelen arreglarse en la primera o segunda ronda. Las iteraciones posteriores implican ajustes finos de tamaños de fuente, esquinas redondeadas y desplazamientos de sombra, donde arreglar una cosa a menudo rompe otra. Por lo tanto, guardo la mejor histórica en lugar de asumir que la última ronda es la respuesta.
¿Qué puede hacer realmente?
De estos resultados, la primera versión es estándar de Captura-a-Código. Lo interesante es que, después de ver la salida renderizada, puede señalar problemas a elementos específicos y propiedades CSS en lugar de solo decir "hazlo más similar".
Incluso sin auto-corrección, este paso de diagnóstico sirve como una lista de verificación útil.
Muchos problemas visuales no generan errores. Si el modelo puede ver la página real renderizada por el navegador, tiene la oportunidad de seguir corrigiéndose.
Otro punto práctico: este flujo de trabajo requiere llamadas repetidas al modelo, así que la velocidad importa. Mi generación única de HTML de página completa registrada tomó unos 7 segundos. Los datos públicos muestran que Ling-3.0-flash-VL tiene 124B parámetros totales, activando 5.5B por inferencia, con capacidades adicionales de comprensión visual y Visual Agent.
La cifra de 7 segundos se basa en mi interfaz y configuraciones específicas. No he hecho comparaciones horizontales ni derivaré velocidad/costo únicamente de los parámetros activos.
¿Dónde están las trampas?
La verdadera pérdida de tiempo no fue conectar el modelo, sino obtener una retroalimentación precisa. Inicialmente, pensé que las fluctuaciones significaban inestabilidad del modelo. Después de revisar los Diffs uno por uno, me di cuenta de que parte del problema residía en mi bucle de retroalimentación.
1. Primera trampa: Tamaño
Si la imagen objetivo estaba escalada y la captura del navegador tenía un tamaño diferente, las imágenes nunca se alineaban desde el principio. Incluso con la respuesta correcta, el Diff mostraba grandes discrepancias.
Para diffs de píxeles, estar desviado unos pocos píxeles globalmente crea zonas de error masivas.
2. Segunda trampa: Animación
Una vez, el modelo añadió efectos de aparición (fade-in) a las listas de características. Las capturas tomadas a mitad de animación dejaban contenido transparente.
Después de quitar las animaciones, la página se veía normal visualmente, pero las puntuaciones de comparación automatizada empeoraron.
Razón: El contenido transparente revelaba el fondo, haciendo que los algoritmos de píxeles pensaran que "se veía más similar".
3. Tercera trampa: Versionado
Si una ronda rompía el diseño, continuar parcheando sobre código malo acumula errores. Como construir sobre una base torcida: cuanto más intentas, más desordenado se vuelve.
En resumen, Diff es una herramienta, no un juez.
Si la retroalimentación es incorrecta, el modelo no lo detectará. Corregirá diligentemente en la dirección equivocada basándose en entradas defectuosas.
Conclusión
Destilé las reglas en tres puntos:
- Usa dimensiones idénticas para capturas originales y del navegador; sin escalado secundario.
- Fija viewport, fuentes, estados de animación y momento de la captura.
- Continúa desde la mejor versión histórica en cada ronda; no parchees código degradado.
El código funcional es solo el primer paso. Los problemas que no generan errores pero se ven mal pueden ser revisados por modelos visuales. Sin embargo, ver desviaciones no garantiza correcciones correctas cada vez.
Así que ya no asumo que más rondas equivalen a mejores resultados. Arregla los problemas obvios primero, detente cuando las mejoras se estabilicen: eso es suficiente para mí.
El modelo es de código abierto y gratuito durante 2 semanas. Para ejecutarlo tú mismo, usa estos enlaces 👇🏻:
- Huggingface : [https://huggingface.co/inclusionAI/Ling-3.0-flash-VL
- Ling studio：https://chat.ant-ling.com/chat
- Ant Digital MaaS (China): https://maas.antdigital.com/models/modelservice-1788265478122001738
- Openrouter：https://openrouter.ai/inclusionai/ling-3.0-flash-vl:free
P.D.: Este artículo fue dictado y pulido por IA, así que tiene alma ✌🏻
