Każda agencja SEO, która używa AI dłużej niż pół roku, dochodzi do tego samego momentu: prompty zaczynają się powtarzać. Senior copywriter ma w głowie „swój” prompt do meta description, junior ma swój, redaktor ma swój. Każdy z nich daje nieco inne wyniki, każdy jest nieco inaczej zoptymalizowany. Po roku zespół ma 30 promptów rozsianych po Notion, Slacku i osobistych zakładkach przeglądarek. To moment, w którym warto pomyśleć systematycznie.
Dlaczego to nie jest temat „nice-to-have”
Maxim AI w raporcie 2025 oszacował, że do końca tego roku 750 milionów aplikacji globalnie będzie wykorzystywało LLM, a straty enterprise z undetected LLM failures wynoszą już 1,9 mld USD rocznie. Większość z tych failures to nie halucynacje — to prompt drift, czyli sytuacja, w której prompt, który dwa miesiące temu działał, dziś daje gorsze wyniki, bo model został zaktualizowany lub kontekst się zmienił.
Bez wersjonowania promptów i metryk per wersja nie jesteś w stanie wykryć, kiedy zaczynasz produkować gorszą jakość — aż klient zwróci uwagę.
Dla agencji to jest realna oszczędność: 1 prompt do meta description użyty 5 000 razy/miesiąc, jeśli wygeneruje 2% gorsze meta — to jest 100 stron miesięcznie z gorszym CTR. Mierzalne.
Trzy poziomy biblioteki
Poziom 1: Notion / Linear / Google Doc. Niskotechnologiczne. Działa dla zespołów < 5 osób, gdzie wszyscy widzą się codziennie i konsultują zmiany. Limit: brak versioning, brak metryk, brak A/B. Każda zmiana w prompcie nadpisuje historię. Zero infrastructure cost — to jest jego przewaga.
Poziom 2: PromptLayer. Git-style versioning + CMS dla promptów. Działa jako warstwa między aplikacją a LLM provider. Auto-capture promptów, version history, output examples. Integracja: kilka linii kodu (Python/JS). Słabość: brak wbudowanych eval frameworks (musisz je dorzucić sam). Cena: free tier wystarcza dla testów, plan paid od $20/mc.
Poziom 3: Langfuse. Open source / self-host. Najczęściej polecany dla teamów wymagających eval. A/B testing built-in, observability, prompt versioning, cost/latency tracking per version. Może być self-hosted (ważne dla wrażliwych danych klientów). Aktywna społeczność, dobra dokumentacja. Dla agencji — najczęstszy „production-grade” wybór.
Alternatywy enterprise. Braintrust, LangSmith, Maxim AI, Helicone. Lista długa, decyzja zwykle robiona pod konkretny stack: jeśli używasz LangChain — LangSmith. Jeśli OpenAI heavy — Braintrust ma najlepszy fit. Dla 95% agencji Langfuse + PromptLayer pokrywa 90% potrzeb.
prompts.chat jako baseline
Repozytorium prompts.chat na GitHubie ma 143k+ gwiazdek, GitHub Staff Pick, cytowania akademickie z Forbes, Harvard, Columbii. To jest „awesome-list” promptów do wszystkiego — nie SEO-specific, ale baseline z którego można zacząć.
Anti-pattern, który widzimy regularnie: zespoły kopiują prompty z LinkedIn lub z prompts.chat bez testowania na własnych klientach. Prompt, który działa dla amerykańskiego SaaS-a, nie zadziała 1:1 dla polskiej kancelarii prawnej. Test na 5–10 stronach przed włączeniem do SOP — niezbędne minimum.
Najczęściej re-używane prompty SEO (kandydaci do SOP)
Lista, którą widzimy w 90% agencji średniej skali:
- Keyword research clustering — zamień listę KW w klastry topical z intent labels
- Outline generator — z entity coverage + fan-out queries (więcej w tekście o briefach SEO)
- Outline expansion — przekonwertuj outline w pełny draft sections
- Meta description compress — zredukuj artykuł do 155-znakowego meta z CTA i KW
- Schema markup generator — dla FAQPage, Article, Product, HowTo
- Image alt text — z kontekstem surrounding content
- Internal link suggestions — dopasuj anchor do target page topic
- Intent classifier — informational/commercial/transactional/navigational
8 promptów. Każdy używany regularnie (kilka razy/tydzień), każdy z mierzalnym output (meta to 155 chars lub nie, schema valid lub nie). Idealni kandydaci do SOP z versioning.
Kandydaci do ad-hoc (nie do SOP)
Prompty, które są kreatywne, jednorazowe, kontekstualne — versioning utrudnia bardziej niż pomaga:
- Audyt brand voice w nowej domenie — każda domena ma inny ton
- Competitor angle exploration — „jakich kątów konkurent nie pokrył?”
- „Why is this page not ranking” exploration — diagnostyka case-by-case
- Niestandardowe content angles dla unikalnego klienta
- Crisis communication content — jednorazowe, wysokie stakes
Próba wsadzenia tych promptów do SOP zwykle skutkuje albo dłuższymi i mniej elastycznymi SOP-ami, albo „mega-promptem” pokrywającym wiele scenariuszy (anti-pattern, opisany niżej).
A/B testing — wzorce 2025–2026
Trzy techniki, których używają zespoły production-grade:
Canary deploy. 10% traffic do variant B, 90% do A. Po 2–4 tygodniach decyzja. Best practice dla promptów wysokiego volume.
Shadow testing. Logujesz oba responses, wybierasz manualnie lepszy. Najmniej destrukcyjne, ale wymaga manual review.
LLM-as-judge. Trzeci LLM (zwykle większy/droższy) ocenia, który response z A vs B jest lepszy. Wymaga kalibracji (czy LLM-judge ma swój bias), ale skaluje się do tysięcy testów.
Per-version metrics, które warto trackować:
- Latency (czas response)
- Cost per call (tokens × pricing)
- Output quality score (LLM-as-judge lub manual)
- Edit ratio (jak dużo finalny output zmienia się od raw output)
- User satisfaction (jeśli prompt jest user-facing)
Anti-patterny
„One mega prompt”. Wszystko w jednym promptcie — generuj brief + draft + meta + schema. Wynik: niska jakość każdego z elementów, brak kontroli, niemożność A/B testing. Aleyda Solis i Kevin Indig konsekwentnie polecają chained prompts — dziel zadanie na kroki, każdy z własnym promptem i własną metryką.
Brak versioning. Prompt w Notion bez historii zmian. Każdy edytuje na żywo. Po pół roku nie wiesz, kiedy prompt zaczął gorzej działać.
Brak metryk per prompt. Nie mierzysz, czy v3 produkuje lepsze meta niż v2. Wybór wersji opiera się na intuicji.
Brak ownership. Prompt jest „team’s”, nikt go nie utrzymuje. Po 6 miesiącach: 3 forki, każdy nieco inny, nikt nie wie, który jest „prawdziwy”.
Akt-as-prefix bez ramy. „Act as senior SEO expert” — to model 2023, dziś LLM-y ignorują role-play prefix bez konkretnej ramy. Zamiast tego: structured input + extraction prompt. Widzimy to też w analizie konkurencji — patrz tekst o analizie konkurencji bez halucynacji.
Kto utrzymuje bibliotekę
W zespołach średniej skali — zwykle senior strateg lub head of content. W większych — dedykowany prompt engineer (mimo że prompt engineering jako specjalizacja nie jest dziś full-time job).
Ważne: ownership musi być jednoosobowe. Komitet utrzymujący bibliotekę = nikt jej nie utrzymuje. SOP wymaga osoby decyzyjnej.
Co warto zrobić w pierwszym kwartale
Krótka lista dla zespołu, który nie ma zorganizowanej biblioteki:
- Audyt — zbierz 20 najczęściej używanych promptów (prawdopodobnie znajdziesz ich więcej, niż sądzisz). Przejrzyj Slacka, Notion, osobiste zakładki team członków.
- Klasyfikacja — które są kandydatami do SOP (re-używane, deterministyczne), które ad-hoc (kreatywne, jednorazowe).
- Wybór narzędzia — Notion + dyscyplina jeśli zespół < 5 osób, Langfuse self-host jeśli większy lub jeśli liczy się audit trail dla klienta.
- Versioning — każdy SOP-prompt dostaje v1, do każdej zmiany v1.1, v2 itd. Historia musi być zachowana.
- Metryki — minimum: edit ratio i koszt per call. Plus: jakościowa ocena na próbie 50 outputów raz na 2 miesiące.
- Ownership — jedna osoba odpowiedzialna za bibliotekę, czas alokowany w ich planning (typowo 4–8h/tydzień).
To jest projekt dwumiesięczny, nie weekendowa robota. ROI: przewidywalność jakości i mniejszy „prompt drift”, którego inaczej nie wykryjesz.
Czego nie pisać
- „Wystarczy zbiór promptów w Google Doc” — w 2026 to nieprofesjonalne, brak metryki = brak optymalizacji
- „Custom GPTs jako library” — brak versioning, brak A/B, brak metryk. Custom GPT to demo tool, nie production library
- „Biblioteka promptów to przewaga konkurencyjna” — sama w sobie nie jest. Workflow + ewaluacja + integracja z toolami to przewaga; sam plik z promptami można zskryptować w godzinę
- „Prompt engineering jako specjalizacja” — w 2026 to higiena pracy, nie odrębny zawód. Widzimy to w tekście o stack kompetencji 2026