Innan du bränner upp många polletter med en stor agentsvärm på ett nytt projekt, är det gamla träbearbetningsmottoet "Mät två gånger, skär en gång!" värt att revidera till "Kolla dina pärlor N gånger, implementera en gång", där N i princip är så många du klarar av. Jag har märkt att du fortsätter att få fler och fler förbättringar, även om de är subtila, ju fler gånger du kör detta i rad med Opus 4.5 (notera att följande prompt bara är för användning EFTER att du redan har förvandlat din initiala markdown-plan till pärlor med hjälp av den andra prompt jag nyligen gav i mitt mycket långa inlägg om mina arbetsflöden): "Läs om AGENTS dot md så det fortfarande är färskt i minnet. Kolla varje pärla väldigt noggrant-- är du säker på att det är vettigt? Är det optimalt? Skulle vi kunna ändra något för att få systemet att fungera bättre för användarna? Om så är fallet, revidera pärlorna. Det är mycket enklare och snabbare att arbeta i "planutrymme" innan vi börjar implementera dessa saker! FÖRENKLA INTE SAKER FÖR MYCKET! FÖRLORA INGA FUNKTIONER ELLER FUNKTIONER! Se också till att vi som en del av dessa beads inkluderar omfattande enhetstester och e2e-testskript med utmärkt, detaljerad loggning så att vi kan vara säkra på att allt fungerar perfekt efter implementeringen. Kom ihåg att ENDAST använda 'bd'-verktyget för att skapa och modifiera pärlorna och för att lägga till beroenden till pärlorna. Använd ultrathink." Jag brukade bara köra det en eller två gånger innan jag började implementera, men jag experimenterade nyligen med att köra det 6+ gånger, och det fortsatte att göra användbara förbättringar. Om det börjar platta ut i form av gradvisa förbättringar av pärlorna kan du prova att starta en helt ny CC-session, med följande start: "Läs först ALLA AGENTS dot md-filer och README dot md-filer supernoggrant och förstå ALLT av båda! Använd sedan ditt kodundersökningsagentläge för att fullt ut förstå koden, den tekniska arkitekturen och syftet med projektet. Använd ultrathink." Och följer sedan upp med samma prompt som visas ovan, men inleds med: "Vi har nyligen förvandlat en nedslagsplan till en massa nya pärlor. Jag vill att du noggrant granskar och analyserar dessa med hjälp av 'bd' och 'bv'." Ju mer komplex och intrikat din rabattplan är, desto mer relevant är denna teknik. Om du har en liten, trivial plan och ett väldigt enkelt projekt är detta uppenbarligen överdrivet. Men i så fall kommer du troligen att se få inkrementella förbättringar/förbättringar per runda, så det borde vara ganska tydligt när det är dags att sluta. Kom bara ihåg: planeringstokens är mycket färre och billigare än implementationstokens. Även en mycket stor, komplex markdown-plan är kortare än några få substantiella kodfiler, än mindre ett helt projekt. Och modellerna är mycket smartare när de resonerar kring en plan som är mycket detaljerad och genomarbetad men ändå tillräckligt trivialt liten för att enkelt passa in i deras kontextfönster (detta är verkligen den viktigaste insikten bakom mitt tvångsmässiga fokus på planering och varför jag lade 80%+ av min tid på den delen). Och om du lutar dig mot GPT Pro med Extended Reasoning i webbappen för den initiala planeringen, som jag starkt rekommenderar (det vill säga för att skapa och förbättra din rabattplan som du så småningom förvandlar till pärlor), så får du i princip dem på en all-you-can-eat-basis med en Pro-plan, så utnyttja det fullt ut! Ingen annan modell kan röra Pro på webben när den hanterar indata som enkelt passar in i dess kontextfönster. Det är verkligen unikt. ...