Jeden prompt dla Opusa 5 i Sonneta 5.5 przestał wystarczać

Anthropic wydał przewodnik po promptowaniu Claude Sonnet 5.5, modelu, przy którym do najtrudniejszych długich zadań Anthropic nadal poleca Opusa, i w sprawie sprawdzania własnej pracy radzi w nim coś odwrotnego niż przy Opusie. Tydzień temu pisałem o przewodniku po Opusie 5 i o dwóch starych nawykach, które tam po cichu psują wynik: prośbie o zachowawczość w botach recenzujących kod i prośbie o wypisanie toku rozumowania. Druga pułapka wraca w nowym dokumencie bez zmian, bo także Sonnet 5.5 odrzuca takie prośby z kategorią reasoning_extraction. Anthropic ma mechanizm, który odrzucone żądanie automatycznie wysyła jeszcze raz do starszego modelu, ale tej kategorii on nie obejmuje, więc twoja aplikacja dostanie po prostu odmowę. Ważniejsza jest jednak ta odwrócona rada o sprawdzaniu własnej pracy: Opusa trzeba odzwyczajać od dodatkowej weryfikacji, a Sonneta 5.5 przy niskim poziomie namysłu trzeba do niej zmuszać, co oznacza, że jeden wspólny prompt systemowy dla obu modeli przestał być bezpieczną oszczędnością.

Jeden model trzeba hamować, drugiego pilnować

Przewodnik po Opusie 5 każe wyciąć z promptów polecenia w rodzaju "dodaj na koniec krok weryfikacji" albo "sprawdź to subagentem", bo model sprawdza się sam, a dopisane instrukcje tylko mnożą zużyte tokeny, nie poprawiając jakości. Sonnet 5.5 też zwykle sprawdza swoje zmiany, ale przy najniższym poziomie effort, którym każesz mu myśleć jak najkrócej, zdarza mu się ogłosić koniec pracy bez choćby jednego uruchomienia testów. Przykład z dokumentacji jest bardzo przyziemny: model pomija testy projektu, bo nie ma zainstalowanych zależności, i mimo to melduje, że zmiana jest gotowa.