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 YOLO (Wskazówka 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
Dodaj nową tabelę "organizations" z polami name, slug i owner_id.
Utwórz schemat Drizzle, migrację i funkcje zapytań CRUD zgodnie z
tym samym wzorcem co istniejące zapytania użytkowników w plikach, do których się odwołujesz.

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 w panelu agenta. 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 Ask do Planowania, Trybu Agent do Wykonania

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

Dwuetapowy przepływ pracy przynosi dramatycznie lepsze rezultaty niż pojedyncza rozmowa z agentem:

  1. Otwórz tryb Ask: „Muszę dodać rozliczenia subskrypcji Stripe. Przejrzyj @src/api/ i @src/lib/ i zasugeruj plan implementacji. Wymień pliki, które wymagają zmian, nowe pliki do utworzenia i kolejność operacji. Nie wprowadzaj żadnych zmian.”
  2. Przejrzyj plan: Agent tworzy ustrukturyzowany plan bez dotykania Twojego kodu
  3. Otwórz nową rozmowę Agent: „Zaimplementuj krok 1 z tego planu: [wklej odpowiednią sekcję]. Postępuj zgodnie ze wzorcami z @src/api/users/route.ts dla struktury endpointu.”
  4. Powtarzaj: Jedna rozmowa agenta na krok, każda rozpoczyna się od nowa z skupionym kontekstem

To podejście zapobiega przytłoczeniu agenta. Każda rozmowa jest skupiona, kontekst jest świeży i możesz weryfikować poprawność między krokami.

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:

# Zamiast:
@src/api/ @src/lib/ @src/components/ @src/types/ "Refaktoryzuj auth"
# Zrób:
# Rozmowa 1: @src/lib/auth.ts @src/types/user.ts "Refaktoryzuj serwis auth"
# Rozmowa 2: @src/api/auth/ @src/lib/auth.ts "Zaktualizuj trasy API dla nowego serwisu auth"
# Rozmowa 3: @src/components/AuthProvider.tsx @src/lib/auth.ts "Zaktualizuj dostawcę auth frontendu"

Wskazówka 66: Używaj @web dla Aktualnej Dokumentacji Bibliotek

Dział zatytułowany „Wskazówka 66: Używaj @web dla Aktualnej Dokumentacji Bibliotek”

Podczas pracy z biblioteką, która została zaktualizowana od czasu trenowania AI, użyj @web, aby pobrać aktualne dokumenty:

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

Wskazówka 67: Odwołuj się do @git dla Promptów Świadomych Zmian

Dział zatytułowany „Wskazówka 67: Odwołuj się do @git dla Promptów Świadomych Zmian”

Kontekst @git pozwala agentowi zrozumieć, co ostatnio się zmieniło:

@git diff main
Przejrzyj zmiany, które wprowadzłem od rozgałęzienia od main. Sprawdź:
1. Brakującą obsługę błędów w nowym kodzie
2. Problemy z bezpieczeństwem typów
3. Spójność z istniejącymi wzorcami
4. Brakujące pokrycie testami dla nowej funkcjonalności

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 nietrywalnej funkcji, ustrukturyzuj swój prompt, aby zawierał krok weryfikacji:

Sekcja „po implementacji” daje agentowi jasną listę kontrolną weryfikacji. Z trybem YOLO automatycznie uruchamia te kontrole.

Wskazówka 69: Używaj Przepływu Pracy Logowania Debugowania

Dział zatytułowany „Wskazówka 69: Używaj Przepływu Pracy Logowania Debugowania”

Gdy agent nie może znaleźć błędu tylko poprzez analizę statyczną, użyj tego iteracyjnego wzorca debugowania:

  1. Powiedz agentowi: „Dodaj instrukcje console.log w każdym punkcie decyzyjnym w @src/services/payment.ts, aby śledzić przepływ wykonania. Loguj wejście/wyjście z funkcji, wartości parametrów i wyniki pośrednie.”
  2. Uruchom scenariusz kończy się niepowodzeniem i skopiuj wyjście logu
  3. Wklej logi z powrotem do rozmowy z agentem: „Oto wyjście logu. Przeanalizuj ślad i zidentyfikuj, gdzie zachowanie odbiega od oczekiwanego.”
  4. Agent ma teraz dane czasu wykonania do połączenia z analizą kodu statycznego
  5. Proponuje ukierunkowaną poprawkę na podstawie rzeczywistej ścieżki wykonania

Jest to dramatycznie bardziej efektywne 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: „Teraz przekonwertuj @src/api/users.ts zgodnie z tym samym wzorcem ustanowionym w endpoincie health.” 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:

Oto błąd z naszych logów produkcyjnych:
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)
Payload webhooka ze Stripe czasami nie zawiera szczegółów klienta,
gdy jest to zdarzenie aktualizacji subskrypcji. Napraw handler w
@src/api/webhooks/stripe.ts, aby obsługiwał brakujące dane klienta w sposób łagodny.

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: „Wygeneruj kompleksowe testy dla każdego serwisu w @src/services/. Celuj w 90% pokrycia.”
  • 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
Utwórz nowy endpoint API zgodnie z tymi konwencjami:
- Użyj wzorca trasy z @src/api/users/route.ts
- Dołącz walidację zod dla body żądania
- Dodaj odpowiednią obsługę błędów z naszą klasą AppError
- Zwróć ustandaryzowane odpowiedzi JSON
- Dodaj testy vitest w sąsiednim katalogu __tests__
- Uruchom testy po implementacji

Następnie w agencie: “@.cursor/prompts/new-endpoint.md — utwórz endpoint POST /api/organizations, który tworzy nową organizację z polami name i slug.”

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: „Poprzednia próba nie powiodła się, ponieważ agent próbował użyć surowego SQL zamiast Drizzle ORM. Upewnij się, że wszystkie operacje bazodanowe używają query buildera Drizzle z @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: „Modyfikuj tylko pliki w @src/api/users/. Nie dotykaj żadnych innych katalogów.” 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.