Este artículo registra algunas trampas que encontré recientemente al usar IA para replicar páginas. Más tarde, creé un flujo de trabajo para abordar estos problemas y organicé todo el proceso como referencia.
Seguramente te ha pasado lo mismo.
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 mirarla 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 veces lleva bastante tiempo.
Así que pensé en encadenar el renderizado, las capturas de pantalla, la comparación y la 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 planeado. A veces, después de corregir la segunda ronda, la tercera revertía los cambios; los resultados fluctuaban y la página podía incluso empeorar con cada iteración.
Vamos al grano.
Cómo hacer que se autocorrija
El proceso no es complejo:
1Captura de destino ──▶ El modelo escribe HTML ──▶ El navegador renderiza una captura 1:1 ──▶ Generación de diff píxel a píxel2 │3Mantener mejor histórico ◀── Re-renderizar ◀── El modelo diagnostica y edita código ◀── Original + Renderizado + Diff
El Diff no arregla la página por sí solo para el modelo. Simplemente convierte "no se ve bien" en un mapa visual de desviaciones específicas, que luego se devuelve al modelo para que decida 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 simple: 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 del botón y las sombras... si uno falla, se nota inmediatamente.
Primera ejecución
Empecemos con la tarjeta amarilla.
Después de 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 los botones no están perfectamente alineados.
Luego alimenté a Ling 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". Identifica 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 una mejora continua.
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.
Entonces, alimentar el Diff no significa que el modelo de repente sea más inteligente. Puede detectar muchos problemas de detalle y mapear juicios a CSS específico, pero todavía se confunde a veces.
Para detalles sobre cómo funciona el flujo de trabajo, mira la grabación de pantalla a continuación.
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 era cercana. Las rondas posteriores 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ó mejoras pequeñas y constantes en 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 generalmente se arreglan en la primera o segunda ronda. Las iteraciones posteriores implican ajustar 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 un estándar De Captura a Código. Lo interesante es que, después de ver la salida renderizada, puede identificar problemas en elementos específicos y propiedades CSS en lugar de simplemente decir "hazlo más similar".
Incluso sin la corrección automática, 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, por lo que la velocidad importa. Mi generación de HTML de página completa registrada tomó unos 7 segundos. Los datos públicos muestran que Ling-3.0-flash-VL tiene 124B de 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 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 el navegador hacía la captura de pantalla a un tamaño diferente, las imágenes nunca estaban alineadas desde el principio. Incluso con la respuesta correcta, el Diff mostraba grandes discrepancias.
Para diffs de píxeles, estar desalineado por unos pocos píxeles globalmente crea enormes zonas de error.
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 de pantalla tomadas a mitad de la animación dejaron contenido transparente.
Después de eliminar las animaciones, la página se veía normal visualmente, pero las puntuaciones de comparación automatizadas 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 encima de 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 la dirección equivocada basándose en entradas defectuosas.
Conclusión
Destilé las reglas en tres puntos:
- Usa dimensiones idénticas para las capturas originales y las del navegador; sin escalado secundario.
- Fija el viewport, fuentes, estados de animación y momento de la captura de pantalla.
- Continúa desde la mejor versión histórica en cada ronda; no parches 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 efectivamente por modelos visuales. Sin embargo, ver desviaciones no garantiza correcciones correctas cada vez.
Por lo tanto, 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 ✌🏻
