Voltar para o Blog
IA na Prática33 / 50
  1. 01Bem-vindo: o que você vai conseguir fazer no fim desta série
  2. 02O que é uma IA que conversa, em português claro
  3. 03O que dá e o que não dá pra fazer com IA hoje
  4. 04Claude, ChatGPT, Gemini: qual a diferença e por que vamos usar o Claude
  5. 05Os três jeitos de falar com a IA: site, app e terminal
  6. 06A mentalidade certa: você é o maestro, a IA é o instrumento
  7. 07Criando sua conta e instalando o app do Claude
  8. 08Sua primeira conversa: como pedir bem (o prompt)
  9. 09Anexando arquivos, imagens e PDFs
  10. 10Projetos no Claude: guardando contexto que não se perde
  11. 11Artifacts: quando o Claude monta um documento ou um mini-app pra você
  12. 12Memória, instruções e estilo: ensinando o Claude do seu jeito
  13. 13Planos, limites e custo: o que é grátis e quando vale pagar
  14. 14O que é o "terminal" e por que ele não dá medo
  15. 15Abrindo o terminal no Mac e no Windows (e no Linux)
  16. 16Cinco comandos de sobrevivência: pwd, ls, cd, mkdir, cat
  17. 17Como o computador organiza tudo: pastas, arquivos e caminhos
  18. 18Instalando o Node.js (e o que é isso, afinal)
  19. 19npm: a "loja de peças" gratuita do mundo dev
  20. 20Instalando o VS Code: seu editor de código (e por que precisa de um)
  21. 21O que é o Git e por que todo projeto sério usa
  22. 22Criando sua conta no GitHub (a nuvem do seu código)
  23. 23O que é o Claude Code e por que ele é diferente do app
  24. 24Instalando o Claude Code
  25. 25Primeiro login e sua primeira sessão
  26. 26Como o Claude Code "enxerga" suas pastas (e por que isso importa)
  27. 27Sua primeira tarefa real: peça pra ele criar um arquivo
  28. 28Permissões: quando ele pergunta antes de mexer
  29. 29O arquivo CLAUDE.md: ensinando o robô sobre o seu projeto
  30. 30Modo plano e revisão: deixe ele pensar antes de fazer
  31. 31Errou? Desfazendo e recomeçando sem medo
  32. 32Escolhendo um primeiro projeto pequeno e real
  33. 33Descrevendo o que você quer: o briefing
  34. 34Deixe o Claude montar o esqueleto do projeto
  35. 35Rodando o projeto na sua máquina pela primeira vez
  36. 36Mudando textos, cores e imagens só conversando
  37. 37Quando algo quebra: lendo um erro sem entrar em pânico
  38. 38Pedindo pro Claude consertar o erro (copiar, colar, descrever)
  39. 39Adicionando uma página ou funcionalidade nova
  40. 40Salvando seu progresso com Git (commits, sem decoreba)
  41. 41Subindo seu projeto pro GitHub
  42. 42Colocando seu projeto no ar de graça (deploy)
  43. 43A anatomia de um bom pedido (revisão turbinada)
  44. 44Dividir pra conquistar: por que tarefas pequenas vencem
  45. 45Revisar o que a IA fez: a responsabilidade é sua
  46. 46Segurança básica: senhas, chaves e o que NUNCA colar
  47. 47Quando a IA "alucina" e como perceber
  48. 48Aprendendo a aprender com a IA: ela é sua professora particular
  49. 49Cinco ideias de próximos projetos pra praticar
  50. 50Seu novo superpoder: pra onde ir a partir daqui (fecho)
IA na PráticaParte 33 de 50

Descrevendo o que você quer: o briefing

4 min de leitura
Compartilhar
IA na Prática

Você já tem o conteúdo do seu site pessoal rascunhado (se ainda não tem, volte ao post anterior). Agora vem um passo que faz toda a diferença no resultado: explicar pro Claude o que você quer antes dele começar a construir.

Esse pedido bem feito tem um nome no mundo da criação: briefing. É a explicação clara do que você precisa. E aqui vale uma lei simples: quanto melhor o briefing, melhor o resultado.

A ideia: você é o cliente, o Claude é o profissional

Imagine que você contratou um marceneiro pra fazer uma estante. Se você disser só "quero uma estante", vai receber qualquer estante — talvez nem caiba na sua parede. Mas se você disser o tamanho, a cor, quantas prateleiras e onde vai ficar, recebe a sua estante.

Com o Claude é igual. Ele é o profissional habilidoso. Você é o cliente que sabe o que quer. O briefing é a conversa onde você passa os detalhes. Você não precisa saber como construir — precisa saber descrever.

As perguntas que todo bom briefing responde

Um bom briefing pra um site responde quatro coisas. Pense nelas como o roteiro da sua explicação:

  • O quê — que tipo de coisa é. No seu caso: um site pessoal de uma página.
  • Pra quem — quem vai visitar. Ex.: pessoas que te conheceram e querem saber mais, possíveis clientes, recrutadores.
  • Quais partes — as seções que você quer na página. Para um site pessoal, o clássico é: topo com seu nome, uma seção "sobre", uma de projetos ou links, e um contato.
  • Que estilo — a cara da coisa. Para começar, peça algo limpo e claro. Sem firula. Você refina depois.

Repare: nenhuma dessas perguntas exige conhecimento técnico. São todas sobre o que você quer, não sobre como fazer.

Um briefing pronto pra colar

Para tirar o medo da página em branco, aqui está um exemplo completo de briefing. Abra o Claude Code na pasta do seu projeto e cole um texto como este — trocando pelos seus dados:

Quero que você construa um site pessoal simples pra mim.

O QUÊ: um site de uma página só (sem outras páginas internas).

PRA QUEM: pessoas que me conhecem ou querem saber mais sobre meu
trabalho — possíveis clientes e contatos profissionais.

SEÇÕES, de cima pra baixo:
1. Topo: meu nome "Ana Souza" em destaque e a frase
   "Professora de inglês e apaixonada por viagens".
2. Sobre: dois parágrafos curtos sobre mim e o que eu faço.
   (vou te passar o texto: ...)
3. Links: meu e-mail (ana@exemplo.com) e meu Instagram (@anasouza).
4. Rodapé simples com meu nome e o ano.

ESTILO: limpo, claro, fácil de ler no celular e no computador.
Cores suaves. Nada chamativo.

Antes de começar, me explique em poucas linhas o que você vai
criar e quais arquivos. Aí eu aprovo.

Três detalhes que fazem esse briefing funcionar:

  1. Ele separa em blocos (o quê, pra quem, seções, estilo). Fica fácil de ler.
  2. Ele dá exemplos concretos (nome real, frase real, e-mail real). Concreto vale mais que vago.
  3. Ele pede pro Claude explicar antes de fazer. Assim você confere se ele entendeu — e corrige antes de qualquer trabalho.

Não precisa estar perfeito

Talvez você fique inseguro: "será que escrevi certo?". Relaxe. O briefing é uma conversa, não um contrato. Se o Claude entender algo diferente do que você queria, é só dizer: "não era bem isso, eu queria assim...". Você vai ajustando. O briefing inicial só precisa ser bom o bastante pra começar.

Se algo der errado

  • "O Claude começou a construir sem me explicar antes." Sem crise. Diga: "espera, antes me explica o que você vai fazer". E, pro futuro, sempre termine o briefing pedindo a explicação prévia, como no exemplo.
  • "Esqueci de pedir uma seção." Normal e fácil de resolver. Depois é só pedir: "adiciona também uma seção de contato com meu telefone". Você não precisa acertar tudo de primeira.
  • "Meu texto 'sobre' ficou ruim." Peça ajuda: "melhora esse texto pra ficar mais leve, mantendo o sentido". O Claude também escreve, não só constrói.

Briefing na mão e colado no terminal, você deu a instrução. No próximo post, é a hora mágica: você vai deixar o Claude montar o esqueleto do projeto a partir do seu briefing — e ver os primeiros arquivos do seu site nascerem.

Curtiu como a gente pensa?

É assim que trabalhamos todo dia.

Se esse jeito de pensar é o seu, vem construir com a gente — dá uma olhada nas vagas abertas.

Ver vagas