Für mich ist KI am stärksten, wenn ich das Ziel und den fachlichen Kontext kenne, aber nicht jede Syntax, jedes Detail oder jeden möglichen Lösungsweg selbst beherrschen muss.
1. Das Problem kommt zuerst
Ich starte möglichst nicht mit „Schreib mir Code“, sondern mit der Frage: Was soll am Ende funktionieren? Welche Daten habe ich? Was darf sich ändern und was nicht? Wer soll die Lösung später bedienen? Und woran erkenne ich, dass sie wirklich funktioniert?
Ein halber Absatz guter Kontext ist für ein reales Projekt oft wertvoller als ein kunstvoll formulierter Einzeiler.
2. Ein guter Prompt besteht für mich aus Bausteinen
| Baustein | Frage dahinter |
|---|---|
| Ziel | Was soll am Ende konkret funktionieren? |
| Ausgangslage | Welche Dateien, Systeme oder Daten existieren bereits? |
| Grenzen | Was darf nicht verändert werden? Welche Technik soll bewusst vermieden werden? |
| Erwartung | Brauche ich Erklärung, Entwurf, fertigen Code, Prüfschritte oder mehrere Varianten? |
| Prüfung | Wie testen wir anschließend, ob die Lösung wirklich stimmt? |
3. Bei länger laufenden Projekten kommen Grundregeln dazu
Wenn ein Projekt größer wird, möchte ich bestimmte Arbeitsweisen nicht in jedem einzelnen Prompt neu erklären. Deshalb halte ich Grundsätze dauerhaft fest – zum Beispiel in Projektanweisungen, Projektdokumentationen oder einer methodischen Basis.
- Bei aktuellen oder unklaren Themen nicht raten, sondern aktuelle Quellen prüfen.
- Unsicherheiten sichtbar benennen.
- Bei technischen Änderungen immer vom zuletzt bestätigten Quellstand ausgehen.
- Spezifische Projektdokumentation hat Vorrang vor allgemeinen Annahmen.
- Keine Zugangsdaten in normale Arbeitsdialoge übernehmen.
- Bei Code erklären, was wo passiert, statt nur einen Block zum Kopieren hinzustellen.
4. Ich lasse mir nicht nur das Ergebnis geben
Bei VBA, Excel, JavaScript oder Webtechnik möchte ich erklärt bekommen, wo Daten gelesen, verarbeitet, geprüft und geschrieben werden. Ich muss den Code nicht komplett selbst schreiben können. Aber ich möchte ihn so weit verstehen, dass ich bei einem Fehler eine sinnvolle Vermutung habe.
5. Bestehende Lösungen dürfen bleiben – oder besser werden
Eine alte Lösung ist nicht automatisch schlecht. Meine frühere Kickbase-Exceldatei hat funktioniert. Später war aber die spannende Frage: Wenn neue Werkzeuge verfügbar sind, lässt sich dieselbe Aufgabe heute einfacher, robuster oder schneller lösen?
6. Ich teste gegen die Realität
Ein Code kann logisch aussehen und trotzdem auf dem Smartphone schlecht sein. Eine API kann andere Daten liefern als erwartet. Ein Webserver kann eine Konfiguration anders behandeln als gedacht. Und eine KI kann eine Schnittstelle sehr überzeugend falsch beschreiben.
Deshalb gehören echte Tests zum Arbeitsweg. Erst der Test macht aus einer plausiblen Antwort eine belastbare Lösung.
7. Bei größeren Projekten wird dokumentiert
Wenn ein Projekt nach Wochen weitergehen soll, reicht der Chatverlauf nicht als technische Dokumentation. Deshalb entstehen bei größeren Vorhaben ein bestätigter Quellstand und eine Projektdokumentation. So kann ein neuer Chat oder ein anderer Bearbeiter wieder einsteigen, ohne die gesamte Geschichte rekonstruieren zu müssen.
LSD Worringen und PODC sind dafür gute Beispiele: Die Dokumentation ist nicht hübsches Beiwerk, sondern Teil der technischen Lösung.
8. Sensible Daten bleiben draußen
Kennwörter, Tokens und unnötige vertrauliche Informationen gehören nicht in normale Arbeitsdialoge. Wenn echte Daten nötig sind, wird möglichst nur das geteilt, was für die konkrete Aufgabe gebraucht wird.
Meine typische Arbeitsteilung
| Aufgabe | Typisch |
|---|---|
| Idee, Ziel, fachliche Anforderungen | ich |
| Varianten, Recherche, Syntax, erster Code | häufig KI-unterstützt |
| Abwägen und Prioritäten | gemeinsam, Entscheidung bei mir |
| Praxistest mit echten Daten/Geräten | ich |
| Fehlersuche und Überarbeitung | gemeinsam |
| Dokumentation | gemeinsam, fachlich freigegeben |
Aktueller Produkt-Hinweis zu ChatGPT
Stand September 2026 lassen sich in ChatGPT sowohl benutzerdefinierte Anweisungen als auch projektspezifische Anweisungen verwenden. Das ist praktisch, um Arbeitsweisen dauerhaft festzuhalten. OpenAI weist gleichzeitig selbst darauf hin, dass ChatGPT falsch oder irreführend antworten und dabei trotzdem sehr sicher klingen kann. Wichtige Informationen sollten deshalb anhand verlässlicher Quellen überprüft werden.
Produktfunktionen und Einstellungswege ändern sich. Deshalb beschreibe ich sie hier bewusst nicht als für alle Zeiten gültige Klickanleitung. Wer das aktuell nachsehen möchte, findet die offiziellen Hinweise bei OpenAI zu benutzerdefinierten Anweisungen, Projekten und Projektanweisungen sowie zur Frage „Sagt ChatGPT die Wahrheit?“.
Der ausführlichere Gedanke dahinter steht im Grundsatzartikel „Von der Idee zum Ergebnis“. Warum ein vermeintlich perfekter Prompt nicht reicht, beschreibe ich in „Warum ein guter Prompt allein nicht reicht“.