Debugowanie wspomagane przez AI w Cursor
Produkcja zwraca błędy 500 na 15% żądań checkout. Działa bezbłędnie w developmencie. Zaczęło się po wdrożeniu we wtorek, ale diff wygląda niewinnie — tylko mała refaktoryzacja logiki przetwarzania płatności. Komunikat błędu to niezwykle nieprzydatne “Transakcja nie powiodła się”. Twój CEO pyta o aktualizacje co 30 minut.
Możesz spędzić godziny na manualnym czytaniu logów, dodawaniu console.log i próbach odtworzenia problemu lokalnie. Lub możesz użyć możliwości debugowania Cursor, aby systematycznie zawęzić problem w minuty zamiast godzin. Kluczowa wiedza: debugowanie to problem wyszukiwania, a AI jest bardzo dobry w wyszukiwaniu.
Co wyniesiesz z tej lekcji
Dział zatytułowany „Co wyniesiesz z tej lekcji”- Systematyczny prompt do analizy logów błędów i wydobywania wzorców, których ludzkie oko nie zauważa
- Przepływ pracy trybu Debug, który instrumentuje kod, przechwytuje dane runtime i identyfikuje przyczyny główne
- Prompt “generowania hipotez”, który produkuje uszeregowane, testowalne teorie z objawów
- Prompt generowania testu obciążeniowego do odtwarzania przerywanych awarii lokalnie
- Szablon post-mortem, który dokumentuje bug, poprawkę i strategię prewencji
Przepływ pracy
Dział zatytułowany „Przepływ pracy”Krok 1: Zbierz objawy z trybem Ask
Dział zatytułowany „Krok 1: Zbierz objawy z trybem Ask”Przed zbadaniem kodu, zbierz każdy obserwowalny fakt o awarii. Użyj trybu Ask, więc tylko czytasz i analizujesz, nie zmieniasz przypadkowo niczego w bazie kodu związanej z produkcją.
Model prawdopodobnie zidentyfikuje wzorce jak wyczerpanie puli połączeń, race conditions, błędne konfiguracje timeout, lub brakujący handler błędów na konkretnej ścieżce kodu. Każda hipoteza jest testowalna, co jest kluczową częścią — niejasne teorie marnują czas.
Krok 2: Przełącz na tryb Debug do badania runtime
Dział zatytułowany „Krok 2: Przełącz na tryb Debug do badania runtime”Cursor ma dedykowany tryb Debug zaprojektowany dokładnie dla tego rodzaju problemów. Naciśnij Cmd+. lub Shift+Tab, aby przełączyć na tryb Debug. W przeciwieństwie do trybu Agent, tryb Debug podąża za strukturalnym procesem śledztwa:
- Eksploruje odpowiednie pliki i generuje hipotezy
- Dodaje instrumentację (instrukcje logowania) do twojego kodu, które raportują do lokalnego serwera debug
- Prosi cię o odtworzenie buga
- Analizuje zebrane dane runtime
- Proponuje celowaną poprawkę opartą na dowodach, nie domysłach
Endpoint checkout na POST /api/checkout zwraca "Transakcja nie powiodła się"dla ~15% żądań pod obciążeniem. Błąd następuje w kroku przetwarzaniapłatności. Mogę odtworzyć lokalnie używając narzędzia do testowania obciążenia (k6 lub podobnego)które wysyła 200 równoczesnych żądań.
Znajdź przyczynę główną używając instrumentacji.Tryb Debug doda instrukcje logowania w kluczowych punktach — nabycie połączenia do bazy danych, wywołania API płatności, granice transakcji — i poprosi cię o wywołanie buga. Kiedy zbierze dane runtime, często może określić dokładny problem w ciągu minut.
Krok 3: Odtwórz awarię z celowanym testem obciążeniowym
Dział zatytułowany „Krok 3: Odtwórz awarię z celowanym testem obciążeniowym”Jeśli nie możesz odtworzyć buga manualnie, poproś tryb Agent o wygenerowanie testu obciążeniowego, który wywołuje dokładne warunki.
Uruchom test lokalnie. Jeśli odtwarza awarię, masz niezawodny sposób na zweryfikowanie swojej poprawki później.
Krok 4: Analizuj dowody z trybem Agent
Dział zatytułowany „Krok 4: Analizuj dowody z trybem Agent”Kiedy masz logi, ślady błędów lub output trybu Debug, użyj trybu Agent do analizy danych i identyfikacji przyczyny głównej.
@logs/debug-output.log @src/payment/processor.ts
Oto logi debug z testu obciążeniowego. Przeanalizuj je i odpowiedz:
1. Które żądania nie powiodły się i co mają wspólnego?2. Jaki jest wzorzec czasowy? Czy awarie grupują się w konkretnych odstępach?3. Czy jest zasób, który jest wyczerpywany (połączenia, uchwyty plików, pamięć)?4. Czy możesz zidentyfikować dokładną linię, gdzie awaria się rozpoczyna?5. Jaka jest przyczyna główna?
Pokaż mi konkretny kod, który trzeba zmienić i wyjaśnij dlaczego.Typowe odkrycie w tym scenariuszu: procesor płatności nabywa połączenie do bazy danych, ale nie zwalnia go na niektórych ścieżkach błędów (“wyciek połączenia”). Pod obciążeniem pula połączeń się wyczerpuje, a kolejne żądania kończą się timeoutem, który zostaje opakowany w ogólny komunikat “Transakcja nie powiodła się”.
Krok 5: Zaimplementuj i zweryfikuj poprawkę
Dział zatytułowany „Krok 5: Zaimplementuj i zweryfikuj poprawkę”Kiedy przyczyna główna jest zidentyfikowana, użyj trybu Agent do zaimplementowania poprawki, dodania testu regresji i ulepszenia obsługi błędów, aby ta klasa bugów była łatwiejsza do zdiagnozowania następnym razem.
Krok 6: Napisz post-mortem
Dział zatytułowany „Krok 6: Napisz post-mortem”To jest krok, który większość zespołów pomija, a jest najbardziej wartościowy długoterminowo. Użyj trybu Ask do napisania strukturalnego post-mortem z sesji debugowania.
Na podstawie tej sesji debugowania, napisz dokument post-mortem obejmujący:
1. Podsumowanie: co się zepsuło, kto został dotknięty, jak długo to trwało2. Timeline: kiedy się zaczęło, kiedy wykryto, kiedy naprawiono3. Przyczyna główna: wyciek połączenia w przetwarzaniu płatności4. Poprawka: co się zmieniło i dlaczego5. Luka w wykrywaniu: dlaczego nasze monitorowanie nie wykryło tego wcześniej6. Prewencja: co zrobimy, aby zapobiec podobnym bugom (alertowanie puli połączeń, checklist przeglądu kodu dla czyszczenia zasobów)7. Elementy akcji z właścicielami i terminami
Zapisz do docs/postmortems/2026-02-checkout-connection-leak.mdZaawansowana technika: Git Bisect z AI
Dział zatytułowany „Zaawansowana technika: Git Bisect z AI”Kiedy bug zaczął się po konkretnym wdrożeniu i masz dobry test, użyj kontekstu @git, aby zawęzić dokładny commit:
@git
Test obciążeniowy checkout przechodzi na commit abc123 (poniedziałek), ale nie przechodzi na HEAD (wtorek).Jest 12 commitów między nimi. Pomóż mi skonfigurować git bisect:
1. Utwórz skrypt, który uruchamia test obciążeniowy i zwraca kod wyjścia 0, jeśli mniej niż 1% z żądań nie powiedzie się, kod wyjścia 1 w przeciwnym razie2. Pokaż mi polecenia git bisect, aby znaleźć dokładny commit, który wprowadził regresjęTo zawęża 12 commitów do 1 w około 4 iteracjach.
Kiedy to się psuje
Dział zatytułowany „Kiedy to się psuje”Instrumentacja trybu Debug zmienia zachowanie buga. Dodanie instrukcji logowania może zmienić timing na tyle, że race conditions znikają (problem “Heisenbugs”). Jeśli to się dzieje, użyj lżejszej instrumentacji: inkrementuj atomowe liczniki zamiast logować stringi, lub użyj timestampów process.hrtime(), które nie wymagają I/O.
AI generuje prawdopodobną, ale błędną przyczynę główną. Modele AI są doskonałe w dopasowywaniu wzorców, ale mogą być pewnie mylne. Zawsze weryfikuj hipotezę przed implementacją poprawki. Test obciążeniowy powinien potwierdzić: jeśli przyczyna główna jest poprawna, poprawka powinna zredukować wskaźnik błędów do prawie zera.
Tryb Agent sugeruje poprawkę, która maskuje objaw. Typowa zła poprawka: dodanie ogólnego wrappera retry wokół zawodzącej operacji zamiast naprawienia wycieku. Retries maskują wyczerpanie puli połączeń tymczasowo, ale pogorszają to pod trwałym obciążeniem. Sprzeciwiaj się poprawkom na szybko — poproś AI o znalezienie rzeczywistej przyczyny, nie obejścia.
Nie można odtworzyć lokalnie. Niektóre bugi manifestują się tylko przy wolumenach danych produkcyjnych, opóźnieniu sieciowym lub konkretnym sprzęcie. W tych przypadkach instrumentuj produkcję ze strukturalnym logowaniem i analizuj logi z trybem Ask. Użyj @web do wyszukania znanych problemów z konkretną biblioteką lub serwisem, który zawodzi.
Błąd jest w bibliotece zewnętrznej. Jeśli ślad buga prowadzi do node_modules, użyj @docs, aby sprawdzić tracker problemów biblioteki i changelogs. Zapytaj: “Czy ta biblioteka była zgłaszana jako mająca wycieki połączeń lub problemy z timeout w ostatnich wersjach?”