Zaawansowane techniki: Wskazówki 91-105

Opanowałeś tryb agent, twoje zasady projektu są dopracowane i obsługujesz duże bazy kodu bez wysiłku. Ale wciąż brakuje ci funkcji, które przekształcają Cursor ze sprytnego edytora w platformę programistyczną: serwery MCP, które łączą AI z twoją infrastrukturą, agenci w tle, którzy pracują, gdy ty śpisz, i automatyzacje niestandardowe, które eliminują całe kategorie powtarzalnej pracy. Tych 15 wskazówek jest dla programistów, którzy chcą przesuwać każdą granicę.

Z czym odejdziesz

• Konfigurację serwera MCP, która łączy Cursor z twoją bazą danych, zarządzaniem projektem i pipeline’m CI/CD
• Przepływy pracy agenta w tle dla zadań, które działają asynchronicznie
• Wzorce automatyzacji niestandardowej, które eliminują powtarzalne zadania programistyczne
• Bug Finder i przepływy pracy przeglądu kodu, które wychwytują problemy, zanim zobaczą je członkowie twojego zespołu
• Strategie równoważenia kosztów modelu z jakością wyjścia

Serwery MCP: Rozszerzanie zasięgu agenta

Wskazówka 91: Zrozum, co faktycznie robią serwery MCP

Model Context Protocol (MCP) daje agentowi narzędzia wykraczające poza czytanie plików i uruchamianie poleceń terminala. Bez MCP agent jest ograniczony do tego, co jest w twoim systemie plików. Z MCP może:

• Zapytać twoją produkcyjną bazę danych bezpośrednio
• Czytać i aktualizować zadania Jira/Linear
• Pobierać projekty z Figma
• Sprawdzać status wdrożenia w twoim pipeline’ie CI/CD
• Uzyskać dostęp do DevTools przeglądarki w celu debugowania

Ważny model mentalny: serwery MCP nie są wtyczkami ani rozszerzeniami. Są dostawcami narzędzi, które AI może wywoływać podczas rozmowy. Agent decyduje, kiedy ich użyć na podstawie twojego promptu, tak jak decyduje, kiedy przeczytać plik lub uruchomić polecenie.

Wskazówka 92: Skonfiguruj niezbędne serwery MCP

Skonfiguruj serwery MCP, które mają największy wpływ dla większości przepływów pracy programistycznych:

// .cursor/mcp.json (poziom projektu)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    }
  }
}

Włączaj serwery MCP na żądanie

Każdy włączony serwer MCP dodaje się do kontekstu, który przetwarza agent. Jeśli masz 10 włączonych serwerów MCP, agent zużywa tokeny na ustalenie, które narzędzia są dostępne, zanim jeszcze rozpocznie twoje zadanie. Włączaj tylko serwery istotne dla twojej bieżącej pracy.

Wskazówka 93: Użyj MCP bazy danych do programowania świadomego schematu

Z podłączonym serwerem MCP PostgreSQL lub MySQL agent może zapytać twój rzeczywisty schemat bazy danych zamiast zgadywać:

Skopiuj i wklej prompt świadomy bazy danych

Używając połączenia z bazą danych, sprawdź obecny schemat dla tabeli “users”. Następnie utwórz nową migrację Drizzle ORM, która dodaje kolumnę “organization_id” jako klucz obcy do tabeli “organizations”, z wartością domyślną null dla istniejących wierszy.

Po utworzeniu migracji zweryfikuj ją, uruchamiając migrację względem bazy deweloperskiej i zapytując zaktualizowany schemat.

To eliminuje kategorię błędów, gdzie agent generuje migrację, która nie pasuje do rzeczywistego stanu bazy danych.

Wskazówka 94: Połącz MCP Figma dla przepływów pracy design-to-code

Z serwerem MCP Figma agent może pobrać rzeczywiste tokeny designu, specyfikacje komponentów i informacje o układzie z twoich plików Figma:

Spójrz na stronę "Dashboard" w naszym projekcie Figma. Wyodrębnij design komponentu karty -- jego odstępy, kolory, typografię i układ. Następnie zaimplementuj go używając naszych istniejących klas Tailwind i wzorców komponentów React z @src/components/.

To daje znacznie lepsze wyniki niż wklejanie zrzutu ekranu, ponieważ agent otrzymuje dokładne wartości (padding: 24px, nie “jakiś padding”) i tokeny kolorów (rzeczywiste wartości hex twojego systemu designu, nie przybliżenia).

Wskazówka 95: Użyj MCP Atlassian do programowania kierowanego zadaniami

Połącz Jira lub Linear, aby pozwolić agentowi czytać zadania i aktualizować status:

Skopiuj i wklej prompt programowania kierowanego zadaniami

Przeczytaj wymagania z zadania JIRA PROJ-1234. Zaimplementuj funkcję opisaną w zadaniu, postępując zgodnie z kryteriami akceptacji. Po implementacji zaktualizuj status zadania na “In Review” i dodaj komentarz z podsumowaniem zmian.

To zamyka pętlę między zarządzaniem projektem a rozwojem. Agent czyta zadanie, implementuje funkcję i aktualizuje zadanie — wszystko w jednej rozmowie.

Agenci w tle

Wskazówka 96: Używaj agentów w tle do długotrwałych zadań

Agenci w tle działają w infrastrukturze chmurowej Cursor. Nie musisz trzymać otwartego edytora. Uruchom agenta w tle dla:

• Generowania pokrycia testowego w całym module
• Implementacji funkcji z opisu problemu GitHub
• Refaktoryzacji dużego katalogu, aby podążał za nowym wzorcem
• Tworzenia dokumentacji dla nieudokumentowanej bazy kodu

Agent w tle tworzy gałąź i otwiera PR, gdy kończy. Przeglądasz PR jak każdą inną zmianę kodu.

Wskazówka 97: Pisz jasne specyfikacje dla agentów w tle

Agenci w tle nie mogą zadawać pytań wyjaśniających. Twój prompt musi być samowystarczalny:

Skopiuj i wklej specyfikację agenta w tle

Rozgałęź się od main. Utwórz kompleksowe testy vitest dla każdej eksportowanej funkcji w src/services/payment.ts.

Wymagania:

• Testuj ścieżki pozytywne z realistycznymi danymi
• Testuj przypadki błędów (awarie sieci, nieprawidłowe dane wejściowe, brakujące wymagane pola)
• Testuj przypadki brzegowe (zerowe kwoty, maksymalne kwoty, współbieżne żądania)
• Mockuj zewnętrzne zależności (Stripe SDK, zapytania do bazy danych) używając mocków vitest
• Dąż do 90% pokrycia kodu w pliku
• Podążaj za wzorcami testów ustalonymi w src/services/tests/user.test.ts

Po napisaniu testów uruchom je, aby zweryfikować, że przechodzą. Napraw wszelkie błędy. Otwórz PR zatytułowany “test: add payment service test coverage” z podsumowaniem dodanych przypadków testowych.

Im bardziej szczegółowy prompt, tym lepsze wyjście. Uwzględnij wzorce do naśladowania, narzędzia do użycia i oczekiwany format wyjścia.

Wskazówka 98: Przypisuj agentów w tle z problemów GitHub

Gdy problem GitHub ma jasne wymagania, przypisz go bezpośrednio agentowi w tle. Działa to najlepiej dla:

• Poprawek błędów z jasnymi krokami reprodukcji
• Małych dodatków funkcji o dobrze zdefiniowanym zakresie
• Aktualizacji dokumentacji
• Aktualizacji zależności z przewodnikami migracji

Agent w tle czyta problem, implementuje rozwiązanie i otwiera PR odwołujący się do problemu. Twoja rola zmienia się z implementatora na recenzenta.

Automatyzacje niestandardowe

Wskazówka 99: Zbuduj plik promptu automatyzacji “Pre-PR”

Zapisz listę kontrolną pre-PR swojego zespołu jako plik promptu i używaj go dla każdego PR:

.cursor/prompts/pre-pr.md

# Lista kontrolna Pre-PR

Uruchom każdy krok i napraw wszelkie problemy przed przejściem do następnego:

1. pnpm run typecheck -- napraw wszystkie błędy TypeScript
2. pnpm run lint -- napraw wszystkie problemy lintingu (nie dodawaj komentarzy eslint-disable)
3. pnpm run test -- napraw błędy testów modyfikując kod źródłowy, nie asercje testowe
4. Sprawdź instrukcje console.log/console.debug -- usuń te, które nie są celowe
5. Sprawdź komentarze TODO, które powinny być rozwiązane w tym PR
6. Zweryfikuj, że wszystkie nowe pliki mają właściwe importy i eksporty
7. Uruchom pnpm run build, aby zweryfikować, że build produkcyjny się udaje

Po przejściu wszystkich kroków podsumuj, co zostało naprawione.

Odwołaj się do niego z @.cursor/prompts/pre-pr.md na końcu każdej sesji programistycznej.

Wskazówka 100: Utwórz szablon automatyzacji “Nowa funkcja”

Standaryzuj sposób tworzenia szkieletu nowych funkcji:

Skopiuj i wklej prompt szkieletu nowej funkcji

Utwórz nowy moduł funkcji dla “powiadomień” podążając za naszymi ustalonymi wzorcami:

1. Utwórz src/services/notification.ts podążając za wzorcem w @src/services/user.ts
2. Utwórz src/api/notifications/route.ts podążając za wzorcem w @src/api/users/route.ts
3. Utwórz src/types/notification.ts z interfejsami TypeScript
4. Utwórz src/services/tests/notification.test.ts z kompleksowymi testami
5. Dodaj schemat Drizzle do @src/lib/db/schema.ts podążając za istniejącymi wzorcami tabel
6. Utwórz migrację bazy danych dla nowej tabeli
7. Eksportuj wszystko z odpowiednich plików index

Uruchom testy po utworzeniu każdego pliku, aby upewnić się, że nic nie pęka.

Wskazówka 101: Zautomatyzuj debugowanie oparte na logach

Utwórz wielokrotnie używalny prompt dla przepływu pracy debugowania z logami ze wskazówki 69:

.cursor/prompts/debug-with-logs.md

# Debuguj z logami

Debuguję problem w [PLIK]. Oto czego oczekuję vs co się dzieje:
- Oczekiwane: [OPIS]
- Rzeczywiste: [OPIS]

Krok 1: Dodaj szczegółowe instrukcje console.log w każdym punkcie decyzyjnym w pliku.
Loguj wejście/wyjście funkcji, wszystkie wartości parametrów, wyniki obliczeń pośrednich
i każdą podjętą gałąź warunkową.

Krok 2: Uruchomię scenariusz i wkleję logi z powrotem.

Krok 3: Przeanalizuj logi, zidentyfikuj, gdzie rzeczywiste zachowanie odbiega od oczekiwanego
i zaproponuj ukierunkowaną poprawkę.

Krok 4: Usuń całe debugowanie logowania po zweryfikowaniu poprawki.

Narzędzia jakości kodu

Wskazówka 102: Używaj Bug Finder systematycznie przed każdym PR

Bug Finder (Cmd+Shift+P > “Bug Finder”) porównuje twoją gałąź z main i oznacza potencjalne problemy. Uczyń to częścią swojego przepływu pracy:

1. Zakończ implementację funkcji
2. Uruchom listę kontrolną pre-PR (wskazówka 99)
3. Uruchom Bug Finder
4. Przejrzyj każdy oznaczony problem — napraw prawdziwe błędy, odrzuć fałszywe pozytywy
5. Uruchom testy jeszcze raz, aby zweryfikować poprawki
6. Otwórz swój PR

Bug Finder wychwytuje specyficzną kategorię błędów, które lintery i sprawdzacze typów pomijają: błędy logiczne, nieobsłużone przypadki brzegowe i niespójne wzorce zachowań. Warto poświęcić 30 sekund na PR.

Wskazówka 103: Użyj trybu Agent do przeglądu kodu przed merge

Przed poproszeniem o ludzki przegląd kodu uruchom przegląd AI:

Skopiuj i wklej prompt auto-przeglądu

@git diff main

Przejrzyj wszystkie moje zmiany, jakbyś był starszym inżynierem przeglądającym ten PR. Sprawdź:

1. Problemy bezpieczeństwa (injection, obejście uwierzytelniania, ujawnienie danych)
2. Obawy o wydajność (zapytania N+1, brakujące indeksy, niepotrzebne re-rendery)
3. Luki w obsłudze błędów (nieobsłużone odrzucenia promise, brakujące przypadki błędów)
4. Problemy z nazewnictwem i czytelnością
5. Brakujące lub niekompletne pokrycie testowe
6. Naruszenia wzorców ustalonych w @.cursor/rules/

Bądź krytyczny. Wolę naprawić problemy teraz niż otrzymać je w przeglądzie.

To nie zastępuje ludzkiego przeglądu kodu. To pierwsze przejście, które wychwytuje łatwe rzeczy, aby twój ludzki recenzent mógł skupić się na architekturze i designie.

Optymalizacja kosztów i modeli

Wskazówka 104: Przełączaj modele w zależności od fazy zadania

Pojedyncza funkcja przechodzi przez wiele faz, każda z różnymi wymaganiami modelowymi:

Faza	Zalecany model	Dlaczego
Planowanie i architektura	Claude Opus 4.6	Potrzebuje głębokiego rozumowania o designie systemu
Implementacja	Claude Sonnet 4.5	Wystarczająco dobry do pisania kodu, o wiele szybszy
Debugowanie	Claude Opus 4.6	Złożone rozumowanie potrzebne do trudnych błędów
Generowanie testów	Claude Sonnet 4.5	Zadanie podążania za wzorcem, nie wymaga głębokiego rozumowania
Przegląd kodu	Claude Opus 4.6	Potrzebuje rozumować o przypadkach brzegowych i bezpieczeństwie
Dokumentacja	Claude Sonnet 4.5	Proste zadanie generowania

Przełączaj modele używając wybieraka modelu w panelu agenta. Większość programistów domyślnie używa Opus do wszystkiego i wypala swój limit. Sonnet obsługuje 70% zadań programistycznych równie dobrze za ułamek kosztu.

Wskazówka 105: Śledź i zarządzaj swoim budżetem tokenów

Cursor zapewnia śledzenie użycia w Settings > Usage. Monitoruj je, aby uniknąć niespodzianek limitu:

• Sprawdzaj tygodniowe wzorce użycia, aby zrozumieć swoje zużycie
• Identyfikuj, które zadania zużywają najwięcej tokenów (zwykle długie rozmowy agenta z wieloma odniesieniami do plików)
• Ustaw osobisty budżet i przełączaj się na Sonnet, gdy zbliżasz się do limitu
• Używaj Max Mode tylko wtedy, gdy standardowy kontekst jest naprawdę niewystarczający

Programiści, którym kończy się limit w połowie sprintu, to zwykle ci, którzy używają Opus z Max Mode do każdego zadania. Ci, którym nigdy nie kończy się, są strategiczni w wyborze modelu i zarządzaniu kontekstem.

Gdy to się psuje

Serwer MCP nie łączy się: Sprawdź, czy wymagane zmienne środowiskowe są ustawione (GITHUB_TOKEN, DATABASE_URL itp.). Uruchom polecenie serwera MCP ręcznie w swoim terminalu, aby zobaczyć wyjście błędu. Typowe przyczyny: wygasłe tokeny, złe ciągi połączeń, brakujące pakiety npm.

Agent w tle produkuje niskiej jakości wyjście: Prompt nie był wystarczająco szczegółowy. Agenci w tle potrzebują samowystarczalnych specyfikacji, ponieważ nie mogą zadawać pytań wyjaśniających. Jeśli wyjście jest konsekwentnie słabe, dodaj więcej szczegółów do swoich promptów: konkretne pliki do naśladowania jako wzorce, dokładne frameworki testowe do użycia i wyraźne ograniczenia.

Bug Finder zgłasza zbyt wiele fałszywych pozytywów: Bug Finder oznacza celowe wzorce (nieużywane zmienne w destrukturyzacji, celowe rozszerzanie typów) jako potencjalne błędy. Traktuj go jako narzędzie doradcze, nie bramę. Napraw prawdziwe problemy i pomiń fałszywe pozytywy.

Użycie tokenów jest nieoczekiwanie wysokie: Długie rozmowy agenta z odniesieniami do @ na poziomie katalogu są największymi konsumentami tokenów. Dziel rozmowy na mniejsze, ograniczone sesje. Odwołuj się do konkretnych plików zamiast całych katalogów. Rozpoczynaj nowe rozmowy dla nowych zadań zamiast kontynuować istniejące.

Co dalej

Te zaawansowane techniki czynią cię indywidualnie produktywnym na wyjątkowym poziomie. Ostatnia sekcja, Współpraca zespołowa (wskazówki 106-112), pokazuje, jak skalować te praktyki w całym zespole — wspólne zasady, przepływy pracy onboardingu i wzorce współpracy, które przyspieszają cały zespół.