7 příkladů system promptů pro produkční aplikace (šablony ke zkopírování pro rok 2026)

Nejlepší příklady system promptů nejsou jednořádkové „jste užitečný asistent“ z tutoriálů. Jsou to konkrétní bloky instrukcí, které zabrání produkční aplikaci, aby se ve dvě ráno zvrhla. V našem vlastním obsahovém pipeline běží více než tucet Claude subagentů a každý řídí system prompt, který jsme opakovaně přepisovali poté, co na Claude Opus 4.8 nebo GPT-5 vypustil bug. Tento článek přeskakuje hračkové ukázky. Dostanete 7 reálných system promptů ke zkopírování, z toho dva přímo z tohoto produkčního stacku, plus 6blokovou anatomii, která stojí pod každým spolehlivým promptem.

Klíčové poznatky

• System prompt jsou trvalé instrukce (role, omezení, formát výstupu, guardrails) nastavené jednou před jakoukoli uživatelskou zprávou.
• Pokud je obsah identický napříč 1 000 požadavky, patří do system promptu; obsah pro jednotlivé požadavky patří do uživatelského tahu.
• Spolehlivý prompt tvoří šest bloků: role, kontext, omezení, formát výstupu, guardrails, příklady.
• Reasoning modely (řada o, GPT-5, Claude Opus 4.5+) chtějí vysokoúrovňové cíle, ne agresivní formulace „MUSÍŠ“.

Co patří do system promptu? 6 stavebních bloků

System prompt je sada trvalých instrukcí, které definují roli, chování, omezení a formát výstupu modelu pro celou relaci — nastavují se jednou před jakoukoli uživatelskou zprávou. Ty spolehlivé sdílejí šest stavebních bloků: role, kontext, omezení, formát výstupu, guardrails a volitelné příklady. Když je máte srovnané, máte v kostce návod, jak napsat system prompt, který přežije produkci.

Tady je, co každý blok dělá.

Na bloku role záleží víc, než to vypadá. Dokumentace Anthropic to říká jasně: nastavení role v system promptu zaměří chování a tón modelu a „i jediná věta udělá rozdíl“. U bloku guardrails si pravidla pro odmítnutí a bezpečnost zaslouží skutečné promyšlení; těm se věnujeme do hloubky v našem průvodci guardrails. A pokud napojujete Claude, Anthropic doporučuje XML tagy (<instructions>, <context>, <input>), které oddělí jednotlivé typy obsahu, aby je model nesplýval.

Tady je kostra připravená ke vložení, která všech šest bloků spojuje do jedné šablony:

# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.

# CONTEXT
{Stable facts the model needs on every request.}

# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.

# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}

# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.

# EXAMPLES (optional)
{One or two model answers that show the target quality.}

Šest bloků změní pocit v zadání. Tohle je jen vrstva system promptu. Pro širší techniky (few-shot, chain-of-thought, řetězení promptů) se podívejte do našeho průvodce prompt engineering a do samotného system promptu je nemíchejte. Session system prompt se také liší od repozitářového souboru s trvalými instrukcemi na úrovni projektu, jako je CLAUDE.md, který řídí celý codebase, ne jednu API session.

7 příkladů produkčních system promptů (připravené ke zkopírování)

Tady je 7 příkladů system promptů, které můžete ještě dnes vložit do parametru system nebo zprávy developer. Každý míří na reálnou práci (agent, RAG, support, coding, JSON, QA obsahu, překlad) a každý ukazuje, proč jeho klíčové bloky existují. Poslední dva běží v našem vlastním pipeline. Repozitáře uniklých promptů Cursor a Devin dokazují poptávku; co ale nikdo neposílá, je anotace vysvětlující, proč je každý blok na svém místě.

1. Autonomní agent

Zúžte roli, rozepište pravidla pro nástroje a dejte mu stop podmínku, aby nemohl donekonečna smyčkovat.

You are a research agent. Your only job is to answer the user's
question using the provided tools.

TOOLS: web_search, read_url, calculator.

RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.

STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
  human and explain why.

Proč to funguje: úzká role plus explicitní stop podmínka jsou tím rozdílem mezi agentem, který úlohu dokončí, a tím, který ve smyčce pálí tokeny. Tohle je jádro osvědčených postupů pro system prompty agentů.

2. RAG / Retrieval Q&A

Celé umění retrievalu je zabránit modelu, aby odpovídal z vlastní paměti. Jedno pravidlo to zařídí.

You answer questions using ONLY the context provided below.

CONTEXT
{retrieved_chunks}

RULES
- If the answer is not in the context, say: "I don't have that
  in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].

OUTPUT
Two to four sentences, plain text, with citations.

Proč to funguje: „pouze z kontextu“ plus formát citace je nejlevnější hlídka proti halucinacím, kterou pro RAG system prompt napíšete.

3. Zákaznický support bot

Tón, eskalační cesta a tvrdé pravidlo ohledně peněz udrží support bot užitečný, aniž by sliboval věci, na které nemá.

You are a support agent for Northwind's billing team. Be warm,
brief, and factual.

CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.

CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.

GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
  human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.

Proč to funguje: refund guardrail a eskalační fallback zastaví dva způsoby selhání, kvůli kterým se support boti stahují z produkce.

4. Coding asistent

Omezte formát výstupu a verze a přimějte ho vysvětlit postup, než začne editovat.

You are a coding assistant for a Next.js 15 + TypeScript codebase.

RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.

If a request is ambiguous, ask one clarifying question before editing.

Proč to funguje: „diff, ne celé soubory“ plus version ceiling udrží asistenta uvnitř vašeho stacku. Design promptů pro coding agenty je téma dost hluboké na vlastního průvodce, takže tento příklad držíme stručný.

5. Strukturovaná data / extrakce JSON

Dejte schéma do bloku formátu výstupu a zakažte prózu. To je vzor pro spolehlivé strukturované výstupy.

You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.

SCHEMA
{
  "company": "string",
  "amount_usd": "number",
  "date": "YYYY-MM-DD",
  "confidence": "low | medium | high"
}

RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.

Proč to funguje: doslovné schéma plus „pouze platný JSON“ pokaždé porazí popsaný formát. Pro vzory vynucování nad rámec promptu (validace JSON schématu, extrakce přes nástroje) se podívejte do našeho průvodce strukturovanými výstupy.

6. Content-QA / validační agent (z našeho produkčního pipeline)

Tenhle běží v našem vlastním stacku. System prompt našeho validátoru je příkladem negativních omezení: říká modelu přesně, co NEmá psát, a pak skript pravidla doslova kontroluje.

You are a content QA agent. You check one blog draft against a
fixed style contract.

BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"

FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
  per 500 words of body.

ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
  exits non-zero on any hit. If it fails, the post does not publish.

Proč to funguje: číslovaný seznam zakázaných slov plus grep jsou vymahatelné způsobem, jakým „vyhýbej se buzzwordům“ nikdy není. Model se může hádat s pocitem; s nenulovým exit kódem se hádat nemůže.

7. Překladový agent (z našeho produkčního pipeline)

Také náš. Prompt překladatele je kontrakt o formátu výstupu a úplnosti se sebekontrolou, kterou model provádí nad vlastním výstupem.

You are an expert translator. You translate ONE blog post into ONE
target language.

COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.

DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
  "karşılaştırma" (Turkish), or "developpement" instead of
  "développement" (French), the translation is WRONG. Re-do it.

If you cannot meet the contract, report the problem. Do not ship a
truncated post.

Proč to funguje: kontrakt úplnosti plus konkrétní příklad špatného výstupu zachytí tichá selhání, která vágní věta „překládej přesně“ propustí.

Co jsme se naučili při provozu system promptů v produkci

Tři bugy system promptů v našem vlastním pipeline nás naučily víc než jakákoli stránka dokumentace. Všechny tři vzešly z instrukcí, které zněly dobře, ale nebyly specifické ani ověřitelné. Tady je, co se rozbilo napříč našimi 16+ Claude subagenty, a přesná oprava, která pokaždé zabrala. Vzor je vždy stejný: měkká pravidla se ignorují, specifická a externě kontrolovaná pravidla platí.

Bug zakázané slovní zásoby. Celé týdny model vracel do návrhů leverage a robust, ať jsme prosili sebelépe. Měkká věta „vyhýbej se buzzwordům“ nezmohla nic. Opravou byl příklad #6: číslovaný seznam zakázaných slov uvnitř promptu plus skript, který grepne výstup a při jakémkoli zásahu skončí nenulovým kódem, k tomu strop 3 pomlčky na 1 000 slov. Poučení: vágní omezení se ignorují; číslovaná, externě ověřená omezení platí.

Bug diakritiky. Náš překladatel tiše chrlil ASCII pro turečtinu, francouzštinu a španělštinu. Z karşılaştırma se stalo karsilastirma a nikdo si toho nevšiml, dokud na to neupozornil rodilý čtenář. Opravou byla tabulka nativních znaků v promptu, explicitní příklad špatného výstupu a grep po spuštění (nula nativních znaků znamená přeložit znovu). Poučení: dejte modelu konkrétní příklad selhání, ne jen pravidlo.

Bug stabilního ID. Tohle je ten drahý. System prompt, který při každém překladu znovu odvozoval lokalizovaný slug, přiměl vydavatele razit druhý živý dokument na příspěvek. 13. 6. 2026 jsme odeslali 54 duplicitních živých dokumentů a zveřejněné jsme je zrušili až 5. 7. 2026 — tři týdny rozdělené odkazové síly a příznaků duplicitního obsahu. Oprava: explicitně zafixujte identitu a stávající ID používejte doslovně. System prompt, který nedeterministicky regeneruje vlastní identifikátory, posílá duplicity; ten náš orazil 54 živých dokumentů, než jsme ID zafixovali.

Jaké jsou nejčastější chyby system promptů?

Nejčastější chyby system promptů jsou instrukce čitelné jako zeď textu, protichůdná pravidla, čistě negativní formulace, cpát kontext pro jednotlivé požadavky do statického promptu a vynechat fallback. U modelů z roku 2026 přibyla nová: agresivní VELKÁ PÍSMENA a formulace „MUSÍŠ“ teď u Claude Opus 4.5+ příliš spouštějí.

Tady je rychlý seznam oprav:

• Zeď textu. Oprava: rozdělte ji do šesti bloků a stabilní obsah dejte na začátek.
• Protichůdné instrukce. Oprava: jedno pravidlo na řádek; konflikty vyřešte před odesláním.
• Čistě negativní formulace. Oprava: říkejte, co dělat, ne jen čemu se vyhnout.
• Přemíra VELKÝCH PÍSMEN a „MUSÍŠ“. U novějších modelů Anthropic se to obrátí proti vám. Jejich dokumentace teď říká, že tam, kde byste napsali „KRITICKÉ: MUSÍŠ použít tento nástroj“, můžete použít běžnou formulaci jako „Tento nástroj použij, když“. Rada z roku 2025 je teď ta chyba.
• Dynamický kontext ve statickém promptu. Data pro jednotlivé požadavky nechte v uživatelském tahu. Co kam patří je disciplína sama o sobě; pokrývá ji náš průvodce context engineering.
• Žádný fallback. Vždy definujte odmítnutí a eskalační cestu.
• Ignorování délky a nákladů. Delší prompty zvyšují latenci a náklady na tokeny při každém volání; zkraťte je na to, co si místo zaslouží.

Pro základy srozumitelnosti instrukcí je článek o osvědčených postupech od OpenAI stále solidní kontrolní seznam.

Jak system prompt testovat a iterovat?

Testujte system prompt stejně jako kód. Sestavte malou zlatou sadu vstupů s očekávanými výstupy a při každé změně proti nim assertujte odpověď modelu. A/B otestujte dvě verze promptu na stejných vstupech a nechte tu, která projde více kontrolami. Asserty pokaždé porazí okometrické posuzování.

Minimální eval smyčka vypadá takto:

# pseudo eval loop
for case in golden_set:
    out = model(system=PROMPT, user=case.input)
    assert is_valid_json(out)              # format check
    assert case.expected_field in out      # content check
    if case.no_context:
        assert "I don't have that" in out  # refusal check
# ship the prompt version that passes the most cases

Grep z příkladu #6 je nejlevnější assert, který spustíte: nic nestojí a nikdy se neunaví. Až vaše knihovna promptů přeroste hrstku, verzujte a testujte prompty se skutečnými nástroji pro správu promptů, místo abyste kopírovali mezi soubory. Pointa je v jakékoli škále stejná: nikdy neměňte produkční prompt bez kontroly, která vám řekne, jestli jste ho zlepšili, nebo zhoršili.

System prompt vs user prompt vs developer message

System prompt nastavuje pevné chování; user prompt nese úkol pro daný požadavek; developer message je role reasoning modelů OpenAI, která drží instrukce na úrovni aplikace a v řetězci velení stojí nad uživatelskými zprávami. Anthropic místo zprávy role: "system" používá top-level parametr system. Tady je trojí rozdělení, které konkurence obvykle přehlíží.

OpenAI je ohledně pořadí explicitní: „developer messages jsou instrukce poskytnuté vývojářem aplikace, upřednostněné před uživatelskými zprávami“. Takže pokud se uživatel pokusí přepsat pravidla vaší aplikace, developer message v řetězci velení vyhraje.

Potřebují reasoning modely jiné system prompty? (2026)

Ano. Reasoning modely jako řada o od OpenAI, GPT-5 a Claude Opus 4.5+ chtějí vysokoúrovňové cíle, ne skripty krok za krokem. OpenAI přirovnává reasoning model ke staršímu kolegovi, kterému svěříte detaily, zatímco model GPT se chová jako junior potřebující explicitní instrukce.

Toto pojetí mění způsob, jakým prompt píšete. Pro reasoning model uveďte cíl a omezení a „nechte je, ať si detaily vyřeší“; pro model GPT kroky rozepište. Přílišná specifikace reasoning modelu ho často zhorší, nezlepší.

Strana Claude má vlastní posun pro rok 2026. Protože Opus 4.5+ lépe reaguje na system prompt, starý zvyk vršit CRITICAL: a MUST ho teď přespouští. Tlumte tento jazyk na běžnou formulaci. Jedna poznámka k nákladům: stabilní, znovu používaný obsah dejte na začátek promptu, aby mohl zabrat prompt caching a zkrátit latenci opakovaných volání. A pokud váš reasoning model dělá práci krok za krokem, chain-of-thought prompting je vlastní téma s vlastním průvodcem, takže ho tu nebudeme učit znovu.

Jak k tomu přistupuje Techsy

V Techsy stavíme agentské systémy pro B2B klienty a validátor s překladatelem výše běží v tomto produkčním stacku. S každým system promptem zacházíme jako s kódem: verzujeme ho, testujeme proti zlaté sadě a nezpochybnitelná pravidla vynucujeme skriptem, ne nadějí. Pokud posouváte LLM funkci z dema do produkce a chcete pomoct s AI integrací, získejte bezplatnou konzultaci.

O autorovi

Mert Batur Gurbuz je spoluzakladatelem Techsy.io, kde tým nasazuje AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Studuje na University of Birmingham a píše o stacku nástrojů pro LLM, který tým Techsy skutečně používá v produkci.

Spoluzakladatel, Techsy.io, University of Birmingham · LinkedIn

Často kladené otázky

Co je system prompt?

System prompt je sada trvalých instrukcí nastavených jednou, před jakoukoli uživatelskou zprávou, které definují roli, chování, omezení a formát výstupu modelu pro celou relaci. Je to pevná vrstva „jak se chová“ a zůstává identická, zatímco uživatelské zprávy pro jednotlivé požadavky se mění každý tah.

Jaký je rozdíl mezi system promptem a user promptem?

System prompt je pevné „jak se chová“, identické napříč každým požadavkem; user prompt je „co udělat“ pro daný požadavek. Jednoduché pravidlo: pokud by obsah byl identický napříč 1 000 požadavky, patří do system promptu, a cokoli, co se mění s každým voláním, patří do uživatelského tahu.

Co je developer message versus system prompt?

Reasoning modely OpenAI (řada o, GPT-5) přijímají zprávu developer místo zprávy system. Nese instrukce na úrovni aplikace, které v řetězci velení stojí nad uživatelskými zprávami, takže vyhraje, pokud se uživatel pokusí přepsat vaše pravidla. Anthropic udržuje jeden top-level parametr system namísto zprávy založené na roli.

Jak dlouhý by system prompt měl být?

Tak krátký, jak to jde, přičemž stále pokrývá roli, omezení, formát výstupu a guardrails. Příliš dlouhé prompty zvyšují náklady na tokeny a latenci při každém volání a u Claude Opus 4.5+ mohou přespouštět dodatečné uvažování. Pokud musí být stabilní prompt dlouhý, dejte znovu používaný obsah na začátek, aby prompt caching náklady vykompenzoval.

Fungují system prompty stejně v ChatGPT/GPT a Claude?

Stejný koncept, odlišná mechanika. OpenAI používá roli system nebo developer uvnitř pole zpráv, zatímco Anthropic používá samostatný top-level parametr system a upřednostňuje XML tagy pro oddělení instrukcí, kontextu a příkladů. Instrukce se mezi poskytovateli přenášejí; zapojení a formátovací konvence ne.

Lze system prompt změnit uprostřed konverzace?

Přes API při každém volání znovu posíláte celý payload zpráv, takže technicky vzato můžete system prompt mezi tahy vyměnit. Ale změna uprostřed konverzace může narušit kontinuitu a zmást model ohledně jeho vlastních pravidel. Upřednostněte nastavení jednou, nebo cíleně vyměňte za odlišný prompt pro konkrétní úkol.

Mám v system promptu používat XML tagy, nebo markdown?

Anthropic doporučuje pro Claude XML tagy, které oddělí instrukce, kontext a příklady, aby je model nesplýval. Modely OpenAI zvládají markdown a prosté nadpisy dobře. Přizpůsobte se konvenci poskytovatele, místo abyste oběma vnutili jeden styl, a ať vyberete cokoli, držte to v rámci jednoho promptu konzistentní.

Potřebují reasoning modely jiné system prompty?

Ano. Reasoning modely chtějí vysokoúrovňové cíle, jako když briefujete staršího kolegu, ne mikrořízení krok za krokem. Vykašlete se na agresivní VELKÁ PÍSMENA a jazyk „MUSÍŠ“, které přespouštějí novější modely jako Claude Opus 4.5+, uveďte cíl a guardrails a nechte model naplánovat cestu k němu.

Z jakých částí se skládá dobrý system prompt?

Šest bloků: role, kontext, omezení, formát výstupu, guardrails nebo fallbacky a volitelně pár příkladů. Role a omezení odvedou většinu práce; blok formátu výstupu zajišťuje, že odpovědi jsou parsovatelné; guardrails definují, co se děje na okrajích. Příklady stojí za přidání jen tehdy, když cílovou kvalitu těžko popíšete slovy.