Najlepsze praktyki i typowe workflow

O tej stronie

Czas: ok. 8 minut czytania + 10 minut ćwiczenia. Poziom: średni, po kontekście i kosztach. Wcześniej: znasz wszystkie mechanizmy. Tu: układasz je w sposób pracy.

1. Explore → Plan → Code → Commit. Najpierw niech Claude przeczyta właściwe pliki i napisze plan (“nie pisz jeszcze kodu”), potem implementuje, weryfikuje i commituje. Fazy Explore i Plan są najtańsze tokenowo, a jednocześnie najcenniejsze.

2. Weryfikacja to najwyższa dźwignia. Dokumentacja mówi to wprost: dołącz testy, zrzuty ekranu albo oczekiwane wyjścia, żeby Claude mógł sam siebie sprawdzić - to pojedyncza rzecz o największym wpływie. Bez tego kod “wygląda dobrze”, ale bywa błędny.

3. TDD. Napisz testy najpierw, zacommituj je, potem implementuj do zielonego. Claude bywa skłonny zmieniać testy zamiast kodu - zacommitowanie testów temu zapobiega. Nie blokuj Edit ani Write w trakcie planu, waliduj przez PostToolUse albo pre-commit.

4. Plan mode (Shift+Tab do plan albo /plan) do eksploracji nieznanego lub dużego repozytorium. Dla małych zadań pomiń planowanie: przy oczywistym zakresie i drobnej poprawce - literówka, dodanie logu, zmiana nazwy zmiennej - poproś po prostu o zmianę.

5. Zrzuty ekranu i mockupy. Wklej obraz (Ctrl+V), poproś o implementację i porównanie wizualne, na przykład przez integrację Chrome.

6. Precyzyjne prompty i korygowanie kursu. Esc przerywa, podwójny Esc cofa. /rewind i checkpointy przywracają stan.

7. Higiena sesji. Częste /clear, --resume i --continue do wznawiania, /branch i /fork do eksperymentów.

8. Adwersaryjny przegląd subagentem. Zanim spojrzysz na PR napisany przez Claude, poproś o subagenta, który zaatakuje zmianę pod kątem poprawności i prostoty, a potem spisze przyjęte założenia i decyzje projektowe wraz z uzasadnieniem i opublikuje to jako artefakt.

Subagent nie widział rozmowy, więc nie dzieli ślepych plam sesji głównej. Artefakt mówi Ci, gdzie patrzeć, zamiast zmuszać do czytania całego diffa na zimno. (praktyka Dicksona Tsaia, Claude Code w Anthropic)

9. Własny /recap przy wielu sesjach. Przy ośmiu i więcej równoległych sesjach nie da się pamiętać, gdzie która jest. Skill /recap może wymuszać: najpierw odświeżenie tego, co mogło się zdezaktualizować - pull requesty, uruchomione joby, podlinkowane wątki - a potem raport w czterech punktach:

1. cel, słowami tego, kto o niego prosił,
2. faktyczny stan wraz z dowodem (przechodzące testy jednostkowe to nie dowód),
3. co jest zablokowane na człowieku, a co technicznie,
4. krótka lista kolejnych kroków, każdy oznaczony: Claude czy Ty.

Twardy warunek: recap nie zaczyna żadnej nowej pracy. (praktyka Richarda Zhuanga z Anthropic)

10. Odpowiedzialność. To Ty odpowiadasz za kod w pull requeście z Twoim nazwiskiem, niezależnie od tego, jak powstał. Recenzuj.

Ćwiczenie: 10 minut

1. Zrób pełny cykl na drobnej funkcji: plan mode → zatwierdź plan → implementacja → testy → commit.
2. Puść na tym samym diffie adwersaryjnego subagenta.
3. Porównaj, co znalazł, z tym, co sam byś zauważył.

Zaliczenie: masz przejście przez cały cykl i listę uwag od subagenta, który nie widział rozmowy. Jeśli znalazł coś, czego nie widziałeś, wiesz już, po co ten krok istnieje.

Jeśli nic nie zgrzyta i zostaje czas: zapisz sobie punkt 9 jako własny skill /recap i przetestuj go po tygodniu pracy nad kilkoma rzeczami naraz.

Teraz wiesz

• Explore i Plan są najtańsze i najcenniejsze - to tam wygrywa się zadanie.
• Bez sposobu weryfikacji agent nie wie, czy skończył, a Ty nie wiesz, czy działa.
• Świeże spojrzenie subagenta jest wartościowe właśnie dlatego, że nie zna rozmowy.

Następny krok: Rozwiązywanie problemów - tabela objaw, przyczyna, komenda naprawcza.

Pojęcia z tej strony

Agent AI

System AI, który dostaje cel zamiast pojedynczego polecenia - sam planuje kroki, korzysta z narzędzi i wykonuje wieloetapowe zadanie.

Prompt

Polecenie lub pytanie, które wpisujesz do AI - na jego podstawie model układa odpowiedź.

Pełne definicje w słowniku pojęć.

Częste pytania

Co najbardziej poprawia jakość pracy agenta?

Weryfikacja. Dołącz testy, zrzuty ekranu albo oczekiwane wyjścia, żeby Claude mógł sam siebie sprawdzić. Dokumentacja mówi to wprost - to pojedyncza rzecz o największym wpływie. Bez tego kod wygląda dobrze, ale bywa błędny.

Czy przy pracy z agentem można robić TDD?

Tak, i warto. Napisz testy najpierw, zacommituj je, potem implementuj do zielonego. Zacommitowanie testów jest kluczowe: bez tego Claude bywa skłonny zmieniać testy zamiast kodu.

Kiedy pomijać tryb planowania?

Przy drobnych i oczywistych zmianach - literówce, dodaniu logu, zmianie nazwy zmiennej. Plan mode jest do eksploracji nieznanego albo dużego repozytorium, nie do każdej poprawki.