Przeglądanie kodu wzmocnione AI w Cursorze

Jest piątkowe popołudnie. Masz sześć pull requestów czekających na przegląd. Dwa są od juniora, który ma tendencję do pomijania obsługi błędów. Jeden to refaktoring 47 plików od seniora, który zajmie godzinę tylko na zrozumienie zakresu. Kolejny dotyka flow płatności i wymaga starannej kontroli bezpieczeństwa. Prędkość twojego zespołu zależy od szybkiego review, ale bezmyślne zatwierdzanie PR-ów prowadzi do incydentów produkcyjnych. Potrzebujesz sposobu na dokładne przeglądanie bez poświęcania całego popołudnia.

Cursor oferuje trzy odrębne mechanizmy przeglądania kodu: Agent Review w IDE, BugBot do automatycznej analizy PR-ów i Cursor CLI do niestandardowych workflow’ów przeglądania w GitHub Actions. Każdy służy innej części pipeline’u przeglądania, a ich połączenie daje pokrycie, którego żadne pojedyncze podejście nie może zapewnić.

Co wyniesiesz

• Workflow używania Agent Review do wstępnej kontroli własnych zmian przed pushowaniem
• Konfigurację BugBot, która wychwytuje prawdziwe problemy bez generowania szumu
• Niestandardowy workflow przeglądania oparty na CLI dla standardów specyficznych dla zespołu
• Prompty do skopiowania i wklejenia do przeglądania skomplikowanych PR-ów, kodu wrażliwego na bezpieczeństwo i dużych refaktorów
• Reguły projektu, które kodują checklistę przeglądania twojego zespołu, aby AI automatycznie ją egzekwowało

Agent Review: kontrola przed lotem dla własnego kodu

Zanim wypchniesz commit, Agent Review pozwala uruchomić analizę Cursora przeciwko twojemu lokalnemu diffowi. To najszybszy sposób na wychwycenie problemów, zanim dotrą do PR-a.

Po wygenerowaniu zmian przez Agenta (lub po posiadaniu niezcommitowanych zmian) kliknij Review w widoku diffa, następnie Find Issues. Agent analizuje twoje zmiany linia po linii i oznacza potencjalne błędy, błędy logiczne i brakujące przypadki brzegowe.

Możesz również przeglądać wszystkie zmiany względem swojego brancha main z zakładki Source Control. Jest to szczególnie przydatne przed otwarciem PR-a — daje checklistę problemów do rozwiązania przed lotem.

Konfiguracja Agent Review

W ustawieniach Cursora możesz włączyć:

• Auto-run on commit: Automatycznie skanuje w poszukiwaniu błędów po każdym commicie
• Include submodules: Przegląda zmiany w submodułach Git
• Include untracked files: Wychwytuje problemy w plikach jeszcze nie dodanych do stage

Włącz auto-run on commit, jeśli chcesz ciągłej informacji zwrotnej z przeglądania. Wyłącz, jeśli wolisz wyzwalać przeglądy ręcznie, aby oszczędzać użycie.

Przeglądanie konkretnych obaw

Czasami chcesz, aby przegląd skupił się na konkretnej kwestii. Użyj czatu Agenta obok diffa:

Wskazówka

Prompt do skopiowania i wklejenia do przeglądania zmian pod kątem bezpieczeństwa:

Przejrzyj mój bieżący git diff pod kątem luk w zabezpieczeniach:

1. Sprawdź SQL injection, XSS i luki CSRF
2. Zweryfikuj, że dane wejściowe użytkownika są walidowane i sanityzowane
3. Upewnij się, że sekrety nie są hardcodowane lub logowane
4. Sprawdź, że uwierzytelnianie i autoryzacja są prawidłowo egzekwowane
5. Szukaj niebezpiecznego deserializowania lub użycia eval
6. Zweryfikuj, że komunikaty błędów nie ujawniają wewnętrznych szczegółów

Oznacz tylko problemy w zmienionych liniach, nie w istniejącym kodzie.

BugBot: zautomatyzowane przeglądy PR-ów

BugBot to zarządzana usługa Cursora do automatycznych przeglądów pull requestów. Włącz ją w swoim panelu Cursora (Settings > BugBot), połącz swoje repozytorium GitHub, a automatycznie przejrzy każdy PR.

BugBot działa inaczej niż prompt ręcznego przeglądu. Używa specjalistycznej analizy dostrojonej do wychwytywania błędów w diffach — nie tylko problemów ze stylem, ale rzeczywistych błędów logicznych, brakujących przypadków brzegowych i potencjalnych regresji.

Dostosowywanie BugBot za pomocą reguł

Prawdziwa moc BugBot pochodzi z połączenia go z regułami projektu. Utwórz plik .cursor/rules/bugbot.md z konkretnymi kryteriami przeglądania twojego zespołu:

.cursor/rules/bugbot.md

# Standardy Code Review

## Zawsze sprawdzaj
- Każdy nowy endpoint API musi mieć walidację wejścia używając Zod
- Zapytania do bazy danych muszą używać parametryzowanych inputów, nigdy konkatenacji stringów
- Obsługa błędów nie może cicho ich pochłaniać (brak pustych bloków catch)
- Nowe komponenty React muszą mieć interfejsy prop TypeScript, nie typy inline
- Funkcje async muszą mieć obsługę błędów try/catch lub .catch()

## Wydajność
- Brak zapytań N+1: jeśli pętla zawiera wywołanie bazy danych, oznacz to
- Brak synchronicznych operacji systemu plików w handlerach requestów
- Obrazy muszą używać lazy loading w kodzie frontendowym

## Testowanie
- Nowe funkcje utility muszą mieć odpowiednie pliki testowe
- Pliki testowe muszą zawierać przynajmniej jeden test przypadku brzegowego
- Mockuj zewnętrzne usługi, nigdy nie uderzaj w prawdziwe API w testach

BugBot konsultuje się z tymi regułami podczas przeglądu, więc jego feedback jest zgodny z rzeczywistymi standardami twojego zespołu, a nie ogólnymi najlepszymi praktykami.

Notatka

Reguły BugBot używają tego samego systemu reguł projektu co tryb Agent. Reguły z zakresem “Always Apply” są uwzględniane w każdym przeglądzie BugBot. Użyj wzorców glob do ograniczenia reguł do konkretnych typów plików — na przykład stosuj bardziej rygorystyczne reguły bezpieczeństwa do plików pasujących do src/api/**/*.ts.

Niestandardowe workflow’y przeglądania oparte na CLI

Dla zespołów, które potrzebują logiki przeglądania wykraczającej poza to, co zapewnia BugBot — sprawdzania zgodności, wymuszania wzorców architektonicznych lub integracji z zewnętrznymi narzędziami — Cursor CLI umożliwia w pełni niestandardowe workflow’y przeglądania w GitHub Actions.

Wskazówka

Prompt do skopiowania i wklejenia do utworzenia niestandardowego GitHub Action przeglądania:

Utwórz workflow GitHub Actions w .github/workflows/code-review.yml, który:

1. Wyzwala się na zdarzeniach pull_request (opened, synchronize, reopened)
2. Instaluje Cursor CLI przez curl https://cursor.com/install
3. Uruchamia agenta, który przegląda diff PR-a używając gh pr diff
4. Oznacza tylko problemy o wysokiej wadze (bezpieczeństwo, błędy logiczne, ryzyko utraty danych)
5. Dodaje komentarze inline do konkretnych zmienionych linii
6. Dodaje komentarz podsumowujący na końcu
7. NIE zatwierdza ani nie żąda zmian -- tylko komentuje
8. Ogranicza do maksymalnie 10 komentarzy inline na przegląd

Użyj .cursor/cli.json, aby odmówić uprawnień Write i git push.
Użyj sekretu CURSOR_API_KEY do uwierzytelniania.

Konfiguracja uprawnień zapewnia, że agent przeglądania może czytać kod i dodawać komentarze, ale nie może modyfikować twojego repozytorium:

.cursor/cli.json

{
  "permissions": {
    "deny": [
      "Shell(git push)",
      "Shell(gh pr create)",
      "Shell(gh pr merge)",
      "Write(**)"
    ]
  }
}

Przeglądanie dużych PR-ów

Duże PR-y to miejsce, gdzie przegląd AI dostarcza największej wartości. Uwaga ludzkiego recenzenta pogarsza się po pierwszych 200 liniach diffa. AI utrzymuje ten sam poziom kontroli przez 2000 linii.

Dla dużych refaktorów podziel przegląd na skoncentrowane podejścia:

@src/services

Ten PR refaktoryzuje warstwę usług z serwisów opartych na klasach na moduły funkcjonalne.
Przejrzyj zmiany w trzech podejściach:

Podejście 1 - Poprawność: Czy nowe implementacje funkcjonalne zachowują to samo
zachowanie co wersje oparte na klasach? Sprawdź typy zwracane, obsługę błędów i
przypadki brzegowe.

Podejście 2 - Powierzchnia API: Czy eksportowane sygnatury funkcji są wstecznie kompatybilne?
Czy konsumenci tych usług będą musieli zaktualizować swoje importy lub wzorce wywołań?

Podejście 3 - Testowanie: Czy istniejące testy nadal mają sens z nową
implementacją? Czy są nowe ścieżki kodu, które nie mają pokrycia testami?

Podsumuj ustalenia dla każdego podejścia osobno.

To uporządkowane podejście zapobiega mieszaniu przez AI obaw i daje jasną checklistę do przejścia.

Przeglądanie pod kątem konkretnych wzorców

Czasami potrzebujesz, aby przegląd wymuszał konkretny wzorzec architektoniczny, a nie ogólne najlepsze praktyki:

Wskazówka

Prompt do skopiowania i wklejenia do przeglądu skoncentrowanego na architekturze:

Przejrzyj ten PR zgodnie z naszymi regułami architektonicznymi:

1. Route'y API nie mogą zawierać logiki biznesowej -- delegują do funkcji serwisowych
2. Funkcje serwisowe nie mogą importować z plików route'ów (brak zależności cyklicznych)
3. Dostęp do bazy danych odbywa się przez warstwę repozytorium, nigdy nie jest wywoływany bezpośrednio z serwisów
4. Komunikacja między serwisami odbywa się przez magistralę zdarzeń, nie bezpośrednie wywołania funkcji
5. Komponenty React nie mogą wywoływać endpointów API bezpośrednio -- używaj niestandardowych hooków

Dla każdego naruszenia pokaż plik, numer linii i sugerowaną poprawkę.

Budowanie kultury przeglądania z AI

Najbardziej efektywne zespoły używają przeglądu AI jako pierwszego podejścia, nie jako zamiennika ludzkiego przeglądu. Oto workflow, który działa:

1. Autor uruchamia Agent Review lokalnie przed pushowaniem. Naprawia oczywiste problemy, zanim PR w ogóle zostanie utworzony.
2. BugBot przegląda PR automatycznie, gdy zostanie otwarty. Wychwytuje błędy, brakujące testy i problemy z bezpieczeństwem.
3. Ludzki recenzent skupia się na architekturze, decyzjach projektowych i logice biznesowej — rzeczach, do oceny których AI jest mniej przystosowane.
4. Autor zajmuje się feedbackiem zarówno od AI, jak i ludzkiego recenzenta. Dla feedbacku AI mogą poprosić tryb Agent o bezpośrednie zaimplementowanie poprawki.

Ten pipeline oznacza, że ludzcy recenzenci spędzają czas na wartościowym feedbacku zamiast wychwytywania literówek, brakujących sprawdzeń null lub niespójnej obsługi błędów.

Gdy to się psuje

BugBot generuje zbyt wiele fałszywych alarmów. Zwykle oznacza to, że reguły twojego projektu są zbyt szerokie lub sprzeczne. Zawęź je: zamiast “wszystkie funkcje muszą mieć obsługę błędów” powiedz “funkcje async w src/api/ muszą owijać swoje ciało w try/catch.” Konkretne reguły produkują konkretny feedback.

Agent Review pomija oczywiste błędy. Przegląd jest tylko tak dobry, jak model i dostępny kontekst. Dla skomplikowanej logiki pytaj bezpośrednio: “Czy jest przypadek, w którym ta funkcja zwraca undefined zamiast rzucać?” Celowane pytania dają lepsze odpowiedzi niż otwarte “przejrzyj ten kod.”

Workflow przeglądania CLI dodaje duplikujące się komentarze. Jeśli twój workflow wyzwala się na zdarzeniach synchronize (nowe commity wypchnięte do PR-a), przegląda cały diff ponownie. Dołącz logikę w prompcie agenta do sprawdzania istniejących komentarzy: “Przed dodaniem komentarza sprawdź, czy podobny feedback już istnieje na pobliskich liniach używając gh pr view —json comments.”

Przegląd trwa zbyt długo i blokuje PR-a. Ustaw timeout na swoim jobie GitHub Actions (10 minut jest zazwyczaj wystarczające). Jeśli przegląd konsekwentnie się przekracza, zmniejsz zakres: przeglądaj tylko zmienione pliki, nie całą bazę kodu.

Co dalej

Pair Programming Użyj Cursora jako współpracownika w czasie rzeczywistym, nie tylko recenzenta.

Pipeline'y CI/CD Zintegruj swój workflow przeglądania w kompletny pipeline CI/CD.

Testowanie i TDD Generuj kompleksowe testy obok swojego workflow przeglądania.