Dołączyłem tutaj miniaturową wersję tego promptu, ponieważ seria "Moje ulubione prompty" ma być kompaktowa, małych rozmiarów, samodzielnie zawierająca informacje. Ale dzisiaj przekształciłem to w naprawdę szalony system. Nie ma to znaczenia, czy tworzysz kolejny program CRUD w React lub listę TODO, ale jeśli robisz coś dość skomplikowanego w Rust lub Golang, lub coś związanego z złożonymi danymi, to podejście jest prawie przerażające w tym, co może zrobić. To proces składający się z 2 rund. Oto Runda 1: --- Najpierw przeczytaj WSZYSTKIE pliki AGENTS dot md i README dot md bardzo uważnie 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. Następnie, gdy już wykonasz niezwykle dokładną i skrupulatną pracę w tym zakresie i głęboko zrozumiesz cały istniejący system, co robi, jego cel, jak jest wdrożony i jak wszystkie elementy łączą się ze sobą, muszę, abyś hiper-intensywnie zbadał, studiował i rozmyślał nad tymi pytaniami, które dotyczą tego projektu: Czy są jakieś inne poważne nieefektywności w systemie podstawowym? miejsca w bazie kodu, gdzie 1) zmiany rzeczywiście wpłynęłyby na ogólną latencję/reaktywność i przepustowość; 2) w taki sposób, że nasze zmiany byłyby dowodowo izomorficzne pod względem funkcjonalności, abyśmy wiedzieli na pewno, że nie zmieni to wynikowych wyjść przy tych samych wejściach; 3) gdzie masz wyraźną wizję oczywiście lepszego podejścia pod względem algorytmów lub struktur danych (zauważ, że w tym przypadku możesz uwzględnić w swoich rozważaniach mniej znane struktury danych oraz bardziej ezoteryczne/sofistykowane/matematyczne algorytmy, a także sposoby przekształcenia problemów, aby ujawnić inny paradygmat, taki jak lista pokazana poniżej (Uwaga: przed zaproponowaniem jakiejkolwiek optymalizacji ustal metryki bazowe (p50/p95/p99 latencja, przepustowość, maksymalna pamięć) i uchwyć profile CPU/alokacji/I/O, aby zidentyfikować rzeczywiste gorące punkty): - eliminacja wzorca zapytań/fetch N+1 - zero-copy / ponowne użycie buforów / scatter-gather I/O - koszty formatu serializacji (przeanalizuj/zakoduj) - ograniczone kolejki + backpressure (zapobiegaj wzrostowi pamięci i latencji ogonowej) - sharding / zablokowane paski, aby zmniejszyć kontencję - memoizacja z strategiami unieważniania pamięci podręcznej - techniki programowania dynamicznego - teoria optymalizacji wypukłej - leniwa ewaluacja / opóźnione obliczenia - wzorce iteratorów/generatorów, aby uniknąć materializacji dużych kolekcji - przetwarzanie strumieniowe/podzielone dla pracy ograniczonej pamięcią - wstępne obliczenia i tabele wyszukiwania - wyszukiwanie oparte na indeksach vs liniowe skanowanie - wyszukiwanie binarne (na danych i na przestrzeni odpowiedzi) - techniki dwóch wskaźników i przesuwającego się okna - sumy prefiksowe / kumulacyjne agregaty - sortowanie topologiczne i świadomość DAG dla grafów zależności - wykrywanie cykli - union-find dla dynamicznej łączności - przeszukiwanie grafów (BFS/DFS) z wczesnym zakończeniem - Dijkstra / A* dla ważonych najkrótszych ścieżek - kolejki priorytetowe / kopce - tries dla operacji prefiksowych - filtry blooma dla probabilistycznego członkostwa - drzewa przedziałowe/segmentowe dla zapytań zakresowych - indeksowanie przestrzenne (drzewa k-d, quadtrees, R-trees) - trwałe/niemutowalne struktury danych - semantyka copy-on-write - puli obiektów/połączeń - wybór polityki usuwania pamięci podręcznej (LRU/LFU/ARC) - wybór algorytmu świadomego wsadowości - asynchroniczne wsadowe I/O i koalescencja - struktury bezblokowe dla scenariuszy o wysokiej kontencji - kradzież pracy dla równoległości rekurencyjnej - optymalizacja układu pamięci (SoA vs AoS, lokalność pamięci cache) - skrócenie i wczesne zakończenie - internowanie ciągów dla powtarzających się wartości - rozumowanie analizy amortyzowanej biorąc pod uwagę te ogólne wytyczne, gdzie to możliwe: SPRAWDZENIA ZASTOSOWANIA DP: - Nakładające się podproblemy? → memoizuj z kluczem stabilnego stanu - Optymalne partycjonowanie/wsadowość? → sumy prefiksowe + DP przedziałowe - Graf zależności z powtarzanym przeszukiwaniem? → DP topologiczne w jednym przejściu SPRAWDZENIA OPTIMALIZACJI WYPUKŁEJ: - Brutalne wymuszanie dokładnej alokacji/harmonogramu? → LP / przepływ minimalnych kosztów z deterministycznym łamaniem remisu - Dopasowywanie parametrów ciągłych z wyraźną stratą? → regularizowane najmniejsze kwadraty / QP - Duży rozkładalny cel wypukły? → ADMM / metody proksymalne Zauważ również, że jeśli znasz dobrze napisane biblioteki stron trzecich, które dobrze by działały, możemy je uwzględnić w projekcie). WYMAGANIA METODOLOGICZNE: A) Najpierw baza: Uruchom zestaw testów i reprezentatywny ładunek; zarejestruj latencję p50/p95/p99, przepustowość i maksymalną pamięć z dokładnymi poleceniami. B) Profiluj przed proponowaniem: Uchwyć profile CPU + alokacji + I/O; zidentyfikuj 3–5 gorących punktów według % czasu przed zasugerowaniem zmian. C) Oracle równoważności: Zdefiniuj wyraźne złote wyjścia + invariants. Dla dużych przestrzeni wejściowych dodaj testy oparte na właściwościach lub testy metamorficzne. D) Dowód izomorfizmu dla każdej zmiany: Każda proponowana różnica musi zawierać krótki szkic dowodu wyjaśniający, dlaczego wyjścia nie mogą się zmienić (w tym porządek, łamanie remisu, zachowanie zmiennoprzecinkowe i nasiona RNG). E) Macierz możliwości: Oceń kandydatów według (Wpływ × Pewność) / Wysiłek przed wdrożeniem; skup się tylko na elementach, które prawdopodobnie znacząco wpłyną na p95+ lub przepustowość. F) Minimalne różnice: Jeden dźwignia wydajności na zmianę. Żadne niepowiązane refaktory. Dołącz wskazówki dotyczące wycofania, jeśli istnieje jakiekolwiek ryzyko. G) Ochrona przed regresją: Dodaj progi benchmarkowe lub haki monitorujące, aby zapobiec przyszłym regresjom. Użyj ultrathink. --- Możesz to uruchomić raz w Claude Code z Opus 4.5 i raz w Codex z GPT 5.2 Codex (zacząłem używać tylko Wysokiego, ponieważ Ekstra Wysokie jest dla mnie zbyt wolne, chyba że zamierzam iść spać). Po zakończeniu, uderz w nie każde z nich jakimiś 5 szybkimi rundami tego: "Świetnie. Spójrz jeszcze raz na wszystko pod kątem oczywistych przeoczeń, pominięć lub błędów, błędów koncepcyjnych, gaf itp. Użyj ultrathink" Następnie każ im zapisać wyniki w ten sposób: "OK, zapisz to wszystko jako PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, zapisz to wszystko jako PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Następnie w Claude Code, zrób: "Porównaj to, co zrobiłeś z PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md i weź najlepsze elementy z tego i wpleć je w swój plan, aby uzyskać hybrydowy najlepszy plan z obu światów, edytując swój oryginalny plik planu na miejscu." Następnie to: Przeczytaj ponownie AGENTS dot md, aby było świeże w twojej pamięci. Teraz przeczytaj WSZYSTKO z PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Następnie sprawdź każdy bead bardzo uważnie-- czy jesteś pewien, że ma sens? Czy jest optymalny? Czy możemy coś zmienić, aby system działał lepiej dla użytkowników? Chcemy kompleksowego i szczegółowego zestawu beadów dla tego wszystkiego z zadaniami, podzadaniami i strukturą zależności nałożoną, z szczegółowymi komentarzami, aby całość była całkowicie samodzielna i samodokumentująca (w tym odpowiednie tło, uzasadnienie/uzasadnienie, rozważania itp.-- wszystko, co chcielibyśmy, aby nasza "przyszła ja" wiedziała o celach i intencjach oraz procesie myślowym i jak to służy ogólnym celom projektu). Beady powinny być tak szczegółowe, że nigdy nie będziemy musieli wracać do oryginalnego dokumentu planu markdown. Czy dokładnie odzwierciedla WSZYSTKO z pliku planu markdown w sposób kompleksowy? Jeśli zmiany są uzasadnione, to popraw bead lub stwórz nowe lub zamknij nieważne lub nieodpowiednie. W "przestrzeni planu" łatwiej i szybciej jest działać przed rozpoczęciem wdrażania tych rzeczy! NIE UPROSZCZAJ RZECZY! NIE TRAC ZADNYCH CECH ANI FUNKCJONALNOŚCI! Upewnij się również, że jako część tych beadó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 beadów oraz dodawania zależności do beadów." Następnie kilka rund: "Sprawdź każdy bead bardzo uważnie-- 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 bead. W "przestrzeni planu" łatwiej i szybciej jest działać przed rozpoczęciem wdrażania tych rzeczy! NIE UPROSZCZAJ RZECZY! NIE TRAC ZADNYCH CECH ANI FUNKCJONALNOŚCI! Upewnij się również, że jako część beadó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. Użyj ultrathink." Następnie uwolnij rój, aby to wszystko wdrożyć. Następnie przygotuj się na RUNDĘ 2.