Aus Anforderungen einen klickbaren Prototyp mit KI erstellen

Ein Prototyp hat ansprechende Karten und bedienbare Schaltflächen, aber die Bestätigung einer Buchung ändert nichts. Anforderungen in einen interaktiven Prototyp umzuwandeln bedeutet, Verhalten zu spezifizieren und nicht nur nach einem Bildschirm zu fragen.

Definieren Sie die einzige Entscheidung des Prototyps

Verwenden Sie ein fiktives Beispiel für eine Buchung für zwei Sitzungen. Ein Besucher wählt den Vormittag oder den Nachmittag; Jeder startet mit zwei freien Plätzen. Eine Bestätigung reserviert einen Platz, eine wiederholte Bestätigung darf keinen anderen reservieren und eine Stornierung stellt diesen Platz wieder her.

Die Demo verwendet nur den Speicher der aktuellen Seite. Beim Neuladen wird die Demo zurückgesetzt; andere Browser-Tabs teilen ihren Kapazitätsstand nicht. Dabei handelt es sich um eine explizite Überprüfungsgrenze, nicht um ein produktionsreifes Buchungssystem.

Diese Tabelle ist präziser als „das Formular intuitiv gestalten“. Sie gibt dem Modell und dem Prüfer eine gemeinsame Definition von Erfolg.

Geben Sie der KI das Verhalten und den Implementierungsspielraum

Erstellen Sie einen HTML-Prototyp mit einer einzelnen Datei für den bereitgestellten Buchungsablauf.
Verwenden Sie native Beschriftungs-/Auswahl-/Schaltflächensteuerelemente und sichtbaren Statustext.
Anfangskapazität: 2 Vormittage, 2 Nachmittage. Eine Buchung pro Seitensitzung.
Keine Auswahl: Bestätigung deaktivieren. Bestätigen Sie nur, wenn die ausgewählte Kapazität positiv ist.
Während der Buchung: Wiederholte Bestätigungen und Auswahländerungen blockieren.
Stornieren: Stellen Sie genau einen Platz im gebuchten Slot wieder her und löschen Sie dann die Buchung.
Wiederholtes Abbrechen ist ein No-Op. Kündigen Sie Updates in einer höflichen Live-Region an.
Keine externen Bibliotheken, Netzwerkanrufe, persönliche Daten, Zahlung oder Persistenz.
Geben Sie vollständiges HTML, Anweisungen zum Öffnen und Annahmefälle zurück.
Beanspruchen Sie keine Parallelitäts- oder Produktionsreservierungsgarantien.

Senden Sie Zustandstabelle und Prompt und verlangen Sie eine vollständige HTML-Datei. Öffnen Sie sie und prüfen Sie die Abnahmefälle; ein Screenshot oder „implementiert“ ersetzt das bedienbare Ergebnis nicht.

Von der EvoLink-Anfrage zur prüfbaren Datei

1. Öffnen Sie die EvoLink-Seite für Gemini 4 und folgen Sie der Anleitung für Agent oder API. Übermitteln Sie Zustandstabelle und Prompt zusammen. Ergänzen Sie zwei Testszenarien: regulär 2/2 Plätze, vormittags ausgebucht 0/2. Ein Szenariowechsel setzt Auswahl und Buchung zurück. Verlangen Sie ein übersichtliches Layout, freie Plätze und eindeutige Meldungen für Buchung, Stornierung und ausgebuchte Termine.
2. Fordern Sie ein vollständiges HTML-Dokument mit Styles und Skript an. Ein Agent soll es als booking.html speichern; bei einem API-Client speichern Sie den zurückgegebenen HTML-Text ohne Markdown-Codezäune. Speichern Sie nicht die JSON-Antworthülle als HTML. Prüfen Sie vor dem Öffnen auf unerwartete externe Skripte und Netzwerkanfragen.
3. Öffnen Sie booking.html im Browser. Wählen Sie im normalen Szenario Morning und bestätigen Sie: Die freien Plätze sinken von 2 auf 1, eine Buchungsbestätigung erscheint. Nach der Stornierung sind wieder 2 Plätze frei und die Auswahl ist leer. Auch ein erneuter Aufruf des Stornierungs-Handlers im Test darf daraus nicht 3 machen.
4. Wählen Sie Morning full, dann Morning: 0 freie Plätze, eine verständliche Meldung und keine mögliche Bestätigung. Afternoon bleibt buchbar; nach der Bestätigung sinkt die Zahl von 2 auf 1. Normal setzt die Buchung zurück und stellt 2/2 wieder her. Diese Steuerung setzt Testdaten und simuliert weder andere Nutzer noch konkurrierende Serverzugriffe.
5. Bei Fehlern übermitteln Sie Ausgangszustand, Klickfolge, Soll- und Ist-Ergebnis sowie HTML über denselben Zugang. Lassen Sie gezielt korrigieren und prüfen Sie beide Szenarien erneut. Erfassen Sie akzeptierte Ergebnisse und Verbrauch, bevor Sie über das Gateway ein anderes Modell vergleichen; eine erzeugte Datei allein belegt weder Qualität noch Kostenvorteile.

Ein vollständig lauffähiger Referenzprototyp

Die folgende Referenz wurde als Lehrbeispiel verfasst und ist keine protokollierte Modellantwort. Die Oberfläche bleibt in allen Sprachfassungen englisch, damit die ausführbare Datei identisch ist. Layout und Rückmeldungen erleichtern die Prüfung; sie ersetzen kein fertiges Produktdesign.

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Session booking · Review prototype</title>
<style>
* { box-sizing: border-box; }
body { margin: 0; background: #f4f6f8; color: #172033; font: 16px/1.6 system-ui, sans-serif; }
main { max-width: 640px; margin: 48px auto; padding: 28px; background: white; border: 1px solid #dce2ea; border-radius: 16px; }
h1 { margin: 8px 0; font-size: 30px; line-height: 1.2; }
p { margin: 12px 0; }
.eyebrow { color: #526077; font-size: 13px; text-transform: uppercase; letter-spacing: .08em; }
label { display: block; font-weight: 600; margin: 16px 0 6px; }
select, button { font: inherit; padding: 10px 14px; border: 1px solid #aeb9c8; border-radius: 8px; }
select { width: 100%; background: white; color: #172033; }
.actions { display: flex; flex-wrap: wrap; gap: 10px; margin-top: 20px; }
button { cursor: pointer; background: white; color: #172033; }
#confirm { background: #193e87; color: white; border-color: #193e87; }
button:disabled { opacity: .5; cursor: not-allowed; }
:focus-visible { outline: 3px solid #b56b00; outline-offset: 3px; }
#status { background: #edf3fc; padding: 16px; border-radius: 8px; }
small { display: block; color: #526077; }
fieldset { margin: 28px 0 0; padding: 16px; border: 1px dashed #aeb9c8; border-radius: 8px; }
legend { font-weight: 600; }
@media (max-width: 680px) { main { margin: 16px; padding: 20px; } }
</style>
</head>
<body><main>
<p class="eyebrow">Interactive prototype · Local demo</p>
<h1>Book a workshop session</h1>
<p>Choose a session, confirm your place, or cancel to release it.</p>
<p id="capacity"></p>
<label for="slot">Session</label>
<select id="slot"><option value="">Choose a session</option>
<option value="am">Morning</option><option value="pm">Afternoon</option></select>
<div class="actions">
<button id="confirm" type="button" disabled>Confirm booking</button>
<button id="cancel" type="button" disabled>Cancel booking</button>
</div>
<p id="status" role="status" aria-live="polite"></p>
<small>One booking per page. Refresh resets this demo; other tabs do not share availability.</small>
<fieldset><legend>Review scenarios</legend>
<label for="scenario">Starting availability</label>
<select id="scenario"><option value="normal">Normal · 2 morning / 2 afternoon</option>
<option value="full">Morning full · 0 morning / 2 afternoon</option></select>
<p><small>Changing the scenario clears the current booking and selection. This control is for review only.</small></p>
</fieldset>
</main>
<script>
const capacity = { am: 2, pm: 2 };
const names = { am: "Morning", pm: "Afternoon" };
let selected = "";
let booking = null;
const slot = document.getElementById("slot");
const scenario = document.getElementById("scenario");
const confirmButton = document.getElementById("confirm");
const cancelButton = document.getElementById("cancel");
const status = document.getElementById("status");
const availability = document.getElementById("capacity");
function render(message = "") {
  const valid = Object.hasOwn(capacity, selected);
  confirmButton.disabled = !valid || booking !== null || capacity[selected] <= 0;
  cancelButton.disabled = booking === null;
  slot.disabled = booking !== null;
  availability.textContent = `Available: morning ${capacity.am}, afternoon ${capacity.pm}`;
  status.textContent = message || (booking !== null
    ? `Booked: ${names[booking]}. Your place is reserved in this demo.`
    : valid && capacity[selected] === 0
      ? `${names[selected]} is full. Choose another session.`
      : "Choose a session to book your place.");
}
slot.addEventListener("change", () => { selected = slot.value; render(); });
confirmButton.addEventListener("click", () => {
  if (!Object.hasOwn(capacity, selected) || booking !== null || capacity[selected] <= 0) return;
  capacity[selected] -= 1;
  booking = selected;
  render();
});
cancelButton.addEventListener("click", () => {
  if (booking === null) return;
  const cancelled = names[booking];
  capacity[booking] += 1;
  booking = null;
  selected = "";
  slot.value = "";
  render(`${cancelled} booking cancelled. Your place has been released.`);
});
scenario.addEventListener("change", () => {
  capacity.am = scenario.value === "full" ? 0 : 2;
  capacity.pm = 2;
  booking = null;
  selected = "";
  slot.value = "";
  render("Review scenario reset. Choose a session to test it.");
});
render();
</script>
</body></html>

Testen Sie das Verhalten, bevor Sie das Layout polieren

Beginnen Sie ohne Auswahl und stellen Sie sicher, dass die Bestätigung deaktiviert ist. Wählen Sie „Vormittag“, bestätigen Sie und überprüfen Sie, ob der Status „gebucht“ lautet. Stornieren Sie die Buchung und überprüfen Sie, ob beide Kapazitäten auf zwei zurückgehen. Wiederholen Sie die Stornierung über die Benutzeroberfläche oder automatisierte Prüfungen und stellen Sie sicher, dass kein Drittplatz entstehen kann.

Versuchen Sie es dann mit einem anderen Slot. Überprüfen Sie, ob die Buchung gelöscht ist, bevor Sie die nächste Auswahl ändern. Die Prüfungen des Handlers sind wichtig, auch wenn die Schaltfläche deaktiviert ist: Der Zustandsübergang sollte gültig bleiben, wenn der Code den Handler erneut aufruft.

Der ausgebuchte Termin lässt sich jetzt unter Review scenarios direkt prüfen. Netzwerkfehler und laufende Anfragen gehören noch nicht zu diesem lokalen Beispiel; definieren Sie diese Zustände vor dem Anschluss eines echten Dienstes.

Finden Sie Lücken in den Anforderungen, nicht nur Fehler in HTML

In der nächsten Implementierungsphase sollten maßgebliche Kapazität und Reservierungslogik auf einem Backend mit der erforderlichen Konfliktbehandlung bereitgestellt werden. Betrachten Sie den lokalen Zähler nicht als Beleg dafür, dass die gleichzeitige Buchung funktioniert.

Verwenden Sie für eine echte Next.js-Anwendung das Komponentensystem und die Statusgrenzen des Repositorys, anstatt eine eigenständige Seite in die Produktion einzufügen. Die HTML-Datei ist ein Überprüfungsartefakt, das die Produktentscheidung konkretisiert.

Anforderungen mit der Arbeitsdatei übergeben

Speichern Sie die Anforderungsrevision, den Prototyp, die Abnahmetabelle, die beobachteten Testergebnisse und ungelöste Produktfragen. Wenn ein Prüfer die Stornierungsregel ändert, aktualisieren Sie sowohl die Zustandstabelle als auch die Schnittstelle und führen Sie dann die betroffenen Fälle erneut aus.

FAQ

Benötigt ein anklickbarer Prototyp ein Backend?

Nicht um diesen lokalen Ablauf zu demonstrieren. Gemeinsame Reservierungen und dauerhafte Kapazität erfordern eine maßgebliche Implementierung.

Was sollte ich außer einer Designreferenz angeben?

Zustände, Aktionen, erwartete Ergebnisse, Fehlerverhalten und Umfang. Ein Bild allein definiert nicht die Übergangsregeln.

Ist das Deaktivieren der Schaltfläche eine ausreichende Validierung?

Überprüfen Sie auch den Übergangshandler. Der UI-Status sollte nicht das Einzige sein, was ungültige Updates verhindert.

Warum die Stornierung zweimal testen?

Es erfasst Logik, die die Kapazität für eine Buchung mehr als einmal wiederherstellt.

Kann ich das direkt in die Produktion kopieren?

Passen Sie es an die Anwendungsarchitektur an und implementieren Sie die fehlenden Anforderungen an Backend, Validierung und Barrierefreiheit, bevor Sie sich darauf verlassen.

Was macht den Prototyp bereit für die Überprüfung?

Er lässt sich öffnen, die vereinbarten Interaktionen funktionieren, Einschränkungen werden in der Übergabe sichtbar und der Prüfer kann die Akzeptanzfälle reproduzieren.

Quellen

• MDN: Schaltfläche.
• MDN: aria-live.