Como escrever prompt para Lovable, Bolt e v0: descreva a tela em blocos em vez de pedir ‘um app bonito’

Fala aí, beleza? Se tu já abriu o Lovable, o Bolt ou o v0 e mandou um ‘cria um app bonito de pedidos’, sabe o que volta: uma tela genérica, com cara de template e cheia de texto de preenchimento 😅

Isso acontece porque o pedido vago deixa a IA decidir TUDO: o que aparece, onde aparece e como a tela se comporta quando algo dá errado

A saída é quebrar o pedido em blocos, tipo uma ficha técnica

Em vez de uma frase solta, o prompt vira objetivo da tela, layout, componentes, dados de exemplo, estados e restrições de estilo

No fim tem um modelo pronto pra copiar e o ajuste de cada uma das três ferramentas 🙂

O que ter em mãos antes de escrever o prompt

Antes de abrir o chat, tu precisa saber o que está construindo

Parece óbvio, né? Mas é literalmente a primeira boa prática da documentação do Lovable, junto com construir uma parte de cada vez, ser específico e iterar

Se liga no que separar:

• A tela que você quer agora: uma só, não o app inteiro
• A arquitetura desejada: a ajuda do Bolt manda começar por ela, ou seja, dizer quais ferramentas e frameworks você quer usar
• Uma referência visual (opcional): o guia de vibecoding do v0 diz que screenshot, rascunho ou até a foto de um desenho em guardanapo guiam o layout mais rápido que parágrafos de descrição
• O back-end fica pra depois: no Lovable, a recomendação é conectar o Supabase só quando o front-end estiver estável

Não tem design nenhum em mãos? Tranquilo, dá pra descrever a tela sem design só com palavras, e os blocos abaixo servem exatamente pra isso

Como montar o prompt em blocos, passo a passo

A ideia é a mesma de uma ficha técnica: cada bloco responde uma pergunta que, se ficar em branco, a IA responde do jeito dela

Os exemplos abaixo são didáticos, montados pra uma tela de pedidos de uma loja pequena de bolos. Troca pelo teu caso

1. Objetivo da tela: quem usa e pra quê?

Começa dizendo quem abre essa tela e o que a pessoa precisa resolver ali

Objetivo: tela de pedidos do dia para a dona de uma loja pequena de bolos.
Ela abre pelo celular de manhã para ver o que precisa entregar hoje
e marcar cada pedido como entregue.

O erro comum deste passo: descrever o app inteiro (login, financeiro, relatórios…) no mesmo prompt

O Lovable manda construir uma parte por vez, e o blog do Bolt orienta deixar fluxos diferentes em prompts separados. Uma tela, um objetivo

2. Layout: quais regiões existem e qual o nome de cada uma?

Aqui tu divide a tela em regiões e dá NOME pra cada uma

Por quê? Porque o v0 lembra o nome que você dá pra uma parte da tela (‘o hero’, ‘o formulário de contato’), e prompts futuros que usam esse nome caem no lugar certo

Layout (mobile primeiro):
- "o cabeçalho": nome da loja e data de hoje
- "o resumo": três números lado a lado (total, entregues, pendentes)
- "a lista de pedidos": ocupa o resto da tela, rolagem vertical

O erro comum deste passo: não nomear nada e depois não ter como apontar ‘aquela parte de cima ali’ na hora de corrigir

3. Componentes: o que tem dentro de cada região?

Agora lista o que existe em cada região que tu nomeou

Componentes:
- Em "a lista de pedidos", cada item é um card com: nome do cliente,
  sabor do bolo, horário de entrega e um botão "Marcar como entregue".
- Pedidos entregues ficam no fim da lista, com o card esmaecido.

O erro comum deste passo: citar o componente sem dizer o que vai dentro dele (‘uma lista de pedidos’ e só). Aí a IA inventa os campos

4. Dados de exemplo: com o que a tela vai nascer preenchida?

Esse bloco é proposta do método, não uma regra das documentações

A lógica é simples: se tu não der dados, a tela tende a sair vazia ou com texto genérico, e fica difícil julgar se o layout funciona de verdade

Dados de exemplo (fictícios):
- Ana Souza, bolo de cenoura com chocolate, entrega 10:00, pendente
- Carlos Lima, bolo de fubá, entrega 11:30, pendente
- Beatriz Rocha, bolo de limão, entrega 09:00, entregue

O erro comum deste passo: usar nomes e textos curtíssimos. Coloca pelo menos um nome comprido pra ver se o card quebra 😛

5. Estados: como a tela fica vazia, com erro e carregando?

Outro bloco que é proposta do método, não recomendação documentada pelas ferramentas

Mas é ele que separa protótipo de tela usável: o que aparece quando não tem pedido, quando a lista não carrega, e enquanto carrega?

Estados:
- Vazio: mensagem "Nenhum pedido para hoje" com um ícone simples.
- Erro: aviso "Não foi possível carregar os pedidos" e botão "Tentar de novo".
- Carregando: três cards cinza no formato dos cards reais.

O erro comum deste passo: descrever só o caminho feliz, com tudo dando certo

6. Restrições de estilo e limites: o que pode e o que NÃO pode?

Aqui entra o que o Lovable chama de Constraints: limites rígidos, o que não fazer

E vale a regra do Bolt: os resultados ficam mais precisos quando você diz explicitamente o que deve e o que não deve mudar. A mesma ajuda manda não esperar que o LLM tenha bom senso

Restrições:
- Estilo limpo, fundo claro, uma cor de destaque (rosa) só nos botões.
- Fonte legível no celular, nada menor que o texto padrão.
- NÃO criar login, menu lateral nem outras telas.
- NÃO conectar banco de dados agora; use apenas os dados de exemplo.

O erro comum deste passo: achar que ‘design moderno’ é restrição. Não é, é só mais um pedido vago

7. Planejar antes de construir: como rodar o prompt?

Antes de gerar código, joga o prompt no modo de planejamento

No Lovable, o Plan mode serve pra raciocinar, comparar abordagens e revisar o plano antes de qualquer mudança, e ele nunca modifica o projeto

No Bolt, o Plan Mode planeja e tira dúvidas sem mexer no código. Quando tu manda implementar o plano, ele troca sozinho pro Build Mode

Lê o plano e confere se cada bloco apareceu nele. Faltou algum? Corrige o plano, não o código

O erro comum deste passo: pular direto pra geração e descobrir no código que a IA entendeu outra coisa

O modelo completo pra copiar:

Juntando tudo, fica assim:

Objetivo da tela: (quem usa, em que situação e o que precisa resolver aqui)

Layout:
- "nome da região 1": (o que fica ali e onde)
- "nome da região 2": (o que fica ali e onde)

Componentes:
- Em "nome da região": (componentes e o que vai dentro de cada um)

Dados de exemplo (fictícios):
- (registro 1)
- (registro 2)
- (registro 3, com um texto bem comprido)

Estados:
- Vazio: (o que aparece)
- Erro: (mensagem e ação)
- Carregando: (como a tela fica)

Restrições:
- (regras de estilo)
- NÃO (o que a IA não pode fazer ou mudar)

São os mesmos seis blocos dos passos acima. Se tu já definiu a arquitetura, como a ajuda do Bolt sugere, cabe uma linha de stack no topo do objetivo

No Lovable, dá pra encaixar os blocos no formato rotulado que a doc de prompting sugere: Context (o objetivo da tela, com quem usa e em que situação), Task (layout, componentes, dados e estados), Guidelines (preferências de estilo) e Constraints (os ‘NÃO’)

O próprio Lovable chama esse formato de ‘rodinhas de treinamento’ e admite que parece verboso, mas deixa pouco espaço pra mal-entendido

No Bolt, a doc sugere seções como contexto, design e esclarecimentos, então dá pra agrupar do mesmo jeito

No v0, anexa a referência visual junto: a doc de screenshots diz que screenshot mais especificação escrita dá os melhores resultados, então a imagem não dispensa os blocos de dados, estados e restrições

Como verificar: abre a prévia e confere bloco por bloco. As regiões estão lá com os nomes certos? Cada componente tem os campos pedidos? Os dados de exemplo aparecem? E os três estados existem?

O que faltar vira o próximo prompt, um por vez 😀

Por que a ferramenta ignorou parte do prompt e como corrigir na iteração

Na maioria das vezes, o pedido estava grande demais ou caiu no lugar errado. A correção é diminuir o pedido e apontar onde ele vale

Bora ver os casos que as próprias documentações cobrem:

A IA não fez tudo o que foi pedido:

Causa: muita coisa num prompt só

Solução: o Bolt orienta quebrar o pedido em partes menores e pedir uma mudança por vez

Dois prompts seguidos e nada de chegar perto:

Causa: a conversa foi pra um caminho ruim e cada correção empilha em cima dele

Solução: no v0, cada mudança vira uma versão nova, e o guia recomenda voltar pelo dropdown de versões quando dois prompts seguidos não te aproximaram do resultado

Pediu ‘desfaz’ por texto e piorou:

Causa: pedir pra IA desfazer é pedir mais uma mudança

Solução: o blog do Bolt manda usar a restauração de versão em vez de pedir undo, e também não clicar repetidamente em Attempt fix. Tome cuidado com esse botão!

A mudança caiu no lugar errado:

Causa: o prompt não disse onde mexer

Solução: depende da ferramenta

• Bolt: aponta a tela e o arquivo específicos no prompt
• v0: usa o nome que tu deu pra seção (‘mude a lista de pedidos’), ou ativa o Design mode pela barra do formulário de prompt, seleciona o elemento e ajusta no painel ou escreve a instrução (aí o v0 anexa um screenshot do elemento)
• Lovable: usa a barra de ferramentas do preview, aponta o elemento e descreve a alteração em linguagem natural

Se o teu caso é ajuste fino no Lovable, tem um post só sobre pedir correções sem refazer o app inteiro

Como prevenir:

• Um fluxo por prompt, com todos os detalhes daquele fluxo juntos
• Fluxos diferentes em prompts separados
• Limpar o contexto com regularidade, como orienta a ajuda do Bolt

Onde Lovable, Bolt e v0 guardam regras fixas, planejam e ajustam a tela

O bloco de restrições de estilo se repete em todo prompt, né? A boa notícia é que dá pra escrever ele uma vez só nas instruções fixas

A tabela mostra onde fica cada coisa. ‘Não coberto’ quer dizer que não há fonte confirmada aqui, não que o recurso não exista

Função	Lovable	Bolt	v0
Regras fixas	Knowledge: workspace (todos os projetos) e project (só o projeto)	Project Prompt (projeto atual) e Global System Prompt (todos), em engrenagem > All project settings > Knowledge > Save prompt	Não coberto
Planejar sem alterar código	Plan mode	Plan Mode, troca sozinho pro Build Mode ao implementar	Não coberto
Ajuste visual apontando o elemento	Barra de ferramentas do preview	Não coberto	Design mode
Referência visual	Não coberto	Não coberto	Screenshot e + > Create from Figma
Ajuda pra estruturar o prompt	Não coberto	Enhance prompt na caixa de chat	Não coberto
Reverter	Não coberto	Restauração de versão	Dropdown de versões

Dois detalhes que valem ouro:

O Chat mode do Lovable também nunca altera código nem dados, então serve pra tirar dúvida sobre o projeto sem risco

E o Create from Figma do v0 analisa o layout e os design tokens, como cores e espaçamento. Se tu já tem o design lá, economiza um baita bloco de restrições

Vídeo de apoio: o outro extremo, tudo num prompt só

Pra contrastar com o método em blocos, este vídeo do canal mostra o outro extremo: tudo pedido num prompt só

Próximo passo: transformar o modelo em regra do projeto

Escolhe UMA tela do projeto que tu está tocando agora e preenche os seis blocos do modelo

Roda primeiro no modo de planejamento (Plan mode no Lovable, Plan Mode no Bolt) e só gera quando o plano bater com o que tu escreveu

Quando a tela estabilizar, pega o bloco de restrições de estilo e move pras instruções fixas: Knowledge no Lovable, Project Prompt no Bolt

A partir daí, cada tela nova precisa só de objetivo, layout, componentes, dados e estados. O estilo já vem junto 😀

Até o próximo post!

Perguntas frequentes

O Enhance prompt do Bolt substitui escrever os blocos do método?

Não. O Enhance prompt reformata ou expande o texto que você já escreveu pra deixar mais claro e estruturado, mas ele não decide objetivo, layout, componentes ou estados por você. Os blocos continuam sendo seu trabalho antes de usar o Enhance.

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.