Než spálíte spoustu žetonů s velkým zástupcem na novém projektu, staré dřevařské heslo "Měřit dvakrát, jednou řezat!" stojí za to přehodnotit na "Zkontrolujte korálky N-krát, provedte jednou," kde N je v podstatě tolik, kolik zvládnete. Zjistil jsem, že čím víc to spusťujete za sebou s Opus 4.5 (poznámka: následující prompt je určen pouze POTÉ, co jste svůj původní plán markdownu proměnili v korálky podle druhého promptu, který jsem nedávno uvedl ve svém nedávném velmi dlouhém příspěvku o svých pracovních postupech): "Přečti si znovu AGENTS dot md, aby to bylo stále čerstvé v paměti. Pečlivě zkontrolujte každou korálku – jste si jistý, že to dává smysl? Je to optimální? Můžeme něco změnit, aby systém fungoval lépe pro uživatele? Pokud ano, upravte korálky. Je mnohem jednodušší a rychlejší pracovat v "plánovacím prostoru" ještě před tím, než začneme tyto věci zavádět! NEZJEDNODUŠUJTE TO PŘÍLIŠ! NEZTRÁCEJTE ŽÁDNÉ FUNKCE ANI FUNKČNOST! Také se ujistěte, že součástí těchto perlí jsou komplexní jednotkové testy a e2e testovací skripty s kvalitním, detailním logováním, abychom si byli jisti, že vše po implementaci funguje perfektně. Pamatujte, že nástroj 'bd' je třeba používat POUZE k vytváření a úpravě korálků a přidávání závislostí do korálků. Používejte ultrathink." Dřív jsem to spouštěl jen jednou nebo dvakrát před začátkem implementace, ale nedávno jsem to zkoušel spouštět 6+ krát a pořád to přinášelo užitečné vylepšení. Pokud začne stagnovat v postupném zlepšování korálků, můžete zkusit začít úplně novou CC seanci, začít z: "Nejdřív si přečti VŠECHNY soubory AGENTŮ tečka md a README tečka md soubory velmi pečlivě a pochop VŠECHNO z obou! Pak použijte režim agenta pro vyšetřování kódu, abyste plně pochopili kód, technickou architekturu a účel projektu. Používejte ultrathink." A pak pokračuje stejným zadáním, které je uvedeno výše, ale s úvodem: "Nedávno jsme proměnili soubor s plánem marke na spoustu nových korálků. Chci, abyste je velmi pečlivě zkontrolovali a analyzovali pomocí 'bd' a 'bv'." Čím složitější a propracovanější je váš plán snižování, tím relevantnější je tato technika. Pokud máte malý, triviální plán a velmi jednoduchý projekt, je to samozřejmě přehnané. Ale v tom případě pravděpodobně uvidíte s každým kolem jen málo postupných zlepšení nebo změn, takže by mělo být docela jasné, kdy je čas přestat. Jen si pamatujte: plánovací tokeny jsou mnohem méně a levnější než implementační tokeny. I velmi velký, složitý plán markdownu je kratší než pár podstatných souborů kódu, natož celý projekt. A modely jsou mnohem chytřejší při uvažování o plánu, který je velmi detailní a propracovaný, ale zároveň dostatečně malý, aby se snadno vešel do jejich kontextového okna (to je opravdu klíčový poznatek mého posedlého zaměření na plánování a proč jsem tomu věnoval 80 %+ času). A pokud se při počátečním plánování opíráte o GPT Pro s rozšířeným uvažováním ve webové aplikaci, jak důrazně doporučuji (tedy vytvořit a vylepšit svůj plán slev, který nakonec proměníte v korálky), dostanete je v podstatě na principu "neomezené jídlo" s Pro plánem, takže toho využijte naplno! Žádný jiný model nemůže Pro na webu sáhnout, když zpracovává vstup, který se snadno vejde do kontextového okna. Je to opravdu jedinečné. ...