Edycja inline w Cursorze: wskazówki 46–60

Edycja inline w Cursorze przepisuje zaznaczony kod według krótkiej instrukcji w języku naturalnym albo wstawia nowy kod w miejscu kursora, gdy nic nie jest zaznaczone. Zaznaczenie wyznacza granicę zmiany, więc jego zakres decyduje o wyniku w tym samym stopniu co treść instrukcji. Edycja inline pasuje do zmian w jednym pliku, które potwierdzi sprawdzenie typów albo test tej jednej funkcji.

Ta strona jest dla programistów, którzy korzystają już z agenta i z Tab w Cursorze, ale edycja inline daje im wyniki jak rzut monetą. Zaznaczasz 60-liniową funkcję, piszesz „zrób to lepiej” i dostajesz przeróbkę, która zmieniła nazwy dwóch zmiennych, usunęła klauzulę ochronną i dodała nieużywany import. Potem czytasz cały diff linijka po linijce, co trwa dłużej niż ręczne wpisanie zmiany. Rozwiązaniem jest węższe zaznaczenie, instrukcja nazywająca jedną transformację i jej granice oraz bramka, która sprawdzi wynik za ciebie.

Co zyskasz dzięki tym wskazówkom do edycji inline

Tabelę zaznaczeń: co zaznaczasz, co edycja inline może zmienić i jakie sprawdzenie kończy edycję.
Siedem gotowych instrukcji do edycji inline: wygenerowanie funkcji pomocniczej, powtórzenie wzorca z pliku, konwersja struktury, obsługa błędów, przejście z JavaScriptu na ścisły TypeScript, wydzielenie „magicznych” wartości i napisanie testów.
Sposób łączenia edycji przy refaktoryzacji: najpierw utrwal zachowanie testem, potem jedna transformacja na edycję i bramka między edycjami.
Sprawdzenie oparte na czterech sygnałach, które potwierdza edycję inline bez czytania każdej linii, oraz tabelę, kiedy przejść do agenta.

Jak zaznaczenie wpływa na edycję inline?

Wskazówka 46: Dopasuj zaznaczenie do zmiany, której chcesz

Edycja inline traktuje zaznaczenie jako granicę: przepisuje to, co zaznaczyłeś, a resztę pliku zostawia w spokoju. Zbyt szerokie zaznaczenie kusi model do poprawek, o które nie prosiłeś. Zaznaczenie mniejsze niż zmiana daje kod, który przestaje pasować do otoczenia.

Co zaznaczasz	Co zmienia edycja inline	Do czego się nadaje	Sprawdzenie, które ją kończy
Nic (kursor w pustej linii)	Wstawia nowy kod w miejscu kursora	Funkcja pomocnicza, typ, mały blok opisany krótką instrukcją	Sprawdzenie typów, potem test, który go wywołuje
Jedna lub dwie linie	Te linie	Warunek, wartość zwracana, pojedyncze wyrażenie	Przeczytaj te linie sam, potem sprawdzenie typów
Cała funkcja	Ciało funkcji, a sygnaturę tylko wtedy, gdy na to pozwolisz	Obsługa błędów, konwersja struktury, walidacja wejścia	Testy jednostkowe tej funkcji
Kilka powiązanych funkcji	Wszystkie jako jedną całość	Ta sama zmiana wprowadzona spójnie, np. logowanie w trzech handlerach	Testy każdej funkcji oraz `git diff --stat` pokazujący jeden plik

Zaznacz najmniejszy blok, który zawiera każdą linię do zmiany. Żeby zmienić dwie linie w 60-liniowej funkcji, zaznacz te dwie linie, a nie całą funkcję.

Wskazówka 47: Umieść kontekst w zaznaczeniu albo w instrukcji

W praktyce edycja inline pracuje na zaznaczeniu i otaczającym je pliku. Nie otwiera niezawodnie typu ani funkcji pomocniczej z innego pliku, więc zgaduje ich kształt, a zgadnięty kod kompiluje się tylko przypadkiem.

Gdy typ jest w tym samym pliku, rozszerz zaznaczenie w górę, tak aby go obejmowało:

// Zaznacz typ razem z funkcją, potem uruchom edycję inline.
type UserRole = 'admin' | 'editor' | 'viewer';

function getPermissions(role: UserRole): Permission[] {
  // ...
}

Gdy typ jest gdzie indziej, podaj jego kształt w instrukcji: „User ma id: string, email: string i role: UserRole”. Jeśli zmiana wymaga więcej niż dwóch takich faktów, w praktyce obejmuje kilka plików i wtedy stosuje się wskazówkę 60.

Wskazówka 48: Generuj w pustej linii mały, samodzielny kod

Gdy kursor stoi w pustej linii i nic nie jest zaznaczone, edycja inline pisze nowy kod w tym miejscu. To lżejsze niż otwieranie agenta dla bloku, który opiszesz krótką instrukcją. Traktuj edycję inline jako narzędzie, które pisze tylko w miejscu kursora albo w zaznaczeniu; tworzenie plików, edycja innych plików i uruchamianie poleceń to zadanie agenta.

Write a generic TypeScript debounce(fn, waitMs) that returns a function with the same
parameter types as fn plus a cancel() method. A new call cancels the pending one.
Preserve `this` and the arguments of the last call. No external dependencies. Export
it.

Następnie napisz sam albo poproś agenta o test z fałszywymi zegarami (fake timers), który udowodni, że drugie wywołanie w czasie waitMs anuluje pierwsze. Wygenerowana funkcja bez testu to kod niezweryfikowany.

Jak napisać instrukcję do edycji inline, która trafia za pierwszym razem?

Wskazówka 49: Nazwij jedną transformację i to, co ma się nie zmienić

Nazwij transformację, a potem niezmienniki. To niezmienniki powstrzymują przeróbkę przed rozlaniem się poza zmianę, o którą prosisz.

Ogólnikowo	Konkretnie
„Zrób to lepiej”	„Zwracaj wcześniej dla null, undefined i pustego ciągu znaków, rzucając `TypeError` z nazwą parametru. Nie zmieniaj ścieżki sukcesu.”
„Zoptymalizuj”	„Zastąp zagnieżdżone pętle wyszukiwaniem w `Set`, tak aby funkcja była liniowa względem rozmiaru wejścia. Zachowaj kolejność wyniku.”
„Popraw typy”	„Dodaj jawne typy do każdego parametru i wartości zwracanej. Bez `any`. Zachowaj kolejność parametrów w sygnaturze.”

Dobrym domyślnym zakończeniem każdej instrukcji jest „Do not change the signature, the return type or any line outside the selection.”

Wskazówka 50: Wskaż wzorzec, który już jest w pliku

Gdy ten sam plik zawiera już wzorzec, o który ci chodzi, nazwij go. Edycja inline widzi resztę pliku, więc nazwany przykład działa lepiej niż akapit opisujący wzorzec.

Add error handling to this handler that matches handleUserCreation above: the same
try/catch structure, the same logger.error call shape with the handler name and
request ID, and the same mapping from ValidationError to 400 and NotFoundError to 404.
Do not change the success path or the function signature.

Jeśli wzorzec jest w innym pliku, wklej jego krótki przykład do instrukcji albo zapisz go w regule projektu, tak aby widziała go każda edycja.

Wskazówka 51: Przy zmianach strukturalnych pisz „convert X to Y”

Konwersja daje edycji inline jasny stan przed i po, dlatego to najbardziej niezawodny kształt instrukcji: callbacki na async/await, switch na obiekt z mapowaniem, komponent klasowy na funkcyjny z hookami albo pętla na map i filter. Zawsze dopisz zachowanie, które musi przetrwać konwersję.

Convert this callback-based function to async/await. Keep the exported name and
every parameter except the trailing callback, which you remove; return a Promise
instead. Every error the callback version passed as its first argument must now
reject with the same Error object. Keep the retry loop and its three-attempt limit exactly as it is.

Po konwersji trzeba zaktualizować miejsca wywołań. Leżą poza zaznaczeniem, więc w tym momencie pracę przejmuje agent, a nie edycja inline.

Jak łączyć edycje inline w refaktoryzacji?

Wskazówka 52: Przed pierwszą edycją utrwal zachowanie testem

Seria przeróbek jest bezpieczna tylko wtedy, gdy coś mówi ci, że zachowanie się nie zmieniło. Dla kodu bez testów poproś agenta o testy charakteryzacyjne, które zapiszą, co funkcja robi dziś, łącznie z dziwnymi przypadkami, zanim cokolwiek zmienisz. Technikę szczegółowo opisują testy charakteryzacyjne.

Before I refactor calculateInvoiceTotal in src/billing/invoice.ts, write
characterization tests in src/billing/invoice.characterization.test.ts that record
what it returns today: an empty cart, one line, a discount above the subtotal, a
negative quantity, and a currency with no minor unit. Assert the current outputs even
where they look wrong, and mark those cases with a comment. Do not change invoice.ts.
Run npx vitest run src/billing/ and show me the passing output.

Te testy są wyrocznią dla całej serii. Jeśli edycja zmieni je na czerwone, zmieniła zachowanie. Odrzuć ją zamiast poprawiać test.

Wskazówka 53: Jedna transformacja na edycję i bramka między edycjami

Jedna instrukcja „dodaj typy, walidację i obsługę błędów” daje jeden duży diff, który sprawdzisz tylko czytając go. Trzy edycje dają trzy małe diffy, a każdy sprawdza polecenie.

Zaznacz funkcję i uruchom edycję inline: „Add explicit types to every parameter and the return value. No any.”
Bramka: npx tsc --noEmit. Akceptuj dopiero, gdy kończy się kodem 0.
Uruchom edycję inline ponownie: „Validate each parameter against the types above and throw a TypeError naming the parameter.”
Bramka: npx vitest run src/billing/. Testy charakteryzacyjne muszą przechodzić bez zmian.
Uruchom edycję inline ponownie: „Wrap the database call in try/catch and rethrow as AppError, preserving the cause.”
Bramka: ten sam przebieg testów oraz npx eslint src/billing/invoice.ts.
Zrób commit. Każdy commit jest wtedy punktem kontrolnym w Gicie, do którego możesz wrócić, niezależnie od punktów kontrolnych samego Cursora.

Ułóż serię tak, aby żaden krok nie cofał wcześniejszego. „Dodaj logowanie”, a po nim „usuń wszystkie efekty uboczne” zostawia niespójny kod.

Wskazówka 54: Dopracuj wynik agenta edycją inline

Agent szybko tworzy szkic modułu, a w kilku miejscach mija się z konwencjami zespołu. Poprawienie tych miejsc edycją inline jest tańsze niż kolejna runda z agentem, bo każda poprawka jest lokalna, a reszta szkicu zostaje na miejscu.

Pozwól agentowi skończyć i najpierw niech przejdzie jego własna bramka (testy i sprawdzenie typów).
Zaznacz jedną funkcję i uruchom edycję inline, na przykład: „Rename boolean parameters to start with is or has, and update their uses inside this function only.”
Zaznacz blok throw new Error(...) i uruchom edycję inline: „Throw AppError from @/lib/errors with the same message and a code field.”
Uruchom tę samą bramkę co agent. Poprawka konwencji, która psuje test, nie była poprawką konwencji.

Które transformacje najlepiej pasują do edycji inline?

Wskazówka 55: Dodaj obsługę błędów do kodu, który zna tylko ścieżkę sukcesu

Add error handling to this function. Catch only errors from the fetch call and the
JSON parse. Retry a network error once after 1 second. Throw a validation error
immediately with a message naming the bad field. Log unexpected errors with the
function name and rethrow them. Never swallow an error. Do not change the signature.

Sprawdź to testem, w którym fetch raz się nie udaje, a potem przechodzi, oraz testem zwracającym niepoprawny JSON.

Wskazówka 56: Przejdź z JavaScriptu na ścisły TypeScript

Convert this code to TypeScript that passes strict mode. No `any`; use `unknown` and
narrow it where the input is untrusted. Declare an interface for every object
parameter and return value. Mark optional properties with `?`. Reuse types already
declared in this file instead of inventing new ones.

Bramką jest npx tsc --noEmit z włączonym strict. Konwersja, która potrzebuje nowego // @ts-expect-error, ukrywa problem z typami zamiast go rozwiązać. Odrzuć ją.

Wskazówka 57: Wydziel „magiczne” liczby i ciągi znaków

Extract every magic number and string literal in the selection into named constants
declared directly above it, in SCREAMING_SNAKE_CASE. Group related constants. Add a
one-line comment only where the name does not explain the value. Behaviour must not
change: every constant keeps its exact current value.

Ta edycja nie zmienia zachowania, więc istniejące testy muszą przejść bez żadnych zmian w samych testach.

Wskazówka 58: Napisz testy na podstawie implementacji, a potem udowodnij, że mogą paść

Edycja inline pisze tylko w miejscu kursora, więc uruchom ją w pustej linii pliku testowego, a nie pliku źródłowego, i wklej do instrukcji sygnaturę funkcji, żeby model wiedział, co testuje. Testy pisane na podstawie implementacji zwykle potwierdzają to, co kod robi, razem z błędami, więc zielony przebieg niewiele dowodzi, dopóki nie zobaczysz, że testy potrafią paść.

Write Vitest tests for this function: <paste the signature, for example
export function parsePrice(input: string): number | null>. Cover the typical
case, the empty input, zero and boundary values, null or undefined arguments, and, if it is async, both the resolve
and the reject path. Name each test after the scenario, not the function. Assert
specific values, never toBeDefined() or toBeTruthy() alone.

Zaakceptuj testy, potem celowo zepsuj funkcję, na przykład zamieniając < na <=, i uruchom testy. Co najmniej jeden musi paść. Cofnij zmianę. Zestaw, który zostaje zielony, to dekoracja. TDD w Cursorze opisuje, jak napisać testy najpierw.

Jak sprawdzić edycję inline bez czytania każdej linii?

Wskazówka 59: Zanim zaakceptujesz, użyj czterech sygnałów

Edycja inline proponuje zmianę jako diff do zaakceptowania albo odrzucenia. Czytaj diff pod kątem jego kształtu, nie linijka po linijce, a o treści niech rozstrzygają polecenia:

Zakres. Zmienione linie leżą w twoim zaznaczeniu. Po akceptacji git diff --stat pokazuje jeden plik z mniej więcej oczekiwaną liczbą linii (najpierw zrób commit albo stash, albo porównaj z ostatnim commitem, żeby statystyka pokazała tylko tę edycję). Cokolwiek innego znaczy, że zaznaczenie albo instrukcja były zbyt luźne.
Usunięcia i importy. Przejrzyj tylko czerwone linie i każdy nowy import. Usuniętą klauzulę ochronną czy nieużywany import widać tu w kilka sekund.
Typy i lint. npx tsc --noEmit i npx eslint <plik> kończą się kodem 0. Trzymaj sprawdzanie typów w trybie watch (npx tsc --noEmit --watch), żeby ten sygnał pojawił się, zanim skończysz czytać.
Zachowanie. Testy tego modułu przechodzą, a przy refaktoryzacji testy charakteryzacyjne ze wskazówki 52 przechodzą bez zmian.

Zatwierdzasz edycję, gdy wszystkie cztery sygnały są zielone, a potem robisz commit. Pull request dodaje drugą bramkę: CI uruchamia pełny zestaw testów, a recenzent albo bot do code review widzi łączny diff. Dowody zamiast diffów wyjaśnia, dlaczego taka kolejność sprawdzeń skaluje się lepiej niż czytanie każdego diffu.

Wskazówka 60: Przejdź do agenta, gdy zmiana wychodzi poza zaznaczenie

Sygnał	Zostań przy edycji inline	Przejdź do agenta
Zmieniane pliki	Jeden plik, w obrębie jednego zaznaczenia	Dwa lub więcej albo trzeba zaktualizować wywołania
Potrzebny kontekst	W zaznaczeniu, w tym samym pliku albo dwa fakty w instrukcji	Typy i funkcje pomocnicze z całej bazy kodu
Dowód	Po akceptacji uruchamiasz jedno polecenie	Zmiana wymaga pętli: napisz, przetestuj, popraw
Długość instrukcji	Jedna transformacja plus jej niezmienniki, najwyżej krótki akapit	Kilka transformacji albo brzmi jak plan

Gdy przechodzisz do agenta, przenieś tę samą dyscyplinę do promptu: testy definiujące „gotowe” i polecenia, które stanowią bramkę. Praca z czatem agenta w Cursorze pokazuje taki kształt promptu, a tryby agenta w Cursorze opisują, kiedy najpierw zaplanować.

Gdy edycja inline w Cursorze zawodzi

Objaw	Prawdopodobna przyczyna	Wyjście z sytuacji
Przeróbka zmieniła więcej, niż prosiłeś	Zaznaczenie było większe niż zmiana albo instrukcja nie miała niezmienników	Odrzuć, zaznacz tylko linie do zmiany i dopisz „Do not change anything else”
Kod używa typu lub pola, które nie istnieje	Typ jest w innym pliku	Odrzuć, podaj kształt typu w instrukcji albo użyj agenta
Diff wygląda dobrze, ale test pada	Zmiana zachowania ukryta w refaktoryzacji, często przestawiony warunek albo usunięty wczesny `return`	Cofnij poleceniem Undo w edytorze albo `git restore <plik>`, potem podziel edycję na mniejsze kroki
Wszystkie wygenerowane testy przechodzą, nawet na zepsutym kodzie	Testy powtarzają implementację	Celowo zepsuj kod i przepisz każdy test, który zostaje zielony, na konkretne oczekiwane wartości
Każda edycja w serii cofa poprzednią	Sprzeczne kroki	Wróć do ostatniego zielonego commita i ułóż serię tak, aby każdy krok budował na poprzednim
W każdej edycji trzeba poprawiać tę samą konwencję	Konwencja istnieje tylko w twojej głowie	Zapisz ją w regule projektu, żeby widziały ją i edycja inline, i agent

Jeśli zaakceptowałeś już kilka edycji, a testy są czerwone, nie proś o poprawkę na wierzchu. Wróć do ostatniego commita, przy którym bramka przechodziła, i powtórz serię mniejszymi krokami.

Dokąd dalej po edycji inline

Przed tą stroną: podstawowe funkcje Cursora, wskazówki 16–30 oraz autouzupełnianie Tab w Cursorze, wskazówki 31–45, które przekazuje szkielet z Tab do edycji inline.
Dalej: praca z czatem agenta w Cursorze, dla zmian obejmujących kilka plików i wymagających pętli: napisz, przetestuj, popraw.
Przy większych przebudowach: strategie refaktoryzacji w Cursorze i instrukcje wielokrotnego użytku w szablonach promptów dla Cursora.
Jeśli obok Cursora używasz Claude Code: koordynacja IDE i CLI pokazuje, jak nie dopuścić, by edycja inline i CLI pisały do tego samego pliku.