Claude-Prompts testen und versionieren, bevor sie in Produktion gehen

Claude-Prompts testen und versionieren bedeutet dreierlei. Jeder produktive Prompt erhält eine Versionsnummer und einen festen Testsatz aus echten Fällen. Vor jedem Livegang läuft außerdem eine Regressionsprüfung. Erst wenn die neue Fassung alle Fälle mindestens so gut löst wie die alte, ersetzt sie die laufende Version.

Ein Prompt ist in einem produktiven System die feste Anweisung, die Claude bei jedem einzelnen Vorgang mitbekommt. Der Prompt entscheidet zum Beispiel, in welcher Gruppe ein Ticket in Zoho Desk landet. Er legt auch fest, welche Felder eine Automatisierung in Zoho CRM befüllt. Ein geänderter Satz wirkt deshalb nicht auf einen Fall, sondern auf alle künftigen Fälle.

Genau darin liegt das Risiko. Wer einen Prompt im laufenden Betrieb „schnell verbessert“, prüft meist nur den Fall, der ihn gestört hat. Ob dabei andere Fälle kippen, sieht er nicht. Behandeln Sie produktive Prompts deshalb wie Programmcode: mit Versionsstand, Testfällen und einer Freigabe vor dem Einsatz.

Die folgenden Abschnitte zeigen den Aufbau eines Testsatzes, eine saubere Versionierung, die passenden Werkzeuge und ein durchgerechnetes Beispiel aus dem Ticket-Routing. Eine Prüftabelle fasst zusammen, welche Änderung welchen Test braucht.

Produktive Prompts brauchen dieselbe Sorgfalt wie Code, weil ihr Verhalten nicht vollständig vorhersagbar ist. Sider.AI beschreibt Prompt Engineering als flexibel und schnell. Es könne aber zwischen Nutzern und Sessions inkonsistent sein. Ein einzelner erfolgreicher Versuch beweist daher wenig.

Hinzu kommt die Fehlerquote bei anspruchsvollen Aufgaben. Laut ObserviX macht Claude bei komplexen, mehrteiligen Ausgaben etwa einmal von zehn Mal einen Fehler. Wer eine Änderung nur an zwei oder drei Beispielen prüft, übersieht solche Ausreißer leicht.

Eine Regression ist ein Rückschritt: Ein Fall, den die alte Prompt-Version richtig gelöst hat, wird von der neuen falsch gelöst. Regressionen sind tückisch, weil sie leise passieren. Das Ticket landet einfach in der falschen Gruppe, und niemand meldet einen Absturz.

Die Lösung kennt die Softwareentwicklung seit Langem. DevKarriere empfiehlt für Claude Code ausdrücklich Git als Sicherheitsnetz. Damit kommen Sie schnell auf eine saubere Version zurück, wenn etwas schiefläuft. Für Prompts gilt dieselbe Logik: Jede Fassung muss wiederherstellbar sein. Jede neue Fassung muss sich gegen dieselben Fälle beweisen wie ihre Vorgängerin.

Ein Testsatz ist eine feste Sammlung echter Geschäftsfälle. Jeder Fall enthält die Eingabe und das Ergebnis, das ein Mensch aus dem Fachteam als richtig festgelegt hat. Gegen diesen Testsatz läuft jede neue Prompt-Version, bevor sie live geht.

Ein brauchbarer Testsatz deckt vier Arten von Fällen ab:

• Typische Fälle: für jede Kategorie mehrere gewöhnliche Vorgänge, wie sie täglich eingehen.
• Grenzfälle: Vorgänge, bei denen auch Mitarbeitende kurz überlegen müssten.
• Fehlerfälle aus dem Betrieb: jeder Vorgang, den eine frühere Version falsch behandelt hat.
• Angriffsversuche: Eingaben, die versteckte Anweisungen enthalten, wie im Beitrag Claude-Agenten vor Prompt Injection schützen beschrieben.

Bei Svennis bauen wir den Testsatz, bevor wir den ersten Satz eines produktiven Prompts ändern. Er besteht aus echten, bereinigten Vorgängen des Kunden, jeweils mit der Entscheidung, die das Fachteam getroffen hat, und jeder im Betrieb falsch behandelte Fall kommt sofort hinzu.

Legen Sie das Soll-Ergebnis so fest, dass ein Programm es vergleichen kann. Statt eines Freitexts verlangt der Prompt dann feste Felder, etwa Kategorie und Priorität. Auch der Testsatz selbst bekommt einen Versionsstand. Fälle kommen hinzu, werden aber nur mit Begründung entfernt.

Prompt-Versionierung ist das lückenlose Festhalten jeder Fassung eines Prompts, sodass jede frühere Fassung abrufbar und jede Änderung begründet ist. Wie das in einer Oberfläche aussehen kann, zeigt das AI Studio von Mistral. Laut Unidigital führt es Versionen als v1, v2, v3 und zeigt beim Speichern alte und neue Anweisung nebeneinander. Die Änderungen sind dabei grün markiert, und ein optionaler Versionshinweis hält den Grund fest.

Für einen Claude-Prompt im Unternehmen sollte jede Version mindestens diese Angaben enthalten:

• Versionsnummer und vollständiger Prompt-Text
• Gegenüberstellung von alter und neuer Fassung
• Begründung der Änderung in einem Satz
• Name der verantwortlichen Person und Datum
• Modell und Einstellungen, mit denen getestet wurde
• Ergebnis des Testlaufs gegen den Testsatz

Liegen Prompts als Dateien vor, ist ein Git-Repository der einfachste Weg. Git speichert jede Fassung, zeigt die Unterschiede und erlaubt die Rückkehr zu jedem früheren Stand.

Für Claude Skills nennt Sider.AI einen weiteren Vorteil: Skill-Updates hinterlassen Spuren. Das sei für regulierte Branchen wertvoll. Claude Skills sind dabei wiederverwendbare, benannte Fähigkeiten, die Claude zuverlässig einen bestimmten Ablauf ausführen lassen. Sider.AI warnt aber auch: Schlecht gestaltete Skills können schlechte Gewohnheiten verankern. Eine nachvollziehbare Version ersetzt also nicht den Test.

Der Playground in der Claude Console eignet sich für einzelne Versuche, aber nicht für Versionierung und Tests. Laut Claude Help Center hat der Playground die frühere Workbench ersetzt. Gespeicherte Prompts, Prompt-Versionen, Evals und das Teilen von Prompts gehören nicht zum Playground. Evals sind automatisierte Bewertungsläufe eines Prompts gegen Testfälle.

Wer seine Prompts bisher in der Workbench gespeichert hat, sollte das prüfen. Der Export der alten Workbench-Daten als JSON war laut Help Center bis zum 1. September 2026 in den Console-Einstellungen möglich. Danach sind die Daten nicht mehr wiederherstellbar. Ein Import in den Playground ist ebenfalls nicht vorgesehen.

Für die Entwicklung einer neuen Prompt-Version bleibt der Playground trotzdem nützlich:

• Er baut direkt auf der öffentlichen Messages API auf. Die Anfrage im Playground ist also dieselbe wie später im Code.
• Er zeigt Token-Zahlen, Werkzeugaufrufe und auf Wunsch die rohe Anfrage samt Stop-Grund.
• Modell, Temperatur und maximale Ausgabelänge lassen sich umstellen.
• Der Schalter „code“ exportiert die aktuelle Anfrage als Code-Ausschnitt.

Der Playground speichert Prompts und Gespräche nicht auf den Servern von Anthropic. Der Entwurf bleibt im Browser. Die gültige Version gehört deshalb immer in Ihr eigenes Repository.

Das quelloffene Plugin claude-prompts von minipuft bringt Versionsverlauf und Vorschau direkt in Claude Code. Laut Anleitung im Projekt definieren Sie einen Prompt einmal, rufen ihn über seinen Namen auf und ändern ihn mit Vorschau und Versionsverlauf. Claude Code ist ein KI-Assistent für die Programmierung, der im Terminal läuft. Das Plugin verlangt Node.js ab 22.13.0 und Python ab 3.10.

Die folgenden zwei Befehle installieren das Plugin. Sie geben sie nacheinander in einer laufenden Claude-Code-Sitzung im Terminal ein:

/plugin marketplace add minipuft/minipuft-plugins
/plugin install claude-prompts@minipuft

An den Befehlen ändern Sie nichts. Die erste Zeile fügt die Plugin-Quelle hinzu, die zweite installiert das Plugin daraus.

Für die Versionierung sind vier Eigenschaften wichtig:

• Eine Vorschau auf eine Änderung zeigt die Gegenüberstellung, schreibt aber nichts und legt keine Version an.
• Der Server lehnt eine Änderung ab, wenn deren expected_version nicht mehr zur aktuellen Version passt. So überschreibt niemand unbemerkt die Arbeit eines Kollegen.
• Prompts und Versionsverlauf liegen im Datenordner des Plugins und überstehen ein Update.
• Direkte Bearbeitungen der Prompt-Dateien werden zwar neu geladen, umgehen aber die Vorschau.

Der letzte Punkt ist eine Regel für Ihr Team: Änderungen laufen über die Vorschau, nicht über den Texteditor.

Ein Routing-Prompt ordnet eingehende Anfragen einer Gruppe zu, bevor sie als Ticket im Helpdesk erscheinen. In unserem Beispiel liefert der Prompt in Version 3 zwei feste Felder zurück: Kategorie (Rechnung, Technik, Vertrag oder Sonstiges) und Priorität. Version 3 ist live, alle Fälle des Testsatzes laufen korrekt.

Im Betrieb fällt auf: Kündigungen landen unter „Sonstiges“ statt unter „Vertrag“. Das Team ergänzt deshalb einen Satz, der Kündigungen ausdrücklich der Kategorie Vertrag zuordnet. Das ist Version 4, mit der Begründung „Kündigungen fehlgeleitet“.

So läuft die Prüfung

1. Die betroffenen Kündigungen kommen als neue Fälle in den Testsatz, mit Soll-Ergebnis „Vertrag“.
2. Version 3 und Version 4 laufen gegen den ganzen Testsatz. Modell, Temperatur und maximale Ausgabelänge sind in beiden Läufen identisch.
3. Ein Vergleich je Fall zeigt: Die Kündigungen sind jetzt richtig.
4. Der Vergleich zeigt aber auch eine Regression. Eine Rechnungsanfrage, die eine Vertragsnummer nennt, springt jetzt auf „Vertrag“.

Ohne Testsatz wäre Version 4 live gegangen, und die Buchhaltung hätte Anfragen verloren. Mit Testsatz präzisiert das Team die Regel zu Version 5. Kündigungen gehen an Vertrag, Fragen zu Rechnungsbeträgen bleiben bei Rechnung, auch wenn eine Vertragsnummer genannt wird. Erst Version 5 besteht alle Fälle und geht live.

Eine Regressionsprüfung vergleicht die neue Prompt-Version Fall für Fall mit der laufenden Version, bevor die neue Version produktiv wird. Der Ablauf ist für jede Änderung gleich:

1. Neue Version anlegen. Die Änderung bekommt eine Nummer und eine Begründung. Die laufende Version bleibt unverändert.
2. Beide Versionen gegen den Testsatz laufen lassen. Die Einstellungen sind identisch und werden mit der Version notiert.
3. Jeden Fall einordnen. Jeder Fall ist entweder verbessert, unverändert oder verschlechtert.
4. Freigabe einholen. Bei jedem verschlechterten Fall entscheidet die fachlich verantwortliche Person, nicht die Person, die den Prompt geschrieben hat.
5. Live schalten mit Rückweg. Die vorherige Version bleibt abrufbar, damit Sie sofort zurückschalten können.

Nach dem Livegang beginnt die Beobachtung. Neue Fehlerfälle aus dem Betrieb wandern in den Testsatz. So wird der Testsatz mit jeder Version etwas strenger.

Sider.AI beschreibt einen ähnlichen Weg vom freien Prompt zur festen Skill. Er führt von der Exploration über die Pilotierung bis zu Rollout und Monitoring. Der Gedanke ist derselbe: Ein Ablauf geht erst nach einer Probephase in den Regelbetrieb, und er wird danach weiter beobachtet.

Nicht nur der Prompt-Text löst eine Regressionsprüfung aus. Jede Änderung an Modell, Einstellungen oder Ausgabeformat kann das Verhalten verschieben. Die folgende Tabelle ordnet die häufigsten Änderungen einer Prüfung und einer Freigabe zu.

Die Zeile zu CLAUDE.md verdient Beachtung. Laut DevKarriere liest Claude Code diese Datei vor jedem einzelnen Prompt. Eine Änderung dort wirkt also wie eine Änderung an jedem Prompt des Projekts.

Ein Modellwechsel verändert das Verhalten eines Prompts, auch wenn kein Wort geändert wurde. Deshalb gehört die Modellversion zu jeder Prompt-Version. Manche Wechsel erzwingt der Anbieter: Laut Modellübersicht von Anthropic wird Claude Haiku 4.5 nicht vor dem 15. Oktober 2026 eingestellt. Wer Haiku 4.5 produktiv nutzt, sollte den Umstieg jetzt mit dem Testsatz vorbereiten.

Andere Wechsel sind wirtschaftlich verlockend. Laut Anthropic erreicht Claude Opus 5.5 bei den meisten Aufgaben das Niveau von Claude Fable 5.1. Im Betrieb kostet es zudem 40 % weniger als Opus 5. Ob das für Ihren Routing-Prompt gilt, zeigt nur der eigene Testsatz. Den Weg beschreibt der Beitrag Von Claude Opus 5 auf Opus 5.5 wechseln.

Anthropic setzt eigene Tests sogar voraus. Die Modellübersicht empfiehlt Claude Fable 5.1 für anspruchsvolles Schlussfolgern. Sie nennt es auch für den Fall, dass Ihre Evals mit Opus 5.5 bei höherem Aufwand weiter nicht reichen. Der Standardaufwand liegt bei Opus 5.5 auf „medium“, bei Fable 5.1 auf „high“. Halten Sie den Aufwand deshalb ebenfalls mit der Version fest.

Vor einem Wechsel lohnt ein Blick in die Models API. Sie liefert für jedes verfügbare Modell max_input_tokens, max_tokens und ein Objekt mit den Fähigkeiten.

Für Unternehmen im deutschsprachigen Raum ist der Testsatz vor allem eine Datenschutzfrage. Echte Tickets und CRM-Vorgänge enthalten Namen, E-Mail-Adressen und Vertragsdaten. Bevor solche Fälle dauerhaft in einem Repository liegen, sollten Sie personenbezogene Angaben entfernen oder ersetzen. Ersetzte Namen allein machen die Daten aber nur pseudonym, nicht anonym. Die DSGVO gilt deshalb weiter, solange sich ein Personenbezug herstellen lässt.

Für Unternehmen in Deutschland und Österreich richtet sich nach der DSGVO, ob personenbezogene Daten an Claude gehen dürfen. Unternehmen in der Schweiz prüfen zusätzlich das Schweizer Datenschutzgesetz (DSG). Nach der DSGVO brauchen Sie eine Rechtsgrundlage und einen Auftragsverarbeitungsvertrag mit dem Anbieter. Bei Übermittlungen außerhalb des EWR braucht es zusätzlich einen Angemessenheitsbeschluss der EU-Kommission oder eine geeignete Garantie wie die EU-Standardvertragsklauseln. Rechtsgrundlage und Datenweg beschreibt der Beitrag Claude DSGVO-konform nutzen.

Der Playground speichert Prompts und Gespräche laut Help Center nicht auf den Servern von Anthropic. Jede Testanfrage wird aber über die Messages API an Anthropic übermittelt und dort verarbeitet. Verwenden Sie im Playground deshalb nur bereinigte Testfälle.

Der zweite Punkt ist Nachvollziehbarkeit. Wenn ein Kunde fragt, warum seine Anfrage falsch geleitet wurde, sollten Sie die damals gültige Prompt-Version nennen können. Auch Testergebnis und Freigabe sollten belegbar sein. Sider.AI hebt prüfbare Änderungen gerade für regulierte Branchen als wertvoll hervor.

Der dritte Punkt ist die Rollenverteilung. In vielen mittelständischen Betrieben schreibt eine Person aus der IT den Prompt. Die fachliche Verantwortung liegt aber im Service oder Vertrieb. Die Regressionsprüfung gibt der Fachseite ein klares Werkzeug: Sie gibt frei, was sie anhand echter Fälle geprüft hat.

Den Einstieg schaffen Sie mit dem Prompt, der heute den meisten Schaden anrichten könnte. Meist ist das ein Routing- oder Klassifizierungs-Prompt. Gehen Sie in dieser Reihenfolge vor:

1. Laufende Version einfrieren. Legen Sie den aktuellen Prompt als Version 1 mit Modell und Einstellungen in einem Repository ab. Ab jetzt ändert niemand mehr direkt am laufenden Prompt.
2. Testsatz aufbauen. Sammeln Sie bereinigte, echte Fälle aus allen Kategorien, dazu Grenzfälle und bekannte Fehlerfälle. Das Fachteam legt für jeden Fall das Soll-Ergebnis fest.
3. Ausgabe prüfbar machen. Lassen Sie den Prompt feste Felder zurückgeben, damit ein Programm Soll und Ist vergleichen kann.
4. Freigabe regeln. Legen Sie schriftlich fest, wer eine neue Version freigibt und wie Sie auf die vorherige Version zurückschalten.
5. Erste Änderung nach dem Ablauf durchführen. Die nächste Verbesserung läuft vollständig durch die fünf Schritte der Regressionsprüfung.

Wenn Ihr erster produktiver Prompt eingehende E-Mails sortiert, passt der Beitrag E-Mail-Triage und Entwürfe mit Claude als nächster Schritt. Er beschreibt Regeln und Freigaben für genau diesen Ablauf. Den Testsatz aus diesem Leitfaden können Sie dort direkt einsetzen.