# Jak zapobiec utracie kontekstu w długiej sesji programistycznej? > Zapobiegaj utracie kontekstu, przenosząc trwałe fakty z czatu do zwartego rejestru zadań, decyzji, testów i checkpointów repozytorium. Przed kompresją lub zmianą modelu odtwarzaj stan z tych artefaktów zamiast powtarzać nieograniczoną rozmowę. Długie sesje zwykle zawodzą przez stopniowe odchylenie, nie nagłą amnezję. Agent pamięta ogólny cel, ale gubi małe ograniczenie, ufa nieaktualnemu testowi, powtarza analizę lub edytuje według planu, który nie pasuje już do repozytorium. Rozwiązaniem jest trwały stan zewnętrzny, krótszy i bardziej wiarygodny niż rozmowa. Traktuj czat jako pamięć roboczą, a repozytorium jako źródło prawdy. Przy każdym ważnym checkpoincie zapisz, co się zmieniło, co potwierdzono, co pozostaje niepewne i jaki jest następny krok. ## Śledź cztery rodzaje kontekstu Rozdzielaj fakty według funkcji, aby podsumowanie nie stało się jednolitą opowieścią. | Typ | Przykłady | Trwałe miejsce | |---|---|---| | Cel | Wynik użytkownika i kryteria akceptacji | Rejestr zadań | | Ograniczenia | Zgodność, bezpieczeństwo, styl i zakres | Rejestr zadań | | Stan repozytorium | Zmienione pliki i bieżąca gałąź | Kontrola wersji | | Dowody | Testy, logi, zrzuty i benchmarki | Rejestr weryfikacji | Założenia dodawaj jako piątą kategorię tylko wtedy, gdy są wyraźnie oznaczone. Każde powinno wskazywać najtańszą czynność potwierdzającą lub obalającą. ## Prowadź zwarty rejestr zadań Użyteczny rejestr mieści się na jednym ekranie. Aktualizuj go po kamieniach milowych, nie po każdej wiadomości. ```md Objective: Ship model-switch support without changing existing tool behavior. Constraints: * Preserve the public API. * No destructive migration. Current state: * Parser adapter added in src/stream.ts. * Unit tests pass; cancellation test still fails. Decisions: * Buffer tool arguments until the final event. Evidence: * npm test: 142 passed, 1 failed. Next action: Fix duplicate execution after stream cancellation. ``` Zachowuj dokładne ścieżki, komendy i nazwy błędów. Unikaj dziennika przebiegu rozmowy. ## Umieszczaj checkpointy przy zweryfikowanym stanie Checkpoint powinien następować po wyniku możliwym do odtworzenia: zaliczonym zestawie testów, małej potwierdzonej zmianie, zweryfikowanej odpowiedzi API lub decyzji popartej przypadkiem testowym. Przed zmianą modelu lub kompresją zapisz niezatwierdzone pliki. Nie twierdź, że funkcja działa, bo napisano kod; powiąż twierdzenie z testem, buildem lub widocznym artefaktem. | Twierdzenie | Potrzebny dowód | |---|---| | Parser obsługuje dwa wywołania | Test z dwoma powiązanymi ID | | Ponowienie jest bezpieczne | Test idempotencji przy rozłączeniu | | Refaktoryzacja zachowuje zachowanie | Stare i nowe testy przechodzą | | UI jest poprawne | Kontrola renderu w docelowych rozmiarach | ## Odczytuj źródło zamiast powtarzać czat Gdy detal ma znaczenie, ponownie otwórz aktualny plik, schemat lub dokument oficjalny. Stary fragment rozmowy może opisywać kod, który już się zmienił. Podaj ścieżki i terminy wyszukiwania do sprawdzenia bieżącego stanu. Odczyt powinien być wąski: interfejs, implementacja, błędny test i właściwy log przed całym repozytorium. Pozostawia to miejsce na rozumowanie. ## Kompresuj, zachowując decyzje i dowody Dobra kompresja usuwa powtórzenia, lecz zachowuje ograniczenia, trudne do cofnięcia decyzje, odrzucone opcje i weryfikacje. Rozróżniaj `verified`, `observed`, `assumed` i `pending`. Nie opisuj nieudanego eksperymentu jako projektu końcowego. Zachowaj powód odrzucenia, jeśli ten sam pomysł może wrócić. ## Ogranicz dane wyjściowe narzędzi Długie logi i pliki generowane szybko zużywają uwagę. Żądaj zakresów, liczników lub pasujących wierszy; pełny wynik zapisz jako artefakt, a zwróć krótki opis ze ścieżką. Przy błędach zachowaj pierwszy użyteczny stack, błędną asercję i dane środowiska, a nie setki powtórzonych ramek. ## Wznawiaj według deterministycznego rytuału Po przerwie, kompresji lub zmianie modelu: * Przeczytaj cel i ograniczenia. * Sprawdź kontrolę wersji i ostatnie zmiany. * Otwórz pliki wskazane w aktualnym stanie. * Powtórz ostatnią istotną kontrolę. * Potwierdź, że kolejna czynność jest nadal właściwa. Ta rutyna wykrywa nieaktualne podsumowania przed nowymi edycjami. ## Wybieraj modele bez polegania na pamięci czatu Gateway ułatwia zmianę, ale stan pozostaje twoją odpowiedzialnością. Atlas Cloud oferuje kilka protokołów pod jednym adresem; sprawdź [macierz protokołów](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) i [katalog modeli](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context) przed przeniesieniem aktywnego agenta. Przekaż nowemu modelowi rejestr, odpowiednie pliki i świeży wynik weryfikacji. Nie polegaj na ID stanu konkretnego dostawcy bez potwierdzenia protokołu i zachowania. ## Podsumowanie Długie sesje zachowują kontekst, gdy trwały stan jest zwarty, poparty dowodami i łatwy do ponownego wczytania. Używaj rejestru na jeden ekran, checkpointów po zweryfikowanych zmianach, aktualnego źródła zamiast czatu, ograniczonych wyników i stałego rytuału wznowienia. Większe okno pomaga, ale to zdyscyplinowany stan zewnętrzny czyni pracę odtwarzalną. ## FAQ ### Czy większe okno kontekstu wystarczy do długiej sesji? Nie. Większa pojemność opóźnia presję, lecz nie gwarantuje widoczności starych ograniczeń ani korekty nieaktualnych obserwacji. ### Co powinno znaleźć się w rejestrze sesji? Cel, ograniczenia, aktualny plan, zmienione pliki, kluczowe decyzje, wyniki weryfikacji, otwarte ryzyka i dokładna kolejna czynność. ### Kiedy tworzyć checkpoint? Po istotnej zmianie stanu, np. zaliczonym teście, zakończonym etapie, decyzji projektowej lub odkryciu zmieniającym plan. ### Czy wkleić całą rozmowę do nowego modelu? Zwykle nie. Przekaż wybrany checkpoint, odpowiednie pliki i logi, a nowy model niech sprawdzi aktualny stan. ### Jak nie utrwalić starego błędu w podsumowaniu? Oddziel potwierdzone fakty od założeń, dołącz komendy lub ścieżki jako dowody i wycofaj twierdzenia sprzeczne z nowymi testami. ### Jak najbezpieczniej wznowić pracę po przerwie? Wczytaj rejestr, sprawdź kontrolę wersji, powtórz ostatnią istotną weryfikację i zacznij od zapisanej następnej czynności.