Oszczędności czasu

Jest 14:00 i spędziłeś ranek na funkcji, która powinna być prosta. Ale między ręcznym pisaniem JSDoc dla 8 funkcji, naprawianiem tego samego błędu ESLint w 12 plikach, kopiowaniem-wklejaniem tego samego wzorca obsługi błędów do 4 nowych endpointów i wpisywaniem wiadomości commita dokładnie opisującej twoje zmiany, straciłeś godzinę na zadania nie wymagające żadnej kreatywnej myśli. Żadne z tych zadań nie są trudne. Po prostu są żmudne, powtarzalne i stałe.

Oszczędności czasu w tym przewodniku nie są dramatyczne. Każda oszczędza 10 do 60 sekund. Ale robisz większość z nich dziesiątki razy dziennie i kilka z nich dziesiątki razy tygodniowo. Gdy je dodasz, odzyskujesz 5 do 10 godzin tygodniowo — nie przez szybszą pracę, ale przez eliminowanie pracy, która nie powinna wymagać ludzkiej uwagi w pierwszej kolejności.

Co wyniesiesz

• Prompty szybkich wygranych dla najczęstszych powtarzalnych zadań
• Wzorce przepływu pracy, które grupują podobne operacje razem
• Reguły automatyzujące konwencje, które obecnie wymuszasz ręcznie
• Priorytetową listę optymalizacji posortowaną według zaoszczędzonego czasu tygodniowo

Natychmiastowe generowanie dokumentacji

Pisanie dokumentacji dla funkcji, komponentów i modułów to jedno z najbardziej pomijanych zadań w rozwoju oprogramowania, ponieważ stosunek kosztu do korzyści wydaje się zły: 30 sekund pisania za coś, co ma znaczenie tylko później. AI odwraca to równanie.

Wskazówka

Prompt do skopiowania-wklejenia dla zbiorczej dokumentacji:

Dodaj dokumentację JSDoc do każdej wyeksportowanej funkcji w @src/services/order-service.ts.

Dla każdej funkcji:
- Opisz, co robi w jednym zdaniu
- Dokumentuj każdy parametr z jego typem i celem
- Dokumentuj typ zwracany i co zawiera
- Dodaj @throws dla wszelkich błędów, które funkcja może rzucić
- Dodaj krótki @example, jeśli użycie nie jest oczywiste

NIE zmieniaj żadnego kodu implementacji. Tylko dodaj komentarze dokumentacji.

Uruchom to raz na plik po zakończeniu implementacji. AI zajmuje to 15 sekund, a tobie zajęłoby 5 minut ręcznego pisania.

Generowanie wiadomości commitów

Pisanie dobrych wiadomości commitów to dyscyplina, która opłaca się podczas debugowania i przeglądu kodu — ale jest również przeszkodą w twoim przepływie. Pozwól AI przeczytać twój diff i wygenerować wiadomość:

Wskazówka

Prompt do skopiowania-wklejenia dla wiadomości commitów:

Spójrz na staged changes (git diff --staged) i napisz wiadomość commita.

Format:
- Pierwsza linia: type(scope): description (poniżej 72 znaków)
- Typy: feat, fix, refactor, test, docs, chore
- Pusta linia
- Treść: 1-3 punkty wyjaśniające kluczowe zmiany i dlaczego zostały dokonane

Nie dołączaj nazw plików w wiadomości. Skup się na tym, co się zmieniło i dlaczego.

Zapisz to jako niestandardową komendę w .cursor/commands/commit-message.md, aby móc wywołać za pomocą /commit-message zamiast wklejać za każdym razem.

Operacje zbiorcze oszczędzające godziny

Konwersja wzorców w wielu plikach

Gdy musisz zastosować tę samą zmianę do wielu plików (dodawanie obsługi błędów, konwersja callbacków na async/await, aktualizacja ścieżki importu), grupowanie oszczędza masywnie czasu w porównaniu z edytowaniem każdego pliku indywidualnie:

Wskazówka

Prompt do skopiowania-wklejenia dla zbiorczych aktualizacji wzorców:

Znajdź każdy plik w @src/routes/ używający starego wzorca obsługi błędów:

  res.status(500).json({ error: error.message })

Zastąp go naszym standaryzowanym handlerem błędów:

  throw new AppError(500, error.message, { cause: error })

Importuj AppError z @src/lib/errors.ts w każdym pliku, który go jeszcze nie importuje.

Wprowadź zmiany plik po pliku. Uruchom `npm run build` po wszystkich zmianach, aby zweryfikować, że nic się nie zepsuło.

Ten rodzaj zbiorczej aktualizacji zajmuje 30 do 60 minut ręcznie w 15 plikach. Tryb Agent obsługuje to w 2 minuty.

Generowanie brakujących plików testowych

Wskazówka

Prompt do skopiowania-wklejenia dla zbiorczego generowania testów:

Spójrz na @src/services/ i zidentyfikuj każdy plik .ts, który nie ma odpowiadającego pliku testowego w __tests__/.

Dla każdego brakującego pliku testowego wygeneruj podstawowy pakiet testów pokrywający:
- Happy path dla każdej wyeksportowanej funkcji
- Jeden przypadek błędu na funkcję
- Mockowanie zewnętrznych zależności

Przestrzegaj wzorców testowych w @src/services/__tests__/user-service.test.ts.
Uruchom testy po ich wygenerowaniu.

To nie chodzi o osiągnięcie 100% pokrycia w jednym strzale — chodzi o przejście z 0% do 60% pokrycia w 5 minut zamiast 2 godzin, a następnie stopniowe ulepszanie stamtąd.

Auto-formatowanie i auto-naprawianie przy zapisie

Skonfiguruj Cursor do automatycznej obsługi formatowania i prostych poprawek lintowych, aby nigdy o nich nie myśleć:

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit",
    "source.organizeImports": "explicit"
  }
}

Eliminuje to całą kategorię komentarzy przeglądu (“fix the formatting,” “organize your imports”) i oszczędza od ręcznego uruchamiania npm run format.

Szybkie tworzenie szkieletów plików

Zamiast kopiować istniejący plik i ręcznie zmieniać wszystko, pozwól AI stworzyć szkielet nowych plików z twoich istniejących wzorców:

Wskazówka

Prompt do skopiowania-wklejenia dla szkieletu pliku:

Stwórz nowy plik serwisu w src/services/notification-service.ts według dokładnej struktury @src/services/email-service.ts.

Zastąp:
- Nazwa klasy: EmailService -> NotificationService
- Nazwy metod: dostosuj do domeny notyfikacji (sendNotification, getNotificationHistory, markAsRead)
- Typy: stwórz interfejsy NotificationPayload i NotificationResult
- Zależności: zachowaj ten sam wzorzec DI, ale z zależnościami specyficznymi dla notyfikacji

Również stwórz plik testowy w src/services/__tests__/notification-service.test.ts według struktury testowej @src/services/__tests__/email-service.test.ts.

Dwa pliki ze szkieletem w 30 sekund zamiast 10 minut kopiowania-wklejania-zmiany nazw.

Reguły automatyzujące konwencje

Zamiast pamiętać o dodawaniu obsługi błędów, logowania i walidacji za każdym razem, gdy tworzysz nowy endpoint, zakoduj te konwencje w regułach, które stosują się automatycznie:

---
globs: "src/routes/**/*.ts"
---

Every route handler in this project must:
1. Validate the request body using the Zod schema from @src/schemas/
2. Wrap the handler body in a try/catch
3. Log the request at the start: logger.info('[ROUTE_NAME] request received', { userId })
4. Log errors at the catch: logger.error('[ROUTE_NAME] failed', { error, userId })
5. Return errors using AppError from @src/lib/errors.ts
6. Include the route in the route registry at @src/app.ts

Follow the exact pattern in @src/routes/users.ts.

Ta reguła uruchamia się automatycznie, gdy Agent tworzy lub modyfikuje plik trasy. Nigdy nie musisz mu przypominać.

Szybkie edycje inline z Cmd+K

Dla małych, ukierunkowanych zmian Cmd+K (edycja inline) jest szybszy niż przełączanie na tryb Agent:

• Zaznacz funkcję i naciśnij Cmd+K: “add input validation”
• Zaznacz blok i naciśnij Cmd+K: “handle the null case”
• Zaznacz nazwę zmiennej i naciśnij Cmd+K: “rename to currentUser across this file”
• Zaznacz try/catch i naciśnij Cmd+K: “add logging and re-throw”

Każde z tych zajmuje 3 do 5 sekund. Równoważna interakcja w trybie Agent (przełącz na czat, opisz zmianę, poczekaj, aż agent przeczyta plik, przejrzyj diff) zajmuje 30 do 60 sekund dla tego samego rezultatu.

Zasada praktyczna: jeśli twoja zmiana to jedno zdanie, użyj Cmd+K. Jeśli to akapit, użyj trybu Agent.

Szybkie prototypowanie z uzupełnianiem Tab

Uzupełnianie Tab Cursora uczy się twoich wzorców w czasie. Im bardziej konsekwentnie piszesz kod, tym lepsze są jego przewidywania. Te nawyki poprawiają dokładność Tab:

• Bądź konsekwentny z nazewnictwem. Jeśli twoje serwisy są zawsze [Domain]Service (UserService, OrderService, PaymentService), Tab przewiduje wzorzec, gdy wpiszesz Notif....
• Bądź konsekwentny ze strukturą. Jeśli każdy serwis ma metody create, get, update, delete w tej kolejności, Tab przewiduje następną metodę po zakończeniu jednej.
• Akceptuj częściowe uzupełnienia. Naciśnij Cmd+Right Arrow, aby akceptować jedno słowo na raz zamiast całej sugestii. Daje to większą kontrolę, nadal oszczędzając naciśnięcia klawiszy.

Checklista przed-push

Przed wypchaniem swojej gałęzi uruchom tę jednorazową weryfikację:

Wskazówka

Prompt do skopiowania-wklejenia dla weryfikacji przed-push:

Uruchom te sprawdzenia po kolei i napraw wszelkie problemy:

1. npm run build (napraw wszystkie błędy TypeScript)
2. npm run lint (napraw wszystkie błędy linta)
3. npm test (napraw wszelkie niepowodzenia testów)
4. npm run format (zastosuj formatowanie)

Po przejściu wszystkich czterech pokaż mi podsumowanie tego, co zostało naprawione.
Nie pomijaj żadnego kroku. Iteruj, aż wszystkie cztery przejdą czysto.

Zapobiega to cyklowi “CI failed, push a fix, CI failed again”, który marnuje 15 minut na iterację.

Codzienne optymalizacje przepływu pracy

Początek dnia

Otwórz swój projekt i uruchom szybkie sprawdzenie statusu w trybie Ask:

Podsumuj stan tej gałęzi:
- Jakie zmiany są staged i unstaged?
- Jaki jest ostatni commit?
- Czy są jakieś uncommitowane zmiany z wczoraj?
- Czy są konflikty mergowania z main?

Zajmuje to 10 sekund i zapobiega zamieszaniu “wait, where was I?” kosztującemu 5 minut każdego ranka.

Podczas rozwoju

Trzymaj konwersacje w trybie Agent krótkie. Gdy konwersacja przekroczy 15 do 20 wiadomości, okno kontekstu się zapełnia i agent zaczyna tracić ślad wcześniejszych instrukcji. Rozpoczynaj nową konwersację dla każdego odrębnego zadania zamiast kontynuować jeden długi wątek.

Koniec dnia

Przed zamknięciem edytora stwórz punkt orientacyjny na jutro:

Spójrz na moje obecne zmiany (staged i unstaged) i napisz krótkie podsumowanie:
1. Nad czym pracowałem
2. Co jest zrobione
3. Co jeszcze trzeba zrobić
4. Wszelkie blokady lub pytania do rozwiązania

Zapisz to jako komentarz na górze pliku, który edytowałem.

Usuń komentarz jutro rano po jego przeczytaniu. Eliminuje to 10-minutowe “what was I doing?” rozgrzewanie na początku każdego dnia.

Gdy to się psuje

Auto-save wyzwala za dużo operacji format-on-save. Jeśli twój formatter jest wolny (częste z dużymi plikami lub złożonymi konfiguracjami Prettier), zwiększ opóźnienie auto-save do 3000ms lub przełącz na format-on-paste zamiast format-on-save.

Operacje zbiorcze zmieniają za dużo naraz. Jeśli zbiorcza aktualizacja dotyka 20 plików i coś psuje, trudno wskazać, która zmiana spowodowała problem. Preferuj uruchamianie pakietu testów po każdych 3 do 5 zmianach plików zamiast po wszystkich zmianach.

Uzupełnianie Tab sugeruje złe wzorce. Tab uczy się z twojej bazy kodu, więc jeśli twoja baza kodu ma niespójne wzorce, sugestie są niespójne. Napraw pierwotną przyczynę standaryzując wzorce, nie walcząc z przewidywaniami.

Wiadomości commitów są zbyt ogólne. Wiadomość wygenerowana przez AI mówi “update order service” zamiast wyjaśniać dlaczego. Dołącz kontekst w swoim promptcie: “The staged changes fix the bug where decimal quantities returned NaN in the total calculation.”

Co dalej

• Skróty klawiszowe — Warstwa szybkości wprowadzania sprawiająca, że te przepływy pracy są jeszcze szybsze
• Szablony promptów — Gotowe prompty dla zadań omówionych tutaj
• Niestandardowe reguły i szablony — Kodowanie twoich konwencji w reguły stosujące się automatycznie