Seus Prompts de IA Estão Secretamente Falhando

A culpa geralmente recai sobre o modelo. Os usuários assumem que o GPT-4o, Claude 3.5 ou os recursos nativos do Cursor são muito limitados, estão cheios de bugs ou simplesmente "ainda não chegaram lá." Uma análise de 2.236 solicitações reais de codificação de IA diz o contrário: o ponto de falha está quase inteiramente do nosso lado do teclado.

Em 2.236 solicitações, a pontuação média de qualidade ficou em 4,3 de 10 quando medida em relação às melhores práticas de redação de solicitações da OpenAI e da Anthropic. Não é um caso isolado, nem apenas alguns iniciantes se atrapalhando — esta é a forma como a maioria das pessoas está interagindo com ferramentas de IA de nível profissional hoje em dia. Os modelos são capazes; as instruções não são.

O conjunto de dados inclui solicitações de desenvolvedores em atividade, entusiastas de no-code e pessoas criando aplicativos completos dentro de ferramentas como Cursor, Windsurf e Cline. Um pedido típico: “crie um portfólio avançado para mim.” Sem pilha de tecnologia, sem páginas, sem componentes, sem restrições. O usuário tinha uma imagem mental clara; a IA recebeu um desejo vago e teve que adivinhar.

Essa lacuna entre o desejo e a instrução se transforma em três falhas concretas. Você perde tempo em intermináveis idas e vindas, pois o modelo precisa reverter a engenharia do que você quis dizer. Você queima dinheiro enquanto modelos de “pensamento” mais novos trabalham por 10 a 30 minutos em tarefas pouco claras. O pior de tudo é que você perde a confiança no seu próprio trabalho quando suposições quebradas estão escondidas dentro de um código que parece funcionar perfeitamente.

Um aluno usando um modelo de longo prazo como “GBD5 Codex Medium” assistiu enquanto ele processava por 10 minutos a frase “Este projeto utiliza Supabase. Podemos conectar seu servidor MCP, por favor?” antes que finalmente voltasse com uma pergunta esclarecedora. Isso não é mágica da IA; é uma assinatura de $200 por mês pagando para ficar confuso.

Para entender com que frequência isso acontece, reuni a documentação seca e dispersa da OpenAI e da Anthropic, além de suas anotações de pesquisa sobre provocações eficazes. Em seguida, resumi em 15 princípios concretos, desde "seja explícito sobre as restrições" até "mostre exemplos do que você deseja", e avaliei cada uma dessas 2.236 provocações em relação a eles. Os resultados foram brutais—e explicam por que suas provocações de IA continuam falhando secretamente, mesmo quando o código compila.

Grandes modelos de linguagem não leem mentes; eles leem texto. Eles se comportam menos como colegas psíquicos e mais como intérpretes ultra-literais que apenas entendem o que você realmente diz, não o que você queria dizer em sua cabeça. Quando 75% de 2.236 solicitações falham apenas por falta de clareza, o problema não é inteligência, são instruções faltando.

A OpenAI e a Anthropic lançaram diretrizes de prompt por um motivo. Suas equipes de pesquisa mostram repetidamente que os modelos têm melhor desempenho quando você especifica função, tarefa, restrições e formato. Robin Ebers destilou essa enxurrada em 15 princípios e os testou rigorosamente contra prompts reais; a parte “brutal” é quantos usuários ignoram esses fundamentos.

Pense em cada solicitação como a definição de um espaço de interpretação. "Construir um portfólio" oferece ao modelo uma vasta área de busca com milhões de possíveis resultados. Cada detalhe adicional que você adiciona diminui esse espaço e reduz as chances de a IA se desviar para algo que você nunca quis.

Os usuários, por sua vez, chegam com uma especificação interna vívida: a pilha, a atmosfera, os recursos indispensáveis. Na cabeça deles, estão pedindo um site elegante de uma única página em Next.js com animações, validação de e-mail e componentes Shadcn. Na tela, digitam "construa um portfólio avançado para mim" e esperam que o modelo faça a engenharia reversa de sua imaginação.

Olhe para a diferença entre esses dois prompts:

• 1“Crie um portfólio para mim.”
• 2"Crie um portfólio de uma única página em Next.js com três projetos, formulário de inscrição por email validado, um botão para alternar entre modo claro e escuro, e componentes Shadcn."

Ambos se sentem semelhantes ao humano que “sabe o que quer dizer.” Para o modelo, eles são universos diferentes. O segundo colapsa o espaço de interpretação de forma tão agressiva que você troca cinco iterações frustrantes e 45 minutos por uma resposta sólida em cerca de 10.

Setenta e cinco por cento dos pedidos do mundo real analisados por Robin Ebers falharam por um motivo simples: não eram claros. As pessoas achavam que estavam dando instruções; na verdade, estavam lançando desejos vagos a um sistema que só entende o que você especifica.

Considere o pedido real que ele recebe de seu feed: "crie um portfólio avançado para mim." Isso é tudo o que o modelo recebe. Sem pilha tecnológica, sem layout, sem conteúdo, sem usuário-alvo, sem restrições.

Os detalhes em falta se acumulam rapidamente. A IA tem que adivinhar o básico como: - Next.js, React ou HTML simples? - Página única ou múltiplas páginas? - Quais seções: herói, sobre, habilidades, projetos, contato? - Algum sistema de design como Shadcn, Tailwind ou Material UI? - Recursos funcionais: validação de e-mail, modo escuro, animações, CMS?

A pessoa por trás daquela solicitação quase certamente conhece essas respostas. Ela simplesmente nunca diz ao modelo, então ele escolhe sua própria interpretação. Você então olha para um modelo genérico e pensa que a IA “não entende”, quando na verdade você nunca disse o que “é”.

Contrastando isso com uma versão concreta: “Construa um portfólio de uma página em Next.js com três projetos, validação de e-mail, um interruptor de modo escuro e utilize componentes Shadcn.” Agora o modelo tem uma tarefa específica: framework, contagem de páginas, lista de recursos e biblioteca de UI todos definidos. Há muito menos margem para desviar para algo que você não pretendia.

Isso é exatamente o que a OpenAI e a Anthropic descrevem em seus guias de prompts e pesquisas. A própria documentação da OpenAI sobre Engenharia de Prompts | OpenAI API enfatiza a especificidade, a estrutura e as restrições explícitas por um motivo: cada detalhe ausente se torna uma suposição que o modelo precisa inventar.

O custo aparece na sua linha do tempo. A análise da Ebers descobriu que o que deveria ser um único prompt de 10 minutos frequentemente se transforma em cinco prompts ao longo de aproximadamente 45 minutos de idas e vindas. Você corrige a pilha, depois o layout, depois os componentes, então o conteúdo, e, por fim, os casos extremos — coisas que você poderia ter definido desde o início.

Multiplique esse padrão ao longo de um dia de trabalho e você estará perdendo horas reestruturando algo que nunca precisava ter acontecido. O modelo não está tendo um desempenho abaixo do esperado; seu pedido está subespecificando. Quanto mais complexa e "avançada" for sua solicitação, maior será a lacuna entre o desejo e a instrução, resultando em tempo, dinheiro e impulso reais perdidos.

Modelos como GPT-4o, Claude 3.5 Sonnet e os novos codificadores baseados no GPT-4o “agentes” mudaram silenciosamente a forma como a IA funciona. Você não está mais conversando com uma caixa de autocomplete glorificada; você está ativando um trabalhador autônomo que pode planejar, navegar, editar arquivos e refatorar código por 10 a 30 minutos de cada vez.

Esse longo horizonte é o ponto de venda: você entrega uma tarefa complexa e observa a IA passar por documentos, APIs e casos limites enquanto faz outra coisa. Mas a mesma funcionalidade transforma comandos vagos em um triturador de dinheiro, porque esses modelos gastarão alegremente todo o seu orçamento de computação vagando no escuro antes de admitir que não te entendem.

Modelos de chat mais antigos cometiam seus erros instantaneamente. Você recebia uma resposta ruim em três segundos, suspirava e tentava novamente. Com agentes e "artefatos" que permanecem e iteram, o modo de falha muda: você recebe 600 segundos de um silencioso e confiante erro antes que o modelo surja com uma única pergunta confusa.

Um dos alunos de Robin Ebers aprendeu isso da maneira mais difícil. Ele perguntou a um programador avançado e experiente: “Este projeto usa Superbase. Podemos conectar seu servidor MCP, por favor?” Então ele assistiu o AI “pensar” por 10 minutos seguidos, apenas para receber a resposta: “Só quero ter certeza de que estamos na mesma sintonia.”

Aqueles 10 minutos não foram gastos conectando o Supabase, testando conexões ou gerando artefatos utilizáveis. Foram gastos tentando adivinhar o que "servidor MCP" significava neste contexto, quais arquivos de projeto deveriam ser editados e o que "conectar" realmente deveria fazer. Todo aquele tempo de computação paga não trouxe nada além de uma pergunta esclarecedora que ele poderia ter respondido no pedido original.

Agora faça esse mapeamento para suas assinaturas. Se você está pagando entre R$ 100 e R$ 1.000 por mês por agentes baseados em GPT-4, Claude ou ferramentas como Cursor e Windsurf, cada instrução imprecisa se torna uma confusão que gera custos. Você não está pagando para o IA funcionar; você está pagando para que ele fique confuso, em blocos de 10 minutos, repetidamente.

A maioria dos desastres de IA não começa com uma mensagem de erro vermelha. Eles começam com uma marca de verificação verde, uma construção bem-sucedida e uma pequena e invisível curva errada que o modelo tomou porque seu comando deixou espaço demais para adivinhações.

Chame isso de falha silenciosa. Você solicita "autenticação de usuário com JWTs", a IA cria um fluxo funcional, o formulário de login se comporta bem, os tokens são emitidos, tudo parece perfeito. Duas semanas depois, você percebe que nunca lidou com a rotação de tokens, a expiração de atualização ou o armazenamento seguro, e agora seu sistema de autenticação "funcional" é um incidente de segurança prestes a acontecer.

Modelos de linguagem preenchem lacunas com suposições confiantes. Quando seu prompt não define a arquitetura, o fluxo de dados ou as restrições, o modelo as inventa. Ele pode optar por sessões no servidor em vez de JWT, REST em vez de WebSockets, ou um layout de banco de dados de único locatário onde você precisava de uma separação estrita entre múltiplos locatários. O aplicativo inicializa, os testes passam, a demonstração vai bem — e você acaba de consolidar uma fundação que nunca realmente aprovou.

É aí que o dano se multiplica. Você não envia apenas um recurso com falhas; você empilha novos recursos em cima daquela suposição oculta. Você conecta mais endpoints na camada de autenticação errada, espalha o modelo de dados com falhas por 20 arquivos e copia e cola padrões que a IA inventou no primeiro dia. Quando alguém percebe, a "correção" significa desfazer dezenas de commits, não apenas ajustar uma única função.

A dívida técnica resultante de falhas silenciosas não parece dívida à primeira vista. Parece progresso. Os sprints se concluem, os PRs são mesclados, os gráficos de velocidade sobem. Somente quando você tenta adicionar algo não trivial — controle de acesso baseado em funções, suporte a múltiplas regiões, um provedor de faturamento diferente — é que você descobre que a arquitetura original gerada por IA o colocou em uma situação complicada.

Um prompt que falha de forma barulhenta é irritante, mas manejável. Você vê o rastreamento de empilhamento, vê o código sem sentido, regride e tenta novamente. Um prompt que falha de forma silenciosa se comporta como uma mina terrestre: tudo parece seguro até que você pise na combinação exata de caso extremo, solicitação de recurso ou exigência de escala que desencadeia a explosão.

Uma vez que isso acontece, você não apenas perde tempo. Você perde confiança em sua base de código assistida por IA. Cada saída aparentemente "boa" agora vem com um asterisco: que suposições ocultas o modelo incorporou desta vez?

A maior parte dos conselhos sobre prompts de IA soa como uma vaga intuição. Robin Ebers seguiu o caminho oposto: ele examinou documentos extensos da OpenAI e da Anthropic, e então testou suas ideias em 2.236 prompts de codificação reais. Dessa colisão surgiram 15 princípios de clareza brutalmente práticos.

No núcleo estão algumas movimentações enganadoramente simples. Defina um papel: “Você é um desenvolvedor Python sênior que se especializa em FastAPI e Postgres.” Especifique a tarefa: “Refatore este manipulador para ser totalmente assíncrono e adicione validação de entrada.” Envolva o código e os arquivos do usuário em delimitadores como `###` ou ```"""``` para que o modelo possa separar instruções, contexto e artefatos.

A pesquisa de ambos os laboratórios continua a girar em torno da estrutura. Modelos como o GPT-4o e o Claude 3.5 Sonnet processam solicitações como longas sequências de tokens; uma secação clara reduz a margem de erro. Ao marcar blocos como “CONTEXTO”, “CÓDIGO EXISTENTE” e “A FAZER”, você comprime o espaço de busca de interpretações plausíveis e reduz alucinações. Exemplos de poucos disparos—3 a 5 rotulados como “ruins” versus “bons” trechos—ancoram ainda mais o padrão.

Alguns dos 15 princípios podem parecer quase enfadonhos até que você veja os modos de falha que eles previnem. Ebers enfatiza: - Restrições de estado: limites de desempenho, regras de segurança, stack tecnológico - Defina saídas: “Retorne um único arquivo .ts” ou “Responda apenas com JSON” - Exija raciocínio: “Pense passo a passo, depois mostre apenas a diferença final”

Essas ações correspondem à orientação pública como Engenharia de Prompt - Anthropic, que enfatiza papéis explícitos, delimitadores e exemplos como ferramentas de primeira classe. Elas funcionam não por “tornar o modelo mais inteligente”, mas por alinhar sua intenção com a forma como os transformers realmente processam tokens.

A maioria dos desenvolvedores não vai memorizar 15 regras, então a Ebers criou um verificador que faz isso por você. Cole um prompt e ele te dá uma nota—4,8/10 em uma demonstração—apontando para contextos ausentes, exemplos faltando e objetivos imprecisos, antes que você gaste 20 minutos de tempo autônomo de agente.

Conheça o Prompt Coach, a resposta de Robin Ebers para as falhas silenciosas de prompts que se escondem em seu fluxo de trabalho. Em vez de adivinhar se suas instruções serão compreendidas, você cola seu prompt em um formulário simples na web e recebe um veredito baseado em pesquisa da OpenAI e Anthropic, não em intuições. Sem login, sem paywall, apenas uma auditoria de prompt brutalmente honesta em menos de um minuto.

Sob o capô, o Prompt Coach avalia seu prompt com base em 15 princípios de clareza extraídos de documentações técnicas densas que a maioria dos desenvolvedores nunca lerá. Ele não se limita a fornecer um único número; ele divide essa pontuação por categoria: quão clara é a sua tarefa, quanto contexto você fornece, se você especifica formato, estilo, restrições e critérios de sucesso. Cada ponto fraco vem acompanhado de sugestões concretas de reescrita.

Pense nisso como uma verificação pré-voo para a codificação de IA. Antes de entregar um funcionamento autônomo de 30 minutos para o GPT-4o ou Claude 3.5 Sonnet, você passa o prompt pelo Prompt Coach e identifica o problema de “construa um portfólio avançado para mim” antes que isso consuma seus créditos. A ferramenta sinaliza questões como falta de pilha tecnológica (Next.js vs. HTML simples), detalhes de UX ausentes (alternar modo escuro, componentes Shadcn) ou requisitos vagos que costumam acionar aqueles desvios de 10 minutos “só para esclarecer”.

O Prompt Coach não apenas insiste; ele reescreve. Sob cada princípio, ele propõe uma linguagem mais precisa e até variantes completas de “tente este prompt em vez disso” que incorporam especificidades: número de páginas, fontes de dados, regras de validação, casos limite e expectativas de teste. Você copia, ajusta e só então clica em enter no Cursor, Windsurf ou em sua IDE de IA favorita.

Aqueles 2.236 prompts que Ebers analisou não ficaram em uma planilha. Eles alimentam a pontuação e os exemplos do Prompt Coach, refletindo padrões de milhares de codificadores de IA reais. Quando seu prompt retorna com uma pontuação de 4,8 em 10, você não está sendo avaliado com base em teoria; você está vendo como suas instruções se comparam a um problema muito comum e muito caro.

A maioria das pessoas começa com algo como: “Crie uma página de aterrissagem para um seminário.” Curtos, confiantes e quase inúteis. Robin Ebers insere esse tipo exato de solicitação no Prompt Coach, espera 30 segundos e a ferramenta devolve um veredicto brutal: 4,8 de 10.

O Prompt Coach não apenas exibe uma nota baixa; ele explica o porquê. Sob “Seja claro sobre o que você quer”, ele classifica o prompt com 4/10 e aponta tudo o que está faltando: Sobre o que é o seminário? Quando e onde ele acontece? O que deve estar na página? O que o texto deve dizer para realmente fazer as pessoas se inscreverem?

Outro princípio, “Mostre o que você está buscando,” recebe uma nota ainda mais baixa, 3/10. A ferramenta destaca a total falta de exemplos: nenhum site de referência, nenhuma direção de design, nenhuma vibe. Ela o empurra a decidir se você quer “simples e limpo,” “colorido e ousado,” “profissional,” ou “divertido” antes que o modelo escreva uma única linha de HTML.

O feedback não se limita à crítica. O Prompt Coach sugere passos concretos a seguir: compartilhe um link para uma landing page que você gosta ou descreva um estilo, como "o site da Apple — limpo e simples", ou "cores vibrantes com botões grandes". Esse pequeno empurrão transforma uma ideia nebulosa em um briefing que um designer — ou modelo — pode realmente executar.

Role para baixo e a verdadeira mágica aparece sob “Experimente este prompt em vez disso.” A ferramenta reescreve seu pedido vago em um template estruturado, com espaços reservados onde seus detalhes ausentes devem ir. Pode parecer: “Crie uma página de destino responsiva para um seminário sobre [TÓPICO] que acontecerá em [DATA] em [LOCALIZAÇÃO] direcionado a [PÚBLICO].”

O prompt atualizado continua com requisitos explícitos de conteúdo e layout: seção principal com um título e subtítulo, visão geral da programação, biografias dos palestrantes, FAQ e um formulário de inscrição conectado à validação de e-mail. Também incorpora dicas de estilo: “Utilize um design semelhante ao [SITE DE REFERÊNCIA], focando em [TRAÇOS DE ESTILO] como layout minimalista, tipografia grande e botões de CTA de alto contraste.”

Você passa de um desejo de cinco palavras para uma especificação em várias linhas que qualquer modelo moderno—GPT-4o, Claude 3.5 Sonnet, seja o que for—pode seguir quase mecanicamente. Sem suposições, sem "É isso que você quis dizer?" após 10 minutos de frustração autônoma.

Esses 60 segundos extras no início substituem meia hora de tentativas, reescritas e dúvidas silenciosas sobre se sua base de código está apoiada em uma mina terrestre escondida. A especificidade não é polimento; é seguro.

O aprimoramento avançado começa onde “seja mais específico” termina. Uma vez que suas instruções atingem os 15 princípios de Robin Ebers, você desbloqueia uma segunda camada: técnicas que moldam como modelos como o GPT-4o e o Claude 3.5 Sonnet realmente pensam, e não apenas o que eles produzem.

Primeiro, temos o prompting de Cadeia de Pensamentos. Quando você diz ao modelo "pense passo a passo" ou "mostre seu raciocínio antes da resposta final", a precisão em tarefas complexas—refatores de múltiplos arquivos, fluxos de autenticação complicados, migrações de dados desafiadoras—aumenta drasticamente. Tanto a OpenAI quanto a Anthropic demonstram que o raciocínio explícito reduz as taxas de erro em problemas difíceis, especialmente quando um único erro silencioso pode comprometer toda a base de código.

Você pode levar isso adiante com estruturas de raciocínio organizadas. Em vez de um vago “explique,” force estágios: “1) reitere o objetivo, 2) liste as restrições, 3) proponha 2–3 opções, 4) escolha uma e justifique, 5) produza o código.” Esse modelo transforma um palpite único em uma mini revisão de design incorporada em cada resposta.

A seguir está o prompting de poucos exemplos: forneça 3–5 pares de entrada/saída concretos para definir estilo, formato e profundidade. Para um bot de revisão de código, você pode mostrar exemplos que sempre incluem: - Um resumo breve - Uma lista numerada de problemas - Sugestões de código concretas

Uma vez que esses exemplos estejam acima do seu pedido real, o modelo se ajusta a esse padrão. Você obtém um tom de comentário consistente, uma estrutura de markdown estável e menos “surpresas” nas interpretações ao conectar o sistema ao CI.

A estrutura em torno dessas técnicas é importante. As melhores práticas baseadas em pesquisa dizem: comece com um papel como "Você é um engenheiro sênior de TypeScript e revisor de segurança", em seguida, separe as seções com delimitadores claros, como `### CONTEXTO`, `### CÓDIGO`, `### TAREFA`, cercados por `"""` ou ``` cercas. Os delimitadores separam as instruções dos conteúdos, para que o modelo não confunda onde seu prompt termina e os dados do usuário começam.

Se você quer ir mais longe do que o vídeo do Robin e os 15 princípios, recursos como **O Guia Definitivo para Prompt Engineering em 2025 - Lakera** catalogam esses padrões, além de truques mais novos, como a solicitação consciente de ferramentas e exemplos aumentados por recuperação. Combinados com o Prompt Coach, esses movimentos profissionais transformam solicitações de "espero que isso funcione" em sistemas reproduzíveis.

Seus prompts agora precisam de uma checagem pré-voo tão seriamente quanto seu código. Modelos como GPT-4o e Claude 3.5 Sonnet gastarão alegremente de 10 a 30 minutos e parte da sua assinatura em um desejo vago, apenas para lhe entregar um código que parece correto. Trate a elaboração de prompts como um artefato de engenharia, não como uma mensagem de chat descartável.

Comece com a etapa um: Defina o objetivo e o contexto. Esclareça o que você está fazendo, por quê e para quem. “Refatorar isso para desempenho” se torna “Refatorar esta rota API do Next.js para lidar com 10x o tráfego, manter os tempos de resposta abaixo de 200ms e preservar os tipos existentes em TypeScript.”

Em seguida, especifique o formato e a pilha tecnológica. Os modelos fazem suposições erradas quando você pula esta parte. Diga exatamente o que deve ser gerado e onde isso estará:

• 1Tecnologia: “Next.js 14, App Router, TypeScript, Tailwind, Supabase”
• 2“Retorne um único componente React”, “Apenas SQL” ou “Patch estilo Diff”
• 3Restrições: caminhos de arquivos, frameworks, bibliotecas e padrões de codificação.

Então forneça um exemplo. A abordagem de poucos exemplos ainda se destaca. Cole um componente “bom”, manipulador de API ou arquivo de teste e diga: “Combine esta estrutura, nomes e estilo de comentários”, ou link para um repositório público e descreva o que deve ser espelhado.

Adicione um papel ou persona para que o modelo otimize os trade-offs corretos. “Você é um engenheiro full-stack sênior otimizando para segurança e manutenibilidade a longo prazo” resulta em decisões diferentes de “Você é um prototipador ágil otimizando para velocidade.” Use isso para direcionar a atenção para testes, documentação ou desempenho.

Antes de você pressionar enter, passe o rascunho por um verificador como o Prompt Coach. A ferramenta de Robin Ebers avalia seu prompt com base em 15 princípios extraídos de pesquisas da OpenAI e Anthropic, e então mostra exatamente por que seu “8/10 na sua cabeça” é na verdade um 4.8/10 na realidade — e como corrigi-lo.

A solicitação intencional e estruturada ultrapassou a linha de truque de festa para se tornar um nível básico de alfabetização no desenvolvimento de IA. Seu próximo passo: pegue seu último prompt "construa algo para mim", passe pelo Prompt Coach, envie a versão melhorada e compartilhe o quanto sua pontuação—e seu resultado—aumentaram.

Qual é a razão mais comum para a falha dos prompts de IA?

De acordo com uma análise de mais de 2.200 prompts, 75% falham porque não são claros ou específicos o suficiente. Os usuários costumam escrever 'desejos' vagos em vez de instruções detalhadas.

Como solicitações ruins desperdiçam dinheiro com modelos de IA mais recentes?

Novos modelos de IA autônomos podem trabalhar por minutos ou horas em um único comando. Um comando pouco claro faz com que a IA desperdice tempo de computação caro tentando interpretar sua solicitação, consumindo seu orçamento de assinatura sem produzir resultados úteis.

O que é uma 'falha silenciosa' na indução de IA?

Uma falha silenciosa ocorre quando uma IA produz código que parece funcionar corretamente, mas é baseado em uma suposição falha devido a um comando vago. Isso cria uma 'bomba-relógio' de dívida técnica que pode levar semanas para consertar depois.

Como posso melhorar instantaneamente meus prompts de IA?

Seja hiper-específico. Em vez de 'construir um portfólio', defina a tecnologia (Next.js), páginas (página única), recursos (modo escuro, validação de e-mail) e componentes (Shadcn) para dar à IA menos margem para interpretação equivocada.