🤖 AI

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

HTMLCure führt ein zustandsgeleitetes Browser-Erfahrungs-Framework ein, das interaktives HTML durch deterministische Interaktionstrajektorien bewertet und repariert, wodurch ein Seed-Korpus signifikant zu einem hochwertigen Datensatz erweitert wird, der es einem 27B-Modell ermöglicht, auf interaktiven Web-Benchmarks eine Leistung zu erzielen, die mit führenden Systemen wie Kimi-K2.6 und GPT-5.4 vergleichbar ist.

Ursprüngliche Autoren: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

Veröffentlicht 2026-05-27

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das große Problem: „Sieht gut aus, ist aber kaputt"

Stellen Sie sich vor, Sie bitten einen sehr talentierten Künstler (eine KI), ein Spielzeugauto zu bauen. Der Künstler überreicht Ihnen ein wunderschönes Modell. Auf dem Foto sieht es perfekt aus. Aber wenn Sie versuchen, es zu schieben, fallen die Räder ab. Wenn Sie versuchen, zu lenken, dreht sich das Lenkrad nutzlos.

Das ist das aktuelle Problem mit von KI generierten Webseiten (HTML). Sie sehen oft in einem einzigen Schnappschuss (einem Screenshot) großartig aus, aber wenn eine echte Person versucht, auf Buttons zu klicken, nach unten zu scrollen, das Fenster zu vergrößern oder ein Spiel zu spielen, bricht die Seite zusammen.

Der alte Weg: Forscher nahmen früher ein Foto der Seite, prüften, ob sie hübsch aussah, und entschieden, ob sie „gut" war. Dabei wurden alle kaputten Räder übersehen.
Das Ergebnis: Sie warfen Tausende von Seiten weg, die eigentlich reparierbar waren, oder behielten Seiten, die gut aussahen, aber nicht funktionierten.

Die Lösung: HTMLCURE (Der „Probefahr"-Kfz-Mechaniker)

Die Autoren entwickelten ein System namens HTMLCURE. Anstatt nur ein Foto anzusehen, agiert HTMLCURE wie ein Mechaniker, der das Auto einer Probefahrt unterzieht.

So funktioniert es, Schritt für Schritt:

1. Die Probefahrt (Browser-Erfahrung)

Anstatt nur ein Foto zu machen, lädt HTMLCURE die Webseite in einen echten Browser. Es sitzt nicht nur da; es interagiert aktiv damit:

Es scrollt hoch und runter.
Es vergrößert und verkleinert das Fenster (wie beim Prüfen, ob ein Auto in eine kleine Garage passt).
Es klickt Buttons, fährt über Links und versucht, Spiele zu spielen.
Es protokolliert genau, was passiert: „Der Button funktionierte nicht", „Das Spiel eingefroren" oder „Das Layout brach auf dem Mobilgerät zusammen".

Analogie: Denken Sie daran als an einen Führerschein-Test für ein Auto. Sie schauen sich nicht nur den Lack an; Sie fahren damit, um zu sehen, ob der Motor startet, ob die Bremsen funktionieren und ob das Getriebe sauber schaltet.

2. Die Diagnose (Zustandssignal)

Nach der Probefahrt gibt das System der Seite eine „Gesundheitsnote" und eine Diagnose. Es kategorisiert die Seite in drei Gruppen, wie ein Arzt Patienten triagiert:

Niedrige Note (Das Wrack): Die Seite ist ein Chaos. Es fehlen große strukturelle Teile.
- Die Reparatur: Kompletter Neuaufbau. Versuchen Sie nicht, sie zu flicken; bauen Sie ein neues Auto von Grund auf neu.
Mittlere Note (Der Schrottkäfer): Die Seite funktioniert größtenteils, hat aber spezifische kaputte Teile (z. B. funktioniert das Radio nicht oder der Türgriff klemmt).
- Die Reparatur: Gezielte Reparatur. Diagnostizieren Sie das spezifische kaputte Teil und reparieren Sie nur das.
Hohe Note (Der Sportwagen): Die Seite ist bereits großartig.
- Die Reparatur: Nur polieren. Rühren Sie den Motor nicht an; vielleicht nur den Lack wachsen. Wenn Sie versuchen, etwas zu „reparieren", das nicht kaputt ist, könnten Sie es kaputt machen.

Kern-Erkenntnis: Das Papier behauptet, dass die Verwendung derselben Reparaturmethode für alle Seiten ein Fehler ist. Sie benötigen eine andere Strategie, je nachdem, wie kaputt die Seite tatsächlich ist.

3. Die Reparatur-Schleife (Der Feedback-Zyklus)

Sobald das System eine Strategie entscheidet (Neuaufbau, Flickwerk oder Polieren), bittet es die KI, die Seite zu reparieren.

Kritischer Schritt: Das System vertraut nicht einfach dem Wort der KI. Es nimmt die neue Version der Seite und führt die Probefahrt erneut durch.
Der Türsteher: Wenn die neue Version besser ist, behält sie sie. Wenn die neue Version schlechter ist (ein „Rückfall"), wirft sie sie weg und versucht es erneut.
Das Ziel: Es macht dies weiter, bis die Seite einen Qualitätsstandard von hoher Güte besteht (eine Note von 97/100).

Analogie: Stellen Sie sich einen Koch vor, der eine Suppe probiert. Wenn sie zu salzig ist, fügen sie Wasser hinzu. Dann probieren sie sie wieder. Sie gehen nicht einfach davon aus, dass das Wasser es repariert hat; sie verifizieren es. Wenn sie zu viel Wasser hinzufügen und sie jetzt zu fade ist, hören sie auf und versuchen ein anderes Rezept.

Die Ergebnisse: Aufbau einer besseren Bibliothek

Die Autoren nutzten dieses System auf einer riesigen Sammlung von 97.000 von KI generierten Seiten.

Sie begannen mit einem kleinen Haufen „perfekter" Seiten.
Sie nutzten HTMLCURE, um die „kaputten" zu reparieren.
Sie endeten mit 63.000 hochwertigen, verifizierten Seiten (im Vergleich zum ursprünglichen kleinen Set).

Anschließend nutzten sie diese neue, bereinigte Bibliothek, um ein neues KI-Modell zu trainieren (genannt HTMLCure-27B).

Das Ergebnis:

Das neue Modell ist deutlich besser darin, funktionierende Webseiten zu erstellen.
Es erreichte 50,6 Punkte auf einem strengen Test namens HTMLBENCH, was mit Top-Kommerziellen Modellen (wie Kimi-K2.6 und GPT-5.4) gleichauf liegt.
Auf einem anderen Test (MiniAppBench) verbesserte es sich um 15 Punkte im Vergleich zur untrainierten Version.

Zusammenfassung in einem Satz

HTMLCURE ist ein System, das verhindert, dass KI nur „rät", ob eine Webseite funktioniert; stattdessen zwingt es die KI, jede Seite zu probefahren, genau zu diagnostizieren, was kaputt ist, sie mit der richtigen Strategie zu reparieren und sie erneut zu testen, um sicherzustellen, dass die Reparatur tatsächlich funktioniert hat, wodurch eine riesige Bibliothek hochwertiger, funktionierenden Codes entsteht.

Technische Zusammenfassung: HTMLCure

Problemstellung

Large Language Models (LLMs) haben die Fähigkeit demonstriert, vollständige HTML-Seiten zu generieren, doch diese Ausgaben leiden häufig unter einem Problem der „oberflächlichen Korrektheit". Während eine generierte Seite in einem einzelnen statischen Screenshot korrekt dargestellt werden mag, versagt sie häufig unter dynamischen Bedingungen wie Scrollen, Hover-Effekten, Klicks, Größenänderungen oder Spielabläufen. Herkömmliche Evaluierungsmethoden, die sich auf statische Screenshots oder spärliche visuelle Spuren verlassen, übersehen diese interaktionsspezifischen Fehler. Darüber hinaus verwerfen Standardansätze zur Datenfilterung viele dieser Seiten als unbrauchbar, ohne zu erkennen, dass sie oft reparierbar sind. Die identifizierte Kernherausforderung besteht darin, dass die Datenkonstruktion für interaktives HTML ein Zustandsschätzproblem und nicht lediglich ein Bewertungsproblem ist; statische Beobachtungen können Fehler nicht aufdecken, die sich erst nach spezifischen Benutzerinteraktionen manifestieren.

Methodik

Die Arbeit stellt HTMLCURE vor, ein Browser-Erfahrungs-Framework, das entwickelt wurde, um interaktives HTML durch einen geschlossenen Regelkreis zu evaluieren, zu diagnostizieren und zu reparieren, der von Browser-Ausführungsspuren angetrieben wird.

1. Mehrdimensionaler Erfahrungs-Evaluierungs-Pipeline

Anstatt sich auf statische Screenshots zu verlassen, bewertet HTMLCURE ein HTML-Artefakt ( $h$ ) durch die Ausführung einer Sequenz von Betrachtungs- und Interaktionsaktionen ( $\pi$ ).

Vierschichtiges Erfahrungsprotokoll:
- L1 (Visuelle Beobachtung): Prüft das Ladeverhalten und die initiale Darstellung.
- L2 (Aktive Interaktion): Testet Steuerelemente, Hover-Zustände, Tastaturbelegungen und Scrollverhalten.
- L3 (Tiefes Gameplay): Führt aufgabengetriebene Rollouts für Spiele oder komplexe Benutzeroberflächen durch, um Zustandsübergänge, Zähler und Canvas-Änderungen zu verifizieren.
- L4 (Responsivität): Wählt repräsentative Schlüsselbilder aus der Ausführungs-Trajektorie mit Ereigniskontext aus.
Strukturierte Evidenz: Der Evaluierer erzeugt eine geordnete Spur $E(h, \pi)$ , die visuelle Evidenz ( $v_t$ , z. B. gerenderte Frames) und verhaltensbezogene Evidenz ( $b_t$ , z. B. DOM-Zustand, Konsolenfehler, Ergebnis von Sonden) enthält.
Bewertung mit fünf Komponenten: Eine Bewertung $S(h)$ wird aus fünf Dimensionen abgeleitet: Darstellung, Visuelles Design, Funktionalität, Interaktivität und Codequalität. Entscheidend ist, dass Visuelles Design die einzige Komponente ist, die von einem Vision-Language-Modell (VLM) basierend auf kuratierten Schlüsselbildern beurteilt wird; alle anderen Dimensionen verlassen sich auf deterministische Browserausführung und statische Analyse.

2. Zustandsbewusste Interaktive Reparatur-Engine

Der Reparaturprozess ist keine generische Neugenerierung, sondern eine kontrollierte Intervention basierend auf dem aktuellen Zustand der Seite.

Zustands-Routing: Das System klassifiziert Seiten basierend auf ihrer Bewertung $s$ $s$ in drei Zustände:
- Niedrig (< 40): Seiten ohne stabilen lokalen Zielzustand. Strategie: Ganzheitliche Neuschreibung.
- Mittel (40–79): Seiten mit nutzbarer Struktur, aber defektem Verhalten. Strategie: Diagnosegeleitete lokale Reparatur (z. B. Behebung spezifischer Interaktionsfehler).
- Hoch (≥ 80): Starke Seiten. Strategie: Erhaltung oder Gezielte Verfeinerung, um Regressionen zu vermeiden.
Geschlossener Regelkreis: Der Controller wählt eine Reparaturfamilie aus, fordert vom LLM Kandidaten an und führt jeden Kandidaten erneut im Browser aus.
Regressionserkennende Annahme: Kandidaten werden unter Verwendung einer zusammengesetzten Bewertung $S_{comp}$ ausgewählt, die Regressionen in Funktionalität und Interaktivität bestraft, wodurch sichergestellt wird, dass Verbesserungen im visuellen Design nicht auf Kosten defekter Logik gehen.
Beendigung: Die Schleife stoppt, wenn eine Seite eine hohe Zielbewertung (≥ 97) erreicht, eine Plateaubildung eintritt oder das Budget an Runden erschöpft ist.

3. Datenkonstruktion

HTMLCURE betrachtet Reparatur als Mechanismus zur Datenkonstruktion. Akzeptierte Reparaturen aus dem ursprünglichen Prompt-Korpus mit 97.000 Einträgen werden in einen verfeinerten Pool für Supervised Fine-Tuning (SFT) exportiert. Dieser Prozess erweitert den nutzbaren Datensatz von einem kleinen Subset „Hoher" Seiten auf einen größeren Pool von 63.703 qualitätsgeprüften Seiten, aus dem ein endgültiger Trainingsdatensatz von 40.000 Einträgen konstruiert wird.

Hauptbeiträge

Browser-Erfahrung als Reparatur-Zustandssignal: Die Arbeit zeigt, dass die Umwandlung von Browser-Ausführungsspuren in strukturierte Seitenzustände eine präzise Begrenzung der visuellen Beurteilung durch VLMs ermöglicht und spezifische Reparaturentscheidungen antreibt.
Zustandsbewusste interaktive Reparatur: Das Framework führt eine Strategie ein, bei der die Reparaturstrategie (Neuschreiben vs. Diagnostizieren vs. Erhalten) dynamisch basierend auf dem beobachteten Zustand der Seite ausgewählt wird. Dies verhindert die Zerstörung funktionierender Komponenten in hochwertigen Seiten und gewährleistet eine strukturelle Rekonstruktion für qualitativ minderwertige Seiten.
Reparatur als Datenkonstruktion: Durch die Validierung von Reparaturen mittels erneuter Ausführung erstellt das System ein hochwertiges, verifiziertes SFT-Korpus. Dieser Ansatz verwandelt das Paradigma der „Filterung" (Verwerfen schlechter Seiten) in ein Paradigma der „Wiederherstellung" (Reparieren und Verifizieren von Seiten).

Ergebnisse

Die Autoren evaluierten die Methodik unter Verwendung von HTMLBENCH-400, einem deterministischen, browserausführbaren Benchmark, sowie der Validierungsaufteilung von MiniAppBench.

Leistung: Unter derselben Backbone-Architektur (Qwen3.5) und demselben Trainingsrezept erreichte das Modell HTMLCure-27B-Refined:
- 50,6 auf HTMLBENCH-400 (Gesamtbewertung).
- 45,2 % Durchlaufquote bei deterministischen Testfällen.
- 81,2 im Durchschnitt auf der Validierungsaufteilung von MiniAppBench.
Vergleiche: Diese Ergebnisse platzieren das Modell in derselben Leistungsklasse wie starke Referenzsysteme wie Kimi-K2.6 und GPT-5.4.
Ablationsstudie: Kontrollierte Experimente mit gleichen Datenmengen (12.392 Beispiele) bestätigten, dass die Route „Refined" (unter Verwendung reparierter, verifizierter Daten) sowohl die Route „Raw" (originale Generierungen) als auch „Filtered" (nur originale hochwertige Seiten) übertrifft. Dies beweist, dass die Qualität der Supervision, die aus der Browser-Erfahrung abgeleitet wird, der primäre Treiber der Verbesserung ist und nicht nur das Datenvolumen.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass HTMLCURE das Paradigma der interaktiven HTML-Generierung von „generieren und filtern" zu „erfahren, reparieren und verifizieren" verschiebt.

Ausführung als Steuerung: Die zentrale Behauptung ist, dass Browserausführung nicht nur als endgültiger Pass/Fail-Richter verwendet werden sollte, sondern als kontinuierliches Steuersignal, das fehlende Struktur von defekter Interaktion trennt.
Datenqualität: Die Arbeit zeigt, dass das Reparieren schwacher und partieller Seiten unter zustandsspezifischer Kontrolle eine stärkere Supervision für SFT liefert als die einfache Auswahl bereits existierender hochwertiger Seiten.
Reproduzierbarkeit: Die Autoren stellen einen eingefrorenen Benchmark (HTMLBENCH) mit deterministischen Testfällen und eine vollständige Pipeline für reproduzierbare Vergleiche bereit und gehen damit über agentenbasierte Evaluierungen hinaus, denen standardisierte Fehleraufzeichnungen fehlen.

Die Arbeit bleibt hinsichtlich ihrer Grenzen bescheiden und räumt ein, dass das VLM immer noch für eine begrenzte Bewertung des visuellen Designs erforderlich ist, Browser-Sonden nicht jede mögliche Interaktion abdecken können und komplexe Spiele gekoppelte Timing-Fehler aufdecken können. Sie schlägt vor, dass zukünftige Arbeiten das Lernen von Routing- und Stopp-Strategien direkt aus Reparaturspuren umfassen könnten.