Przejdź do głównej zawartości

Optymalizacja Agenta i Chatu: Wskazówki 61-75

Otwierasz panel agenta, wpisujesz „dodaj uwierzytelnianie użytkownika” i patrzysz, jak Cursor tworzy niedokończony moduł auth, który ignoruje Twoje istniejące middleware, używa innego ORM-a niż Twój projekt i psuje trzy pliki testowe. Spędzasz więcej czasu na naprawianiu bałaganu, niż zajęłoby Ci napisanie tego samodzielnie. Problem nie leży w trybie agenta – problem polega na tym, że tryb agenta to potężne narzędzie, a potężne narzędzia bez techniki wyrządzają szkody. Te 15 wskazówek nauczy Cię techniki.

  • Przepływ pracy agenta oparty na testach, który produkuje kod, któremu faktycznie możesz zaufać
  • Strategie zarządzania kontekstem, które powstrzymują agenta przed zbaczaniem z kursu w trakcie rozmowy
  • Wzorce promptów dla najczęstszych zadań agenta (funkcje, refaktoryzacje, debugowanie, migracje)
  • Jasne zasady dotyczące tego, kiedy nadzorować agenta, a kiedy pozwolić mu działać bez nadzoru

Wskazówka 61: Zawsze Najpierw Pisz Testy w Trybie Agenta

Dział zatytułowany „Wskazówka 61: Zawsze Najpierw Pisz Testy w Trybie Agenta”

Najbardziej znacząca zmiana, jaką możesz wprowadzić do swojego przepływu pracy z agentem: każ mu pisać testy przed implementacją. To daje agentowi jasną definicję „ukończenia”, którą może zweryfikować autonomicznie.

Z włączonym trybem Auto-Run (dawniej nazywanym trybem YOLO – zobacz Wskazówkę 5), agent:

  1. Tworzy plik testowy z dobrze zdefiniowanymi asercjami
  2. Tworzy plik implementacji
  3. Uruchamia vitest
  4. Widzi niepowodzenia, naprawia kod
  5. Ponownie uruchamia vitest
  6. Powtarza, aż wszystkie testy przejdą

Nie zatwierdziłeś ani jednego polecenia. Nie przejrzałeś wyjścia pośredniego. A końcowy kod ma pokrycie testami z definicji.

Wskazówka 62: Używaj Referencji @ do Uziemienia Każdej Rozmowy

Dział zatytułowany „Wskazówka 62: Używaj Referencji @ do Uziemienia Każdej Rozmowy”

Symbol @ nie jest opcjonalny – to różnica między zgadywaniem przez agenta struktury Twojego kodu a jej znajomością. Zawsze dołączaj odpowiedni kontekst:

@src/lib/db/schema.ts @src/lib/db/queries.ts
Add a new "organizations" table with name, slug, and owner_id fields.
Create the Drizzle schema, migration, and CRUD query functions following
the same pattern as the existing user queries in the referenced files.

Bez referencji @, agent może wygenerować surowy SQL zamiast Drizzle, użyć innej konwencji nazewniczej lub utworzyć pliki w niewłaściwym katalogu. Z nimi dopasowuje wzorce do Twojego istniejącego kodu i produkuje spójne wyjście.

Wskazówka 63: Rozpoczynaj Nowe Rozmowy dla Nowych Zadań

Dział zatytułowany „Wskazówka 63: Rozpoczynaj Nowe Rozmowy dla Nowych Zadań”

Rozmowy z agentem mają ograniczone okno kontekstu, a długie rozmowy degradują jakość. Oto znaki, że potrzebujesz nowej rozmowy:

  • Agent zaczyna „zapominać” instrukcje, które podałeś wcześniej
  • Powtarza błędy, które już poprawiłeś
  • Odwołuje się do plików, które nie są już istotne
  • Jego odpowiedzi stają się wolniejsze

Rozpocznij nową rozmowę za pomocą Cmd+N (lub Cmd+R) w panelu chatu. Przenieś tylko niezbędny kontekst: pliki, których potrzebujesz, konkretne zadanie i wszelkie ograniczenia. Nie próbuj wznawiać nieaktualnej rozmowy, wklejając podsumowanie – szybsze i bardziej niezawodne jest rozpoczęcie od nowa.

Wskazówka 64: Używaj Trybu Plan do Planowania, Trybu Agent do Wykonania

Dział zatytułowany „Wskazówka 64: Używaj Trybu Plan do Planowania, Trybu Agent do Wykonania”

Przepływ pracy „najpierw planuj, potem wykonuj” przynosi dramatycznie lepsze rezultaty niż pojedyncza rozmowa z agentem. Cursor dostarcza dedykowany tryb Plan dokładnie do tego: bada Twoją bazę kodu, zadaje pytania doprecyzowujące i tworzy edytowalny plan do przejrzenia, zanim napisze jakikolwiek kod. Dotrzesz do niego, naciskając Shift+Tab w polu chatu, aby przełączać się między trybami, albo wybierając go z rozwijanej listy trybów.

  1. Przełącz się na tryb Plan (Shift+Tab): „I need to add Stripe subscription billing. Research @src/api/ and @src/lib/, then produce a plan: the files that need to change, the new files to create, and the order of operations.”
  2. Przejrzyj i edytuj plan: Tryb Plan generuje ustrukturyzowany plan jako edytowalny dokument markdown i zadaje pytania doprecyzowujące. Zawęź zakres, popraw błędne założenia i odpowiedz na jego pytania, zanim zacznie budować.
  3. Kliknij, aby zbudować: Gdy plan wygląda dobrze, Cursor wykonuje go bezpośrednio – żadne przekazywanie przez kopiuj-wklej nie jest wymagane. Jeśli wynik zbacza z kursu, cofnij i dopracuj plan zamiast walczyć z agentem w trakcie pracy.

To powstrzymuje agenta przed braniem na siebie zbyt wielu rzeczy naraz: plan jest przeglądany z góry, a budowa pozostaje ograniczona do tego, co zatwierdziłeś.

Jeśli chcesz precyzyjniejszej ręcznej kontroli, starszy dwuetapowy wzorzec nadal działa: poproś w trybie Ask (tylko do odczytu) o plan, a następnie wklej każdy krok do świeżej rozmowy Agent. Tryb Plan automatyzuje tę pętlę, ale tryb Ask jest przydatny, gdy chcesz tylko omówić podejście, bez tego, by Cursor proponował budowę.

Każdy plik, do którego się odwołujesz za pomocą @, zużywa tokeny kontekstu. Odwołaj się do zbyt wielu plików, a jakość rozumowania agenta spada, ponieważ nie może przechowywać wszystkiego w pamięci roboczej. Zasady:

  • 1-3 pliki: Agent może rozumować o każdej linii szczegółowo
  • 4-8 plików: Agent rozumie ogólną strukturę, ale może przegapić szczegóły
  • 8+ plików: Agent pobieżnie przegląda i może halucynować połączenia między plikami

Dla zadań wymagających wielu plików, podziel je na podzadania, z których każde odwołuje się tylko do odpowiedniego podzbioru:

# Instead of:
@src/api/ @src/lib/ @src/components/ @src/types/ "Refactor auth"
# Do:
# Conversation 1: @src/lib/auth.ts @src/types/user.ts "Refactor the auth service"
# Conversation 2: @src/api/auth/ @src/lib/auth.ts "Update API routes for new auth service"
# Conversation 3: @src/components/AuthProvider.tsx @src/lib/auth.ts "Update the frontend auth provider"

Wskazówka 66: Poproś Agenta o Przeszukanie Sieci w Poszukiwaniu Aktualnej Dokumentacji

Dział zatytułowany „Wskazówka 66: Poproś Agenta o Przeszukanie Sieci w Poszukiwaniu Aktualnej Dokumentacji”

Podczas pracy z biblioteką, która została zaktualizowana od czasu danych treningowych modelu, po prostu poproś agenta o sprawdzenie aktualnej dokumentacji – sam zbiera kontekst z sieci na podstawie zwykłego polecenia w języku naturalnym. (Starsze wersje Cursora udostępniały jawną wzmiankę @Web, ale Cursor 2.0 usunął ją z menu kontekstowego na rzecz samodzielnego wyszukiwania przez agenta).

Jest to szczególnie cenne dla szybko ewoluujących bibliotek (Next.js App Router, Drizzle, tRPC), gdzie wbudowana wiedza modelu może być o wersję lub dwie w tyle.

Każ agentowi samemu porównać Twój branch (diff), a następnie przejrzeć to, co się zmieniło. Cursor 2.0 usunął jawną wzmiankę @Git; teraz prosisz agenta bezpośrednio, aby spojrzał na Twój branch (sam uruchamia git), co jest bardziej elastyczne – w tym samym zdaniu możesz zawęzić zakres do konkretnych commitów lub plików.

Review the changes on my current branch versus main. Check for:
1. Missing error handling in new code
2. Type safety issues
3. Consistency with existing patterns
4. Missing test coverage for new functionality

To szybki przegląd przed PR, który wyłapuje problemy, zanim zobaczą je Twoi koledzy z zespołu.

Wskazówka 68: Używaj Wzorca „Implementuj i Weryfikuj”

Dział zatytułowany „Wskazówka 68: Używaj Wzorca „Implementuj i Weryfikuj””

Dla każdej nietrywialnej funkcji, ustrukturyzuj swój prompt, aby zawierał krok weryfikacji:

Sekcja „after implementation” daje agentowi jasną listę kontrolną weryfikacji. Z włączonym trybem Auto-Run automatycznie uruchamia te kontrole.

Wskazówka 69: Sięgnij po Tryb Debug przy Trudnych do Odtworzenia Błędach

Dział zatytułowany „Wskazówka 69: Sięgnij po Tryb Debug przy Trudnych do Odtworzenia Błędach”

Gdy błąd opiera się analizie statycznej – regresja, race condition, sporadyczna awaria – użyj trybu Debug Cursora zamiast zgadywać. Tryb Debug generuje hipotezy, automatycznie instrumentuje odpowiedni kod instrukcjami logującymi, które przesyłają dane do lokalnego serwera debugowania, prosi Cię o odtworzenie błędu, następnie czyta przechwycone dane czasu wykonania, wprowadza ukierunkowaną poprawkę i sam usuwa później swoją instrumentację. Przełącz się na niego za pomocą Shift+Tab (znajduje się obok trybu Plan w rotacji trybów).

Jeśli tryb Debug jest niedostępny (starszy Cursor lub chcesz pełnej ręcznej kontroli), wróć do klasycznej pętli instrumentuj-i-wklej:

  1. Powiedz agentowi: „Add console.log statements at every decision point in @src/services/payment.ts to trace the execution flow. Log function entry/exit, parameter values, and intermediate results.”
  2. Uruchom scenariusz, który kończy się niepowodzeniem, i skopiuj wyjście logu.
  3. Wklej logi z powrotem: „Here is the log output. Analyze the trace and identify where the behavior diverges from expected.” Agent łączy teraz dane czasu wykonania z analizą statyczną i proponuje ukierunkowaną poprawkę – pamiętaj potem o usunięciu tymczasowych logów.

Każda z tych ścieżek jest dramatycznie bardziej efektywna niż mówienie agentowi „napraw błąd” bez kontekstu czasu wykonania.

Wskazówka 70: Używaj Wzorca „Migracji Przyrostowej”

Dział zatytułowany „Wskazówka 70: Używaj Wzorca „Migracji Przyrostowej””

Dla dużych migracji (aktualizacje bibliotek, zmiany wzorców, migracje frameworków), nie proś agenta o migrację wszystkiego na raz. Użyj migracji przyrostowej:

Po zweryfikowaniu pierwszego pliku przejdź do następnego: „Now convert @src/api/users.ts following the same pattern established in the health endpoint.” Każdy krok bazuje na poprzednim, a Ty weryfikujesz przed kontynuacją.

Wskazówka 71: Używaj Przepływu Pracy „Napraw Mój PR”

Dział zatytułowany „Wskazówka 71: Używaj Przepływu Pracy „Napraw Mój PR””

Kończ swoje sesje programistyczne, pozwalając agentowi uporządkować wszystko w jednym przebiegu:

Wskazówka 72: Pozwól Agentowi Generować z Logów Błędów

Dział zatytułowany „Wskazówka 72: Pozwól Agentowi Generować z Logów Błędów”

Zamiast opisywać problem produkcyjny, wklej rzeczywisty błąd:

Here is the error from our production logs:
TypeError: Cannot read properties of undefined (reading 'email')
at processWebhook (src/api/webhooks/stripe.ts:47:28)
at handleRequest (src/middleware/router.ts:112:5)
The webhook payload from Stripe sometimes does not include customer details
when it is a subscription update event. Fix the handler in
@src/api/webhooks/stripe.ts to handle missing customer data gracefully.

Prawdziwe ślady stosu dają agentowi dokładne ścieżki plików, numery linii i typy błędów – o wiele bardziej użyteczne niż opis.

Dla długotrwałych zadań rozpocznij agenta w tle i kontynuuj pracę w regularnej rozmowie z agentem:

  • Agent w tle: „Generate comprehensive tests for every service in @src/services/. Aim for 90% coverage.”
  • Agent na pierwszym planie: Kontynuuj implementację funkcji, nad którą obecnie pracujesz

Agent w tle tworzy PR, gdy skończy. Przejrzyj PR, zmerguj testy, a Twoje pokrycie testami zostanie ulepszone bez blokowania Twojej aktywnej pracy.

Wskazówka 74: Twórz Pliki Promptów Wielokrotnego Użytku

Dział zatytułowany „Wskazówka 74: Twórz Pliki Promptów Wielokrotnego Użytku”

Zapisuj często używane prompty jako pliki .md w swoim projekcie i odwołuj się do nich za pomocą @:

.cursor/prompts/new-endpoint.md
Create a new API endpoint following these conventions:
- Use the route pattern from @src/api/users/route.ts
- Include zod validation for request body
- Add proper error handling with our AppError class
- Return standardized JSON responses
- Add vitest tests in the adjacent __tests__ directory
- Run tests after implementation

Następnie w agencie: “@.cursor/prompts/new-endpoint.md — create a POST /api/organizations endpoint that creates a new organization with name and slug fields.”

Wskazówka 75: Wiedz, Kiedy Zatrzymać się i Zacząć od Nowa

Dział zatytułowany „Wskazówka 75: Wiedz, Kiedy Zatrzymać się i Zacząć od Nowa”

Agent nie zawsze ma rację, a czasami schodzi na ślepą ścieżkę. Znaki, że powinieneś zatrzymać się, przywrócić punkt kontrolny i zrestartować:

  • Agent popełnił ten sam błąd trzy razy z rzędu
  • Agent generuje kod sprzeczny z Twoimi instrukcjami
  • Rozmowa przekroczyła 15-20 wymian bez zbliżania się do rozwiązania
  • Agent edytuje pliki, które wyraźnie kazałeś mu nie dotykać

Gdy restartujesz, dodaj kontekst niepowodzenia do swojego nowego promptu: „Previous attempt failed because the agent tried to use raw SQL instead of Drizzle ORM. Ensure all database operations use the Drizzle query builder from @src/lib/db/queries.ts.”

Agent modyfikuje pliki, których nie zamierzałeś: Zwykle dzieje się tak, gdy Twój prompt jest niejednoznaczny co do zakresu. Bądź jednoznaczny: „Only modify files in @src/api/users/. Do not touch any other directories.” Jeśli już się stało, użyj punktów kontrolnych do przywrócenia.

Agent wchodzi w nieskończoną pętlę napraw: Agent uruchamia testy, widzi niepowodzenie, „naprawia” to, wprowadza nowe niepowodzenie, „naprawia” to i zapętla się w nieskończoność. Zatrzymaj agenta, przejrzyj, co poszło nie tak, i zrestartuj z bardziej ograniczonym promptem. Często problem polega na tym, że agent walczy z własnymi poprzednimi zmianami.

Agent produkuje działający kod, który nie pasuje do Twoich konwencji: Dzieje się tak, gdy brakuje reguł projektu lub są niekompletne. Zainwestuj czas w swój .cursorrules lub .cursor/rules/ (Wskazówki 9-11). 30 minut spędzonych na regułach oszczędza godziny przeróbek.

Przepełnienie kontekstu w długich rozmowach: Jeśli odpowiedzi agenta stają się coraz bardziej ogólne lub zaczynają ignorować Twoje instrukcje, okno kontekstu jest nasycone. Rozpocznij nową rozmowę. Nie ma sposobu na „przycięcie” kontekstu w istniejącej rozmowie.

Tryb agenta dobrze radzi sobie z pojedynczymi funkcjami i skupionymi zadaniami. Ale co się dzieje, gdy Twój projekt ma 500 000 linii kodu i agent musi zrozumieć granice architektoniczne, łańcuchy zależności i granice modułów? Przejdź do Strategii dla Dużych Baz Kodu (Wskazówki 76-90) dla technik w skali enterprise.