Feldnotizen

Das Prompting-Handbuch
für Entwickler:innen

Wie ich LLM-Ausgaben verlässlich genug für den Produktionseinsatz mache.

Kateryna Skoryna
Software Developer · 2026

Umblättern →

Ich diskutierte eine Stunde mit einer KI.
Am Ende lagen wir beide falsch – sie war nur selbstbewusster.

— Innenseite —

01 Grundlagen

Die Anatomie eines guten Prompts

Bevor meine eigenen Methoden ins Spiel kommen, gilt diese Grundlage fast überall: Ein guter Prompt besteht aus klar benannten Teilen. Nicht alle sind immer nötig – nur die Aufgabe ist unverzichtbar. Je mehr du ausdrücklich formulierst, desto weniger muss das Modell erraten.

RolleSag dem Modell, wer es sein soll. Das prägt Wortwahl, Tiefe und Ton.

AufgabeWas genau soll es tun? Der einzige zwingende Teil.

KontextZweck, Zielgruppe und Einschränkungen. Hier scheitern viele schwache Prompts.

FormatWie die Ausgabe aussehen soll: JSON, Stichpunkte, Tabelle oder feste Länge.

BeispieleEin oder zwei Eingabe→Ausgabe-Beispiele. Zeigen ist besser als beschreiben.

DenkenBei komplexen Aufgaben: erst schrittweise analysieren, dann antworten.

Reihenfolge – es gibt keine einzig richtige. Setze Kontext und Daten zuerst, die Anweisung zuletzt, damit das Modell erst handelt, nachdem es alles gelesen hat.

✦Beispiel

Rolle: Senior Full-Stack Engineer (React + Express), mit Fokus auf Performance.

Kontext: Die Seite lädt langsam – das Start-Bundle enthält Bibliotheken, die für den ersten Render nicht nötig sind.

Aufgabe: Imports in <code> refaktorieren, um das Start-Bundle zu verkleinern (Lazy Loading / Code Splitting), ohne öffentliche Props zu ändern.

Format: Nur den korrigierten Code in <answer> zurückgeben; dazu ein einzeiliger Kommentar, was ausgelagert wurde.

02 Meine Regeln

Meine Regeln – und die Fehler, aus denen sie entstanden

Die Grundlagen ergeben einen brauchbaren Prompt; diese Gewohnheiten machen die Ausgabe verlässlich genug, um darauf aufzubauen. Für mich ist ein Prompt wie Produktionscode: versioniert, getestet und anhand echter Fehler verbessert.

Was ich tue

Richtig starten

Zuerst ein gemeinsames Aufgabenverständnis. Ich kläre nach, bis das Modell die Aufgabe so versteht wie ich.
Stabile Regeln dauerhaft speichern – im System-Prompt, Gem oder Projekt – und dem Modell sagen, wer du bist.
Wiederverwenden – Assistenten bauen. Gems ≈ Projekte ≈ Custom GPTs; ein Meta-Prompt erstellt neue Entwürfe.

Präzise sein

Exakte Länge („3 Punkte, ≤12 Wörter“), nie nur „kurz“.
Dinge beim Namen oder mit Nummer nennen – das Modell sieht deinen Bildschirm nicht.
Eingaben isolieren – Daten ≠ Befehle.

Wie Code behandeln

Temperatur = Vielfalt, nicht Qualität.
Prompt korrigieren und neu generieren – nicht mit der Ausgabe diskutieren.
Wenige Regeln, keine Widersprüche.

Wie ich es gelernt habe

→ Temperatur 1.2 erfand eine falsche Tatsache → auf 0.9 gesenkt plus eine klare Regel zur FAKTENGENAUIGKEIT. (mehrschichtige Absicherung)

→ Ein Freitextfeld erlaubte beliebige Eingaben → eine enge CONTENT-MODERATION-Regel plus ein dauerhafter Regressionstest.

→ „Fortgeschritten“ war zu unklar → eine Beispielfrage pro Niveau. (ein Beispiel ist stärker als ein Adjektiv)

Nichts davon stammt einfach aus einem Leitfaden. Ich lese echte Ausgaben, führe jeden Fehler auf eine Lücke zurück, schließe sie und schreibe einen Test, damit sie geschlossen bleibt. Genau darin liegt die Fähigkeit.

03 Formate

Dasselbe Denken für drei Arten von Ausgabe

Prompting ist nicht nur Chat. Hier setze ich diese Prinzipien ein – mit dem wichtigsten Tipp für jedes Format.

CodeClaude / Gemini + Genkit

Anwendungsfall: Entwickler-Quizze in quizdom generieren und bewerten – typisiertes JSON (mit Zod validiert) plus ein zweites „Judge“-Modell, das das erste bewertet.

Tipp Strukturierte Ausgabe gegen ein Schema erzwingen, damit Abweichungen direkt am Aufruf abgefangen werden – statt drei Komponenten später einen Absturz auszulösen.

PräsentationenClaude

Anwendungsfall: Engineering-Design-Reviews und Erklärungen technischer Architekturen.

Tipp Das Modell soll mich zuerst interviewen – mit „Stelle mir vor der Erstellung alle nötigen Rückfragen.“ Danach: zuerst Gliederung, eine Idee pro Folie, exakte Anzahl („8 Folien“).

InfografikenNotebookLM (Gemini)

Anwendungsfall: Eine Spezifikation oder ein Dokument in eine klare Visualisierung für nichttechnische Personen verwandeln.

Tipp Es ist quellenbasiert (saubere Quellen rein = gute Visualisierung raus) und rendert über Nano Banana Pro. Schreibe den Bild-Prompt wie ein Regiebriefing: Zweck → Motiv → Stil → Komposition → Licht → Palette → Format. Beschreibe, was du willst, nicht was du vermeiden willst („eine leere Straße“, nicht „keine Autos“).

04 Meine Gems

Spezialisten, die ich einmal gebaut habe und wiederverwende

Gem-Architekt

Zweck — erstellt erste Anweisungsentwürfe für andere Gems (Meta-Prompting statt leerer Seite).

„Du bist Prompt-Engineer. Wenn ich einen Assistenten beschreibe, stelle Rückfragen und gib dann ein vollständiges Gem-Set aus: Rolle, Regeln, Ton, Ausgabeformat, zwei Beispielinteraktionen.“

Nutzen — „Ich möchte ein Gem, das X tut“ → sofort einsetzbare Konfiguration.

Persönliche Ernährungsberatung

Zweck — personalisierte Ernährungstipps, ohne meine Situation jedes Mal neu zu erklären.

„Du bist mein Ernährungscoach. Mein Ziel: fit bleiben. Praktische, konkrete Vorschläge; frage lieber nach, statt etwas anzunehmen; realistisch für einen vollen Terminkalender.“

Nutzen — konsistente, passende Antworten – der Kontext bleibt im Gem.

Senior Full-Stack Architekt

Zweck — Sparringspartner für Designentscheidungen, ohne meinen Stack jedes Mal neu zu erklären.

„…stelle zuerst Rückfragen, schlage dann 2–3 Ansätze mit Abwägungen vor, bevor du einen empfiehlst. Weise auf Skalierungsrisiken & Overengineering hin. Stack: React/Next + Node.js.“

Nutzen — eine zweite Meinung, die blinde Flecken und Overengineering früh erkennt.

Das Muster: Rolle + Regeln + Kontext + Ausgabeformat – schnell mit dem Architekten entworfen und bei der Nutzung verfeinert.

05 Checkliste

Das ganze Handbuch auf einer Seite

Das Modell passend zur Aufgabe wählen. Zuerst entscheide ich: schneller Fix oder komplexe Lösung? Für einfache Arbeit nehme ich ein schnelles, leichtes Modell; bei Unklarheit, Abwägungen oder mehreren Schritten eines mit stärkerem Reasoning.

Grundlagen abgedeckt – Rolle, Aufgabe, Kontext, Format?

Kontext und Warum genannt, nicht nur die Aufgabe?

Stabile Regeln stehen im System-Prompt, Gem oder Projekt?

Jede Länge als exakte Zahl, nie nur „kurz“?

Dinge mit klarem Namen oder Nummer bezeichnet?

Nicht vertrauenswürdige Daten isoliert und als Daten statt Befehle markiert?

Temperatur passend zur Aufgabe (hoch = Vielfalt, niedrig = reproduzierbar)?

Ausgabe mit einem Schema validiert, wenn sie in Code fließt?

Bei Fehlern den Prompt ändern und neu generieren – statt zu diskutieren?

Jede Regel aus einem echten Fehler abgeleitet – und keine Widersprüche?

"Jeder Fehler lehrt mich doppelt: Ich trainiere das Modell – und währenddessen lerne ich selbst. Es ist eine kontinuierliche Schleife: integrieren, ausliefern, lernen, wiederholen."

Ich bat die KI um sauberen Code.
Sie gab mir eine leere Datei.

Kontakt aufnehmen

Du fragst dich, welches KI-Tool wofür passt? Lies meinen Journal-Beitrag →

↳ Schreib mir. Prompt-Engineering ist nicht nötig.

Prompting Handbook