Otwarty warsztat pracy z AI
Instrukcje, które można sprawdzić
„Sprawdź ten projekt” to za mało, żeby wiedzieć, czy praca została wykonana dobrze. Open Prompts pokazuje, jak zamienić taką prośbę w zadanie z kontekstem, granicami i kryteriami odbioru.
- AI
- Bezpieczeństwo aplikacji
- DevSecOps
- Markdown
Problem
Odpowiedź modelu może brzmieć przekonująco, a mimo to pomijać cel zadania. Bez zakresu i kryteriów trudno ocenić, czy audyt znalazł rzeczywisty problem, czy projekt interfejsu odpowiada na potrzeby użytkownika.
Rozwiązanie
Zapisuję instrukcje jak brief do konkretnej pracy: z kontekstem, ograniczeniami, oczekiwanym rezultatem i sposobem jego sprawdzenia. Publikuję je w Markdown, żeby można je było przeczytać, dopasować i rozwijać w Git.
Od „zrób audyt” do konkretnego zadania
Załóżmy, że prosisz model o sprawdzenie bezpieczeństwa aplikacji. Dostajesz długą listę porad: waliduj dane, chroń tokeny, aktualizuj biblioteki. Wszystko brzmi rozsądnie, ale nadal nie wiesz, który fragment twojego kodu wymaga poprawy. Ten przykład dobrze pokazuje problem, wokół którego zbudowany jest Open Prompts.
Repozytorium zbiera instrukcje, których używam lub które dostosowuję w pracy nad projektami. Każda ma pomóc przejść od ogólnej intencji do zadania możliwego do oceny. Czy model zbadał właściwy obszar? Czy podał dowody? Czy wiadomo, co jest ustaleniem, a co dopiero hipotezą?
Instrukcja zaczyna się przed pierwszym poleceniem
Dobry punkt wyjścia to opis aplikacji, stosu technologicznego i celu pracy. Potem pojawiają się granice: które elementy można zmieniać, czego nie należy zakładać i jaki rezultat ma powstać. Tak zapisany brief można przejrzeć jeszcze przed uruchomieniem modelu.
To szczególnie przydatne przy pracy z istniejącym produktem. Redesign powinien uwzględniać jego funkcję, treść i dostępność. Audyt SEO powinien najpierw wskazać problemy oraz ich znaczenie. Przegląd bezpieczeństwa potrzebuje odniesienia do rzeczywistych przepływów danych i kodu.
Sześć różnych zadań, wspólna zasada
W zbiorze są materiały do przeglądu bezpieczeństwa kodu, projektowania pipeline’u DevSecOps i modelowania zagrożeń. Obok nich znajdują się instrukcje do poprawy UI/UX, audytu SEO oraz strony produktowej z modelem 3D. Każdy z tych obszarów wymaga innych pytań i innego sposobu oceny rezultatu.
Instrukcja audytu SEO rozdziela analizę od dalszego planowania, zostawiając człowiekowi punkt decyzji. Materiał do threat modelingu prowadzi przez architekturę, przepływy danych i granice zaufania. W code review liczą się dowód w kodzie, warunki wykorzystania problemu i konkretna poprawka.
Dlaczego zwykły Markdown
Instrukcję można otworzyć bez dodatkowej aplikacji, skopiować do wybranego narzędzia i dopasować do projektu. Git zachowuje historię zmian. Kiedy doprecyzujesz kryterium lub usuniesz niejasne polecenie, widać dokładnie, co się zmieniło.
Ta prostota ułatwia także rozmowę w zespole. Można oceniać sam sposób zlecania pracy: czy zakres jest jasny, czy model ma wystarczający kontekst i czy instrukcja nie wymaga wniosków, których nie da się poprzeć dostępnymi materiałami.
Wynik trzeba umieć odebrać
Open Prompts daje gotowe punkty wyjścia, ale wymaga dopasowania założeń, technologii i kryteriów do konkretnego zadania. W materiałach bezpieczeństwa znajdują się odwołania do publicznych standardów i wskazówek, między innymi OWASP oraz NIST. Samo użycie instrukcji nie potwierdza zgodności ani bezpieczeństwa aplikacji.
Praktyczny sposób na rozpoczęcie pracy jest prosty: wybierz jeden plik, przeczytaj go w całości, uzupełnij kontekst i sprawdź wynik na rzeczywistym projekcie. Warto zachować zarówno wersję instrukcji, jak i dowody z wykonanej pracy. Wtedy kolejne podejście można świadomie poprawić.