Anhand eines echten Fallbeispiels mit Claude Code zur automatischen Programmierung teile ich einige Prompt-Techniken

In diesem Artikel teile ich anhand eines echten Fallbeispiels eine praktische Anwendung von Claude Code. Bevor ich beginne, möchte ich eine kleine Umfrage machen.

Ursprüngliche Anforderung: Ein wertvoller zahlender Benutzer wünschte, dass ich in den Artikeln das Änderungsdatum hinzufüge.

Auf den ersten Blick schien diese Anforderung schwierig umzusetzen. Denn die Artikel meiner Website sind nicht in einer Datenbank gespeichert, sondern werden mit SSG von next.js generiert. Sie haben überhaupt kein Aktualisierungsdatum.

Ein Trick hier ist: Beim Lösen von Problemen sollten wir die ursprüngliche Anforderung nicht direkt an Claude Code verfüttern, aus folgenden Gründen:

1. Die ursprüngliche Anforderung ist relativ vage, es könnte zu Missverständnissen kommen. Wenn es einmal falsch verstanden wird, könnte es zwar ein Datum hinzufügen, aber dieses Datum ist möglicherweise nicht zuverlässig.

2. Der Token-Verbrauch von Claude Code ist wirklich sehr teuer. Daher können unklare Anforderungen zu einer sinnlosen Verschwendung vieler Tokens führen.

Daher sollten wir die ursprüngliche Anforderung zunächst aufschlüsseln. Ich habe zuerst deepseek konsultiert, und deepseek gab mir zwei Lösungsansätze:

1. Dateierstellungszeit: Bei jedem Build müssen wir die Erstellungszeit der Datei abrufen. Aber die Build-Strategie von turbopack ist etwas anders, bei jedem Build ändert sich der Hash-Wert der Datei, daher könnte diese Erstellungszeit unzuverlässig sein.

2. Git-Commit-Zeit: Ich dachte, das sollte zuverlässiger sein.

Nachdem ich eine grobe Lösungsrichtung hatte, hatte ich diesen einfachen Prompt: Kompiliere die git-Commit-Zeit in den Kopf jeder .mdx-Artikeldatei.

Claude Code ist ziemlich zuverlässig. Wenn der Prompt präzise ist, gibt es im Allgemeinen keine Probleme, es legt einfach los und führt aus.

Nachdem es 7 Dollar meines Guthabens verbraucht und etwa 20 Minuten gedauert hatte, war die Ausführung endlich erfolgreich.

Und wie zu erwarten, trat ein unerwartetes Problem auf: Es übersprang Änderungen an 171 Dateien.

Ein sehr ärgerlicher Punkt hier ist, dass die übersprungenen Dateien lediglich einen zusätzlichen pass-Parameter übergeben bekamen, ansonsten waren sie völlig identisch.

<PostLayout pass>...

Aber es war unflexibel und definierte diesen zusätzlich übergebenen Parameter als völlig andere benutzerdefinierte Komponente. Dann übersprang es die Bearbeitung ~ ~

import Layout from 'components/post-layout';
import { getGitFileInfo } from '@/utils/git-info';
export default function Article({ children }: any) {
  const gitInfo = getGitFileInfo('src/app/IhrPfad/page.mdx');
  return (
    
      {children}
    
  );
}

Aber in Wirklichkeit brauchte ich dieses Ergebnis, und das Ausführungsergebnis war völlig identisch.

import MdxLayout from 'components/mdx-layout';
export default function Article({ children }: any) {
  return (
    
      {children}
    
  );
}

Und dann stolperte ich über einen Fehler im Prompt.

Ich gab erneut den Prompt ein: Refaktorisiere die übersprungenen 171 Dateien auf die gleiche Weise wie oben.

Meine Formulierung hatte, bei genauerem Nachdenken, eine gewisse Mehrdeutigkeit. Denn Claude Code hatte mir bereits einen vorgeschlagenen Lösungsansatz gegeben, den ich aber nicht akzeptierte. Meine Absicht war, die übersprungenen Dateien mit dem gleichen Schema zu ändern wie die bereits geänderten Hunderte von Dateien. Aber während der Ausführung verstand es es als: den oben von ihm vorgeschlagenen Lösungsansatz.

Diese Mehrdeutigkeit führte direkt dazu, dass es 20 Minuten lang nach dem unerwünschten Schema ausführte, wobei es zweimal Fehler selbst korrigierte und heftig meine Tokens verschlang. Die beiden unterschiedlichen Interpretationen begannen zu kollidieren und verursachten Fehler.

Schließlich musste ich diese Ausführung abbrechen und meine Bedeutung neu klarstellen.

Zusammenfassung

1. Prompts sollten möglichst stabile und genaue Lösungsansätze enthalten. Je weniger die KI nachdenken muss, desto geringer ist die Halluzinationsrate.

2. Prompts für Anforderungen dürfen keine Mehrdeutigkeiten enthalten. Mehrdeutigkeiten führen leicht zu Fehlern. Obwohl Claude Code diese letztendlich reparieren kann, verursacht dies einen hohen Token-Verbrauch. Da LLMs auf Vorhersagemechanismen basieren, führen frühes Missverstehen oder Mehrdeutigkeiten dazu, dass jeder weitere Schritt in die falsche Richtung geht. Es versucht auch, logisch konsistent zu bleiben, und erzeugt Dinge, die nicht existieren. Je mehr es schreibt, desto größer werden die Probleme, und es erhöht die Überprüfungsschwierigkeit für Entwickler. Wenn man von seiner Halluzination getäuscht wird, kann das schwerwiegende Folgen haben.

3. Natürliche Sprache ist weniger präzise als Code. Das Einbeziehen von Dateinamen, Code-Variablen, Code-spezifischen Begriffen und Fachtermini in Prompts reduziert die Halluzinationen von Claude Code erheblich.