Zyski:
- Możliwość zredukowania błędu do najmniejszego powtarzalnego wystąpienia i przeniesienia go do AI z pełnym dowodem
- Możliwość testowania hipotez opartych na dowodach za pomocą najtańszej kontroli i znalezienia pierwotnej przyczyny
- Możliwość rozwiązania pierwotnej przyczyny i zabezpieczenia jej za pomocą testu regresyjnego zamiast łatania objawu
Debugowanie to proces ustalania, dlaczego oprogramowanie zachowuje się nieoczekiwanie i naprawiania tego. Jest to praca, w której programista spędza najwięcej czasu i jest najbardziej zmęczony; Ponieważ w większości przypadków błąd nie jest tam, gdzie się pojawia, ale jest ukryty kilka kroków za nim. Sztuczna inteligencja to potężny partner, który przyspiesza te badania, ale tylko wtedy, gdy przedstawisz im odpowiednie dowody. Debugowanie bez dowodów to obszar, w którym sztuczna inteligencja wywołuje najwięcej halucynacji.
W tej jednostce ustalamy zdyscyplinowany przepływ od wygenerowania błędu do dotarcia do pierwotnej przyczyny: wyjaśnienie symptomu, zebranie dowodów (komunikat o błędzie, ślad stosu, dziennik, wpis), wygenerowanie hipotezy, przetestowanie hipotezy i weryfikacja poprawki. AI pomaga na każdym kroku; ale „stała” decyzja jest podejmowana na podstawie sprawdzenia, czy błąd rzeczywiście zniknął.
Dlaczego dowody są wszystkim?
LLM nie widzi błędów tak jak Ty; On wie tylko to, co mu powiesz. Zdanie takie jak „Awaria aplikacji” nie daje modelowi prawie żadnych informacji, a model wypełnia lukę przewidywaniem – czyli halucynacją. Z kolei pełny komunikat o błędzie, ślad stosu — zestawienie wywołań funkcji, przez które wystąpił błąd, dane wejściowe, które spowodowały błąd, czego oczekiwano itp. Biorąc pod uwagę zaobserwowane zachowanie, model może uszeregować prawdziwe prawdopodobieństwa.
Podczas debugowania pomyśl o sztucznej inteligencji jako o asystencie detektywa: im więcej dowodów przedstawisz, tym dokładniejsza będzie wygenerowana przez nią hipoteza. Jeśli nie ma dowodów, asystent będzie tylko zgadywał i może sprowadzić Cię na zły trop.
Wskazówka: zanim przeniesiesz błąd do AI, zredukuj go do najmniejszego powtarzalnego przykładu. Najmniejszy kod i dane wejściowe, które powodują błąd, znacznie ułatwiają pracę zarówno Tobie, jak i modelowi; najczęściej podczas tej redukcji sam znajdujesz przyczynę.
Krok po kroku: Przebieg analizy pierwotnej przyczyny
- Wyjaśnij objaw. „Co się dzieje, czego się spodziewałeś?” Zapisz oba w jednym zdaniu.
- Zbierz dowody. Pełny komunikat o błędzie, ślad stosu, odpowiednie wiersze dziennika, wpis wyzwalający, informacje o wersji.
- Wygeneruj hipotezę. Z AI „3 możliwe przyczyny wyjaśniające ten objaw i jak przetestować każdą z nich?” zapytać.
- Najpierw przetestuj najtańszą hipotezę. Dodaj dziennik, wydrukuj wartość, uruchom test. Czy dowody potwierdzają hipotezę?
- Napraw pierwotną przyczynę, a nie objaw. Zamiast wyciszać objawy za pomocą plastra, zajmij się pierwotną przyczyną.
- Sprawdź i dodaj testy regresyjne. Zobacz, jak błąd zniknie; Następnie napisz test, który wyłapie ten błąd, aby nie wrócił.
Trzy mini etui
Przypadek 1 — Śledzenie stosu doprowadziło do prawidłowego pliku. Aplikacja zwracała błąd 500 w przypadku niektórych żądań. Deweloper przekazał AI śledzenie pełnego stosu i żądanie wyzwalające; W modelu postawiono hipotezę, że przyczyną błędu była wartość Brak w warstwie analizowania daty. Programista dodał dziennik do tej linii, zweryfikował go i rozwiązał w 15 minut; Poprzedniego dnia zmarnowano 2 godziny na niepotwierdzone eksperymenty.
Przypadek 2 — Halucynacje sprowadziły na zły tor. Inny programista po prostu napisał „połączenie z bazą danych zostaje zerwane”. AI oskarżyła o ustawienie puli połączeń bez żadnych dowodów; Programista spędził 40 minut na majstrowaniu przy tym ustawieniu. Prawdziwą przyczyną był przekroczenie limitu czasu po stronie sieci i została ujawniona dopiero po przejrzeniu dzienników. Lekcja: hipoteza przyjęta bez dowodów jest jedynie prawdopodobna, a nie wiarygodna.
Przypadek 3 — wykryto niestabilny błąd. Był test, który czasami kończył się niepowodzeniem. Sztuczna inteligencja otrzymała kod testowy, komunikat o błędzie oraz informację „czasami się udaje, czasem nie”; model wskazał wspólną zależność czasu/kolejności testów. Przegląd potwierdził, że test przeprowadzono w oparciu o czas lokalny systemu. Po naprawieniu zegara (wyśmiewaniu) test stał się stabilny.
Cztery szablony do kopiowania
Generowanie hipotez opartych na dowodach:
Debuguję błąd. Dowody poniżej.- Oczekiwane zachowanie: {{expected}}- Zaobserwowane zachowanie: {{observed}} - Komunikat o błędzie/śledzenie stosu: {{trace}} - Wejście wyzwalające: {{input}} - Środowisko/wersja: {{version}}Wymień 3 NAJBARDZIEJ PRAWDOPODOBNE przyczyny źródłowe, które wyjaśniają ten objaw. Dla każdego: jak przetestować (najtańszy test) i jak to naprawić, jeśli to prawda. Jeśli dowody są niewystarczające, powiedz mi, jakich dodatkowych informacji potrzebujesz.
Interpretacja śladu stosu:
Przeczytaj ten ślad stosu. Rozróżnij, w której linii błąd PRAWDOPODOBNIE zaczyna się (korzeń), a które linie są tylko kontynuacją łańcucha. Zaproponuj 1-2 miejsca, w których warto zajrzeć w pierwszej kolejności. Powiązany kod:{{code}}Trace:{{trace}}
Minimalne odejmowanie reprodukcji:
Poniższy kod generuje błąd. Zmniejsz go do NAJMNIEJSZEJ instancji, która nadal powoduje błąd, ale odrzuca wszystko, co niepotrzebne. Nie zakładaj, że każdy usunięty element nie ma wpływu na błąd, ale dodaj notatkę mówiącą „jeśli błąd zniknie po usunięciu tego, to właśnie dlatego”.{{code}}
Walidacja po korekcji i testy regresyjne:
Załóżmy, że główną przyczyną jest {{przyczyna}} i wprowadzam następującą poprawkę: {{fix}}.1) Czy ta poprawka faktycznie usuwa objaw i czy będzie miała jakieś skutki uboczne?2) Napisz test regresji, który wykryje ten błąd w przyszłości.
Słaba zachęta/silna zachęta
Słaby: „Kod nie działa, dlaczego?”
Mocne: „Węzeł 20/Express. POST /orders zwraca 500, gdy elementy są pustym ciągiem w treści; powinien zwrócić 400. Ślad stosu: TypeError: Nie można odczytać właściwości niezdefiniowanego (czytanie „0”) — w załączeniu pełny ślad i powiązana procedura obsługi. Podaj mi 3 najbardziej prawdopodobne przyczyny wyjaśniające ten symptom i sposób testowania każdej z nich. [ślad + kod]”
Potężna wersja; Podaje środowisko, punkt końcowy, dane wejściowe wyzwalacza, dokładny typ błędu i oczekiwane zachowanie. Model nie może już przewidywać, ale analizować.
krok
wkład AI
twoja kontrola
zbieranie dowodów
Jakie dowody są potrzebne, przypomina
Naprawdę zbiera dowody
generowanie hipotez
Wymień możliwe przyczyny
Priorytetyzuje na podstawie kontekstu
testowanie hipotez
Zaleca metodę testową
Działa i obserwuje osobiście
korekta
patch zaleca
Czy rozwiązuje pierwotną przyczynę? To prawda.
regresja
pisze test
Sprawdza, czy test został uszkodzony
Rozwiązanie pierwotnej przyczyny, a nie objawu
W większości przypadków sztuczna inteligencja zaproponuje łatkę, która szybko wyciszy objaw: dodaj try/catch, zaznacz wartość null i połknij błąd. Czasami jest to prawdą, często niebezpieczną; ponieważ pierwotna przyczyna pozostaje na miejscu i wybucha ponownie z innego miejsca. Przy każdej naprawie zadaj sobie pytanie: „Czy to usuwa przyczynę błędu, czy też sprawia, że staje się on niewidoczny?” Po znalezieniu pierwotnej przyczyny naprawa jest zwykle mniejsza, solidniejsza i trwała.
Przestroga: Ciche przełknięcie wyjątku (pustego catch) nie rozwiązuje błędu; jedynie ukrywa i uniemożliwia przyszłą diagnozę. Jeśli sztuczna inteligencja zasugeruje takie „rozwiązanie”, nie akceptuj go bez kwestionowania pierwotnej przyczyny.
Typowe błędy
- Zadawanie pytań bez dowodów. Zdania dwuznaczne wprawiają modelkę w halucynacje; Podaj pełny błąd, ślad i dane wejściowe.
- Trzymając się pierwszej hipotezy. Pierwsza sugestia sztucznej inteligencji może nie być najbardziej prawdopodobna; Zacznij od najtańszej możliwej do kontrolowania hipotezy.
- Łatanie objawu i pomijanie pierwotnej przyczyny. Wyciszony błąd powraca.
- Zamykanie poprawki bez jej weryfikacji. Zobacz w stanie zbliżonym do produkcyjnego, że błąd faktycznie znika.
- Nie pisanie testów regresyjnych. Jeśli nie zostaną dodane żadne testy, ten sam błąd powróci w późniejszych wersjach.
Podsumowując
Podczas debugowania siła sztucznej inteligencji jest wprost proporcjonalna do dostarczonych przez nią dowodów: bez pełnego komunikatu o błędzie, śledzenia stosu, danych wejściowych wyzwalających i oczekiwanego zachowania model po prostu spekuluje. Zdyscyplinowany przepływ – wyjaśnianie symptomów, zbieranie dowodów, generowanie hipotez, testowanie z najtańszą kontrolą, naprawianie pierwotnej przyczyny, weryfikacja i dodanie testów regresyjnych – szybko i trwale eliminuje błąd. AI jest generatorem hipotez; To Ty decydujesz, że błąd został faktycznie rozwiązany.
Zadanie aplikacji
Wybierz prawdziwy błąd, który ostatnio napotkałeś (lub odtwórz błąd testowy). Najpierw wykonaj krok „minimalna reprodukcja”; Usuń najmniejszy kod i dane wejściowe, które powodują błąd. Następnie uzyskaj 3 możliwe przyczyny i metody testowania od sztucznej inteligencji za pomocą szablonu „generowanie hipotez opartych na dowodach”. Przetestuj samodzielnie najtańszą hipotezę, znajdź przyczynę, napraw ją i na koniec napisz test regresyjny, który wyłapie ten błąd w przyszłości i zweryfikuje, czy test faktycznie jest zepsuty.
lista kontrolna
- [ ] Redukuję błąd do najmniejszej powtarzalnej próbki przed przeniesieniem jej do AI.
- [ ] Do zachęty dodaję pełny komunikat o błędzie, ślad stosu, dane wejściowe i oczekiwane zachowanie.
- [ ] Zaczynam od najtańszego, dającego się kontrolować, bez zamykania się w jednej hipotezie.
- [ ] Sprawdzam, czy rozwiązałem pierwotną przyczynę, zamiast łatać objaw.
- [ ] Zauważyłem, że poprawka faktycznie naprawia błąd.
- [ ] Dodaję test regresji dla każdego rozwiązanego błędu.