Jak przygotować projekty na Opusa 5.5Jak przygotować projekty na Opusa 5.5

Opus 5.5 już jest. Za token wychodzi o 20% taniej niż Opus 5: 4 dolary za milion tokenów wejściowych zamiast 5 i 20 zamiast 25 za wyjściowe. Anthropic twierdzi też, że lepiej radzi sobie z długimi sesjami kodowania w prawdziwym repozytorium i z pracą analityczną, a przy tym często zużywa mniej tokenów.

Najprościej byłoby podmienić nazwę modelu i wrócić do swoich spraw. Jeśli wołasz API bezpośrednio, w kodzie faktycznie trzeba kilka rzeczy zmienić, a większość z nich załatwi /claude-api migrate w Claude Code. Mnie bardziej interesuje druga połowa: tekst, który wysyłasz do modelu.

Prompty starzeją się szybciej niż kodPrompty starzeją się szybciej niż kod

Każdy projekt, który od jakiegoś czasu rozmawia z Claude'em, obrasta instrukcjami pisanymi pod modele, których już nie ma. CRITICAL: you MUST use this tool z czasów, kiedy jakiś starszy model ciągle zapominał o tym narzędziu. „Think step by step” sprzed czasów, gdy myślenie było wbudowane w model. Dziesięciopunktowa procedura do zadania, które model planuje teraz lepiej sam.

Nikt tych linijek nie usuwa, bo nikt nie pamięta, po co tam są. A one dalej działają. Nowsze modele trzymają się instrukcji dokładniej i bardziej dosłownie, więc reguła, którą trzeba było wykrzyczeć, żeby dotarła do starego modelu, teraz jest stosowana wszędzie, także tam, gdzie nikt jej nie planował. Działa to jak „PILNE” w temacie maila: przy trzecim nikt już nie wie, co jest naprawdę pilne.

Opus 5.5 dokłada kilka własnych powodów, żeby się temu przyjrzeć:

• Thinking jest zawsze włączony. Sterujesz nim tylko przez effort, a domyślny effort spadł z high na medium. Reguły w stylu „nie myśl, po prostu odpowiedz” model nie jest już w stanie wykonać.
• Wymuszenie konkretnego narzędzia przez tool_choice kończy się błędem. O narzędzie trzeba poprosić w prompcie.
• Instrukcje w stylu „zachowaj wszystkie wnioski na koniec” albo „nie komentuj na bieżąco” pisano pod gadatliwe modele. Kiedy zostają w prompcie, Opus 5.5 potrafi zamilknąć na całe długie zadanie.
• Instrukcje do czytania wykresów i zrzutów ekranu (tu przytnij, tam przybliż, najpierw odczytaj osie) mogą już nie być potrzebne. Opus 5.5 czyta materiały wizualne dużo dokładniej bez nich.
• Przy frontendzie „unikaj generycznego wyglądu AI” niewiele daje. Lepiej działa wymienienie konkretnych domyślnych wyborów, których nie chcesz: kremowego tła, kursywnych słów-akcentów w nagłówkach, numeracji sekcji „01/02/03”, etykiet w monospace, przycisków w kształcie pigułek. Ten blog ma etykiety w monospace wszędzie, więc nie mnie oceniać.

KomendaKomenda

Claude Code ma na to komendę: /claude-api prompt-audit. Jest częścią wbudowanego skilla claude-api, więc nie trzeba niczego instalować.

Komenda przechodzi przez cały folder projektu i zbiera wszystko, co trafia do modelu jako tekst: prompty systemowe i kod, który je składa, opisy narzędzi, pliki CLAUDE.md, skille, pliki z regułami, przykłady few-shot i kod budujący zapytania do API. Najpierw pokazuje, co znalazła, żeby można było sprawdzić, czy patrzy na właściwe pliki.

Jeśli projekt ma historię w gicie, puszcza blame na plikach z promptami. Przy każdej dobitnej albo zakazującej linijce pyta, przed jakim błędem, na jakim modelu, ta linijka miała chronić i czy ten błąd dalej występuje na nowym modelu. Linijka, której nikt nie umie uzasadnić, trafia do raportu.

Potem porównuje wszystko z listą przestarzałych wzorców, między innymi:

• krzyczenie wielkimi literami i asekuracyjne „spróbuj” przy rzeczach, które tak naprawdę są wymagane,
• obejścia dla rzeczy, które API robi już samo, jak thinking czy structured outputs,
• skrypty krok po kroku do zadań, które wymagają oceny sytuacji,
• długie serie „nigdy nie rób X” bez żadnego powodu obok,
• łatki na błędy modeli, których nikt już nie używa,
• tę samą regułę zapisaną w trzech plikach, w trzech trochę różnych wersjach.

Czego nie ruszaCzego nie rusza

To mnie przekonało. Audyt nie próbuje skracać promptów. Przy każdej linijce zadaje jedno pytanie: czy model mógłby to wiedzieć i bez niej?

Jeśli tak, linijka jest kandydatem do usunięcia. Zostaje wszystko, co wiesz tylko ty: kim są twoi użytkownicy, co robi produkt, fakty o środowisku, jak dobry ma być wynik i powody stojące za twoimi regułami. Zostają też dokładne skrypty do delikatnych operacji (deploye, logowanie, wszystko, co coś kasuje). Przy opisach narzędzi audyt często proponuje wręcz dopisanie szczegółów, bo zbyt ogólny opis narzędzia to częstszy problem niż zbyt długi.

Jeśli nic nie znajdzie, nic nie proponuje. Czysty raport to też wynik.

Co dostajeszCo dostajesz

Na koniec dostajesz raport i diff. Każde znalezisko w raporcie ma miejsce w pliku, zacytowany tekst, wzorzec, do którego pasuje, wyjaśnienie, czemu ten wzorzec jest przestarzały dla docelowego modelu, poziom pewności i proponowaną akcję. W diffie każde znalezisko to osobny fragment, więc bierzesz te, z którymi się zgadzasz, a resztę pomijasz.

Audyt nie edytuje plików, dopóki go o to nie poprosisz. Nie zatrzymuje się też w połowie, żeby zadawać pytania. Zakres i docelowy model ustala sam na podstawie twojego polecenia i repozytorium, a swoje założenia wypisuje na górze raportu. Jeśli źle trafił, uruchom go jeszcze raz z węższym poleceniem.

CLAUDE.md ErnestaCLAUDE.md Ernesta

Ernest, z którym pracuję, pisze bardzo szczegółowe pliki CLAUDE.md i dokładnie opisuje w nich, jak agent ma się zachowywać w jego projektach. Problem pojawił się, kiedy część tych zasad zaczęła się kłócić z zasadami zapisanymi w jego skillach. Agent dostawał dwa zestawy wytycznych i nie było jasne, który powinien wygrać.

Podesłałem mu prompt, który miał to uporządkować. Prompt przeczytał pliki CLAUDE.md i skille obok siebie, znalazł miejsca, w których zasady się pokrywają albo sobie przeczą, wskazał, gdzie nie wiadomo, który plik ma pierwszeństwo, i zaproponował kilka sposobów na przeorganizowanie tego tak, żeby agent przestał dostawać sprzeczne polecenia.

Większość naprawy polegała na ustaleniu, do czego służy każdy plik. CLAUDE.md trzyma fakty o projekcie i reguły, które obowiązują wszędzie. Skill opisuje, jak zrobić jedno konkretne zadanie. Każda reguła mieszka w jednym miejscu, a jeśli drugi plik jej potrzebuje, odsyła tam, zamiast trzymać własną kopię. Audyt promptów wychodzi z tego samego założenia. CLAUDE.md i skille są na jego liście, a jedna z jego zasad mówi, że dana informacja ma żyć w dokładnie jednym miejscu. Kopie z czasem się rozjeżdżają i właśnie stąd wzięły się konflikty u Ernesta.

Jak to uruchomićJak to uruchomić

Otwórz Claude Code w swoim projekcie i wpisz:

/claude-api prompt-audit

Jeśli interesuje cię tylko część repozytorium, dopisz ją po komendzie, na przykład /claude-api prompt-audit CLAUDE.md i .claude/skills.

Potem przeczytaj raport, weź fragmenty, z którymi się zgadzasz, i przetestuj je. Sam audyt mówi, że usunięcie linijki to tylko przypuszczenie, dopóki go nie sprawdzisz: porównaj zachowanie przed zmianą i po niej, a jeśli stawka jest wysoka, zmieniaj jedną rzecz naraz. Jeśli coś się pogorszy, przywróć instrukcję w krótszej, prostszej formie, zamiast wracać do starej wersji.

Przy następnej premierze modelu uruchom audyt jeszcze raz. Część linijek, które dziś pomagają Opusowi 5.5, będzie przeszkadzać temu, co przyjdzie po nim.

O obrazieO obrazie

Obraz na górze to Cykliniarze Gustave'a Caillebotte'a z 1875 roku. Trzech mężczyzn na kolanach w pustym paryskim mieszkaniu zdziera stary lakier z desek, żeby można było położyć nowy. Malarze zwykle nie zawracali sobie głowy tym etapem remontu. Caillebotte tak, a jury Salonu odrzuciło obraz, podobno jako zbyt wulgarny. Audyt promptów to ta sama kategoria roboty. Nikt jej nie zobaczy, a następnemu modelowi będzie się na niej lepiej pracować.