Zanim spalisz wiele tokenów z dużą grupą agentów w nowym projekcie, stara zasada stolarska "Mierz dwa razy, tnij raz!" zasługuje na przemyślenie jako "Sprawdź swoje koralik N razy, wdrażaj raz," gdzie N to w zasadzie tyle, ile możesz znieść. Odkryłem, że im więcej razy to uruchamiasz z rzędu z Opus 4.5, tym więcej ulepszeń otrzymujesz, nawet jeśli są subtelne (zauważ, że poniższy prompt jest przeznaczony do użycia DOPIERO PO tym, jak już przekształciłeś swój początkowy plan markdown w koraliki za pomocą innego promptu, który niedawno podałem w moim bardzo długim poście o moich przepływach pracy): "Przeczytaj ponownie AGENTS dot md, aby było wciąż świeże w twojej pamięci. Sprawdź każdy koralik super dokładnie-- czy jesteś pewien, że ma sens? Czy jest optymalny? Czy możemy coś zmienić, aby system działał lepiej dla użytkowników? Jeśli tak, popraw koraliki. W "przestrzeni planu" działa się znacznie łatwiej i szybciej, zanim zaczniemy wdrażać te rzeczy! NIE UPROSZCZAJ RZECZY! NIE TRAC ZADNYCH CECH ANI FUNKCJONALNOŚCI! Ponadto upewnij się, że w ramach tych koralików uwzględniamy kompleksowe testy jednostkowe i skrypty testów e2e z doskonałym, szczegółowym logowaniem, abyśmy mogli być pewni, że wszystko działa perfekcyjnie po wdrożeniu. Pamiętaj, aby UŻYWAĆ TYLKO narzędzia `bd` do tworzenia i modyfikowania koralików oraz dodawania zależności do koralików. Użyj ultrathink." Kiedyś uruchamiałem to tylko raz lub dwa razy przed rozpoczęciem wdrożenia, ale ostatnio eksperymentowałem z uruchamianiem tego 6+ razy i ciągle wprowadzało to użyteczne poprawki. Jeśli zacznie to osiągać plateau pod względem stopniowych ulepszeń koralików, możesz spróbować rozpocząć nową sesję CC, zaczynając od: "Najpierw przeczytaj WSZYSTKIE pliki AGENTS dot md i README dot md super dokładnie i zrozum WSZYSTKO z obu! Następnie użyj trybu agenta do badania kodu, aby w pełni zrozumieć kod, architekturę techniczną i cel projektu. Użyj ultrathink." A następnie kontynuuj tym samym promptem, jak pokazano powyżej, ale poprzedzonym: "Niedawno przekształciliśmy plik planu markdown w mnóstwo nowych koralików. Chcę, abyś bardzo dokładnie przejrzał i przeanalizował je, używając `bd` i `bv`." Im bardziej złożony i skomplikowany jest twój plan markdown, tym bardziej odpowiednia jest ta technika. Jeśli masz mały, trywialny plan i bardzo prosty projekt, to oczywiście jest to przesada. Ale w takim przypadku prawdopodobnie zobaczysz niewiele w drobnych zyskach/zmianach z każdą rundą, więc powinno być dość oczywiste, kiedy czas przestać. Pamiętaj tylko: tokeny planowania są znacznie tańsze i mniej liczne niż tokeny wdrożeniowe. Nawet bardzo duży, skomplikowany plan markdown jest krótszy niż kilka istotnych plików kodu, nie mówiąc już o całym projekcie. A modele są znacznie mądrzejsze, gdy rozważają plan, który jest bardzo szczegółowy i rozwinięty, ale nadal na tyle mały, aby łatwo zmieścić się w ich oknie kontekstowym (to naprawdę kluczowy wgląd za moim obsesyjnym skupieniem na planowaniu i dlaczego spędzam 80%+ swojego czasu na tej części). A jeśli polegasz na GPT Pro z Rozszerzonym Rozumowaniem w aplikacji internetowej do początkowego planowania, jak mocno zalecam (to znaczy, aby stworzyć i poprawić swój plan markdown, który ostatecznie przekształcisz w koraliki), w zasadzie otrzymujesz je na zasadzie all-you-can-eat z planem Pro, więc w pełni z tego korzystaj! Żaden inny model nie może się równać z Pro w sieci, gdy ma do czynienia z danymi, które łatwo mieszczą się w jego oknie kontekstowym. To naprawdę unikalne. ...