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
• Przepływy pracy Bugbot i 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": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    }
  }
}

Używaj utrzymywanego serwera GitHub

Stary pakiet npm @modelcontextprotocol/server-github jest przestarzały — rozwój przeniósł się do własnego serwera GitHuba. Skieruj Cursor na hostowany zdalny endpoint (https://api.githubcopilot.com/mcp/, pokazany powyżej) albo samodzielnie hostuj binarkę github/github-mcp-server. Pakiet @modelcontextprotocol/server-postgres to zamrożona implementacja referencyjna (wciąż się instaluje, ale nie jest już aktywnie rozwijana); nadaje się do szybkiego połączenia, ale do produkcji sięgnij po utrzymywany serwer Postgresa, taki jak postgres-mcp od Crystal DBA (instalowany przez pipx install postgres-mcp albo uruchamiany z obrazu Dockera crystaldba/postgres-mcp).

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

Using the database connection, check the current schema for the “users” table. Then create a new Drizzle ORM migration that adds an “organization_id” column as a foreign key to the “organizations” table, with a default value of null for existing rows.

After creating the migration, verify it by running the migration against the dev database and querying the updated schema.

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:

Look at the "Dashboard" page in our Figma project. Extract the card component design -- its spacing, colors, typography, and layout. Then implement it using our existing Tailwind classes and React component patterns from @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

Read the requirements from JIRA ticket PROJ-1234. Implement the feature described in the ticket, following the acceptance criteria. After implementation, update the ticket status to “In Review” and add a comment with a summary of changes.

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

Branch from main. Create comprehensive vitest tests for every exported function in src/services/payment.ts.

Requirements:

• Test happy paths with realistic data
• Test error cases (network failures, invalid inputs, missing required fields)
• Test edge cases (zero amounts, maximum amounts, concurrent requests)
• Mock external dependencies (Stripe SDK, database queries) using vitest mocks
• Aim for 90% code coverage on the file
• Follow the test patterns established in src/services/tests/user.test.ts

After writing tests, run them to verify they pass. Fix any failures. Open a PR titled “test: add payment service test coverage” with a summary of test cases added.

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

# Pre-PR Checklist

Run each step and fix any issues before proceeding to the next:

1. pnpm run typecheck -- fix all TypeScript errors
2. pnpm run lint -- fix all linting issues (do not add eslint-disable comments)
3. pnpm run test -- fix test failures by modifying source code, not test assertions
4. Check for console.log/console.debug statements -- remove any that are not intentional
5. Check for TODO comments that should be addressed in this PR
6. Verify all new files have proper imports and exports
7. Run pnpm run build to verify the production build succeeds

After all steps pass, summarize what was fixed.

Odwołaj się do niego z @.cursor/prompts/pre-pr.md na końcu każdej sesji programistycznej. Przykłady tutaj używają pnpm; podmień na npm run lub yarn, aby dopasować się do menedżera pakietów twojego projektu.

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

Standaryzuj sposób tworzenia szkieletu nowych funkcji:

Skopiuj i wklej prompt szkieletu nowej funkcji

Create a new feature module for “notifications” following our established patterns:

1. Create src/services/notification.ts following the pattern in @src/services/user.ts
2. Create src/api/notifications/route.ts following the pattern in @src/api/users/route.ts
3. Create src/types/notification.ts with TypeScript interfaces
4. Create src/services/tests/notification.test.ts with comprehensive tests
5. Add the Drizzle schema to @src/lib/db/schema.ts following existing table patterns
6. Create a database migration for the new table
7. Export everything from the appropriate index files

Run tests after each file creation to ensure nothing breaks.

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

# Debug with Logs

I am debugging an issue in [FILE]. Here is what I expect vs what happens:
- Expected: [DESCRIPTION]
- Actual: [DESCRIPTION]

Step 1: Add detailed console.log statements at every decision point in the file.
Log function entry/exit, all parameter values, intermediate calculation results,
and any conditional branch taken.

Step 2: I will run the scenario and paste the logs back.

Step 3: Analyze the logs, identify where actual behavior diverges from expected,
and propose a targeted fix.

Step 4: Remove all debug logging after the fix is verified.

Narzędzia jakości kodu

Wskazówka 102: Używaj Bugbot systematycznie przy każdym PR

Bugbot to recenzent kodu AI w Cursorze (zastąpił dawne polecenie „Bug Finder”). Włącz go raz z poziomu Cursor Dashboard i połącz swoje repozytorium GitHub; od tej chwili recenzuje każdy PR automatycznie, dodaje komentarze inline do znalezionych problemów i potrafi wypchnąć poprawkę przez Cloud Agent. Możesz też nim sterować zasadami na poziomie repozytorium w plikach .cursor/BUGBOT.md (Bugbot zawsze dołącza plik z katalogu głównego i przechodzi w górę drzewa od zmienionych plików). Uczyń go częścią swojego przepływu pracy:

1. Zakończ implementację funkcji
2. Uruchom listę kontrolną pre-PR (wskazówka 99)
3. Otwórz swój PR — Bugbot recenzuje diff i komentuje automatycznie
4. Przejrzyj każdy oznaczony problem — napraw prawdziwe błędy (albo kliknij „Fix in Cursor”, aby Cloud Agent przygotował poprawkę), odrzuć fałszywe pozytywy
5. Wypchnij poprawki i pozwól Bugbotowi przejrzeć ponownie
6. Poproś o ludzki przegląd, gdy Bugbot jest czysty

Bugbot 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ń. Z czasem dostrajaj jego stosunek sygnału do szumu, dodając konwencje projektu do .cursor/BUGBOT.md.

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

Review all my changes as if you are a senior engineer reviewing this PR. Check for:

1. Security issues (injection, auth bypass, data exposure)
2. Performance concerns (N+1 queries, missing indexes, unnecessary re-renders)
3. Error handling gaps (unhandled promise rejections, missing error cases)
4. Naming and readability issues
5. Missing or incomplete test coverage
6. Violations of the patterns established in @.cursor/rules/

Be critical. I would rather fix issues now than get them flagged in review.

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 Fable 5 lub Opus 4.8	Fable 5 do najtrudniejszych problemów z designem systemu; Opus 4.8 gdy budżet ma znaczenie
Implementacja	Claude Sonnet 4.6	Wystarczająco dobry do pisania kodu, o wiele szybszy
Debugowanie	Claude Opus 4.8	Złożone rozumowanie potrzebne do trudnych błędów
Generowanie testów	Claude Sonnet 4.6	Zadanie podążania za wzorcem, nie wymaga głębokiego rozumowania
Przegląd kodu / weryfikacja końcowa	Claude Fable 5 lub Opus 4.8	Fable 5 wyłapuje więcej subtelnych przypadków brzegowych; Opus 4.8 to domyślny wybór świadomy kosztów
Dokumentacja	Claude Sonnet 4.6	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. Gdy budżet ma mniejsze znaczenie niż prędkość i jakość — na przykład przy złożonym refaktoryzowaniu wielu plików lub budowaniu nowego modułu od podstaw — użyj Claude Fable 5 (/model fable w Claude Code; dostępny w selektorze modeli Cursora). Fable 5 to najbardziej zaawansowany model Anthropic i doskonale sprawdza się w dokładnie tych zadaniach, w których Opus 4.8 czasem zawodzi. Subagenci w trybie plan nadal automatycznie działają na Opus/Sonnet/Haiku, więc codzienne koszty pozostają pod kontrolą. Zobacz Porównanie modeli po pełne zestawienie.

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.

Bugbot zgłasza zbyt wiele fałszywych pozytywów: Bugbot czasem oznacza celowe wzorce (nieużywane zmienne w destrukturyzacji, celowe rozszerzanie typów) jako potencjalne błędy. Traktuj go jako recenzenta doradczego, nie twardą bramę. Napraw prawdziwe problemy, odrzuć fałszywe pozytywy i skodyfikuj swoje konwencje w .cursor/BUGBOT.md, aby przestał je ponownie oznaczać.

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ół.