Warum die automatische UI-Korrektur durch KI scheitert und die ultimative Lösung

Dieser Artikel dokumentiert einige Stolperfallen, auf die ich kürzlich gestoßen bin, als ich versuchte, Seiten mit KI zu replizieren. Später habe ich einen Workflow entwickelt, um diese Probleme anzugehen, und den gesamten Prozess zur Referenz organisiert.

Das ist dir bestimmt auch schon passiert.

Manchmal wirfst du einem KI-Modell einen Screenshot hin und bittest es, eine Seite darauf basierend zu erstellen. Die erste Version sieht grob richtig aus, aber bei genauerem Hinsehen wirkt etwas seltsam: Karten sind leicht breiter, Schriftarten kleiner, Schatten falsch – nur kleine Details.

Dann musst du mündlich beschreiben, was angepasst werden muss und wie. Das Iterieren über mehrere Runden kostet ziemlich viel Zeit.

Also dachte ich daran, Rendering, Screenshots, Vergleich und Modifikation in einen Workflow zu ketten, damit das Modell sich selbst überprüft und korrigiert. Dieser Ansatz schien sinnvoll.

In der Praxis lief es jedoch nicht wie geplant. Manchmal wurden nach der Korrektur in Runde zwei die Änderungen in Runde drei wieder rückgängig gemacht; die Ergebnisse schwankten, und die Seite konnte mit jeder Iteration sogar schlechter werden.

Kommen wir direkt zum Punkt.

So sorgst du für Selbstkorrektur

Der Prozess ist nicht komplex:

1Ziel-Screenshot ──▶ Modell schreibt HTML ──▶ Browser rendert 1:1 Screenshot ──▶ Erzeugung eines Pixel-für-Pixel-Diffs
2                                                         │
3Beste Historie behalten ◀── Erneutes Rendern ◀── Modell diagnostiziert und bearbeitet Code ◀── Original + Gerendert + Diff

Der Diff repariert die Seite nicht automatisch für das Modell. Er verwandelt lediglich „sieht nicht ganz richtig aus“ in eine visuelle Karte spezifischer Abweichungen, die dann an das Modell zurückgegeben wird, damit es die nächsten Schritte entscheiden kann.

Um zu verhindern, dass das Modell blind aufgrund des Diffs rät, verlange ich vor jeder Änderung, dass es drei Fragen beantwortet:

1. Wo liegt das größte Problem?
2. Welches Element oder welche CSS-Eigenschaft hat es wahrscheinlich verursacht?
3. Wie plant es, das Problem zu beheben?

Erst nach Beantwortung dieser Fragen greifen wir in den Code ein.

Für diesen Test habe ich Ling-3.0-flash-VL verwendet und zwei Karten für eine einfache Demo ausgewählt: eine gelbe Karte mit hellem Hintergrund, dickem schwarzen Rand und hartem Schatten; die andere eine dunkle SaaS-Preiskarte mit Gradient-Buttons, Tags und Feature-Listen.

Ich finde, Karten sind perfekt dafür. Nicht zu viele Elemente, aber Breite, Weißraum, Button-Ausrichtung und Schatten – wenn einer davon nicht stimmt, fällt es sofort auf.

Erster Durchlauf

Beginnen wir mit der gelben Karte.

Nach der ersten Version war das Gesamtergebnis tatsächlich recht gut.

Struktur, Farbschema, Text und Button-Positionen waren größtenteils repliziert. Ohne direkten Side-by-Side-Vergleich mit dem Original könnte man denken, es sei nah genug dran.

Aber nebeneinander gelegt treten subtile Unterschiede zutage: Die Karte ist leicht größer, die Schriftgewichte unterscheiden sich, und Weißraum/Button-Größen sind nicht perfekt ausgerichtet.

Anschließend habe ich das Originalbild, das Ergebnis der ersten Runde und den Diff wieder an Ling gegeben und gebeten, diese Detailprobleme zu identifizieren.

Aus der Diagnose geht hervor, dass es nicht einfach nur sagt „nicht ähnlich genug“. Es lokalisiert Probleme wie Kartengröße, Schriften und Buttons und modifiziert anschließend das entsprechende CSS.

Vergleich der gelben Karte über drei Runden: Runde 2 verbesserte sich, Runde 3 verschlechterte sich, also behielten wir Runde 2 als historischen Bestwert bei.

Ein gutes erstes Ergebnis garantiert jedoch keine kontinuierliche Verbesserung.

Dieses Video zeigt das Problem: Runde 2 kam dem Original näher, aber Runde 3 fiel leicht zurück. Zum Glück wählte der Workflow nicht standardmäßig die letzte Runde als Endergebnis, sondern bewahrte den historischen Bestwert aus Runde 2 auf.

Den Diff zurückzuspielen bedeutet also nicht, dass das Modell plötzlich schlauer wird. Es kann viele Detailprobleme erkennen und Urteile auf spezifisches CSS abbilden, aber manchmal verwirrt es sich trotzdem.

Details dazu, wie der Workflow abläuft, findest du im folgenden Bildschirmaufzeichnung.

Volle Demo der dunklen Preiskarte: Auswählen der Assets, initiale Generierung, Slider-Vergleich, gefolgt von zwei Self-Healing-Runden.

Die Änderungen hier waren nicht dramatisch, weil die erste Runde bereits sehr nah am Ziel lag. Die folgenden Runden verbesserten sich weiter, konzentriert auf Kartengröße, abgerundete Ecken, Buttons und Verläufe.

Ein Vergleich beider Aufzeichnungen zeigt unterschiedliche Trends:

Die gelbe Karte verbesserte sich bis Runde 2, verschlechterte sich aber in Runde 3; die dunkle Karte zeigte über alle drei Runden hinweg stetige kleine Verbesserungen. Auch wenn zwei Aufzeichnungen keine statistischen Regeln beweisen, zeigen sie doch, dass derselbe Workflow nicht immer in jeder Runde bessere Ergebnisse liefert.

Offensichtliche Probleme werden meist in den ersten ein oder zwei Runden behoben. Spätere Iterationen beinhalten Feintuning von Schriftgrößen, abgerundeten Ecken und Schatten-Offsets, wobei das Beheben eines Problems oft ein anderes bricht. Daher speichere ich den historischen Bestwert, statt anzunehmen, dass die letzte Runde die Lösung ist.

Was kann es wirklich?

Aus diesen Ergebnissen lässt sich ableiten, dass die erste Version ein Standard-Screenshot-zu-Code-Prozess ist. Interessant ist, dass es nach Betrachtung des gerenderten Outputs Probleme auf spezifische Elemente und CSS-Eigenschaften eingrenzen kann, anstatt nur zu sagen „mach es ähnlicher“.

Selbst ohne automatische Korrektur dient dieser Diagnose-Schritt als nützliche Checkliste.

Viele visuelle Probleme lösen keine Fehlermeldungen aus. Wenn das Modell die tatsächlich vom Browser gerenderte Seite sehen kann, hat es die Chance, sich selbst weiter zu korrigieren.

Ein weiterer praktischer Punkt: Dieser Workflow erfordert wiederholte Modellaufrufe, daher ist Geschwindigkeit wichtig. Meine aufgezeichnete einzelne Generierung einer vollständigen HTML-Seite dauerte etwa 7 Sekunden. Öffentliche Daten zeigen, dass Ling-3.0-flash-VL insgesamt 124B Parameter hat, wobei 5,5B pro Inferenz aktiviert werden, plus zusätzliche Fähigkeiten für visuelles Verständnis und Visual Agent.

Die Zahl von 7 Sekunden basiert auf meiner spezifischen Schnittstelle und Einstellungen. Ich habe keine horizontalen Vergleiche durchgeführt und werde Geschwindigkeit/Kosten nicht allein aus den aktiven Parametern ableiten.

Wo liegen die Stolperfallen?

Der eigentliche Zeitaufwand lag nicht darin, das Modell anzubinden, sondern darin, präzises Feedback zu erhalten. Anfangs dachte ich, die Schwankungen bedeuteten Instabilität des Modells. Nach Überprüfung der Diffs einzeln wurde mir klar, dass ein Teil des Problems in meinem Feedback-Loop lag.

1. Erste Stolperfalle: Größe

Wenn das Zielbild skaliert war und der Browser in einer anderen Größe screenshotet wurde, passten die Bilder von Anfang an nie zusammen. Selbst bei korrektem Code zeigte der Diff große Abweichungen.

Bei Pixel-Diffs erzeugen globale Verschiebungen um wenige Pixel massive Fehlerzonen.

2. Zweite Stolperfalle: Animation

Einmal fügte das Modell Fade-in-Effekte für Feature-Listen hinzu. Screenshots, die mitten in der Animation aufgenommen wurden, zeigten transparenten Inhalt.

Nach dem Entfernen der Animationen sah die Seite visuell normal aus, aber die automatisierten Vergleichswerte verschlechterten sich.

Grund: Transparenter Inhalt ließ den Hintergrund durchscheinen, wodurch die Pixel-Algorithmen dachten, es „sehe ähnlicher aus“.

3. Dritte Stolperfalle: Versionierung

Wenn eine Runde das Design brach, führte das Fortsetzen mit Patches auf fehlerhaftem Code zu gestapelten Fehlern. Wie beim Bauen auf einem schiefen Fundament – je mehr man sich anstrengt, desto chaotischer wird es.

Kurz gesagt: Der Diff ist ein Werkzeug, kein Richter.

Wenn das Feedback falsch ist, erkennt das Modell das nicht. Es wird fleißig in die falsche Richtung korrigieren, basierend auf fehlerhaften Eingaben.

Fazit

Ich habe die Regeln auf drei Punkte reduziert:

1. Verwende identische Dimensionen für Original- und Browser-Screenshots; keine sekundäre Skalierung.
2. Fixiere Viewport, Schriftarten, Animationszustände und Screenshot-Timing.
3. Setze jede Runde auf der historischen Bestversion fort; patche keinen degradierten Code.

Funktionierender Code ist nur der erste Schritt. Probleme, die keine Fehler werfen, aber falsch aussehen, können tatsächlich von visuellen Modellen erkannt werden. Allerdings garantiert das Erkennen von Abweichungen nicht, dass die Korrekturen jedes Mal richtig sind.

Daher gehe ich nicht mehr davon aus, dass mehr Runden automatisch bessere Ergebnisse bedeuten. Erst offensichtliche Probleme beheben, stoppen, wenn die Verbesserungen stagnieren – das reicht für mich aus.

Das Modell ist Open Source und zwei Wochen lang kostenlos verfügbar. Um es selbst auszuführen, nutze diese Links 👇🏻:

• 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

Ps: Dieser Artikel wurde diktiert und von KI poliert, daher hat er Seele ✌🏻