Potrzeba, brief i kryteria wyniku

Cel: przełożyć potrzebę na brief i kryteria

Brief opisuje pracę, którą zlecasz narzędziu, oraz sposób, w jaki sprawdzisz rezultat. Własna wiedza o procesie jest tu ważniejsza niż efektowny prompt. Dobry brief ma wskazanego użytkownika, cel, wejście, źródło prawdy, oczekiwany format, granice i kryteria odbioru. Dodaj też regułę na brak informacji: model ma zapytać, wskazać lukę albo zatrzymać się, zamiast wymyślić odpowiedź.

Porównaj dwa polecenia. „Napisz dobrą odpowiedź dla klienta” nie mówi, jakich faktów użyć ani co znaczy „dobra”. Model może dodać gwarancję, termin lub cenę, których nie oferujesz. Lepszy brief brzmi: „Przygotuj szkic odpowiedzi na podstawie poniższej, fikcyjnej wiadomości i załączonej tabeli usług. Używaj tylko cen z tabeli. Nie obiecuj terminu realizacji, jeśli nie ma go w danych. Gdy brakuje informacji, wypisz pytanie. Zwróć: temat, szkic odpowiedzi, użyte źródła i listę braków. Nie wysyłaj wiadomości”. Kryteria mogą brzmieć: cena zgodna z tabelą; brak wymyślonego terminu; każdy brak nazwany; ton uprzejmy; treść pozostaje szkicem.

Kryteria powinny być obserwowalne. Zastąp „ma być profesjonalnie” konkretnym zachowaniem, które da się potwierdzić. Unikaj kryteriów, które wymuszają jeden styl, jeśli ważniejsza jest poprawność. Zapisz co najmniej jeden zwykły przypadek i jeden przypadek z brakującymi danymi. Poproś model o wskazanie założeń przed generacją; założenia sprawdź z briefem.

Ćwiczenie: Wybierz małe zadanie swojej ścieżki i napisz najpierw polecenie ogólne. Uruchom je na fikcyjnym przykładzie. Następnie uzupełnij brief o źródło prawdy, zakazy, format i pięć kryteriów. Uruchom ponownie i porównaj wyniki, cytując konkretne zdania, które spełniły albo naruszyły kryteria.

Sprawdź: Czy osoba z zewnątrz wie, jaki jest wynik? Czy każda liczba ma źródło? Co ma się stać, gdy brakuje danych? Oddaj obie wersje briefu, wyniki i kryteria.