O czym jest ten film
- Stanford opracował metodę badawczą o nazwie STORM, która w testach recenzowanych naukowo generowała artykuły o 25% lepiej zorganizowane niż następna najlepsza metoda.
- Autor przełożył zasady STORM na własny „skill” (umiejętność) dla Claude’a, który udostępnia za darmo.
- Skill tworzy zweryfikowany, samodzielny raport HTML łączący perspektywy pięciu „agentów”: praktyka, akademika, sceptyka, ekonomisty i historyka.
- Każda perspektywa wychwytuje luki, których nie widzą pozostałe — to sedno przewagi metody nad pojedynczym promptem.
- Proces obejmuje cztery etapy: uruchomienie pięciu perspektyw, zmapowanie sprzeczności między nimi, syntezę w jeden raport oraz adwersarialną recenzję i weryfikację źródeł.
- Autor porównuje STORM z natywną funkcją Claude Code „deep research” (uruchamiającą nawet ponad 100 agentów) i pokazuje, że raport STORM wypadł lepiej w ocenie modelu Codex pod względem jakości dowodów, różnorodności źródeł, tezy, praktyczności, kontroli ryzyka i przydatności do tworzenia treści — a przy tym był szybszy i tańszy.
- Raport końcowy rankinguje ustalenia według wiarygodności i wskazuje, które perspektywy je potwierdzają, a które kwestionują.
- Skill potrafi też wskazać „brakującą szóstą perspektywę” (np. klienta lub pracownika pierwszej linii), której nie uwzględniono.
- Autor wyjaśnia różnicę między subagentami (komunikującymi się tylko z sesją główną) a zespołami agentów (które mogą się ze sobą komunikować i debatować, ale są droższe).
- Skill oraz szablon raportu HTML są dostępne za darmo w społeczności Skool autora, działają z Claude Code (folder
.claude) i innymi agentami kodującymi (np. Codex).
Redakcyjne tłumaczenie
Czym jest metoda STORM i dlaczego warto ją znać
Stanford opracował metodę badawczą o nazwie STORM, która w recenzowanych naukowo testach wykazała zdolność tworzenia artykułów o 25% lepiej zorganizowanych niż następna najlepsza metoda. Autor przeniósł zasady STORM do własnego skilla (umiejętności) dla Claude’a, który udostępnia całkowicie za darmo. Efektem działania tego skilla jest briefing w formacie HTML, przygotowany przez pięć różnych perspektyw agentów, a następnie zweryfikowany. Na samym dole takiego raportu widać, że poszczególne perspektywy analizują różne fragmenty całości, a wskazane tam źródła zostały albo potwierdzone, albo skorygowane, albo zdegradowane (czyli uznane za mniej wiarygodne). Oznacza to, że w pierwszej wersji briefing zawierał informacje, które nie były do końca poprawne — ale ponieważ skill ma wbudowany mechanizm weryfikacji, druga wersja (V2) raportu jest już dużo bardziej wiarygodna.
Idea stojąca za STORM polega na tym, by zamiast wysyłać jeden prompt i otrzymywać jeden kąt spojrzenia na temat, wykorzystać wiele różnych perspektyw jednocześnie. Pojedynczy prompt wysłany do Claude’a zawsze będzie generował plan badawczy z licznymi „ślepymi punktami”. STORM wykorzystuje pięć takich perspektyw: praktyka, akademika, sceptyka, ekonomistę i historyka. Każda z nich znajduje lukę, której pozostałe nie dostrzegają. Pomysł, by różni agenci odgrywali swoje własne „role” — z odrębnymi osobowościami, doświadczeniem i obszarami eksperckimi — okazuje się bardzo skuteczny. (Informacja dodatkowa: autor odwołuje się tu do innych swoich materiałów na temat tzw. „roast skill” oraz wykorzystywania zespołów agentów jako swoistej „rady”, której zadaniem jest identyfikowanie różnych punktów widzenia.)
Porównanie z natywną funkcją „deep research” w Claude Code
Aby pokazać, dlaczego takie podejście jest wartościowe, autor porównał STORM z natywną funkcją Claude Code o nazwie „deep research”, która pojawiła się wraz z tzw. dynamic workflows. Po wpisaniu komendy deep research i podaniu tematu badawczego, system uruchamia dynamiczny przepływ pracy, który w tle odpala nawet setki agentów — w omawianym przykładzie było ich 103. Funkcja ta dostarcza solidny raport typu „deep research”, jednak nie wyświetla od razu żadnego wyniku — cała praca zostaje „zinternalizowana”. Dopiero po dopytaniu „gdzie jest raport?” system zwrócił plik markdown, który okazał się przyzwoity, ale niezbyt dogłębny — ze stosunkowo niewieloma potwierdzonymi źródłami (tylko dwa), kilkoma niepotwierdzonymi na dole oraz listą otwartych pytań.
Następnie autor wziął dokładnie ten sam prompt, który wykorzystał w deep research, i wprowadził go do skilla STORM, mówiąc po prostu: „Hej, zrób badanie metodą Storm na ten temat”. Skill odpowiedział, że rozumie temat i uruchamia pipeline STORM. Najpierw odpaliło się pięć agentów — praktyk, akademik, sceptyk, ekonomista i historyk — których wnioski zostały następnie zestawione ze sobą, z wyraźnym wskazaniem punktów rozbieżności. Potem uruchomiono kolejnych sześć agentów, których zadaniem była weryfikacja wszystkich znalezionych wcześniej faktów.
Po zakończeniu weryfikacji powstaje raport HTML, który za każdym razem wygląda tak samo: zawiera 60-sekundowe podsumowanie oraz kluczowe ustalenia. Wszystkie te ustalenia są dodatkowo uszeregowane według wiarygodności — przykładowo jedno z nich oznaczono jako „wysoka wiarygodność, 9/10”, ponieważ poparli je akademik i sceptyk, a zakwestionowali praktyk i ekonomista. Cały raport utrzymuje ten format do samego końca. Wskazuje też, na jakim założeniu opiera się briefing, oraz jaka perspektywa została pominięta — w tym przypadku wszystkie pięć „soczewek” patrzyło na firmę z perspektywy właściciela: wskaźniki adopcji, produktywność, zwrot z inwestycji (ROI). Żadna nie spojrzała z perspektywy klienta ani pracownika pierwszej linii. To właśnie ta brakująca, szósta perspektywa — i autor mógłby teraz po prostu zlecić jej dodanie oraz wygenerowanie wersji trzeciej (V3) raportu. Dzięki temu raport dostarcza też bardzo praktyczne wnioski.
Kluczowa różnica względem deep research polega na tym, że ta funkcja daje w zasadzie „zrzut mózgu” w postaci stosu znalezionych statystyk, podczas gdy badanie metodą STORM można naprawdę dopasować do siebie — wystarczy w skillu opisać swój biznes i cele, a każdy raz, kiedy uruchamiany jest raport STORM, będzie on dostosowany do tego kontekstu i wskazywał, co faktycznie warto zrobić inaczej w świetle nowych danych.
Autor postanowił też sprawdzić oba raporty w innym modelu — wprowadził je do Codexa i zapytał, który z nich jest lepszy. Codex ocenił, że lepszy jest briefing HTML ze STORM: ma lepszą jakość dowodów, większą różnorodność źródeł, mocniejszą tezę, jest bardziej praktyczny, ma lepszą kontrolę ryzyka i lepiej nadaje się do wykorzystania w wideo i treściach. We wszystkich sześciu ocenianych kategoriach Codex uznał briefing STORM za lepszy. Choć autor nie zna dokładnych kosztów, badanie STORM było szybsze i wyraźnie tańsze — w tym przypadku uruchomiono w sumie około 12 agentów, podczas gdy deep research odpalił ponad 100. Trzeba jednak zaznaczyć, że ten konkretny przebieg deep research został spowolniony przez limity zapytań API (rate limits) — co samo w sobie jest kolejnym argumentem: uruchamiając naraz tak wiele agentów, łatwo natrafić na takie ograniczenia. W przypadku STORM zawsze pracuje pięć ustalonych person, więc problem ten nie występuje.
Jak działa skill krok po kroku
Cały mechanizm sprowadza się do czterech promptów. Pierwszy uruchamia pięć różnych perspektyw — tu wystarczy podać temat badawczy. Gdy te odpowiedzi wrócą, wykonywany jest drugi prompt, czyli „mapa sprzeczności” — system sprawdza, gdzie poszczególne perspektywy się ze sobą nie zgadzają, która ma mocniejsze dowody, a która słabsze, i każe im wzajemnie analizować swoje wnioski. Trzeci krok to synteza, a czwarty — recenzja koleżeńska (peer review). Innymi słowy, są to cztery prompty połączone w łańcuch, prowadzące przez syntezę aż do recenzji.
Autor przetestował ten proces ręcznie, uznał że działa świetnie, i poprosił Claude’a, by zapakował całość w skill — tak, by wystarczyło podać temat, a system wykonywał całą sekwencję samodzielnie, za każdym razem zwracając spójny szablon raportu HTML.
W praktyce wygląda to tak: w folderze .claude znajduje się wiele skilli, w tym skill „storm research”. Plik skill.md opisuje go następująco: STORM research zamienia jeden temat w zweryfikowany, wieloperspektywiczny briefing HTML. Symuluje pięć eksperckich „soczewek” patrzących na temat, mapuje miejsca, w których się one ze sobą nie zgadzają, syntetyzuje wszystko w jeden samodzielny raport HTML, następnie poddaje własne wnioski adwersarialnej recenzji koleżeńskiej i weryfikuje każdy cytat względem jego źródła pierwotnego, zanim dostarczy końcowy wynik.
W skillu znajduje się też szablon raportu HTML (report template), który autor również udostępnia za darmo. Jest on przywoływany przez sam skill z instrukcją: gdy już znajdziesz wszystkie informacje, umieść je w HTML i zadbaj, by zawsze wyglądały tak samo. To zapewnia spójność wizualną wyników.
Obie te rzeczy — plik markdown ze skillem i szablon HTML — są dostępne za darmo w społeczności autora na platformie Skool (link w opisie filmu). Wystarczy wejść do sekcji „classroom”, kliknąć „all YouTube resources” i znaleźć tam każdy film wraz z powiązanymi materiałami.
Instalacja i uruchomienie
Po pobraniu plików wystarczy przekazać markdown oraz plik HTML Claude’owi i powiedzieć: „Hej, Claude, to jest skill o nazwie storm research, umieść go w folderze .claude” — i to wszystko, konfiguracja jest gotowa. Dla osób, które nie wiedzą, czym jest „skill” — to w gruncie rzeczy rozbudowany prompt, swoisty „master prompt”, który za każdym razem, gdy użytkownik mówi „Hej, Claude, zrób dla mnie storm research”, zostaje wywołany, w całości odczytany i uruchomiony. Po jednorazowej instalacji cały proces działa praktycznie bezobsługowo.
Skill działa również z Codexem i innymi agentami kodującymi — różnica polega tylko na tym, że w przypadku Claude’a musi on znajdować się w folderze .claude, natomiast dla innych narzędzi istnieją analogiczne foldery, np. .codex czy .agents, w których można umieszczać skille dedykowane danemu agentowi. (Informacja dodatkowa: niniejszy materiał stanowi w praktyce samouczek dotyczący Claude Code.)
Sam proces przebiega w kilku fazach. Faza zero to dookreślenie tematu — jeśli podany temat nie jest wystarczająco precyzyjny, skill może zadać kilka dodatkowych pytań, zanim uruchomi pełen proces STORM. Następnie uruchamiane jest równolegle pięć eksperckich „soczewek”, po czym następuje mapowanie sprzeczności, synteza raportu oraz adwersarialna recenzja i weryfikacja — i to właśnie na tym etapie powstaje finalny wynik.
Demonstracja na żywo
Autor otworzył aplikację desktopową Claude i rozpoczął nową sesję poleceniem: „Hej, Claude, uruchom dla mnie storm research na temat agentów głosowych AI”. Co istotne, nie użył komendy ze slashem (/) — mimo to skill i tak został wywołany. Ponieważ temat nie był bardzo precyzyjny, system mógł dopytać o doprecyzowanie. Rzeczywiście, pojawił się komunikat: „Uruchamiam skill storm research”, wraz z informacją, że obecnie rozpoznanym argumentem są „agenci głosowi AI”. System odpowiedział, definiując temat oraz odbiorcę raportu — rozpoznał, że autor jest edukatorem AI rozważającym, czy temat agentów głosowych jest wart osobnego filmu, czy to tylko chwilowy szum medialny (hype).
Pipeline zaczął działać — po jego rozwinięciu widać uruchamianie pięciu agentów: praktyka, akademika, sceptyka i pozostałych. Można było kliknąć w każdego z nich i zobaczyć, czym się zajmuje. Przykładowo, po kliknięciu w „ekonomistę” widoczny był dokładny prompt, jaki sesja główna wysłała do tego subagenta, a poniżej — że subagent przegląda internet, korzysta z narzędzi i prowadzi badania. To samo dotyczyło „akademika” — widoczny był jego prompt oraz bieżące działania.
Subagenci a zespoły agentów
W trakcie oczekiwania na wyniki autor wyjaśnił różnicę między subagentami a zespołami agentów (agent teams). W modelu subagentów istnieje jedna sesja główna — to z nią rozmawia użytkownik. Wszystkie podrzędne agenty pracują dla tej sesji głównej: sesja główna komunikuje się z każdym z pięciu agentów, ale agenci ci nie komunikują się ze sobą nawzajem. To istotna różnica względem zespołów agentów (agent teams), w których można uruchomić całe „rady” agentów, mogące rozmawiać nie tylko z sesją główną, ale też między sobą. Autor lubi wykorzystywać zespoły agentów wtedy, gdy potrzebuje pomocy w podjęciu decyzji co do jakiejś koncepcji lub tematu — wówczas każe im nie tylko prowadzić badania, ale i debatować ze sobą, dosłownie się ze sobą spierać, aż osiągną pewien konsensus. Zespoły agentów są jednak znacznie droższe niż subagenci, co stanowi ważne rozróżnienie. (Informacja dodatkowa: autor zapowiada osobne materiały poświęcone zespołom agentów i odsyła do swoich wcześniejszych filmów na temat subagentów oraz agent teams.)
Wszystkie pięć subagentów w tym przykładzie działało na modelu Opus 4.8 — choć nie jest to konieczne, można je równie dobrze uruchomić na modelach Haiku lub Sonnet. Autor po prostu wolał w tym przypadku skorzystać z Opusa. Po zebraniu wszystkich pięciu perspektyw system przeszedł do analizy sprzeczności, odczytując plik szablonu raportu, uruchamiając kolejne agenty w tle, a następnie weryfikując cytaty, statystyki i inne dane wypracowane przez wcześniejsze agenty.
Autor zaznaczył też, że w tym materiale przełączał się między aplikacją desktopową Claude a edytorem VS Code — na co dzień zwykle pracuje w VS Code, a Claude działa identycznie w obu środowiskach, różniąc się jedynie interfejsem. Tym razem część materiału pokazano w aplikacji desktopowej, ponieważ łatwiej w niej zobaczyć działające agenty.
Wynik końcowy
Gdy raport był gotowy, autor otworzył go w przeglądarce — to wersja V2, czyli już w pełni zweryfikowana. Po przewinięciu na sam dół widać, że źródła zostały odpowiednio zdegradowane, skorygowane lub potwierdzone. Raport zawiera 60-sekundowe podsumowanie oraz kluczowe ustalenia, ponownie uszeregowane według wiarygodności.
Rekomendacje końcowe
Autor zaleca, by widzowie pobrali skill, zainstalowali go we własnym Claude i poeksperymentowali z nim — dostosowali go bardziej do swoich potrzeb, ewentualnie zmodyfikowali wygląd raportu HTML. Warto przetestować go na temacie, który dobrze się zna i który jest istotny dla własnego biznesu, a następnie przeanalizować wynik pod kątem tego, co warto poprawić lub zmienić. Można też rozważyć dodanie szóstej czy nawet siódmej perspektywy — sam autor zastanawia się, czy w jego przypadku warto byłoby dodać perspektywę „początkującego w AI” (ponieważ uczy głównie osoby na starcie z tą technologią) albo perspektywę twórcy treści (content creatora).
Najważniejszy wniosek z materiału nie dotyczy jednak samego skilla STORM ani twierdzenia, że metoda Stanford jest najlepsza dla każdego — chodzi raczej o leżącą u jej podstaw zasadę: im więcej perspektyw prowadzi badania i wzajemnie się ze sobą konfrontuje, tym pełniejsze i bardziej holistyczne są efekty tych badań. Jeśli nie dysponuje się wiedzą ekspercką w danej dziedzinie, warto sprawdzić, czy można ją w jakiś sposób „pożyczyć” — zlikwidować własne ślepe punkty, znaleźć luki we własnej wiedzy i wykorzystać agentów do stworzenia małych „ekspertów” pokrywających różne obszary, tak by mieć przy sobie całą radę agentów o różnej wiedzy i kompetencjach, niezależnie od tego, czym aktualnie się zajmujemy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Metoda STORM ze Stanfordu jako podstawa lepszego researchu AI
Na czym polega: STORM to recenzowana naukowo metoda badawcza, która w testach generowała artykuły o 25% lepiej zorganizowane niż konkurencyjne podejścia, dzięki łączeniu wielu perspektyw badawczych zamiast jednego punktu widzenia.
Jak stosować: Jeśli potrzebujesz pogłębionego, wyważonego researchu na ważny dla firmy temat, warto sięgnąć po narzędzie zbudowane na zasadach STORM zamiast pojedynczego promptu do modelu AI.
Na co uważać: Sama metoda nie gwarantuje automatycznie poprawności — kluczowa jest następująca po niej faza weryfikacji źródeł.
2.Pięć perspektyw eliminuje ślepe punkty pojedynczego promptu
Na czym polega: Skill uruchamia pięciu „agentów” o odrębnych rolach — praktyka, akademika, sceptyka, ekonomistę i historyka — z których każdy dostrzega inne aspekty i luki w temacie.
Jak stosować: Przy badaniu złożonych tematów biznesowych warto świadomie zaprojektować różne „role” analityczne (np. zwolennika, krytyka, eksperta technicznego, użytkownika końcowego), by wymusić wielostronne spojrzenie.
Na co uważać: Więcej perspektyw oznacza więcej kosztów obliczeniowych i czasu — warto dobierać liczbę „lens” do wagi decyzji.
3.Mapowanie sprzeczności jako etap kontroli jakości
Na czym polega: Po zebraniu odpowiedzi od pięciu perspektyw system tworzy „mapę sprzeczności”, wskazując, gdzie się one nie zgadzają i która strona ma mocniejsze dowody.
Jak stosować: W każdym procesie syntezy wielu źródeł warto jawnie wypisać punkty rozbieżności zamiast je uśredniać czy pomijać — to ujawnia obszary niepewności.
Na co uważać: Sprzeczności nie zawsze da się jednoznacznie rozstrzygnąć — raport powinien jasno komunikować poziom pewności, a nie sztucznie wybierać „zwycięzcę”.
4.Adwersarialna recenzja i weryfikacja cytatów podnosi wiarygodność
Na czym polega: Po syntezie raportu system poddaje własne wnioski krytycznej recenzji i weryfikuje każdy cytat względem jego pierwotnego źródła, oznaczając informacje jako potwierdzone, skorygowane lub zdegradowane.
Jak stosować: Przy generowaniu raportów AI do celów biznesowych warto wymagać takiego etapu weryfikacji jako standardu, zamiast ufać pierwszej wersji wyniku.
Na co uważać: Weryfikacja nie eliminuje ryzyka błędu całkowicie — to dodatkowa warstwa kontroli, a nie gwarancja stuprocentowej poprawności.
5.STORM kontra natywny „deep research” w Claude Code
Na czym polega: W bezpośrednim porównaniu raport wygenerowany metodą STORM (ok. 12 agentów) został oceniony przez model Codex jako lepszy pod każdym z sześciu kryteriów niż raport z natywnej funkcji deep research (ponad 100 agentów), a przy tym był szybszy i tańszy.
Jak stosować: Zanim odpalisz funkcję uruchamiającą setki agentów naraz, rozważ, czy mniejszy, ustrukturyzowany zestaw kilku ról nie da lepszego i tańszego rezultatu.
Na co uważać: To porównanie pochodzi z jednego przykładu ocenianego przez inny model AI (Codex) — nie jest to niezależny, powtarzalny benchmark, więc warto traktować je jako wskazówkę, a nie ostateczny dowód.
6.Duża liczba równoległych agentów może trafić na limity API
Na czym polega: Uruchomienie ponad 100 agentów naraz (jak w przypadku deep research) może skutkować trafieniem na rate limity API, spowalniając lub zakłócając proces.
Jak stosować: Projektując własne pipeline’y z wieloma agentami, warto ograniczać ich liczbę do niezbędnego minimum (np. stałych pięciu-sześciu ról) zamiast skalować w nieskończoność.
Na co uważać: Limity te zależą od dostawcy API i mogą się zmieniać — warto monitorować koszty i ograniczenia konta przed uruchomieniem dużych przebiegów.
7.Personalizacja skilla pod konkretny biznes zwiększa trafność wniosków
Na czym polega: Skill STORM można dostosować, opisując w nim własny biznes, cele i kontekst, dzięki czemu każdy wygenerowany raport zawiera rekomendacje dopasowane do konkretnej sytuacji, a nie ogólny „zrzut” danych.
Jak stosować: Przed pierwszym użyciem warto poświęcić czas na opisanie w skillu profilu firmy i celów, by uzyskiwać bardziej praktyczne, actionable wnioski.
Na co uważać: Zbyt wąsko zdefiniowany kontekst może ograniczyć obiektywność analizy — warto zachować równowagę między personalizacją a bezstronnością.
8.Subagenci vs. zespoły agentów — różne narzędzia do różnych zadań
Na czym polega: Subagenci komunikują się wyłącznie z sesją główną i nie rozmawiają między sobą, podczas gdy zespoły agentów (agent teams) mogą debatować ze sobą nawzajem aż do osiągnięcia konsensusu — kosztem znacznie wyższych wydatków.
Jak stosować: Do uporządkowanego, jednorazowego researchu (jak STORM) wystarczą subagenci; do podejmowania trudnych decyzji wymagających dyskusji i kontrargumentów lepiej sprawdzą się zespoły agentów.
Na co uważać: Zespoły agentów generują wyraźnie wyższe koszty — warto je rezerwować na sytuacje, w których realnie potrzebna jest „debata”, a nie stosować ich rutynowo.
9.Raport wskazuje także brakujące perspektywy
Na czym polega: System potrafi sam zidentyfikować, że pewna istotna perspektywa (np. klienta czy pracownika pierwszej linii) nie została uwzględniona w pierwotnych pięciu „soczewkach”, i zasygnalizować to jako lukę.
Jak stosować: Po otrzymaniu raportu warto świadomie sprawdzić sekcję dotyczącą założeń i brakujących perspektyw, a w razie potrzeby zlecić dodatkową rundę analizy z nową rolą.
Na co uważać: System wskaże tylko te luki, które sam jest w stanie rozpoznać — ostateczna odpowiedzialność za kompletność analizy nadal spoczywa na użytkowniku.
10.Skill jest darmowy, przenośny między agentami i łatwy do zainstalowania
Na czym polega: Skill STORM (plik markdown) wraz z szablonem raportu HTML są darmowo dostępne w społeczności autora i działają nie tylko w Claude Code (folder .claude), ale też w innych agentach, takich jak Codex (foldery .codex lub .agents).
Jak stosować: Instalacja sprowadza się do przekazania plików odpowiedniemu agentowi i umieszczenia ich we właściwym folderze konfiguracyjnym — od tego momentu wystarczy jedno polecenie tekstowe, by uruchomić cały pipeline.
Na co uważać: Skill działa w obrębie konkretnego ekosystemu danego agenta kodującego (np. struktury folderów Claude Code) — przy przenoszeniu do innego narzędzia może wymagać drobnych dostosowań.