O que é que realmente precisa de estar num pedido de construção?
Quatro coisas, e digo isto depois de ver algo como duzentos destes pedidos transformarem-se em sites concluídos: o que é, para quem é, os requisitos essenciais e — opcionalmente — um tom. Tudo o resto é ruído que o construtor vai preencher com valores predefinidos de qualquer forma, por isso a verdadeira competência não é escrever mais, é perceber sobre qual destas quatro coisas tem realmente uma opinião e dizer só isso.
Comece pelo que é, e mantenha-o numa categoria, não numa especificação. "Um site de marcações para um estúdio de ioga" é melhor do que "um site onde as pessoas veem horários e clicam num botão para reservar um lugar e recebem uma confirmação" mesmo que a segunda opção contenha mais informação. A categoria ativa os valores predefinidos que o construtor já tem — horários parecem-se com horários, fluxos de marcação parecem-se com fluxos de marcação — enquanto a descrição o obriga a reconstruir a categoria do zero.
Preciso de dizer para quem é?
Não precisa, mas é a linha que as pessoas saltam e não deveriam. "Para os alunos atuais do estúdio" e "para pessoas a descobrir o estúdio pela primeira vez" produzem sites diferentes em quase tudo o que importa — tom do texto, se há um grande destaque de marketing ou um layout direto para o horário, se os preços aparecem em destaque (novos visitantes precisam deles) ou ficam mais escondidos (os habituais já os conhecem). Uma frase aqui pode resolver uma centena de pequenas ambiguidades que uma página de pedidos de funcionalidades nunca resolveria. Se o público for realmente genérico, deixe de fora — não invente um só para preencher o campo.
Quantos requisitos essenciais devo listar?
Dois ou três. O teste que uso: rejeitaria a primeira construção por faltar isto? "Horário de aulas, pagamentos online, biografias dos professores" passa este teste para um estúdio de ioga — sem um horário não é uma versão mais pequena do site, é um site diferente. "Uma inscrição na newsletter no rodapé" quase nunca passa; isso é um extra desejável, e os extras desejáveis pertencem à conversa de seguimento depois de ver um plano, não espremidos no pedido inicial onde competem com o que realmente importa.
Este é, honestamente, o ingrediente que as pessoas estragam mais, em ambas as direções. Zero indispensáveis e o construtor tem de adivinhar, por vezes mal. Oito indispensáveis e o construtor trata todos os oito como igualmente essenciais, e o resultado lê-se como uma lista de funcionalidades disfarçada de website — sem hierarquia, sem espaço para respirar. Se tivesse de contestar a decisão de ignorar um ingrediente, seria este. Mesmo uma única frase com "as duas coisas que tornam isto seu" evita quase sempre uma ida e volta, porque é a única informação que o construtor não consegue inferir apenas a partir da categoria.
Devo especificar um ambiente/tom?
Só se tiver um em mente. Muitos bons prompts dispensam isto por completo, e está tudo bem — o diretor de design assume uma direção artística quer especifique ou não. Um tom em duas palavras ("quente e desenhado à mão", "clínico e rápido", "como um arcade dos anos 90") apenas direciona esse compromisso, em vez de o deixar entregue aos padrões da categoria. Se tiver uma reação forte — sabe que quer fundos creme e tipografia serif quente, ou sabe que detesta cantos arredondados — vale a pena gastar a frase nisso. "Limpo e moderno", já agora, não conta. Isso não é um tom, é a ausência de um, e não direciona nada, ainda que lhe custe um espaço.
Porque não descrever simplesmente tudo o que estou a pensar?
Porque o construtor obedece. Essa é a verdadeira falha, e não é o que as pessoas esperam — não é que demasiada informação confunda o construtor, é que cada frase que escreve é lida como uma instrução, incluindo as ideias a meio caminho que descartaria de bom grado numa segunda leitura. Já vi alguém escrever "talvez uma secção de testemunhos, não tenho a certeza" e receber de volta uma secção de testemunhos com três citações de exemplo, porque "talvez, não tenho a certeza" é uma reticência para um leitor humano e um pedido de funcionalidade para um sistema que o leva à letra.
Isto não teria importância se especificar de menos fosse caro, como acontece com uma equipa humana de desenvolvimento, em que a ambiguidade custa duas semanas até alguém reparar que se construiu a coisa errada. Aqui não é caro. O construtor planeia antes de construir — vê uma proposta concreta antes de algo ficar comprometido em código — pelo que especificar de menos custa uma correção de cinco minutos no chat, enquanto especificar de mais coloca logo à cabeça todas as suas ideias mais frágeis e a meio caminho, precisamente no momento em que tem menos informação para saber quais valem a pena manter. Dez palavras de requisitos reais valem mais do que duzentas palavras de fluxo de consciência, não porque mais informação seja má em abstrato, mas porque, especificamente nesta interface, cada palavra a mais é um compromisso.
Há também um custo mais discreto: achata a hierarquia. Liste doze funcionalidades com igual ênfase e o construtor não tem qualquer indicação de quais as três com que realmente se importa, pelo que dá a mesma importância visual às doze (resultado confuso) ou tenta adivinhar a prioridade (às vezes mal, e agora está a depurar uma suposição em vez de afirmar uma preferência). Três indispensáveis expressos com clareza protegem essa hierarquia. Doze num parágrafo apagam-na.
Como é, na prática, um bom prompt?
| Comando | Porque funciona |
|---|---|
| "Um registo de treino para escaladores — sessões, graus, gráficos de progresso." | O quê mais três indispensáveis, dez palavras de requisitos no total. Sem nota sobre o público-alvo, porque "escaladores a registar o seu próprio treino" é óbvio a partir da categoria — omite corretamente o único ingrediente que aqui não teria qualquer utilidade. |
| "Uma landing page para o meu podcast sobre agricultura urbana, com um ambiente caloroso e editorial, com uma lista de episódios e um formulário de subscrição." | O quê, público-alvo implícito em "o meu podcast", ambiente/tom, duas funcionalidades. Não diz que leitor incorpora os episódios nem quantos aparecem por página — são perguntas para uma segunda ronda, não para o prompt inicial. |
| "Um jogo de air-hockey para dois jogadores, física real, um só teclado." | Os jogos tornam este padrão óbvio: género mais a única restrição que define como o jogo realmente se sente. "Física real" e "um só teclado" não são tanto funcionalidades como as duas decisões que determinam se o jogo corresponde ao que imaginou. Cor da mesa, rastos do disco, interface de pontuação — o construtor propõe, o utilizador reage. |
O que une os três exemplos não é a brevidade pela brevidade, é que cada palavra tem uma função. Retire "caloroso e editorial" do prompt do podcast e fica com uma página de podcast genérica; retire "agricultura urbana" e a palavra do ambiente/tom fica sem nada a que se agarrar. Esse é o verdadeiro teste para saber se um prompt está bem formado — não a contagem de palavras. Prefiro um prompt de 40 palavras em que cada frase justifica o seu lugar a um prompt de 15 palavras que é conciso por si só mas que, silenciosamente, deixa cair um indispensável.
E se já tiver cores de marca ou fotografias reais?
Anexe-os. Não os descreva. Já vi pessoas escreverem um parágrafo cuidadoso a tentar fixar uma paleta de marca em linguagem quase-hexadecimal — "um verde-floresta profundo, meio suave" — quando o verdadeiro manual de marca estava, o tempo todo, num PDF na área de trabalho. Uma cor descrita é uma suposição que o construtor tem de reconstruir; uma cor anexada está simplesmente correta. Menus reais, fotografias reais, elementos de marca — as funcionalidades de conhecimento e referência alimentam-nos diretamente para o build, e factos vencem sempre descrições de factos.
