Przejdź do głównej zawartości
Developer Toolkit Developer Toolkit Developer Toolkit

Programowanie sterowane błędami

Twój pipeline CI świeci na czerwono. Jest 14 błędów TypeScript, 3 nieudane testy i ostrzeżenie o deprecjacji. Twój instynkt podpowiada, żeby naprawić je samodzielnie albo wkleić cały log błędów do AI i powiedzieć “napraw wszystko”. Oba podejścia marnują czas. Naprawianie samodzielnie ignoruje zdolność AI do rozwiązywania mechanicznych problemów. Zrzucanie całego logu daje AI zbyt wiele do przetworzenia na raz i prowadzi do kaskadowych “napraw”, które wprowadzają nowe problemy.

Programowanie sterowane błędami traktuje każdy błąd jako precyzyjną, wygenerowaną maszynowo specyfikację. Komunikat błędu mówi AI dokładnie co jest źle, gdzie jest źle i czego system oczekuje zamiast tego. To lepsza informacja niż jakikolwiek prompt, który mógłbyś napisać od zera.

Czego się nauczysz

Dział zatytułowany „Czego się nauczysz”
  • Systematyczny przepływ pracy do przekazywania błędów asystentowi AI po jednym na raz
  • Prompty, które wyciągają maksymalny sygnał z komunikatów błędów
  • Strategie przerywania kaskad błędów (gdy naprawienie jednego błędu tworzy trzy nowe)
  • Techniki wykorzystywania błędów jako okazji do nauki, które ulepszają twój CLAUDE.md, .cursor/rules i AGENTS.md

Pętla sterowana błędami

Dział zatytułowany „Pętla sterowana błędami”

Zamiast próbować zapobiec wszystkim błędom, wykorzystujesz je jako najszybszy dostępny mechanizm sprzężenia zwrotnego. Pętla jest prosta:

  1. Wprowadź zmianę (lub pozwól AI ją wprowadzić)
  2. Uruchom krok weryfikacji (build, test, lint, type-check)
  3. Przeczytaj pierwszy błąd
  4. Przekaż go AI z docelowym kontekstem
  5. Pozwól AI naprawić przyczynę źródłową
  6. Powtórz od kroku 2

Kluczowa dyscyplina to jeden błąd na raz. Komunikaty błędów często kaskadują — jedna przyczyna źródłowa produkuje dziesiątki dalszych błędów. Napraw pierwszy, a połowa pozostałych zniknie.

Przekazywanie błędów do AI

Dział zatytułowany „Przekazywanie błędów do AI”

Jakość naprawy zależy całkowicie od tego, jak prezentujesz błąd. Nie mów po prostu “build jest zepsuty”. Daj AI dokładny komunikat błędu, plik, w którym wystąpił, i to, czego się spodziewałeś.

Zintegrowany terminal Cursor sprawia, że programowanie sterowane błędami jest bezproblemowe. Uruchom build lub testy bezpośrednio w terminalu, a następnie odwołaj się do błędu w trybie Agent:

I ran npm run type-check and got this error:


src/services/notification.ts:42:5 - error TS2345:
Argument of type 'string' is not assignable to parameter
of type 'NotificationPayload'.


Fix the root cause. The function signature in @src/services/notification.ts
expects a NotificationPayload object, not a raw string. Check the caller
at line 42 and the type definition in @src/types/notification.ts.

Agent Cursor może również czytać wyjście terminala bezpośrednio. Po nieudanej komendzie po prostu wpisz w czacie: “Fix the error in the terminal.”

Przerywanie kaskad błędów

Dział zatytułowany „Przerywanie kaskad błędów”

Częsta pułapka: AI naprawia błąd 1, co wprowadza błąd 2, który po naprawieniu wprowadza błąd 3. Kończysz w cyklu “wack-a-mole”, który wypala twoje okno kontekstowe bez robienia postępu.

Rozwiązaniem jest rozpoznanie wzorców kaskadowych i zaadresowanie ich strukturalnie.

Gdy widzisz ten sam plik pojawiający się w wielu błędach, cofnij się:

We've been fixing errors in notification.ts for three iterations
and new ones keep appearing. Stop fixing individual errors.


Instead:
1. Read the full file @src/services/notification.ts
2. Read the types it depends on @src/types/notification.ts
3. Read the test file @src/services/__tests__/notification.test.ts
4. Identify the structural problem causing the cascade
5. Propose a fix for the root architectural issue


Do not modify any files until I approve the approach.

Zamiana błędów w trwałą wiedzę

Dział zatytułowany „Zamiana błędów w trwałą wiedzę”

Najcenniejsze błędy to te, których nigdy więcej nie zobaczysz. Gdy napotkasz nieoczywisty błąd, zapisz lekcję w konfiguracji projektu, aby AI unikał tego samego błędu w przyszłych sesjach.

Dodaj regułę projektu w .cursor/rules/errors.md:

---
description: "Common errors and their fixes for this project"
alwaysApply: true
---


## Known Error Patterns


- When modifying notification types, always update both
  `src/types/notification.ts` AND the Zod schema in
  `src/validators/notification.ts`. They must stay in sync.
- Redis connection errors in tests: run `docker compose up -d redis`
  before running the test suite.

Kiedy to nie działa

Dział zatytułowany „Kiedy to nie działa”

Komunikat błędu jest bezużyteczny. Niektóre komunikaty błędów są naprawdę nieprzejrzyste (segfaulty, generyczne “internal server error”). W takich przypadkach przełącz się z podejścia sterowanego błędami na podejście sterowane hipotezami: poproś AI o dodanie logowania, odtworzenie problemu i zawężenie przyczyny przez eliminację.

AI ciągle tłumi błędy zamiast je naprawiać. Jeśli widzisz @ts-ignore, as any, puste bloki catch lub eslint-disable w wyjściu AI, to tłumi objawy zamiast naprawiać przyczyny. Bądź bezpośredni: “Do not suppress errors. Fix the underlying issue.”

Zbyt wiele błędów do przetworzenia. Jeśli type-check produkuje 200+ błędów, nie podawaj ich wszystkich AI. Skup się na pierwszych 3-5 błędach — to zwykle przyczyny źródłowe, które produkują resztę. Po ich naprawieniu uruchom ponownie i sprawdź, ile pozostało.

Błąd jest w wygenerowanym kodzie. Gdy błąd jest w pliku, który AI wygenerowało od zera, często szybciej jest usunąć plik i wygenerować go ponownie z bardziej ograniczonym promptem, niż łatać istniejącą zepsutą wersję.

Co dalej

Dział zatytułowany „Co dalej”
Programowanie sterowane testami Połącz TDD z programowaniem sterowanym błędami dla najszybszej drogi do poprawnego kodu.
Ciągła dostawa Dostarczaj bezbłędne zmiany przyrostowo zamiast gromadzić ryzyko.
Wzorce pamięci Przechowuj wzorce błędów na stałe, aby AI uczył się z przeszłych pomyłek.
Polityka prywatności Regulamin