O czym jest ten film
- Opus 5 generuje tekst, który bywa gęsty od żargonu i męczący w odbiorze — problem zgłasza wielu użytkowników, nie tylko autor.
- Punktem odniesienia jest głośny wpis blogowy o tym, że czytanie outputu AI to dodatkowy wysiłek: rozwlekłość, „zbyt wiarygodne bzdury” i narastający żargon.
- Rozwiązanie rekomendowane przez osobę z zespołu Claude Code to output styles — style odpowiedzi.
- Funkcja istnieje od października poprzedniego roku, ale autor dopiero teraz zaczął jej realnie używać.
- Instrukcja krok po kroku: wklejenie stylu, dodanie go przez
@claude-code-guide, przełączenie w/config, cofnięcie rozmowy i powtórzenie promptu. - Wbudowane style:
explain like I'm 5,learning(każe użytkownikowi samemu napisać fragment kodu) orazexplanatory. - Zespół Claude Code każe nowym inżynierom włączać styl wyjaśniający przy pracy w nieznanym repozytorium.
- Metoda szukania własnego stylu:
/branchz mylącej rozmowy i poproszenie modelu o wygenerowanie kilku wariantów tej samej odpowiedzi. - Ciekawy trop: styl oparty o ASD-STE100, czyli standard uproszczonego angielskiego technicznego.
- Style zapisują się per projekt w
.claude/settings.local.json, więc każdy projekt może mieć własny poziom szczegółowości.
Redakcyjne tłumaczenie
Problem: output, którego nie da się czytać
Jednym z największych kłopotów, z jakimi ostatnio zderzacie się przy pracy z Opusem 5, jest to, że jego wypowiedzi bywają po prostu mylące. Przykład z mojej własnej rozmowy: dyskutowałem o pewnych pomysłach i model odpisał mi, że „korpus jest silnikiem, a ujęcia biorą się z tego, co już przyswoiłeś”. Przeczytałem sporo takiego tekstu i myślę sobie: co to w ogóle znaczy? Nie mam pojęcia. Człowiek ma wrażenie, że jego własny angielski osłabł albo że model mówi w innym języku.
Wiem, że nie jestem w tym odosobniony. Krąży dość świeży, viralowy wpis blogowy, którego autor pisze wprost: czytanie outputu AI to dodatkowy wysiłek. Jest rozwlekły, często zawiera aż nazbyt wiarygodnie brzmiące bzdury i staje się coraz bardziej naszpikowany żargonem. Autor pokazał odpowiedź, którą dostał od Claude’a — ja nawet nie próbowałbym jej czytać. Sam napisał, że musiał sprawdzać znaczenie każdego słowa, żeby to rozgryźć.
Rozwiązanie: style odpowiedzi
Rozwiązanie, które podpowiedziała osoba z zespołu Claude Code, to output styles — style odpowiedzi. Nagrałem o nich materiał w mojej szkole programowania agentowego jakieś osiem–dziewięć miesięcy temu, w październiku, kiedy funkcja się pojawiła. Ale potem właściwie z niej nie korzystałem. Kiedy dziś otwieram tamten materiał, widzę, że zaczynam go od zdania: to funkcja, której raczej nie używam, ale ona istnieje. Teraz sięgam po nią coraz częściej, bo pomaga obejść to, jak irytujący potrafi być Opus 5 w formułowaniu odpowiedzi.
Osoba z zespołu pisze, że lubi używać takiego stylu po długim dniu pracy — szczerze, potrafi bardzo pomóc. Wygląda też na to, że różni członkowie zespołu stosują różne style: inne do różnych projektów, inne do różnych zadań, a nawet inne o różnych porach dnia, zależnie od tego, jak bardzo są zmęczeni i jak głęboko chcą być zaangażowani w proces. To więc nie jest tak, że tworzysz jeden styl, ustawiasz go raz i temat zamknięty. Będziesz się między nimi przełączać.
Jak to skonfigurować krok po kroku
Gotowy tekst stylu znajdziecie w opisie pod filmem — można go po prostu skopiować. Następnie przechodzicie do Claude Code, oznaczacie przewodnik po Claude Code przez @claude-code-guide, wklejacie treść stylu i piszecie: dodaj mi ten styl odpowiedzi. Enter — i narzędzie to zrobi.
Kiedy skończy, wpisujecie /config w Claude Code, szukacie pozycji dotyczącej stylu odpowiedzi, przełączacie na explain like I’m 5 i wciskacie Escape. Potem wystarczy cofnąć rozmowę o jedną wiadomość i wpisać ten sam prompt jeszcze raz. Po ponownym wysłaniu tego samego zapytania — już w stylu „wytłumacz jak pięciolatkowi” — odpowiedź była o wiele bardziej zrozumiała.
(Informacja dodatkowa: w transkrypcie automatycznym nazwa stylu bywa zniekształcana — chodzi o styl „explain like I’m 5”, czyli wyjaśnianie na poziomie pięciolatka.)
Pozostałe wbudowane style
Zauważycie, że dostępnych stylów jest więcej. Jest styl uczący (learning), w którym model poprosi was, żebyście część kodu napisali samodzielnie. Jest też styl wyjaśniający (explanatory), który — jak wiem — lubi zespół Claude Code; wspominali o tym w wywiadzie, mówiąc, że każą go włączać nowym pracownikom pracującym w zupełnie nieznanym repozytorium.
Cytat z tego wywiadu brzmiał mniej więcej tak: „Kiedy do zespołu dołącza nowy inżynier, każemy mu włączyć styl wyjaśniający. To po prostu /config output style = explanatory — uruchamiacie to w Claude Code albo prosicie Claude’a, żeby ustawił to za was. Efekt jest taki, że za każdym razem, gdy Claude wprowadza zmianę, tłumaczy: o, tak działa ta architektura, tak działa ten język, jeśli wcześniej z niego nie korzystałeś, a tak działa ta część bazy kodu. Wyjaśnia po to, żebyś się uczył.”
Jak znaleźć własny styl
To oczywiście nie jest rozwiązanie uniwersalne. Warto poeksperymentować i znaleźć coś dopasowanego do siebie. Jedna z metod: kiedy trafiacie na wyjątkowo mylącą albo irytującą odpowiedź — jak ta w mojej rozmowie — wpisujecie /branch. Rozmowa rozgałęzia się wtedy z bieżącego punktu na nowe wątki. Do takiego wątku wklejam istniejący styl odpowiedzi i proszę: wygeneruj mi pięć innych stylów oraz pokaż, jak w każdym z nich wyglądałaby poprzednia odpowiedź.
Celem jest znalezienie sposobu komunikacji, który rozumiem. W wynikach widzę różne warianty. Jest tryb dziecięcy, z którego nie skorzystam — jest zdecydowanie zbyt uproszczony. Jest wariant „Slack DM”, który wygląda lepiej, ale gdy go czytam, nadal jest dla mnie dość mętny.
Jeśli nic z tego nie pasuje, można poprosić o styl oparty na ASD-STE100 — standardzie uproszczonego angielskiego technicznego. Kiedy cofam rozmowę i mówię: dobrze, wyjaśnij to w takim stylu — dostaję odpowiedź zdecydowanie lepszą. Można ją jeszcze doszlifować.
(Informacja dodatkowa: ASD-STE100 to Simplified Technical English — standard opracowany dla dokumentacji lotniczej, ograniczający słownictwo i narzucający prostą składnię, żeby teksty techniczne były jednoznaczne także dla osób nieanglojęzycznych.)
Gdybym zrobił z tego nowy styl odpowiedzi, mógłbym z czasem stwierdzić, że chcę go jednak nieco bardziej technicznego. Czytając taką odpowiedź, myślę sobie: świetnie, to jest znacznie lepsze, chcę to zamienić w styl. Oznaczam przewodnik po Claude Code i mówię: zamień to w styl odpowiedzi. A jeśli po czasie zauważę, że tekst robi się dla mnie zbyt techniczny, mogę odpowiednio podkręcić albo obniżyć poziom stylu.
Style per projekt
Jedną z przyjemnych wbudowanych właściwości Claude Code jest to, że style odpowiedzi zapamiętują się osobno dla każdego projektu. W projekcie „agent stack” wchodzę do settings.local.json w folderze .claude i widzę tam ustawiony styl explain like I’m 5. Jeśli teraz w innym projekcie ustawię styl oparty na STE100, czyli na uproszczonym angielskim technicznym, to styl poprzedniego projektu pozostanie nietknięty, a ten nowy zmieni się na STE100. To bardzo dobre rozwiązanie, bo pozwala mieć różne style dla różnych projektów.
Sam zamierzam korzystać z tego właśnie w ten sposób. Na przykład ostatnio pracuję nad nowym projektem — budową naprawdę dobrych piaskownic dla agentów. Mogę więc wpisać /config i ustawić tam styl wyjaśniający, żeby lepiej zrozumieć temat piaskownic agentowych. A w projektach, które znam bardzo dobrze, mogę ustawić styl o wiele bardziej zwięzły.
Podsumowanie
Zachęcam do eksperymentowania, bo sądzę, że to coś, co w przyszłości będziemy musieli robić coraz częściej — modele stają się w swoich domyślnych odpowiedziach trochę bardziej zagmatwane.
Jeśli lubicie takie materiały, zasubskrybujcie kanał. A jeśli chcecie regularnie dostawać ode mnie wskazówki, sprawdźcie mój newsletter — link pod filmem. Zapisując się, dostaniecie też dostęp do kilku darmowych materiałów z mojej szkoły programowania agentowego. Możecie też odpowiadać na każde wydanie newslettera — postaram się odpisywać, bo naprawdę lubię takie wiadomości od czytelników.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nieczytelny output to problem konfiguracji, nie twojego rozumienia
Na czym polega: Poczucie „to chyba ja nie nadążam” przy gęstych, żargonowych odpowiedziach Opusa 5 jest powszechne — opisał je viralowy wpis blogowy i potwierdza zespół Claude Code.
Jak stosować: Zanim zaczniesz walczyć z promptem, sprawdź, czy problemem nie jest po prostu domyślny styl wypowiedzi modelu. To zmienna, którą możesz ustawić raz i mieć spokój.
Na co uważać: Styl nie naprawia błędów merytorycznych. „Zbyt wiarygodnie brzmiące bzdury” po uproszczeniu języka stają się tylko łatwiejsze do przeczytania — nie bardziej prawdziwe.
2.Output styles to najprostsze narzędzie do ujarzmienia formy odpowiedzi
Na czym polega: Funkcja istnieje w Claude Code od października poprzedniego roku, ale wielu użytkowników — łącznie z autorem — nigdy z niej realnie nie skorzystało.
Jak stosować: Wejdź w /config, znajdź pozycję dotyczącą stylu odpowiedzi i przełącz ją. To pojedyncza zmiana ustawienia, nie przebudowa workflow.
Na co uważać: Nie traktuj tego jako jednorazowej decyzji — sens tej funkcji polega na przełączaniu.
3.Procedura testowa: cofnij rozmowę i powtórz ten sam prompt
Na czym polega: Autor pokazuje, że po zmianie stylu można cofnąć się o jedną wiadomość i wysłać dokładnie to samo zapytanie ponownie.
Jak stosować: To najuczciwsze porównanie — identyczny prompt, identyczny kontekst, różny tylko styl. Dzięki temu ocenisz efekt stylu, a nie przypadkową zmienność modelu.
Na co uważać: Porównuj na treściach, które faktycznie sprawiały ci trudność. Na prostym pytaniu każdy styl wygląda dobrze.
4.Styl wyjaśniający przy wchodzeniu w nowe repozytorium
Na czym polega: Zespół Claude Code każe nowym inżynierom włączać styl wyjaśniający — model przy każdej zmianie tłumaczy architekturę, specyfikę języka i działanie danej części bazy kodu.
Jak stosować: Włączaj go, gdy dołączasz do nieznanego projektu albo pracujesz w technologii, której nie znasz. To praktyka wewnętrzna zespołu, nie teoria.
Na co uważać: W projekcie, który znasz na pamięć, ten sam styl to czysty szum — wtedy przełącz się na coś zwięzłego.
5.Styl uczący, gdy chcesz naprawdę zrozumieć kod
Na czym polega: Tryb learning nie tylko wyjaśnia, ale prosi cię o samodzielne napisanie fragmentu kodu.
Jak stosować: Sięgaj po niego, kiedy celem jest twoja kompetencja, a nie sam dowieziony efekt — nauka nowego frameworka, onboarding, zmiana stosu technologicznego.
Na co uważać: To styl kosztowny czasowo. Przy terminie na jutro spowolni cię zamiast pomóc.
6./branch jako laboratorium do szukania własnego stylu
Na czym polega: Z mylącej rozmowy autor rozgałęzia wątek komendą /branch, wkleja obecny styl i prosi o wygenerowanie pięciu alternatyw wraz z przepisaną w każdej z nich poprzednią odpowiedzią.
Jak stosować: Testuj warianty na tej samej, konkretnej odpowiedzi, która cię zirytowała. Widzisz wtedy porównanie „ten sam sens, pięć form” i wybierasz to, co rozumiesz.
Na co uważać: Model chętnie wygeneruje style skrajne — od dziecięcych po czatowe. Autor odrzucił oba: jeden był zbyt prymitywny, drugi wciąż niejasny.
7.ASD-STE100 jako punkt zaczepienia dla stylu technicznego
Na czym polega: Kiedy gotowe warianty nie działały, autor poprosił o styl oparty na standardzie uproszczonego angielskiego technicznego — i dostał wyraźnie lepszy rezultat.
Jak stosować: Odwołanie do istniejącego, nazwanego standardu daje modelowi twarde ramy zamiast miękkiego „pisz prościej”. Ten trik działa też z innymi znanymi standardami redakcyjnymi.
Na co uważać: STE jest z natury oszczędne — jeśli potrzebujesz precyzji technicznej, licz się z koniecznością podniesienia poziomu stylu.
8.Traktuj styl jako parametr do strojenia, nie jako gotowy preset
Na czym polega: Autor zapowiada, że z czasem może stwierdzić, iż styl jest zbyt techniczny lub zbyt uproszczony, i odpowiednio go przesunie.
Jak stosować: Kiedy trafisz na odpowiedź, której forma ci odpowiada, oznacz @claude-code-guide i poproś o zamienienie jej w styl odpowiedzi. Tak budujesz styl z realnego przykładu, a nie z abstrakcyjnego opisu.
Na co uważać: Nie mnóż stylów bez potrzeby — kilka dobrze dobranych, między którymi realnie się przełączasz, jest użyteczniejsze niż dwadzieścia zapomnianych.
9.Styl zapisuje się per projekt
Na czym polega: Ustawienie trafia do .claude/settings.local.json w danym projekcie; zmiana w jednym repozytorium nie rusza pozostałych.
Jak stosować: Nowy albo nieznany projekt — styl wyjaśniający. Projekt, który znasz od podszewki — styl maksymalnie zwięzły. Autor stosuje dokładnie ten podział, pracując nad piaskownicami dla agentów.
Na co uważać: Skoro ustawienie jest lokalne dla projektu, łatwo zapomnieć, w jakim trybie jesteś. Jeśli odpowiedzi nagle wyglądają dziwnie, sprawdź /config, zanim zaczniesz zmieniać prompt.
10.Dobieraj styl do stanu, w jakim jesteś
Na czym polega: Członkowie zespołu Claude Code zmieniają styl zależnie od projektu, zadania, a nawet pory dnia i poziomu zmęczenia.
Jak stosować: Pod koniec długiego dnia przełącz się na styl maksymalnie prosty. To nie jest oznaka słabości, tylko dopasowanie narzędzia do dostępnej uwagi.
Na co uważać: Autor przewiduje, że domyślne odpowiedzi modeli będą coraz bardziej zagmatwane — więc traktuj to jako nawyk do wyrobienia, a nie jednorazową poprawkę.