Pakiet promptów do kodowania z Claude: debugowanie, refaktoryzacja, architektura

Cztery zasady, dzięki którym działa każdy z poniższych promptów

Zanim przejdziemy do promptów, oto zasady wspólne dla wszystkich. Dodanie ich do dowolnego promptu do kodowania poprawia wynik bardziej niż zmiana modelu.

Podaj swoją wersję. Dane treningowe są przechylone w stronę tej głównej wersji, o której napisano najwięcej, a często nie jest to wersja, której używasz. Używamy [framework] [wersja], [język] [wersja] zapobiega większości nieaktualnych odpowiedzi.

Ogranicz zakres zmian. Poproś o poprawkę, a często dostaniesz refaktoryzację. Zmień jak najmniej, zachowaj istniejącą strukturę i nazewnictwo, i wypisz każdą zmienioną linię z jednozdaniowym uzasadnieniem to najbardziej przydatne zdanie w tym dokumencie.

Poproś o hipotezy przed rozwiązaniami. Model zapytany, co jest nie tak, daje ci domysł podany jako wniosek. Model zapytany o uszeregowane przyczyny i tanie sposoby ich sprawdzenia daje ci plan debugowania.

Wymagaj określenia trybu awarii. Co to może zepsuć i czy to naprawia przyczynę, czy objaw? wychwytuje najbardziej kosztowną klasę pomocy AI, czyli zmianę, która sprawia, że objaw znika, podczas gdy defekt pozostaje.

Debugowanie

1. Uszeregowane hipotezy

Oto błąd, odpowiedni kod i to, co już wykluczyłem. Nie podawaj mi jeszcze poprawki. Wypisz cztery najbardziej prawdopodobne przyczyny uszeregowane według prawdopodobieństwa, a dla każdej najtańszy sposób sprawdzenia, który ją potwierdzi lub wykluczy. Błąd: [wklej]. Kod: [wklej]. Już wykluczone: [lista]. Stos: [język, framework, wersje].

2. Sporadyczny błąd

To zawodzi sporadycznie, mniej więcej [częstotliwość], w warunkach [warunki]. Wymień kategorie sporadycznych błędów, które mogłyby wywołać ten konkretny objaw: czasowanie, kolejność, wyczerpanie zasobów, zależność zewnętrzna, wyciek stanu między uruchomieniami, zegar lub strefa czasowa, cache. Dla każdej powiedz, co w kodzie ją potwierdza lub jej przeczy, i co dokładnie powinienem logować, by je rozróżnić. Kod: [wklej].

3. Działa lokalnie

To działa lokalnie, a zawodzi w [środowisko]. Wypisz każdą kategorię różnic środowiskowych, które mogłyby powodować ten konkretny objaw: konfiguracja, zmienne środowiskowe, wersje, system plików i wielkość liter, strefa czasowa i lokalizacja, sieć i DNS, uprawnienia, limity zasobów oraz różnice w budowaniu lub bundlowaniu. Uszereguj według prawdopodobieństwa w kontekście objawu i podaj polecenie diagnostyczne dla każdej z nich.

4. Wyjaśnij poprawkę, zanim ją zastosuję

Wyjaśnij, dlaczego ta poprawka działa, czego nie naprawia i co może zepsuć. Jeśli prawdziwa przyczyna leży gdzie indziej, a to jest tylko łatanie objawu, powiedz to wprost.

Code review

5. Przejrzyj diff

Przejrzyj ten diff jako wymagający recenzent. Kategorie w kolejności priorytetu: błędy poprawności, kwestie bezpieczeństwa, nieobsłużone tryby awarii, wyścigi (race conditions), a na końcu styl. Dla każdego znaleziska podaj wagę, konkretną linię i dlaczego ma to znaczenie w tej bazie kodu, a nie ogólnie. Nie komentuj formatowania. Jeśli diff jest solidny, powiedz to zamiast wymyślać zastrzeżenia. Konwencje: [opisz]. Diff: [wklej].

6. Przegląd bezpieczeństwa

Przejrzyj ten kod pod kątem konkretnie kwestii bezpieczeństwa: wstrzykiwanie kodu, luki w uwierzytelnianiu i autoryzacji, niebezpieczna deserializacja, sekrety w kodzie lub logach, niewalidowane dane wejściowe docierające do wrażliwej operacji oraz ryzyko związane z zależnościami. Dla każdej podaj konkretną ścieżkę ataku, a nie tylko nazwę kategorii. Powiedz jasno, czego nie możesz ocenić bez wglądu w [wdrożenie, warstwę uwierzytelniania, wrażliwość danych].

7. Audyt trybów awarii

Dla każdego zewnętrznego wywołania w tym kodzie podaj, co się dzieje, gdy jest wolne, gdy zawodzi, gdy zwraca nieoczekiwane dane i gdy kończy się sukcesem tylko częściowo. Które z tych przypadków są obecnie nieobsłużone, a które byłyby ciche?

Ten ostatni prompt wykrywa więcej realnych problemów produkcyjnych niż zwykły przegląd, bo pyta o ścieżki, dla których nikt nie napisał testu.

Refaktoryzacja i architektura

8. Plan refaktoryzacji

Zaproponuj etapowy plan refaktoryzacji [opis]. Ograniczenia: publiczne API [x] nie może się zmienić, wdrażamy ciągle, więc każdy krok musi dać się wdrożyć niezależnie, a testy muszą przechodzić po każdym kroku. Dla każdego kroku podaj zmianę, ryzyko, sposób weryfikacji i sposób wycofania. Uszereguj według ryzyka, od najniższego. Nie pisz jeszcze kodu.

9. Argumentuj za drugą stroną

Wybieram [podejście A] zamiast [podejścia B] w kontekście [kontekst i ograniczenia]. Przedstaw najmocniejsze argumenty za B. Co musiałoby być prawdą co do naszych ograniczeń, żeby B było słuszne, i czy cokolwiek z tego jest tu prawdą? Nie wyciągaj wniosku, że oba są słuszne.

10. Zrozum, co odziedziczyłeś

Oto główne pliki źródłowe. Podaj: punkty wejścia, przepływ danych od żądania do odpowiedzi, stan, który jest współdzielony i miejsca, gdzie jest modyfikowany, zewnętrzne zależności i co się dzieje, gdy każda z nich jest niedostępna, oraz trzy obszary najbardziej narażone na błędy na podstawie złożoności i powiązań. Podaj wprost, czego nie możesz ustalić na podstawie tego, co dostarczyłem.

To ostatnie polecenie ma znaczenie. Modele opisują zachowanie pliku, którego nie wkleiłeś, wnioskując je z nazwy. Wymuszenie jawnej listy niewiadomych mówi ci, co powinieneś jeszcze przeczytać.

Testy

11. Testy, których byś nie napisał

Napisz przypadki testowe dla tej funkcji, koncentrując się na danych wejściowych, których prawdopodobnie nie uwzględniłem: wartości graniczne, puste i null, unicode, bardzo duże wartości, wywołania równoległe i wszelkie ukryte założenia w implementacji. Dla każdego testu podaj założenie, które sprawdza. Funkcja: [wklej].

12. Przetestuj zestaw testów

Oto funkcja i jej istniejące testy. Jakie zachowanie nie jest pokryte? Konkretnie: ścieżki błędów, wartości graniczne, interakcje między parametrami i wszystko, co robi implementacja, a czego żaden test nie sprawdza. Nie przepisuj istniejących testów.

Ten drugi jest bardziej wartościowym promptem i rzadko jest używany. Procent pokrycia mówi ci, które linie zostały wykonane, a nie które zachowania są faktycznie zabezpieczone, a to właśnie w tej luce żyją regresje.

Wzorzec drugiej opinii

Najbardziej opłacalny nawyk w całym tym pakiecie i jedyny, który wymaga więcej niż jednego modelu.

Uzyskaj odpowiedź od jednego modelu. Potem przełącz się i przekaż ją dalej:

Inny inżynier zaproponował to rozwiązanie tego problemu. Znajdź, co jest w nim nie tak: poprawność w przypadkach brzegowych, współbieżność, obsługa błędów, wydajność przy [skala], lub prostsze podejście, które zostało pominięte. Jeśli jest naprawdę solidne, powiedz to wprost, zamiast wymyślać zastrzeżenia. Problem: [wklej]. Proponowane rozwiązanie: [wklej].

Są dwa możliwe wyniki i oba są przydatne. Albo drugi model znajduje prawdziwą lukę, o której wiesz teraz, przed scaleniem, albo zgadza się mimo nakłaniania go do sprzeciwu, co jest znaczącym potwierdzeniem. Iterowanie z tym samym modelem nie daje ci ani jednego, ani drugiego, bo model recenzujący własny wynik zwykle zgadza się sam ze sobą.

Używaj go przy decyzjach, których błąd byłby kosztowny: zmiana schematu, poprawka współbieżności, cokolwiek dotykające uwierzytelniania lub pieniędzy. Nie przy rutynowej pracy. Zobacz porównanie modeli obok siebie, przełączanie modeli w trakcie rozmowy oraz pisanie i debugowanie kodu z wieloma modelami, gdzie znajdziesz cały ten workflow w jednym miejscu.

Na co uważać

Wymyślone API. Pewne siebie nazwy metod, parametry i klucze konfiguracji, które nie istnieją, zwłaszcza dla bibliotek, które ostatnio się zmieniły. Sygnatura będzie wyglądać poprawnie. Sprawdź prawdziwą dokumentację, zanim zbudujesz coś na nieznanym elemencie.

Brak sygnału pewności. Poprawna poprawka i subtelnie błędna przychodzą z identyczną pewnością siebie. Ton niczego ci nie mówi.

Ciche rozszerzanie zakresu. Po to właśnie istnieje druga zasada.

Teatr bezpieczeństwa. Nazywanie klas podatności w twoim kodzie to użyteczny pierwszy krok. To nie jest audyt, a model nie zna twojego modelu zagrożeń, wdrożenia ani wrażliwości danych.

Trzymaj prompty, których używasz co tydzień, w miejscu, z którego możesz je wklejać, a stałe ograniczenia umieść w instrukcjach projektu, żeby stosowały się automatycznie do każdego czatu w tym projekcie.