In den meisten Teams existiert die Prompt-Bibliothek nicht als Bibliothek, sondern als Sammlung von Notizen: im privaten Notizbuch der einen Person, im Chat-Verlauf der anderen, in einer vergessenen Textdatei einer dritten. Alle lösen dieselbe Aufgabe – aber mit leicht unterschiedlichen Prompts, leicht unterschiedlicher Qualität und ohne Möglichkeit, nachzuvollziehen, welche Version gerade die aktuelle ist. Genau dieses Chaos verschwindet, sobald Prompts wie das behandelt werden, was sie tatsächlich sind: wiederverwendbarer, versionierbarer Arbeitscode.
1. Warum Prompts wie Code behandelt werden sollten
Ein Prompt, der in der Praxis funktioniert, ist das Ergebnis mehrerer Iterationen: erste Version zu vage, zweite Version zu lang, dritte Version liefert endlich konsistent brauchbare Ergebnisse. Genau dieser Reifungsprozess geht verloren, wenn niemand mitschreibt, was sich zwischen den Versionen geändert hat und warum.
Software-Teams haben dieses Problem vor Jahrzehnten gelöst – mit Versionskontrolle. Dieselbe Logik lässt sich eins zu eins auf Prompts übertragen: Jede funktionierende Version wird festgehalten, jede Änderung wird begründet, und jede Person im Team greift auf dieselbe, aktuell gültige Version zu – statt auf ihre eigene, möglicherweise veraltete Kopie.
Der Aufwand dafür ist gering. Der Nutzen ist gross: Neue Teammitglieder starten nicht bei null, gute Prompts verschwinden nicht in Einzelpostfächern, und die Qualität einer KI-gestützten Antwort hängt nicht mehr davon ab, wer sie gerade formuliert hat.
2. Ein einfaches Versionierungsschema
Es braucht kein Git-Repository und kein technisches Versionierungssystem, um von Prompt-Chaos zu Prompt-Ordnung zu kommen. Ein einfaches Schema reicht:
v1.0 – Erstversion, funktioniert grundsätzlich v1.1 – Kleine Korrektur (z. B. Tonalität angepasst) v2.0 – Grössere Änderung (z. B. neue Struktur, anderer Anwendungsfall)
Zu jeder Version gehört ein Ein-Zeiler im Changelog: was sich geändert hat und warum. „v1.1 – Antwortlänge auf 150 Wörter begrenzt, weil Kunden zu lange E-Mail-Antworten erhielten" ist mehr wert als zehn stillschweigend überschriebene Prompt-Varianten ohne jede Spur, welche davon aktuell gilt.
3. Wo dokumentieren? Notion, Confluence oder Git-Repo
Das richtige Werkzeug ist das, das Ihr Team ohnehin schon täglich nutzt – nicht das technisch eleganteste.
| Werkzeug | Passt gut, wenn … |
|---|---|
| Notion / Confluence | … das Team ohnehin dort dokumentiert und Prompts neben anderen Anleitungen sinnvoll einsortiert werden können |
| Geteiltes Dokument (Google Doc, SharePoint) | … der Einstieg möglichst niedrigschwellig sein soll, ganz ohne neues Tool |
| Eigenes Git-Repository | … bereits ein Entwicklerteam vorhanden ist, das Prompts wie andere Konfigurationsdateien behandeln will |
Wichtiger als das Werkzeug ist die Regel: ein Ort, an dem die jeweils aktuelle Version steht – nicht drei Kopien in drei Systemen, die parallel auseinanderdriften.
4. Der Prompt-Steckbrief: das Team-Template
Damit ein dokumentierter Prompt tatsächlich nachnutzbar ist, braucht er mehr als nur den reinen Text. Fünf Angaben reichen für einen vollständigen Steckbrief:
Prompt: Kunden-E-Mail – Offerten-Antwort Version: v1.2 Zweck: Freundliche, sachliche Antwort auf Offerten-Anfragen Input: Kundenanfrage (Text), optional Standardkonditionen Output: E-Mail-Entwurf, max. 150 Wörter, Schweizerhochdeutsch Einschränkungen: Keine verbindlichen Preiszusagen, keine echten Kundendaten im Prompt-Text – nur Platzhalter wie [Kundenname] Autor: Name, Team Letzte Änderung: 28.08.2026 – Länge von 200 auf 150 Wörter reduziert
Der Punkt „Einschränkungen" verdient besondere Aufmerksamkeit: Ein dokumentierter Prompt landet oft an mehreren Orten – im Team-Wiki, vielleicht in einem Export, vielleicht in einer Schulungsunterlage. Echte Kundendaten oder Personendaten gehören dort nicht hinein. Ein guter Prompt-Steckbrief arbeitet mit Platzhaltern, nicht mit echten Fällen – das ist zugleich die einfachste Form, die eigene Prompt-Bibliothek datenschutzkonform zu halten.
5. Rollout in drei Schritten
Die Einführung muss kein Projekt sein. Drei Schritte reichen für den Start:
- Bestandsaufnahme: Jede Person im Team trägt ihre drei bis fünf meistgenutzten Prompts zusammen – roh, unformatiert, wie sie gerade vorliegen.
- Dokumentieren: Aus den besten, am häufigsten gebrauchten Prompts werden Steckbriefe nach dem Template. Doppelte oder ähnliche Varianten werden zu einer gemeinsamen Version zusammengeführt.
- Review-Zyklus: Ein fester Rhythmus – etwa monatlich – in dem kurz geprüft wird: Funktioniert der Prompt noch wie gedacht? Gibt es eine bessere Version aus der Praxis? Nur bei echtem Änderungsbedarf wird eine neue Version angelegt.
Dieser dritte Schritt ist der, der am häufigsten übersprungen wird – und der am meisten bringt. Eine Prompt-Bibliothek ohne Review-Zyklus veraltet genauso wie jede andere Dokumentation, die niemand mehr anfasst.
6. Nächste Schritte
Eine dokumentierte, versionierte Prompt-Bibliothek ist der Unterschied zwischen KI-Nutzung, die von Einzelpersonen abhängt, und KI-Nutzung, die im Team Bestand hat. Wer noch am Anfang steht und erst prüfen will, welche Aufgaben sich überhaupt für einen dokumentierten Prompt lohnen, findet den passenden Einstieg im KI-Effizienz-Audit für Schweizer KMU. Wer bereits eine Sammlung wiederkehrender Muster hat, findet Struktur dafür im Prompt Pattern Catalog – und vermeidet mit dem Artikel Top 5 Fehler im Prompt Engineering die häufigsten Stolpersteine dabei gleich mit.
Für Teams, die diesen Rollout strukturiert begleitet haben wollen – von der Bestandsaufnahme bis zum ersten Review-Zyklus – bietet CuonzTech ThinkLab ein massgeschneidertes Workshop-Format für Schweizer KMU an.