Como escrever prompts para construtores de apps com IA (com exemplos de antes e depois)

Um bom prompt para um construtor de apps com IA descreve o produto, não o código: quem o usa, o que essa pessoa faz passo a passo, quais dados ele guarda e quem tem permissão para ver o quê. Depois que a primeira versão existe, peça uma mudança específica por mensagem, diga o que precisa continuar igual e descreva problemas como “fiz X, esperava Y, aconteceu Z”. Esses três hábitos resolvem a maioria dos resultados decepcionantes.

O restante deste guia mostra os padrões em detalhe, com exemplos de antes e depois que você pode adaptar.

Por que pedir algo a um construtor de apps é diferente de conversar com uma IA

Quando você faz uma pergunta a um assistente de chat, um prompt vago gera uma resposta vaga e você segue em frente. Quando você pede algo a um construtor de apps com IA, a resposta é um programa em funcionamento. Cada lacuna na sua descrição é preenchida com um palpite, e esses palpites viram código, tabelas de banco de dados e telas com as quais você então precisa conviver ou desfazer.

Portanto, o objetivo de um prompt não é soar inteligente. É deixar menos decisões importantes ao acaso. Você não precisa de vocabulário técnico para isso. Precisa ser específico sobre o que só você sabe: seus usuários, seu fluxo de trabalho e suas regras.

O que incluir em um primeiro prompt

Antes de escrever qualquer coisa, responda a estas perguntas. Cada uma fecha uma lacuna que a IA, de outra forma, chutaria.

Essa última linha é subestimada. Dizer o que você não quer impede a IA de acrescentar um blog, uma página de preços e um cadastro de newsletter que você nunca pediu.

Antes e depois: o primeiro prompt

Antes:

Faça um app para a minha academia.

O construtor precisa adivinhar tudo: são membros ou funcionários? Aulas coletivas ou personal? Pagamentos? Você vai receber algo que parece um site de academia e não faz nada do que você precisa.

Depois:

Crie um app de reserva de aulas para um pequeno estúdio de yoga. Os alunos veem as aulas da semana (nome, professor, horário, vagas restantes), reservam uma vaga e cancelam até duas horas antes. Os alunos se cadastram com e-mail e senha. O dono do estúdio faz login para adicionar aulas, ver quem está inscrito e marcar presença. Guarde aulas, alunos e reservas em um banco de dados. Design leve e calmo, que funcione bem em celulares. Sem pagamentos por enquanto.

A segunda versão continua curta. Ela apenas responde às perguntas da tabela acima.

Descreva o comportamento, não a implementação

Você muitas vezes obtém melhores resultados descrevendo o que deve acontecer, em vez de como construir.

Antes:

Adicione um useEffect que busque as reservas e um componente de modal para edição.

Depois:

Quando o dono clicar em uma reserva, abra um painel onde ele possa mudar o horário ou cancelá-la. As alterações devem aparecer imediatamente na lista.

O primeiro prompt prende a IA a uma técnica específica que pode não combinar com a forma como o app foi construído. O segundo informa o resultado e deixa a IA escolher a abordagem certa para o código que ela já escreveu. Se você é desenvolvedor e tem uma preferência forte, diga, mas junto com o resultado desejado.

Seja concreto com as regras

Regras de negócio são onde apps feitos com IA mais costumam dar errado, porque são óbvias para você e invisíveis para a IA. Escreva-as por extenso.

• Limites: “Um aluno pode ter no máximo três reservas futuras.”
• Prazos: “Os cancelamentos encerram duas horas antes do início da aula.”
• Casos extremos: “Se a aula estiver lotada, mostre um botão de lista de espera em vez de Reservar.”
• Permissões: “Professores veem a presença das próprias aulas, mas não as de outros professores.”

Cada uma dessas regras cabe em uma frase. Deixar qualquer uma de fora significa que o app ou não vai aplicar a regra, ou vai inventar a própria versão dela.

Depois da primeira versão: uma mudança por mensagem

Quando algo já está rodando na prévia, mude de descrever o produto inteiro para pedir pequenas mudanças que você consiga verificar.

Antes:

O design está estranho, a reserva não funciona direito e quero uma visualização em calendário e e-mails.

Depois (como quatro mensagens separadas):

1. Quando eu reservo a última vaga de uma aula, ela continua mostrando “1 vaga restante”. Deveria mostrar “Lotada” e esconder o botão Reservar.
2. Adicione na página de agenda uma visualização de calendário semanal, com uma coluna por dia. Mantenha a lista atual como opção.
3. Deixe os cards das aulas mais compactos no celular: menos espaçamento interno e o nome do professor na mesma linha do horário.
4. Envie ao aluno um e-mail de confirmação quando ele reservar.

Por que isso funciona:

• Cada mudança é pequena o bastante para a IA acertar em uma tentativa.
• Você pode testar cada uma antes de seguir em frente.
• Se uma der errado, você pode desfazer só aquele passo sem perder as outras.

Diga o que manter

Quando você pedir uma mudança em algo que já funciona, diga à IA o que não pode mudar. Essa é a forma mais fácil de evitar regressões (coisas que funcionavam e quebram depois de uma edição).

Redesenhe o topo da página inicial com um título maior e uma foto à direita. Mantenha a navegação, as cores e tudo abaixo do topo exatamente como está.

O mesmo vale para os dados: “Adicione um campo de telefone aos alunos. Não remova nem renomeie nenhum campo existente.”

Use capturas de tela e texto exato

Expressões como “aquela coisa lá em cima” são ambíguas. A maioria dos construtores de apps com IA aceita imagens, e uma captura de tela com uma breve nota é mais rápida do que um parágrafo de descrição.

• Anexe uma captura de tela e diga “o botão circulado em vermelho sobrepõe o menu no celular”.
• Cole o texto exato de qualquer mensagem de erro, em vez de parafraseá-la.
• Cite os rótulos da tela exatamente: “o botão Salvar alterações na página de Configurações”.

Para bugs, use esta estrutura:

Na página de reservas, cliquei em Cancelar em uma reserva de amanhã. Esperava que ela sumisse da minha lista. Em vez disso, nada aconteceu, e a reserva continua lá depois de atualizar a página. Corrija e verifique se o cancelamento funciona.

Nosso guia sobre como depurar um app feito com IA aprofunda isso.

Planeje primeiro em mudanças grandes

Para qualquer coisa que afete muitas partes do app (adicionar contas de usuário a um app que não tinha, adicionar pagamentos, mudar a estrutura dos dados), peça um plano antes de qualquer mudança no código.

Antes de mudar qualquer coisa, explique como você adicionaria contas de equipe: quais novas tabelas, quais páginas mudam e o que acontece com os usuários existentes. Não edite o código ainda.

Leia o plano. Se ele entender algo errado, corrigir um parágrafo custa muito menos do que corrigir uma funcionalidade pronta. Muitos construtores têm um modo dedicado para isso; na Mythex é o modo Plano, ao lado de Construir e Perguntar.

O que evitar

Sobre chaves de API: se você precisa de um serviço de pagamento ou de e-mail, coloque as chaves nos segredos do projeto, e não no prompt. Veja o que são variáveis de ambiente e segredos se for um conceito novo para você.

Modelos de prompt reutilizáveis

Adapte estes trocando as partes entre colchetes.

Novo app:

Crie um [tipo de app] para [quem]. Eles [fluxo principal, passo a passo]. [Segundo tipo de usuário] faz login para [o que faz]. Guarde [dados] em um banco de dados. [Aparência e estilo]. Deixe de fora [coisas para depois].

Nova funcionalidade:

Adicione [funcionalidade] na página [página]. Quando [usuário] fizer [ação], [o que deve acontecer]. Só [quem] pode [fazer isso]. Mantenha [coisas existentes] como estão.

Mudança de design:

Na página [página], mude [elemento específico] para [mudança específica]. Mantenha [o que manter]. Verifique se fica bem em uma tela com largura de celular.

Bug:

Na página [página], eu [passos]. Esperava [resultado esperado]. Em vez disso, [resultado real, mais o texto exato do erro]. Corrija e verifique se o fluxo funciona.

Pergunta sem mudanças:

Não altere nenhum código. Explique como [parte do app] funciona e onde [dados] são armazenados.

Escrevendo uma especificação mais longa

Em projetos maiores, pode ajudar escrever antes um briefing de uma página e colá-lo como primeiro prompt: os usuários, os fluxos principais, os dados, as regras e o que está fora do escopo. Você pode até pedir ajuda à IA para rascunhá-lo. Nosso guia sobre como escrever um documento de requisitos de produto com IA explica como. Só mantenha o primeiro pedido de construção no fluxo principal e acrescente o resto passo a passo.

Prompts na Mythex

Tudo o que está acima funciona na Mythex. Alguns detalhes que ajudam:

• Modos Construir, Plano e Perguntar. Use Plano para mudanças grandes ou arriscadas, e Perguntar quando quiser uma explicação sem edições.
• Pontos de restauração. Depois de cada mudança bem-sucedida, a Mythex salva um ponto de restauração, e Voltar para este ponto em uma resposta reverte o projeto. Você também pode editar uma mensagem anterior e reenviá-la para testar outro prompt a partir dali.
• Cartão de segredos. Quando o agente precisa de uma chave de API, ele pede por meio de um cartão no chat, para que o valor seja guardado como segredo do projeto e não escrito na sua mensagem.
• Imagens. Anexe capturas de tela ou maquetes e o agente vai analisá-las.

A documentação tem uma página curta sobre prompts eficazes e outra sobre iterar sem recriar. Se você está começando do zero, como criar um app com IA percorre um projeto completo, e como desenhar um app bonito com IA trata de prompts para o acabamento visual.

Perguntas