Przejdź do głównej zawartości
Developer Toolkit Developer Toolkit Developer Toolkit

Przewodnik transformacji przepływu pracy

Zainstalowałeś Cursora, masz miejsce w Claude Max, a team lead bez przerwy podsyła ci dema Codeksa. Wszyscy zgadzają się, że AI powinno przyspieszać pracę. Ale twój rzeczywisty przepływ pracy się nie zmienił: nadal czytasz ticket, ręcznie piszesz kod, a AI jest tylko sprytniejszym autouzupełnianiem. Zyski są realne, ale niewielkie i nikt nie potrafi wskazać, który krok narzędzie faktycznie zastąpiło.

Problem nie leży w narzędziu. Leży w tym, że doczepiłeś AI do procesu zaprojektowanego dla ludzi piszących każdą linię ręcznie. Ten przewodnik przebudowuje jeden przepływ pracy — pętlę dostarczania funkcji, od ticketu do zmergowanego PR — tak, by AI robiło pierwszą wersję i ciężką pracę mechaniczną, a ty poświęcał czas na decyzje wymagające osądu. Ten sam schemat działa przy naprawianiu błędów, refaktoryzacji i migracjach.

Co z tego wyniesiesz

Dział zatytułowany „Co z tego wyniesiesz”
  • Czteroetapową pętlę funkcji (planuj, implementuj, weryfikuj, przeglądaj), która stawia AI przy wersji roboczej, a ciebie przy decyzjach
  • Konkretną mechanikę tej samej pętli w Cursorze, Claude Code i Codeksie
  • Trzy prompty do skopiowania: prompt audytu przepływu pracy, prompt od ticketu do planu oraz prompt do samodzielnego przeglądu
  • Realne zadanie GitHub Actions, które uruchamia Claude Code lub Codeksa jako recenzenta w CI (żadnego machania ręką nad YAML-em)
  • Tryby awaryjne, które sprawiają, że przepływy z AI są wolniejsze niż dawne metody, oraz jak je wyłapać

Zacznij od audytu, nie od przepisywania

Dział zatytułowany „Zacznij od audytu, nie od przepisywania”

Nie transformuj wszystkiego naraz. Wybierz jeden przepływ pracy, który pożera najwięcej twojego tygodnia — zwykle dostarczanie funkcji albo triaż błędów — i zmapuj, gdzie naprawdę ucieka czas, zanim cokolwiek zmienisz. AI dobrze radzi sobie z taką analizą, jeśli skierujesz je na twoją własną historię commitów.

Wynik mówi ci, który etap przekazać AI jako pierwszy. W większości zespołów są to te same dwa: odnajdywanie odpowiedniego kodu oraz pisanie pierwszej wersji zmiany wraz z testami. To zadania mechaniczne i weryfikowalne. Decyzje o architekturze i przypadkach brzegowych zostają przy tobie.

Przekształcona pętla funkcji

Dział zatytułowany „Przekształcona pętla funkcji”

Pętla ma cztery etapy. AI robi wersję roboczą; ty decydujesz i weryfikujesz. Mechanika różni się w zależności od narzędzia, ale etapy nie.

  1. Planuj. Podaj ticket i pozwól agentowi przygotować pisemny plan — pliki, których dotknie, podejście oraz otwarte pytania. Przeglądasz i poprawiasz plan przed napisaniem choćby jednej linii kodu. To punkt przeglądu o najwyższej dźwigni: poprawienie planu kosztuje sekundy, poprawienie błędnej implementacji kosztuje godzinę.

  2. Implementuj. Agent wykonuje zatwierdzony plan. Obserwujesz diff, nie naciśnięcia klawiszy. Trzymaj zmiany w zakresie jednej logicznej jednostki, żeby diff pozostał możliwy do przejrzenia.

  3. Weryfikuj. Testy, typy i lint uruchamiają się przy każdej zmianie. Agent w pętli naprawia własne błędy, aż zestaw testów przejdzie na zielono. Nigdy nie mergujesz na czerwono.

  4. Przeglądaj. Czytasz finalny diff jak starszy recenzent: poprawność, bezpieczeństwo, przypadki brzegowe. Drugie przejście AI (w CI) wyłapuje problemy mechaniczne, dzięki czemu twoja ludzka uwaga idzie na decyzje wymagające osądu.

Etap 1-3: planuj, implementuj, weryfikuj w każdym narzędziu

Dział zatytułowany „Etap 1-3: planuj, implementuj, weryfikuj w każdym narzędziu”

Otwórz tryb Agent (steruje nim wybór modelu — użyj Claude Fable 5 do najtrudniejszych funkcji, gdzie liczy się szczytowa inteligencja, Opus 4.8 do nietrywialnych zadań i Sonnet 4.6 do rutynowych; pełne zestawienie znajdziesz w porównaniu modeli). Wklej ticket i najpierw poproś o plan; przejrzyj go w miejscu, zanim zatwierdzisz wykonanie.

Checkpointy Cursora to twoja siatka bezpieczeństwa na etapie 2: każda akcja agenta jest punktem przywracania, więc pozwól mu wykonać zmianę w wielu plikach i natychmiast cofnij się, jeśli podejście było błędne, zamiast pilnować każdej edycji. Na etapie 3 trzymaj polecenie testów w terminalu i każ agentowi uruchamiać je po każdej zmianie:

Implement the approved plan. After each file, run `npm test -- --run`
and fix any failures before continuing. Do not move on while tests are red.

Użyj background agenta, by równolegle wykonać drugie, niezależne zadanie (np. przygotowanie skryptu wycofania migracji), podczas gdy przeglądasz główny diff.

Etap 4: przegląd, w tym drugie przejście AI w CI

Dział zatytułowany „Etap 4: przegląd, w tym drugie przejście AI w CI”

Twój ludzki przegląd jest nie do podważenia. Ale mechaniczne przeczesanie — zapachy bezpieczeństwa, brak obsługi błędów, oczywiste przypadki brzegowe — możesz oddać recenzentowi AI w CI, tak by twoja uwaga była zarezerwowana dla osądu. Zarówno Anthropic, jak i OpenAI dostarczają oficjalne, utrzymywane akcje GitHub Actions do tego celu.

anthropics/claude-code-action@v1 uruchamia pełne środowisko Claude Code wewnątrz runnera. To zadanie publikuje skupiony przegląd przy każdym PR:

name: AI PR Review
on:
  pull_request:
    types: [opened, synchronize]


jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v5
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Review the diff in PR #${{ github.event.pull_request.number }}.
            Flag only: security issues, unhandled errors, and missing edge cases.
            Skip style nits. Post findings as a PR review comment.
          claude_args: "--model opus"

Przykład z życia: dodawanie endpointu z limitem zapytań

Dział zatytułowany „Przykład z życia: dodawanie endpointu z limitem zapytań”

Konkretnie, oto jak wygląda pętla na realnym zadaniu — dodaniu endpointu POST /api/exports z limitem zapytań do usługi Express.

  1. Planuj. Agent proponuje: nową trasę w src/routes/exports.ts, middleware rateLimit korzystające z istniejącego klienta Redis, schemat Zod dla ciała żądania oraz trzy testy (ścieżka pozytywna, błąd walidacji, przekroczenie limitu). Zauważasz, że zaplanował limiter w pamięci; poprawiasz go, by używał współdzielonej instancji Redis, tak aby działał między instancjami. Koszt tej poprawki: jedno zdanie.

  2. Implementuj. Pisze trasę, middleware, schemat i testy zgodnie z poprawionym planem. Obserwujesz, jak diff ląduje w tych czterech plikach.

  3. Weryfikuj. npm test zawodzi raz — test przekroczenia limitu oczekuje 429, ale middleware zwraca 503. Agent poprawia kod statusu i uruchamia ponownie, aż przejdzie na zielono.

  4. Przeglądaj. Czytasz diff: klucz Redis zawiera ID użytkownika i okno czasowe, błędy zwracają ustrukturyzowany AppError, żadne sekrety nie są logowane. Recenzent w CI wyłapuje jedną rzecz, którą przeoczyłeś — limiter nie ma awaryjnego trybu, gdy Redis jest niedostępny. Uznajesz to za akceptowalne w wersji v1 i odnotowujesz w PR. Merge.

Decyzje wymagające osądu (Redis vs pamięć, intencja 503 vs 429, zachowanie typu fail-open) zostały przy tobie. Pisanie kodu — nie.

Kiedy to się psuje

Dział zatytułowany „Kiedy to się psuje”

Co dalej

Dział zatytułowany „Co dalej”
Metodologia PRD do planu do todo Pogłęb temat bramki „najpierw plan”: zamiana PRD w plan do przejrzenia i śledzoną listę todo we wszystkich trzech narzędziach.
Strategie migracji zespołu Wdróż tę pętlę w całym zespole: standardy, współdzielone skills i jak onboardować bez chaosu.
Playbook konwersji projektu Przeprowadź istniejący codebase na przepływy wspomagane AI: konfiguracja, konwencje i pierwsze bezpieczne zmiany.
Migracja z tradycyjnych IDE Stan przed i po dla deweloperów przechodzących z edytora bez AI, wraz z nawykami do oduczenia.

Zobacz co nowego na platformie.

Polityka prywatności Regulamin