Questo articolo documenta alcune insidie che ho incontrato di recente utilizzando l'IA per replicare pagine web. Successivamente, ho creato un workflow per affrontare questi problemi e ho organizzato l'intero processo come riferimento.
Probabilmente ti è capitato anche a te.
A volte invii uno screenshot a un'IA e le chiedi di costruire una pagina basata su quell'immagine. La prima versione sembra più o meno corretta, ma a un'attenta ispezione c'è qualcosa che non torna: le card sono leggermente più larghe, i font più piccoli, le ombre sbagliate—solo dettagli minori.
Quindi devi descrivere verbalmente cosa va aggiustato e come. Iterare attraverso vari tentativi richiede parecchio tempo.
Così ho pensato di concatenare rendering, screenshot, confronto e modifica in un workflow, lasciando che il modello si controllasse e correggesse da solo. Questo approccio sembrava sensato.
Ma nella pratica, le cose non sono andate come previsto. A volte, dopo aver corretto al secondo giro, il terzo annullava le modifiche; i risultati oscillavano e la pagina poteva persino peggiorare ad ogni iterazione.
Andiamo dritti al punto.
Come renderlo auto-correttivo
Il processo non è complesso:
1Screenshot Target ──▶ Il modello scrive HTML ──▶ Il browser genera uno screenshot 1:1 ──▶ Generazione del diff pixel-per-pixel2 │3Mantieni la Migliore Storica ◀── Re-rendering ◀── Il modello diagnostica e poi modifica il codice ◀── Originale + Renderizzato + Diff
Il Diff non corregge la pagina per il modello. Trasforma semplicemente "non sembra abbastanza simile" in una mappa visiva delle deviazioni specifiche, che viene poi restituita al modello per decidere i passi successivi.
Per evitare che il modello indichi a caso basandosi sul Diff, prima di ogni modifica gli richiedo di rispondere a tre domande:
- Dove sta il problema principale?
- Quale elemento o proprietà CSS probabilmente lo ha causato?
- Come pianifica di risolverlo?
Solo dopo aver risposto, interveniamo sul codice.
Per questo test, ho usato Ling-3.0-flash-VL e ho selezionato due card per una demo semplice: una card gialla con sfondo luminoso, bordo nero spesso e ombra dura; l'altra una card scura per prezzi SaaS con pulsanti in gradiente, tag ed elenchi di funzionalità.
Penso che le card siano perfette. Non hanno troppi elementi, ma larghezza, spaziatura, direzione dei pulsanti e ombre—se anche solo uno di questi è sbagliato, si nota immediatamente.
Prima esecuzione
Iniziamo con la card gialla.
Dopo la prima versione, il risultato complessivo era in realtà piuttosto buono.
La struttura, la palette colori, il testo e le posizioni dei pulsanti erano stati replicati quasi fedelmente. Senza confrontarli fianco a fianco con l'originale, potresti pensare che sia abbastanza vicino.
Ma messi insieme, emergono sottili differenze: la card è leggermente più grande, i pesi dei font differiscono e gli spazi/pulsanti non sono perfettamente allineati.
Ho quindi reinviato a Ling l'immagine originale, il risultato del primo giro e il Diff, chiedendogli di identificare questi problemi di dettaglio.
Dalla diagnosi, non dice semplicemente "non è abbastanza simile". Individua problemi come dimensioni della card, font e pulsanti, poi modifica il CSS corrispondente.
Confronto a tre round della card gialla: il Round 2 è migliorato, il Round 3 è regredito, quindi abbiamo mantenuto il Round 2 come migliore storico.
Tuttavia, un buon primo round non garantisce un miglioramento continuo.
Questo video cattura il problema: il Round 2 era più vicino all'originale, ma il Round 3 è scivolato leggermente indietro. Per fortuna, il workflow non ha impostato di default l'ultimo round come risposta finale, ma ha preservato il migliore storico dal Round 2.
Quindi reinviare il Diff non significa che il modello diventi improvvisamente più intelligente. Può individuare molti problemi di dettaglio e mappare i giudizi su CSS specifici, ma a volte si confonde ancora.
Per i dettagli su come funziona il workflow, guarda la registrazione dello schermo qui sotto.
Demo completa della card prezzi scura: selezione degli asset, generazione iniziale, confronto con slider, poi due round di auto-guarigione.
I cambiamenti qui non sono stati drastici perché il primo round era già vicino. I round successivi hanno continuato a migliorare, concentrandosi sulle dimensioni della card, sugli angoli arrotondati, sui pulsanti e sui gradienti.
Confrontando entrambe le registrazioni si notano tendenze diverse:
La card gialla è migliorata al Round 2 ma è regredita al Round 3; la card scura ha mostrato piccoli miglioramenti costanti in tutti e tre i round. Sebbene due registrazioni non dimostrino regole statistiche, mostrano che lo stesso workflow non produce sempre risultati migliori ad ogni round.
I problemi evidenti vengono solitamente risolti nel primo o secondo round. Le iterazioni successive coinvolgono la messa a punto delle dimensioni dei font, degli angoli arrotondati e degli offset delle ombre, dove correggere una cosa spesso ne rompe un'altra. Pertanto, salvo il migliore storico invece di assumere che l'ultimo round sia la risposta definitiva.
Cosa può fare realmente?
Da questi risultati, la prima versione è un classico Screenshot-to-Code. Ciò che è interessante è che, dopo aver visto l'output renderizzato, può individuare i problemi fino a elementi e proprietà CSS specifici invece di dire semplicemente "rendilo più simile".
Anche senza la correzione automatica, questo passo diagnostico serve come checklist utile.
Molti problemi visivi non generano errori. Se il modello può vedere la pagina effettivamente renderizzata dal browser, ha la possibilità di continuare a correggersi.
Un altro punto pratico: questo workflow richiede chiamate ripetute al modello, quindi la velocità conta. La mia singola generazione HTML di una pagina intera registrata ha richiesto circa 7 secondi. I dati pubblici mostrano che Ling-3.0-flash-VL ha 124B parametri totali, attivandone 5.5B per inferenza, con capacità aggiuntive di comprensione visiva e Visual Agent.
La cifra di 7 secondi si basa sulla mia interfaccia e impostazioni specifiche. Non ho fatto confronti orizzontali né deriverò velocità/costi esclusivamente dai parametri attivi.
Dove sono le insidie?
Il vero dispendio di tempo non è stato collegare il modello, ma ottenere feedback accurati. Inizialmente, pensavo che le fluttuazioni significassero instabilità del modello. Dopo aver controllato i Diffs uno per uno, mi sono reso conto che parte del problema risiedeva nel mio ciclo di feedback.
1. Prima insidia: Dimensioni
Se l'immagine target era stata ridimensionata e lo screenshot del browser aveva una dimensione diversa, le immagini non si allineavano mai fin dall'inizio. Anche con la risposta corretta, il Diff mostrava grandi discrepanze.
Per i diff pixel-per-pixel, essere fuori di pochi pixel globalmente crea enormi zone di errore.
2. Seconda insidia: Animazioni
Una volta, il modello ha aggiunto effetti di fade-in agli elenchi di funzionalità. Gli screenshot catturati a metà animazione lasciavano il contenuto trasparente.
Dopo aver rimosso le animazioni, la pagina sembrava normale visivamente, ma i punteggi del confronto automatizzato peggioravano.
Motivo: Il contenuto trasparente rivelava lo sfondo, facendo pensare agli algoritmi pixel-based che "sembrasse più simile".
3. Terza insidia: Versionamento
Se un round rompesse il design, continuare a patchare sopra codice errato accumula errori. È come costruire su fondamenta storte—più ci provi, più diventa disordinato.
In breve, il Diff è uno strumento, non un giudice.
Se il feedback è sbagliato, il modello non se ne accorgerà. Correggerà diligentemente nella direzione sbagliata basandosi su input difettosi.
Conclusione
Ho distillato le regole in tre punti:
- Usa dimensioni identiche per l'originale e gli screenshot del browser; nessun ridimensionamento secondario.
- Fissa viewport, font, stati delle animazioni e tempistica degli screenshot.
- Continua dalla versione migliore storica ad ogni round; non patchare codice degradato.
Il codice funzionante è solo il primo passo. I problemi che non generano errori ma sembrano sbagliati possono effettivamente essere controllati dai modelli visivi. Tuttavia, vedere le deviazioni non garantisce correzioni giuste ogni volta.
Quindi non assumo più che più round equivalgano a risultati migliori. Risolvi prima i problemi evidenti, fermati quando i miglioramenti raggiungono un plateau—per me è sufficiente.
Il modello è open-source e gratuito per 2 settimane. Per eseguirlo tu stesso, usa questi link 👇🏻:
- Huggingface : [https://huggingface.co/inclusionAI/Ling-3.0-flash-VL
- Ling studio：https://chat.ant-ling.com/chat
- Ant Digital MaaS (Cina): https://maas.antdigital.com/models/modelservice-1788265478122001738
- Openrouter：https://openrouter.ai/inclusionai/ling-3.0-flash-vl:free
Ps: Questo articolo è stato dettato e rifinito dall'IA, quindi ha anima ✌🏻
