Claude-System-Prompts: So legen Sie Ton-Grenzen für technische Dokumentation fest

Technische Dokumentation scheitert oft auf subtile Weise, bevor sie faktisch falsch wird. Ein Entwurf kann zwar korrekt sein, aber zu locker, zu werblich, zu ausführlich, zu vage im Umgang mit Unsicherheiten oder inkonsistent mit dem Rest der Dokumentationsreihe. Wenn Sie Claude nutzen, um API-Leitfäden, Fehlerbehebungsartikel, Versionshinweise, interne Runbooks oder Entwicklerdokumentationen zu erstellen, ist der System-Prompt einer der besten Orte, um diese dauerhaften Schreibgrenzen zu definieren.

Es gibt auch eine aktuelle Änderung im Modellverhalten, die erwähnenswert ist. Ab September 2026 besagt die Deprecation-Dokumentation von Anthropic, dass temperature, top_p und top_k für Claude Opus 4.7 und neuer sowie Claude Mythos Preview eingestellt werden, wobei stattdessen Prompting zur Verhaltenssteuerung empfohlen wird. Das macht explizite stilistische Anweisungen auf Systemebene wichtiger als ältere Rezepte, die versuchten, den Ton hauptsächlich über Sampling-Parameter zu formen. Siehe Anthropics Leitfaden zur Deprecation von Modellen und APIs.

Was sollte eine „Ton-Grenze“ tatsächlich steuern?

Eine Ton-Grenze sollte das Kommunikationsverhalten definieren, das über viele Dokumentationsanfragen hinweg stabil bleibt. Es geht nicht nur darum, „professionell zu klingen“. Eine nützliche Grenze deckt normalerweise fünf Dinge ab: Zielgruppe, Stimme, Detailtiefe, akzeptable Sprache für Unsicherheiten und Formatierungsgewohnheiten.

Einem dokumentationsorientierten Assistenten für Entwickler könnte beispielsweise gesagt werden, in einem professionellen und neutralen Ton zu schreiben, unbekannte Begriffe bei der ersten Verwendung zu erklären, direkte Sätze gegenüber Marketing-Sprache zu bevorzugen, bestätigte Fakten von Annahmen zu unterscheiden und Überschriften sowie Code-Blöcke nur dann zu verwenden, wenn sie die Navigation verbessern.

Anthropics aktuelle Prompting-Richtlinien empfehlen ausdrücklich klare und direkte Anweisungen, Kontext darüber, warum ein Verhalten wichtig ist, Beispiele für Ton und Struktur sowie XML-Tags, wenn ein Prompt verschiedene Arten von Informationen mischt. Es wird auch gesagt, dass das Zuweisen einer Rolle an Claude im System-Prompt hilft, Verhalten und Ton zu fokussieren. Siehe Anthropics Best Practices für Prompting.

Sollten Ton-Regeln im System-Prompt oder im User-Prompt stehen?

Platzieren Sie dauerhafte Regeln im System-Prompt und aufgaben-spezifische Anweisungen im User-Prompt. Der System-Prompt ist der richtige Ort für Regeln wie „Schreiben Sie für Softwareentwickler“, „Vermeiden Sie Marketing-Aussagen“, „Nennen Sie Unsicherheiten statt zu raten“ und „Verwenden Sie prägnante technische Prosa“. Die User-Nachricht sollte den aktuellen Job beschreiben: zum Beispiel „Schreiben Sie einen Migrationsleitfaden von Version 4 zu Version 5 unter Verwendung dieser Versionshinweise.“

Diese Trennung reduziert Wiederholungen und macht Ihre Dokumentations-Pipeline leichter testbar. Sie verhindert auch, dass eine einzelne Aufgabenanfrage Ihre gesamte redaktionelle Stimme neu definiert.

Ein einfaches System-Prompt-Muster

<role>
Sie sind ein Autor für technische Dokumentation.
</role>

<audience>
Schreiben Sie für Softwareentwickler und Systemadministratoren.
Gehen Sie von allgemeiner technischer Kompetenz aus, erklären Sie aber produktspezifische Begriffe bei der ersten Verwendung.
</audience>

<tone>
Verwenden Sie einen professionellen, neutralen, direkten Ton.
Bevorzugen Sie konkrete Sprache gegenüber Hype oder werblichen Aussagen.
Vermeiden Sie Slang, Füllwörter, Emojis und übertriebene Sicherheit.
Halten Sie Sätze angemessen kurz und Absätze fokussiert.
</tone>

<accuracy>
Erfinden Sie keine Befehle, Funktionen, Versionen, Benchmarks oder Verhaltensweisen.
Unterscheiden Sie verifizierte Fakten von Annahmen oder Empfehlungen.
Wenn erforderliche Informationen fehlen, sagen Sie, was unbekannt ist.
</accuracy>

<format>
Verwenden Sie beschreibende Überschriften.
Verwenden Sie Listen nur für wirklich diskrete Schritte oder Checks.
Verwenden Sie Code-Blöcke für Befehle und Code.
Fügen Sie keine Schlussfolgerung hinzu, die den Artikel nur wiederholt.
</format>

Dies funktioniert, weil jeder Abschnitt eine Aufgabe hat. Anthropic empfiehlt speziell konsistente, beschreibende XML-Tags für komplexe Prompts, damit das Modell Anweisungen, Kontext, Beispiele und Eingaben zuverlässiger unterscheiden kann.

Wie spezifisch sollten die Ton-Regeln sein?

Spezifisch genug, dass ein anderer Autor ihnen folgen kann, ohne nachzufragen, was Sie gemeint haben. „Seien Sie professionell“ ist schwach, weil professionelle API-Dokumentation, architektonische Notizen für Führungskräfte und Setup-Anweisungen für Endbenutzer alle unterschiedlich klingen können.

Eine stärkere Regel beschreibt beobachtbares Verhalten:

Positive Anweisungen sind in der Regel leichter umzusetzen als reine Verbotsregeln. Anstatt nur zu sagen „klingen Sie nicht werblich“, fügen Sie die gewünschte Alternative hinzu: „Beschreiben Sie Vorteile in konkreten Begriffen, die an Benutzerergebnisse geknüpft sind.“

Wie verhindern Sie, dass Ton-Regeln die technische Genauigkeit beeinträchtigen?

Lassen Sie nicht zu, dass Stil die Beweislage übertrumpft. Ein häufiger Fehler ist es, nach „selbstbewusstem, autoritativem Schreiben“ zu fragen, ohne auch zu definieren, was das Modell tun soll, wenn das Quellmaterial unvollständig ist. Das kann dazu führen, dass polierte Unsicherheit statt nützlicher Dokumentation erzeugt wird.

Fügen Sie eine Genauigkeitsgrenze wie diese hinzu:

Wenn Dokumentationsquellen eine Tatsache nicht belegen:
- Leiten Sie keine Produktfähigkeit aus dem Namen oder dem UI-Erscheinungsbild ab.
- Geben Sie an, dass das Verhalten nicht verifiziert werden konnte.
- Fragen Sie nach der fehlenden Quelle, wenn die Tatsache erforderlich ist, um die Aufgabe abzuschließen.
- Verwandeln Sie Annahmen nicht in definitive Anweisungen.

Für technische Dokumentation ist diese Regel oft wertvoller als eine generische Anweisung, „Halluzinationen zu vermeiden“, weil sie das erwartete Verhalten definiert, wenn Beweise fehlen.

Sollten Sie die Ausführlichkeit im System-Prompt spezifizieren?

Ja, wenn Dokumentlänge und -dichte wichtig sind. Anthropics aktuelle Prompting-Richtlinien weisen darauf hin, dass sich neuere Claude-Modelle im Standard-Kommunikationsstil und in der Ausführlichkeit unterscheiden. Die Dokumentation rät ausdrücklich dazu, bei Bedarf explizit nach Prägnanz zu prompten, anstatt anzunehmen, dass Aufwand oder andere Modelleinstellungen die sichtbare Antwortlänge konsistent steuern.

Eine praktische Dokumentationsgrenze kann die Dichte definieren, anstatt einer festen Wortanzahl:

Führen Sie mit den Informationen, die zum Handeln benötigt werden.
Verwenden Sie genug Erklärung, um die Anweisung sicher und eindeutig zu machen.
Wiederholen Sie dieselbe Empfehlung nicht in Einleitung, Hauptteil und Schluss.
Bevorzugen Sie kurze Abschnitte für einfache Korrekturen.
Erklären Sie bei Architektur- oder Migrationsthemen Trade-offs und Voraussetzungen tiefer.

Dies skaliert besser als eine pauschale Anweisung „schreiben Sie immer 1.000 Wörter“.

Wie viele Beispiele sollten Sie einbeziehen?

Verwenden Sie Beispiele, wenn Prosa-Regeln noch Raum für Interpretationen lassen. Anthropic bezeichnet Beispiele als eine der zuverlässigsten Methoden, um Format, Ton und Struktur zu steuern, und die aktuellen Richtlinien empfehlen, etwa drei bis fünf relevante, vielfältige Beispiele zu verwenden, wenn Sie sich auf Few-Shot-Prompting verlassen.

Für Dokumentation sollten Beispiele verschiedene Fälle abdecken, anstatt eine einzige Stimmprobe zu wiederholen. Ein nützlicher Satz könnte eine kurze Fehlerbehebungsantwort, einen API-Referenz-Absatz, eine Warnung vor Datenverlust, eine versionsabhängige Notiz und ein Beispiel enthalten, in dem das Modell sagen muss, dass etwas nicht verifiziert ist.

Machen Sie die Beispiele nicht so lang, dass sie den Prompt dominieren. Ihr Zweck ist es, das Muster zu zeigen, nicht einen versteckten Template bereitzustellen, den jeder Artikel mechanisch kopiert.

Welche Ton-Grenzen sind für gängige Dokumentationsarten nützlich?

Was sollte nicht als „Ton“ kodiert werden?

Vergraben Sie keine Geschäftslogik, Sicherheitsrichtlinien oder faktische Einschränkungen in einem vagen Stilabschnitt. „Geben Sie niemals Zugangsdaten preis“, „verwenden Sie nur Informationen aus genehmigten Quellen“ und „führen Sie keine Befehle aus“ sind Verhaltens- oder Sicherheitsregeln, keine Ton-Präferenzen. Geben Sie ihnen separate Abschnitte, damit sie sichtbar und testbar bleiben.

Dasselbe gilt für Ausgabe-Schemas. Wenn eine Anwendung gültiges JSON, exakte Schlüssel oder maschinenlesbare Felder benötigt, spezifizieren Sie dies als Ausgabe-Vertrag, anstatt es als stilistische Präferenz zu beschreiben.

Wie sollten Sie einen Dokumentations-System-Prompt testen?

Urteilen Sie nicht anhand eines einzigen erfolgreichen Beispiels. Erstellen Sie einen kleinen Evaluierungssatz, der normale Aufgaben und Randfälle enthält. Ein nützlicher Testpack könnte enthalten:

• Eine einfache „Wie installiere ich das?“-Anfrage.
• Einen Migrationsleitfaden mit Breaking Changes.
• Ein Quelldokument mit stark werblicher Sprache, die nicht in den endgültigen Ton durchsickern sollte.
• Einen Prompt mit unvollständigen Versionsinformationen.
• Eine technische Frage, deren Antwort durch die gelieferte Quelle nicht belegt ist.
• Eine Anfrage nach einer langen Erklärung, bei der Prägnanz dennoch erhalten bleiben sollte.
• Eine Benutzeranweisung, die einen Stil verlangt, der mit der Dokumentationsrichtlinie Ihrer Organisation kollidiert.

Überprüfen Sie die Ausgaben anhand expliziter Kriterien: richtige Zielgruppe, neutraler Ton, keine unbelegten Aussagen, angemessene Details, konsistente Terminologie, klare Unsicherheit und nutzbare Struktur. Anthropics Prompting-Richtlinien empfehlen auch, klare Erfolgskriterien zu definieren und Ergebnisse zu überprüfen, anstatt sich nur auf Intuition zu verlassen.

Wie verhindern Sie, dass der System-Prompt aufgebläht wird?

Halten Sie Regeln auf der Ebene stabiler redaktioneller Richtlinien. Wenn ein Satz mehrere Fälle abdeckt, ersetzen Sie ihn nicht durch zwölf enge Verbote. Aktuelle Anthropic-Richtlinien für neuere Modelle warnen auch vor Over-Prompting: Stärkere Befolgung von Anweisungen kann dazu führen, dass aggressive alte Formulierungen wie wiederholte „CRITICAL“- oder „MUST“-Regeln Verhalten auslösen, dem neuere Modelle bereits mit normaler Formulierung folgen würden.

Eine gute Wartungsregel ist, eine System-Prompt-Anweisung erst hinzuzufügen, nachdem Sie den wiederkehrenden Fehler benennen können, den sie verhindert. Wenn eine Regel nur für einen Artikel existiert, setzen Sie sie in den User-Prompt für diesen Artikel.

Wiederverwendbarer System-Prompt für technische Dokumentation

<role>
Sie sind ein Senior-Autor für technische Dokumentation.
</role>

<audience>
Schreiben Sie für die in der Benutzeranfrage angegebene Zielgruppe.
Wenn keine Zielgruppe angegeben ist, gehen Sie von technisch kompetenten Praktikern aus.
Erklären Sie ungewöhnliche produktspezifische Terminologie bei der ersten Verwendung.
</audience>

<tone>
Verwenden Sie klares, professionelles, neutrales Amerikanisches Englisch.
Führen Sie mit den Informationen, die zum Handeln benötigt werden.
Vermeiden Sie Hype, lockere Füllwörter, Witze, Emojis, übertriebene Sicherheit
und Phrasen, die wie Marketing-Copy klingen.
Verwenden Sie direkte Aussagen, wenn Fakten verifiziert sind.
</tone>

<accuracy>
Erfinden Sie niemals Produktverhalten, Befehle, UI-Labels, Versionen,
Benchmarks, Einschränkungen oder Testergebnisse.
Trennen Sie verifizierte Fakten, bedingtes Verhalten, Empfehlungen
und Unbekanntes.
Wenn die Beweislage unzureichend ist, sagen Sie dies explizit.
</accuracy>

<structure>
Verwenden Sie beschreibende Überschriften, die der Navigation helfen.
Bevorzugen Sie kurze, fokussierte Absätze.
Verwenden Sie nummerierte Schritte nur für geordnete Verfahren.
Verwenden Sie Aufzählungspunkte für wirklich diskrete Checks oder Optionen.
Verwenden Sie Code-Blöcke für Befehle und Code.
Vermeiden Sie wiederholende Zusammenfassungen.
</structure>

<examples>
Stellen Sie 3–5 aufgabenrelevante Beispiele im Produktions-Prompt bereit,
wenn Ton oder Format mehrdeutig bleiben.
</examples>

<quality_check>
Überprüfen Sie vor der Fertigstellung, ob die Antwort der angeforderten
Zielgruppe entspricht, konsistente Terminologie verwendet, unbelegte Aussagen
vermeidet und das angeforderte Ausgabeformat befolgt.
</quality_check>

Das Ziel ist nicht, dass jedes Dokument identisch klingt. Das Ziel ist, die Grenzen stabil zu machen: Genauigkeit wird nicht zu Enthusiasmus, Unsicherheit wird nicht zu Raten, technische Tiefe wird nicht zu unnötigem Jargon und Prägnanz entfernt keine Voraussetzungen oder Sicherheitsinformationen.

Ein gut gestalteter Claude-System-Prompt funktioniert am besten als redaktionelle Policy-Ebene. Halten Sie die dauerhafte Stimme und Qualitäts-Grenzen dort, halten Sie artikel-spezifische Anforderungen im User-Prompt und verwenden Sie einen kleinen Evaluierungssatz, um zu überprüfen, dass beide Ebenen weiterhin Dokumentation produzieren, der Ihre Leser vertrauen können.