Jeżeli prompt jest w Twoim systemie „logiką sterującą”, to nie może żyć jako przypadkowy tekst w kodzie. Biblioteka promptów wprowadza porządek: wersje, testy i ślad zmian.
W skrócie
prompt to artefakt: prompt_id, kontrakt danych, owner, test pack
zmiany przez review i CI — bez wyjątków
SemVer działa: PATCH/MINOR/MAJOR + deprecjacja starych wersji
testuj: format, dowody/cytowania, no‑answer, stabilność
Jeśli to ma wejść do procesu, proszę traktować ten rozdział jako standard operacyjny.
Tradycyjna zasada inżynierii: to, co wpływa na wynik systemu, musi być wersjonowane.
Prompt jest częścią logiki. Dlatego prompt trafia do biblioteki jak kod — z testami i właścicielem.
1. Po co biblioteka promptów
„Prompt wklejony w kod” działa tylko do pierwszej zmiany zespołu, modelu albo polityki.
Biblioteka promptów rozwiązuje trzy rzeczy naraz:
powtarzalność (prompt_id@version w śladzie),
kontrola jakości (testy regresji dla promptów),
odpowiedzialność (owner i proces zmian).
2. Struktura promptu jako artefaktu
Minimalne elementy, które powinny być jawne:
prompt_id — stały identyfikator,
template — treść z placeholderami,
kontrakt danych — jakie zmienne są wymagane i w jakim formacie,
policy hooks — gdzie wchodzi standard językowy, cytowania, no‑answer,
test pack — golden set, przypadki negatywne, tolerancje.
3. Workflow: review → testy → release
Najczęstsza porażka: prompt zmieniany „na produkcji”, bez testów i bez śladu.
To kończy się dryfem jakości i brakiem odpowiedzi na pytanie: co się zmieniło.
4. Wersjonowanie: SemVer i polityka deprecjacji
Dla promptów SemVer sprawdza się zaskakująco dobrze:
PATCH — korekta stylu, literówki, drobne doprecyzowania bez zmiany zachowania,
MINOR — nowa możliwość (np. nowy tryb formatu), kompatybilna wstecz,
MAJOR — zmiana kontraktu danych lub zachowania, wymaga migracji.
