Pierwszy skrypt od AI: opis zadania, próba na kopii i kontrola przed uruchomieniem

👁 116 przeczytań

Pokazuję, jak opisać zadanie techniczne bez znajomości programowania i poprosić o wyjaśnienie działania skryptu. Prowadzę przez próbę na kopii danych, ocenę skutków i zgłoszenie błędu z informacjami potrzebnymi do poprawki.

Powiązany materiał: Codex: agent OpenAI, któremu oddaje się zadanie, a nie linijkę kodu

Zacznij od opisu zadania, nie od prośby o kod

Najczęstszy błąd początkującego brzmi tak: „napisz mi skrypt, który uporządkuje pliki”. Model coś napisze, bo zawsze coś napisze, tylko że połowę założeń zmyśli, a ty tych założeń nawet nie zauważysz, bo nie czytasz kodu. Zadanie trzeba opisać tak, jakbyś zlecał je człowiekowi, który nigdy nie widział twojego komputera.

Gotowy szablon zlecenia, który wklejam na początku każdej takiej rozmowy:

Nie jestem programistą. Potrzebuję prostego skryptu i muszę rozumieć, co on robi.

ZADANIE: [jednym zdaniem, co ma się wydarzyć]
WEJŚCIE: [pliki, folder, arkusz, skrzynka: dokładnie co i ile]
WYJŚCIE: [co ma powstać i gdzie]
REGUŁA: [według czego skrypt podejmuje decyzje]
ŚRODOWISKO: [system, wersja Pythona lub inne, jak uruchamiam]
SKALA: [ile elementów, jak często]
PRZY BŁĘDZIE: [pominąć i zapisać w logu / zatrzymać wszystko]
CZEGO NIE WOLNO: [nie kasować, nie nadpisywać, nie wysyłać niczego na zewnątrz]

Wymagania techniczne:
1. Użyj tylko biblioteki standardowej, chyba że bez zewnętrznej naprawdę się nie da. Jeśli się nie da, napisz dlaczego.
2. Skrypt ma mieć na górze przełącznik TRYB_NA_SUCHO ustawiony na wartość prawda. W tym trybie tylko wypisuje, co by zrobił, i niczego nie zmienia.
3. Każda operacja na plikach ma trafić do logu tekstowego.
4. Najpierw napisz plan w punktach, po polsku, bez kodu. Kod dopisz dopiero po moim potwierdzeniu.

Ostatni punkt jest najważniejszy. Plan po polsku czytam w minutę i od razu widzę, że model zrozumiał „data modyfikacji” jako „data utworzenia”. Poprawienie planu kosztuje jedno zdanie, poprawianie skutków kosztuje wieczór.

Powiedz, gdzie to ma się uruchomić

Model nie widzi twojego komputera i domyśli się źle. Napisz wprost: jaki system, czy masz zainstalowanego Pythona, czy umiesz otworzyć wiersz poleceń, czy wolisz rozwiązanie w arkuszu. Jeśli nie wiesz, co masz, zapytaj o to osobno.

Zanim napiszesz kod: podaj mi trzy komendy, którymi sprawdzę, czy mam w systemie Windows to, czego potrzebujesz. Napisz, jak wygląda poprawna odpowiedź każdej z nich i co zrobić, jeśli wyjdzie inaczej.

Proś też o wersję bez instalowania czegokolwiek. Skrypt korzystający wyłącznie z tego, co jest w standardzie, ma mniej ruchomych części i mniej powodów, by przestać działać za pół roku.

Poproś o wyjaśnienie, zanim poprosisz o działanie

Kod, którego nie rozumiesz, to nie jest narzędzie, tylko zakład. Nie musisz umieć go napisać, musisz umieć przeczytać, co robi. Do tego służy jeden prompt:

Wyjaśnij ten skrypt linijka po linijce, po polsku, dla osoby bez doświadczenia w programowaniu.
Przy każdej linijce napisz: co robi i czy coś zmienia poza pamięcią (pliki, dane, wysyłka).
Na końcu wypisz trzy listy:
1. Linijki, które coś TWORZĄ.
2. Linijki, które coś ZMIENIAJĄ lub KASUJĄ.
3. Linijki, które wychodzą poza mój komputer (sieć, API, poczta).
Jeśli któraś z list jest pusta, napisz to wprost.

Te trzy listy są sednem całej sprawy. Skrypt, który tylko czyta i wypisuje, możesz uruchomić spokojnie. Skrypt, który kasuje albo wysyła, wymaga osobnej rozmowy przed każdym uruchomieniem. Jeśli model odpowie mgliście albo zacznie zapewniać, że „wszystko jest bezpieczne”, poproś o konkretne numery linii. Brak konkretu to sygnał, żeby zwolnić.

Drugie pytanie, które zadaję zawsze:

Wypisz pięć sytuacji, w których ten skrypt zadziała nie tak, jak zakładam, chociaż nie zgłosi żadnego błędu. Dla każdej napisz, jak to zauważę.

Cicha awaria jest gorsza od głośnej. Skrypt, który przerobił 12 plików z 600 i zakończył się bez komunikatu, wygląda na sukces.

Bezpieczne testowanie: cztery zasady, których nie łamię

Kopia danych. Zanim cokolwiek uruchomię, kopiuję folder w inne miejsce. Nie „na wszelki wypadek”, tylko zawsze. To jest jedyny mechanizm, który naprawdę cofa skutki.

Mały poligon. Zakładam pusty folder testowy i wrzucam do niego pięć, sześć plików odwzorowujących prawdziwe przypadki: jeden z polskimi znakami w nazwie, jeden bardzo duży, jeden pusty, jeden z dziwnym rozszerzeniem. Skrypt dostaje ścieżkę do tego folderu, nie do prawdziwych danych.

Tryb na sucho. Pierwszy przebieg tylko wypisuje: „przeniosę A do B”, „pominę C, bo nie pasuje do reguły”. Czytam te linie i porównuję z tym, czego oczekiwałem. Dopiero potem przełączam skrypt w tryb wykonawczy.

Limit. Nawet po teście pierwsze prawdziwe uruchomienie robię na ograniczonej liczbie elementów. Prosty przełącznik na górze skryptu, który mówi: przerób tylko dwadzieścia pierwszych. Jeśli dwadzieścia wyszło dobrze, reszta wyjdzie tak samo.

Przerób ten skrypt tak, żeby miał na górze trzy ustawienia w jednym miejscu, z komentarzem po polsku przy każdym:
TRYB_NA_SUCHO = True  (nic nie zmienia, tylko wypisuje planowane operacje)
LIMIT = 20  (przerabia tylko tyle elementów, 0 oznacza wszystkie)
PLIK_LOGU = ścieżka do pliku tekstowego
W trybie na sucho każda linia ma zaczynać się od słowa SUCHO, żebym nie pomylił przebiegów.

Czego nie uruchamiam w ciemno

Kilka wzorców zatrzymuje mnie natychmiast, niezależnie od tego, jak przekonująco model je tłumaczy.

Jeśli skrypt robi którąkolwiek z tych rzeczy i naprawdę musi, to nie znaczy, że nie wolno. Znaczy tylko, że przed uruchomieniem czytam tę konkretną linijkę i wiem, co w niej jest.

Jak wrócić do modelu z błędem

„Nie działa” to najgorsza możliwa informacja zwrotna. Model zacznie zgadywać i w trzeciej iteracji przepisze połowę skryptu, dokładając nowe problemy. Dobre zgłoszenie błędu ma cztery elementy: dokładną komendę, którą wpisałeś, pełny komunikat błędu skopiowany jako tekst, to co miało się wydarzyć, i to co się wydarzyło naprawdę.

Skrypt się zatrzymał. Podaję komplet informacji.

URUCHOMIŁEM: [dokładna komenda]
OCZEKIWAŁEM: [co miało się stać]
STAŁO SIĘ: [co się stało naprawdę, łącznie z tym, ile elementów zdążył przerobić]
PEŁNY KOMUNIKAT BŁĘDU:
[wklejam wszystko, od pierwszej do ostatniej linii]
ŚRODOWISKO: [system, wersja]

Zanim poprawisz kod: napisz jednym akapitem, co ten komunikat oznacza i która linijka go wywołała. Potem podaj poprawkę TYLKO tej części, nie przepisuj całego skryptu.

Ostatnie zdanie oszczędza najwięcej czasu. Gdy model przepisuje całość, tracisz orientację, co się zmieniło, i nie wiesz, czy poprawka rozwiązała problem, czy przypadkiem obeszła go inną drogą.

Gdy poprawka nie pomaga po drugim podejściu, zmieniam tryb rozmowy:

Dwie poprawki nie pomogły, więc przestań zgadywać. Zaproponuj trzy możliwe przyczyny tego błędu i dla każdej podaj jedną krótką komendę albo linijkę diagnostyczną, która potwierdzi lub wykluczy tę przyczynę. Poczekaj na moje wyniki, zanim cokolwiek poprawisz.

Przykład od zera do działania

Zadanie: mam folder ze skanami, które przez rok lądowały w jednym miejscu. Chcę je rozłożyć do podfolderów w układzie rok-miesiąc według daty modyfikacji i dostać zestawienie w CSV.

Krok 1. Opis. Wypełniam szablon z początku tekstu. W polu „czego nie wolno” wpisuję: nie kasować niczego, nie nadpisywać, przy konflikcie nazw dopisać numer.

Krok 2. Plan. Model odpowiada planem w siedmiu punktach. Wyłapuję, że zamierza odczytywać datę utworzenia, a nie modyfikacji. Poprawiam jednym zdaniem.

Krok 3. Kod i czytanie. Proszę o skrypt, potem o wyjaśnienie linijka po linijce i o trzy listy operacji. Lista „kasuje” jest pusta, lista „wychodzi do sieci” jest pusta. To zielone światło do testu.

Krok 4. Poligon. Kopiuję dwadzieścia plików do folderu testowego, w tym jeden z polskimi znakami w nazwie i dwa o identycznej nazwie z różnych miejsc. Uruchamiam w trybie na sucho. Wypisane linie zgadzają się z tym, czego oczekiwałem, poza jedną: dwa pliki o tej samej nazwie trafiają w to samo miejsce.

Krok 5. Błąd. Przełączam tryb wykonawczy na poligonie i skrypt zatrzymuje się na pliku, który mam otwarty w podglądzie. Wklejam pełny komunikat i komendę. Model tłumaczy, że system nie pozwala przenieść pliku używanego przez inny program, i proponuje poprawkę tylko w tym fragmencie: taki plik zostaje pominięty i zapisany w logu, a skrypt idzie dalej.

Krok 6. Konflikt nazw. Zgłaszam też sprawę z kroku 4. Dostaję dopisek, który przy istniejącej nazwie dokłada numer zamiast nadpisywać. Sprawdzam to na poligonie jeszcze raz, celowo duplikując plik.

Krok 7. Prawdziwe dane. Kopia całego folderu leży obok. Ustawiam limit na dwadzieścia, uruchamiam, sprawdzam wynik ręcznie. Zgadza się, więc zdejmuję limit i puszczam całość. Na koniec czytam log: trzy pliki pominięte, wszystkie trzy otwarte w innym programie. Zamykam program, uruchamiam ponownie, tym razem log jest pusty.

Cały proces zajmuje mniej czasu niż ręczne przerzucenie stu plików, a różnica polega na tym, że po drodze nic nie mogło zniknąć.

Czego AI nie zrobi za ciebie

Nie wie, które twoje pliki są nie do odtworzenia. Nie wie, że folder o niewinnej nazwie zawiera jedyną kopię czegoś ważnego. Nie sprawdzi wyniku, bo nie widzi twojego dysku, a jeśli ma do niego dostęp, to i tak nie wie, jak wynik ma wyglądać. Nie poniesie też żadnych konsekwencji. Weryfikacja rezultatu zostaje po twojej stronie i to jest ta część, której nie da się oddelegować.

Checklista przed wciśnięciem Enter

1. Mam kopię danych w innym miejscu.
2. Przeczytałem listę operacji, które tworzą, zmieniają i kasują.
3. Uruchomiłem tryb na sucho i porównałem wypisane linie z oczekiwaniami.
4. Przetestowałem na małym folderze z trudnymi przypadkami.
5. Pierwsze prawdziwe uruchomienie ma limit.
6. Skrypt pisze log, który potem faktycznie przeczytam.
7. Żadnego hasła ani klucza w treści pliku.
8. Wiem, co zrobię, jeśli wynik będzie zły.

Ta lista wygląda na przesadę przy skrypcie, który przenosi pliki. Przy pierwszym skrypcie, który ruszy coś ważnego, okaże się najtańszą rzeczą w całym procesie.

Tekst powstał z pomocą AI i został zredagowany przez człowieka.

// czytaj dalejPierwsze wirusy zaprojektowane przez AI - naukowcy ostrzegają przed luką w przepisachNewsyAI już teraz robi rzeczy, których twórcy nigdy nie planowali - australijski minister ostrzega przed utratą kontroliNewsyCzy warto oddać to zadanie AI? Test odpowiedzialności, weryfikacji i utraty wprawyEvergreeny