Prompt-Engineering-Beispiele für Softwareentwickler
Konkrete Prompt-Engineering-Beispiele für Debugging, Refactoring, Tests, Architektur, Code-Review und Dokumentation.
Ein nützlicher Engineering-Prompt lässt den Assistenten aus Problem, Belegen, Einschränkungen und Akzeptanzkriterien schließen – nicht aus einer isolierten Anweisung. Die folgenden Beispiele zeigen, wie das Debugging, Refactoring, Tests, Architektur, Code-Review und Dokumentationsarbeit verändert.
Jeder bessere Prompt benennt bewusst konkret die Entscheidung, die der Assistent treffen muss. Du kannst ihn bei kleinen Aufgaben kürzen, solltest aber die Informationen bewahren, die eine für das Produkt falsche Änderung verhindern.
Eine instabile Kaufabwicklung debuggen
Problem
Eine Anfrage beim Checkout ist nach einem Wiederholungsversuch manchmal erfolgreich, aber die UI zeigt weiterhin den ersten Fehler.
Schwacher Prompt
Behebe den instabilen Checkout-Fehler.
Besserer Prompt
Symptom: Eine Checkout-Anfrage kann einmal wegen eines Timeouts fehlschlagen und beim
automatischen Wiederholungsversuch erfolgreich sein. Nach dem Wiederholungsversuch
erscheint der Erfolgsbildschirm nicht.
Erwartet: Ein erfolgreicher Wiederholungsversuch sollte den Fehlerzustand ersetzen und
den nächsten Checkout-Schritt aktivieren.
Beobachtet: Netzwerkprotokolle zeigen eine 200-Antwort, aber das erste Fehlerbanner bleibt.
Umfang: Prüfe nur die Checkout-Mutation, den Retry-Callback und den Bildschirmzustand.
Einschränkungen: Behalte die bestehende Zahlungsanbieter-Integration und Fehlermeldungen bei.
Verberge Fehler nicht, bevor eine Anfrage tatsächlich erfolgreich war.
Nenne zunächst zwei oder drei beleggestützte Hypothesen und die kleinste Reproduktion
oder das kleinste Log-Signal, das sie unterscheidet. Schlage dann eine minimale Korrektur
und einen Regressionstest vor.
Warum das funktioniert
Der Prompt trennt die Belege von der Annahme. Er fordert eine Diagnose der Zustandsübergänge vor einem Umschreiben und schützt die Zahlungsintegration vor einer nicht zusammenhängenden Änderung.
Wiederholte Formularlogik refaktorieren
Problem
Drei Einstellungsformulare wiederholen denselben Code für Lade-, Fehler- und Speicherzustand.
Schwacher Prompt
Refaktoriere diese Formulare, um Duplikate zu entfernen.
Besserer Prompt
Die Konto-, Benachrichtigungs- und Profilformulare duplizieren das Rendern des
Speicherzustands. Ermittle das exakt wiederholte Verhalten und die Stellen, an denen sich
die Formulare unterscheiden.
Ergebnis: Reduziere doppelte Darstellung, ohne öffentliche Formular-Props,
Zeitpunkt der Validierung, lokalisierte Fehler, Analytics-Ereignisse oder
Tastaturverhalten zu verändern.
Umfang: Die drei Einstellungsformulare und ihre direkten Tests.
Nicht-Ziel: Erstelle kein allgemeines Formular-Framework und verlagere die
Zuständigkeit für Anfragen nicht aus den bestehenden Feature-Hooks.
Empfiehl die kleinste Extraktion, zeige den bewahrten Vertrag und ergänze oder
aktualisiere Tests für Laden, Fehlschlag und Erfolg bei jedem Formular.
Warum das funktioniert
„Duplikate entfernen“ ist ein Ziel, kein Entwurf. Der bessere Prompt fordert den Assistenten auf, die tatsächliche gemeinsame Nahtstelle zu finden, und verhindert eine überdimensionierte Abstraktion.
Einen Test für eine Race Condition schreiben
Problem
Suchergebnisse einer langsamen alten Anfrage können eine neuere Anfrage überschreiben.
Schwacher Prompt
Füge Tests für die Suche hinzu.
Besserer Prompt
Füge Regressionstests für eine Race Condition bei der Suche hinzu.
Szenario: Ein Nutzer sucht nach "network", ändert die Anfrage sofort zu
"terminal", und die Netzwerkantwort trifft zuletzt ein.
Erwartet: Die UI zeigt nur Ergebnisse für "terminal". Die ältere Antwort darf sie
nicht ersetzen.
Verwende den bestehenden Test-Stack und zugängliche Assertions. Prüfe keine internen
Zustandsnamen. Falls der Produktionscode Abbruch oder Aktualität nicht klar ausdrücken
kann, erkläre die kleinste erforderliche Änderung, bevor du den Test schreibst.
Warum das funktioniert
Der Test-Prompt definiert Zeit, Nutzeraktion und sichtbares Verhalten. Er erlaubt nicht, dass ein bequemes Implementierungsdetail zum Vertrag des Tests wird.
Eine Architekturänderung bewerten
Problem
Ein Team entscheidet, ob es eine zweite Cache-Schicht für die Konfiguration hinzufügen soll.
Schwacher Prompt
Füge Caching für die Konfiguration hinzu, damit die App schneller wird.
Besserer Prompt
Bewerte, ob ein clientseitiger Konfigurations-Cache den langsamen Bildschirm verbessern
würde, ohne veraltete Berechtigungs- oder Präferenzentscheidungen zu erzeugen.
Kontext: Die App hat bereits einen Konfigurations-Provider und der Bildschirm wartet auf
einen authentifizierten Nutzer. Wir haben nicht gemessen, ob Abruf oder Rendering der
Engpass ist.
Vergleiche: keinen Cache, einen begrenzten In-Memory-Cache und den vorgeschlagenen
persistenten Cache. Bewerte Aktualität, Invalidierung, Datenschutz, Offline-Verhalten
und die Messung, die die Änderung rechtfertigen würde.
Implementiere nichts, bevor du sagst, welche Option du empfiehlst und warum.
Warum das funktioniert
Der Prompt macht „schneller“ messbar und fordert den Assistenten auf, die Prämisse zu hinterfragen. Ein Cache ist nicht automatisch eine Leistungsverbesserung.
Einen riskanten Diff prüfen
Problem
Ein Pull Request ändert Berechtigungen und nutzerseitige Navigation im selben Feature.
Schwacher Prompt
Prüfe diesen Pull Request.
Besserer Prompt
Prüfe diesen Diff auf Autorisierungsregressionen, Navigation, die die Locale beschädigt,
und durch Refactoring verdeckte Verhaltensänderungen.
Verfolge jede geänderte Berechtigungsentscheidung bis zu ihrem Aufrufer. Prüfe, dass
interne Links die aktive Locale bewahren und verweigerte Zustände keine geschützten
Daten offenlegen.
Melde nur Befunde mit Belegen aus dem Diff oder seinen direkten Aufrufstellen.
Priorisiere Korrektheit und Sicherheit vor Stilvorschlägen. Liste fehlende Tests
getrennt von bestätigten Defekten auf.
Warum das funktioniert
Das Review hat ein Bedrohungsmodell und einen Umfang. So entsteht ein kleineres, besser umsetzbares Ergebnis, als wenn du nur nach allgemeinem Feedback fragst.
Dokumentation nach einer Tool-Änderung aktualisieren
Problem
Der lokale Einrichtungsbefehl hat sich geändert, und der Leitfaden für den Einstieg ist jetzt veraltet.
Schwacher Prompt
Aktualisiere die Einrichtungsdokumentation.
Besserer Prompt
Aktualisiere den lokalen Einrichtungsleitfaden für die aktuellen Package-Skripte.
Prüfe jeden dokumentierten Befehl anhand von package.json und den Einrichtungsanweisungen
des Repositorys. Erkläre Voraussetzungen, erwartete Bereitschaftsausgabe, häufige
Fehlersignale und einen sicheren Wiederherstellungsweg.
Dokumentiere keine Geheimnisse, keine aus einer lokalen Umgebung kopierten Werte und keine
Befehle, die das Projekt tatsächlich nicht ausführt. Füge eine kurze Validierungs-Checkliste
für einen neuen Mitwirkenden hinzu.
Warum das funktioniert
Der Assistent muss den Text im Repository verankern, statt einen ausgefeilten, aber erfundenen Leitfaden zu erstellen.
Nutze das Beispiel, das zu deiner Aufgabe passt
Das wiederkehrende Muster ist einfach: Benenne das Problem, grenze den Umfang ein, schütze wichtiges Verhalten, fordere Belege an und definiere die Validierung. Beginne mit dem wiederverwendbaren Rahmen in wie man bessere KI-Prompts schreibt und lies dann Prompt Engineering für Entwickler für einen nach Engineering-Rollen organisierten Ablauf.
Produktionsprobleme brauchen eine noch strengere Belegkette. Lies weiter mit Prompt-Vorlagen zum Debuggen von Produktionsproblemen, bevor du einen Assistenten bittest, eine Korrektur für ein Live-System vorzuschlagen. Wenn ein Fehler Shell-Ausgabe oder ein Skript betrifft, reproduziere den Kommandozeilen-Workflow im Browser, bevor du eine Lösung automatisierst.
Quellen
Diese Dokumentationslinks liefern verlässliche Details zu den in diesem Artikel verwendeten Befehlen.