Screenshot zu Code generieren mit Qwen 3.7 Plus

Geben Sie Qwen 3.7 Plus einen Screenshot einer Benutzeroberfläche, und das Modell kann daraus Front-End-Code generieren. Es verarbeitet Bild und Code gemeinsam, sodass ein Design-Mockup, eine Konkurrenzseite oder ein Figma-Export in einem Aufruf zu einer ersten React- oder HTML-Komponente wird. Dieser Leitfaden zeigt den praktischen Workflow: Screenshot senden, Prompt präzisieren, Ergebnis rendern, visuell nachbessern und anschließend mit echten APIs verbinden.

Probieren Sie Apidog noch heute aus

Wir behandeln den grundlegenden API-Aufruf, die wichtigsten Prompt-Details, die visuelle Feedbackschleife für bessere Genauigkeit und den Schritt von der generierten UI zur funktionierenden App. Für den Modellhintergrund siehe die Qwen 3.7 Plus Übersicht, und für das Request-Format den Qwen 3.7 Plus API Leitfaden. Die APIs und Endpunkte, die Ihre generierte UI später aufruft, können Sie parallel in Apidog testen.

TL;DR

Senden Sie einen Screenshot plus einen konkreten Prompt an Qwen 3.7 Plus und fordern Sie Code in Ihrem Ziel-Framework an. Der erste Durchlauf liefert meist eine brauchbare Struktur. Danach rendern Sie das Ergebnis, machen einen Screenshot davon und senden Original und Render zurück, damit das Modell Unterschiede korrigiert.

Qwen 3.7 Plus eignet sich für diesen Workflow, weil es Vision-Fähigkeiten mit solider Codegenerierung kombiniert, einen großen Kontext unterstützt und Iterationen pro Aufruf vergleichsweise günstig bleiben. Die Qualität hängt vor allem von Prompt, Zuschnitt des Screenshots und Feedbackschleife ab.

Warum Qwen 3.7 Plus dafür?

Screenshot-zu-Code erfordert zwei Fähigkeiten gleichzeitig:

1. Das Modell muss Layout, Farben, Abstände, Typografie und UI-Elemente aus dem Bild erfassen.
2. Es muss daraus sauberen, wartbaren Front-End-Code schreiben.

Qwen 3.7 Plus erreicht etwa 60% auf SWE-Bench Pro und 70,3 auf Terminal-Bench. Damit ist die Codegenerierung stark genug für UI-Prototypen und Komponenten. Der 1M-Token-Kontext hilft bei großen Designs, und mit 0,40 $ pro Million Input-Tokens lassen sich mehrere Iterationen durchführen.

Für den verwandten agentenbasierten Anwendungsfall, bei dem ein Modell eine UI bedient statt sie neu aufzubauen, siehe den Leitfaden zum Computer-Nutzungs-Agenten.

Der grundlegende Aufruf

Senden Sie den Screenshot als image_url zusammen mit einer Textanweisung. Das folgende Python-Beispiel nutzt den OpenAI-kompatiblen DashScope-Endpunkt:

import os
import base64
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DASHSCOPE_API_KEY"],
    base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)

def screenshot_to_code(png_path, prompt):
    with open(png_path, "rb") as f:
        b64 = base64.b64encode(f.read()).decode()

    resp = client.chat.completions.create(
        model="qwen3.7-plus",
        messages=[
            {
                "role": "user",
                "content": [
                    {
                        "type": "text",
                        "text": prompt,
                    },
                    {
                        "type": "image_url",
                        "image_url": {
                            "url": f"data:image/png;base64,{b64}"
                        },
                    },
                ],
            }
        ],
    )

    return resp.choices[0].message.content

prompt = """
Baue diese UI als einzelne React-Komponente nach.
Verwende Tailwind CSS.
Gib nur den Code zurück, keine Erklärung.
"""

print(screenshot_to_code("mockup.png", prompt))

Prüfen Sie vor dem Deployment die aktuelle Modell-ID in den Model Studio-Dokumenten.

Der minimale Aufruf funktioniert, aber ein kurzer Prompt erzeugt meist generischen Code. Für verwertbare Ergebnisse müssen Sie Stack, Einschränkungen und Qualitätskriterien angeben.

Einen Prompt schreiben, der versandfähigen Code liefert

Ein guter Screenshot-zu-Code-Prompt beschreibt nicht nur das Ziel, sondern auch die technischen Rahmenbedingungen.

Beispiel:

Wandle diesen UI-Screenshot in eine einzelne React-Komponente mit Tailwind CSS um.

Anforderungen:
- Triff Layout, Abstände und Farbpalette so genau wie möglich.
- Verwende responsive Breakpoints bis zu einer mobilen Breite von 375px.
- Nutze semantisches HTML.
- Verwende zugängliche Labels für Inputs und Buttons.
- Verwende Platzhalterdaten für dynamische Inhalte.
- Erfinde keine Backend-API.
- Gib nur den Komponenten-Code zurück, keine Prosa.

Geben Sie insbesondere an:

• Framework: React, Vue, Svelte oder HTML/CSS
• Styling-System: Tailwind CSS, CSS Modules, plain CSS oder Komponentenbibliothek
• Breakpoints: z. B. 375px, 768px, 1024px
• Accessibility-Anforderungen: Labels, Buttons, Fokuszustände
• Dynamische Inhalte: Platzhalter statt erfundener APIs
• Ausgabeformat: nur Code, keine Erklärung

Die Tailwind CSS-Dokumentation ist eine gute Referenz, wenn das Modell Utility-Klassen ausgeben soll.

Wenn Sie zusätzlich eine Komponentenspezifikation oder ein kurzes Design-Briefing bereitstellen, wird die Ausgabe stabiler. Der Artikel darüber, was eine design.md für Coding-Agenten leistet, erklärt, warum schriftliche Spezifikationen die Ergebnisse verbessern.

Die Lücke schließen mit einer visuellen Feedbackschleife

Der erste Durchlauf trifft die grobe Struktur, aber selten die exakten Abstände, Farben und Größen. Verwenden Sie deshalb eine kurze Feedbackschleife:

1. Generierte Komponente lokal rendern.
2. Screenshot des Renderings erstellen.
3. Original-Screenshot und Rendering-Screenshot gemeinsam an Qwen 3.7 Plus senden.
4. Unterschiede analysieren lassen.
5. Korrigierten Code anfordern.

Prompt-Beispiel:

Bild 1 ist das Ziel-Design.
Bild 2 ist mein aktuelles Rendering.

Aufgabe:
1. Liste die visuellen Unterschiede auf.
2. Korrigiere die React-Komponente so, dass Bild 2 Bild 1 näherkommt.
3. Achte besonders auf Abstände, Farben, Schriftgrößen und Ausrichtung.
4. Gib am Ende nur den vollständigen korrigierten Komponenten-Code zurück.

In der Praxis reichen oft zwei oder drei Runden, um aus einem groben Nachbau eine brauchbare UI-Komponente zu machen. Das Prinzip ist ähnlich wie bei einem Computer-Nutzungs-Agenten: Das Modell sieht den aktuellen Zustand, vergleicht ihn mit dem Ziel und korrigiert die nächste Aktion. Hier ist die Aktion jedoch Code statt Klicks.

Umgang mit echten Designs

Produktions-Mockups sind oft groß, detailreich und voller dynamischer Bereiche. Gehen Sie deshalb schrittweise vor.

1. Screenshot zuschneiden

Senden Sie nicht immer die gesamte Seite. Schneiden Sie den Bereich zu, den Sie gerade bauen:

• Header
• Sidebar
• Hero Section
• Pricing Cards
• Tabelle
• Formular
• Modal
• Dashboard-Widget

Kleinere Screenshots führen zu saubereren Prompts und besser fokussiertem Code.

2. Bildgröße reduzieren

Ein hochauflösender Screenshot kann viele Tokens verbrauchen. Skalieren Sie das Bild auf die kleinste Größe herunter, bei der Text und UI-Details noch lesbar bleiben.

Praktische Regel:

• Text muss lesbar bleiben.
• Icons müssen erkennbar bleiben.
• Abstände müssen grob sichtbar bleiben.
• Unnötige weiße Ränder entfernen.

3. Seite in Komponenten zerlegen

Fordern Sie nicht ein komplettes Dashboard in einem einzigen Aufruf an. Besser:

1. Header generieren
2. Sidebar generieren
3. Cards generieren
4. Tabelle generieren
5. Alles in einer Parent-Komponente zusammensetzen

Der große Kontext von Qwen 3.7 Plus hilft, aber kleinere Aufgaben erzeugen in der Regel wartbareren Code.

Bessere Ausgabe erhalten

Viele Probleme lassen sich mit einer Zeile im Prompt vermeiden.

Problem: Farben sind ungenau

Fügen Sie exakte Hex-Werte hinzu:

Verwende diese Farben exakt:
- Primary: #2563EB
- Background: #F8FAFC
- Border: #E2E8F0
- Text: #0F172A

Problem: Icons werden erfunden

Nennen Sie ein konkretes Icon-Set:

Verwende lucide-react für alle Icons.
Erfinde keine eigenen SVGs, außer wenn im Screenshot kein passendes Icon erkennbar ist.

Problem: Text wird erfunden

Lassen Sie Platzhalter verwenden:

Wenn Text im Screenshot nicht lesbar ist, verwende klar erkennbare Platzhalter wie "Produktname", "Beschreibung" oder "Status".
Erfinde keine realistisch klingenden Kundendaten.

Problem: Zu viele verschachtelte divs

Fordern Sie semantische Struktur:

Verwende semantische Elemente wie header, nav, main, section, article, form, label und button.
Halte die DOM-Struktur so flach wie möglich.

Problem: Komponente ist nicht responsive

Definieren Sie Breakpoints:

Die Komponente muss responsive sein:
- Mobile: 375px
- Tablet: 768px
- Desktop: 1280px
Nutze Tailwind-Breakpoints und vermeide horizontales Scrollen.

Diese Ergänzungen reduzieren die Anzahl der Nachbesserungsrunden deutlich.

Von der UI zur funktionierenden App

Generierter Front-End-Code ist nur die halbe Lösung. Eine echte Anwendung braucht:

• Daten für Listen, Tabellen und Cards
• Endpunkte für Formulare
• Authentifizierungszustände
• Fehlerzustände
• Ladezustände
• realistische Response-Strukturen

Entwerfen Sie diese Endpunkte früh, damit die generierte UI gegen eine stabile Schnittstelle entwickelt werden kann.

Mit Apidog können Sie den API-Vertrag definieren, Mock-Daten bereitstellen und Responses testen, bevor das Backend fertig ist. Der Leitfaden zum Spec-First-Modus zeigt diesen Workflow. Er passt gut zu KI-generierten Frontends und ebenso zu APIs, die in Cursor erstellt wurden.

Ein sinnvoller Ablauf:

1. UI-Screenshot mit Qwen 3.7 Plus in eine Komponente umwandeln.
2. Datenfelder aus der Komponente ableiten.
3. API-Schema in Apidog definieren.
4. Mock-Responses erstellen.
5. Komponente gegen Mock-API testen.
6. Backend implementieren.
7. API-Tests ausführen und Integration validieren.

Laden Sie Apidog herunter, um die APIs hinter der von Qwen 3.7 Plus generierten Benutzeroberfläche zu mocken und zu testen.

FAQ

Welche Frameworks kann Qwen 3.7 Plus ansprechen?

Alles, was Sie im Prompt angeben: React, Vue, Svelte, einfaches HTML und CSS, Tailwind CSS oder eine Komponentenbibliothek. Seien Sie explizit, sonst erhalten Sie eher generisches Markup.

Wie genau ist der erste Durchlauf?

Die Struktur ist oft nah am Ziel. Exakte Abstände, Farben und Typografie brauchen meist Nacharbeit. Die visuelle Feedbackschleife mit erneutem Screenshot ist der wichtigste Schritt für bessere Genauigkeit.

Kann es mit einem Figma-Design arbeiten?

Ja, wenn Sie den Frame als Bild exportieren. Das Modell liest das gerenderte Design, nicht die Figma-Datei selbst.

Wie halte ich die Token-Kosten niedrig?

Schneiden Sie den relevanten Bereich zu, skalieren Sie das Bild auf eine lesbare Größe herunter und generieren Sie große Seiten in mehreren Komponenten statt in einem einzigen Aufruf.

Baut es auch das Backend?

Nein. Es erzeugt Front-End-Code, der APIs erwartet. Die Endpunkte sollten Sie separat entwerfen, mocken und testen, zum Beispiel mit Apidog.

Das Fazit

Screenshot-zu-Code mit Qwen 3.7 Plus funktioniert am besten als iterativer Workflow: präziser Prompt, multimodaler Aufruf, lokales Rendering und visuelle Korrekturschleife. So entsteht schnell eine brauchbare Front-End-Komponente.

Für eine produktionsfähige Funktion braucht die UI jedoch stabile APIs. Generieren Sie das Frontend mit Qwen 3.7 Plus, definieren und mocken Sie die Endpunkte in Apidog, und testen Sie die Integration, bevor Sie das Backend final anbinden.