O framework role-constraint: a estrutura de duas partes por trás de todo prompt eficaz

Você provavelmente já percebeu: alguns prompts simplesmente funcionam, enquanto outros fazem o Claude virar de cabeça para baixo. A diferença não é sorte. É estrutura.

Depois de trabalhar extensivamente com Claude, identifiquei um padrão que separa prompts mediocres daqueles que realmente entregam resultados. Chamo de framework role-constraint, e é deceptivamente simples: todo prompt eficaz tem duas partes essenciais funcionando juntas.

O que é o framework (e por que importa)

O framework role-constraint consiste em:

1. Role: Quem Claude deveria ser ou como Claude deveria pensar
2. Constraints: As limitações específicas, regras e formato de saída

Essas não são preocupações separadas que você lida casualmente. São as paredes de carga da arquitetura do seu prompt. Quando uma delas está ausente ou mal definida, seus resultados sofrem.

Aqui está o insight crítico: role e constraints trabalham sinergeticamente. O role dá ao Claude um framework cognitivo—uma lente através da qual abordar o problema. Constraints traduzem esse framework em disciplina de saída real.

Sem role, você consegue respostas genéricas. Sem constraints, você consegue dispersão. Juntos, criam precisão.

O componente Role: dando ao Claude uma lente

O role é sua resposta para: "Como Claude deveria pensar sobre isso?"

Não se trata de fazer Claude atuar como um pirata ou um cavaleiro medieval (embora você possa usar esses). É sobre especificar uma perspectiva, nível de experiência ou abordagem cognitiva.

Roles fortes incluem:

• Baseado em expertise: "Você é um arquiteto sênior de sistemas revisando decisões de infraestrutura"
• Consciência de audiência: "Você está escrevendo para desenvolvedores que conhecem Python mas não padrões async"
• Consciência de restrições: "Você é um redator técnico que prioriza clareza sobre abrangência"
• Baseado em processo: "Você é um tutor socrático que guia através de perguntas, não respostas"

O role funciona porque molda como Claude prioriza informação, seleciona vocabulário e estrutura o pensamento. É sua maneira de dizer: pense como essa pessoa pensaria.

Um exemplo concreto. Compare esses dois prompts:

Sem role claro: "Explique arquitetura de nuvem."

Com role: "Você é um CTO explicando arquitetura de nuvem para um conselho de investidores não-técnicos que precisam entender implicações de custo e vantagens competitivas, não detalhes de implementação."

A segunda versão restringe toda a abordagem do Claude. Ele sabe pular a explicação de Docker. Sabe começar com valor de negócio. O role faz esse trabalho.

O componente Constraints: impondo disciplina

Constraints são as regras que mantêm a saída do Claude dentro dos limites. Respondem: "Quais são os limites?"

Constraints eficazes abordam:

• Formato: "Use uma lista com bullets, não prosa" ou "Estruture como: Problema → Solução → Trade-off"
• Escopo: "Foque apenas em preocupações frontend" ou "Cubra apenas resultados Q1 e Q2"
• Profundidade: "Explique em duas frases" ou "Inclua um exemplo detalhado"
• Tom: "Combine com a voz do blog HubSpot: conversacional e baseado em evidências"
• Constraints em constraints: "Se a tarefa é impossível, diga—não finjas"

Constraints evitam o que Claude faz naturalmente: gerar respostas abrangentes e totalmente elaboradas. Isso é uma feature, não um bug. Frequentemente você quer restringir a completude em favor do foco.

Aqui está um exemplo real do meu próprio trabalho. Estava gerando tabelas de comparação de produtos. As tentativas iniciais eram inchadas—colunas demais, linhas que não importavam. A constraint que importava: "Inclua apenas critérios onde os produtos diferem significativamente. Ordene por relevância para a decisão do usuário. Máximo 8 linhas."

Essa constraint forçou priorização. Claude parou de listar cada feature possível e começou a pensar como um editor.

Juntando tudo: exemplos reais de prompts

Deixe-me mostrar como role e constraints interagem na prática.

Exemplo 1: Documentação técnica

Você é um redator técnico que especializa em tornar
tópicos complexos acessíveis para desenvolvedores de nível intermediário.

Ao documentar esse recurso:
- Assuma que leitores conhecem APIs REST mas não message queues
- Use uma estrutura de três partes: O que é → Por que importa → Como usar
- Inclua um exemplo real, não pseudocódigo
- Sinalize qualquer armadilha com uma seção "⚠️ Cuidado"
- Mantenha em menos de 300 palavras

O role diz ao Claude como pensar sobre a audiência e seus gaps. As constraints dizem ao Claude exatamente que forma a saída toma. Nenhum sozinho funcionaria.

Exemplo 2: Marketing de conteúdo

Você é um estrategista de marketing escrevendo para nosso blog.
Sua audiência: founders de startups considerando trocar de nosso competidor.

Escreva essa peça:
- Comece com um problema concreto que eles enfrentam (não features que nos faltam)
- Suporte afirmações com exemplos específicos, não declarações genéricas
- Termine com um próximo passo claro que é low-friction (não "agende uma demo")
- Evite: superlativos, jargão técnico, menções de nossos competidores pelo nome
- Comprimento alvo: 1.200 palavras

Role = perspectiva estratégica + consciência de audiência. Constraints = forma, escopo e conteúdo proibido.

Exemplo 3: Feedback de revisão de código

Você está revisando esse código como um engenheiro sênior que valoriza
pragmatismo sobre perfeição. Você quer ajudar desenvolvedores juniores a aprender.

Forneça feedback como:
1. Uma ou duas observações de alto impacto (não uma lista infindável)
2. Para cada uma: explique o por quê (objetivo de aprendizado) e o como (solução concreta)
3. Destaque uma coisa que fizeram bem
4. Sinalize qualquer coisa que é um problema bloqueador vs. nice-to-have

O role determina sua postura (pragmática, educacional, respeitosa). As constraints determinam a estrutura e profundidade.

Quando o framework quebra (e como corrigir)

A maioria das saídas decepcionantes do Claude rastreiam de volta para definição fraca de role ou constraint.

Se a resposta do Claude é genérica e superficial, geralmente seu role é muito vago. "Você é um assistente prestativo" não é um role—é rendição do framework. Seja específico sobre perspectiva e expertise.

Se a resposta do Claude é dispersa e desfocar, geralmente suas constraints carecem de força. "Escreva sobre mudança climática" é pedir caos. "Escreva um explicador de 400 palavras sobre precificação de carbono voltado para alunos de política, estruturado como: mecanismo → trade-offs → exemplo do mundo real" o restringe.

Se Claude continua interpretando mal sua intenção, geralmente role e constraints estão trabalhando um contra o outro. Uma vez tive um role ("analista financeiro") que continuava empurrando jargão enquanto minhas constraints pediam acessibilidade. Corrigir o role resolveu.

Próximos passos práticos

Para seu próximo prompt, faça uma auditoria contra o framework:

1. Role: Você consegue descrevê-lo em uma frase? É específico o bastante para mudar a resposta do Claude?
2. Constraints: Você tem pelo menos 2-3 constraints ativos? Eles abordam formato, escopo ou profundidade?
3. Compatibilidade: Eles trabalham juntos ou se combatem?

O framework role-constraint não é uma fórmula rígida. É uma lente diagnóstica. Mas descobri que todo prompt que produz confiável e consistentemente resultados de qualidade tem ambas as partes funcionando.

Quando você começar a pensar em termos de role e constraint, vai notar em bons prompts por toda parte. E vai saber exatamente o que consertar quando as coisas saem pela tangente.