Claude Code nur eine Datei ändern lassen: der sichere Prompt

„Mach die Einleitung von diesem Blogartikel bitte noch ein bisschen besser.”

Das tippte ich an einem Freitagabend um 22 Uhr ein. Ändern sollte sich nur ein einziger Block: die ersten drei Absätze in einer Datei. Am nächsten Morgen öffnete ich den Diff und starrte auf zwölf geänderte Dateien. Nicht nur der Artikeltext, sondern auch das gemeinsame Layout, die Tag-Übersicht und, ich weiß bis heute nicht warum, die Datei mit den Veröffentlichungs-Einstellungen. Ob überhaupt noch etwas funktionierte, hatte niemand geprüft. Ich war einfach eingeschlafen.

Es kostete mich 30 Minuten, alles zurückzudrehen. Woran lag es? Nicht daran, dass Claude Code schlecht gearbeitet hätte. Es lag daran, dass mein Auftrag mit keinem Wort gesagt hatte, wie weit das Werkzeug greifen darf. Eine clevere KI hat „Einleitung besser machen” einfach als „und dann gleich die zusammenhängenden Stellen mitaufräumen” verstanden. Hilfsbereit gemeint, fatal in der Wirkung.

In diesem Artikel gebe ich dir genau die Briefing-Vorlage weiter, die ich nach jenem Abend gebaut habe, fertig zum Kopieren: den Umfang eng abstecken, am Ende selbst prüfen lassen und im Fehlerfall sauber zurückrollen. Mehr braucht es nicht, und die nächtlichen Unfälle waren danach so gut wie verschwunden.

Das Wichtigste in Kürze

• Wenn eine an die KI delegierte Aufgabe entgleist, liegt das selten am Modell, sondern daran, dass der erlaubte Umfang nirgends steht.
• In den Brief gehören immer fünf Dinge: „Dateien zum Lesen”, „Dateien zum Ändern”, „Tabu-Bereiche”, „Prüfbefehl” und „Rollback-Weg”.
• Lass vor der Erfolgsmeldung zwingend den Prüfbefehl laufen, sonst wirst du am Ende selbst zum Testteam.
• Fang mit kleinen Aufgaben an, deren Endpunkt klar ist: Blog-Korrekturen, Bugreports sortieren, Produkttexte umformulieren.
• Ein enger Umfang senkt nicht den Wert des Ergebnisses. Im Gegenteil: Leser können es leichter auf ihre eigene Umgebung übertragen.

Warum „mach es besser” zum Unfall führt

Der Auftrag „mach es besser” hat keine Ziellinie.

Eine menschliche Redakteurin fragt an einem hektischen Freitagabend zurück: „Du meinst nur die drei Einleitungsabsätze, oder?” Eine KI dagegen kann ohne Rückfrage losrennen. Und weil sie besonders gut darin ist, mitzudenken, weitet sie den Umfang von selbst aus: „Wenn ich die Einleitung verbessere, sollte ich auch die Tags aufräumen und ein paar passende Links ergänzen, das ist doch hilfreich.” Keinerlei böse Absicht. Genau das macht es so tückisch.

Hier hilft ein simpler Gedanke: Schreib den Endpunkt direkt in die Anweisung. Der Prompt muss kein langer, kunstvoller Text sein, im Gegenteil, kurz ist besser. Stattdessen trennst du von Anfang an klar, welche Dateien angefasst werden dürfen und welche nicht. Allein das stoppt das Ausufern.

Wer tiefer in das Formulieren von Prompts einsteigen will, liest dazu am besten Fortgeschrittenes Prompt-Engineering für Claude Code. Dort wird sichtbar, wie das hier beschriebene „Umfang eingrenzen” mit anderen Techniken zusammenhängt.

Die fünf Punkte, die immer in den Brief gehören

In dem Brief, den ich heute verwende, stehen ausnahmslos diese fünf Punkte. Auch ihre Reihenfolge hat einen Sinn.

Punkt	Inhalt	Was ohne ihn passiert
Dateien zum Lesen	Was zur Lage-Erfassung gelesen werden darf	Liest unbeteiligte Stellen und korrigiert am Ziel vorbei
Dateien zum Ändern	Die 1–2 Dateien, die wirklich geschrieben werden dürfen	Der Zwölf-Dateien-Unfall passiert
Tabu-Bereiche	Konfiguration, generierte Dateien, Geheimnisse, Veröffentlichungs-Einstellungen	Heikle Dateien werden „aufgeräumt”
Prüfbefehl	Der eine Prüfbefehl, der nach der Änderung läuft	„Fertig!” wird gemeldet, obwohl alles kaputt ist
Rollback-Weg	Wie man im Fehlerfall zurückkommt	Die Wiederherstellung kostet 30 Minuten

Der Kniff: Lass dir erst einen „Plan” zurückgeben, bevor überhaupt editiert wird. Nicht sofort losschreiben lassen. Vorher soll die KI sagen: „Welche Dateien sehe ich mir an, welche ändere ich, und was geht kaputt, falls ich danebenliege?” Kommt hier ein Plan zurück, der am Ziel vorbeigeht, kannst du genau an dieser Stelle stoppen. Das ist weit billiger, als es erst nach dem Umschreiben zu merken.

Was die KI übernimmt und was der Mensch entscheidet

Du musst nicht alles an die KI abgeben. Ich ziehe die Linie so.

Was die KI ruhig übernehmen darf

• Dateien lesen, um die Lage zu erfassen
• einen Änderungsplan aufstellen und in Worte fassen
• den eigentlichen Text oder Code schreiben
• den Prüfbefehl laufen lassen und das Ergebnis melden

Was der Mensch in der Hand behält

• welche Dateien überhaupt zum Ziel werden (die Festlegung des Umfangs)
• ob der Knopf für Veröffentlichung oder Produktiv-Deployment gedrückt wird
• die Entscheidung, Konfigurationsdateien oder Geheimnisse anzufassen
• die Entscheidung, eine Veröffentlichung zu stoppen, wenn die Prüfung durchfällt

Gerade wer zum ersten Mal Arbeit an eine KI abgibt, sollte diese Linie kennen. Wie man den delegierten Bereich vom menschlichen Entscheidungsbereich trennt, ist auch in Claude Code für Nicht-Entwickler eine der Grundideen. Solange du noch unsicher bist, reicht die grobe Faustregel: „Lesen und Schreiben macht die KI, Löschen und Veröffentlichen macht der Mensch.”

Die kopierbare Briefing-Vorlage

Füg sie direkt ein und ersetze nur die Dateinamen durch die deiner Umgebung. Ob PowerShell oder Bash, du legst den Text in eine Variable und gibst ihn aus.

brief=$(cat <<'EOF'
Ziel: genau eine sichere Änderung an einer einzigen Stelle.
Datei, die geändert werden darf: site/src/content/blog/example.mdx
Tabu: package-Dateien, generierte Dateien, Geheimnisse, Veröffentlichungs- und Deploy-Einstellungen.

Bevor du mit dem Editieren beginnst, gib Folgendes zurück:
1. Dateien, die du zur Lage-Erfassung ansiehst
2. die eine Datei, die du tatsächlich änderst
3. was kaputtgeht, falls diese Änderung falsch ist
4. den Prüfbefehl, der nach der Änderung läuft

Wenn du fertig editiert hast, gib Folgendes zurück:
- eine Zusammenfassung des Diffs
- das Ergebnis des Prüfbefehls
- den Weg, um die Änderung zurückzudrehen
EOF
)

echo "$brief"

Dieser Text ist nicht spektakulär. Sein Wert liegt darin, dass du die Grenzen festschreibst, bevor die Arbeit beginnt. Pass Dateinamen, Tabu-Bereiche und Prüfbefehl an dein eigenes Repository an und gib das Ganze an Claude Code. Kommt ein guter Plan zurück, lass dir dieselben Vorgaben noch einmal bestätigen, bevor es an die Umsetzung geht.

Wenn du dieselben Vorgaben in deine CLAUDE.md schreibst, wirken sie automatisch, ohne dass du sie jedes Mal einfügen musst. Wie das geht, steht in Best Practices für CLAUDE.md.

Ein kleines Skript, das am Ende prüft

„Fertig!” nicht einfach glauben. Das ist die zweite Säule.

Nach dem Editieren prüfe ich maschinell, ob wirklich nur eine Datei geändert wurde. Das Skript unten zählt die Zahl der nicht committeten Änderungsdateien und bricht ab, sobald es mehr sind als erwartet. Es läuft so, wie es ist, mit deutschen Kommentaren.

#!/usr/bin/env bash
# Pruefen, ob nur eine Datei geaendert wurde. Bei zu vielen abbrechen.
set -e

# Erwartete Anzahl geaenderter Dateien (bei einer Ein-Datei-Edit: 1)
expected=1

# Zahl der nicht committeten, geaenderten Dateien zaehlen
changed=$(git status --porcelain | grep -c .)

echo "Geaenderte Dateien: $changed (erwartet: $expected)"

if [ "$changed" -gt "$expected" ]; then
  echo "Es wurden mehr Dateien geaendert als erwartet. Bitte den Diff pruefen."
  git status --porcelain
  exit 1
fi

echo "Alles im Umfang."

Gibst du dieses Skript im Brief als „Prüfbefehl” an, lässt die KI es selbst laufen und meldet das Ergebnis. Sind zwölf Dateien geändert, erscheint schon zum Meldezeitpunkt rote Schrift. Es stoppt direkt an Ort und Stelle, statt dass ich es erst morgens beim Aufwachen entdecke. Genau das wirkt.

Wer Prüfung und tägliche Abläufe stärker automatisieren will, findet weitere Muster in Produktivitäts-Tipps für Claude Code.

Drei Situationen, in denen das wirkt

In allen drei Fällen ist der Endpunkt klar. Umgekehrt gilt: Bei Aufgaben, deren Endpunkt nicht erkennbar ist, solltest du noch nicht alles an die KI abgeben.

1. Eine Blog-Einleitung umschreiben Schreib gleich am Anfang: geändert wird nur die Einleitung einer einzigen Datei. Leg Zielgruppe und Prüfbefehl dazu. So greift das Werkzeug nicht auf den ganzen Text oder das Layout über. Genau diese eine Zeile hätte meinen Zwölf-Dateien-Unfall verhindert.

2. Einen Bugreport sortieren Zeig nur die Logdatei und eine einzige Vorlage und schreib dazu: „Aufräumen von unbeteiligtem Code ist verboten.” Wird beim Sortieren des Reports nebenbei refaktoriert, wird dein Review schlagartig schwer. Engst du den gezeigten Bereich ein, engst du auch die Ausgabe ein.

3. Texte auf einer Produktseite testen Statt die ganze Seite neu zu bauen, verlangst du nur „eine Variante des Slogans” plus „die Prüfung, wie es danach aussieht”. Weil der Umfang auf eine Variante fixiert ist, fällt auch der A/B-Vergleich leicht.

Häufige Fragen

F: Diesen langen Brief jedes Mal einzufügen, ist doch lästig? Häufig genutzte Vorgaben schreibst du in die CLAUDE.md, dann wirken sie ohne erneutes Einfügen. Einzufügen bleibt nur „der Dateiname, der diesmal angefasst werden darf”.

F: Tötet ein enger Umfang nicht gerade die Stärke der KI? Bei mir war es umgekehrt. Je enger der Umfang, desto entschlossener und tiefer korrigiert die KI. Ein weiter Auftrag lässt sie nur grübeln, wo sie überhaupt anfangen soll.

F: Was gehört als Prüfbefehl hinein? Am Anfang reicht allein die „Prüfung der Anzahl geänderter Dateien”. Mit etwas Übung ergänzt du Schritt für Schritt: ob der Build durchläuft, ob die Tests halten, ob es keine toten Links gibt, je ein Befehl nach dem anderen.

F: Und wenn sich trotzdem unerwartete Dateien ändern? Steht der Rollback-Weg im Brief, drehst du es einfach mit diesem Verfahren zurück. Der Trick: Schreib einen Rückroll-Befehl wie git restore . von Anfang an in die Anweisung.

F: Womit fange ich am besten an? Wähl eine kleine Aufgabe, die du im Fehlerfall zurückdrehen kannst. Das Korrigieren eines Entwurfsartikels oder das Austauschen von Textbausteinen eignet sich gut. Bist du bei den Grundlagen unsicher, schafft der Einsteiger-Leitfaden zu Claude Code erst einmal sicheren Boden.

Was beim Selbsttest herauskam

Nach jenem Zwölf-Dateien-Unfall schreibe ich meine Briefe ausnahmslos mit „Dateien zum Ändern”, „Tabu-Bereichen” und „Prüfbefehl”.

Seit ich das Prüfskript als „Prüfbefehl” angebe, stoppen Fälle mit unerwartet eingemischten Dateien direkt an Ort und Stelle. Tatsächlich wollte die KI letzte Woche, als ich Texte einer Produktseite ändern ließ, sogar an eine gemeinsame Komponente greifen, doch in dem Moment, als die Zahl geänderter Dateien auf 2 stieg, gab das Skript rot aus und stoppte. Morgens aufwachen und beim Blick auf den Diff erblassen, das gibt es nicht mehr.

Noch etwas habe ich bestätigt: Ein enger Umfang senkt die Ausgabequalität nicht. An den Tagen, an denen ich auf „nur die drei Einleitungsabsätze” einschränkte, kamen eher die treffsicheren Korrekturen zurück. Statt einer cleveren KI weit zu vertrauen, eng beauftragen und selbst prüfen lassen. Was nach Umweg aussieht, ist für mich der schnellste Weg, das ist mein heutiges Fazit.

Wenn du im Unternehmen ein System aufbauen willst, bei dem die KI Redaktion oder Betrieb übernimmt, könnt ihr im Training und Einführungsberatung gemeinsam vom konkreten Vorgehen an loslegen. Probier zuerst bei dir selbst einen Brief für nur eine Datei aus.

Zur Einordnung: Die offiziellen Informationen zu dem hier verwendeten Werkzeug findest du in der offiziellen Claude-Code-Dokumentation.