Autoanaliza z AI — genialne czy psychoza?

W rozmowach z AI, czyli sztuczną inteligencją, wracam do pytania: „Powiedz mi coś, czego nie wiem, a powinienem wiedzieć w tym obszarze”. Albo bardziej konkretnie: „Czego mogę nie uwzględniać, a co pomoże mi lepiej wykonać to zadanie?”.

Prowokacja w tytule nie jest diagnozą. Interesuje mnie praktyczne pytanie: czy po takiej rozmowie potrafię lepiej pracować, czy tylko dostaję kolejną listę rzeczy do rozważenia?

Widzę sens w pytaniu o własną niewiedzę. Szczególnie wtedy, gdy wchodzę w nowy temat i potrafię nazwać cel, ale nie znam jeszcze wszystkich zależności. Jest jednak warunek: odpowiedź AI powinna prowadzić do sprawdzenia czegoś konkretnego. Samo wrażenie, że model odkrył głęboką prawdę, niewiele daje.

Nie zawsze umiem zadać właściwe pytanie

Gdy wiem, że nie rozumiem kopii zapasowych, mogę zapytać, jak je wykonywać. Trudniej zapytać o problem, którego jeszcze nie zauważyłem. Mogę skupiać się na tym, czy aplikacja się uruchamia, i nie uwzględniać sposobu jej odtworzenia po awarii.

Wtedy przydaje się prośba o poszerzenie perspektywy:

Znasz cel i opis mojego zadania. Jakie istotne pytanie powinienem jeszcze zadać, zanim przejdę dalej? Wyjaśnij, z czego wynika jego znaczenie.

Model może zaproponować zależności, alternatywy albo ryzyka do sprawdzenia. Nie ma jednak bezpośredniego dostępu do mojej wiedzy. To, że o czymś nie napisałem, nie oznacza, że o tym nie wiem.

Dlatego wolę odpowiedź „w opisie nie ma informacji o próbie odtworzenia danych” od odpowiedzi „nie rozumiesz kopii zapasowych”. Pierwsze zdanie wskazuje brak w materiale. Drugie przypisuje mi brak wiedzy bez wystarczającej podstawy.

Jak wygląda to w moich rozmowach

W dostępnych zapisach moich chatów można znaleźć podobny sposób pytania. Dwa przykłady pokazują, że używam go zarówno podczas nauki, jak i przy ocenie już przygotowanego materiału. Poniżej parafrazuję własne wiadomości, poprawiając pisownię i skracając kontekst.

Przy przeglądzie materiałów strony, 1 października 2026 roku, poprosiłem o sprawdzenie, czego jeszcze brakuje, co warto dodać i które fragmenty są zbyt ogólne. Doprecyzowałem, że tekst ma być praktyczny i możliwy do zastosowania.

To istotne dopowiedzenie. Sama prośba „co jeszcze dodać?” zachęca do rozbudowywania materiału. Kryterium praktyczności pozwala ocenić każdą propozycję: co czytelnik będzie umiał dzięki niej zrobić?

W rozmowie „Budowa roju agentów”, 3 października 2026 roku, pytałem, co muszę wiedzieć, jak robią to inni, czy istnieją gotowe biblioteki i czy takie rozwiązanie uruchamia się lokalnie, czy w chmurze. Chodziło o współpracę wielu agentów AI nad aplikacją.

W kolejnym pytaniu zawęziłem temat: podstawy orkiestracji, czyli organizowania pracy agentów, już chyba rozumiem; szukam sposobu na pracę równoległą. To ważna korekta. Pomaga oddzielić to, co chcę dopiero poznać, od tego, czego nie potrzebuję tłumaczyć od początku.

Te przykłady potwierdzają sposób zadawania pytań. Same nie dowodzą, że odpowiedzi były trafne ani że dzięki nim zadania zakończyły się lepszym wynikiem. Taki efekt trzeba ocenić osobno.

Trzy rzeczy, które łatwo pomylić

Pytanie „czego nie wiem?” miesza kilka różnych problemów. Warto je rozdzielić jeszcze przed odpowiedzią:

Jest jeszcze niewiedza samego modelu: brak dostępu do pliku, aktualnej dokumentacji czy stanu środowiska. Dobra odpowiedź również ją ujawnia. Jeśli AI nie widziało konfiguracji, nie powinno przedstawiać jej oceny jako wyniku audytu.

Nie musimy więc zaczynać od rozbudowanej analizy moich kompetencji. Często wystarczy ustalić, jakiej informacji brakuje do następnej decyzji.

Jak zbudować prompt, który ma szansę pomóc

Prompt to po prostu polecenie przekazane modelowi. W tej metodzie powinien łączyć cel, obecny stan, ograniczenia i sposób sprawdzenia odpowiedzi.

Zamiast samego „powiedz mi coś, czego nie wiem”, warto napisać:

Chcę osiągnąć: [konkretny rezultat].
Obecny stan: [co już działa i co zostało sprawdzone].
Znam lub rozumiem: [istotne elementy, których nie trzeba tłumaczyć od zera].
Nie jestem pewien: [otwarte pytania i założenia].
Ograniczenia: [czas, budżet, zakres, ustalone technologie].
Materiał do oceny: [opis, plan, dokument lub dostępny plik].

Wskaż do trzech istotnych rzeczy, których mogę nie uwzględniać,
a które mogą zmienić decyzję lub jakość wykonania tego zadania.
Nie dopisuj punktów tylko po to, żeby osiągnąć tę liczbę.

Dla każdej rzeczy podaj:
1. Co w dostarczonym materiale jest podstawą tej uwagi.
2. Czy to potwierdzony brak, hipoteza, czy pytanie o brakujący kontekst.
3. Jakie ma to znaczenie dla mojego celu.
4. Jak najprościej to sprawdzić.

Nie zakładaj, że czegoś nie wiem tylko dlatego, że o tym nie napisałem.
Jeśli nie masz danych do oceny, wskaż konkretny brak.
Nie rozszerzaj automatycznie zakresu projektu.
Jeśli znalazłeś istotną lukę, wskaż jedną rzecz wartą sprawdzenia
w pierwszej kolejności. Jeśli nie, powiedz to wprost.

To propozycja do wypróbowania, nie uniwersalna recepta. Po pierwszej odpowiedzi sprawdź, czy potrzebne były wszystkie instrukcje i czy zabrakło jakiejś informacji. Jeśli pytasz o małą rzecz, skróć prompt.

Znaczenie ma także dobór materiału wejściowego. Jasny opis celu i właściwy fragment dokumentu mogą być bardziej użyteczne niż ogromny zbiór luźnych notatek. Podobny kierunek — dobieranie informacji istotnych dla zadania — opisuje zespół Anthropic w materiale o przygotowywaniu kontekstu dla agentów AI. Nie wynika z tego, że każdy dłuższy prompt jest gorszy. Kontekst ma być wystarczający i związany z pytaniem.

Przykład: czego mogę nie uwzględniać w DevOps?

DevOps łączy tworzenie oprogramowania z jego dostarczaniem i utrzymaniem. Załóżmy, że przygotowujesz małą aplikację do pierwszego udostępnienia użytkownikom. Potrafisz uruchomić ją lokalnie i masz działającą wersję testową.

Poniższy scenariusz jest przykładem dydaktycznym. Nie jest rekonstrukcją mojej historycznej rozmowy o DevOps.

Ogólne pytanie „czego nie wiem o DevOps?” pozostawia modelowi bardzo szeroki wybór tematów. Możesz dostać listę technologii i praktyk bez związku z etapem projektu. Użyteczniej byłoby zapytać:

Przygotowuję pierwsze wdrożenie małej aplikacji internetowej z bazą danych.
Wersja testowa działa. Umiałem ją uruchomić, ale nie przeprowadzałem
jeszcze próby odtworzenia po awarii.
Cel: udostępnić aplikację pierwszym użytkownikom i wiedzieć,
jak postąpić, jeśli wdrożenie się nie powiedzie.

Jakie ważne zależności mogę pomijać na tym etapie?
Zacznij od brakujących informacji. Potem wskaż do trzech kwestii,
które warto sprawdzić przed wdrożeniem, wraz z uzasadnieniem.
Oddziel wymagania wynikające z mojego opisu od ogólnych sugestii.
Nie zakładaj potrzeby zmiany technologii ani rozbudowy infrastruktury.

Jednym z możliwych tropów byłoby odtwarzanie danych. Wtedy odpowiedź można ocenić według prostego układu:

To nadal nie jest gotowa instrukcja wykonania operacji. Konkretny test wymaga znajomości środowiska i uzgodnionego zakresu. Wartość odpowiedzi polega na wskazaniu pytania, którego wcześniej nie uwzględniliśmy.

Planowanie odtwarzania rzeczywiście obejmuje dopuszczalny czas przerwy i dopuszczalną utratę danych; znaczenie testowania planu opisuje oficjalny przewodnik Google Cloud. Źródło pomaga sprawdzić zasadność tropu. Nie potwierdza, że w konkretnym projekcie znaleziono usterkę.

Gdy chcę poprawić realizację, a nie poznawać całą dziedzinę

W środku zadania często przyda się znacznie krótsze polecenie:

Zanim przejdziemy dalej, sprawdź, jakiej jednej informacji brakuje nam do poprawnego wykonania następnego kroku. Jeśli wszystko potrzebne już mamy, powiedz to i kontynuuj w ustalonym zakresie.

Przed decyzją można zapytać:

Które założenie najbardziej wpływa na tę rekomendację? Co powinienem sprawdzić, aby przekonać się, czy jest prawdziwe? Jaki wynik sprawdzenia zmieniłby rekomendację?

A przy przeglądzie tekstu lub planu:

Sprawdź, czy jest pominięcie, przez które odbiorca może nie umieć zastosować tego materiału. Jeśli je znajdziesz, pokaż konkretne miejsce i zaproponuj najmniejsze potrzebne uzupełnienie. Jeśli uwaga jest tylko preferencją stylistyczną, nazwij ją tak. Jeśli nie widzisz istotnych pominięć, powiedz to wprost.

Każdy z tych promptów kieruje rozmowę ku określonemu wynikowi. Nie trzeba za każdym razem prosić o pełny audyt wszystkiego.

Odpowiedź też trzeba sprawdzić

Model może potwierdzać moje przekonania, nawet gdy powinien je zakwestionować. W badaniu opublikowanym przez Anthropic w 2023 roku zaobserwowano takie zachowanie w testowanych modelach: dopasowywanie odpowiedzi do poglądów użytkownika kosztem prawdziwości, określane jako sycophancy, czyli nadmierne przytakiwanie. To wynik konkretnego badania, nie pomiar jakości każdego dzisiejszego narzędzia ani moich rozmów.

Polecenie „bądź krytyczny” nie zapewnia jednak trafnej oceny. Można dostać także krytykę, która brzmi poważnie, ale nie ma oparcia w materiale.

Dlatego proponuję sprawdzać przede wszystkim konstrukcję odpowiedzi:

• Podstawa: czy model wskazał fragment, fakt lub brak informacji, z którego wyprowadza uwagę?
• Znaczenie: czy wyjaśnił wpływ na cel, zamiast tylko wymienić interesujący temat?
• Weryfikacja: czy wiadomo, jakie działanie, źródło lub wynik pozwoli ocenić trafność uwagi?
• Zakres: czy propozycja pasuje do obecnego etapu i ograniczeń?

To kryteria, które proponuję stosować przy tej metodzie. Nie są certyfikatem poprawności odpowiedzi. Przy ważnej decyzji potrzebne może być sprawdzenie dokumentacji, test albo konsultacja z osobą znającą dziedzinę.

Jeśli korzystasz z drugiego chatu do przeglądu, przekaż mu pytanie i materiał źródłowy. Poproś o własną ocenę, zanim pokażesz wnioski pierwszego modelu. Taki przegląd może dostarczyć innej perspektywy, ale dwa podobne werdykty nadal nie zastępują dowodu.

Kiedy kończę zadawanie kolejnych pytań

„Co jeszcze?” łatwo zamienić w niekończące się rozszerzanie zadania. Dlatego proponuję prostą granicę: po wskazaniu potencjalnych braków wybierz jeden, sprawdź go i dopiero na tej podstawie zdecyduj o zmianie.

Przykładowe domknięcie rozmowy:

Wybieram punkt dotyczący [konkretna luka].
Pomóż ustalić najmniejszy sposób jego sprawdzenia.
Po wyniku podsumuj:
- co się potwierdziło;
- co odrzuciliśmy;
- czy trzeba zmienić plan, a jeśli tak, to w którym miejscu.
Nie otwieraj nowych tematów bez wskazania ich związku z tym wynikiem.

Dobrze, jeśli rozmowa kończy się lepszym pytaniem, uzupełnionym opisem, poprawioną decyzją albo konkretnym testem. Może też zakończyć się wnioskiem, że nie znaleźliśmy podstaw do zmiany. Nie każda analiza musi powiększać listę zadań.

Pytanie „czego nie wiem?” ma dla mnie sens wtedy, gdy pomaga zobaczyć coś, co warto sprawdzić. Jego praktyczna wersja brzmi: „Czego mogę nie uwzględniać przy tym zadaniu, dlaczego ma to znaczenie i jak to zweryfikować?”