Procedura

Biblioteka promptów i wersjonowanie

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.

Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Projektowanie interakcji i ma formę Procedura. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal cel i kryteria poprawności (co znaczy „dobry wynik”).
  • Zamknij format wyjścia (JSON / tabela / sekcje) i przygotuj walidację.
  • Ogranicz przestrzeń odpowiedzi: instrukcje, słownik terminów, limity.
  • Dodaj kontrolę jakości: self-check, sanity-checks, fallback, „no-answer”.
  • Zapisz jako szablon (prompt_template) i wersjonuj jak kod.
  • Wprowadź testy regresyjne (golden set) i przeglądy po zmianach.

Najczęstsze pułapki

  • Mieszanie instrukcji z danymi wejściowymi (brak separacji „co” vs „na czym”).
  • Format wynikowy „opisowy” bez kontraktu – brak automatycznej kontroli.
  • Zbyt ogólne polecenia („napisz mądrze”) bez parametrów i ograniczeń.
  • Brak strategii na niepewność: model zaczyna „zgadywać” zamiast eskalować.

Artefakty w Luage

prompt_template output_contract policy:language.standard trace_id golden_set

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

Szablon do skopiowania

Minimalny szablon promptu (do biblioteki)

prompt_template: support.reply@v3
intent: support.reply
inputs:
  - user_message
  - locale
constraints:
  - "Jeśli brak źródła → powiedz, że nie wiesz i poproś o doprecyzowanie"
output:
  format: markdown
  sections: ["Odpowiedź", "Co dalej"]

Traktuj szablon jak kod: owner, wersja, testy i przegląd. Wtedy to działa powtarzalnie.

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

Biblioteka promptów — workflow wersjonowania
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.

5. Testy promptów: co mierzyć

Test Co sprawdza Minimalny próg
Format czy wynik spełnia schema / JSON 0 błędów
Dowody czy cytowania są wymagane i poprawne coverage ≥ próg
No‑answer czy model umie odmówić, gdy brakuje danych brak „zmyśleń”
Stabilność czy wynik nie skacze przy powtórkach tolerancja ustalona

6. Powiązane rozdziały

Następny krok

Jeśli prompt ma korzystać z narzędzi, dopnij kontrakt i testy narzędzi.

Przejdź do testów narzędzi