Tutorial 4 Prompting and Reviewing pl

Samouczek 4 · Formułowanie promptów i recenzja

Cel: metaumiejętność. Umiesz już zbudować funkcję z agentem — ten rozdział jest o robieniu tego płynnie i powtarzalnie: pisaniu promptów, które trafiają za pierwszym razem, sprawnym recenzowaniu diffów, iterowaniu, gdy sprawy idą nie tak, i utrzymywaniu tempa między sesjami.

← Poprzednio: Samouczek 3 Twoje pierwsze zadanie dla agenta · Dalej: Samouczek 5 Lokalizacja

---

Formułuj jak lider, nie jak pole wyszukiwania

Agent to szybki, dosłowny, gorliwy młodszy inżynier. Prowadź go tak, jak prowadziłbyś dobrego:

• Podaj cel oraz ograniczenia. „Dodaj endorse” jest słabe. „Dodaj endorse zgodnie ze wzorcem connect, tylko RNG z ziarnem, z testami, bramka pozostaje zielona” jest mocne. Ograniczenia to sposób na uzyskanie kodu, który pasuje.
• Wskaż przykłady. „Trzymaj się wzorca użytego przez renderConnect” bije akapit opisu. Istniejący kod to najlepsza specyfikacja.
• Poproś o plan przed edycjami przy wszystkim nietrywialnym. Tanio jest przekierować plan; drogo cofać dziesięć zedytowanych plików.
• Jedno zadanie na prompt. Łączenie „dodaj endorse, a przy okazji refaktoryzuj RNG, a także zaktualizuj README” daje splątany diff, który trudno recenzować.
• Daj mu bramkę testową. „Uruchom npm test i nie uznawaj tego za zrobione, dopóki nie jest zielone” zamienia agenta w coś, co sprawdza swoją własną pracę.

Recenzuj diff za każdym razem

Szybkość to cały sens agenta — ale nieprzeczytana szybkość to sposób, w jaki wysyłane są błędy. Zbuduj szybki, spójny odruch recenzji:

1. Zakres: czy zmienił tylko to, co powinien? Niepowiązane przesunięte linie to podejrzany zapach.
2. Wzorce: czy pasuje do otaczającego kodu, bez nowych zależności i bez I/O wewnątrz src/?
3. Zasady projektu: dla tego repozytorium to tylko RNG z ziarnem (przeszukaj diff pod kątem Math.random), widoczny dla użytkownika tekst w pakietach językowych (nie na sztywno) oraz linie karty nigdy nie przekraczają szerokości, do której układ dopełnia.
4. Dostępność: czy nowe wyjście przetrwa --accessible? Uruchom lockedin --accessible <your command> i sprawdź, czy czyta się jako czysty zwykły tekst — żadnych nowych dekoracyjnych glifów przemykających przez a11yFilter.
5. Testy: czy jest nowy test i czy faktycznie by padł, gdyby funkcja się zepsuła? Zapytaj: „Którą linię musiałbym zmienić, aby ten nowy test padł?”
6. Uruchom to: npm test, a potem uruchom komendę i spójrz na wyjście.

Nie musisz rozumieć każdego znaku — ale musisz rozumieć każdą decyzję. Jeśli nie umiesz wyjaśnić zmiany, poproś agenta, aby ją wyjaśnił, zanim zaakceptujesz.

Iteruj, gdy nie jest zielone

Czerwona bramka to normalny krok, nie porażka. Naprawą jest precyzyjna informacja zwrotna:

„npm test pada z: [paste the exact error]. Test szerokości renderEndorse oczekuje, że każda linia karty ma ≤ 60 widocznych kolumn. Napraw to bez osłabiania testu.”

Wklej rzeczywisty tekst błędu. „Jest zepsute” każe agentowi zgadywać; ślad stosu każe mu naprawić. I wolej kontynuować tę samą rozmowę niż zaczynać od nowa — agent ma już kontekst tego, co właśnie napisał. Jeśli dwie lub trzy iteracje nie zbiegają się, cofnij się i zmień zakres: zadanie może być za duże na jeden prompt.

Utrzymuj tempo między sesjami

Prawdziwa praca rozciąga się na więcej niż jedno posiedzenie. Dwa nawyki utrzymują agenta skutecznym w czasie:

• Pamięć / konwencje. Jeśli Twój agent obsługuje trwałą pamięć albo plik instrukcji projektu, zapisz tam zasady, których zawsze powinien przestrzegać (np. „cała losowość musi używać pick/shuffle”, „uruchom npm test przed ogłoszeniem gotowości”). Konwencję podajesz raz, zamiast w każdym prompcie.
• Notatka przekazania. To repozytorium trzyma krótki, oczyszczony dokument statusu w docs/HANDOFF.md: czym jest projekt, jak jest zbudowany, jak jest testowany i co dalej. Gdy wracasz (albo przekazujesz koledze z zespołu — lub innemu agentowi), ta notatka odbudowuje kontekst w sekundy. Poproś agenta, aby utrzymywał ją aktualną jako część zmiany.

Barierki warte utrzymania

• Bramka jest nienegocjowalna. Zielone testy przed wysłaniem czegokolwiek. To ona pozwala poruszać się szybko i ufać wynikowi.
• Jesteś recenzentem odpowiedzialnym. Agent pisze; Ty decydujesz. Zaakceptowanie diffa oznacza, że za niego ręczysz.
• Małe, weryfikowalne kroki biją jeden gigantyczny skok. Każda zaakceptowana zmiana powinna zostawić działającą aplikację.

---

✅ Wypróbuj ze swoim agentem

1. Napisz jednoakapitową specyfikację komendy mentor („rozdaje nieproszone rady”), z ograniczeniami, i każ agentowi zbudować ją testy-najpierw — plan, testy, kod, bramka — recenzując na każdym kroku.
2. Poproś agenta, aby zaktualizował docs/HANDOFF.md, wspominając nową komendę.
3. Celowo coś zepsuj (np. usuń wpis puli), uruchom npm test i przećwicz podawanie agentowi dokładnego błędu do naprawy.

---

Dokąd dalej

• Przejrzyj prawdziwy kod w src/lockedin.js — znasz już jego kształt.
• Przeczytaj docs/HANDOFF.md po własny status projektu i notatki o architekturze.
• Ciesz się żartami w Podręczniku komend.

To koniec samouczka. Umiesz teraz kierować agentem AI, aby budował i zmieniał prawdziwe oprogramowanie za bramką testową — na najbardziej przesadnie pewnym siebie przykładzie, jaki można sobie wyobrazić. Agree? 👇