AI für Dokumentation

AI für Dokumentation: Wie du mit Claude & ChatGPT automatisch API-Docs, READMEs, JSDoc, Code-Kommentare und Architektur-Dokumentation generierst. 10 Prompts + Templates.

Einleitung

Dokumentation schreiben ist die unbeliebteste Aufgabe unter Entwicklern. Gleichzeitig ist fehlende oder veraltete Dokumentation einer der größten Produktivitätskiller in Teams. KI-Tools lösen dieses Dilemma: Sie generieren Dokumentation in Minuten statt Stunden – und sie wird sogar gut.

In diesem Artikel zeige ich dir 10 Prompts und Templates für die häufigsten Dokumentationsaufgaben.

Vor allem in der Praxis hat sich dieser Workflow bewährt.

Außerdem profitierst du von einem systematischen Vorgehen.

Warum AI-generierte Dokumentation?

Darüber hinaus bietet dieser Abschnitt konkrete Beispiele und Tipps.

Geschwindigkeit: Eine vollständige README in 2 Minuten statt 2 Stunden
Konsistenz: KI folgt einem Template – jedes Mal das gleiche Format
Vollständigkeit: KI vergisst keine Edge Cases oder Parameter
Aktualität: Bei Code-Änderungen einfach neu generieren lassen
Sprache: KI schreibt verständlich, auch für Nicht-Muttersprachler

Wichtig: AI-generierte Dokumentation muss immer reviewed werden. KI kann Annahmen treffen, die nicht stimmen. Nutze sie als ersten Entwurf, nicht als finales Produkt.

Dementsprechend solltest du die einzelnen Schritte sorgfältig abarbeiten.

Prompt 1: README.md generieren

Insbesondere für den Einstieg sind die folgenden Informationen hilfreich.

Generiere eine vollständige README.md für dieses Projekt:

Projektname: [Name]
Sprache: [TypeScript/Python/etc.]
Zweck: [1-2 Sätze]

Quellcode:
```[sprache]
[Hauptdateien oder package.json/pyproject.toml einfügen]
```

Die README soll enthalten:
1. Projekt-Titel mit Badge-Platzhaltern (Build, Coverage, License)
2. Kurzbeschreibung (max. 2 Sätze)
3. Features (Bullet Points)
4. Prerequisites
5. Installation (Schritt für Schritt)
6. Quick Start / Usage mit Code-Beispiel
7. Konfiguration (alle Optionen als Tabelle)
8. API / CLI Referenz
9. Contributing Guidelines (kurz)
10. License

Format: GitHub-flavored Markdown

Im Grunde funktioniert dieser Ansatz mit allen gängigen AI-Tools.

Zudem lassen sich die Ergebnisse auch auf andere Projekte übertragen.

Prompt 2: API-Dokumentation

Vor allem für den praktischen Einsatz sind diese Informationen wertvoll.

Generiere eine vollständige API-Dokumentation für diese Endpunkte:

```[sprache]
[Controller/Route-Code einfügen]
```

Für jeden Endpunkt:
1. HTTP-Methode + URL
2. Kurzbeschreibung
3. Auth: Welche Authentifizierung nötig ist
4. Request: Headers, Query-Parameter, Body (mit Types)
5. Response: Status-Codes mit Beispiel-JSON für jeden
6. Fehler: Mögliche Error-Responses mit Codes
7. cURL-Beispiel
8. Code-Beispiel (JavaScript fetch)

Format: Markdown, geeignet für Docusaurus/GitBook

Tatsächlich lässt sich dieser Code direkt in dein Projekt übernehmen.

Ebenso hilfreich ist ein strukturierter Ansatz bei der Umsetzung.

Prompt 3: JSDoc / Docstrings

Ebenfalls relevant sind die praktischen Anwendungsbeispiele.

Füge JSDoc-Kommentare zu allen Funktionen und Klassen in diesem Code hinzu:

```[sprache]
[Code einfügen]
```

Regeln:
1. @description: Was die Funktion tut (1-2 Sätze)
2. @param: Alle Parameter mit Typ und Beschreibung
3. @returns: Rückgabewert mit Typ und Beschreibung
4. @throws: Welche Exceptions geworfen werden können
5. @example: Ein Nutzungsbeispiel pro Funktion
6. @since: Version leer lassen (füge ich manuell ein)
7. Keine trivialen Kommentare ("Gets the name" für getName())
8. Nur beschreiben, was NICHT offensichtlich aus dem Code lesbar ist

Somit sparst du Zeit und erhältst qualitativ hochwertigeren Output.

Natürlich kannst du den Ansatz an deine Bedürfnisse anpassen.

Prompt 4: Architektur-Dokumentation

Allerdings gibt es einige wichtige Unterschiede zu beachten.

Erstelle eine Architektur-Dokumentation basierend auf diesem Code:

```
[Ordnerstruktur einfügen]
```

Relevante Dateien:
```[sprache]
[Schlüsseldateien einfügen: Entry Point, Config, Hauptmodule]
```

Erstelle:
1. System-Übersicht (1 Absatz)
2. Architektur-Diagramm (als Mermaid-Code)
3. Komponentenbeschreibung (jedes Modul/Package)
4. Datenfluss-Beschreibung
5. Externe Abhängigkeiten und warum sie gewählt wurden
6. Deployment-Architektur
7. Wichtige Design-Entscheidungen

Im Folgenden gehe ich auf die wichtigsten Details ein.

Prompt 5: Onboarding-Guide

Weiterhin ist es wichtig, die Grundlagen zu verstehen.

Erstelle einen Onboarding-Guide für neue Entwickler in diesem Projekt:

Projekt: [Name]
Tech Stack: [Technologien]
Ordnerstruktur:
```
[Ordnerstruktur]
```

Der Guide soll enthalten:
1. "Was ist dieses Projekt?" (2-3 Sätze)
2. Lokales Setup (Schritt für Schritt, copy-paste-ready)
3. Wichtigste Dateien und was sie tun
4. Architektur-Übersicht für Einsteiger
5. "Dein erster Bug-Fix" – Walkthrough
6. Coding Conventions und Styleguide
7. Git-Workflow (Branch-Naming, Commit-Messages, PR-Prozess)
8. Wen fragen bei welchem Thema (Platzhalter)
9. Häufige Fehler und Lösungen

Dabei zeigt dieses Beispiel den grundlegenden Ansatz.

Grundsätzlich empfiehlt es sich, schrittweise vorzugehen.

Prompt 6: Changelog erstellen

Deshalb lohnt es sich, dieses Thema genauer zu betrachten.

Erstelle einen Changelog-Eintrag basierend auf diesen Git-Commits:

```
[Git Log oder Commit-Messages einfügen]
```

Format: Keep a Changelog (https://keepachangelog.com)

Kategorien:
- Added: Neue Features
- Changed: Änderungen an bestehendem Verhalten
- Deprecated: Features die bald entfernt werden
- Removed: Entfernte Features
- Fixed: Bug-Fixes
- Security: Sicherheits-Updates

Schreibe für Endbenutzer verständlich, nicht für Entwickler.
Versionsnummer: [Semver-Nummer]

Außerdem kannst du den Prompt für verschiedene Programmiersprachen anpassen.

Insbesondere für fortgeschrittene Projekte ist das relevant.

Prompt 7: Architecture Decision Records (ADR)

Dementsprechend solltest du die folgenden Aspekte kennen.

Erstelle ein Architecture Decision Record (ADR) für folgende Entscheidung:

Entscheidung: [z.B. "Wir nutzen PostgreSQL statt MongoDB"]
Kontext: [Warum stand die Entscheidung an?]

Format:
# ADR-[Nummer]: [Titel]

## Status
[Proposed/Accepted/Deprecated/Superseded]

## Kontext
[Was ist das Problem?]

## Entscheidung
[Was wurde entschieden?]

## Begründung
[Warum diese Option?]

## Alternativen
[Welche Alternativen wurden geprüft? Pro/Contra für jede]

## Konsequenzen
### Positiv
### Negativ
### Risiken

## Referenzen
[Links, Benchmarks, Dokumente]

Darüber hinaus lässt sich das Beispiel leicht erweitern.

Tatsächlich zeigt die Praxis, dass dieser Ansatz sehr effektiv ist.

Prompt 8: Runbook / Operations Guide

Dennoch solltest du einige Besonderheiten beachten.

Erstelle ein Runbook für den operativen Betrieb dieser Anwendung:

Anwendung: [Name]
Infrastruktur: [Cloud-Provider, Services]
Monitoring: [Tools]

Das Runbook soll enthalten:
1. Service-Übersicht (was läuft wo)
2. Health Checks (URLs, erwartete Responses)
3. Häufige Alarme und was zu tun ist
4. Deployment-Prozess (Schritt für Schritt)
5. Rollback-Prozedur
6. Datenbank-Wartung (Backups, Migrations)
7. Scaling-Prozedur (wann und wie)
8. Incident-Response-Checklist
9. Kontakte und Eskalationspfade

Allerdings gibt es dabei einige Punkte, die du beachten solltest.

Prompt 9: Code-Kommentare optimieren

Grundsätzlich gibt es dabei einige Punkte zu beachten.

Optimiere die Kommentare in diesem Code:

```[sprache]
[Code mit bestehenden Kommentaren einfügen]
```

Regeln:
1. ENTFERNE Kommentare die nur wiederholen, was der Code tut
   ❌ // Increment counter - counter++;
2. BEHALTE Kommentare die erklären WARUM etwas getan wird
   ✅ // Use binary search because the list is always sorted by timestamp
3. FÜGE HINZU: Kommentare für nicht-offensichtliche Logik
4. FÜGE HINZU: TODO/FIXME mit klarer Beschreibung wo nötig
5. FÜGE HINZU: Warnungen vor Seiteneffekten oder Gotchas
6. Kommentare auf Englisch, klar und knapp

Grundsätzlich kannst du diesen Prompt an deine Bedürfnisse anpassen.

Weiterhin ist es sinnvoll, die Ergebnisse regelmäßig zu überprüfen.

Prompt 10: Migrationsleitfaden

Tatsächlich ist dieser Bereich besonders wichtig für Entwickler.

Erstelle einen Migrationsleitfaden:

Migration von: [z.B. React 17 → React 18 / Express 4 → Express 5]
Projekt-Größe: [z.B. 50 Dateien, 10K LOC]
Dependencies: [package.json/requirements.txt einfügen]

Der Leitfaden soll enthalten:
1. Breaking Changes, die uns betreffen (basierend auf unseren Dependencies)
2. Schritt-für-Schritt Migrationsplan
3. Code-Änderungen mit vorher/nachher Beispielen
4. Geschätzte Aufwand pro Schritt
5. Risikobewertung
6. Rollback-Plan
7. Test-Strategie für die Migration

Weiterhin ist es ratsam, die Ergebnisse immer kritisch zu prüfen.

Folglich verbessert sich die gesamte Codequalität deutlich.

Best Practices für AI-generierte Dokumentation

1. Review ist Pflicht

Somit kannst du direkt mit der Umsetzung beginnen.

KI kann Annahmen treffen, die nicht stimmen. Prüfe immer: Stimmen die Typen? Stimmen die Beschreibungen? Fehlt etwas Wichtiges?

2. Gib den richtigen Kontext

Ebenso wichtig ist es, die Best Practices zu kennen.

Je mehr relevanten Code du der KI gibst, desto besser die Dokumentation. Bei Claude kannst du ganze Dateistrukturen einfügen (200K Tokens).

3. Definiere die Zielgruppe

Natürlich gibt es dabei verschiedene Herangehensweisen.

Sage der KI, für wen die Dokumentation ist: Junior-Entwickler? Andere Teams? Endbenutzer? Das ändert den Detailgrad und die Sprache drastisch.

4. Nutze Templates

Im Folgenden findest du alle wichtigen Details dazu.

Erstelle einmal ein gutes Template (README, ADR, API-Doc) und nutze es für alle zukünftigen Projekte. Konsistenz ist wichtiger als Perfektion.

5. Automatisiere Updates

Folglich profitierst du von einem besseren Verständnis dieser Konzepte.

Integriere Dokumentationsgenerierung in deine CI/CD-Pipeline. Tools wie TypeDoc, Swagger oder Storybook können mit KI-generierten Beschreibungen gefüttert werden.

Deshalb ist es wichtig, diesen Abschnitt aufmerksam zu lesen.

FAQ

Kann KI meine gesamte Dokumentation ersetzen?

Im Grunde vereinfacht dieser Ansatz den gesamten Workflow erheblich.

Nein. KI generiert einen hervorragenden ersten Entwurf (80%), den ein Mensch finalisiert (20%). Business-Kontext, politische Entscheidungen und Teamwissen kann die KI nicht kennen.

In welcher Sprache soll ich dokumentieren?

Zusammenfassend lässt sich sagen, dass dies ein zentraler Aspekt ist.

Code-Kommentare und technische Docs auf Englisch (internationaler Standard). Benutzer-Dokumentation in der Sprache deiner Zielgruppe. KI kann beides.

Wie halte ich die Dokumentation aktuell?

Außerdem gibt es hilfreiche Tools, die dich dabei unterstützen.

Regel: Bei jedem PR, der Code ändert, auch die Docs updaten. Nutze die KI: „Hier ist die aktuelle Doku und der geänderte Code. Was muss in der Doku angepasst werden?“

Welches Tool für welche Dokumentation?

Dabei spielen mehrere Faktoren eine wichtige Rolle.

Claude für lange, strukturierte Dokumente (README, Architektur, ADR). ChatGPT für schnelle Docs und Erklärungen. GitHub Copilot für inline JSDoc/Docstrings direkt im Editor.

Hierbei hilft es, von konkreten Beispielen auszugehen.

Verwandte Artikel:

Dabei ist der folgende Punkt besonders wichtig.

Zuletzt aktualisiert: März 2026