Few-Shot-Prompting in der Praxis

1. Was Few-Shot-Prompting eigentlich bewirkt

Few-Shot-Prompting bedeutet, einem Sprachmodell nicht nur eine Aufgabenbeschreibung zu geben, sondern zusätzlich einige wenige konkrete Beispiele dafür, wie eine Eingabe in die gewünschte Ausgabe überführt werden soll. Das Modell erkennt das Muster aus den Beispielen im Kontext und wendet es auf neue, ähnliche Eingaben an, ein Effekt, der in der Forschung als In-Context Learning bezeichnet wird. Anders als beim Fine-Tuning verändert sich dabei kein einziges Modellgewicht, das Muster wirkt ausschließlich innerhalb des aktuellen Kontextfensters.

Für Entwickler ist das relevant, weil viele Aufgaben im Alltag genau diese Struktur haben: Ein Rohtext soll in ein bestimmtes Format überführt werden, eine Funktion soll nach einem festen Schema dokumentiert werden, ein Diff soll in eine Commit-Nachricht mit fester Struktur münden. Solche Aufgaben lassen sich zwar auch mit einer reinen Anweisung beschreiben, aber die Beschreibung müsste jede Formatregel, jede Ausnahme und jede stilistische Feinheit explizit benennen. Few-Shot-Prompting verlagert diese Arbeit vom Formulieren einer vollständigen Spezifikation hin zum Kuratieren weniger, aber aussagekräftiger Beispiele.

2. Zero-Shot, One-Shot und Few-Shot im Vergleich

Beim Zero-Shot-Prompting erhält das Modell nur die Aufgabenbeschreibung, keine Beispiele. Das funktioniert gut bei Aufgaben, die Claude aus dem Training bereits gut kennt, etwa allgemeine Zusammenfassungen oder Standardübersetzungen. Bei projektspezifischen Formaten, ungewöhnlichen Konventionen oder mehrdeutigen Stilfragen liefert Zero-Shot dagegen oft brauchbare, aber inkonsistente Ergebnisse, weil das Modell die fehlenden Details selbst interpretieren muss und diese Interpretation von Anfrage zu Anfrage leicht variieren kann.

One-Shot-Prompting mit genau einem Beispiel reduziert diese Varianz bereits deutlich, weil ein konkretes Muster als Anker dient. Das Risiko dabei: Das Modell kann Eigenschaften des einzelnen Beispiels übergeneralisieren, etwa eine zufällige Variablennamens-Konvention als verbindliche Regel interpretieren. Few-Shot-Prompting mit typischerweise drei bis acht Beispielen schafft hier Balance, genug Beispiele, um das eigentliche Muster von zufälligen Details zu trennen, aber noch wenig genug, um den Kontext nicht unnötig aufzublähen und die Antwortzeit spürbar zu verlängern.

3. Warum Beispiele zuverlässiger steuern als Anweisungen

Natürlichsprachliche Anweisungen wie schreibe prägnanten, idiomatischen Code sind semantisch unterspezifiziert. Was als prägnant gilt, hängt vom Kontext, der Sprache und den Konventionen eines Teams ab, und das Modell muss diese Lücke mit eigenen, oft plausiblen, aber nicht immer passenden Annahmen füllen. Ein konkretes Beispiel dagegen zeigt das gewünschte Ergebnis unmittelbar, ohne dass eine abstrakte Regel erst in eine konkrete Form übersetzt werden muss. Das Modell muss nicht mehr interpretieren, sondern kann interpolieren, also ein neues Ergebnis finden, das strukturell zwischen den gezeigten Beispielen liegt.

Ein zweiter Effekt betrifft die Konsistenz über mehrere Anfragen hinweg. Weil Sprachmodelle bei gleicher Eingabe nicht deterministisch antworten, streuen rein anweisungsbasierte Ergebnisse stärker als beispielbasierte, insbesondere bei Formatfragen wie Einrückung, Reihenfolge von Parametern oder Struktur von Docblocks. Beispiele wirken wie Leitplanken, die den Lösungsraum des Modells gezielt einengen. In der Praxis zeigt sich das deutlich: Ein Team, das Claude nur anweist, Commits im Conventional-Commits-Format zu schreiben, bekommt tendenziell mehr Format-Abweichungen als ein Team, das zusätzlich drei reale Beispiel-Commits aus dem eigenen Repository mitgibt.

4. Praxisbeispiel: konsistenten Code-Stil per Beispiel lehren

Ein typisches Szenario aus der Magento-Entwicklung: Jede neue Methode soll einen vollständigen PHPDoc-Block mit Beschreibung, @param für jeden Parameter und @return erhalten, wie es die Projektkonventionen vorschreiben. Eine reine Anweisung dazu funktioniert meistens, aber Detailfragen wie die genaue Formulierung der Beschreibung, der Umgang mit optionalen Parametern oder die Reihenfolge von @param und @throws bleiben uneinheitlich, wenn sie nicht explizit vorgegeben werden.

Mit zwei bis drei Beispiel-Paaren aus echtem Projektcode lässt sich dieses Muster wesentlich zuverlässiger festlegen. Wichtig ist dabei, dass die Beispiele nicht nur den Standardfall zeigen, sondern auch mindestens eine Methode mit optionalem Parameter und eine mit Rückgabetyp void, damit das Modell nicht fälschlich annimmt, jede Methode habe genau einen Pflichtparameter und einen Rückgabewert. Das folgende JSON zeigt ein Few-Shot-Set, wie es sich in einem Prompt-Template oder einer CLAUDE.md-Datei hinterlegen lässt.

{
  "task": "Add a complete PHPDoc block above each public method",
  "examples": [
    {
      "input": "public function getPriceForCustomer(int $productId, int $customerGroupId): float\n{\n    return $this->priceResolver->resolve($productId, $customerGroupId);\n}",
      "output": "/**\n * Resolves the effective price for a product within a customer group.\n *\n * @param int $productId Product entity id.\n * @param int $customerGroupId Customer group id used for tier pricing.\n * @return float Resolved price including applicable customer group rules.\n */\npublic function getPriceForCustomer(int $productId, int $customerGroupId): float\n{\n    return $this->priceResolver->resolve($productId, $customerGroupId);\n}"
    },
    {
      "input": "public function logDeprecationWarning(string $message, ?string $context = null): void\n{\n    $this->logger->warning($message, ['context' => $context]);\n}",
      "output": "/**\n * Logs a deprecation warning with optional context.\n *\n * @param string $message Human readable deprecation message.\n * @param string|null $context Optional context information, null if not applicable.\n * @return void\n */\npublic function logDeprecationWarning(string $message, ?string $context = null): void\n{\n    $this->logger->warning($message, ['context' => $context]);\n}"
    }
  ]
}

5. Praxisbeispiel: Commit-Message-Format durchsetzen

Ein zweites, sehr alltägliches Beispiel ist die automatische Formulierung von Commit-Nachrichten aus einem git diff. Eine Anweisung wie nutze Conventional Commits mit Typ und Scope beschreibt zwar das Format, aber nicht, wie granular ein Team seine Scopes benennt, wie lang die Zusammenfassungszeile üblicherweise ist oder ob ein Body-Absatz erwartet wird. Diese Details unterscheiden sich von Projekt zu Projekt und lassen sich kaum vollständig in Textregeln fassen, ohne den Prompt unübersichtlich zu machen.

Effektiver ist es, drei bis vier echte, gut formulierte Commits aus der eigenen Git-Historie als Beispiele mitzugeben, ausgewählt so, dass sie unterschiedliche Änderungstypen abdecken: ein Feature, ein Bugfix und ein reines Refactoring. Das folgende Skript extrahiert solche Beispiel-Commits automatisiert aus der Historie und bereitet sie für einen Few-Shot-Prompt auf.

#!/usr/bin/env bash
# collect-commit-examples.sh - extract well-formed commits as few-shot examples
set -euo pipefail

readonly REPO_DIR="${1:-.}"
readonly EXAMPLE_COUNT=4

cd "$REPO_DIR"

# Pick recent commits that already follow the conventional commit pattern
git log --pretty=format:"%H" -n 200 \
  | while read -r hash; do
      subject="$(git log -1 --pretty=%s "$hash")"
      if [[ "$subject" =~ ^(feat|fix|refactor|docs|test)(\([a-z0-9_-]+\))?:\ .+ ]]; then
        echo "$hash"
      fi
    done \
  | head -n "$EXAMPLE_COUNT" \
  | while read -r hash; do
      echo "=== Example commit $hash ==="
      git show --stat --format="%s%n%n%b" "$hash" | head -n 20
      echo
    done

Diese Beispiele wandern anschließend als Few-Shot-Block in den Prompt, gefolgt vom aktuellen git diff --staged. In der Praxis reduziert das die Zahl der Nacharbeiten spürbar, weil Claude nicht mehr erraten muss, wie lang eine Zusammenfassungszeile im konkreten Projekt sein darf oder ob Scopes wie checkout oder catalog gebräuchlich sind, sondern es direkt aus den Beispielen ableitet.

6. Repräsentative Beispiele wählen und Edge Cases abdecken

Die Qualität eines Few-Shot-Prompts hängt fast ausschließlich von der Auswahl der Beispiele ab, nicht von deren Anzahl. Drei sorgfältig gewählte Beispiele, die unterschiedliche Aspekte einer Aufgabe zeigen, übertreffen zehn nahezu identische Beispiele, die alle denselben Fall abdecken. Eine bewährte Faustregel: mindestens ein Beispiel für den Standardfall, mindestens ein Beispiel für einen Grenzfall wie eine leere Eingabe, einen optionalen Parameter oder eine Ausnahme, und wenn möglich ein Beispiel, das zeigt, was das Modell explizit nicht tun soll.

Ein häufiger Fehler ist, dass alle Beispiele zufällig aus denselben Codeteilen stammen und dadurch oberflächliche Gemeinsamkeiten aufweisen, etwa immer dieselben Variablennamen oder immer eine Rückgabe vom Typ array. Das Modell kann solche Zufälligkeiten fälschlich als Teil des eigentlichen Musters interpretieren, ein Effekt, der dem Overfitting beim klassischen maschinellen Lernen ähnelt. Auch die Reihenfolge der Beispiele spielt eine Rolle, da Modelle tendenziell dem zuletzt gezeigten Beispiel etwas mehr Gewicht geben. Wer ein Beispiel besonders betonen möchte, platziert es daher bewusst am Ende der Liste, kurz vor der eigentlichen Anfrage.

# build_fewshot_prompt.py - select diverse examples covering edge cases
from dataclasses import dataclass


@dataclass
class Example:
    label: str
    input_text: str
    output_text: str


def select_representative_examples(pool: list[Example], max_examples: int = 5) -> list[Example]:
    """Pick a diverse subset: standard case, edge cases, and a negative example."""
    required_labels = ["standard", "empty_input", "optional_param", "exception_path"]
    selected: list[Example] = []

    for label in required_labels:
        match = next((ex for ex in pool if ex.label == label), None)
        if match:
            selected.append(match)

    # Fill remaining slots with additional diverse examples, avoiding near-duplicates
    for ex in pool:
        if len(selected) >= max_examples:
            break
        if ex not in selected:
            selected.append(ex)

    return selected[:max_examples]


def render_prompt(task: str, examples: list[Example], new_input: str) -> str:
    blocks = "\n\n".join(
        f"Input:\n{ex.input_text}\n\nOutput:\n{ex.output_text}" for ex in examples
    )
    return f"Task: {task}\n\n{blocks}\n\nInput:\n{new_input}\n\nOutput:"

7. Few-Shot in Claude Code und der Anthropic API einsetzen

In Claude Code lassen sich Few-Shot-Beispiele auf zwei Wegen dauerhaft verankern: entweder direkt in der CLAUDE.md-Datei des Projekts, mit einem kurzen Abschnitt, der zwei oder drei Vorher-Nachher-Beispiele für Code-Stil oder Commit-Format enthält, oder als eigene Slash-Command-Vorlage, die bei jedem Aufruf die passenden Beispiele einbindet. Der Vorteil gegenüber einer reinen Textanweisung in CLAUDE.md: Die Beispiele bleiben stabil und reproduzierbar über verschiedene Sitzungen hinweg, während eine abstrakte Regel bei jeder neuen Konversation leicht neu interpretiert werden kann. Ein solcher Abschnitt für Commit-Messages könnte in der CLAUDE.md-Datei so aussehen:

## Commit-Message-Format (Few-Shot-Beispiele)

Beispiel 1:
Eingabe: git diff mit neuer Zahlungsmethode
Ausgabe: feat(checkout): add PayPal Express as payment method

Beispiel 2:
Eingabe: git diff mit Bugfix an der Preisberechnung
Ausgabe: fix(catalog): correct tier price rounding for decimal quantities

Beispiel 3:
Eingabe: git diff mit Refactoring ohne Verhaltensänderung
Ausgabe: refactor(customer): extract address validation into service class

Bei direkter Nutzung der Anthropic API werden Few-Shot-Beispiele meist als abwechselnde user- und assistant-Nachrichten im messages-Array übergeben, gefolgt von der eigentlichen neuen Anfrage als letzter user-Eintrag. Diese Struktur nutzt das Modell effizienter als Beispiele, die als reiner Text in einer einzigen Nachricht zusammengefasst sind, weil sie dem tatsächlichen Konversationsformat entspricht, mit dem das Modell trainiert wurde.

// build-fewshot-messages.js - construct a few-shot message array for the API
const client = require("@anthropic-ai/sdk");

function buildFewShotMessages(examples, newDiff) {
  const messages = [];

  for (const example of examples) {
    messages.push({ role: "user", content: `Diff:\n${example.diff}\n\nWrite a commit message.` });
    messages.push({ role: "assistant", content: example.commitMessage });
  }

  messages.push({ role: "user", content: `Diff:\n${newDiff}\n\nWrite a commit message.` });
  return messages;
}

async function generateCommitMessage(anthropic, examples, newDiff) {
  const response = await anthropic.messages.create({
    model: "claude-sonnet-4-5",
    max_tokens: 200,
    messages: buildFewShotMessages(examples, newDiff),
  });

  return response.content[0].text;
}

module.exports = { buildFewShotMessages, generateCommitMessage };

8. Grenzen und Risiken von Few-Shot-Prompting

Few-Shot-Prompting ist kein kostenloser Mechanismus. Jedes Beispiel verbraucht Tokens im Kontextfenster, was sich bei häufig wiederholten Anfragen in messbaren zusätzlichen API-Kosten und leicht erhöhter Latenz niederschlägt. Bei sehr langen Beispielen, etwa vollständigen Dateien statt kurzer Ausschnitte, kann der Overhead den Nutzen übersteigen, besonders wenn ohnehin schon viel Projektkontext im Prompt enthalten ist. Eine sinnvolle Praxis ist, Beispiele so kurz wie möglich, aber so vollständig wie nötig zu halten.

Ein zweites Risiko betrifft die Qualität der Quelle: Wenn Beispiele aus echtem, aber fehlerhaftem oder inkonsistentem Bestandscode stammen, lernt das Modell diese Fehler mit. Beispiele sollten deshalb kuratiert und nicht blind aus dem Repository entnommen werden. Drittens können Beispiele aus sensiblem Code versehentlich interne Details, Kundennamen oder Zugangsdaten in den Prompt und damit potenziell in Logs oder Trainingsdaten des Anbieters übertragen, weshalb Beispiele vor dem Einsatz auf sensible Inhalte geprüft werden sollten. Und schließlich gilt: Few-Shot verbessert Konsistenz und Format, aber es ersetzt kein Code-Review, denn ein formal korrektes, aber logisch falsches Ergebnis sieht durch gute Beispiele oft überzeugender aus, nicht weniger fehlerhaft.

9. Few-Shot-Prompting im direkten Vergleich

Die folgende Übersicht fasst zusammen, an welchen Stellen reine Anweisungen an ihre Grenzen stoßen und wie ein sauber aufgebautes Few-Shot-Pattern die jeweilige Schwäche gezielt behebt.

In der Praxis lassen sich die beiden Spalten selten strikt trennen: Ein kurzer erklärender Satz vor den Beispielen hilft dem Modell, das übergeordnete Ziel zu verstehen, während die Beispiele die konkrete Umsetzung festlegen. Wer beides kombiniert, statt sich für eine Seite zu entscheiden, erhält in der Regel die zuverlässigsten Ergebnisse bei vertretbarem Token-Aufwand.

10. Zusammenfassung

Few-Shot-Prompting löst ein Grundproblem des reinen Anweisungsprompts: Natürliche Sprache lässt zu viel Interpretationsspielraum für Formatfragen, Stilentscheidungen und Detailregeln. Zwei bis acht konkrete Beispiel-Paare aus Eingabe und gewünschter Ausgabe legen dieses Muster deutlich präziser fest, weil das Modell interpolieren statt interpretieren kann. Bei Code-Stil-Vorgaben wie vollständigen PHPDoc-Blöcken und bei Commit-Message-Formaten zeigt sich der Effekt besonders deutlich, weil beide Aufgaben stark formatgetrieben sind und sich schlecht vollständig in Textregeln fassen lassen.

Entscheidend für die Qualität ist nicht die Anzahl der Beispiele, sondern ihre Diversität: mindestens ein Standardfall, mindestens ein Edge Case, und wo sinnvoll ein Negativbeispiel. Wer diese Auswahl bewusst trifft und die Beispiele dauerhaft in CLAUDE.md-Dateien oder Prompt-Vorlagen hinterlegt, bekommt spürbar konsistentere Ergebnisse über viele Anfragen hinweg, muss dafür aber zusätzliche Tokens, Pflegeaufwand und das Risiko von Overfitting auf oberflächliche Muster einkalkulieren.

11. FAQ: Few-Shot-Prompting in der Praxis