Tutorial 4 Prompting and Reviewing de

Tutorial 4 · Prompts formulieren und prüfen

🌎 Sprache: Deutsch — alle 33 Sprachen ansehen

Ziel: die Meta-Fähigkeit. Du kannst jetzt mit einem Agenten ein Feature bauen — in diesem Kapitel geht es darum, das reibungslos und wiederholbar zu tun: Prompts so zu formulieren, dass sie beim ersten Mal sitzen, Diffs effizient zu prüfen, zu iterieren, wenn etwas schiefläuft, und über mehrere Sessions hinweg Tempo zu halten.

← Zurück: Tutorial 3 Deine erste Aufgabe mit dem Agenten · Weiter: Tutorial 5 Lokalisierung

---

Formuliere Prompts wie ein Lead, nicht wie ein Suchfeld

Der Agent ist ein schneller, wörtlicher, eifriger Junior Engineer. Führe ihn so, wie du einen guten führen würdest:

• Nenne das Ziel und die Einschränkungen. „Füge endorse hinzu“ ist schwach. „Füge endorse hinzu, folge dem Muster von connect, nur RNG mit Seed, mit Tests, das Gate bleibt grün“ ist stark. Mit Einschränkungen bekommst du Code, der ins Projekt passt.
• Verweise auf Beispiele. „Folge dem Muster von renderConnect“ ist besser als ein ganzer Absatz Beschreibung. Bestehender Code ist die beste Spezifikation.
• Bitte bei allem, was nicht trivial ist, vor Edits um einen Plan. Einen Plan umzulenken ist billig; zehn bearbeitete Dateien wieder auseinanderzunehmen ist teuer.
• Eine Aufgabe pro Prompt. Wenn du „füge endorse hinzu, refaktorisiere außerdem den RNG und aktualisiere auch noch das README“ bündelst, bekommst du einen verhedderten Diff, der sich schwer prüfen lässt.
• Gib ihm das Test-Gate. „Führe npm test aus und betrachte es erst als fertig, wenn alles grün ist“ macht aus dem Agenten etwas, das seine eigene Arbeit überprüft.

Prüfe den Diff jedes Mal

Geschwindigkeit ist der ganze Punkt eines Agenten — aber ungelesene Geschwindigkeit ist, wie Bugs ausgeliefert werden. Gewöhn dir einen schnellen, konsistenten Prüfreflex an:

1. Umfang: Hat er nur das geändert, was er sollte? Nicht zusammenhängende verschobene Zeilen sind ein Warnsignal.
2. Muster: Passt es zum umgebenden Code, ohne neue Abhängigkeiten und ohne E/A in src/?
3. Die Regeln des Projekts: In diesem Repo heißt das nur RNG mit Seed (suche im Diff nach Math.random), sichtbarer Text in den Sprach-Bundles (nicht hartcodiert) und Kartenzeilen überschreiten nie die Breite, auf die das Layout auffüllt.
4. Barrierefreiheit: Überlebt neue Ausgabe --accessible? Führe lockedin --accessible <your command> aus und prüfe, ob sie sich als sauberer Klartext liest — keine neuen dekorativen Glyphen, die an a11yFilter vorbeirutschen.
5. Tests: Gibt es einen neuen Test, und würde er tatsächlich scheitern, wenn das Feature kaputtginge? Frag dich: „Welche Zeile müsste ich ändern, damit dieser neue Test fehlschlägt?“
6. Führe es aus: npm test, dann den Command starten und dir die Ausgabe ansehen.

Du musst nicht jedes einzelne Zeichen verstehen — aber jede Entscheidung. Wenn du eine Änderung nicht erklären kannst, lass sie dir vom Agenten erklären, bevor du sie akzeptierst.

Iteriere, wenn es nicht grün ist

Ein rotes Gate ist ein normaler Schritt, kein Scheitern. Die Lösung ist präzises Feedback:

„npm test schlägt fehl mit: [paste the exact error]. Der Breitentest für renderEndorse erwartet, dass jede Kartenzeile ≤ 60 sichtbare Spalten hat. Behebe das, ohne den Test abzuschwächen.“

Füge den tatsächlichen Fehlertext ein. „Es ist kaputt“ lässt den Agenten raten; der Stacktrace lässt ihn reparieren. Und mach nach Möglichkeit in derselben Unterhaltung weiter, statt neu anzufangen — der Agent hat bereits den Kontext dessen, was er gerade geschrieben hat. Wenn zwei oder drei Iterationen nicht zusammenlaufen, geh einen Schritt zurück und grenze die Aufgabe neu ein: Vielleicht ist sie zu groß für einen einzelnen Prompt.

Halte das Tempo über mehrere Sessions hinweg

Echte Arbeit dauert länger als eine Sitzung. Zwei Gewohnheiten halten einen Agenten langfristig wirksam:

• Memory / Konventionen. Wenn dein Agent dauerhafte Memory oder eine Datei mit Projektanweisungen unterstützt, halte dort die Regeln fest, denen er immer folgen soll (z. B. „jede Zufälligkeit muss pick/shuffle verwenden“, „vor dem Fertigmelden npm test ausführen“). Dann formulierst du eine Konvention einmal statt in jedem Prompt.
• Eine Handoff-Notiz. Dieses Repo hält ein kurzes, bereinigtes Statusdokument unter docs/HANDOFF.md: was das Projekt ist, wie es gebaut ist, wie es getestet wird und was als Nächstes ansteht. Wenn du zurückkommst (oder an einen Teamkollegen — oder einen anderen Agenten — übergibst), baut diese Notiz den Kontext in Sekunden wieder auf. Bitte deinen Agenten, sie als Teil einer Änderung aktuell zu halten.

Leitplanken, die du behalten solltest

• Das Gate ist nicht verhandelbar. Grüne Tests, bevor irgendetwas ausgeliefert wird. Nur so kannst du schnell sein und der Ausgabe vertrauen.
• Du bist der Reviewer mit Verantwortung. Der Agent schreibt; du entscheidest. Einen Diff zu akzeptieren heißt, dafür einzustehen.
• Kleine, überprüfbare Schritte schlagen einen gigantischen Sprung. Jede akzeptierte Änderung sollte die App funktionsfähig hinterlassen.

---

✅ Probier es mit deinem Agenten aus

1. Schreib eine Spezifikation von einem Absatz für einen mentor-Command („gibt ungefragt Ratschläge“), inklusive Einschränkungen, und lass den Agenten ihn test-first bauen — Plan, Tests, Code, Gate — mit Prüfung in jedem Schritt.
2. Bitte den Agenten, docs/HANDOFF.md zu aktualisieren, damit der neue Command erwähnt wird.
3. Mach absichtlich etwas kaputt (z. B. einen Pool-Eintrag löschen), führe npm test aus und übe, dem Agenten den exakten Fehler zur Reparatur zu geben.

---

Wohin du als Nächstes gehen kannst

• Überflieg den echten Code in src/lockedin.js — du kennst seine Form jetzt.
• Lies docs/HANDOFF.md für die projektinternen Status- und Architekturhinweise noch einmal.
• Genieße die Witze in der Befehlsreferenz.

Das ist das Tutorial. Du kannst jetzt einen KI-Agenten anleiten, echte Software hinter einem Test-Gate zu bauen und zu verändern — mit dem überheblichsten Beispiel, das man sich vorstellen kann. Stimmst du zu? 👇