Grok dla programistów

Grok to świetna gumowa kaczuszka, która potrafi odpowiedzieć. Na grok.online nic to nie kosztuje i nie wymaga konta: Grok 4.20 jest szybki przy prostych pytaniach, Grok 4.3 Thinking analizuje problem przed udzieleniem odpowiedzi i sprawdza się lepiej przy bugach, a Grok 4.7, najnowszy model, radzi sobie z najtrudniejszymi zadaniami w ramach 10 z Twoich 30 codziennych wiadomości. Wszystkie trzy modele potrafią odczytywać zrzuty ekranu. Oto siedem zastosowań wraz z promptami, które możesz otworzyć w czacie i dostosować do siebie.

Znajdowanie i naprawianie błędów

Większość czasu podczas debugowania schodzi na zrozumienie, co tak właściwie się dzieje. Te prompty przyspieszą ten proces.

Rozszyfruj stack trace

Wklej cały błąd (nie własną parafrazę) wraz z linijkami, na które wskazuje. Zanim przejdziesz do poprawki, poproś o wyjaśnienie przyczyny prostymi słowami, aby móc ją samodzielnie ocenić.

Używam [język i wersja] z [framework]. Oto pełny błąd i stack trace: [wklej błąd]. Oto kod, na który wskazuje: [wklej kod]. Wyjaśnij prostymi słowami, co poszło nie tak i dlaczego, wskaż najpierw najbardziej prawdopodobną przyczynę, a potem zaproponuj najmniejszą możliwą zmianę naprawiającą problem.

Otwórz to w czacie. Code Assistant zrobi to samo w jednym wygodnym panelu.

Zrozum kod, którego nie pisałeś

Odziedziczenie pliku bez ani jednego komentarza to chrzest bojowy każdego programisty. Zanim cokolwiek zmienisz, poproś o przewodnik po kodzie, który wskaże newralgiczne miejsca.

Właśnie odziedziczyłem ten plik w [język] i muszę zmodyfikować funkcję [funkcja]. Zrób mi krótki przegląd: za co odpowiada ten plik, jakie są główne funkcje w kolejności ich wywoływania, na jaki stan globalny lub efekty uboczne muszę uważać i gdzie najbezpieczniej wprowadzić moją zmianę: [wklej kod]

Zrób przegląd kodu, a potem dopytaj o funkcje, które nadal budzą Twoje wątpliwości.

Namierz błąd logiczny z modelem myślowym

Gdy kod się kompiluje, ale zwraca złe dane, potrzebna jest dokładna analiza krok po kroku. Grok 4.3 Thinking przechodzi przez kod przed udzieleniem odpowiedzi, co idealnie sprawdza się przy błędach typu off-by-one czy poplątanych warunkach logicznych.

Ta funkcja w [język] powinna [oczekiwane zachowanie], ale dla danych wejściowych [dane wejściowe] zwraca [rzeczywisty wynik] zamiast [oczekiwany wynik]. Przeanalizuj wykonanie krok po kroku z tymi danymi wejściowymi, pokaż wartości kluczowych zmiennych na każdym etapie i wskaż dokładnie linijkę, w której pojawia się błąd: [wklej funkcję]

Przeanalizuj to z Grok 4.3 Thinking.

Napraw rozjechany layout ze zrzutu ekranu

Załącz zrzut ekranu strony z obecnym wyglądem, wklej powiązany kod HTML i CSS, a potem opisz, jak powinien wyglądać docelowy efekt.

Załączam zrzut ekranu strony, na której [opisz problem, np. pasek boczny nachodzi na treść na wąskich ekranach]. Oto HTML i CSS tej sekcji: [wklej kod]. Wyjaśnij, co powoduje ten problem, i podaj poprawiony kod CSS, zmieniając tak mało, jak to możliwe.

Otwórz ten prompt i załącz swój zrzut ekranu.

Zaplanuj ryzykowny refaktoring

Uporządkowanie przerośniętego modułu to idealne zadanie, na które warto poświęcić jedną z limitowanych dziennych wiadomości najnowszego modelu. Poproś o plan działania, a nie o natychmiastowe przepisanie całości.

Poniżej znajduje się moduł w [język], który stał się trudny w utrzymaniu: [wklej kod]. Nie przepisuj go jeszcze. Opisz jego odpowiedzialności, ukryte zależności oraz przygotuj plan refaktoringu w małych krokach — tak, aby kod działał po każdym z nich. Wskaż też, jakie testy powinienem napisać przed rozpoczęciem pierwszego kroku.

Zaplanuj to z Grok 4.7, a poszczególne kroki wdrażaj po kolei z pomocą Grok 4.20.

Zadbaj o otoczenie kodu

Testy, zapytania do bazy, review i dokumentacja to rzeczy, z których rezygnuje się najszybciej, gdy gonią deadline'y.

Napisz testy dla pominiętych edge case'ów

Najpierw poproś o listę przypadków skrajnych, a dopiero potem o sam kod testów. Największa wartość kryje się w samej liście.

Oto funkcja w [język]: [wklej funkcję]. Najpierw wypisz edge case'y warte przetestowania, takie jak puste dane wejściowe, wartości brzegowe i nieprawidłowe typy, z jednozdaniowym uzasadnieniem dla każdego. Następnie napisz testy przy użyciu [framework testowy] — jeden test na każdy przypadek, z czytelnymi nazwami.

Wygeneruj testy, uruchom je i zostaw te, które faktycznie wyłapują błędy.

Zrób code review u zgryźliwego seniora

Grok z przyjemnością wcieli się w rolę code reviewera, który widział już każdy możliwy błąd. Może być zrzędliwy, ale nie może być ogólnikowy — dlatego wymagaj odwołań do konkretnych linijek.

Zrób review tego diffa jak zrzędliwy, ale sprawiedliwy senior developer. Wskaż bugi, niejasne nazewnictwo, brak obsługi błędów i wszystko, co zemści się za pół roku — podając przy każdym punkcie numer linijki i sugerowaną poprawkę. Posortuj uwagi według ważności i pomiń czepianie się czysto wizualnego stylu kodu: [wklej diff]

Poproś o review, zanim kod zobaczy reszta Twojego zespołu.

Zamień schemat bazy w SQL i README

Podaj definicje tabel oraz swoje zapytanie opisane własnymi słowami i poproś o krótkie wyjaśnienie do wygenerowanego kodu SQL.

Oto definicje moich tabel w [baza danych, np. PostgreSQL]: [wklej schemat]. Napisz zapytanie, które zwraca [czego potrzebujesz, opisane własnymi słowami]. Wyjaśnij każdy JOIN i warunek filtrowania w jednym zdaniu i powiedz, jaki indeks może przyspieszyć to zapytanie, gdy tabele będą miały miliony wierszy.

Napisz zapytanie, a potem poproś o sekcję do README dokumentującą tabele.

Czego unikać

• Wklejania poufnych danych. Klucze API, hasła, tokeny i dane klientów nigdy nie powinny trafiać na czat. Zastąp je placeholderami.
• Ślepego ufania szczegółom bibliotek. Modele mają ograniczony stan wiedzy w czasie i brak dostępu do internetu, więc dana funkcja lub opcja może być przestarzała albo zmyślona. Zawsze sprawdzaj oficjalną dokumentację.
• Wdrażania nieprzetestowanego kodu. Kod, który wygląda dobrze na pierwszy rzut oka, może i tak nie działać. Uruchom go, przetestuj i zrób review.
• Wysyłania całych repozytoriów. Bardzo długie wiadomości są ucinane. Przesyłaj tylko te funkcje, które mają znaczenie.

Powiązane strony

• Dwadzieścia kolejnych inspiracji znajdziesz w sekcji prompty do programowania.
• Nasz poradnik na temat programowania z Grok oraz artykuł wyjaśniający modele myślowe.
• Tworzysz własną aplikację? Dowiedz się więcej o Grok API.