Plattform
Inspect-to-Prompt für ernsthafte KI-Softwarelieferung
Klicke auf ein beliebiges Element in der laufenden App, um es in deinem nächsten Prompt zu referenzieren — sodass die Änderung dort landet, worauf du gezeigt hast, nicht dort, was die KI geraten hat.
Inspect-to-Prompt ist eine Ciao-Builder-Funktion, mit der du auf ein beliebiges Element in der Live-Vorschau klicken kannst — einen Button, eine Tabelle, ein Diagramm oder ein Formularfeld — und es direkt in deinem nächsten Prompt referenzierst. Anders als UI in Worten zu beschreiben und zu hoffen, dass die KI dieselben Karten zählt wie du, macht Inspect-to-Prompt das Ziel eindeutig, sodass Änderungen auf die ausgewählte Komponente begrenzt landen, mit einem kleinen, prüfbaren Diff.
Veröffentlicht 2026-07-03 · Zuletzt aktualisiert 2026-07-03
Die meisten fehlgeschlagenen Prompts sind falsche Adressen, keine schlechten Ideen
„Mach die dritte Karte kleiner“ funktioniert genau so lange, bis die KI andere Karten zählt als du. Eine Benutzeroberfläche in Worten zu beschreiben ist eine verlustbehaftete Übung: dein „Header“, der „Header“ des Modells und der „Header“ des Codes können drei verschiedene Dinge sein. Mehrdeutigkeit geht rein, die falsche Änderung kommt raus, und du verbringst die nächsten drei Prompts damit, Schäden an Elementen rückgängig zu machen, die du nie erwähnt hast.
Inspect-to-Prompt entfernt das Adressierungsproblem. Die App läuft live neben dem Chat, während sie gebaut wird; klicke auf ein beliebiges Element in dieser Vorschau, und es wird in deinem nächsten Prompt referenziert. Der Builder weiß genau, welche Komponente du meinst — kein Zählen, kein Beschreiben, keine Vokabelverhandlung.
Es ist eine kleine Interaktion mit überproportionalen Folgen. Der Builder verbindet eine Konversation mit einer laufenden Anwendung genau deshalb, damit Zeigen möglich ist — die Vorschau ist kein Demo-Panel, sie ist ein gemeinsamer Bezugsrahmen zwischen dir und der KI.
Wie Inspect-to-Prompt funktioniert
Der Kreislauf dauert Sekunden, und er ist derselbe für einen Gründer, der eine Landingpage poliert, und einen Ingenieur, der eine Admin-Tabelle anpasst.
1. Die Live-Vorschau öffnen
Die Anwendung läuft neben der Konversation, während sie gebaut wird — echte Komponenten, echte Datenstrukturen, echte Klicks.
2. Auf das gemeinte Element klicken
Ein Button, eine Tabellenspalte, ein Diagramm, ein Formularfeld, ein verirrtes Label. Auswahl funktioniert auf der laufenden App, nicht auf einem Screenshot.
3. Es wird Teil deines nächsten Prompts
Das ausgewählte Element wird direkt im Prompt referenziert, sodass der Builder es zur exakten Komponente im Code auflöst.
4. Die Änderung in einfacher Sprache beschreiben
„Mach das zu einem Dropdown“, „verschiebe das über die Zusammenfassung“, „das sollte nur für Admins sichtbar sein.“ Das Was bleibt natürlich; das Wo ist schon geklärt.
5. Die Änderung landet abgegrenzt
Die Änderung zielt auf die ausgewählte Komponente und erzeugt einen kleinen Diff auf einem echten Git-Branch statt einer spekulativen Neuschreibung.
6. Sofort verifizieren
Die Vorschau aktualisiert sich neben dem Chat. Wenn es noch nicht stimmt, klicke erneut — Undo und Checkpoints machen Iteration billig.
Warum es wichtig ist
Präzision summiert sich. Wenn Änderungen dort landen, worauf du gezeigt hast, sinken Iterationen, schrumpfen Diffs, und Prüfung wird leichter — ein Prüfer, der bestätigt, „der ausgewählte Button hat sich geändert“, arbeitet schneller als einer, der eine Neuschreibung auditiert. Kleine, abgegrenzte Änderungen sind auch genau das, worin Guardrails und QA am besten sind.
Es erweitert auch, wer Arbeit lenken kann. Ein Gründer, Designer oder Kunde braucht kein CSS-Vokabular, um zu sagen, was er meint — er zeigt auf die laufende App. Die Lücke zwischen „Person, die das Problem sieht“ und „Person, die die Korrektur ausdrücken kann“ schrumpft auf einen Klick.
Teams spüren den Unterschied am meisten während Feedback-Runden. Ein Review-Call, bei dem angeforderte Änderungen landen, während Leute zusehen, ist eine andere Produktbeziehung als ein Call, der eine Ticketliste für nächste Woche produziert.
Wer Inspect-to-Prompt nutzt
Jeder, der das Problem sehen kann, kann es jetzt präzise adressieren:
- Gründer und Designer — Oberflächen durch Zeigen polieren, ohne den Unterschied zwischen Padding und Margin zu lernen.
- Agenturen — „Verschieb das dahin“-Kundenfeedback in exakte Änderungen während Review-Calls verwandeln, nicht danach.
- Product Manager — Änderungen genau an das Element lenken, über das sich ein Stakeholder beschwert hat, ohne Übersetzungsverlust durch Tickets.
- Entwickler — KI-Änderungen eng abgrenzen, sodass Diffs klein und Prüfungen schnell bleiben.
Hinweise zu Sicherheit und Governance
Präzision lockert die Regeln nicht — gezielte Änderungen durchlaufen dieselben Gates wie getippte.
- ✓ Abgegrenzte Änderungen erzeugen kleine, prüfbare Diffs auf echten Git-Branches.
- ✓ Jede Änderung — gezeigt oder getippt — durchläuft die Guardrails-Richtlinienprüfung vor dem Merge.
- ✓ Das unveränderliche Audit-Protokoll erfasst den Prompt und die resultierende Änderung zusammen.
- ✓ Undo und Checkpoint-Wiederherstellung machen jeden Fehltritt in Sekunden rückgängig.
- ✓ Rollenbasierte Zugriffskontrolle regelt, wer bearbeiten und wer mergen kann.
UI-Änderungen beschreiben: nur Worte vs Inspect-to-Prompt
Der Vergleich hört auf, subtil zu sein, nach dem ersten Nachmittag, an dem man beide Wege ausprobiert hat.
| Nur Worte | Inspect-to-Prompt | |
|---|---|---|
| Zielen | Hängt von gemeinsamem Vokabular und Zählen ab | Auf das exakte Element in der laufenden App klicken |
| Iterationen | Mehrere Versuche, während Beschreibungen verfeinert werden | Weniger — die Referenz ist eindeutig |
| Nebenwirkungen | Änderungen können auf ähnlich aussehenden Elementen landen | Auf die ausgewählte Komponente begrenzt |
| Diff-Größe | Oft größer als die Anfrage | Klein und an ein Element gebunden |
| Wer Arbeit lenken kann | Menschen, die UI-Vokabular fließend sprechen | Jeder, der auf das Problem zeigen kann |
Häufig gestellte Fragen
Funktioniert Inspect-to-Prompt in jedem Teil der App?
Du kannst Elemente über die gesamte laufende Oberfläche auswählen — Buttons, Tabellen, Diagramme, Formulare, Labels —, weil die Live-Vorschau die echte Anwendung ist, kein Bild. Die Auswahl löst sich zur tatsächlichen Komponente im generierten React- und TypeScript-Code auf.
Muss ich den Code verstehen, um es zu nutzen?
Nein. Du zeigst auf das Element und beschreibst die Änderung in einfacher Sprache. Der Builder übernimmt die Zuordnung vom ausgewählten Element zur Komponente im Code, und der Diff ist da für jeden, der ihn lesen möchte.
Was ist mit Änderungen, die viele Elemente gleichzeitig betreffen?
„Wende diesen Stil auf alle Zusammenfassungskarten an“ — beschreibe das Muster im Prompt, oder reihe eine Sequenz abgegrenzter Änderungen mit der Prompt-Warteschlange ein. Inspect-to-Prompt ist für Präzision; es hindert dich nicht daran, breite Änderungen vorzunehmen, wenn du sie willst.
Gibt es ein Protokoll dessen, was ausgewählt und geändert wurde?
Ja. Jede Änderung ist ein Diff auf einem Git-Branch, und das unveränderliche Audit-Protokoll erfasst Prompts, Merges und Deploys. Prüfer können sehen, was angefragt wurde und was sich genau geändert hat.
Ist Inspect-to-Prompt in Self-Service-Plänen enthalten?
Ja — es ist eine Kernfunktion des Builders, und einzelne Builder starten Self-Service mit Guthaben. Ernsthafte Produktionsprogramme beginnen bei 10.000 USD pro Jahr.
Verwandte Seiten
Bau die Software, auf die du früher warten musstest.
Inspect-to-Prompt: Auf die UI klicken, exakt prompten | Ciao