Plan-and-Solve Prompting

1. Konzeptüberblick und systemisches Problem

Wenn ein Entwickler einer KI eine komplexe ingenieurtechnische Aufgabe stellt (z. B. „Migrieren des Authentifizierungsmoduls von JWT auf datenbankbasierte Sessions“), neigt der Agent dazu, impulsiv sofort die erste beliebige Datei zu bearbeiten.

Dieser rein reaktive Ansatz führt zu kritischen Fehlern:

1. Verletzung der Abhängigkeitsreihenfolge: Der Agent ändert UI-Komponenten, bevor das Datenbankschema aktualisiert oder die erforderlichen TypeScript-Typen erstellt wurden.
2. Zirkuläre Änderungen: Das Modell behebt einen Fehler, bricht dabei aber eine andere verknüpfte Datei und verfängt sich in einem endlosen Patching-Syntax ohne Verständnis für das Gesamtbild.
3. Verlust des ursprünglichen Ziels: Nach 10 Schritten der Fehlersuche wird der Kontext mit Compiler-Meldungen überflutet, und das Modell vergisst die ursprüngliche Benutzeraufgabe.

Plan-and-Solve löst dieses Problem durch ein klassisches Ingenieursprinzip: Die Trennung von strategischem Design (Planning) und taktischer Umsetzung (Execution).

2. Architektonische Taxonomie und mentales Modell

Das Pattern wird durch drei komplementäre Phasen umgesetzt:

• 1. Discover- & Planner-Phase: Der Agent analysiert die Anfrage, liest vorab das Dateisystem (Read-Only) und generiert einen klar strukturierten Aktionsgraphen: ein Array von Schritten mit definierten Zielen, Erfolgskriterien und benötigten Dateien.
• 2. Solver-/Execution-Phase: Ein spezialisierter Executor nimmt den ersten offenen Punkt des Plans, ruft die erforderlichen Tools auf (Dateibearbeitung, Build-Ausführung), stellt sicher, dass die Teilaufgabe erfüllt ist, und markiert den Punkt als abgeschlossen.
• 3. Replanning- & Feedback-Phase: Tritt während der Ausführung eines Schritts ein Fehler auf, der nicht durch einfachen Retry behoben werden kann (z. B. fehlt ein benötigtes Modul im System), überprüft der Replanner die restlichen Punkte des Plans und fügt Schritte zur Installation von Abhängigkeiten hinzu.

3. Technischer Pipeline und interne Mechanik

Der Lebenszyklus nach dem Plan-and-Solve-Pattern:

1. Plan Generation (Generierung des strukturierten Plans): Das Modell formt ein valides JSON-Objekt mit einem Task-Array: tasks: [{ id: 1, title: "DB Schema", status: "pending" }, { id: 2, title: "API Route", status: "pending" }].
2. State Injection (Initialisierung des Trackers): Der Plan wird in den Agent-State geschrieben. Der Benutzer sieht den visuellen Fortschritt als interaktive Checkliste.
3. Execution Loop (Iterative Abarbeitung): Der Orchestrator wählt die nächste Aufgabe mit Status pending. Der Kontext wird von alten Debugging-Details bereinigt und fokussiert sich nur auf die aktuelle Aufgabe sowie das finale Ziel.
4. Invariant Check & Status Transition (Invarianzprüfung): Nach Abschluss eines Schritts wird ein Linter oder Unit-Test ausgeführt. Ist die Prüfung erfolgreich, wechselt der Status zu completed. Andernfalls wird die Methode replan() aufgerufen, die die noch ausstehenden Schritte anpasst.

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Komplexer Codebase-Migration

Umstellung eines Projekts vom Next.js Pages Router zum App Router:

• Schritt 1: Audit der Struktur des Ordners pages/ und Extraktion gemeinsamer Layouts.
• Schritt 2: Erstellung des Root-app/layout.tsx und der Basis-Stile.
• Schritt 3: Schrittweise Migration statischer Seiten.
• Schritt 4: Umschreiben dynamischer Routen und API Routes in route.ts.
• Schritt 5: Vollständiger Projekt-Build und Löschung veralteter Dateien.

02. Feature-Entwicklung nach Spezifikation (Spec-Driven Development)

Der Agent erhält eine Business-Anforderung. Zuerst schreibt er Dokumentation und Zod-Schemas, stimmt diese mit dem Benutzer ab und generiert erst nach Freigabe schrittweise Backend, Client-Hooks und UI-Komponenten.

03. Infrastruktur-Deployment von Servern

Schrittweises Hardening eines Linux VPS:

• Generierung eines Plans mit 6 Stufen (SSH-Keys, UFW-Firewall, fail2ban, Paketupdates, Erstellung eines Non-Root-Nutzers, Deaktivierung des Passwortzugriffs).
• Jeder Punkt wird einzeln ausgeführt, mit zwingender Überprüfung des Portstatus, bevor die vorherige Verbindungsmethode deaktiviert wird.

5. Fallstricke, typische Fehler und Sicherheit

• Blindes Planen (Premature Planning): Erstellen eines Plans ohne vorherige Analyse der Repository-Dateien. Das Modell könnte Bibliotheken planen, die im Projekt nicht vorhanden sind. Lösung: Pflichtschritt „Discovery“ vor Start des Planners.
• Übermäßige Starrheit (Plan Rigidity): Der Agent versucht hartnäckig, Schritt 3 auszuführen, obwohl sich bereits bei Schritt 1 herausgestellt hat, dass die Architektur einen grundlegend anderen Ansatz erfordert. Implementieren Sie unbedingt Hooks für dynamisches Replanning.
• Mikromanagement mit 30 Schritten: Zu feingranulare Schritte (z. B. ein eigener Schritt für jeden Typ-Import) verbrennen Zeit und Kosten. Halten Sie die Abstraktionsebene auf logische Funktionsblöcke beschränkt.