IDE-Setup für Prompt Engineering
📍 In One Sentence
Cursor und VS Code mit Continue.dev sind die zwei IDEs, die die meisten Entwickler-Prompt-Engineering-Anforderungen abdecken — Cursor für Cloud-API-Workflows, Continue.dev für Open-Source- und lokale Modellanforderungen.
💬 In Plain Terms
Wählen Sie die IDE, in der Sie bereits die meiste Zeit verbringen. Wenn Sie TypeScript oder Python verwenden und Cloud-APIs aufrufen, bietet Cursor die geringste Reibung. Wenn Sie Modelle lokal ausführen müssen oder Open-Source-Anforderungen haben, ist VS Code mit Continue.dev die richtige Wahl.
Zwei IDEs decken die meisten Entwickler-Prompt-Engineering-Anforderungen ab: Cursor (native KI-Integration, Prompts als First-Class-Citizens) und VS Code mit Continue.dev (Open Source, lokale Modellunterstützung). Die Wahl hängt von der primären Programmiersprache und den Modell-Zugriffsanforderungen ab.
Cursor behandelt Prompt-Dateien nativ — Sie können Prompts direkt im Editor neben Ihrem Anwendungscode referenzieren, bearbeiten und testen. Es bietet native Integration mit OpenAI-kompatiblen APIs und unterstützt TypeScript und Python gut. Verwenden Sie Cursor, wenn Sie hauptsächlich in diesen Sprachen arbeiten.
VS Code mit Continue.dev ist Open Source, unterstützt lokale Modelle über Ollama und funktioniert mit jedem Sprachökosystem. Continue.dev bietet In-Editor-Prompt-Vervollständigung und -Bearbeitung. Verwenden Sie VS Code + Continue.dev bei Open-Source-Anforderungen oder bei der Notwendigkeit, Modelle lokal auszuführen.
💡 Cursor für schnelle Prompt-Iteration
Cursor ermöglicht das direkte Ausführen von Claude 4.6 Sonnet auf Prompt-Dateien aus dem Editor heraus. Das reduziert den Schreib-Test-Zyklus für Teams, die bereits Cursor für Code verwenden, von Minuten auf Sekunden.
Die lokale Prompt-Testschleife
Die lokale Prompt-Testschleife hat 4 Schritte: Prompt schreiben, auf 3 repräsentativen Eingaben testen, mit der Baseline vergleichen und committen, wenn erfolgreich. Diese Schleife sollte mit lokal konfiguriertem Promptfoo unter 30 Sekunden dauern.
Schritt 1: Prompt im IDE schreiben oder bearbeiten. Schritt 2: Prompt gegen 3 repräsentative Eingaben ausführen — eine typische Eingabe, einen Edge Case und eine, die zuvor einen Fehler verursacht hat. Schritt 3: Ausgabe mit der Baseline vergleichen (letzte committete Version). Schritt 4: Bei gleichbleibender oder verbesserter Qualität mit einer Conventional-Commit-Message committen.
Promptfoo für die lokale Schleife einrichten: mit `npm install -g promptfoo` installieren, eine `promptfooconfig.yaml` im Projektstamm mit 3 Testfällen und einem LLM-as-Judge-Evaluator erstellen. `promptfoo eval` ausführen. Die Gesamteinrichtungszeit beträgt unter 15 Minuten für einen bestehenden Prompt.
⚠️ Baseline-Vergleich ist nicht optional
Ohne Vergleich mit einer Baseline kann ein Prompt, der bei Edge Cases schlechter wird, dennoch "bestehen", wenn der absolute Schwellenwert niedrig genug ist. Immer mit der letzten deployten Version vergleichen.
Prompts in der Versionskontrolle speichern
Prompts als `.txt`- oder `.ts`-Dateien in einem `/prompts`-Verzeichnis im Repository-Stamm speichern. Die Versionierung von Prompts in Git bietet dieselben Vorteile wie die Versionierung von Code: vollständige Historie, Blame, Rollback und PR-basierte Überprüfung.
Namenskonvention: `task-version.txt` — zum Beispiel `kundenbetreuung-v3.txt`, `email-entwurf-v1.txt`. Sequentielle Versionsnummern verwenden, keine Datumsangaben. Veraltete Prompts in `/prompts/archive/` verschieben statt löschen.
Conventional Commits für Prompt-Änderungen verwenden: `feat: Few-Shot-Beispiele zum Kundenbetreuungs-Prompt hinzugefügt`, `fix: Halluzination im E-Mail-Entwurfs-Prompt reduziert`. Git-Tags für jede erfolgreich in der Produktion deploygte Version setzen: `prompts/task/version`.
📌 Prompts sind Code
Prompt-Dateien mit derselben Disziplin wie Code-Dateien behandeln: PR-Review, benannte Autoren, semantische Versionierung und niemals löschen — stattdessen in /prompts/archive/ verschieben.
CI/CD-Gates für Prompts
Einen GitHub Actions Workflow hinzufügen, der Promptfoo oder Braintrust bei jedem Pull Request ausführt und den Build scheitern lässt, wenn die Bestehensquote unter einen Schwellenwert fällt. Mit 85% beginnen und nach 3 Monaten stabiler Tests auf 95% erhöhen.
GitHub Actions Workflow-Struktur: `.github/workflows/prompt-test.yml` mit einem Job erstellen, der bei `pull_request` ausgelöst wird, Promptfoo installiert, `promptfoo eval --config promptfooconfig.yaml` ausführt und bei einem Exit-Code ungleich null fehlschlägt.
Schwellenwert-Strategie: Mit 85% beginnen, um etwas Varianz zu erlauben, während größere Regressionen dennoch abgefangen werden. Nach 3 Monaten stabiler Tests ohne Fehlalarme auf 95% erhöhen. Den prompt-test-Job als erforderliche Statusprüfung in den Branch-Protection-Einstellungen hinzufügen.
Produktionsmonitoring für Prompts
Prompt-Inputs und -Outputs loggen, einen Qualitätsscorer für jede Antwort ausführen und Alerts bei Qualitätsscore-Abfällen von mehr als 10% über ein 24-Stunden-Rollfenster setzen. Alle Prompts, die Nutzerdaten verarbeiten, überwachen.
Was geloggt werden soll: Prompt-Identifier und -Version, Modellname, Eingabe-Token-Anzahl, Ausgabe-Token-Anzahl, Latenz in Millisekunden und ein Qualitätsscore. Für Prompts, die personenbezogene Daten verarbeiten (DSGVO-relevant), einen Hash der Eingabe statt der Roheingabe loggen.
Qualitätsbewertungsoptionen: Braintrust bietet einen Cloud-Evaluator mit Scoring je Antwort und Dashboards. Für einen selbst gehosteten Ansatz einen leichtgewichtigen LLM-as-Judge-Aufruf auf 10% der Antworten ausführen. Alerts auslösen, wenn der durchschnittliche Qualitätsscore um mehr als 10% gegenüber dem 7-Tage-Rollmittel fällt.
Häufige Fehler im Entwickler-Prompt-Workflow
❌ Prompts direkt im Anwendungscode schreiben
Why it hurts: Hardcodierte Prompts können nicht versioniert, getestet oder ohne vollständiges Deployment geändert werden
Fix: Prompts als separate Dateien in einem /prompts-Verzeichnis speichern. Zur Laufzeit laden.
❌ Nur lokal testen, nie in CI/CD
Why it hurts: Lokale Tests werden unter Zeitdruck übersprungen; CI/CD-Gates sind obligatorisch
Fix: Einen Promptfoo-Testschritt zu GitHub Actions hinzufügen. Merge blockieren, wenn Bestehensquote unter 85% fällt.
❌ Kein Produktionsmonitoring
Why it hurts: Prompt-Qualität verschlechtert sich nach dem Deployment ohne Sichtbarkeit
Fix: Bestehensquote pro Prompt pro Tag loggen. Alarmieren, wenn Bestehensquote wöchentlich um 5% fällt.
❌ Nur auf einem Modell testen
Why it hurts: Ein Prompt, der auf GPT-4o funktioniert, kann auf Claude 4.6 Sonnet scheitern
Fix: Testsuite gegen mindestens 2 Modelle in CI/CD ausführen.
Zusammenfassung
- Cursor für TypeScript/Python mit Cloud-APIs verwenden. VS Code + Continue.dev für lokale Modelle oder Open-Source-Anforderungen.
- Die lokale Testschleife hat 4 Schritte: schreiben, auf 3 repräsentativen Eingaben testen, mit der Baseline vergleichen, committen. Ziel: unter 30 Sekunden mit Promptfoo.
- Prompts als .txt- oder .ts-Dateien in /prompts speichern. Namenskonvention task-version.txt. Produktionsversionen in Git taggen.
- GitHub Actions CI/CD-Gate hinzufügen, das den Build scheitern lässt, wenn die Bestehensquote unter 85% fällt. Nach 3 Monaten auf 95% erhöhen.
- In der Produktion Prompt-Identifier, Modell, Token-Anzahl, Latenz und Qualitätsscore loggen. Bei Qualitätsscore-Abfällen von mehr als 10% über 24 Stunden alarmieren.
Häufig gestellte Fragen
Welche IDE ist am besten für Prompt Engineering geeignet?
Cursor ist empfohlen für Entwickler, die hauptsächlich in TypeScript oder Python arbeiten und eine native KI-Integration wünschen. VS Code mit Continue.dev wird empfohlen, wenn lokale Modellunterstützung oder Open-Source-Anforderungen benötigt werden.
Wie sollten Prompts in der Versionskontrolle gespeichert werden?
Prompts als .txt- oder .ts-Dateien in einem /prompts-Verzeichnis speichern. Namenskonvention: task-version.txt. Conventional Commits für Prompt-Änderungen verwenden. Git-Tags für jede in der Produktion deploygte Version setzen.
Wie richtet man ein CI/CD-Gate für Prompts ein?
GitHub Actions Workflow hinzufügen, der Promptfoo bei jedem Pull Request ausführt. Den Build scheitern lassen, wenn die Bestehensquote unter den Schwellenwert fällt — mit 85% beginnen, nach 3 Monaten auf 95% erhöhen.
Was sollte für das Produktionsmonitoring geloggt werden?
Prompt-Inputs (oder deren Hash bei personenbezogenen Daten), Modellantworten, Latenz, Token-Anzahl und Qualitätsscore loggen. Logs mindestens 30 Tage aufbewahren.
Wie speichert man Prompts in einem Git-Repository?
Jeden Prompt als Textdatei in `/prompts/theme/` speichern. Benennung: `classify-intent-v2.txt`. YAML-Frontmatter mit Version, Autor, Datum, Modell und Beschreibung hinzufügen.
Was ist ein CI/CD-Gate für Prompts?
Ein CI/CD-Gate ist ein automatisierter Testschritt, der die Prompt-Testsuite bei jedem PR ausführt und den Merge blockiert, wenn die Bestehensquote unter den Schwellenwert fällt (typischerweise 85%).
Welche IDE ist beste für Prompt Engineering?
Cursor ist die beste IDE für Prompt Engineering wegen integrierter KI-Unterstützung und direktem Claude 4.6 Sonnet-Zugriff auf Prompt-Dateien. VS Code mit Continue.dev ist eine gute Alternative für Open-Source-Tooling.