Mów do agenta AI jak jaskiniowiec

Większość ludzi pisze do agentów AI tak, jak do mało znanego kolegi z pracy: „Cześć! Chciałem zapytać, czy mógłbyś przy okazji rzucić okiem na pewien problem — wydaje mi się, że coś jest nie tak z logowaniem?". Czterdzieści słów. Agentowi wystarczyłoby sześć: „Logowanie nie działa. Znajdź błąd."

To nie jest kwestia stylu. Za tą różnicą stoi konkretna mechanika i wszystkie jej elementy prowadzą do tego samego wniosku.

Dlaczego zbędne słowa szkodzą

Zbędne słowa konkurują z istotnymi. Uwaga modelu nie rozkłada się równomiernie na całą długość promptu: dobrze opisany efekt lost-in-the-middle pokazuje, że trafność odpowiedzi spada, gdy ważna informacja znajduje się w środku kontekstu. Każde „chciałem zapytać, czy może" to obciążenie, z którym musi konkurować właściwa instrukcja. Krótki prompt utrzymuje sygnał tam, gdzie model nie może go przeoczyć.

Rozwlekłość łączy się też z niższą jakością odpowiedzi, i to w obie strony. Badanie o tytule, który bardzo lubię, Verbosity ≠ Veracity, opisuje zjawisko kompensacji rozwlekłością: modele wydłużają odpowiedzi, kiedy nie są pewne, a dłuższe odpowiedzi wypadają w testach gorzej, nie lepiej. Kto pisze zwięźle, zwykle otrzymuje zwięzłą odpowiedź.

Producenci modeli mówią to samo. Wytyczne Anthropic dotyczące pisania promptów zaczynają się od zasady „bądź jasny i bezpośredni", a poradniki praktyków sprowadzają się do reguły „tak krótko, jak można; tak długo, jak trzeba". Nikt, kto mierzy skuteczność promptów, nie zaleca zaczynania od uprzejmości.

Jest wreszcie kwestia kosztów. Tokeny liczone są w obie strony, a w pętli agenta wiadomość użytkownika jest czytana ponownie przy każdym wywołaniu narzędzia. Za uprzejmy wstęp w zadaniu wymagającym pięciu kroków płaci się pięć razy.

Tryb jaskiniowca

Matt Pocock publikuje tę praktykę jako gotowy skill w swoim otwartym repozytorium. Nazywa się caveman, a jego opis streszcza całą filozofię:

"Respond terse like smart caveman. All technical substance stay. Only fluff die."

Zasady: usunąć przedimki, wypełniacze („po prostu", „naprawdę", „właściwie"), uprzejmości i asekuracyjne zastrzeżenia; zachować dokładnie każdy termin techniczny; cytować błędy dosłownie; nie zmieniać bloków kodu. Deklarowany efekt: około 75% mniej tokenów przy zachowaniu pełnej precyzji technicznej. Przykład z pliku skilla mówi sam za siebie:

Nie: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..." Tak: "Bug in auth middleware. Token expiry check use < not <=. Fix:"

Przyjąłem ten styl jako obowiązujący w moim projekcie AppMaker. Ostatecznie przekonał mnie jeden szczegół: wyjątek nazwany auto-clarity. Tryb jaskiniowca sam się wyłącza przy ostrzeżeniach dotyczących bezpieczeństwa, przy potwierdzaniu nieodwracalnych działań i przy sekwencjach kroków, w których skrót mógłby zostać źle odczytany. Zwięzłość tam, gdzie nic nie kosztuje; pełne zdania tam, gdzie niejasność może kosztować dużo. Widać, że ktoś to dobrze przemyślał.

Jak to wygląda w praktyce

Moje wiadomości do agentów układają się dziś w stały wzór: fakt, ograniczenie, polecenie.

• „Testy nie przechodzą po aktualizacji do vitest 4. Błąd: <wklejka>. Nie zmieniaj konfiguracji w /infra. Napraw."
• „Potrzebny status faktury klientki M. z FreeAgent. Tylko odczyt."

Bez przeprosin, bez „czy mógłbyś", bez streszczania tego, co agent już wie. Komunikaty o błędach wklejam dosłownie i nigdy ich nie parafrazuję — tekst błędu to najbardziej treściwa informacja, jaką mam. Ograniczenia zapisuję wprost, bo model nie uszanuje granicy, o której nie wie.

Jest też efekt uboczny, którego się nie spodziewałem. Sprowadzenie prośby do schematu fakt–ograniczenie–polecenie wymaga, żeby najpierw samemu wiedzieć, czego się chce. W połowie przypadków zauważam własne niejasne myślenie, zanim zobaczy je agent.