Debugowanie z AI: prompty, które znajdą przyczynę

Debugowanie z AI działa najlepiej, gdy dajesz modelowi to samo, co dostałby kolega przy twoim biurku: cały błąd, kod, który go wywołał, czego się spodziewasz, co dzieje się zamiast tego i co już wykluczasz. Model nie może uruchomić twojego programu ani zobaczyć twoich danych, więc wszystko, co wie o błędzie, pochodzi z tego, co wkleisz. Najbardziej przydatny pojedynczy nawyk to prośba o przyczynę, zanim poprosisz o poprawkę.

Wklej wszystko, nie tylko błąd

Obie poniższe zakładki opisują ten sam błąd. Skrypt czyta plik CSV wyeksportowany z Excela i kończy się KeyError: 'email', choć plik wyraźnie ma kolumnę email.

Sam błądPełny opis

EditCopy

Napraw to: KeyError: 'email'

Try it

Example replyReplies vary between models and runs.

KeyError oznacza, że słownik nie ma klucza 'email'. Możesz uniknąć błędu, używając .get(), które zwraca None, zamiast zgłaszać wyjątek:

email = row.get("email")

Albo najpierw sprawdź:

if "email" in row:
    email = row["email"]

Pierwsza odpowiedź poprawnie wyjaśnia, czym jest KeyError, ale jej rada w tym przypadku szkodzi. Z row.get("email") awaria znika, a każdy e-mail zmienia się w None. Model odpowiedział na najczęstszą wersję błędu, bo tylko ją opisywał prompt.

Pełny opis zadziałał dzięki dwóm liniom. "Zawodzi tylko pierwsza kolumna" i "zapisany z Excela jako CSV UTF-8" to wskazówki prowadzące do znacznika kolejności bajtów i żadnej z nich nie ma w komunikacie błędu. Rzadko wiadomo, który ze szczegółów jest wskazówką, i właśnie dlatego wkleja się wszystkie.

Pięć rzeczy, które trzeba dołączyć

1. Pełny błąd. Cały traceback albo wynik z konsoli, a nie jego parafrazę. Numery linii i łańcuch wywołań pokazują, gdzie zaczęła się awaria, a to często kilka ramek od miejsca, w którym wyszła na wierzch.
2. Kod, który go wywołał. Funkcję, która zawodzi, i kod, który ją wywołuje. Jeśli błąd wspomina linię, upewnij się, że ta linia jest w tym, co wklejasz.
3. Oczekiwane a faktyczne. Po jednym zdaniu. Przy błędach bez żadnego komunikatu (zły wynik, pusta strona, wolne zapytanie) to jest cały opis błędu.
4. Twoje środowisko. Wersję języka, system operacyjny, framework i wersje bibliotek, gdy mogą mieć znaczenie. Błędy kodowania znaków, ścieżek i dat często zależą od platformy.
5. Co już próbujesz. To powstrzymuje model przed ponownym proponowaniem tego samego, a wynik każdej próby jest dowodem. "Usunięcie części z e-mailem sprawia, że działa" zawęziło błąd z CSV do jednej kolumny.

Poproś o przyczynę przed poprawką

Prośba o poprawkę zachęca model do zmieniania kodu, aż błąd zniknie. Prośba o przyczynę każe mu rozumować, dlaczego błąd występuje, a poprawka z tego wynika. Poproś o krótką uszeregowaną listę przyczyn ze sposobem sprawdzenia każdej, a potem sam wykonaj te sprawdzenia. Ten szablon robi właśnie to:

Uszereguj przyczyny, jeszcze bez poprawki

EditCopy

Fill injęzykoczekiwanefaktyczne

PartsTaskContextInputFormat

Task

Pomóż mi znaleźć przyczynę błędu w moim kodzie w JavaScript. Nie pisz jeszcze poprawki.

Context

Oczekiwane: lista użytkowników pojawia się po załadowaniu strony Faktyczne: pusta strona i ten błąd w konsoli przeglądarki

Input

TypeError: Cannot read properties of undefined (reading 'map')function UserList() { const [users, setUsers] = useState(); useEffect(() => { fetch("/api/users") .then((res) => res.json()) .then((data) => setUsers(data)); }, []); return ( <ul> {users.map((u) => ( <li key={u.id}>{u.name}</li> ))} </ul> ); }

Format

Wypisz maksymalnie trzy prawdopodobne przyczyny, od najbardziej prawdopodobnej. Dla każdej podaj jednolinijkowe sprawdzenie, które mogę uruchomić, żeby ją potwierdzić albo wykluczyć.

Try it

Example replyReplies vary between models and runs.

1. Komponent renderuje się, zanim pojawią się jakiekolwiek dane. useState() zaczyna od undefined, a React renderuje komponent raz, zanim uruchomi efekt, więc users.map jest wywoływane na undefined. Już to samo daje dokładnie twój błąd, przy każdym ładowaniu. Sprawdzenie: dodaj console.log(users) tuż przed return. Jeśli wypisze undefined, a zaraz potem pojawi się błąd, to jest to.
2. API zwraca coś innego niż tablicę. Gdyby zwracało obiekt w rodzaju { users: [...] }, błąd byłby inny (users.map is not a function), więc to nie jest wklejony przez ciebie błąd. Może to jednak być kolejny problem, gdy przyczyna 1 zostanie naprawiona. Sprawdzenie: console.log(data) w drugim .then.
3. Zapytanie się nie udaje. Na razie bez znaczenia: ponieważ pierwszy render rzuca wyjątek, React nigdy nie uruchamia efektu, więc zapytanie nawet nie jest wysyłane. Sprawdzenie: zakładka Network nie pokazuje żadnego zapytania /api/users, co przy okazji potwierdza przyczynę 1.

Odpowiedź robi coś, co pomija odpowiedź zaczynająca od poprawki: wyklucza przyczyny, bo błąd, który by dały, różni się od wklejonego, albo dlatego, że kod nigdy nie dochodzi do miejsca, w którym mogłyby wystąpić. Z tego samego powodu ważny jest dokładny tekst błędu. Prośba, żeby model wypisał przyczyny przed odpowiedzią, to lekka forma chain-of-thought prompting: najpierw jest rozumowanie, a wniosek się na nim opiera.

Zrób minimalną reprodukcję

Minimalna reprodukcja to najmniejszy program, który nadal pokazuje błąd: dane wpisane na sztywno zamiast wywołania bazy danych, jedna funkcja zamiast całego modułu. Jej budowanie często pozwala znaleźć błąd, zanim o cokolwiek zapytasz, bo każdy usunięty element albo zostawia błąd (nie miał z nim związku), albo sprawia, że znika (miał). Gdy tak się nie stanie, reprodukcja jest idealnym promptem: na tyle krótkim, że model przeczyta każdą linię, i wolnym od niezwiązanego kodu, który mógłby go wysłać w pogoń za złym problemem.

Jeśli błąd zależy od danych, dołącz kilka wierszy, które go wywołują. Model potrafi rozumować o [{"id": 1, "name": null}]; nie potrafi rozumować o "niektórych wierszach na produkcji".

Gdy poprawki przestają działać

Jeśli trzecia poprawka od modelu zawodzi w ten sam sposób, czwarta prośba o poprawkę raczej nie da nic lepszego. Bardziej pomagają dwie rzeczy:

• Daj mu nowe dowody. Dodaj linię z print albo logiem, która pokazuje faktyczne wartości w miejscu awarii, uruchom ją i wklej wynik. Dowody, które przeczą teorii modelu, to najszybsza droga do lepszej.
• Zacznij nową rozmowę. Długie wątki debugowania zapełniają się porzuconymi teoriami i starymi wersjami kodu, a model może dalej na nich budować. Nowy czat z aktualnym kodem, błędem, dowodami i linią "już wykluczone: X i Y" często zachodzi dalej w jednej odpowiedzi.

Uważaj na pewne siebie odpowiedzi o działaniu bibliotek. Model może opisać opcję albo funkcję, która nie istnieje; jak to sprawdzić, opisują halucynacje AI. Gdy kod nie jest zepsuty, ale nie rozumiesz, dlaczego robi to, co robi, lepszym narzędziem jest prompt do wyjaśniania kodu.