---
title: "6 Prompt-Prinzipien für bessere Ergebnisse mit Claude Code"
locale: de
category: tutorial
category_name: "Tutorial"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/claude-code-prompt-six-principles-and-templates
published_at: 2026-08-23T02:30:01+09:00
---

# 6 Prompt-Prinzipien für bessere Ergebnisse mit Claude Code

> Hier wird erläutert, wie Sie statt einer einfachen Aufforderung zur Codeerstellung den Kontext, den Ausgabevertrag, die Ausnahmebehandlung und die Validierungskriterien strukturiert an Claude Code übermitteln. Zudem werden Prompt-Vorlagen bereitgestellt, die sich direkt auf die Entwicklung neuer Agenten, Funktionserweiterungen und Fehlerbehebungen anwenden lassen.

## Key Points

- 1. Fassen Sie vor Beginn der Arbeit den Nutzerkontext, das zu lösende Problem, die Erfolgskriterien und die technischen Einschränkungen in einem Dokument zusammen.
- 2. Legen Sie die Dateistruktur und das Datenformat des Ergebnisses, den zulässigen Umfang sowie die Abschlussbedingungen in einem konkreten Ausgabevertrag fest.
- 3. Definieren Sie vorhersehbare Ausnahmen wie Ausfälle externer APIs, leere Ergebnisse, doppelte Daten und Authentifizierungsfehler sowie entsprechende Reaktionsrichtlinien.
- 4. Unterteilen Sie die Arbeit in die Prüfung des Plans, die Umsetzung der Mindestfunktionalität, automatisierte Tests und die Funktionserweiterung, und überprüfen Sie die Ergebnisse nach jedem Schritt.
- 5. Geben Sie statt unklarer Überarbeitungsaufforderungen konkrete Fehlerfälle und messbare Verbesserungsziele an und validieren Sie das Ergebnis anhand der endgültigen Abnahmebedingungen.

Coding-Agenten wie Claude Code sind nicht nur Werkzeuge, die einzelne Codefragmente erzeugen, sondern Arbeitsumgebungen, die Repositorys durchsuchen, mehrere Dateien ändern sowie Tests und Befehle ausführen können. Daher hängt die Qualität des Ergebnisses weniger davon ab, wie plausibel Formulierungen klingen, sondern maßgeblich davon, **wie klar Arbeitsumfang und Validierungsmethode definiert sind**.

Ein guter Prompt ist kein langer Erklärungstext, sondern eine ausführbare Arbeitsspezifikation. Er sollte nicht nur vermitteln, was erstellt werden soll, sondern auch, warum es benötigt wird, welche Bedingungen einzuhalten sind, wie mit Fehlern umzugehen ist und welche Kriterien für den Abschluss erfüllt sein müssen.

## Zuerst unterscheiden: Prompt und Ausführungsumgebung

Vibe Coding ist eine Form der Zusammenarbeit, bei der Absichten in natürlicher Sprache vermittelt werden und ein AI-Agent die Implementierung übernimmt. Die Tatsache, dass eine Anfrage in natürlicher Sprache gestellt wurde, garantiert jedoch weder die Korrektheit des Codes noch die Stabilität im Betrieb.

Bei Arbeiten mit Claude Code wirken die folgenden Elemente zusammen.

| Element | Rolle | Im Prompt zu klärende Inhalte |
|---|---|---|
| Benutzeranfrage | Vermittelt Ziel und Änderungsumfang | Zweck, Prioritäten, Verbote |
| Repository-Kontext | Stellt bestehende Struktur und Regeln bereit | Framework, Ausführungsbefehle, relevante Dateien |
| `CLAUDE.md` | Stellt wiederholt anzuwendende Projektanweisungen bereit | Coding-Regeln, Testmethoden, Verzeichniskonventionen |
| Werkzeugberechtigungen | Kontrollieren den zulässigen Umfang von Dateiänderungen und Befehlsausführungen | Zulässige Befehle und Arbeiten, die eine vorherige Bestätigung erfordern |
| Externe Verbindungen | Ermöglichen den Zugriff auf APIs, Datenbanken, MCP-Server usw. | Authentifizierungsmethode, Vertrauensgrenzen, Fehlerrichtlinien |
| Validierungsverfahren | Stellen fest, ob das Ergebnis die Anforderungen erfüllt | Tests, statische Analyse, manuell zu prüfende Punkte |

Auch ein gut formulierter Prompt löst nicht alle Probleme. Claude Code kann beispielsweise Code für eine geplante Ausführung erstellen. Soll die Aufgabe jedoch auch bei ausgeschaltetem Computer ausgeführt werden, ist ein separater Server, ein CI-Dienst oder ein Scheduler des Betriebssystems erforderlich. Auch der E-Mail-Versand kann ohne Authentifizierungsdaten und Versandberechtigung eines realen Anbieters nicht fertiggestellt werden.

## Prinzip 1. Zuerst Hintergrund, Zweck und Einschränkungen erläutern

Wenn lediglich die Bezeichnung des Ergebnisses genannt wird, etwa `Erstelle mir einen Agenten zur Nachrichtensammlung`, muss der Agent Benutzer, Datenquellen, Ausführungsumgebung und Erfolgskriterien erraten. Selbst bei demselben Nachrichtensammler unterscheiden sich die benötigten Quellen und Klassifizierungskriterien für Verantwortliche in der Geschäftsentwicklung, Investoren oder Redakteure einer Universitätszeitung.

### Unzureichende Anfrage

```text
Erstelle mir einen Agenten zum Sammeln von AI-Nachrichten.
```

### Verbesserte Anfrage

```text
Ich bin für die Geschäftsentwicklung eines IT-Start-ups verantwortlich.
Ich möchte jeden Tag vor Arbeitsbeginn schnell Nachrichten aus den Bereichen
AI, Cloud und Fintech prüfen, die sich auf Geschäftspartnerschaften oder die Produktstrategie auswirken.

Ziele:
- Für die angegebenen Schlüsselwörter Kandidaten aktueller Artikel sammeln.
- Artikel mit derselben URL und Duplikate mit ähnlichen Titeln entfernen.
- Die Auswirkungen danach als hoch, mittel oder niedrig klassifizieren,
  ob innerhalb von 3 Monaten eine Produkt- oder Partnerschaftsentscheidung erforderlich ist.
- Die Ergebnisse als koreanisches E-Mail-Briefing erstellen.

Einschränkungen:
- Die Python-Version und Paketverwaltungsmethode des aktuellen Repositorys beibehalten.
- Vor dem Hinzufügen einer neuen Bibliothek deren Notwendigkeit und Alternativen erläutern.
- API-Schlüssel und E-Mail-Passwörter weder im Code noch in Logs speichern.
- Vor dem tatsächlichen E-Mail-Versand nur eine Vorschaudatei erstellen.

Untersuche zuerst die Repository-Struktur und die Ausführungsmethode und schlage anschließend einen Implementierungsplan vor.
Unbekannte Informationen zur Umgebung nicht erraten, sondern als Fragenliste zusammenstellen.
```

Gute Hintergrundinformationen umfassen die folgenden vier Punkte.

1. **Benutzer und Nutzungssituation:** Wer verwendet das Ergebnis wann und für welche Entscheidung?
2. **Ziel:** Welches Problem soll gelöst werden, statt lediglich Code zu schreiben?
3. **Einschränkungen:** Welche Technologien, Sicherheitsregeln sowie Kosten- oder Zeitlimits müssen eingehalten werden?
4. **Nicht-Ziele:** Welche Funktionen sind ausdrücklich von dieser Änderung ausgeschlossen?

Durch die Angabe von Nicht-Zielen lässt sich verhindern, dass der Umfang unbegrenzt wächst. Wird beispielsweise festgelegt, dass `in dieser Phase die geplante Ausführung und der tatsächliche E-Mail-Versand ausgeschlossen sind`, können zunächst die Sammel- und Klassifizierungslogik zuverlässig validiert werden.

## Prinzip 2. Das gewünschte Ausgabeformat als Ausgabevertrag definieren

`Sende es ansprechend per E-Mail` wird von jedem anders interpretiert. Für das Ausgabeformat sollten nicht nur Beispiele gezeigt, sondern auch Pflichtfelder, zulässige Werte, der Umgang mit fehlenden Angaben und die Sortierreihenfolge definiert werden.

```text
E-Mail-Betreff:
[Nachrichten-Briefing] {YYYY-MM-DD} Die wichtigsten Nachrichten des Tages

Artikelformat im Nachrichtentext:
1. {Titel}
Zusammenfassung: {1–2 Sätze auf Koreanisch}
Auswirkung: {hoch|mittel|niedrig}
Begründung der Bewertung: {1 Satz}
Quelle: {Name des Mediums}
Link: {URL des Originals}

Sortierregeln:
1. Absteigend nach Auswirkung
2. Bei gleicher Auswirkung nach dem neuesten Veröffentlichungszeitpunkt

Statistik am Ende:
- Gesamtzahl der Artikel
- Anzahl der Artikel je Auswirkungsstufe
- Schlüsselwörter ohne Suchergebnisse

Einschränkungen:
- In der Zusammenfassung keine Zahlen oder Behauptungen erfinden, die nicht im Original enthalten sind.
- Wenn das Datum nicht überprüft werden kann, kein Datum schätzen, sondern als 'nicht überprüfbar' kennzeichnen.
- Einträge ohne Link aus dem endgültigen Briefing ausschließen.
```

Wenn Ergebnisse zwischen Programmen übertragen werden müssen, empfiehlt es sich, neben einem für Menschen lesbaren Beispiel auch ein JSON-Schema oder eine Typdefinition anzufordern.

```json
{
  "title": "string",
  "summary": "string",
  "impact": "high | medium | low",
  "reason": "string",
  "source": "string",
  "url": "absolute URL",
  "published_at": "ISO 8601 string | null"
}
```

Ein Ausgabevertrag umfasst nicht nur die Form, sondern auch die Bedeutung. Wenn es keine Bewertungskriterien dafür gibt, was `impact: high` bedeutet, kann die JSON-Syntax korrekt sein, während die Klassifizierungsergebnisse inkonsistent bleiben.

## Prinzip 3. Ausnahmesituationen und Wiederherstellungsrichtlinien festlegen

Die Qualität von Produktionscode zeigt sich stärker im Fehlerpfad als im Normalfall. Im Prompt sollten erwartbare Fehler, die Möglichkeit von Wiederholungsversuchen, die Bedingungen für eine Benachrichtigung des Benutzers und Informationen, die nicht protokolliert werden dürfen, gemeinsam angegeben werden.

| Ausnahmesituation | Beispiel für eine empfohlene Richtlinie |
|---|---|
| Keine Suchergebnisse | Das betreffende Schlüsselwort überspringen und in der abschließenden Statistik erfassen |
| Vorübergehender Netzwerkfehler | Nur eine begrenzte Anzahl von Wiederholungsversuchen in festgelegten Abständen |
| Authentifizierungsfehler | Nicht erneut versuchen, sondern sofort abbrechen und auf die Überprüfung der Konfiguration hinweisen |
| API-Nutzungslimit | Warteanweisungen der Antwort beachten und unbegrenzte Wiederholungsversuche verbieten |
| Doppelte Artikel | Anhand normalisierter URLs und der Titelähnlichkeit entfernen |
| Fehlerhaft formatierte Daten | Original beibehalten und nur den betreffenden Eintrag isolieren |
| Fehler beim E-Mail-Versand | Wenn auch Wiederholungsversuche fehlschlagen, alternative Benachrichtigung senden oder Fehlerstatus protokollieren |
| Teilerfolg | Erfolgreiche Ergebnisse und fehlgeschlagene Einträge getrennt melden |

Richtlinien können wie folgt konkret angefordert werden.

```text
Behandle Netzwerk-Timeouts als Fehler, bei denen ein erneuter Versuch möglich ist.
Warte zwischen den Versuchen. Wenn die maximale Anzahl überschritten wird,
markiere nur die betreffende Quelle als fehlgeschlagen.
Brich bei Authentifizierungsfehlern und fehlerhaften Anfragen sofort ab,
da wiederholte Versuche diese Probleme nicht lösen.

Speichere in allen Fehler-Logs Zeitpunkt, Arbeitsschritt, Quelle und Fehlertyp,
aber keine API-Schlüssel, vollständigen E-Mail-Adressen, Authentifizierungsheader
oder vollständigen Artikeltexte.
Unterscheide über den Prozess-Exit-Status zwischen vollständigem Erfolg,
Teilerfolg und vollständigem Fehlschlag.
```

Werte wie `drei Wiederholungsversuche` oder `5 Sekunden Wartezeit` sind keine universell richtigen Antworten. Sie müssen im Projekt anhand der offiziellen Beschränkungen externer Dienste, der Dringlichkeit der Aufgabe und des Risikos doppelter Ausführungen festgelegt werden. Aufgaben mit Nebenwirkungen, etwa Zahlungen oder der Versand von Nachrichten, können bei automatischen Wiederholungsversuchen ohne garantierte Idempotenz doppelt verarbeitet werden.

## Prinzip 4. Schrittweise in der Reihenfolge Planung, minimale Implementierung und Validierung entwickeln

Wenn mehrere externe Dienste und die automatische Ausführung gleichzeitig verbunden werden, lassen sich Fehlerursachen nur schwer voneinander trennen. Wird die Implementierung in kleine Validierungseinheiten aufgeteilt, können Ein- und Ausgabe jeder Phase überprüft werden.

### Empfohlene Reihenfolge

1. Repository-Struktur, relevante Dateien und Ausführungsbefehle untersuchen.
2. Vor Codeänderungen einen Plan und die betroffenen Dateien vorlegen lassen.
3. Die Sammelfunktion mit einem Schlüsselwort und festgelegten Beispieldaten implementieren.
4. Deduplizierung und Klassifizierung der Auswirkungen jeweils separat testen.
5. E-Mails nicht tatsächlich versenden, sondern anhand einer lokalen Vorschau validieren.
6. Nach Bestehen der Tests die Anbindung eines realen Anbieters und die geplante Ausführung hinzufügen.

Die erste Anfrage kann wie folgt eingeschränkt werden.

```text
Führe jetzt nur Phase 1 aus.
Untersuche das Repository und berichte über Folgendes:
- Einstiegspunkt der aktuellen Anwendung
- Relevante Module und Testdateien
- Verwendete Paketverwaltungs- und Testbefehle
- Dateien, die voraussichtlich geändert werden müssen
- Fragen, die vor der Implementierung geklärt werden müssen

Ändere noch keine Dateien.
```

Nach Prüfung des Plans wird die Implementierung auf einen engen Änderungsumfang begrenzt.

```text
Implementiere aus dem genehmigten Plan nur die Nachrichtensammlung und Deduplizierung.
Füge Klassifizierung, E-Mail-Versand und geplante Ausführung nicht hinzu.
Ermögliche die Ausführung mit festgelegten Testdaten und fasse am Ende
die geänderten Dateien und Ergebnisse der ausgeführten Tests zusammen.
```

Wenn in der Claude Code-Umgebung ein reiner Planungsmodus verfügbar ist, kann er in der Erkundungs- und Entwurfsphase verwendet werden. Ein plausibel wirkender Plan bedeutet jedoch nicht, dass die Implementierung korrekt ist. Daher müssen tatsächliche Tests und eine Codeprüfung folgen.

## Prinzip 5. Feedback anhand von Fehlerbeispielen und Zahlen geben

Mit Aussagen wie `Das Ergebnis ist nicht besonders gut`, `Die Performance ist langsam` oder `Die Klassifizierung ist falsch` lässt sich die Richtung der Korrektur nur schwer bestimmen. Es müssen der aktuelle Zustand, der erwartete Zustand, die Eingabe zur Reproduktion und der zulässige Änderungsumfang angegeben werden.

### Anfrage zur Längenänderung

```text
Der aktuelle E-Mail-Text wird mit etwa 3.000 Zeichen erstellt.
Ich möchte ihn auf höchstens 500 Zeichen kürzen, damit er auf Mobilgeräten schnell gelesen werden kann.
Begrenze jede Artikelzusammenfassung auf 1–2 Sätze und behalte die Bewertungsbegründung bei.
Verlinke die URL des Originals im Titel und entferne die separate Linkzeile.
Behalte die Statistik am Ende bei.
```

### Anfrage zur Änderung der Klassifizierungskriterien

```text
Von 10 Testdatensätzen wurden 8 als 'hoch' klassifiziert.
Klassifiziere langfristige Technologieprognosen oder allgemeine Produktvorstellungen als 'niedrig'.
Klassifiziere einen Artikel nur dann als 'hoch', wenn konkrete Belege dafür vorliegen,
dass innerhalb von 3 Monaten Entscheidungen zu Preisen, Produkt-Roadmap,
regulatorischen Maßnahmen oder Partnerschaften geändert werden müssen.

In den beigefügten Beispielen sind A und B als hoch und C als niedrig korrekt.
Ändere die Klassifizierungsregeln und füge diese Beispiele als Regressionstests hinzu.
```

### Anfrage zur Performanceverbesserung

```text
Die durchschnittliche Ausführungszeit derselben Beispieleingabe beträgt derzeit etwa 45 Sekunden.
Das Ziel liegt in derselben Umgebung bei höchstens 30 Sekunden.
Miss zuerst die Zeit je Phase und zeige den Engpass.
Entferne weder die Ergebnisgenauigkeit noch die Fehlerbehandlung.
Vergleiche Wirkung und Risiken der Verbesserungsalternativen und wende zuerst die kleinste Änderung an.
```

Performancewerte können nur verglichen werden, wenn Messumgebung und Eingabedaten identisch sind. Die Verbesserung sollte nicht anhand eines einzigen Ausführungsergebnisses beurteilt werden. Auch Messmethode, Stichprobe und Cache-Zustand müssen festgelegt werden.

## Prinzip 6. Prompt-Vorlagen nach Aufgabentyp verwenden

### Vorlage zum Erstellen eines neuen Agenten

```text
[Rolle und Situation]
Ich bin {Beruf/Rolle} und möchte {Problemsituation} lösen.
Dieses Ergebnis wird von {Benutzer oder nachgelagertes System} verwendet.

[Ziel]
{Zu erreichendes Ergebnis und Erfolgskriterien}

[Ausführungsauslöser]
{Manuelle Ausführung, Ereignis, geplanter Zeitpunkt usw.}

[Eingabe]
- Datenquelle: {Datei/API/Datenbank}
- Pflichtfelder: {Feldliste}
- Authentifizierungsmethode: {Umgebungsvariable oder Methode zur Geheimnisverwaltung}

[Verarbeitungslogik]
1. {Schritt 1}
2. {Schritt 2}
3. {Schritt 3}

[Ausgabevertrag]
{Dateiformat, Schema, Vorlage sowie Sortier- und Auslassungsregeln}

[Ausnahmebehandlung]
{Leere Ergebnisse, Timeout, Authentifizierungsfehler, Richtlinie bei Teilausfällen}

[Einschränkungen und Nicht-Ziele]
- Beizubehaltende Technologien: {Elemente}
- Verbote: {Elemente}
- Von dieser Aufgabe ausgeschlossene Funktionen: {Elemente}

[Validierung]
- Zu bestehende Tests: {Elemente}
- Inhalte des Abschlussberichts: geänderte Dateien, Ausführungsbefehle, Testergebnisse, verbleibende Risiken

Untersuche zuerst das Repository und lege einen Implementierungsplan vor.
Errate unbekannte Informationen nicht, sondern stelle Fragen.
```

### Vorlage zum Hinzufügen einer bestehenden Funktion

```text
Füge dem bestehenden {Name des Agenten oder Moduls} die {neue Funktion} hinzu.
Die neue Funktion muss nach {bestehender Schritt A} und vor {bestehender Schritt B} ausgeführt werden.

Detaillierte Logik:
- {Bedingungen und Verarbeitungsregeln}
- {Ein- und Ausgabeformat}
- {Verhalten bei einem Fehler}

Beizubehaltende Bedingungen:
- Bestehende öffentliche Schnittstellen und Konfigurationsformate nicht ändern.
- Alle bestehenden Tests beibehalten.
- Keine nicht relevanten Dateien ändern.

Erläutere zuerst den Wirkungsbereich und die Regressionsrisiken.
Füge anschließend Tests hinzu, die das bestehende Verhalten bewahren, und implementiere die Funktion.
```

### Vorlage zur Fehlerbehebung

```text
Reproduziere den folgenden Fehler und behebe seine Grundursache.

Vollständige Fehlermeldung:
{Fehlermeldung und Stacktrace nach Entfernung geheimer und personenbezogener Informationen}

Auftretensbedingungen:
- Ausführungsbefehl: {Befehl}
- Eingabe: {Minimale Eingabe zur Reproduktion}
- Umgebung: {Betriebssystem, Laufzeit, relevante Versionen}
- Zeitpunkt des Auftretens: {In welcher Phase}

Erwartetes Verhalten:
{Ergebnis, das bei normalem Verhalten erscheinen sollte}

Tatsächliches Verhalten:
{Aktuell beobachtetes Ergebnis}

Anfrage:
1. Reproduziere zuerst den Fehler.
2. Erkläre die Ursache anhand von Belegen.
3. Behebe ihn mit dem kleinstmöglichen Änderungsumfang.
4. Füge einen Regressionstest hinzu, der denselben Fehler verhindert.
5. Berichte über die ausgeführten Tests und verbleibenden Risiken.
```

Beim Einfügen von Fehlermeldungen müssen sensible Informationen wie API-Schlüssel, Sitzungstoken, Kundendaten und interne Adressen entfernt werden.

## Vollständiges Beispiel: Anfrage für einen Nachrichten-Briefing-Agenten

Das folgende Beispiel kombiniert die sechs Prinzipien in einer einzigen Anfrage.

```text
Ich bin für die Geschäftsentwicklung eines SaaS-Start-ups verantwortlich.
Ich möchte täglich nur Nachrichten über Veränderungen in den Märkten für AI,
Cloud und Fintech prüfen, die innerhalb von 3 Monaten Produkt- oder
Partnerschaftsentscheidungen verändern können.

Untersuche das aktuelle Repository und entwirf ein Werkzeug für Nachrichten-Briefings.
Implementiere in der ersten Phase nur die Funktion, die Beispiel-JSON einliest,
Duplikate entfernt, die Auswirkungen klassifiziert und anschließend eine HTML-Vorschaudatei erstellt.
Websuche, tatsächlicher E-Mail-Versand und geplante Ausführung sind von dieser Phase ausgeschlossen.

Eingabefelder:
- title, url, source, published_at, body

Verarbeitungsregeln:
- Identische normalisierte URLs gelten als Duplikate.
- Auch bei unterschiedlichen URLs werden Artikel mit ähnlichen Titeln als Duplikatkandidaten markiert.
- Nur Artikel, die innerhalb von 3 Monaten konkrete Änderungen bei Preisen,
  regulatorischen Maßnahmen, der Produkt-Roadmap oder Partnerschaftsentscheidungen
  erforderlich machen, werden mit der Auswirkung 'hoch' klassifiziert.
- Bei unzureichenden Belegen keine hohe Stufe vermuten.

Ausgabe:
- Titel, Zusammenfassung in 1–2 Sätzen, Auswirkung, Bewertungsbegründung, Quelle und URL anzeigen.
- Absteigend nach Auswirkung sortieren.
- Gesamtzahl, Anzahl entfernter Duplikate und Anzahl je Stufe am Ende anzeigen.

Ausnahmebehandlung:
- Einträge ohne Pflichtfelder nicht ausschließen, sondern in einer separaten Fehlerliste erfassen.
- Fehlerhafte Datumsangaben nicht schätzen, sondern als null beibehalten.
- Weder vollständige Artikeltexte noch Authentifizierungsdaten in Logs speichern.

Validierung:
- Normale Eingabe, leere Eingabe, doppelte URL, fehlerhaftes Datum und fehlende Pflichtfelder testen.
- Falls bestehende Tests vorhanden sind, müssen alle bestanden werden.

Arbeitsreihenfolge:
1. Repository-Struktur und relevante Dateien untersuchen.
2. Zu ändernde Dateien und Testplan vorlegen.
3. Den Code nicht ändern, bevor ich den Plan geprüft habe.
4. Nach der Genehmigung die minimale Funktion implementieren und über die Testergebnisse berichten.
```

Diese Anfrage verlangt nicht, alle erforderlichen Funktionen gleichzeitig in der Produktionsumgebung bereitzustellen. Der Umfang ist begrenzt, und Ausgabebedeutung, Fehlerbehandlung sowie Testfälle sind gemeinsam definiert, sodass sich das Ergebnis leicht beurteilen lässt.

## Qualitätskriterien, die bei ausschließlicher Konzentration auf Prompts leicht übersehen werden

Viele Anleitungen zum Vibe Coding konzentrieren sich darauf, detailliertere Anweisungen zu schreiben. Weitere Faktoren, die jedoch die tatsächliche Qualität bestimmen, sind **Validierbarkeit, Änderungskontrolle, Beobachtbarkeit und Sicherheitsgrenzen**.

### 1. Abnahmekriterien in Tests umwandeln

Statt `Sorge dafür, dass es gut funktioniert` werden Eingaben mit den erwarteten Ausgaben als Paare bereitgestellt. Wichtige Klassifizierungsbeispiele werden als Regressionstests festgehalten, um zu prüfen, ob die Ergebnisse auch bei späteren Änderungen erhalten bleiben.

### 2. Die Selbsteinschätzung des Agenten nicht als endgültigen Beleg verwenden

Dass ein Agent erklärt, er sei `fertig`, ist nicht dasselbe wie bestandene Tests. Er sollte über ausgeführte Befehle, Testergebnisse, geänderte Dateien und ungelöste Risiken berichten, und ein Mensch muss den diff prüfen.

### 3. Berechtigungen und geheime Informationen minimieren

Nicht benötigte Verzeichnisse, Produktionsdatenbanken und Bereitstellungszugangsdaten werden nicht gemeinsam zur Verfügung gestellt. API-Schlüssel werden weder direkt in Prompts noch in Repositorys eingetragen. Stattdessen werden Umgebungsvariablen oder genehmigte Systeme zur Geheimnisverwaltung verwendet. MCP-Servern oder Skripten unbekannter Herkunft wird kein Zugriff auf sensible Repositorys gewährt.

### 4. Beobachtbaren Code verlangen

Bei automatisierten Aufgaben werden Informationen hinterlassen, die zur Ermittlung von Fehlerursachen erforderlich sind, etwa Status je Phase, strukturierte Fehler, Ausführungszeiten und die Anzahl verarbeiteter Datensätze. Authentifizierungsdaten und personenbezogene Informationen werden dagegen aus Logs entfernt.

### 5. Änderungen reversibel gestalten

Nicht relevante Refactorings und Funktionserweiterungen werden nicht in derselben Änderung vermischt. Werden diffs in kleinen Einheiten geprüft und in der Versionsverwaltung erfasst, lassen sich fehlerhafte Änderungen leichter isolieren und rückgängig machen.

## Tipps für den Betrieb von Claude Code-Projekten

- Wiederkehrende Projektregeln kurz und konkret in `CLAUDE.md` festhalten.
- Build-, Test- und Lint-Befehle in tatsächlich ausführbarer Form angeben.
- Keine geheimen Informationen, einmaligen Fehler-Logs oder langen Referenzdokumente in `CLAUDE.md` aufnehmen.
- Vor umfangreichen Änderungen zuerst relevante Dateien und Abhängigkeiten untersuchen lassen.
- Beim Hinzufügen neuer Pakete Notwendigkeit, Lizenz und Wartungsrisiken prüfen.
- Gefährliche Befehle zum Löschen, Bereitstellen oder Ändern von Daten nicht automatisch genehmigen.
- Vor der Anbindung externer APIs oder von MCP prüfen, wohin Daten übertragen werden.
- Nach Abschluss geänderte Dateien, Ausführungsbefehle, Testergebnisse und verbleibende Einschränkungen zusammenfassen lassen.

## Checkliste vor der Einreichung

- [ ] Sind Benutzer und Nutzungssituation beschrieben?
- [ ] Sind Ziele und Nicht-Ziele voneinander getrennt?
- [ ] Sind bestehende Technologien und Bereiche, die nicht geändert werden dürfen, angegeben?
- [ ] Sind Eingabedaten und Ausgabeformat definiert?
- [ ] Ist die Bedeutung von Klassifizierungs- und Statuswerten erläutert?
- [ ] Gibt es Richtlinien für leere Ergebnisse, Authentifizierungsfehler, Timeouts und Teilausfälle?
- [ ] Sind Planung und Implementierung phasenweise voneinander getrennt?
- [ ] Gibt es Tests für Normal-, Grenz- und Fehlerfälle?
- [ ] Sind geheime und personenbezogene Informationen aus Prompts und Logs ausgeschlossen?
- [ ] Wurden ein von Menschen zu prüfender diff und Ausführungsbelege angefordert?

Der Kern eines guten Claude Code-Prompts besteht nicht darin, lange Anweisungen zu schreiben. Es geht darum, die Punkte zu reduzieren, die der Agent erraten muss, und das Ergebnis so zu gestalten, dass auch Dritte reproduzierbar feststellen können, ob es korrekt ist.

## FAQ

### Sind längere Claude Code-Prompts besser?
Wichtiger als die Länge ist, ob die für die Aufgabe erforderlichen Informationen strukturiert enthalten sind. Hintergrund, Ziel, Einschränkungen, Ausgabevorgaben, Fehlerbehandlung und Abschlusskriterien sollten konkret formuliert werden; irrelevante Erläuterungen und redundante Anweisungen sollten hingegen entfernt werden.

### Kann ich nicht von Anfang an darum bitten, das gesamte Programm zu erstellen?
Bei einem kleinen, eigenständigen Tool ist das möglich, aber bei Aufgaben, die eine externe API, eine Datenbank, E-Mail und eine zeitgesteuerte Ausführung umfassen, ist eine schrittweise Entwicklung sicherer. Wenn zunächst das Repository untersucht und der Plan geprüft wird und die Anwendung anschließend in der Reihenfolge Mindestfunktionalität, Tests und externe Anbindungen erweitert wird, lassen sich Fehlerursachen leichter isolieren.

### Kann ich Tests auslassen, wenn ich den Plan Mode verwende?
Nein. Der Planungsmodus ist nützlich, um vor Änderungen die Struktur und den Ansatz zu prüfen, belegt jedoch nicht die Korrektheit des tatsächlichen Codes. Nach der Implementierung müssen automatisierte Tests, statische Analysen, eine Prüfung der Änderungen und erforderliche manuelle Kontrollen separat durchgeführt werden.

### Was sollte in CLAUDE.md stehen?
Darin sollten Anweisungen festgehalten werden, die bei verschiedenen Aufgaben wiederholt gelten, etwa die Projektstruktur, Programmierrichtlinien, Build- und Testbefehle sowie Bereiche, die nicht geändert werden dürfen. API-Schlüssel, Passwörter, personenbezogene Daten, Beschreibungen einmaliger Aufgaben und übermäßig umfangreiche Referenzmaterialien sollten nicht aufgenommen werden.

### Welche Informationen sollte ich bei einer Anfrage zur Fehlerbehebung bereitstellen?
Bereitgestellt werden sollten die um sensible Informationen bereinigte Fehlermeldung und Stacktrace, der Ausführungsbefehl, eine minimale Eingabe zur Reproduktion, die relevante Umgebung sowie das tatsächliche und das erwartete Verhalten. Es empfiehlt sich außerdem, eine Erklärung der Ursache, eine Änderung im kleinstmöglichen Umfang, Regressionstests und die Ausführungsergebnisse anzufordern.

### Kann ich Claude Code einen API-Schlüssel über den Prompt übermitteln?
Grundsätzlich sollten echte API-Schlüssel weder direkt im Prompt noch im Quellcode eingetragen werden. Verwenden Sie freigegebene Umgebungsvariablen oder ein System zur Verwaltung von Geheimnissen und stellen Sie sicher, dass auch in Protokollen und Testergebnissen keine Authentifizierungsdaten offengelegt werden.

### Müssen im Prompt unbedingt die Anzahl der Wiederholungsversuche und die Wartezeit angegeben werden?
Bei der Betriebsautomatisierung ist es wichtig, zwischen Fehlern, bei denen ein erneuter Versuch möglich ist, und Fehlern, bei denen sofort abgebrochen werden muss, zu unterscheiden. Die konkrete Anzahl der Versuche und die Wartezeit sollten jedoch anhand der Beschränkungen des externen Dienstes, der Dringlichkeit der Aufgabe und des Risikos einer doppelten Verarbeitung festgelegt werden; nicht jeder Fehler darf bedingungslos erneut versucht werden.

### Wie kann ich feststellen, ob der generierte Code fertiggestellt ist?
Dies wird anhand der zuvor festgelegten Abnahmekriterien beurteilt. Es muss geprüft werden, ob die Tests für die erforderlichen Funktionen und Ausnahmefälle bestanden wurden, welche Befehle ausgeführt und welche Dateien geändert wurden und ob die Leistungs- oder Sicherheitsanforderungen erfüllt sind. Zudem müssen die Codeänderungen von einem Menschen geprüft werden.

## Sources

- [Claude Code – Überblick](https://docs.anthropic.com/en/docs/claude-code/overview)
- [Claude Code: Best Practices für agentenbasiertes Programmieren](https://www.anthropic.com/engineering/claude-code-best-practices)
- [GitHub-Repository von Anthropic Claude Code](https://github.com/anthropics/claude-code)

## Images

![Entwickler vor einem großen Monitor mit Code und einem Ablaufdiagramm](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNTQsInB1ciI6ImJsb2JfaWQifX0=--9f2d2e2c8a61fc294a6019e4807ece297f36e85a/ai-4caeb237.webp)
![Laptop mit Code-Editor, verbunden mit Anforderungen, Tabellen, Fehlern, Versionskontrolle und Leistungsdiagrammen](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTExNjAsInB1ciI6ImJsb2JfaWQifX0=--285d7ecdc8209e07e0fc4eb68085cd8a304b9a81/ai-062b34c5.webp)