Llama AI dla programistów

Dla programisty model czatu jest najbardziej przydatny jako szybka „druga para oczu”: czyta obcy kod, podpowiada pominięte testy, szkicuje powtarzalne fragmenty i wyjaśnia błędy prostym językiem. Na tej stronie znajdziesz siedem praktycznych sposobów na wykorzystanie modeli Llama w naszym czacie do takich zadań — każdy z gotowym promptem, który możesz otworzyć i dostosować. Jeśli wolisz stworzyć własną aplikację na bazie Llama, opisujemy też opcje Llama API oraz to, jak uruchomić Llama lokalnie.

Zrozum i napraw kod

Model pracuje tylko na tym, co umieścisz w wiadomości, więc dołącz istotne linie, dokładną treść błędu i wersje używanego oprogramowania.

Wyjaśnij komunikat o błędzie

Ślad stosu (stack trace) zazwyczaj wskazuje objaw, a nie przyczynę. Podaj modelowi pełny komunikat, otaczający kod i oczekiwany wynik, a następnie poproś o listę prawdopodobnych przyczyn uszeregowaną od najbardziej do najmniej możliwych.

Pojawia się ten błąd w moim projekcie w [język i framework wraz z wersjami]: [wklej błąd i stack trace]. Oto kod, w którym to występuje: [wklej kod]. Uszereguj prawdopodobne przyczyny od najbardziej do najmniej możliwych, wyjaśnij, jak mogę potwierdzić każdą z nich, i pokaż najprostszą poprawkę dla tej najbardziej prawdopodobnej.

Zdebuguj to na czacie. W przypadku pojedynczego fragmentu szybsza będzie strona Code Assistant.

Czytaj kod, którego nie znasz

Odziedziczone moduły i stare skrypty łatwiej zrozumieć z przewodnikiem. Najpierw zapytaj o cel, potem o przepływ danych, a na końcu o ryzykowne miejsca.

Wyjaśnij, co robi ten kod w [język]. Zacznij od dwuzdaniowego podsumowania, potem omów po kolei główne kroki, a na koniec wskaż wszystko, co wygląda na kruche, zaskakujące lub podatne na awarię przy nietypowych danych: [wklej kod]

Uzyskaj omówienie.

Opisz błąd UI na podstawie zrzutu ekranu

Llama 4 Maverick i Llama 4 Scout potrafią analizować obrazy, więc możesz dołączyć zrzut ekranu zepsutego układu obok odpowiedniego kodu CSS lub szablonu. Model widzi tylko grafikę, a nie działającą stronę, więc dopisz, czego oczekujesz.

Załączam zrzut ekranu z problemem z układem na [strona lub komponent]. Oczekiwany wygląd: [jak to powinno wyglądać]. Oto powiązany kod i CSS: [wklej kod]. Wskaż, co najprawdopodobniej powoduje różnicę, i zaproponuj poprawkę.

Otwórz ten prompt, załącz zrzut ekranu i upewnij się, że wybrany jest Llama 4 Maverick.

Pisz, testuj i dokumentuj

Używaj modelu do tworzenia szkiców, które samodzielnie sprawdzisz — nigdy do kodu wklejanego bez czytania.

Generuj testy uwzględniające przypadki brzegowe

Modele świetnie wyłapują sytuacje, które zmęczony człowiek pomija: puste dane wejściowe, olbrzymie wartości, nietypowe znaki czy strefy czasowe. Najpierw poproś o listę przypadków, aby zobaczyć zakres testów.

Napisz testy jednostkowe dla tej funkcji w [język], używając [framework testowy]. Najpierw wypisz przypadki, które pokryjesz (w tym sytuacje brzegowe i nieprawidłowe dane), a potem napisz testy. Nie zmieniaj samej funkcji: [wklej funkcję]

Napisz testy.

Zrób przegląd zmian przed pushem

Szybki code review wychwytuje błędy typu off-by-one, brakującą obsługę błędów czy niebezpieczne użycie danych. Poproś o uwagi posortowane według wagi, ze wskazaniem konkretnych linii.

Przejrzyj ten diff jako dociekliwy senior developer. Najpierw wypisz błędy, luki bezpieczeństwa i brakującą obsługę wyjątków, a potem kwestie czytelności — każdą ze wskazaniem linii i propozycją poprawki. Jeśli nie widzisz nic poważnego, napisz to wprost: [wklej diff]

Uruchom review.

Twórz pewne wyrażenia regularne i zapytania SQL

Poproś o wzorzec wraz z wyjaśnieniem oraz przykładami, które powinny i nie powinny pasować, a następnie przetestuj go samodzielnie.

Napisz [wyrażenie regularne lub zapytanie] w [odmiana regex lub dialekt SQL], które [co ma robić]. Wyjaśnij każdy element, a potem przygotuj krótką tabelę z przykładowymi danymi i oczekiwanym wynikiem dla każdego przypadku, w tym trudniejszymi scenariuszami.

Wypróbuj ten prompt.

Szkicuj README lub opisy commitów

Dokumentację łatwiej poprawiać, niż pisać od zera. Wklej swoje notatki lub diff i określ, dla kogo jest tekst.

Napisz README dla mojego projektu ([typ projektu]) na podstawie poniższych notatek. Sekcje: co robi projekt, wymagania, instalacja, użycie z jednym przykładem, konfiguracja i znane ograniczenia. Pisz zwięźle i umieść polecenia w blokach kodu: [wklej notatki]

Stwórz szkic README.

Czego unikać

• Ujawniania danych uwierzytelniających. Zanim wkleisz kod, usuń z niego klucze, hasła, connection stringi i wszelkie dane klientów. Twoje wiadomości przechodzą przez nasz serwer i dostawcę inferencji, więc przestrzegaj zasad swojej firmy dotyczących dzielenia się kodem z usługami zewnętrznymi.
• Ślepego polegania na detalach bibliotek. Modele mają określony cutoff wiedzy i nie przeszukują bieżącej dokumentacji, więc nowsze API lub parametry mogą być pominięte lub zmyślone. Sprawdzaj oficjalną dokumentację.
• Wdrażania nieprzetestowanego kodu. Wygenerowany kod może się kompilować, a mimo to działać błędnie. Uruchom go, przejrzyj i przetestuj tak samo, jak kod od innego programisty.
• Zbyt długich plików. Czat skraca bardzo długie wiadomości, dlatego wklejaj konkretną funkcję, a nie całe repozytorium.

Powiązane strony

• Zbiór promptów do programowania i poradnik o tym, jak wygląda programowanie ze wsparciem AI.
• Jaki model wybrać: wybór odpowiedniego modelu Llama; Llama 3.1 8B odpowiada najszybciej.
• Własne projekty na bazie Llama: licencja Llama prostym językiem.