KI-Arbeitsvorlagen ohne Toolbindung dokumentieren

Eine KI-Arbeitsvorlage bleibt bei einem Werkzeugwechsel nutzbar, wenn ihr Zweck, ihre Eingaben und ihre Prüfregeln ausserhalb der jeweiligen Oberfläche verständlich dokumentiert sind. Ein kopierter Prompt reicht dafür häufig nicht. Er enthält weder automatisch die verwendeten Quellen noch die Dateirechte, Beispiele oder Freigabeschritte. Diese Abhängigkeiten müssen sichtbar sein, bevor du die Vorlage in ein anderes Werkzeug überträgst.

Toolunabhängig bedeutet dabei nicht, dass jede Vorlage überall unverändert funktioniert. Verschiedene Werkzeuge haben unterschiedliche Eingabewege und Fähigkeiten. Das Ziel ist ein nachvollziehbarer Arbeitsauftrag, dessen fachlicher Kern erhalten bleibt. Die technische Umsetzung erhält eine eigene Beschreibung. Der folgende Aufbau ist ein selbst entwickeltes Dokumentationsmuster, kein standardisiertes Austauschformat für alle KI-Produkte.

Trenne Arbeitsregel und Bedienanleitung

Der fachliche Kern beschreibt, welche Aufgabe erledigt wird und woran ein richtiges Ergebnis erkennbar ist. Eine Bedienanleitung beschreibt dagegen, wo eine Datei hochgeladen oder eine Einstellung gewählt wird. Wenn beide Ebenen in einem einzigen Fliesstext stehen, wird ein Oberflächenwechsel schnell zu einer vollständigen Überarbeitung der Vorlage.

Ein Beispiel: "Öffne den Assistenten und klicke auf das blaue Symbol" hilft nur in einer bestimmten Oberfläche. "Verwende die freigegebene Produktliste mit Versionskennung und prüfe jede Produktnummer gegen diese Liste" beschreibt eine fachliche Anforderung. Der zweite Satz bleibt auch dann sinnvoll, wenn der Upload künftig über eine Schnittstelle erfolgt.

Lege deshalb einen fachlichen Vorlagenkern und eine oder mehrere technische Ausführungsbeschreibungen an. Jede Ausführung verweist auf dieselbe Kernversion. Wenn sich nur eine Schaltfläche ändert, bleibt die Arbeitsregel unberührt. Wenn sich die fachliche Prüfung ändert, müssen dagegen alle Ausführungen erneut geprüft werden. Diese Trennung macht Abhängigkeiten sichtbar, statt sie durch einen allgemeinen Anspruch auf Portabilität zu verdecken.

Ein Dateiformat löst noch keine Bedeutungsfrage

RFC 8259 beschreibt JSON als textbasiertes Format für strukturierte Daten. Objekte enthalten Name-Wert-Paare, Arrays geordnete Wertefolgen. Daraus folgt keine Garantie, dass zwei Anwendungen ein Feld gleich interpretieren. Ein Feld status ist technisch lesbar, aber ohne dokumentierte Werte und Bedeutung fachlich unvollständig.

Die W3C-Empfehlung Data on the Web Best Practices behandelt unter anderem Metadaten, Versionen und maschinenlesbare Formate. Ihr Gegenstand sind Daten im Web, nicht die Migration von KI-Vorlagen. Die Übertragung auf eine Vorlagendokumentation ist eine eigene Empfehlung: Verwende lesbare Dateien, erkläre ihre Bedeutung und mache Änderungen nachvollziehbar.

Markdown eignet sich für eine menschenlesbare Beschreibung. JSON kann ergänzend Metadaten und Testfälle strukturieren. Du brauchst nicht zwingend beide Formate. Wähle den kleinsten Aufbau, den die zuständigen Personen tatsächlich pflegen. Eine umfangreiche Dateisammlung ohne klare Verantwortung wird beim nächsten Wechsel genauso unzuverlässig wie ein einzelner unkommentierter Prompt.

Der portable Kern einer Arbeitsvorlage

Beginne mit einer stabilen Kennung, einem Titel und einem klaren Einsatzzweck. Ergänze den Status und die verantwortliche Person. Danach folgen Eingaben, Ausgabe und Prüfregeln. Beschreibe auch ausdrücklich, welche Aktionen die Vorlage nicht freigibt. Ein Textentwurf und eine versendete Nachricht sind verschiedene Zustände.

Die Tabelle ist ein eigenes Muster. Sie ist bewusst unabhängig von Modellnamen und Schaltflächen. Trotzdem darf der Kern technische Voraussetzungen nennen, wenn sie für die Aufgabe nötig sind. Eine Vorlage zur Auswertung gescannter Dokumente muss beispielsweise festhalten, dass lesbarer Text erforderlich ist. Ob das Werkzeug selbst Texterkennung bietet oder einen vorbereiteten Text benötigt, gehört in die jeweilige Ausführungsbeschreibung.

Ein fiktives Beispiel: Produktangaben vergleichen

Ein Einkaufsteam vergleicht Produktangaben aus zwei freigegebenen Datenblättern. Die Vorlage P-08 soll Unterschiede in Artikelnummer, Abmessungen und Material zeigen. Fehlende Werte bleiben als fehlend markiert. Das Modell darf keine Einheiten umrechnen, solange dafür keine ausdrücklich freigegebene Regel vorliegt. Jede Angabe erhält eine Fundstelle mit Dokumentkennung und Seite.

Der fachliche Kern enthält diese Regeln und einen kleinen Beispielsatz. Ausführung A beschreibt die Arbeit in einer Chatoberfläche mit Dateiupload. Ausführung B beschreibt einen Ablauf mit vorbereiteter Textextraktion. Beide Ausführungen müssen dieselben fachlichen Testfälle bestehen. Eine erfolgreiche Antwort in A beweist nicht, dass B dieselben Tabellen aus dem Dokument korrekt übernimmt.

Das Team speichert zusätzlich einen Fall mit einer leeren Materialangabe. Die erwartete Antwort lautet "nicht angegeben". Ein weiterer Fall enthält Millimeter und Zentimeter, damit eine nicht freigegebene Umrechnung auffällt. Diese Beispiele prüfen die Grenze der Vorlage. Sie sind als synthetisch gekennzeichnet und enthalten keine realen Lieferantendaten.

Ein solcher Aufbau unterstützt den späteren Wechsel, weil die Abnahme unabhängig von der Oberfläche beschrieben ist. Er garantiert keine identischen Formulierungen. Massgeblich für den Test sind die übernommenen Angaben und die erhaltenen Grenzen. Für den Umgang mit Format und Pflichtfeldern ergänzt Arbeitsabläufe als KI-Vorlage beschreiben die Dokumentation.

Verweise auf Quellen statt unkontrollierter Kopien

Eine Vorlage braucht eine nachvollziehbare Beziehung zu ihren Arbeitsunterlagen. Notiere, welche Quelle gilt, wie ihre Version erkennbar ist und wer sie freigibt. Ein Dateiname wie Liste_final_neu.xlsx reicht dafür nicht, wenn mehrere gleichnamige Dateien existieren. Verwende die im vorhandenen System vorgesehene Kennung und beschreibe den erlaubten Zugriff.

Kopiere vertrauliche Inhalte nicht aus Bequemlichkeit in das Vorlagenpaket. Die portable Beschreibung kann auf einen geschützten Bestand verweisen und stattdessen synthetische Testdaten enthalten. Beim Wechsel muss dann separat geprüft werden, ob die neue Ausführung auf die benötigten Daten zugreifen darf. Eine exportierbare Vorlage verleiht keine neuen Zugriffsrechte.

Dokumentiere auch Quellen, die nur während der Ausführung entstehen, etwa ein Suchergebnis oder eine aktuelle Vorgangsabfrage. Ihr Inhalt lässt sich nicht vollständig in einer statischen Vorlage festhalten. Beschreibe stattdessen Auswahlregeln, Zeitbezug und notwendige Herkunftsangaben. Der Artikel Quellenprüfung im KI-Arbeitsalltag hilft bei der fachlichen Abnahme solcher Eingaben.

Halte werkzeugspezifische Fähigkeiten sichtbar

Manche Vorlagen hängen von einer Funktion ab, die ein anderes Werkzeug nicht anbietet. Dazu gehören bestimmte Dateiformate, strukturierte Ausgaben oder ein kontrollierter Zugriff auf interne Systeme. Verschweige diese Abhängigkeit nicht hinter einem neutralen Prompt. Schreibe sie in die Ausführungsbeschreibung und benenne den Ersatzweg, falls einer geprüft ist.

Ein fiktives Beispiel: Ausführung A kann Seitenzahlen aus einem PDF zuverlässig anzeigen; Ausführung B erhält nur einen Text ohne Seitenmarkierungen. Dann erfüllt B die Quellenregel des Kerns noch nicht. Eine mögliche Anpassung ist eine vorgelagerte Extraktion mit erhaltenen Seitenmarken. Bis diese geprüft ist, bleibt B für diese Aufgabe gesperrt. Das ist eine konkrete Lücke, kein allgemeines Urteil über das Werkzeug.

Dasselbe gilt für Einstellungen, die nicht offengelegt werden. Notiere sie als unbekannt. Erfinde keine Modellversion, um die Dokumentation vollständig aussehen zu lassen. Für die Reproduzierbarkeit ist diese Grenze relevant. Eine Ausführung kann brauchbar sein, obwohl einzelne technische Details unbekannt bleiben; ihre geprüfte Reichweite muss dann entsprechend eng beschrieben werden.

Versioniere den Kern und die Ausführung getrennt

Eine Änderung am fachlichen Kern erhält eine neue Kernversion. Eine reine Bedienänderung erhält eine neue Ausführungsversion. Halte im Änderungsvermerk fest, welche Prüfung dadurch ausgelöst wurde. So erkennt eine andere Person, ob sie lediglich einen neuen Uploadweg lernen oder ihre Ergebnisprüfung ändern muss.

Vermeide Versionsnummern ohne Erklärung. "Version 4" sagt wenig, wenn der Unterschied zu Version 3 unbekannt ist. Ein kurzer Vermerk wie "fehlende Materialangaben bleiben offen; bisheriger Ersatzwert entfernt" erklärt die fachliche Wirkung. Die zugehörigen Testfälle dokumentieren, ob die Änderung tatsächlich greift.

Im Beitrag KI-Arbeitsvorlagen versionieren steht die laufende Pflege im Mittelpunkt. Für die portable Dokumentation kommt die Zuordnung hinzu: Welche Ausführung wurde mit welcher Kernversion geprüft? Ohne diese Beziehung kann ein Team versehentlich eine neue Arbeitsregel mit einer alten technischen Umsetzung kombinieren.

Prüfe die Übergabe ohne mündliche Ergänzungen

Gib das Paket einer Person, die die Vorlage nicht erstellt hat. Sie muss den Zweck verstehen, die erlaubten Eingaben erkennen und die Testfälle ausführen können. Halte ihre Rückfragen fest. Jede nötige mündliche Zusatzregel zeigt eine Lücke in der Dokumentation. Nicht jede Rückfrage verlangt mehr Text; manchmal reicht ein präziser Feldname oder ein klarer Verweis.

Prüfe anschliessend einen zweiten Ausführungsweg, wenn ein Werkzeugwechsel tatsächlich ansteht. Verwende dieselben fachlichen Fälle und dieselbe Abnahmeregel. Dokumentiere Unterschiede in Fehlern, Prüfaufwand und fehlenden Funktionen. Ein anderer Wortlaut ist kein Fehler, solange Bedeutung und Anforderungen erhalten bleiben. Eine verlorene Fundstelle ist dagegen ein Fehler, wenn sie zur Abnahme gehört.

Die Prüfung nach einem Modellwechsel ergänzt KI-Vorlagen nach Modellwechsel testen. Sie zeigt auch die Grenze des portablen Kerns: Gute Dokumentation erleichtert die erneute Prüfung, sie ersetzt sie nicht. Jede neue Ausführung erhält ihren Status erst nach dem vorgesehenen Nachweis.

Eine minimale Ordnerstruktur für den Wechseltest

Für eine kleine Vorlage reicht beispielsweise eine Beschreibung, ein Ordner mit synthetischen Prüffällen und eine Ausführungsanleitung pro freigegebenem Werkzeug. Die Beschreibung verweist auf alle nötigen Dateien. Der Einstieg darf nicht davon abhängen, dass die ursprüngliche Autorin die richtige Reihenfolge mündlich erklärt. Verwende die vorhandenen Ablagekonventionen statt einer zusätzlichen, konkurrierenden Bibliothek.

Speichere erwartete Ergebnisse getrennt von tatsächlich erzeugten Antworten. Sonst kann eine alte Modellantwort versehentlich als fachliche Referenz gelten. Die Referenz muss von der zuständigen Person geprüft sein und die Kriterien erklären. Bei offenen Formulierungen können mehrere Antworten richtig sein; dann beschreibt die Referenz die notwendigen Inhalte und Grenzen statt eines einzigen wortgleichen Textes.

Ergänze einen kurzen Startvermerk: Welche Datei wird zuerst gelesen, welche Daten sind synthetisch und welche Quelle muss im echten Einsatz bereitstehen? Eine andere Person muss das Paket ohne Zugang zu deinem Chatverlauf verstehen. Genau dieser Versuch zeigt, ob Wissen noch in der alten Oberfläche verborgen ist.

Prüfe ausserdem, ob Dateinamen und Verweise nach dem Kopieren weiterhin funktionieren. Absolute Pfade zu deinem eigenen Rechner sind kein portabler Zugang für das Team. Nutze die im Zielsystem vorgesehenen stabilen Verweise und dokumentiere notwendige Berechtigungen. Die Lesbarkeit der Vorlage und der Zugriff auf ihre echten Arbeitsdaten bleiben getrennte Prüfpunkte.

Ein Paket ist erst durch Wiederverwendung geprüft

Ein erfolgreich heruntergeladenes Archiv beweist nur, dass Dateien vorliegen. Öffne die Dateien, prüfe ihre Verweise und bearbeite damit einen neuen Fall. Kontrolliere insbesondere, ob Testdaten, erwartete Ergebnisse und Quellenregeln zusammenpassen. Ein fehlender Anhang kann die ganze Vorlage unbrauchbar machen, obwohl der Hauptprompt vollständig aussieht.

Halte im Abschlussvermerk fest, welche Kernversion mit welcher Ausführung geprüft wurde und welche Einschränkungen bleiben. Wenn nur die Lesbarkeit der Dateien geprüft ist, benenne genau diesen Teilstand. Erst die fachlich abgenommene Bearbeitung zeigt, dass die Vorlage im neuen Arbeitsweg nutzbar ist. Diese Unterscheidung schützt vor einem vermeintlich abgeschlossenen Wechsel, bei dem die eigentliche Arbeit noch nicht funktioniert.