Brief zamiast prompta: jak przestać tłumaczyć AI wszystko od nowa

Znasz ten moment. Otwierasz czat z AI, masz do zrobienia analizę sprzedaży i zaczynasz pisać. Pierwsze zdanie jest rzeczowe. Drugie dodaje wyjątek. Trzecie wyjątek od wyjątku. Po kwadransie masz prompt długości listu motywacyjnego, a model i tak policzy coś trochę innego, niż miał policzyć. Wklejasz więc prompt jeszcze raz, z dopiskiem „PAMIĘTAJ, ŻE…” wielkimi literami. Kto z nas tego nie robił, ten niech pierwszy rzuci pierwszym kamieniem (albo pierwszym promptem).

Przez kilka lat pracy z danymi zauważyłem, że ten rytuał ma jedną wspólną cechę: wszystko, co ważne, żyje w oknie rozmowy, a okno rozmowy jest najgorszym możliwym miejscem na przechowywanie wiedzy. Zamyka się je, odświeża, zmienia model albo zmienia się kolega, który ma kontynuować robotę. Kontekst znika. Zostaje tylko wspomnienie, że kiedyś udało się napisać naprawdę dobry prompt.

W tym artykule pokażę Ci alternatywę, którą w kursie nazywam briefem. To jedna z pierwszych rzeczy, jakie robimy w pierwszym tygodniu programu, i jedna z tych, które po kilku tygodniach zmieniają sposób pracy najbardziej. Brief jest zwykłym plikiem tekstowym. Brzmi to mało spektakularnie, ale w tym tkwi jego siła.

Dlaczego długi prompt to kiepski sposób przekazywania wiedzy

Zacznijmy od tego, czego wymagamy od instrukcji dla AI. Ma być zrozumiała, kompletna, aktualna i łatwa do ponownego użycia. Długi prompt wklejany do okna rozmowy spełnia zwykle jeden z tych czterech warunków, i to w dobry dzień.

Po pierwsze, prompt się nie kumuluje. Kiedy poprawiasz go w trakcie rozmowy, poprawka żyje w historii czatu, a nie w niczym, co możesz otworzyć jutro. Następnego dnia piszesz wersję „z głowy” i okazuje się, że zapomniałeś o jednym ograniczeniu, które w poprzedniej rozmowie kosztowało godzinę pracy.

Po drugie, prompt nie ma właściciela. Jeśli analizę robią dwie osoby, każda ma własną wersję instrukcji. Jedna liczy klienta od momentu płatności, druga od wypełnienia formularza. Obie mają wrażenie, że „przecież dały modelowi jasne polecenie”. Wyniki się różnią, a spór o to, kto ma rację, odbywa się na slajdach, nie w dokumentacji.

Po trzecie, długość szkodzi. Modele językowe nie czytają tekstu tak jak człowiek, który zapamiętuje najważniejsze. Badanie zespołu badaczy m.in. ze Stanforda i Berkeley, opisane w pracy Lost in the Middle, pokazało, że modele najlepiej radzą sobie z informacją umieszczoną na początku i na końcu długiego kontekstu, a wyraźnie gorzej z tą ukrytą w środku. Jeśli Twój kluczowy warunek wylądował w czwartym akapicie rozwlekłego prompta, możesz mieć pecha. Wnioski z tej pracy warto traktować ostrożnie, bo modele szybko się zmieniają, ale intuicja pozostaje trafna: gęsty, uporządkowany kontekst działa lepiej niż ściana tekstu.

Po czwarte, prompt miesza rzeczy o różnej trwałości. Cel dzisiejszej analizy zmienia się codziennie. Definicja przychodu w Twojej firmie zmienia się raz na kilka lat. Format raportu dla zarządu zmienia się, kiedy zarząd się zmienia. Wrzucanie tego wszystkiego do jednego worka sprawia, że za każdym razem przepisujesz rzeczy stałe razem ze zmiennymi.

Firma Anthropic opisuje to samo zjawisko od strony inżynierskiej. W tekście Effective context engineering for AI agents przekonuje, że kontekst to ograniczony zasób, a celem jest znalezienie najmniejszego zestawu informacji o wysokiej wartości, który daje oczekiwany wynik. Wynika z tego prosty wniosek: warto świadomie projektować to, co model dostaje, zamiast dorzucać kolejne zdania, bo „na wszelki wypadek”.

Czym jest brief

Słowo „brief” pochodzi z agencji reklamowych i dobrze oddaje sens. Kiedy zamawiasz grafikę, nie dzwonisz do projektanta, żeby powiedzieć „zrób coś ładnego”. Wysyłasz dokument: czemu to służy, dla kogo, jakie są ograniczenia, w jakim formacie ma przyjść plik i po czym poznasz, że praca jest skończona. Dobry projektant po przeczytaniu briefu nie musi zadawać dwudziestu pytań. Zły brief generuje dwadzieścia pytań albo, co gorsze, zero pytań i projekt, który nikomu się nie przyda.

Z AI jest tak samo, z jedną różnicą: model prawie nigdy nie zadaje pytań. Dopowie sobie brakujące elementy najbardziej prawdopodobnie brzmiącymi założeniami i pójdzie dalej z pewnością siebie godną stażysty w pierwszym tygodniu pracy. Dlatego to Ty musisz zrobić pracę, którą człowiek wykonałby w rozmowie, i zapisać ją raz, porządnie.

Brief składa się z pięciu elementów. W programie kursu wracają one w każdym tygodniu, bo po pierwszym tygodniu stają się odruchem.

Pięć elementów briefu

1. Cel biznesowy

Pierwsze pytanie brzmi: jaką decyzję ma wesprzeć ta analiza? Lepiej zapytać „co zmieni się po tym, jak ktoś zobaczy wynik” niż „co mam policzyć”. Jeśli odpowiedź brzmi „nic”, może warto zająć się czymś innym.

Różnica jest większa, niż się wydaje. Polecenie „zrób analizę sprzedaży” prowadzi do tabeli z sumą miesięczną. Cel „zdecydować, czy w czwartym kwartale zwiększyć budżet na kampanie w kategorii A” prowadzi do porównania zwrotu z reklamy w czasie, z uwzględnieniem sezonowości. Ten sam plik z danymi, dwie zupełnie inne analizy.

Dobry cel mieści się w jednym lub dwóch zdaniach i zawiera czasownik decyzyjny: wybrać, zatwierdzić, zrezygnować, zwiększyć, wyjaśnić spadek.

2. Dane i źródła

Drugi element opisuje, na czym model ma pracować i co te dane znaczą. Nazwa pliku to za mało. Potrzebne są: pochodzenie danych (eksport z którego systemu, z jakiego dnia), zakres (jakie lata, jakie regiony), słownik kolumn i wszystkie dziwactwa, które znasz z doświadczenia.

Dziwactwa są tu najcenniejsze. Że kolumna „status” przyjmuje wartości, których nikt nie dokumentuje. Że do końca marca zwroty zapisywano jako wartości ujemne, a od kwietnia jako osobne wiersze. Że w danych z jednego regionu brakuje tygodnia, bo system był wtedy w migracji. Taką wiedzę zna zwykle jedna osoba w zespole i trzyma ją w głowie. Brief to miejsce, gdzie przestaje to być tajemnica poliszynela.

Warto też wskazać, które źródło wygrywa w razie sprzeczności. Jeśli raport finansowy mówi jedno, a eksport z CRM drugie, model nie zgadnie, któremu zaufać. W programie kursu wracamy do tego w drugim tygodniu pod hasłem „źródła prawdy”.

3. Ograniczenia

Trzeci element to lista rzeczy, których nie wolno i których nie wiemy. Brzmi jak formalność, a bywa najważniejszą częścią dokumentu.

Ograniczenia dzielą się na kilka rodzajów. Są poufne dane, które muszą zostać w firmie, więc nie wolno wklejać ich do zewnętrznych narzędzi (ten temat omawiamy w kursie już na starcie, w punkcie „Bezpieczny start”). Są zakazy techniczne, na przykład „pliku źródłowego nie ruszamy, pracujemy na kopii”. Są luki w wiedzy: „nie wiemy, czy w danych z lutego są zwroty”. I są granice odpowiedzialności: „opisz scenariusze, decyzji o zwolnieniach nie rekomenduj”.

Dobrze napisane ograniczenia robią jedną cenną rzecz: dają modelowi pozwolenie na powiedzenie „tego nie da się ustalić z dostępnych danych”. Bez nich model czuje się zobowiązany do odpowiedzi na każde pytanie i wypełnia luki zmyślonymi ustaleniami.

4. Kryterium poprawności

To element, który najczęściej pomijam u początkujących uczestników i który najbardziej im brakuje. Po czym poznasz, że wynik jest dobry?

Kryterium może być twarde: „suma sprzedaży w analizie zgadza się z raportem finansowym z dokładnością do złotówki”. Może być strukturalne: „każdy wniosek ma wskazaną kolumnę i filtr, z których wynika”. Może być procesowe: „przed wnioskami pokaż, ile wierszy odrzucono i dlaczego”. Może też być negatywne: „jeśli wynik wygląda na zbyt dobry, zatrzymaj się i poszukaj błędu”.

Kryterium poprawności zamienia ocenę wyniku z „chyba wygląda dobrze” w czynność, którą da się wykonać. Dodatkowo daje punkt zaczepienia do weryfikacji, a tej poświęcamy w kursie cały osobny temat w trzecim tygodniu. Kasia opisuje to bardziej szczegółowo w artykule o sprawdzaniu wyników AI, więc nie będę się powtarzał.

5. Format wyniku

Ostatni element opisuje, co ma przyjść z powrotem: tabela, krótkie podsumowanie, lista hipotez, wykres, plik CSV, kod SQL. Do tego odbiorca: czy to ma przeczytać zarząd, czy analityk, który będzie kontynuował pracę. Zarząd potrzebuje trzech zdań i jednego wykresu. Analityk potrzebuje zapytań, założeń i listy odrzuconych wierszy.

Format wydaje się detalem, dopóki nie dostaniesz dwunastu akapitów eseju tam, gdzie chciałeś tabelę z pięcioma wierszami.

Markdown w pigułce

Brief najwygodniej pisać w Markdownie. To format zwykłego tekstu z kilkoma znakami, które nadają mu strukturę. Specyfikację standardu utrzymuje projekt CommonMark, ale w praktyce do pisania briefów potrzebujesz mniej niż strony podręcznika.

• Linia zaczynająca się od # to nagłówek. Dwa hashe to nagłówek niższego poziomu, trzy jeszcze niższy.
• Linia zaczynająca się od - to punkt listy.
• Tekst w odwróconych apostrofach, na przykład sprzedaz_netto, to nazwa kolumny lub fragment kodu.
• Trzy odwrócone apostrofy otwierają i zamykają blok kodu albo przykładowych danych.
• Pusta linia oddziela akapity.

I tyle. Powód, dla którego Markdown sprawdza się tak dobrze, jest prosty. Modele uczyły się na ogromnych zbiorach tekstów, w których Markdown występuje wszędzie: w dokumentacji, w repozytoriach kodu, na forach. Czytają go płynnie. Ty możesz go edytować w dowolnym notatniku, a jeśli kiedyś zechcesz pokazać brief w wersji ładnej, każde narzędzie zamieni go w czytelną stronę.

Jest jeszcze jedna zaleta, o której mówi się rzadziej. Plik tekstowy możesz porównać z poprzednią wersją. Kiedy wynik analizy zmienił się między wtorkiem a czwartkiem, zerkasz, co zmieniło się w briefie. Okno rozmowy takiej funkcji nie ma.

Przykład: brief do analizy sprzedaży

Zobaczmy, jak to wygląda w praktyce. Poniżej brief dla zadania, które pojawia się w moich szkoleniach regularnie: porównanie dwóch kampanii reklamowych. Dane są przykładowe.

# Brief: porównanie kampanii A i B za wrzesień

## Cel biznesowy
Zdecydować, którą z dwóch kampanii przedłużyć na październik.
Decyzję podejmuje dyrektor marketingu w piątek. Budżet jest
stały, więc wybieramy jedną.

## Dane i źródła
- `kampanie_wrzesien.csv`: eksport z panelu reklamowego, dzienny
- `zamowienia.csv`: eksport z systemu sprzedaży, zamówienia opłacone
- Klient to osoba, która opłaciła zamówienie. Wypełnienie
  formularza nie jest klientem.
- Przy sprzecznościach wygrywa `zamowienia.csv`.
- Uwaga: 12-14 września brakuje danych z panelu (awaria).

## Ograniczenia
- Nie wklejamy danych osobowych klientów do żadnego narzędzia.
- Pracujemy na kopii plików, nie modyfikujemy oryginałów.
- Jeśli czegoś nie da się ustalić z danych, piszemy to wprost.

## Kryterium poprawności
- Suma zamówień w analizie zgadza się z raportem finansowym.
- Każdy wniosek wskazuje kolumnę i filtr, z których wynika.
- Przed wnioskami: ile wierszy odrzucono i dlaczego.

## Format wyniku
Tabela porównawcza (koszt, liczba klientów, koszt pozyskania),
trzy zdania rekomendacji dla dyrektora i lista założeń.

Ten dokument ma około dwudziestu linijek i zajmuje trzy minuty pisania. Teraz porównaj z promptem, który napisałbyś „z głowy”: „porównaj kampanie A i B i powiedz, która lepsza”. Ten drugi kosztuje kilkanaście sekund i generuje analizę, którą trzeba będzie odrzucić z trzech różnych powodów. Zwróć uwagę na jedną rzecz w briefie: definicja klienta jest zapisana wprost. Ten drobiazg potrafi odwrócić zwycięzcę porównania. Pokazujemy to zresztą w interaktywnej Pracowni na stronie głównej kursu: zmiana jednej definicji zmienia werdykt.

Od briefu do pliku w repozytorium

Pojedynczy brief do zadania to początek. Prawdziwa wygoda zaczyna się, gdy stałe elementy kontekstu trafiają do plików, które narzędzia AI wczytują automatycznie.

W drugim tygodniu kursu zajmujemy się dokładnie tym: organizacją wiedzy w plikach README.md, AGENTS.md i CLAUDE.md. Pierwszy opisuje projekt dla ludzi. Dwa pozostałe to instrukcje dla agentów. Format AGENTS.md powstał jako wspólna konwencja dla wielu narzędzi, a Claude Code wczytuje pliki CLAUDE.md na początku każdej sesji jako stałe instrukcje projektu. W praktyce oba pliki mogą mieć tę samą treść (nasze repozytorium strony kursu trzyma je jako celowo identyczne).

Co tam trafia? To, co w briefie jest stałe: słownik pojęć firmy, definicje KPI, lista źródeł prawdy, zasady bezpieczeństwa i konwencje pracy. Brief do konkretnego zadania zostaje wtedy krótki, bo odsyła do reszty. Podział przypomina to, jak działa każda dojrzała organizacja: są regulaminy i są zlecenia. Nikt rozsądny nie dołącza regulaminu firmy do każdego zlecenia.

Kluczowa zasada: plik z instrukcjami wymaga selekcji jak każde miejsce o ograniczonej pojemności. Każda linijka kosztuje, bo zajmuje miejsce w kontekście modelu przy każdej rozmowie. Zasada, którą stosuję, brzmi: jeśli instrukcja nie zmieniłaby zachowania modelu przy żadnym znanym mi zadaniu, wylatuje.

Najczęstsze błędy w briefach

Po kilku latach pracy z uczestnikami szkoleń lista wpadek jest powtarzalna. Oto te, które widzę najczęściej.

1. Brief opisuje samo zadanie. „Przeanalizuj sprzedaż” to zadanie. „Zdecyduj, czy zamknąć kategorię C” to decyzja. Dopiero druga wersja mówi modelowi, co jest ważne.
2. Brak definicji. Przychód, klient, aktywny użytkownik, konwersja. Każde z tych słów ma w Twojej firmie konkretne znaczenie, którego model nie zna.
3. Same życzenia, zero kryteriów. „Zrób dokładną analizę” brzmi dobrze i nie znaczy nic. Dokładną, czyli jaką? Z jaką tolerancją?
4. Za dużo naraz. Brief na pięć analiz równocześnie jest gorszy niż pięć krótkich briefów. Każde zadanie zasługuje na własny cel i własne kryterium.
5. Brak aktualizacji. Brief napisany w poniedziałek i nieruszany do końca kwartału zaczyna kłamać. Traktuj go jak kod: poprawiasz, kiedy rzeczywistość się zmienia.
6. Sekrety w briefie. Hasła, klucze API i dane osobowe nie należą do plików tekstowych, które potem trafiają do repozytorium. Do tego wracamy w tygodniu czwartym, przy podłączaniu baz danych.

Jak wprowadzić brief w tym tygodniu

Nie potrzebujesz kursu, żeby zacząć. Wystarczy jedno zadanie analityczne, które masz na liście, i kwadrans czasu.

1. Weź realne zadanie, które zaraz zrobisz z AI.
2. Utwórz plik brief.md i skopiuj do niego pięć nagłówków: cel, dane, ograniczenia, kryterium, format.
3. Wypełnij je, zaczynając od celu. Jeśli nie umiesz napisać celu w dwóch zdaniach, to jest pierwszy wynik: właśnie dowiedziałeś się, że zadanie jest niedookreślone.
4. Wklej brief do rozmowy z AI i poproś model, żeby przed rozpoczęciem pracy wypisał swoje założenia oraz pytania, na które nie umie odpowiedzieć z briefu.
5. Popraw brief na podstawie tych pytań. Dopiero wtedy zlecaj zadanie.

Krok czwarty uważam za najlepszą rzecz, jaką można zrobić z modelem, który skłonny jest zgadywać. Zamiast pozwalać mu zgadywać po cichu, każesz mu zgadywać na głos. Połowa pytań będzie zbędna, a druga połowa wskaże dokładnie te luki, które zepsułyby analizę.

Po kilku powtórzeniach zauważysz efekt uboczny, który uważam za największą wartość tej metody. Pisanie briefu zmusza do myślenia o zadaniu, zanim zaczniesz je wykonywać. Model jest tu wygodnym pretekstem. Ludzie, którzy piszą dobre briefy dla AI, piszą też lepsze zlecenia dla kolegów, lepsze maile do szefa i lepsze notatki do samych siebie.

Gdzie to wszystko prowadzi

Brief to fundament całego pierwszego tygodnia. W tym tygodniu uczymy się, jak działa model, czym różni się od czatu i agenta, skąd biorą się błędne odpowiedzi i jak zaplanować analizę w schemacie plan, wykonanie, weryfikacja. Brief jest narzędziem, które spina te elementy. Plan trafia do pliku, wykonanie opiera się na pliku, weryfikacja porównuje wynik z kryterium z pliku.

W kolejnych tygodniach rozbudowujemy to podejście: brief staje się repozytorium wiedzy firmy, potem instrukcją dla agenta, który pracuje na bazie danych, a wreszcie specyfikacją własnego rozwiązania analitycznego. Za każdym razem schemat jest ten sam, tylko skala rośnie. To właśnie ta powtarzalność sprawia, że kurs da się zrealizować w sześć tygodni i nadal mieć czas na życie.

Jeśli po przeczytaniu tego tekstu zrobisz tylko jedną rzecz, niech to będzie ta: zapisz następny prompt w pliku, zanim go wyślesz. Dopisz cel, kryterium i jedno ograniczenie. Sprawdź, czy wynik jest lepszy. Moim zdaniem będzie, a koszt eksperymentu to pięć minut i plik tekstowy.