Como Escrever Prompts para Criadores de Aplicações com IA (com Exemplos Antes e Depois)

Um bom prompt para um criador de aplicações com IA descreve o produto, não o código: quem o usa, o que faz passo a passo, que dados guarda e quem tem permissão para ver o quê. Depois de existir uma primeira versão, peça uma alteração específica de cada vez, diga o que deve manter-se igual e descreva os problemas como “fiz X, esperava Y, obtive Z”. Estes três hábitos resolvem a maioria dos resultados desapontantes.

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

Porque é que pedir algo a um criador de aplicações é diferente de conversar com uma IA

Quando faz uma pergunta a um assistente de conversação, um prompt vago recebe uma resposta vaga e segue em frente. Quando pede algo a um criador de aplicações com IA, a resposta é um programa a correr. Cada lacuna na sua descrição é preenchida com uma suposição, e essas suposições tornam-se código, tabelas de base de dados e ecrãs com que depois tem de viver ou que tem de desfazer.

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

O que incluir num primeiro prompt

Antes de escrever seja o que for, responda a estas perguntas. Cada uma fecha uma lacuna que a IA adivinharia.

Incluir	Porque importa	Exemplo
O produto numa frase	Define o enquadramento de todas as decisões seguintes	“Um site de marcações para uma barbearia com duas cadeiras”
Quem o usa	Decide os ecrãs e o tom	“Clientes de passagem em telemóveis, e o proprietário num portátil”
O fluxo principal, passo a passo	A coisa que tem de funcionar primeiro	“Escolher um serviço, escolher uma hora, indicar nome e telefone, receber uma confirmação”
Os dados que guarda	Torna-se o desenho da base de dados	“Serviços, marcações, clientes”
Quem pode ver ou alterar o quê	Decide o início de sessão e as permissões	“Só o proprietário vê todas as marcações”
Aspeto e estilo, de forma breve	Evita um estilo genérico por defeito	“Escuro, simples, botões grandes”
O que deixar de fora por agora	Mantém a primeira versão pequena	“Sem pagamentos nem avaliações, para já”

Da última linha, de que muitas vezes não se fala, é a mais subestimada. Dizer o que não quer impede a IA de acrescentar um blogue, uma página de preços e um formulário de newsletter que nunca pediu.

Antes e depois: o primeiro prompt

Antes:

Faz-me uma aplicação para o meu ginásio.

O criador tem de adivinhar tudo: são membros ou funcionários? Aulas de grupo ou treino personalizado? Pagamentos? Vai obter algo que parece um site de ginásio e não faz nada do que precisa.

Depois:

Construa uma aplicação de marcação de aulas para um pequeno estúdio de yoga. Os membros veem as aulas desta semana (nome, professor, hora, lugares disponíveis), reservam um lugar e podem cancelar até duas horas antes. Os membros registam-se com e-mail e palavra-passe. A proprietária do estúdio inicia sessão para acrescentar aulas, ver quem está inscrito e marcar presenças. Guarde aulas, membros e reservas numa base de dados. Design calmo e claro que funcione bem em telemóveis. Sem pagamentos por agora.

A segunda versão continua curta. Limita-se a responder às perguntas da tabela acima.

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

Muitas vezes obtém melhores resultados se descrever o que deve acontecer em vez de como construir.

Antes:

Acrescente um useEffect que vá buscar as reservas e um componente modal para editar.

Depois:

Quando a proprietária clicar numa reserva, abra um painel onde possa alterar a hora ou cancelá-la. As alterações devem aparecer de imediato na lista.

O primeiro prompt impõe à IA uma técnica específica que pode não encaixar na forma como a aplicação está construída. O segundo indica-lhe o resultado e deixa-a escolher a abordagem certa para o código que já escreveu. Se for programador e tiver uma preferência forte, diga-a, mas acompanhe-a com o resultado.

Seja concreto nas regras

As regras de negócio são onde as aplicações construídas com IA mais costumam falhar, porque são óbvias para si e invisíveis para a IA. Escreva-as por extenso.

Limites: “Um membro pode ter no máximo três reservas futuras.”
Prazos: “Os cancelamentos fecham duas horas antes do início da aula.”
Casos-limite: “Se uma aula estiver cheia, mostre um botão de lista de espera em vez de Reservar.”
Permissões: “Os professores podem ver a presença das suas próprias aulas, mas não as de outros professores.”

Cada uma destas regras cabe numa frase. Se deixar qualquer uma de fora, a aplicação ou não a cumprirá ou inventará a sua própria versão.

Depois da primeira versão: uma alteração de cada vez

Quando algo já estiver a correr na pré-visualização, passe de descrever o produto inteiro para pedir alterações pequenas e verificáveis.

Antes:

O design não está bem, a reserva não funciona como deve e quero uma vista de calendário e e-mails.

Depois (como quatro mensagens separadas):

Quando reservo o último lugar de uma aula, a aula continua a mostrar “1 lugar disponível”. Deve mostrar “Esgotada” e ocultar o botão Reservar.

Acrescente uma vista semanal de calendário na página de horários, com uma coluna por dia. Mantenha a vista de lista atual como opção.

Torne os cartões das aulas mais compactos em telemóveis: menos margem interior, nome do professor na mesma linha da hora.

Envie ao membro um e-mail de confirmação quando reservar.

Porque é que isto funciona:

Cada alteração é suficientemente pequena para a IA a acertar numa só passagem.
Pode testar cada uma antes de avançar.
Se uma correr mal, pode reverter apenas esse passo sem perder os outros.

Diga o que deve manter

Quando pede uma alteração a algo que já funciona, diga o que não pode mudar. Esta é a forma mais fácil de evitar regressões (coisas que funcionavam e deixaram de funcionar depois de uma edição).

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

O mesmo se aplica aos dados: “Acrescente um campo de número de telefone aos membros. Não remova nem renomeie nenhum campo existente.”

Use capturas de ecrã e texto exato

Expressões como “a coisa no topo” são ambíguas. A maioria dos criadores de aplicações com IA aceita imagens, e uma captura de ecrã com uma pequena nota é mais rápida do que um parágrafo de descrição.

Anexe uma captura de ecrã e diga “o botão assinalado a vermelho sobrepõe-se ao menu em telemóveis”.
Cole o texto exato de qualquer mensagem de erro em vez de o parafrasear.
Cite as etiquetas do ecrã exatamente: “o botão Guardar alterações na página de Definições”.

Para erros concretos, use esta estrutura:

Na página de marcações, cliquei em Cancelar numa reserva para amanhã. Esperava que desaparecesse 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.

O nosso guia sobre como depurar uma aplicação construída com IA aprofunda este ponto.

Planeie primeiro as alterações grandes

Para tudo o que toque em muitas partes da aplicação (acrescentar contas de utilizador a uma aplicação que não tinha, acrescentar pagamentos, alterar a forma como os dados estão estruturados), peça um plano antes de qualquer alteração de código.

Antes de alterar seja o que for, explique como acrescentaria contas de equipa: que tabelas novas, que páginas mudam e o que acontece aos utilizadores existentes. Ainda não edite código.

Leia o plano. Se houver um mal-entendido, corrigir um parágrafo custa muito menos do que corrigir uma funcionalidade já terminada. Muitos criadores têm um modo dedicado para isto; na Mythex é o modo Plan, a par de Build e Ask.

O que evitar

Evitar	Porquê	Em vez disso
“Melhora isto” / “Faz com que chame mais a atenção”	Não há alvo, por isso a IA altera coisas ao acaso	Nomeie a alteração: “mais espaço entre as secções, títulos maiores”
Um prompt gigante com dez funcionalidades	Os erros acumulam-se; difícil de testar	Uma funcionalidade por mensagem
Colar chaves de API no chat	As chaves ficam no histórico do chat	Use os segredos ou as definições de ambiente do criador
Discutir com um resultado avariado	Cada correção se acumula sobre o erro	Reverta e reformule
Especificar código que não compreende	Fixa uma solução pouco adequada	Descreva o comportamento que pretende
Pedir “segurança de nível empresarial”	Não significa nada de concreto	Liste as regras reais: quem pode ver o quê

Sobre as chaves de API: se precisar de um serviço de pagamentos 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 uma novidade.

Modelos de prompts reutilizáveis

Adapte estes modelos substituindo as partes entre parênteses retos.

Nova aplicação:

Construa um [tipo de aplicação] para [quem]. Eles [fluxo principal, passo a passo]. [Segundo tipo de utilizador] inicia sessão para [o que faz]. Guarde [dados] numa base de dados. [Aspeto e estilo]. Deixe de fora [coisas para mais tarde].

Nova funcionalidade:

Acrescente [funcionalidade] à página [página]. Quando [utilizador] fizer [ação], [o que deve acontecer]. Só [quem] pode [fazer isto]. Mantenha [coisas existentes] como estão.

Alteração de design:

Na página [página], altere [elemento específico] para [alteração específica]. Mantenha [o que se mantém]. Verifique se fica bem num ecrã da largura de um telemóvel.

Erro:

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

Pergunta sem alterações:

Não altere nenhum código. Explique como funciona [parte da aplicação] e onde são guardados os [dados].

Escrever uma especificação mais longa

Em projetos maiores, pode ajudar escrever primeiro um briefing de uma página e colá-lo como prompt inicial: os utilizadores, os fluxos principais, os dados, as regras e o que está fora do âmbito. Pode até pedir a uma IA que o ajude a redigi-lo; o nosso guia sobre como escrever um PRD com IA explica como. Mantenha apenas 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 pormenores que ajudam:

Modos Build, Plan e Ask. Use Plan para alterações grandes ou arriscadas e Ask quando quiser uma explicação sem edições.
Pontos de verificação. Depois de cada alteração bem-sucedida, a Mythex guarda um ponto de verificação, e Reverter para este ponto numa resposta repõe o projeto nesse estado. Também pode editar uma mensagem anterior e reenviá-la para experimentar outro prompt a partir desse ponto.
Cartão de segredos. Quando o agente precisa de uma chave de API, pede-a através de um cartão no chat, para que o valor fique guardado como segredo do projeto e não escrito na sua mensagem.
Imagens. Anexe capturas de ecrã ou maquetes e o agente irá analisá-las.

A documentação tem uma breve página sobre prompts eficazes e outra sobre iterar sem reconstruir. Se estiver a começar do zero, como criar uma aplicação com IA percorre um projeto completo, e como desenhar uma aplicação com bom aspeto com IA aborda os prompts para o acabamento visual.

Perguntas

Quão longo deve ser um prompt para um criador de aplicações com IA?

Para a primeira versão, um parágrafo de quatro a oito frases costuma chegar: quem usa a aplicação, o fluxo principal, os dados que guarda e quem pode ver o quê. Depois disso, prompts mais curtos que pedem uma alteração de cada vez funcionam melhor do que os longos.

Devo dizer à IA qual a framework ou linguagem a usar?

Só se tiver um motivo, como um programador que vá ficar com o código ou um serviço que só funciona com uma determinada stack. Caso contrário, descreva o produto e deixe o criador escolher valores por defeito sensatos.

Porque é que a IA continua a alterar coisas que eu não pedi?

Normalmente porque o prompt era demasiado amplo (“melhora isto”) ou não disse o que deve manter. Indique exatamente o que alterar, diga o que deve ficar igual e peça uma alteração por mensagem.

É melhor corrigir um mau resultado com mais prompts ou recomeçar?

Se a última alteração piorou as coisas, volte à versão anterior e reformule, em vez de empilhar correções por cima. Comece um projeto novo apenas quando a própria ideia tiver mudado.