Cursor Tab: trafne edycje wieloliniowe i ich weryfikacja

Cursor Tab to wbudowany model uzupełniania w edytorze Cursor: przewiduje następną edycję w pobliżu kursora, także zmiany wieloliniowe i skoki do kolejnego miejsca wymagającego powiązanej zmiany, a klawisz Tab ją przyjmuje. Tab działa najpewniej, gdy wzorzec do kontynuacji jest już widoczny, a przyjęty kod nadal wymaga bramki typów, lintera lub testów.

Naciskasz Tab, dostajesz wiarygodnie wyglądający, 12-liniowy handler i go przyjmujesz. Dwa dni później recenzent zauważa, że endpoint postów zwraca "User not found", bo Tab wiernie skopiował wzorzec, a razem z nim jedyny szczegół, który miał się zmienić. Problemem nigdy nie była szybkość, tylko to, którym sugestiom ufać i jak wyłapać te, którym ufać nie należało.

Ta strona jest dla programistów, którzy nadal piszą kod w edytorze Cursora i chcą, żeby Tab przejął jego mechaniczną część. Pracę wielkości całej funkcjonalności zostaw agentowi Cursora; Tab jest od edycji, które inaczej wpisujesz ręcznie.

Ustawienia i skróty mogą się różnić w twojej wersji

Strona opisuje linię Cursor 3.x według stanu na 26 września 2026 roku. Nazwy ustawień i skrót częściowej akceptacji zmieniają się między wersjami; potwierdź je w Keyboard Shortcuts i w Cursor Settings.

Co zyskujesz dzięki tym wskazówkom o Tab

• Jasny obraz tego, co przewiduje Tab, i wnioski: gdzie stawiać kursor i które pliki edytować najpierw.
• Technikę dwóch przykładów i przepis na komentarz z intencją, dzięki którym pierwsza sugestia częściej jest trafna.
• Trzy prompty do skopiowania, które przekazują pracę z Tab do edycji inline (inline edit) i Agenta: jeden przepisuje szkielet, drugi sprawdza partię kodu z Tab, trzeci dowodzi, że testy napisane przez Tab potrafią nie przejść.
• Zestaw tanich bramek (sprawdzanie kompletności (exhaustiveness check), satisfies, testy w trybie watch), które wyłapują złą sugestię bez ponownego czytania każdej przyjętej linii.
• Tabelę typowych błędów Tab ze sposobem wyjścia z każdego z nich.

Jak Cursor Tab decyduje, co podpowiedzieć?

Tab pracuje na tym, co jest w pobliżu kursora, i na twojej ostatniej edycji. Poniższe podrozdziały wyjaśniają, co przewiduje, jak postawić wzorzec w jego polu widzenia i do jakich zadań się nadaje.

Tab przewiduje następną edycję, nie następne słowo

Klasyczne autouzupełnianie kończy token, który właśnie wpisujesz. Cursor Tab proponuje edycję: potrafi przepisać kilka linii wokół kursora, a po przyjęciu jednej zmiany może zaproponować skok do następnego miejsca, które wymaga powiązanej zmiany. W praktyce jedna przyjęta sugestia bywa pierwszym krokiem krótkiej sekwencji:

• Zmieniasz nazwę parametru, a Tab proponuje tę samą zmianę przy kolejnym użyciu.
• Dodajesz pole do jednego literału obiektu, a Tab proponuje je w sąsiednim literale poniżej.
• Dodajesz wywołanie nowego helpera, a Tab proponuje potrzebny import.

Traktuj każde naciśnięcie Tab jako przyjęcie jednego kroku sekwencji i sprawdzaj każdy krok na bieżąco. Łańcuch dziesięciu przyjętych edycji to dziesięć decyzji, nie jedna.

Postaw wzorzec tam, gdzie Tab go widzi

Tab przewiduje na podstawie kodu wokół kursora i twojej ostatniej edycji. Praktyczna zasada wynika z tego wprost: zanim poprosisz Tab o kontynuację wzorca, spraw, żeby wzorzec był widoczny. Zanim napiszesz nowy endpoint, upewnij się, że najbliższy istniejący jest w tym samym pliku, najlepiej bezpośrednio nad miejscem nowego kodu, albo zrób pierwszą zmianę ręcznie, żeby Tab miał edycję do kontynuowania. Sugestia ignorująca twoje konwencje zwykle oznacza, że potrzebnego przykładu nie było w pobliżu kursora.

Świadomy dobór kontekstu dla agenta (wzmianki @, reguły, indeksowanie) opisuje strona zarządzanie kontekstem w Cursorze. Tab nie ma pola na wzmianki @ (linia Cursor 3.x, stan na 26 września 2026 roku); sterujesz nim kodem, który umieszczasz w pobliżu kursora. Reguły działają tylko w Agencie, a nie w podpowiedziach Tab (pomoc Cursora, sprawdzone 2026-10-12).

Używaj Tab do „więcej tego samego”, nie do czegoś nowego

Siłą Tab jest kontynuacja. Gdy następna edycja jest wariantem czegoś, co już widać na ekranie, Tab jest najszybszym trybem pracy w Cursorze. Gdy następna edycja wymaga decyzji, której nie widać nigdzie w kodzie, użyj trybu, który przyjmuje polecenie (edycja inline albo Agent).

Następna edycja to…	Użyj	Dlaczego
Czwarte wystąpienie wzorca, gdy trzy są na ekranie	Tab	Wzorzec jest widoczny, więc sugestia jest w większości trafna
Zmiana jednego zaznaczonego bloku („dodaj retry z backoffem”)	Edycja inline	Musisz podać polecenie, którego kod nie zawiera
Zmiana w wielu plikach albo taka, która wymaga uruchomienia testów	Agent	Czyta, edytuje i uruchamia polecenia, a potem raportuje dowody
Logika biznesowa, której nikt jeszcze nie napisał	Agent ze specyfikacją albo ty	Tab może tylko zgadywać reguły, których nigdy nie widział

Przyjmij, przyjmij częściowo albo odrzuć sugestię Tab

Każda sugestia to wybór: bierzesz całość, część albo nic. Poniższe podrozdziały opisują klawisze, to, co sprawdzić przed przyjęciem, i łańcuch przyjętych edycji w powtarzalnej zmianie.

Bierz tylko tę część sugestii, która jest dobra

Nie musisz brać sugestii w całości:

• Tab przyjmuje całą sugestię.
• Częściowa akceptacja przyjmuje ją słowo po słowie. Ostatnio zgłaszany domyślny skrót to Cmd+Strzałka w prawo na macOS (Ctrl+Strzałka w prawo na Windows i Linuksie), stan na 26 września 2026 roku. Potwierdź skrót, wyszukując „partial” w edytorze Keyboard Shortcuts, i zajrzyj do ściągawki skrótów klawiszowych.
• Escape odrzuca sugestię.

Częściowa akceptacja opłaca się, gdy struktura jest dobra, a jedna wartość zła: weź wywołanie i pierwsze argumenty, a argument, który Tab pomylił, wpisz ręcznie.

Oceniaj sugestię po szczególe, który najpewniej jest błędny

Sugestia kopiująca wzorzec rzadko myli się w kształcie. Myli się w jedynym miejscu, w którym nowy przypadek się różni: nazwie encji, kodzie statusu, komunikacie błędu, ID w danych testowych (fixture). Spójrz najpierw tam, zdecyduj i idź dalej: przyjmij Tabem albo odrzuć Escape’em. Nadpisywanie w połowie przyjętej sugestii zostawia mieszankę twojej intencji i intencji Tab, a tę wersję najtrudniej później sprawdzić.

Przeprowadź Tab łańcuchem przez powtarzalną zmianę

Przy zmianie, która powtarza się w dół pliku (nowe pole w każdym zestawie danych testowych, zmieniona nazwa opcji w każdym wywołaniu), pozwól Tab ją przejść:

1. Zrób pierwszą zmianę ręcznie, dokładnie tak, jak ma wyglądać każde wystąpienie.
2. Naciśnij Tab, gdy pojawi się następna sugestia albo gdy Tab zaproponuje skok do kolejnego miejsca.
3. Przed każdym naciśnięciem sprawdź ten jeden szczegół, który zmienia się między wystąpieniami.
4. Przerwij łańcuch, gdy tylko sugestia jest błędna; popraw to wystąpienie ręcznie, a Tab podejmie pracę od twojej poprawionej edycji.
5. Po zakończeniu łańcucha uruchom testy pliku albo sprawdzanie typów.

Podsuń Tab wzorzec, żeby pierwsza sugestia była trafna

Trzy nawyki sprawiają, że pierwsza sugestia Tab jest tą, której chcesz: przykłady, komentarz z intencją i opisowe nazwy.

Napisz dwa przykłady, trzeci niech napisze Tab

Najpewniejszy sposób pracy z Tab: napisz ręcznie dwa wystąpienia wzorca, a potem postaw kursor tam, gdzie zaczyna się trzecie. Dwa przykłady pokazują Tab zarówno to, co stałe, jak i to, co zmienne.

// Napisane ręcznie:
it("returns 200 for an existing user", async () => {
  const res = await request(app).get("/api/users/1");
  expect(res.status).toBe(200);
  expect(res.body).toHaveProperty("id");
});

it("returns 404 for a missing user", async () => {
  const res = await request(app).get("/api/users/999");
  expect(res.status).toBe(404);
  expect(res.body.error).toBe("User not found");
});

// Wpisz tu `it(`. Tab zwykle proponuje kolejny przypadek w tym samym kształcie,
// na przykład 400 dla nienumerycznego ID. Sprawdź status i komunikat.

Zapisz intencję w komentarzu przed kodem

Komentarz nad pustą linią daje Tab jedyną rzecz, której otaczający kod nie zawiera: co zamierzasz zrobić dalej. Komentarz działa najlepiej, gdy nazywa zarówno warunek, jak i dokładną odpowiedź.

Komentarz z intencją do skopiowania: klauzula ochronna, którą Tab dokończy

// Reject the signup if the email is already registered.
// Respond 409 with { error: "Email already in use" } and stop.

Wklej te dwie linie nad miejscem wstawienia w handlerze, naciśnij Enter i poczekaj na Tab. Pierwsza linia podaje warunek, druga kształt odpowiedzi, więc sugestia powinna zawierać wyszukanie, wczesny return i dokładny komunikat. Jeśli Tab wymyśli inny komunikat albo status, odrzuć sugestię: komentarz jest specyfikacją, a kod ma się z nią zgadzać.

Komentarz usuń albo zostaw po fakcie, zależnie od jego wartości; komentarz powtarzający następną linię niczego do pliku nie wnosi.

Nazywaj zmienne tym, co przechowują

Tab czyta twoje identyfikatory. const data = await fetch(url) nie mówi mu nic o tym, co będzie dalej; const userProfileResponse = await fetch(`/api/users/${userId}/profile`) mówi o zasobie, o ID i o tym, że kolejne linie zapewne sprawdzą odpowiedź i sparsują profil. Opisowe nazwy nic nie kosztują, a usuwają zgadywanie z każdej następnej sugestii.

Gdzie Tab sprawdza się najlepiej i jaka bramka go kontroluje

Każdy z poniższych wzorców to przypadek, w którym Tab zwykle trafia, w parze z kontrolą, która go łapie, gdy nie trafi. Bramka jest ważniejsza niż wzorzec: to ona pozwala przyjmować sugestie szybko.

Instrukcje switch ze sprawdzeniem kompletności

Pierwszy case napisz ręcznie, a resztę Tab zaproponuje na podstawie typu unii. Dodaj sprawdzenie kompletności (exhaustiveness check), żeby brakujący albo błędnie wpisany case był błędem kompilacji, a nie czymś, co musisz wypatrzyć:

type Status = "pending" | "active" | "suspended" | "deleted";

function statusLabel(status: Status): string {
  switch (status) {
    case "pending":
      return "Pending review";
    // Tab proponuje "active", "suspended" i "deleted" w tym samym kształcie.
    default: {
      const unhandled: never = status;
      throw new Error(`Unhandled status: ${unhandled}`);
    }
  }
}

Jeśli Tab pominie któryś element unii, status w gałęzi default nie jest typu never i sprawdzanie typów nie przechodzi. Dodanie nowego statusu w przyszłości zatrzyma build w ten sam sposób.

Obiekty konfiguracyjne sprawdzane przez satisfies

Tab dobrze wypełnia obiekty konfiguracyjne, gdy zobaczy dwie lub trzy właściwości. Wypełnia je też wiarygodnymi wartościami, które nie są twoje. Przywiąż obiekt do jego typu, żeby wymyślony albo źle napisany klucz nie przechodził:

const dbConfig = {
  host: "localhost",
  port: 5432,
  // Tab proponuje database, user, rozmiar puli itd. na podstawie typu i kodu obok.
} satisfies DatabaseConfig;

satisfies odrzuca właściwość, której typ nie deklaruje, i brak wymaganej, zachowując przy tym typy literałów. Nie wyłapie natomiast złej wartości poprawnego typu, na przykład rozmiaru puli skopiowanego z innej usługi. Wartości zależne od środowiska należą do zmiennych środowiskowych, a nie do tego, co Tab widział ostatnio.

Przypadki testowe, a potem dowód, że testy potrafią nie przejść

Przy otwartej w edytorze implementacji zacznij blok describe w pliku testów, napisz jeden przypadek ręcznie i pozwól Tab zaproponować kolejne. Testy napisane przez Tab mają typowy słaby punkt: potrafią sprawdzać, co kod robi, zamiast tego, co powinien robić, więc przechodzą mimo błędu. Zanim im zaufasz, udowodnij, że potrafią nie przejść.

Prompt dla Agenta do skopiowania: udowodnij, że testy z Tab łapią błąd

The tests in src/orders/calculateOrderTotal.test.ts were written mostly with Tab. Check that they can fail.
1. In src/orders/calculateOrderTotal.ts, make three separate temporary mutations, one at a time: remove the discount, apply tax before the discount instead of after, and change `>=` to `>` in the free-shipping threshold.
2. After each mutation, run `npx vitest run src/orders/calculateOrderTotal.test.ts` and record which tests fail.
3. Revert each mutation before the next one. Confirm with `git diff --stat` that calculateOrderTotal.ts is unchanged at the end.
Report a table: mutation, tests that failed. If a mutation fails no test, propose the missing test case but do not add it.

Mutacja, której nie łapie żaden test, wskazuje test, który wciąż musisz napisać, a to lepsze wykorzystanie uwagi niż ponowne czytanie testów od Tab. Pełną pętlę test-first w Cursorze opisuje strona TDD w Cursorze.

Przekaż pracę z Tab do edycji inline i Agenta

Tab przestaje być właściwym narzędziem, gdy zmiana wymaga reguły, której nie ma w kodzie, sprawdzenia wielu przyjętych linii albo pracy w ogóle bez sugestii. Poniższe podrozdziały opisują każde z tych przekazań.

Szkielet z Tab, rdzeń przepisany przez edycję inline

Tab szybko pisze to, co się powtarza: sygnaturę, kształt walidacji, obsługę błędów, typ zwracany. Nie zna jednak reguły biznesowej, której nie ma nigdzie w kodzie. Niech Tab zbuduje szkielet, a potem zaznacz ciało funkcji i podaj regułę przez edycję inline (domyślnie Cmd+K na macOS, Ctrl+K na Windows i Linuksie; potwierdź w ściągawce skrótów klawiszowych).

Prompt do edycji inline do skopiowania: zastąp szkielet z Tab prawdziwą regułą

Replace the body of this function. A discount code is valid only if: it exists in Redis under `discount:<code>`, its `expiresAt` is in the future, and its `uses` is below `maxUses`. Return { valid: false, reason } with reason "not_found", "expired" or "exhausted" for the three failures. Keep the signature, the existing error type and the early-return style of this file. Do not increment `uses` here.

Po wprowadzeniu zmiany Tab podejmuje pracę od nowego kodu: zwykle proponuje pasujące przypadki testowe albo zmiany w miejscach wywołań, a dla nich obowiązują te same bramki.

Sprawdź partię kodu z Tab bez czytania każdej linii

Godzina przyjmowania sugestii Tab daje diff, w którym każda linia wyglądała wiarygodnie w chwili przyjęcia. Czytanie go całego od nowa to wolna ścieżka. Strukturę oddaj bramkom, a swoją uwagę (albo uwagę agenta) skieruj na szczegóły, które przy kopiowaniu wzorców się psują.

1. Trzymaj sprawdzanie typów i test runner w trybie watch podczas pracy (npx tsc --noEmit --watch i npx vitest albo odpowiedniki w twoim stosie). Zła sugestia Tab, która psuje typ albo test, wychodzi kilka sekund po przyjęciu, a nie dopiero w CI.
2. Uruchamiaj linter przy zapisie. Nieużywane importy, przesłonięte zmienne i nieosiągalny kod to typowe pozostałości łańcucha, który poszedł o krok za daleko.
3. Przed commitem poproś Agenta o celowane sprawdzenie szczegółów, które psują się przy kopiowaniu wzorców — promptem poniżej. Agent czyta diff, a ty czytasz tylko jego ustalenia.
4. Podpisujesz się pod zmianą przy commicie. Tab nigdy nie commituje, a klawisz akceptacji to nie code review. Commit to moment, w którym na podstawie dowodów z kroków 1–3 decydujesz, że ta partia jest twoja.

Prompt dla Agenta do skopiowania: przegląd diffu z Tab pod kątem skopiowanych szczegółów

Review my uncommitted changes in src/routes/ and tests/routes/. Most of them were written by accepting Tab suggestions that copied an existing pattern, so the structure is probably right and the details may not be.
For every new or changed function and test, check only the details a copied pattern gets wrong: entity and resource names, HTTP status codes, error messages, field names, route paths and IDs in test fixtures. Compare each against the function's name and the route it serves.
List each mismatch as file:line, what it says, what it should say. Then run `npx tsc --noEmit` and `npx vitest run routes` (or your project's typecheck and test scripts) and paste the summary lines. Do not edit any file.

Szerzej o ufaniu dowodom zamiast czytania kodu linia po linii: dowody zamiast diffów.

Wyłącz Tab tam, gdzie kosztuje więcej, niż daje

Sugestie Tab w prozie, dużych plikach danych albo w ręcznie pisanym algorytmie, nad którym właśnie myślisz, mogą kosztować więcej uwagi, niż oszczędzają. Cursor Tab to własny model Cursora, a nie IntelliSense z VS Code, więc konfiguruje się go w Cursor Settings, a nie przez ustawienia editor.suggest.* z VS Code.

We wcześniejszych wersjach 3.x pozycja Cursor Tab na pasku stanu pozwalała uśpić Tab i wyłączyć go dla wybranych rozszerzeń plików (np. md czy json), a Cursor Settings miało sekcję Tab. Tych przełączników nie sprawdzono ponownie 26 września 2026 roku, więc w swojej wersji znajdziesz je, wyszukując „Tab” w Cursor Settings.

Jeśli twoja wersja je ma, uśpienie sprawdza się przy godzinie skupionej pracy poza kodem, a wyłączenie dla rozszerzenia — gdy cały typ plików stale generuje szum.

Kiedy sugestie Tab zawodzą

Objaw	Prawdopodobna przyczyna	Co zrobić
Sugestia ma dobry kształt i złą wartość (kod statusu, komunikat, nazwę)	Tab skopiował najbliższy przykład razem ze szczegółem, który miał się zmienić	Przyjmij częściowo strukturę i wpisz wartość; przed commitem uruchom prompt do przeglądu diffu
Po migracji Tab wciąż proponuje stary wzorzec (komponenty klasowe, przestarzały klient)	Stary wzorzec jest tym, co leży przy kursorze	Zmigruj ręcznie jedno lub dwa wystąpienia w tym samym pliku albo tuż nad kodem; Tab kontynuuje od ostatnich edycji
Tab importuje symbol z niewłaściwego pakietu	Kilka pakietów eksportuje tę samą nazwę	Odrzuć, napisz raz poprawny import na górze pliku i pracuj dalej; jeśli zły import już wszedł, wyłapie go sprawdzanie typów
Wszystkie testy z Tab przechodzą, także przy znanym błędzie	Testy sprawdzają obecne zachowanie, a nie zamierzone	Uruchom prompt z mutacjami; dopisz przypadki, których brak wykazał
Tab proponuje realnie wyglądający URL, klucz albo nazwę hosta	Kontynuuje literał, który widział gdzie indziej w pliku	Odrzuć; pobierz wartość z konfiguracji albo zmiennej środowiskowej. Przed commitem przeszukaj diff pod kątem literałów
Klawisz Tab nic nie robi albo wstawia inne uzupełnienie	Inne rozszerzenie uzupełniające, np. GitHub Copilot, używa tego samego klawisza albo Tab jest uśpiony	Sprawdź, czy Tab nie jest uśpiony albo wyłączony (wyszukaj „Tab” w Cursor Settings); wyłącz podpowiedzi inline drugiego rozszerzenia w tym obszarze roboczym (workspace)
Długi łańcuch zboczył i nie wiesz, które edycje były dobre	Kilka przyjętych kroków powieliło jeden wczesny błąd	Zatrzymaj się, uruchom sprawdzanie typów i testy, cofnij do ostatniego zielonego stanu zamiast łatać do przodu

Co dalej z edycją w Cursorze

• Przed tą stroną: podstawowe funkcje Cursora — jak wybierać między Tab, edycją inline a Agentem.
• Dalej: edycja inline w Cursorze — polecenia stosowane do zaznaczenia, naturalny partner kontynuacji z Tab.
• Potem: praca z czatem agenta w Cursorze — zmiany obejmujące wiele plików i wymagające uruchamiania poleceń.
• O samych bramkach: TDD w Cursorze.
• O miejscu Tab w szerszym obrazie: poziomy 1–2 drabiny autonomii, czyli kodowanie wspomagane i w parze.