AI Prompt Engineering · Lektion

Prompts für technische Dokumentation

README-Dateien, API-Dokumentation und Anleitungen mit präziser technischer Ausdrucksweise

Lektion 3 von 413 Schritte

Prompts für technische Dokumentation ist eine kostenlose AI Prompt Engineering-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AI Prompt Engineering-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AI Prompt Engineering-Kurs umfasst insgesamt 4 Lektionen.

Technische Dokumentation ist ein eigenes Genre

Technische Dokumentation ist ein eigenständiges Schreibgenre mit spezifischen Konventionen: Präzision statt Stil, Struktur statt Erzählung, Vollständigkeit statt Kürze. Prompts, die für Blogbeiträge oder E-Mails funktionieren, führen bei technischen Dokumenten zum falschen sprachlichen Register.

Wirksame Prompts für technische Dokumentation legen das Genre ausdrücklich fest – den Dokumenttyp, das vorausgesetzte Wissensniveau des Lesers, die Standardstruktur für diesen Dokumenttyp und die Sprachkonvention (typischerweise die zweite Person für Anleitungen und die dritte Person für Referenzdokumentation).

Prompts für README-Dateien

Eine README ist der Einstiegspunkt in ein Projekt. Ihre Standardstruktur ist gut etabliert. Ein wirksamer README-Prompt gibt jeden Abschnitt vor:

Projektname und einzeilige Beschreibung
Was es tut: Zweck in 2–3 Sätzen
Voraussetzungen: was installiert sein muss
Installation: nummerierte Schritte mit Befehlen
Schnellstart: minimales funktionierendes Beispiel
Konfiguration: Umgebungsvariablen und Optionen
Beitragen: wie Sie PRs einreichen
Lizenz

Wenn alle Abschnittsnamen im Prompt angegeben werden, entsteht eine vollständige README. Nicht ausdrücklich angegebene Abschnitte werden weggelassen.

README-Prompt im Code

Ein strukturierter README-Generator, der Projektmetadaten entgegennimmt:

import openai

client = openai.OpenAI(api_key='sk-...')

def generate_readme(project_name, description, language, dependencies,
                    install_steps, quick_start_example, config_vars, license_type):

    prompt = f'''Write a README.md for the following project.

Project name: {project_name}
Description: {description}
Language/stack: {language}
Dependencies: {dependencies}
Installation steps: {install_steps}
Quick start example: {quick_start_example}
Key configuration variables: {config_vars}
License: {license_type}

Structure the README with these sections in order:
1. Project title and badge line (GitHub stars, license)
2. One-sentence description
3. Features (3-5 bullet points)
4. Prerequisites
5. Installation (numbered steps with code blocks)
6. Quick Start (minimal working example in a code block)
7. Configuration (table: Variable | Description | Default)
8. Contributing (2-3 sentences)
9. License

Voice: second person imperative for steps ("Run...", "Install...").
Code blocks: use correct language identifiers.
Do not add placeholder content — only include sections where I provided information.'''

    response = client.chat.completions.create(
        model='gpt-4o-mini',
        messages=[{'role': 'user', 'content': prompt}]
    )
    return response.choices[0].message.content

Prompts für API-Dokumentation

API-Dokumentation folgt einer festen Struktur. Jeder Endpunkt-Eintrag benötigt: HTTP-Methode, Pfad, Beschreibung, Parameter, Request-Body, Antwortformat, Fehlercodes und ein Beispiel. Prompts müssen all das angeben:

"Schreiben Sie die API-Dokumentation für einen REST-Endpunkt. Fügen Sie Folgendes ein: Methode (POST), Pfad (/api/v1/users), Beschreibung, Parametertabelle (Name, Typ, erforderlich, Beschreibung), JSON-Beispiel für den Request-Body, JSON-Beispiel für eine erfolgreiche Antwort (200), Fehlerantworten (400, 401, 422) mit JSON-Beispielen. Sprachstil: dritte Person, Präsens. Verwenden Sie Markdown-Tabellen für Parameter."

Jedes Strukturelement muss ausdrücklich benannt werden – das Modell wird Ihren Dokumentationsstandard nicht erraten.

Prompts für Anleitungen

Anleitungen sind prozedural aufgebaut: Sie führen die lesende Person in nummerierten Schritten von Zustand A (Problem) zu Zustand B (Lösung). Elemente für Prompts zu Anleitungen:

Voraussetzungen: was vor dem Beginn erfüllt sein muss
Ergebnis: was die lesende Person erreicht haben wird
Schritte: nummeriert, jeweils eine Handlung – keine mehreren Handlungen in einem Schritt
Codebeispiele: sofern relevant eines pro Schritt, mit Angabe der Sprache
Validierung: woran die lesende Person erkennt, dass der jeweilige Schritt erfolgreich war
Fehlerbehebung: häufige Fehler bei den zwei oder drei schwierigsten Schritten

Technische Genauigkeit in Dokumentations-Prompts

Für technische Dokumentation gelten höhere Genauigkeitsanforderungen als für die meisten anderen Inhaltstypen. Zwei Techniken zur Verbesserung der Genauigkeit in Dokumentations-Prompts:

Stellen Sie den tatsächlichen Code bereit: Fügen Sie die echten Funktionssignaturen, Konfigurationsoptionen oder die API-Spezifikation ein. Das Modell dokumentiert dadurch, was tatsächlich vorhanden ist, statt Details zu erfinden.

Fordern Sie einen Verifizierungsschritt an: „Notieren Sie nach dem Schreiben jedes Schritts alle Annahmen, die Sie über die Umgebung der nutzenden Person oder das Systemverhalten treffen. Kennzeichnen Sie alles, was ich vor der Veröffentlichung überprüfen sollte.“

Verwenden Sie niemals KI-generierte Dokumentation ohne technische Prüfung – das Modell dokumentiert mit großer Sicherheit Dinge, die nicht existieren oder falsch sind.

Qualität von Codebeispielen in der Dokumentation

Codebeispiele sind das wichtigste Element technischer Dokumentation. Fordern Sie sie ausdrücklich an:

„Fügen Sie pro wichtigem Konzept ein funktionierendes Codebeispiel ein. Die Beispiele sollten in sich geschlossen sein – die lesende Person sollte sie kopieren, einfügen und ausführen können.“
„Zeigen Sie sowohl die korrekte Verwendung als auch einen häufigen Fehler und erklären Sie in einem Kommentar, warum dieser Fehler auftritt.“
„Die Codebeispiele sollten realistische Variablennamen und Daten verwenden, nicht ‚foo‘, ‚bar‘ oder ‚test‘.“
„Sprache: Python 3.11. Verwenden Sie Typannotationen. Behandeln Sie Fehler für den Netzwerkaufruf.“

Ohne ausdrückliche Vorgaben für Codebeispiele erzeugt das Modell möglicherweise unvollständige Pseudo-Code-Schnipsel, die tatsächlich nicht ausführbar sind.

Stimme und Stil technischer Dokumentation

Technische Dokumentation hat eine bestimmte Stimme, die sich von anderen Textsorten unterscheidet:

Imperativ in der Anrede mit Sie für Abläufe: „Klicken Sie auf Einstellungen. Wählen Sie den API-Tab aus. Geben Sie Ihren Schlüssel ein.“
Dritte Person in Referenzdokumentation: „Die authenticate()-Methode gibt ein 24 Stunden gültiges Bearer-Token zurück.“
Präsens: „Die Funktion gibt … zurück“, nicht „Die Funktion wird … zurückgeben“
Keine einschränkenden Formulierungen: „Führen Sie diesen Befehl aus“, nicht „Sie könnten erwägen, diesen Befehl auszuführen“
Einheitliche Terminologie: Verwenden Sie im gesamten Text für dasselbe Konzept denselben Begriff – keine Synonyme

Prompts für Changelogs und Versionshinweise

Changelogs und Versionshinweise haben ein gängiges Format, das in den Prompts festgelegt werden sollte:

„Schreiben Sie Versionshinweise für Version 2.3.0. Format: Versionsüberschrift, Veröffentlichungsdatum, danach drei Abschnitte: ‚Hinzugefügt‘ (neue Funktionen), ‚Geändert‘ (Änderungen an bestehenden Funktionen), ‚Behoben‘ (Fehlerbehebungen). Jeder Eintrag: eine Zeile, Aktivform, beginnend mit einem Verb. Zielgruppe: Entwicklerinnen und Entwickler, die diese Bibliothek integrieren. Ton: präzise und neutral – keine Marketingsprache. Hier sind die Änderungen: [Liste der tatsächlichen Änderungen].“

Wenn Sie die tatsächlichen Änderungen als Eingabedaten bereitstellen, gewährleistet dies die Genauigkeit. Ohne diese Angaben erfindet das Modell plausibel klingende, aber fiktive Versionshinweise.

Vollständigkeitsprüfung der Dokumentation

Führen Sie nach der Generierung technischer Dokumentation einen Prompt zur Vollständigkeitsprüfung aus:

import openai

client = openai.OpenAI(api_key='sk-...')

def check_documentation_completeness(doc_text, doc_type='how-to guide'):
    checklist = {
        'how-to guide': [
            'Prerequisites stated?',
            'Expected outcome stated?',
            'Each step is a single action?',
            'Code examples included where relevant?',
            'Validation step for each major action?',
            'Common errors addressed?'
        ],
        'readme': [
            'One-line description present?',
            'Installation steps numbered with commands?',
            'Quick start example included?',
            'Configuration variables documented?',
            'License specified?'
        ]
    }

    items = checklist.get(doc_type, [])
    check_prompt = f'Review this {doc_type} and answer each question (Yes/No + brief note):\n'
    for item in items:
        check_prompt += f'- {item}\n'
    check_prompt += f'\nDocument:\n{doc_text[:2000]}'

    response = client.chat.completions.create(
        model='gpt-4o-mini',
        messages=[{'role': 'user', 'content': check_prompt}]
    )
    return response.choices[0].message.content

Fachbegriffe für gemischte Zielgruppen übersetzen

Technische Dokumentation muss häufig sowohl technischen als auch nichttechnischen Leserinnen und Lesern dienen. Ein praktisches Prompt-Muster:

„Schreiben Sie diese Dokumentation in zwei Ebenen. Erste Ebene: eine nichttechnische Zusammenfassung in drei Sätzen (was sie tut, warum sie wichtig ist, wann sie verwendet wird). Zweite Ebene: die vollständige technische Spezifikation. Verwenden Sie eine klare visuelle Trennung zwischen den Ebenen. So können nichttechnische Führungskräfte die Zusammenfassung lesen und aufhören; technische Leserinnen und Leser können die Zusammenfassung überspringen und die Spezifikation lesen.“

Eine Dokumentation mit zwei Ebenen ist nützlicher als der Versuch, eine einzige Version zu schreiben, die beiden Zielgruppen nur unzureichend dient.

Wissensüberprüfung: Prompts für technische Dokumentation

Sie schreiben Prompts zur Generierung einer API-Dokumentation für 50 Endpunkte. Die wichtigste Qualitätsanforderung ist, dass die Dokumentation das tatsächliche Verhalten der API korrekt wiedergibt und nicht das, was sich das Modell über ihr Verhalten vorstellt. Welcher Ansatz gewährleistet die Genauigkeit am besten?

Beantworte es in der interaktiven Lektion

Zusammenfassung: Prompts für technische Dokumentation

Technische Dokumentation ist eine eigene Textsorte, die Präzision, Struktur und für Abläufe den Imperativ in der Anrede mit Sie erfordert. Effektive Prompts geben den Dokumenttyp, die namentlich geforderten Abschnitte, Anforderungen an Codebeispiele (in sich geschlossen, realistische Variablennamen, Sprachversion) und die Konvention für die Dokumentationsstimme vor.

Die wichtigste Technik für Genauigkeit: Stellen Sie immer den tatsächlichen Code, die API-Spezifikation oder die Konfigurationsdaten als Eingabe bereit – fordern Sie das Modell niemals auf, technische Details zu erfinden. Lassen Sie KI-generierte Dokumentation vor der Veröffentlichung immer von einer technisch qualifizierten Person prüfen.

In der letzten Lektion wenden Sie Prompting-Techniken auf kreative Inhalte und Inhalte des Storytellings an.

Kostenlos starten

Lerne AI Prompt Engineering mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse: 53
Lektionen: 199

Kostenlos lernen Den vollständigen Kurs ansehen

Häufig gestellte Fragen

Ist die Lektion „Prompts für technische Dokumentation“ kostenlos?

Ja — der vollständige Text von „Prompts für technische Dokumentation“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AI Prompt Engineering-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AI Prompt Engineering-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Prompts für technische Dokumentation“?

README-Dateien, API-Dokumentation und Anleitungen mit präziser technischer Ausdrucksweise Du übst AI Prompt Engineering mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um AI Prompt Engineering zu starten?

Keine Vorkenntnisse erforderlich. AI Prompt Engineering auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „Prompts für technische Dokumentation“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser AI Prompt Engineering-Lektion Code schreiben und ausführen?

Ja. Jede AI Prompt Engineering-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Prompts für E-Mails und professionelles Schreiben
Prompts für Social-Media-Inhalte
Prompts für technische Dokumentation
Prompts für Kreatives und Storytelling

← Zurück zu AI Prompt Engineering