Bevor du viele Token mit einem großen Agentenschwarm für ein neues Projekt verbrennst, ist das alte Tischler-Motto "Zweimal messen, einmal schneiden!" es wert, als "Überprüfe deine Perlen N-mal, implementiere einmal" überarbeitet zu werden, wobei N im Grunde so viele ist, wie du ertragen kannst. Ich habe festgestellt, dass du immer mehr Verbesserungen erhältst, selbst wenn sie subtil sind, je öfter du dies hintereinander mit Opus 4.5 ausführst (beachte, dass der folgende Prompt nur verwendet werden sollte, nachdem du deinen ursprünglichen Markdown-Plan in Perlen mit dem anderen Prompt, den ich kürzlich in meinem sehr langen Beitrag über meine Arbeitsabläufe gegeben habe, umgewandelt hast): "Lies AGENTS dot md noch einmal, damit es dir noch frisch im Gedächtnis ist. Überprüfe jede Perle super sorgfältig – bist du dir sicher, dass sie Sinn macht? Ist sie optimal? Könnten wir etwas ändern, um das System besser für die Benutzer zu machen? Wenn ja, überarbeite die Perlen. Es ist viel einfacher und schneller, im "Planraum" zu arbeiten, bevor wir mit der Implementierung dieser Dinge beginnen! ÜBERVERENFACHEN SIE DIE DINGE NICHT! VERLIERE KEINE FUNKTIONEN ODER FUNKTIONALITÄT! Stelle außerdem sicher, dass wir als Teil dieser Perlen umfassende Unit-Tests und e2e-Testskripte mit großartigem, detailliertem Logging einbeziehen, damit wir sicher sein können, dass nach der Implementierung alles perfekt funktioniert. Denke daran, NUR das `bd`-Tool zu verwenden, um die Perlen zu erstellen und zu ändern und die Abhängigkeiten zu den Perlen hinzuzufügen. Verwende ultrathink." Früher habe ich das nur ein- oder zweimal ausgeführt, bevor ich mit der Implementierung begonnen habe, aber ich habe kürzlich experimentiert, indem ich es 6+ Mal ausgeführt habe, und es hat weiterhin nützliche Verfeinerungen hervorgebracht. Wenn es anfängt, in Bezug auf inkrementelle Verbesserungen der Perlen zu stagnieren, könntest du versuchen, eine brandneue CC-Sitzung zu starten, indem du sie mit: "Lies zuerst ALLE AGENTS dot md-Dateien und README dot md-Dateien super sorgfältig und verstehe ALLES von beiden! Verwende dann deinen Code-Untersuchungs-Agentenmodus, um den Code, die technische Architektur und den Zweck des Projekts vollständig zu verstehen. Verwende ultrathink." Und dann mit dem gleichen Prompt wie oben fortfahren, aber eingeleitet mit: "Wir haben kürzlich eine Markdown-Plan-Datei in eine Menge neuer Perlen umgewandelt. Ich möchte, dass du diese sehr sorgfältig überprüfst und analysierst, indem du `bd` und `bv` verwendest." Je komplexer und intricater dein Markdown-Plan ist, desto relevanter ist diese Technik. Wenn du einen kleinen, trivialen Plan und ein sehr einfaches Projekt hast, ist das offensichtlich übertrieben. Aber in diesem Fall wirst du wahrscheinlich wenig in Bezug auf inkrementelle Gewinne/Änderungen mit jeder Runde sehen, sodass es ziemlich offensichtlich sein sollte, wann es Zeit ist, aufzuhören. Denk daran: Planungstoken sind viel weniger und günstiger als Implementierungstoken. Selbst ein sehr großer, komplexer Markdown-Plan ist kürzer als ein paar substanzielle Code-Dateien, ganz zu schweigen von einem ganzen Projekt. Und die Modelle sind viel intelligenter, wenn sie über einen Plan nachdenken, der sehr detailliert und ausgearbeitet ist, aber immer noch trivial klein genug, um leicht in ihr Kontextfenster zu passen (das ist wirklich die Schlüssel-Einsicht hinter meinem obsessiven Fokus auf Planung und warum ich 80%+ meiner Zeit auf diesen Teil verwendet habe). Und wenn du auf GPT Pro mit Extended Reasoning in der Web-App für die anfängliche Planung setzt, wie ich nachdrücklich empfehle (das heißt, um deinen Markdown-Plan zu erstellen und zu verbessern, den du schließlich in Perlen umwandelst), erhältst du diese im Grunde auf einer All-you-can-eat-Basis mit einem Pro-Plan, also nutze das voll aus! Kein anderes Modell kann Pro im Web erreichen, wenn es mit Eingaben umgeht, die leicht in sein Kontextfenster passen. Es ist wirklich einzigartig. ...