Wykorzystaj ChatGPT do pisania skryptów: prompty, testy i poprawki w PowerShellu

Dlaczego łączenie ChatGPT z PowerShellem ma sens (i kiedy nie)

PowerShell jako język automatyzacji, a nie „ładny CMD”

PowerShell nie jest kolejną nakładką na wiersz poleceń. To pełnoprawny język skryptowy oparty na .NET, który operuje na obiektach, a nie tylko na tekstowych strumieniach wyjściowych. Daje dostęp do systemu plików, rejestru, WMI, usług, procesów, API systemowych, a także zewnętrznych usług przez REST i moduły. Dla administratora lub inżyniera DevOps to szwajcarski scyzoryk do automatyzacji.

W praktyce PowerShell służy do budowania skryptów, które:

• porządkują i archiwizują logi oraz pliki w wielu lokalizacjach,
• tworzą raporty z systemów (użytkownicy, usługi, serwery, zasoby w chmurze),
• zarządzają kontami w Active Directory i Azure AD,
• tworzą zadania harmonogramu, monitorują procesy i usługi,
• wykonują złożone sekwencje działań administracyjnych.

ChatGPT bardzo dobrze wpisuje się w ten świat, bo największą barierą nie jest sama składnia, lecz wyszukanie poprawnych cmdletów, właściwych parametrów i bezpiecznych wzorców. AI może wygenerować szkielet, przykładową funkcję czy blok obsługi błędów, który potem da się szybko dopasować do konkretnego środowiska.

Zadania, w których wsparcie AI szczególnie się opłaca

Najwięcej zysku pojawia się tam, gdzie praca jest powtarzalna, a jednocześnie wymaga odrobiny kombinowania. Kilka typowych kategorii:

• Boilerplate i powtarzalne wzorce – funkcje z parametrami, standardowa obsługa błędów, logowanie do pliku, struktury try/catch/finally.
• Raporty i eksport danych – pobieranie list usług, użytkowników, plików, procesów i przerabianie ich na CSV, HTML lub JSON.
• Skrypty „klejące” kilka narzędzi – sekwencje wywołań różnych cmdletów, przeplatanie ich filtrowaniem, pętlami, warunkami.
• Przepisanie istniejącego rozwiązania – migracja z batcha lub Basha na PowerShell, rozbijanie „one-linerów” na przejrzyste funkcje.
• Prototypy – szybkie sprawdzenie, „czy to da się zrobić”, bez jeszcze dopieszczania każdego szczegółu.

ChatGPT skraca drogę od pomysłu do działającego prototypu. To nie jest magia – po prostu nie trzeba pamiętać dokładnej składni i wszystkich parametrów, wystarczy umieć jasno opisać, czego się oczekuje, a potem poprawnie ocenić wygenerowany kod.

Granice użycia ChatGPT: inspiracja i szkic vs bezrefleksyjne kopiuj–wklej

Największe nieporozumienia biorą się z traktowania AI jak nieomylnej encyklopedii kodu. Model językowy generuje wiarygodnie wyglądający tekst, niekoniecznie zawsze poprawny technicznie. Moment, w którym skrypt dotyka plików systemowych, kont użytkowników czy infrastruktury produkcyjnej, wymaga pełnej świadomości, co dokładnie robi każda linijka.

Rozsądny scenariusz użycia wygląda tak:

• opisujesz problem i kontekst (system, wersję PowerShell, ograniczenia),
• dostajesz szkic skryptu,
• korygujesz go, prosisz o wyjaśnienia poszczególnych fragmentów,
• testujesz na środowisku testowym lub na kopiach danych,
• dopiero później przenosisz do produkcji.

Mit: „ChatGPT napisze za mnie idealny skrypt PowerShell od razu na produkcję”. Rzeczywistość: AI przyspiesza pracę, ale odpowiedzialność za uruchomienie kodu, zrozumienie efektów i zabezpieczenie danych pozostaje w 100% po stronie człowieka.

Mit: „AI zastąpi znajomość PowerShell” vs realne wymagania

Często pojawia się przekonanie, że skoro ChatGPT generuje kod, znajomość języka jest zbędna. To prosty przepis na katastrofę. Nie trzeba być ekspertem od każdej funkcji .NET, ale bez podstaw:

• nie odróżnisz kodu niebezpiecznego od nieszkodliwego,
• nie wykryjesz subtelnych błędów logicznych w pętlach i warunkach,
• nie poprawisz skryptu, gdy w środowisku coś zachowa się inaczej niż przykładowo opisałeś w promptach.

Lepszy model: traktuj ChatGPT jako bardzo cierpliwego asystenta, który tłumaczy niejasne rzeczy i pisze „pierwszą wersję”. Ty decydujesz, co zostaje w kodzie, a co wymaga dopisania, uproszczenia lub całkowitego wyrzucenia. Paradoksalnie – regularna praca z AI potrafi przyspieszyć naukę PowerShella, bo zamiast szukać w dokumentacji losowych przykładów, możesz poprosić o fragmenty dopasowane dokładnie do twojego problemu.

Efekty biznesowe i czasowe z rozsądnego wykorzystania AI

Dla zespołu IT, który ma wiecznie za mało czasu, największy zysk nie polega na „napisaniu kilku linijek mniej”, tylko na zmianie sposobu działania. Dzięki ChatGPT można:

• przyspieszyć przygotowanie prototypów automatyzacji i szybciej przekonać decydentów do wdrożenia,
• zredukować czas spędzany na szukaniu idealnych przykładów w dokumentacji i na forach,
• urealnić przekazywanie wiedzy – młodszy administrator może dostać gotowy szkielet funkcji, a senior skupi się na weryfikacji i architekturze,
• łatwiej utrzymać spójny styl kodu dzięki odpowiednio przygotowanym promptom (wymaganie komentarzy, pełnych nazw cmdletów, wzorca obsługi błędów).

Różnica w praktyce: zamiast spędzić pół dnia na klejeniu raportu z kilku modułów i stron dokumentacji, można w godzinę zbudować działającą wersję, przez resztę czasu testując ją, doczyszczając i zabezpieczając. To właśnie ten przesunięty balans – mniej „klepania”, więcej inżynierskiego myślenia – stanowi realną przewagę łączenia ChatGPT z PowerShellem.

Przygotowanie warsztatu: środowisko PowerShell i dostęp do ChatGPT

Windows PowerShell vs PowerShell 7+: dlaczego wersja ma znaczenie dla promptów

Przed rozpoczęciem współpracy z ChatGPT dobrze uświadomić sobie, na jakiej wersji PowerShella się pracuje. Istnieją dwie główne linie:

• Windows PowerShell 5.1 – domyślnie zainstalowany w wielu systemach Windows, ściśle zintegrowany z Windows (WMI, rejestr, moduły administracyjne).
• PowerShell 7+ – wieloplatformowy, działa na Windows, Linux i macOS, rozwijany aktywnie, ma trochę inne zachowania w niektórych obszarach (np. piping obiektów, błędy, kompatybilność modułów).

W promptach do ChatGPT dobrze jasno podawać:

• „Używam PowerShell 5.1 na Windows Server 2019”,
• lub: „Potrzebuję skryptu w PowerShell 7.3, który ma działać zarówno na Windows, jak i Linux”.

Dzięki temu model nie zaproponuje cmdletów dostępnych tylko w nowszej wersji ani nie oprze się na modułach typowo windowsowych, gdy planujesz uruchomienie skryptu na Linuxie. Brzmi banalnie, ale właśnie brak tej informacji często powoduje drobne, lecz uciążliwe poprawki.

Wybór edytora: PowerShell ISE vs VS Code

Do pracy ze skryptami generowanymi przez ChatGPT przydaje się wygodne środowisko, które ułatwia czytanie, uruchamianie i poprawianie kodu. Najpopularniejsze opcje:

• PowerShell ISE – wbudowany w Windows, prosty, z podświetlaniem składni, dzielonym oknem (kod + konsola). Dobry do prostych zadań, ale coraz rzadziej rozwijany.
• Visual Studio Code z rozszerzeniem PowerShell – pełnoprawne IDE z:
  • podpowiadaniem składni,
  • debuggerem (breakpointy, krokowe wykonywanie),
  • integracją z Git,
  • możliwością instalacji dodatkowych rozszerzeń, np. do pracy z REST API czy skrótami do ChatGPT.

Dla pracy w stylu „ChatGPT generuje – ty dopracowujesz i testujesz” najlepszym wyborem jest VS Code. Umożliwia szybkie przełączanie między plikami .ps1, oknem terminala i ewentualnie plikami Markdown, w których możesz trzymać opis promptów oraz notatki. Jeśli jednak w środowisku korporacyjnym nie ma zgody na instalację VS Code, ISE nadal pozwoli wygodnie wklejać wygenerowany kod i uruchamiać go krok po kroku.

Dostęp do ChatGPT: przeglądarka, integracje i API

Najprostszy kontakt z ChatGPT odbywa się przez przeglądarkę. W kontekście PowerShella to często w zupełności wystarczy – rozmowa w oknie czatu, kopiowanie fragmentów kodu do edytora i z powrotem. Istnieją jednak dodatkowe możliwości:

• Wtyczki do VS Code – różne rozszerzenia (oficjalne lub społecznościowe) pozwalają wysyłać zaznaczony kod bezpośrednio jako część promptu i odbierać odpowiedź w postaci nowego fragmentu. To przyspiesza iteracje „popraw ten kod” lub „wyjaśnij, co robi ta funkcja”.
• API ChatGPT – przydaje się, gdy chcesz zautomatyzować pewne wzorce, np. automatyczne generowanie szablonów skryptów, komentarzy lub dokumentacji. Na potrzeby tego poradnika wystarczy świadomość, że taka opcja istnieje – szczegółowa implementacja wymaga już trochę kodu i konfiguracji.
• Integracje przeglądarkowe – dodatki do przeglądarki potrafią np. wysyłać zawartość zaznaczonej strony jako kontekst, co pomaga przy analizie dokumentacji czy kodu z blogów.

Nie trzeba zaczynać od API i rozbudowanych integracji. Dla wielu administratorów naturalna ścieżka to: przeglądarka + VS Code. Dopiero gdy współpraca z AI wejdzie w codzienny rytm, sensowne jest wdrażanie dodatków i automatycznych przepływów.

Porządkowanie promptów i odpowiedzi

Praca z ChatGPT przy PowerShellu bardzo szybko generuje masę małych, użytecznych fragmentów: funkcji, wzorców obsługi błędów, trików na eksport do CSV czy HTML. Jeśli wszystko ląduje w jednym długim czacie bez ładu, za miesiąc trudno będzie coś odnaleźć.

Proste sposoby na organizację:

• Pliki Markdown lub notatnik – osobny plik np. prompty-powershell.md, w którym trzymasz najlepiej działające wzorce promptów z krótkimi opisami.
• Repozytorium Git – katalog z plikami .ps1 posortowanymi wg kategorii (raporty, automatyzacje, AD, logi), plus README z opisem, do jakich promptów zostały wygenerowane.
• Komentarze w kodzie – na początku pliku .ps1 krótkie info:

  # Skrypt wygenerowany z pomocą ChatGPT
  # Data: 2026-01-25
  # Kontekst: raport usług krytycznych na serwerach aplikacyjnych
  

Taki porządek pomaga również przy audycie bezpieczeństwa – łatwiej zidentyfikować, co zostało napisane samodzielnie, a co wygenerowane przez AI, oraz zidentyfikować źródło ewentualnego błędu.

Prosty cykl roboczy: od promptu do działającego skryptu

Współpraca PowerShell + ChatGPT układa się w naturalną pętlę:

1. Opisujesz dokładnie zadanie w promptach, uwzględniając kontekst (system, wersja PS, ograniczenia).
2. Odbierasz pierwszy szkic skryptu lub funkcji.
3. Kopiujesz go do edytora (VS Code / ISE), czytasz, oznaczasz miejsca niejasne.
4. Pytasz ChatGPT o wyjaśnienia lub prosisz o poprawki konkretnych fragmentów (wrzucając je z powrotem jako część promptu).
5. Tworzysz środowisko testowe: katalog, pliki testowe, ewentualnie maszynę wirtualną.
6. Uruchamiasz skrypt w trybie minimalnie inwazyjnym (np. z -WhatIf lub na kopiach danych).
7. Na podstawie wyników prosisz ChatGPT o kolejne korekty (nowe warunki, obsługa wyjątków, logowanie błędów).
8. Gdy skrypt jest stabilny, przenosisz go do repozytorium, opisujesz w dokumentacji i dopiero wtedy myślisz o produkcji.

Ten cykl jest zaskakująco skuteczny pod warunkiem, że każdy etap „rozumiesz”, a nie tylko bezkrytycznie przepychasz kod między ChatGPT a konsolą.

Jak „gadać” z ChatGPT o PowerShellu: anatomia dobrego promptu technicznego

Elementy skutecznego promptu

Dobry prompt techniczny dla skryptu PowerShell składa się z kilku kluczowych części:

• Kontekst – gdzie i po co ma działać skrypt.
• Rola – określenie, jak ma „myśleć” ChatGPT (np. jak doświadczony administrator).
• Cel – opis rezultatu, jaki chcesz osiągnąć.
• Ograniczenia – czego wolno, a czego nie (np. żadnych komend usuwających bez -WhatIf).

Precyzowanie celu i zakresu skryptu

Jedna z najczęstszych pułapek: „Napisz skrypt PowerShell, który posprząta logi na serwerach” – i zdziwienie, że wynik jest mało używalny. Dla ChatGPT to zbyt szerokie zadanie. Jeśli chcesz coś, co da się uruchomić w realnym środowisku, trzeba zejść poziom niżej.

Przydatny szkielet opisu celu:

• Co – typ zadania (raport, modyfikacja, kopia, monitorowanie).
• Gdzie – konkretny zakres: katalogi, serwery, OU w AD, lista plików.
• Jak szczegółowo – format wyniku (tabela, CSV, JSON, HTML), poziom logów.
• Jak często – jednorazowy skrypt czy coś, co potem trafi do harmonogramu zadań.

Przykładowy cel, który ChatGPT potrafi przełożyć na sensowny kod:

Napisz skrypt w PowerShell 7.3, który:
- przechodzi po katalogu C:IIS-Logs na 5 serwerach WWW,
- usuwa pliki starsze niż 30 dni,
- przed usunięciem zapisuje listę plików do CSV,
- domyślnie uruchamia się w trybie -WhatIf, chyba że podam przełącznik -Force.

Mit: „Im krótszy prompt, tym sprytniej AI sobie poradzi”. Rzeczywistość: im mniej doprecyzowany cel, tym więcej poprawek po stronie człowieka. Kod będziesz czyścić tak czy inaczej, ale lepiej zacząć od szkicu zbliżonego do potrzeb niż od ogólnego generatora logów.

Opisywanie ograniczeń technicznych i organizacyjnych

PowerShell w firmie to nie plac zabaw. Często obowiązują polityki, których skrypt nie może łamać, nawet jeśli technicznie jest to możliwe. AI tych polityk nie zna – dopóki ich nie opiszesz.

Dobrym nawykiem jest krótka sekcja „zakazy i ograniczenia” dodawana wprost do promptu, np.:

• „Skrypt nie może wymagać uprawnień lokalnego administratora.”
• „Nie wolno korzystać z zewnętrznych modułów z PSGallery, tylko moduły preinstalowane na Windows Server 2019.”
• „Żadnych operacji usuwania wprost – tylko -WhatIf i logowanie do pliku.”
• „Skrypt ma działać bez dostępu do Internetu (brak wywołań HTTP na zewnątrz).”

To drobiazg, który często decyduje, czy otrzymany kod nadaje się choćby do testów w twojej sieci. Bez tego ChatGPT dołoży np. import modułu z PSGallery, bo „tak szybciej” – a ty zderzysz się z blokadą proxy i polityką bezpieczeństwa.

Proszenie o styl kodu i standardy

Skrypty generowane przez AI łatwo rozpoznać po przypadkowych nazwach zmiennych i zbyt ogólnych komentarzach. Można to ograniczyć już w promptach, prosząc o konkretny styl:

• „Używaj pełnych nazw cmdletów (bez aliasów).”
• „Nazwy funkcji zgodne z konwencją Verb-Noun (Get-, Set-, Test-).”
• „Dodaj komentarze w języku polskim przy kluczowych sekcjach (inicjalizacja, walidacja, zapis wyników).”
• „Zaimplementuj obsługę błędów z try/catch i logowaniem do pliku.”

Dobry trik: poprosić raz o „szablon stylu” i później do niego się odwoływać. Najpierw prompt:

Przygotuj krótki przykład funkcji PowerShell,
która pokazuje, jak ma wyglądać nasz standard:
- nazewnictwo parametrów,
- logowanie do pliku,
- obsługa błędów,
- podsumowanie działania na końcu.

Potem w kolejnych promptach będę pisał: „stosuj taki sam styl jak w poprzednim przykładzie”.

Mit: „AI i tak będzie pisać po swojemu, nie ma sensu dorzucać wymagań co do stylu”. Rzeczywistość: model całkiem dobrze trzyma się zadanych wzorców, szczególnie w ramach jednej sesji czatu. Jeśli styl „pływa”, zwykle brakuje jasnego żądania albo rozpocząłeś nową rozmowę bez przypomnienia standardów.

Dodawanie przykładowych danych i scenariuszy

Teoretyczny opis bywa zbyt abstrakcyjny. Dużo lepsze efekty pojawiają się, gdy wrzucisz 2–3 krótkie przykłady wejścia i oczekiwanego wyjścia. Dla PowerShella to może być fragment CSV, fragment logu, wycinek JSON lub pojedyncza linia z Get-Process.

Przykład promptu z danymi:

Chcę przetwarzać plik CSV z kolumnami: ServerName, Role, OwnerEmail.
Przykładowa zawartość:

ServerName,Role,OwnerEmail
WEB01,WebServer,dev-team@example.com
DB01,Database,dba-team@example.com

Napisz skrypt w PowerShell 5.1, który:
- odczyta ten plik,
- dla każdego serwera sprawdzi, czy jest online (Test-Connection),
- zwróci tabelę z kolumnami: ServerName, Role, Online (True/False).

Takie uziemienie zadania sprawia, że wynikowy kod jest bliżej realiów, a nie abstrakcyjnych przykładów z dokumentacji. Dodatkowo łatwiej potem przygotować testy – plik z przykładową zawartością już masz.

Iteracyjne doprecyzowywanie promptów na żywym przykładzie

Kluczem nie jest jednorazowy perfekcyjny prompt, tylko kilka prostych iteracji, w ramach których stopniowo doklejasz ograniczenia i oczekiwania. Szybki, realistyczny scenariusz:

1. Prosisz: „Napisz skrypt PS7, który pobiera listę usług z serwera i zapisuje do CSV”.
2. Dostajesz wersję bez obsługi błędów i bez logowania.
3. Uruchamiasz na testowym serwerze, widzisz, że na niedostępnej maszynie skrypt się wywala.
4. Wklejasz fragment błędu do ChatGPT i prosisz: „Dodaj obsługę sytuacji, gdy serwer nie odpowiada. W takim wypadku dopisz do CSV wiersz z Online = False i kolumną ErrorMessage.”
5. Dostajesz poprawioną wersję, którą znowu testujesz.

Ta pętla jest dużo bardziej efektywna niż próba przewidzenia od razu wszystkich możliwych scenariuszy. Zwłaszcza gdy dopisujesz: „Oto aktualna wersja skryptu” i wklejasz cały kod – model ma wtedy kontekst i jest w stanie wprowadzić spójne zmiany, zamiast pisać wszystko od nowa.

Formułowanie próśb o refaktoryzację i wyjaśnienia

ChatGPT nadaje się nie tylko do generowania świeżego kodu, ale też do porządkowania istniejących skryptów. W tym przypadku prompt powinien jasno definiować, co chcesz zmienić, a czego nie ruszać.

Skuteczny wzorzec:

Oto mój skrypt w PowerShell 5.1 (poniżej).
Zachowaj jego logikę, ale:
- podziel go na dwie funkcje: Get-Data i Export-Report,
- usuń powtórzenia kodu,
- dodaj podstawową obsługę błędów z try/catch,
- nie zmieniaj nazw parametrów funkcji publicznej.

[tu wklej kod]

Możesz też poprosić o wyjaśnienie konkretnego fragmentu:

Wyjaśnij krok po kroku, co robi poniższy fragment,
tak jakbyś tłumaczył junior administratorowi:

[fragment funkcji]

To dobry sposób na własne „code review na żądanie”, szczególnie przy starych skryptach bez dokumentacji. Często w ten sposób wychodzą na jaw ukryte założenia, o których autor sprzed kilku lat już nie pamięta.

Tworzenie pierwszych skryptów PowerShell z ChatGPT – krok po kroku

Ustalenie prostego, bezpiecznego zadania na start

Na początek najlepiej wybrać zadanie, które:

• jest odczytowe (żadnych modyfikacji w systemie),
• da się łatwo zweryfikować „na oko” (raport, lista, podsumowanie),
• nie wymaga uprawnień admina domeny ani dotykania produkcji.

Dobre przykłady na pierwsze zastosowania:

• raport z ilości miejsca na dyskach i top 10 największych katalogów w wybranym folderze,
• lista procesów przekraczających określony próg użycia RAM lub CPU,
• podsumowanie aktywnych sesji RDP na serwerze.

Mit: „Skoro to AI, to od razu mogę jej powierzyć skrypt do czyszczenia kont w AD”. Rzeczywistość: najpierw trzeba sprawdzić, jak model „rozumie” twoje środowisko i styl pracy na przykładach, które nie zrobią bałaganu.

Formułowanie pierwszego promptu dla zadania raportowego

Przykładowy pierwszy prompt dla zadania z dyskami może wyglądać tak:

Działam na Windows Server 2019 z PowerShell 5.1.
Napisz skrypt PowerShell, który:

- pobiera listę wszystkich dysków logicznych na lokalnej maszynie,
- dla każdego dysku wylicza: literę, etykietę, całkowity rozmiar, wolne miejsce w GB i procent wolnego miejsca,
- wynik zapisuje do pliku CSV w katalogu C:Raporty z nazwą w formacie dyski-YYYY-MM-DD.csv,
- dodatkowo wypisuje tabelę w konsoli posortowaną rosnąco po procent wolnego miejsca.

Użyj pełnych nazw cmdletów, dodaj komentarze po polsku do kluczowych linii.

Tak sformułowane polecenie daje szansę na kod, który po lekkiej korekcie możesz od razu przetestować na swoim serwerze. Następny krok to już nie pisanie od zera, ale wprowadzanie usprawnień.

Analiza wygenerowanego skryptu przed pierwszym uruchomieniem

Po otrzymaniu skryptu sensowne jest krótkie „code review” jeszcze w oknie czatu albo już w edytorze:

• Sprawdź, czy nie ma komend modyfikujących pliki, rejestr lub usługi, jeśli ich nie żądałeś.
• Zwróć uwagę na ścieżki – czy katalogi (np. C:Raporty) są tworzone, jeśli nie istnieją.
• Oceń sposób obsługi błędów – czy skrypt nie przerwie się przy pierwszym ostrzeżeniu.
• Sprawdź, czy nie użyto modułów, których nie masz w środowisku.

Jeżeli coś wygląda podejrzanie lub niespójnie, zaznacz fragment i poproś ChatGPT o wyjaśnienie lub zmianę. Dużo lepiej pytać: „Dlaczego użyłeś tu Get-WmiObject zamiast Get-CimInstance? Potrzebuję rozwiązania, które będzie działać też w PS7.” niż samemu dorabiać intencje.

Uruchomienie w trybie minimalnie inwazyjnym

W przypadku skryptów, które coś zmieniają (tworzą, modyfikują, kasują), pierwsze odpalenie powinno być maksymalnie „miękkie”. Do wyboru jest kilka taktyk:

• Dodanie przełącznika -WhatIf do cmdletów typu Remove-Item, Stop-Service, Disable-ADAccount.
• Praca na kopiach danych (np. katalog testowy zamiast produkcyjnego udziału plików).
• Ręczne „wyłączenie” destrukcyjnych linii przez komentarze (#) i sprawdzenie tylko części odczytowej.

Możesz też poprosić ChatGPT o przerobienie skryptu na wersję „suchą”:

Przerób poniższy skrypt tak, aby:
- wszystkie operacje usuwania plików działały tylko z parametrem -WhatIf,
- dodać przełącznik -ForceDeletion, który dopiero po podaniu usunie pliki naprawdę.

[tu wklej kod]

W ten sposób od razu narzucasz sobie i innym bezpieczniejszy nawyk uruchamiania.

Dodawanie logowania i parametrów wejściowych

Drugim krokiem po działającym „na sztywno” skrypcie jest uczynienie go bardziej elastycznym. Najprościej przez:

• parametry – zamiast twardo zakodowanych ścieżek lub nazw serwerów,
• logowanie – podstawowy plik z informacją, co i kiedy zostało wykonane.

Przykład promptu, który rozszerza gotowy już skrypt:

Dodaj do poniższego skryptu:

- blok param() z parametrem [string]$OutputPath 
  z domyślną wartością 'C:Raporty',
- logowanie do pliku log w tym samym katalogu z nazwą w formacie skrypt-YYYY-MM-DD.log,
- wpisy w logu dla startu skryptu, zakończenia i dla każdego błędu.

Nie zmieniaj logiki, tylko dodaj parametry i logowanie.

[tu wklej kod]

Dzięki temu skrypt generowany z pomocą AI zaczyna przypominać coś, co faktycznie można utrzymywać w czasie, a nie tylko jednorazowy „shot” do konsoli.

Rozdzielenie warstwy logiki i harmonogramu

Przy planowaniu uruchamiania w harmonogramie (Task Scheduler, cron, narzędzia orkiestracji) lepiej trzymać logikę w skryptach, a harmonogram w osobnych definicjach zadań. ChatGPT często miesza te warstwy, dodając np. przykłady z schtasks.exe do samego skryptu.

W promptach warto zaznaczyć:

Separacja skryptu roboczego od skryptu „harmonogramowego”

Zamiast dodawać do głównego skryptu kawałki z schtasks.exe czy polecenia rejestrujące zadanie w Task Schedulerze, wygodniej jest rozdzielić role:

• skrypt A – robi właściwą robotę (logika, raporty, czyszczenie),
• skrypt B – jednorazowo tworzy/aktualizuje zadanie w harmonogramie, wskazując na skrypt A.

Taki podział jest czytelniejszy dla ludzi i dla ChatGPT. Jeśli prosisz model o poprawki, nie musisz za każdym razem nosić ze sobą definicji zadania – pracujesz na „czystej” logice. Dopiero gdy skrypt A jest stabilny, prosisz o pomoc przy zbudowaniu małego skryptu B, np.:

Napisz skrypt PowerShell, który tworzy zadanie w Harmonogramie zadań Windows:
- nazwa zadania: 'RaportDyskow-Daily',
- uruchamiane jest codziennie o 06:00,
- jako akcję uruchamia 'powershell.exe' z parametrami:
  -ExecutionPolicy Bypass -File "C:SkryptyRaportDyskow.ps1",
- zadanie ma działać na koncie SYSTEM.

Nie dodawaj logiki raportowania do tego skryptu, tylko samą konfigurację zadania.

Mit: „Wygodniej mieć wszystko w jednym pliku”. Rzeczywistość: po pół roku trudno zorientować się, co jest logiką biznesową, a co konfiguracją harmonogramu. Rozdzielenie ułatwia debugowanie i zmiany, także przy kolejnych iteracjach z AI.

Wzorce promptów do typowych zadań w PowerShellu

Raporty z systemu plików i serwerów plików

Dla zadań typu „przynieś mi raport” dobrym punktem wyjścia jest jasne opisanie:

• zakresu (katalog, wolumin, udział),
• kryteriów (rozmiar, wiek plików, rozszerzenia),
• formy wyniku (CSV, tabela, HTML, JSON).

Przykładowy wzorzec promptu, który łatwo przerabiać pod kolejne raporty:

Potrzebuję skryptu PowerShell 7, który:

- rekurencyjnie skanuje katalog FILE01DaneProjekty,
- dla każdego pliku zwraca: pełną ścieżkę, nazwę, rozmiar w MB,
  datę ostatniej modyfikacji i właściciela NTFS,
- filtruje tylko pliki większe niż 100 MB,
- zapisuje wynik do pliku CSV w C:Raportyduze-pliki.csv,
- w konsoli pokazuje tylko top 20 największych plików.

Dodaj komentarze po polsku, nie używaj modułów spoza standardowego PowerShella.

Taki szablon można potem adaptować: zmieniać ścieżki, kryteria, format wyników. Model ma jasne „ramy” i nie próbuje zgadywać, co chcesz dostać na wyjściu.

Administracja usługami i procesami

Przy usługach i procesach sprawdza się jasne rozdzielenie trybu odczytowego od wykonawczego. Lepiej zacząć od wersji, która niczego nie zatrzymuje, tylko sygnalizuje problem.

Napisz skrypt w PowerShell 5.1, który:

- pobiera listę usług na lokalnym serwerze,
- wybiera tylko usługi typu 'Automatic', które są zatrzymane,
- wyświetla je w tabeli z kolumnami: Name, DisplayName, Status, StartType,
- zapisuje tę listę do CSV w C:Raportyuslugi-zatrzymane.csv,

Skrypt ma być tylko raportowy, bez prób uruchamiania usług.

Gdy raport działa poprawnie, dopiero wtedy można dodać drugą wersję promptu z logiką naprawczą, np. uruchamianie wybranych usług z listy, ale z dodatkowymi zabezpieczeniami (log, potwierdzenia, przełącznik -Force).

Zarządzanie użytkownikami i AD bez dotykania produkcji

Przy katalogu Active Directory pojawia się klasyczny mit: „Jak poproszę AI o skrypt, to na pewno będzie zgodny z naszymi zasadami bezpieczeństwa”. Rzeczywistość – model nie zna wewnętrznych procedur, a domyślne skrypty potrafią być zbyt agresywne.

Dlatego w promptach lepiej ustawiać bezpieczne ograniczenia:

Potrzebuję skryptu w PowerShell 5.1 na serwerze z modułem ActiveDirectory, który:

- wyszukuje konta użytkowników w OU "OU=Users,DC=example,DC=local",
- zwraca tylko konta, które:
  - nie logowały się od co najmniej 90 dni
  - mają Enabled = True,
- wynik zapisuje do CSV (bez wykonywania jakichkolwiek zmian w AD),
- w konsoli pokazuje tylko podsumowanie: liczba znalezionych kont.

Skrypt ma być wyłącznie raportowy, bez wyłączania, usuwania czy blokowania kont.

Jeśli docelowo chcesz czyścić konta, możesz później wysłać kolejny prompt, który rozszerza ten konkretny skrypt o działania modyfikujące, np.:

Na podstawie poniższego skryptu dodaj nową funkcję Disable-StaleAdAccounts, która:

- przyjmuje ścieżkę do pliku CSV z listą kont,
- wyłącza wskazane konta w AD,
- dla każdego konta dodaje wpis do logu tekstowego.

Nie modyfikuj istniejącej części raportowej, dodaj jedynie nową funkcję z obsługą błędów.

Integracja z REST API i narzędziami zewnętrznymi

API to kolejna przestrzeń, w której ChatGPT potrafi mocno przyspieszyć start, szczególnie przy żmudnym budowaniu żądań HTTP i nagłówków. Ważne, aby w promptach jasno zaznaczyć, jakie informacje już masz: endpoint, token, przykład odpowiedzi.

Pracuję na PowerShell 7. 
Mam REST API pod adresem https://monitoring.example.com/api/servers

- autoryzacja: nagłówek Authorization: Bearer <token>,
- metoda: GET,
- odpowiedź JSON zawiera pola: name, role, status, lastCheck.

Napisz skrypt, który:
- wykonuje zapytanie do tego API z podanym tokenem (przez parametr),
- filtruje tylko serwery, których status != "OK",
- wyświetla tabelę w konsoli z name, role, status, lastCheck,
- zapisuje wynik do pliku JSON w C:Raportyserwery-alert.json.

Nie używaj modułów zewnętrznych, tylko Invoke-RestMethod.

W przypadku API mit jest prosty: „Model przecież wie, jak działa to konkretne API”. Nie wie – chyba że sam mu pokażesz fragment dokumentacji albo przykładową odpowiedź. Bez tego będzie zgadywać nazwy pól i parametry.

Automatyzacja zadań administracyjnych na wielu serwerach

Przy pracy z wieloma maszynami prompt powinien od razu określać sposób połączenia (WinRM, SSH, moduły zdalne), a także model wykonania (sekwencyjnie, równolegle, z przerwami). Nawet proste doprecyzowanie oszczędza późniejszego przerabiania kodu.

Potrzebuję skryptu PowerShell 7, który:

- czyta listę serwerów z pliku C:Daneserwery.txt (po jednym serwerze w linii),
- dla każdego serwera zdalnie (Invoke-Command, WinRM) wykonuje:
  - Get-Service z filtrem na usługi, których nazwa zaczyna się od 'SQL',
- zwraca obiekt z polami: ServerName, ServiceName, Status,
- wynik zapisuje do CSV,
- jeśli połączenie do danego serwera się nie powiedzie, dopisuje do CSV wiersz
  z ServiceName = 'N/A' i Status = 'ConnectionFailed'.

Kod ma działać sekwencyjnie (bez runspace'ów i Jobs), z prostą obsługą błędów.

Później możesz poprosić o wersję równoległą (np. z ForEach-Object -Parallel) albo o wariant z logowaniem szczegółów do osobnego pliku dla każdego serwera, ale nie mieszaj tych wymagań w pierwszej iteracji.

Testowanie i uruchamianie skryptów generowanych przez ChatGPT

Dlaczego „kompilacja w głowie” nie wystarczy

Nawet przy prostym skrypcie wygenerowanym przez AI kuszące jest przejrzenie go wzrokiem, uznanie, że „wygląda dobrze” i odpalenie na produkcji. To pułapka. Model może popełnić subtelne błędy: inne typy danych niż oczekujesz, nieobsłużone ścieżki, inne zachowanie w PS5.1 i PS7.

Przegląd kodu to dopiero pierwsze sito. Potrzebne są jeszcze choćby minimalne testy: na plikach testowych, w odseparowanym środowisku, z parametrami, które nie zniszczą realnych danych. Nawet jeśli brzmi to banalnie, właśnie na tym etapie najczęściej wychodzi, że „drobne założenie” modelu nie pasuje do twojej infrastruktury.

Przygotowanie danych testowych i środowiska

Najwięcej problemów powoduje testowanie skryptu od razu na „prawdziwych” serwerach lub udziałach plików. Bezpieczniej jest zbudować miniaturową piaskownicę:

• katalog testowy odzwierciedlający strukturę produkcyjną, ale z przykładowymi plikami,
• osobny OU w AD z kilkoma sztucznymi kontami,
• lista 2–3 serwerów testowych w pliku CSV lub TXT.

Możesz wręcz poprosić ChatGPT o pomoc w przygotowaniu takich danych:

Napisz prosty skrypt PowerShell, który:

- tworzy katalog C:TestDane,
- tworzy w nim 3 podkatalogi: ProjektA, ProjektB, ProjektC,
- w każdym z nich tworzy po 10 plików tekstowych o losowej wielkości 
  między 1 KB a 500 KB,
- do każdego pliku wpisuje pojedynczą linię z datą utworzenia.

Na takim „piasku” łatwiej wykryć, że np. filtr rozmiaru działa odwrotnie, ścieżki są źle łączone albo CSV ma złe kodowanie.

Ręczne testy krok po kroku (happy path + negatywne)

Dla większości skryptów administracyjnych wystarczą dwa typy testów:

• happy path – typowe, poprawne dane wejściowe,
• negatywne – brak pliku, pusty katalog, brak uprawnień, niedostępny serwer.

Dobry nawyk to uruchamianie skryptu z różnymi zestawami parametrów i obserwacja, czy:

• komunikaty o błędach są zrozumiałe,
• skrypt przerywa się natychmiast, czy próbuje sensownie dokończyć pracę,
• wynik (raport, log) jest spójny nawet przy błędach po drodze.

Jeżeli komunikaty są nieczytelne, warto poprosić ChatGPT o dosypanie lepszego logowania, zamiast godzić się na domyślne wyjątki z .NET.

Proszenie ChatGPT o pomoc w diagnozie błędów

Zamiast opisywać błędy własnymi słowami, lepiej pokazać konkret. Wklejenie komunikatu i fragmentu kodu daje modelowi szansę na analizę kontekstu, a nie zgadywanie.

Po uruchomieniu skryptu pojawia się błąd:

[tu wklej pełny komunikat błędu z PowerShella]

Poniżej fragment kodu, którego dotyczy błąd:

[tu wklej fragment funkcji]

Wyjaśnij przyczynę i zaproponuj minimalną poprawkę, 
która rozwiązuje problem bez zmiany ogólnej logiki skryptu.

Taka prośba zawęża pole manewru. Zamiast przepisywać cały skrypt, model koncentruje się na usunięciu jednej przeszkody. Przy kolejnych iteracjach możesz dodawać następne błędy lub prośby o usprawnienie.

Automatyczne testy z Pesterem – wersja minimalna

Jeżeli skrypt zaczyna żyć dłużej niż tydzień, warto dorobić choćby kilka testów z użyciem Pestera. Nie trzeba od razu projektować złożonego TDD – nawet proste sprawdzenie, czy funkcja zwraca wynik w oczekiwanym formacie, już chroni przed częścią regresji.

Przykładowy prompt do zainicjowania testów:

Mam funkcję PowerShell Get-DiskReport, która:

- przyjmuje parametr [string]$Path,
- zwraca kolekcję obiektów z polami: DriveLetter, TotalGB, FreeGB, FreePercent.

Napisz przykładowy zestaw testów Pester (dla PS7 i Pester 5), który:

- sprawdza, że funkcja zwraca niepustą kolekcję dla istniejącej ścieżki,
- weryfikuje, że pola FreePercent są między 0 a 100,
- sprawdza, że wywołanie z nieistniejącą ścieżką rzuca wyjątek.

Zastosuj konwencję Describe/Context/It.

Model potrafi szybko zbudować szkielet testów, który dalej można już przycinać do realiów środowiska. Mit, że „Pester to tylko dla deweloperów”, zwykle upada po pierwszym razie, gdy testy łapią regresję w skrypcie administracyjnym.

Symulowanie działania skryptu przez „testy na sucho”

Jeżeli nie chcesz od razu inwestować w pełen zestaw testów automatycznych, można używać prostego mechanizmu „trybu symulacji”. W promptach da się to narzucić już na etapie generowania kodu:

Napisz skrypt PowerShell 7, który:

- przyjmuje parametr [switch]$WhatIfMode,
- gdy $WhatIfMode jest ustawiony, zamiast usuwać pliki, 
  tylko wypisuje w konsoli, które pliki byłyby usunięte,
- gdy $WhatIfMode NIE jest ustawiony, wykonuje faktyczne usuwanie.

Zastosuj to do operacji usuwania plików starszych niż 30 dni w katalogu 
podanym parametrem [string]$Path.

Taki przełącznik jest prosty, a chroni przed wieloma nerwami. Dodatkowo świetnie sprawdza się przy recenzji kodu z innymi osobami – można po prostu odpalić skrypt w trybie „co by się stało, gdyby…”.

Porównywanie wyjścia skryptu z oczekiwanym wynikiem

Najczęściej zadawane pytania (FAQ)

Czy ChatGPT może samodzielnie napisać bezpieczny skrypt PowerShell do produkcji?

Nie. ChatGPT może przygotować szkielet, prototyp lub przykład, ale nie zwalnia z obowiązku pełnej weryfikacji kodu przed uruchomieniem na produkcji. Model generuje „wiarygodnie wyglądający” skrypt, który może zawierać błędy logiczne, pomyłki w cmdletach lub nie uwzględniać specyfiki konkretnego środowiska.

Bezpieczny proces wygląda tak: opisujesz dokładnie środowisko i wymagania, prosisz o szkic, dopytujesz o wyjaśnienie fragmentów, testujesz w środowisku testowym lub na kopiach danych, dopiero potem wdrażasz do produkcji. Mit brzmi: „AI od razu da mi gotowy kod na produkcję”. Rzeczywistość: AI skraca czas od pomysłu do pierwszej wersji, ale odpowiedzialność za konsekwencje uruchomienia skryptu zostaje po twojej stronie.

Czy znajomość PowerShell jest jeszcze potrzebna, skoro ChatGPT generuje kod za mnie?

Tak, podstawy PowerShell są absolutnie kluczowe. Bez nich trudno ocenić, czy wygenerowany skrypt jest bezpieczny, poprawny i sensowny. Osoba, która nie rozumie pętli, warunków, potoków czy typowych cmdletów, nie zauważy subtelnych błędów albo niebezpiecznych operacji na plikach czy kontach.

Bardziej realistyczne podejście: traktuj ChatGPT jak asystenta, który pisze pierwszą wersję i tłumaczy niejasne kawałki, a ty decydujesz, co zmienić, skrócić, wyrzucić. Paradoksalnie, regularna praca z AI potrafi przyspieszyć naukę – zamiast szukać losowych przykładów w dokumentacji, masz fragmenty dopasowane dokładnie do twojego problemu, które możesz krok po kroku analizować.

Do jakich zadań w PowerShellu ChatGPT przydaje się najbardziej?

Największy zysk jest tam, gdzie zadania są powtarzalne, ale jednocześnie „nudno‑skomplikowane”. Chodzi o rzeczy, które normalnie zajmują sporo czasu na szukanie przykładów i składni, a niekoniecznie wymagają genialnych trików.

Typowe przykłady zastosowań:

• generowanie boilerplate’u: funkcje z parametrami, standardowa obsługa błędów, logowanie do pliku;
• tworzenie raportów i eksportów: listy użytkowników, usług, procesów do CSV/HTML/JSON;
• „klejenie” kilku narzędzi w jeden skrypt: sekwencje cmdletów, pętle, warunki, filtrowanie;
• przepisanie batch/Bash na PowerShell i rozbijanie trudnych one‑linerów na czytelne funkcje;
• szybkie prototypy: sprawdzenie, czy dana automatyzacja ma sens, zanim poświęcisz dzień na dopieszczanie.

Dobry, praktyczny scenariusz: zamiast pół dnia na „klepanie” raportu z dokumentacją przed nosem, w godzinę generujesz działającą wersję z ChatGPT, a resztę czasu poświęcasz na testy, poprawki i zabezpieczenia.

Jak formułować prompt do ChatGPT, żeby dostać lepszy kod PowerShell?

Im bardziej konkretny opis kontekstu, tym lepsza odpowiedź. Zamiast „napisz skrypt do logów”, napisz: „Używam PowerShell 5.1 na Windows Server 2019. Potrzebuję skryptu, który codziennie przenosi pliki logów *.log starsze niż 7 dni z C:Logs do serwerarchiwum, z logowaniem działań do pliku tekstowego”. To od razu zawęża przestrzeń błędów.

W promptach opłaca się podać:

• wersję i system: np. „PowerShell 7.3 na Windows i Linux” albo „Windows PowerShell 5.1 na serwerach AD”;
• ograniczenia: brak dostępu do internetu, brak możliwości instalacji nowych modułów;
• preferencje stylu: np. „używaj pełnych nazw cmdletów, dodaj komentarze i obsługę błędów przez try/catch”.

Mit: „wystarczy napisać jedno zdanie i dostanę idealny skrypt”. W praktyce często potrzebna jest iteracja – pierwsza odpowiedź, twoje uwagi, poprawka, doprecyzowanie danych wejściowych i dopiero wtedy kod zaczyna realnie pasować do środowiska.

Czy lepiej używać Windows PowerShell 5.1 czy PowerShell 7 z ChatGPT?

To zależy od środowiska. Windows PowerShell 5.1 jest mocno zintegrowany z Windows, ma gotowe moduły administracyjne i „po prostu jest” na wielu serwerach. Jeśli pracujesz głównie z infrastrukturą Windows (AD, WMI, rejestr), często i tak skończysz na 5.1, bo część modułów nie jest w pełni wspierana w 7+.

PowerShell 7+ jest za to wieloplatformowy, aktywnie rozwijany i wygodniejszy, gdy tworzysz skrypty, które mają działać i na Windows, i na Linuxie. Kluczowe jest, żeby w promptach jasno podawać wersję i systemy docelowe. Wtedy ChatGPT nie będzie proponował cmdletów czy modułów, które istnieją tylko w „drugiej” linii i unikniesz serii drobnych, frustrujących poprawek.

Jakie środowisko (edytor) jest najlepsze do pracy ze skryptami z ChatGPT?

Najwygodniej pracuje się w Visual Studio Code z rozszerzeniem PowerShell. Masz wtedy podświetlanie składni, IntelliSense, debugger (breakpointy, krokowe wykonywanie), integrację z Git oraz możliwość trzymania w jednym miejscu skryptów .ps1, notatek i plików z promptami. To ułatwia cykl: skopiuj z ChatGPT → wklej → uruchom krokowo → popraw.

Jeśli polityka w firmie blokuje instalację VS Code, możesz spokojnie używać wbudowanego PowerShell ISE. Nie ma tylu bajerów, ale do wklejania kodu z ChatGPT, prostych poprawek i testów „linijka po linijce” zupełnie wystarcza. Istotniejsze od wyboru edytora jest to, żebyś realnie debugował i testował wygenerowany kod, a nie tylko go kopiował i odpalał „na wiarę”.

Jakie realne korzyści biznesowe daje używanie ChatGPT przy skryptach PowerShell?

Największa korzyść to przesunięcie akcentów z „klepania” kodu na projektowanie i testy. Zamiast spędzać godziny na szukaniu idealnego przykładu raportu czy obsługi błędów, w kilkanaście minut masz działający prototyp i możesz skupić się na tym, czy skrypt robi dokładnie to, czego oczekują użytkownicy lub biznes.

Przykładowe efekty w praktyce:

• szybsze przygotowanie POC (proof of concept) automatyzacji, dzięki czemu łatwiej przekonać decydentów do wdrożenia;
• mniej czasu na przeklejanie kawałków z forów – więcej na testy, zabezpieczenia i dokumentację;
• lepsze wykorzystanie seniorów: junior generuje szkielet z ChatGPT, senior robi przegląd, poprawia architekturę i standardy.

Co warto zapamiętać

• PowerShell to pełnoprawny język automatyzacji oparty na .NET, operujący na obiektach, więc razem z ChatGPT tworzy silne combo do zadań administracyjnych – od porządkowania logów, przez raporty, po złożone sekwencje operacji na serwerach i w chmurze.
• Największy zysk z użycia ChatGPT pojawia się przy powtarzalnych, schematycznych zadaniach: generowaniu boilerplate’u (funkcje, obsługa błędów, logowanie), raportów (CSV/HTML/JSON), „klejeniu” kilku narzędzi w jeden skrypt czy szybkim prototypowaniu rozwiązań.
• Mit, że „ChatGPT napisze idealny skrypt prosto na produkcję”, rozbija się o praktykę: AI generuje szkic, który trzeba zrozumieć, doprecyzować i przetestować na bezpiecznym środowisku, zanim dotknie plików systemowych, kont użytkowników czy infrastruktury produkcyjnej.
• ChatGPT nie zastępuje znajomości PowerShella – bez podstaw trudno wychwycić niebezpieczne polecenia, subtelne błędy logiczne czy dopasować skrypt do specyfiki konkretnego środowiska; to asystent do „pierwszej wersji”, a nie substytut kompetencji.
• Rozsądny workflow wygląda tak: jasny opis problemu i kontekstu, wygenerowanie szkicu, dopytanie o niejasne fragmenty, poprawki, testy na kopiach danych, a dopiero na końcu wdrożenie produkcyjne – odpowiedzialność za efekt zawsze zostaje po stronie człowieka.

Źródła informacji

• PowerShell Documentation. Microsoft – Oficjalna dokumentacja języka PowerShell, cmdletów i modułów
• PowerShell Scripting. Microsoft Learn – Przewodniki i tutoriale dotyczące pisania skryptów PowerShell
• PowerShell Best Practices. Red Hat – Rekomendacje dotyczące bezpiecznego i czytelnego tworzenia skryptów automatyzacji
• DevOps and Automation with PowerShell. Pluralsight – Materiały szkoleniowe o użyciu PowerShell w automatyzacji i DevOps
• Secure Coding Guidelines for PowerShell. SANS Institute – Zalecenia bezpieczeństwa przy tworzeniu i uruchamianiu skryptów PowerShell