7 Exemplos de System Prompt para Aplicações em Produção (Modelos Prontos para 2026)

Os melhores exemplos de system prompt não são as frases únicas do tipo «você é um assistente útil» encontradas em tutoriais. São blocos de instruções específicas que impedem que uma aplicação em produção falhe estrondosamente às 2 da manhã. No nosso próprio pipeline de conteúdo, executamos mais de uma dúzia de subagentes Claude, cada um orientado por um system prompt que reescrevemos repetidamente após ter introduzido um erro no Claude Opus 4.8 ou no GPT-5. Este artigo ignora as demonstrações básicas. Receberá 7 system prompts reais, prontos para copiar e colar, dois dos quais retirados diretamente dessa stack de produção, além da anatomia de 6 blocos subjacente a todos os prompts fiáveis.

Principais Conclusões

• Um system prompt consiste em instruções persistentes (função, restrições, formato de saída, salvaguardas) definidas uma vez antes de qualquer mensagem do utilizador.
• Se o conteúdo for idêntico em 1.000 pedidos, coloque-o no system prompt; o conteúdo específico de cada pedido vai na interação do utilizador.
• Seis blocos constroem um prompt fiável: função, contexto, restrições, formato de saída, salvaguardas e exemplos.
• Os modelos de raciocínio (série o, GPT-5, Claude Opus 4.5+) preferem objetivos de alto nível, não uma redação agressiva do tipo «você DEVE».

O Que Entra Num System Prompt? Os 6 Blocos de Construção

Um system prompt é um conjunto de instruções persistentes que definem a função, o comportamento, as restrições e o formato de saída do modelo para toda uma sessão, estabelecidas uma vez antes de qualquer mensagem do utilizador. Os prompts fiáveis partilham seis blocos de construção: função, contexto, restrições, formato de saída, salvaguardas e exemplos opcionais. Coloque-os na ordem correta e terá a versão resumida de como escrever um system prompt que sobrevive à produção.

Eis o que cada bloco faz.

O bloco de função é mais importante do que parece. A documentação da Anthropic afirma claramente: definir uma função no system prompt foca o comportamento e o tom do modelo, e «mesmo uma única frase faz a diferença». Para o bloco de salvaguardas, as regras de recusa e segurança merecem uma reflexão séria; abordamos isso em profundidade no nosso guia de salvaguardas. E se estiver a integrar o Claude, a Anthropic recomenda etiquetas XML (<instructions>, <context>, <input>) para separar cada tipo de conteúdo, para que o modelo não os confunda.

Eis um esqueleto pronto para colar que une os seis blocos num único modelo:

# 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.}

Seis blocos transformam uma «vibe» numa especificação. Esta é apenas a camada do system prompt. Para técnicas mais amplas (few-shot, cadeia de pensamento, encadeamento de prompts), consulte o nosso guia de engenharia de prompts e mantenha-as fora do próprio system prompt. Um system prompt de sessão também difere de um ficheiro ao nível do repositório de instruções persistentes ao nível do projeto, como um CLAUDE.md, que governa toda uma base de código em vez de uma única sessão de API.

7 Exemplos de System Prompt de Produção (Prontos para Copiar e Colar)

Aqui estão 7 exemplos de system prompt que pode colar no seu parâmetro system ou na mensagem developer hoje. Cada um visa uma tarefa real (agente, RAG, suporte, programação, JSON, QA de conteúdo, tradução) e cada um mostra porque é que os seus blocos-chave existem. Os últimos dois funcionam no nosso próprio pipeline. Os repositórios que vazaram prompts do Cursor e do Devin provam a procura; o que ninguém publica é a anotação que explica porque é que cada bloco lá está.

1. Agente Autónomo

Delimite a função estritamente, especifique as regras das ferramentas e dê-lhe uma condição de paragem para que não entre num loop infinito.

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.

Porque funciona: a função restrita mais uma condição de paragem explícita são a diferença entre um agente que termina a tarefa e um que consome tokens num loop. Este é o núcleo das boas práticas de system prompts para agentes.

2. RAG / Perguntas e Respostas por Recuperação

Todo o jogo com a recuperação consiste em impedir que o modelo responda com base na sua própria memória. Uma regra resolve isso.

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.

Porque funciona: «apenas a partir do contexto» mais um formato de citação é a proteção contra alucinações mais barata que pode escrever para um system prompt de RAG.

3. Bot de Suporte ao Cliente

Tom, um caminho de escalonamento e uma regra financeira rígida mantêm um bot de suporte útil sem lhe permitir prometer coisas que não pode cumprir.

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.

Porque funciona: a salvaguarda de reembolso e o fallback de escalonamento impedem os dois modos de falha que levam à remoção dos bots de suporte da produção.

4. Assistente de Programação

Restrinja o formato de saída e as versões, e faça-o explicar antes de editar.

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.

Porque funciona: «diff, não ficheiros completos» mais um teto de versão mantém o assistente dentro da sua stack. O design de prompts para agentes de codificação é suficientemente profundo para merecer o seu próprio guia, por isso mantemos este exemplo conciso.

5. Extração de Dados Estruturados / JSON

Coloque o esquema no bloco de formato de saída e proíba prosa. Esse é o padrão para saídas estruturadas fiáveis.

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.

Porque funciona: um esquema literal mais «apenas JSON válido» supera sempre um formato descrito. Para padrões de aplicação além do prompt (validação de esquema JSON, extração baseada em ferramentas), consulte o nosso guia de saídas estruturadas.

6. Agente de QA de Conteúdo / Validador (do nosso pipeline de produção)

Este executa-se na nossa própria stack. O system prompt do nosso validador é um exemplo de restrições negativas: diz ao modelo exatamente o que NÃO escrever, e depois um script verifica as regras literalmente.

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.

Porque funciona: uma lista proibida enumerada mais um grep é aplicável de uma forma que «evitar jargão» nunca será. O modelo pode discutir com uma «vibe»; não pode discutir com um código de saída diferente de zero.

7. Agente de Tradução (do nosso pipeline de produção)

Também nosso. O prompt do tradutor é um contrato de formato de saída e completude com uma autoverificação que o modelo executa sobre a sua própria saída.

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.

Porque funciona: um contrato de completude mais um exemplo concreto de saída errada deteta as falhas silenciosas que uma linha vaga do tipo «traduza com precisão» deixa passar.

O Que Aprendemos Ao Executar System Prompts em Produção

Três erros de system prompt no nosso próprio pipeline ensinaram-nos mais do que qualquer página de documentação. Todos os três resultaram de instruções que pareciam corretas, mas não eram específicas ou verificáveis. Eis o que falhou nos nossos 16+ subagentes Claude e a correção exata que prevaleceu em cada caso. O padrão é sempre o mesmo: regras vagas são ignoradas; regras específicas e verificadas externamente permanecem.

O erro do vocabulário proibido. Durante semanas, o modelo continuou a inserir leverage e robust nos rascunhos, não importa quão educadamente pedíssemos. Uma linha suave do tipo «evitar jargão» não fez nada. A solução foi o Exemplo nº 6: uma lista proibida enumerada dentro do prompt mais um script que faz grep na saída e sai com erro em qualquer ocorrência, com um limite de 3 travessões por 1.000 palavras. A lição: restrições vagas são ignoradas; restrições enumeradas e verificadas externamente permanecem.

O erro dos diacríticos. O nosso tradutor emitia silenciosamente ASCII para turco, francês e espanhol. karşılaştırma saía como karsilastirma, e ninguém notou até que um leitor nativo sinalizou o problema. A solução foi uma tabela de caracteres nativos no prompt, um exemplo explícito de saída errada e um grep pós-execução (zero caracteres nativos significa retraduzir). A lição: dê ao modelo um exemplo concreto da falha, não apenas uma regra.

O erro do ID estável. Este é o caro. Um system prompt que rederivava um slug localizado em cada retradução fazia com que o editor criasse um segundo documento ativo por publicação. Lançámos 54 documentos ativos duplicados em 2026-06-13 e só os despublicámos em 2026-07-05, três semanas de divisão de autoridade de link e sinais de conteúdo duplicado. A solução: fixar a identidade explicitamente e reutilizar o ID existente textualmente. Um system prompt que regenera os seus próprios identificadores de forma não determinística lança duplicados; o nosso criou 54 documentos ativos antes de fixarmos o ID.

Quais São os Erros Mais Comuns de System Prompt?

Os erros mais comuns de system prompt são instruções em parede de texto, regras contraditórias, redação apenas negativa, despejar contexto específico de cada pedido num prompt estático e omitir um fallback. Nos modelos de 2026, há um novo: redação agressiva em MAIÚSCULAS e do tipo «você DEVE» agora ativa excessivamente o Claude Opus 4.5+.

Eis a lista rápida de correções:

• Parede de texto. Correção: divida nos seis blocos e coloque o conteúdo estável primeiro.
• Instruções contraditórias. Correção: uma regra por linha; resolva conflitos antes do lançamento.
• Redação apenas negativa. Correção: diga o que fazer, não apenas o que evitar.
• Sobrecarga de MAIÚSCULAS e «DEVE». Nos modelos mais recentes da Anthropic, isto sai pela culatra. A sua documentação agora indica que onde poderia ter escrito «CRÍTICO: Você DEVE usar esta ferramenta», pode usar uma redação normal como «Use esta ferramenta quando...». O conselho de 2025 é agora o erro.
• Contexto dinâmico num prompt estático. Mantenha os dados específicos de cada pedido no turno do utilizador. Saber o que pertence aonde é uma disciplina própria; o nosso guia de engenharia de contexto aborda isso.
• Sem fallback. Defina sempre uma recusa e um caminho de escalonamento.
• Ignorar comprimento e custo. Prompts mais longos adicionam latência e custo de tokens em cada chamada; reduza ao que justifica a sua presença.

Para os básicos de clareza de instruções, o artigo de boas práticas da OpenAI continua a ser uma lista de verificação sólida.

Como Testar e Iterar Num System Prompt?

Teste um system prompt da mesma forma que testa código. Crie um pequeno conjunto de referência de inputs com outputs esperados e afirme a resposta do modelo contra eles em cada alteração. Faça testes A/B de duas versões do prompt nos mesmos inputs e mantenha a que passa mais verificações. As afirmações automáticas superam sempre a inspeção visual.

Um ciclo de avaliação mínimo parece-se com isto:

# 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

O grep no Exemplo nº 6 é a afirmação mais barata que pode executar: não custa nada e nunca se cansa. À medida que a sua biblioteca de prompts cresce para além de alguns itens, versione e teste os seus prompts com ferramentas de gestão de prompts reais em vez de copiar e colar entre ficheiros. O objetivo é o mesmo a qualquer escala: nunca altere um prompt de produção sem uma verificação que lhe diga se o melhorou ou piorou.

System Prompt vs User Prompt vs Mensagem de Developer

Um system prompt define um comportamento fixo; um user prompt transporta a tarefa específica de cada pedido; uma mensagem de developer é a função de modelo de raciocínio da OpenAI que contém instruções ao nível da aplicação, classificadas acima das mensagens do utilizador na cadeia de comando. A Anthropic utiliza um parâmetro system de nível superior em vez de uma mensagem role: "system". Eis a divisão tripla que os concorrentes geralmente ignoram.

A OpenAI é explícita sobre a classificação: «as mensagens de developer são instruções fornecidas pelo developer da aplicação, priorizadas antes das mensagens do utilizador». Portanto, se um utilizador tentar substituir as regras da sua app, a mensagem de developer vence na cadeia de comando.

Os Modelos de Raciocínio Precisam de System Prompts Diferentes? (2026)

Sim. Os modelos de raciocínio como a série o da OpenAI, o GPT-5 e o Claude Opus 4.5+ querem objetivos de alto nível, não scripts passo a passo. A OpenAI compara um modelo de raciocínio a um colega sénior em quem confia para os detalhes, versus um modelo GPT que se comporta como um júnior que precisa de instruções explícitas.

Esta estrutura muda a forma como escreve o prompt. Para um modelo de raciocínio, indique o objetivo e as restrições e «confie neles para resolverem os detalhes»; para um modelo GPT, especifique os passos. Especificar demasiado um modelo de raciocínio muitas vezes piora o resultado, em vez de melhorar.

O lado Claude tem a sua própria mudança em 2026. Como o Opus 4.5+ é mais responsivo ao system prompt, o velho hábito de acumular CRÍTICO: e DEVE agora ativa-o excessivamente. Reduza essa linguagem para uma redação normal. Nota de custo: coloque o seu conteúdo estável e reutilizado no início do prompt para que o caching de prompts possa entrar em ação e reduzir a latência em chamadas repetidas. E se o seu modelo de raciocínio estiver a fazer trabalho passo a passo, o prompting de cadeia de pensamento é um tópico próprio com o seu próprio guia, por isso não o vamos ensinar novamente aqui.

Como a Techsy Aborda Isto

Na Techsy, construímos sistemas de agentes para clientes B2B, e os prompts de validador e tradutor acima executam-se nessa stack de produção. Tratamos cada system prompt como código: versionamo-lo, testamo-lo contra um conjunto de referência e aplicamos as regras não negociáveis com um script em vez de esperança. Se estiver a mover uma funcionalidade LLM de uma demonstração para produção e quiser ajuda com o trabalho de integração de IA, obtenha uma consulta gratuita.

Sobre o Autor

Mert Batur Gurbuz é Co-Fundador da Techsy.io, onde a equipa lança agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Estuda na Universidade de Birmingham e escreve sobre a stack de ferramentas LLM que a equipa da Techsy realmente usa em produção.

Co-Fundador, Techsy.io, Universidade de Birmingham · LinkedIn

Perguntas Frequentes

O que é um system prompt?

Um system prompt é um conjunto de instruções persistentes definidas uma vez, antes de qualquer mensagem do utilizador, que definem a função, o comportamento, as restrições e o formato de saída do modelo para toda a sessão. É a camada fixa de «como se comporta», e permanece idêntica enquanto as mensagens específicas de cada pedido do utilizador mudam em cada turno.

Qual é a diferença entre um system prompt e um user prompt?

O system prompt é o «como se comporta» fixo, idêntico em cada pedido; o user prompt é o «o que fazer» específico de cada pedido. Uma regra simples: se o conteúdo fosse idêntico em 1.000 pedidos, pertence ao system prompt, e tudo o que muda por chamada vai no turno do utilizador.

O que é uma mensagem de developer vs um system prompt?

Os modelos de raciocínio da OpenAI (série o, GPT-5) aceitam uma mensagem developer em vez de uma mensagem system. Contém instruções ao nível da aplicação, classificadas acima das mensagens do utilizador na cadeia de comando, por isso vence se um utilizador tentar substituir as suas regras. A Anthropic mantém um único parâmetro system de nível superior em vez de uma mensagem baseada em funções.

Quão longo deve ser um system prompt?

Tão curto quanto possível, cobrindo ainda assim a função, restrições, formato de saída e salvaguardas. Prompts demasiado longos adicionam custo de tokens e latência em cada chamada e podem ativar excessivamente o raciocínio extra no Claude Opus 4.5+. Se um prompt estável tiver de ser longo, coloque o conteúdo reutilizado primeiro para que o caching de prompts compense o custo.

Os system prompts funcionam da mesma forma no ChatGPT/GPT e no Claude?

Mesmo conceito, mecanismos diferentes. A OpenAI utiliza uma função system ou developer dentro do array de mensagens, enquanto a Anthropic utiliza um parâmetro system separado de nível superior e favorece etiquetas XML para separar instruções, contexto e exemplos. As instruções transferem-se entre fornecedores; a ligação e as convenções de formatação não.

Pode alterar o system prompt a meio da conversa?

Através da API, reenvia a totalidade do payload de mensagens em cada chamada, por isso tecnicamente pode trocar o system prompt entre turnos. Mas alterá-lo a meio da conversa pode quebrar a continuidade e confundir o modelo sobre as suas próprias regras. Prefira defini-lo uma vez, ou troque deliberadamente para um prompt distinto específico da tarefa.

Devo usar etiquetas XML ou markdown num system prompt?

A Anthropic recomenda etiquetas XML para o Claude separar instruções, contexto e exemplos para que o modelo não os confunda. Os modelos da OpenAI lidam bem com markdown e títulos simples. Adapte-se à convenção do fornecedor em vez de impor um estilo em ambos, e mantenha consistente whichever escolher dentro de um único prompt.

Os modelos de raciocínio precisam de system prompts diferentes?

Sim. Os modelos de raciocínio querem objetivos de alto nível, como briefed a um colega sénior, não microgestão passo a passo. Elimine a linguagem agressiva em MAIÚSCULAS e do tipo «você DEVE» que ativa excessivamente modelos mais recentes como o Claude Opus 4.5+, indique o objetivo e as salvaguardas, e deixe o modelo planear o caminho para lá chegar.

Quais são as partes de um bom system prompt?

Seis blocos: função, contexto, restrições, formato de saída, salvaguardas ou fallbacks e, opcionalmente, alguns exemplos. A função e as restrições fazem a maior parte do trabalho; o bloco de formato de saída é o que torna as respostas analisáveis; as salvaguardas definem o que acontece nas extremidades. Os exemplos valem a pena adicionar apenas quando a qualidade alvo é difícil de descrever por palavras.