Prompts para texto, pesquisa, análise e código

Uma estrutura de prompt pode ser reutilizada, mas a prova de qualidade muda com o trabalho. Um texto de apresentação, uma pesquisa de mercado, a análise de uma tabela e a revisão de código têm riscos, evidências e formatos diferentes. Nesta aula, você vai preservar as peças gerais — objetivo, dados, regras e entrega — enquanto adapta o contrato ao que realmente será decidido.

Pense numa caixa de ferramentas. A alça e a organização podem ser as mesmas, mas uma chave de fenda não substitui um multímetro. Da mesma forma, um template ajuda a não esquecer perguntas importantes, porém não transforma toda tarefa no mesmo problema. A analogia termina na execução: ferramentas físicas produzem efeitos previsíveis quando usadas corretamente; modelos ainda geram respostas que precisam de teste e supervisão proporcional ao risco.

Texto precisa de propósito, público e fonte de afirmações

“Escreva um post sobre nosso produto” não informa o que o leitor deve entender ou fazer. Para uma primeira versão, declare objetivo, público, canal, fatos permitidos e ação esperada. Se o texto menciona preço, benefício mensurável ou depoimento, forneça a fonte aprovada. Tom de voz não autoriza inventar prova.

Tarefa: escrever o rascunho de um e-mail de boas-vindas.
Público: pessoas que acabaram de criar uma conta gratuita.
Fatos permitidos: os três recursos listados abaixo.
Regra: não prometer resultado, prazo ou recurso futuro.
Formato: assunto e corpo de até 180 palavras com uma única chamada para ação.

Para resumo, acrescente o que não pode ser perdido: decisão, risco, prazo ou discordância. Um resumo menor não deve apagar ressalvas essenciais. Peça vínculo com o material fornecido e indique como representar ausência. Se você precisa de citação literal, confira o trecho no original; o modelo pode alterar palavras ao parafrasear ou atribuir uma frase ao lugar errado.

Pesquisa exige acesso, seleção e rastreabilidade

O prompt pode definir a pergunta de pesquisa e os critérios de fonte, mas não oferece acesso automático à internet. Verifique se a ferramenta escolhida possui busca e como apresenta referências. Para assunto atual, registre data da coleta, URL, responsável e escopo. Uma lista de links convincente não prova que as páginas existem ou sustentam a afirmação.

Separe etapas. Primeiro delimite a pergunta e os critérios. Depois colete fontes autorizadas. Em seguida extraia evidências e, somente então, sintetize. Esse fluxo facilita descobrir se uma conclusão ruim veio de fonte ausente, leitura incorreta ou comparação inadequada.

Pergunta: quais requisitos oficiais mudaram no período definido?
Fontes aceitas: páginas do órgão responsável publicadas entre as datas A e B.
Entrega: tabela com requisito, data, URL e trecho que sustenta a interpretação.
Pendência: marcar qualquer conclusão sem fonte primária.

Não use um modelo como fonte de si mesmo. Ele pode ajudar a formular termos de busca ou organizar evidências, mas a afirmação precisa voltar ao documento responsável. Em decisões importantes, uma pessoa deve abrir e revisar a fonte.

Análise depende de dados definidos e casos ausentes

Antes de pedir análise, descreva colunas, unidades, período e significado. “Veja o que está acontecendo nas vendas” mistura exploração, diagnóstico e previsão. Divida: calcular variação, encontrar segmentos com queda, listar hipóteses e indicar dados necessários para testá-las. Hipótese não deve aparecer como causa confirmada.

Também explique valores ausentes, duplicatas e filtros. Se a ferramenta puder executar código, peça cálculo reproduzível e confira com exemplos pequenos. Se ela não puder, use-a para planejar a análise, não para inventar números. Contagem, média e porcentagem merecem verificação externa mesmo quando a explicação parece segura.

No laboratório, a tabela é um marcador fictício. A interface não busca preço e não escolhe ferramenta. Sua tarefa é verificar se a recomendação ficaria presa aos dados permitidos, se o orçamento entra como restrição e se ausências aparecem como pendência. Esse contrato reduz o espaço para completar lacunas com memória.

Código precisa de ambiente e critérios executáveis

Para código, informe linguagem, versão, arquivos relevantes, comportamento esperado e restrições de mudança. Um pedido como “corrija meu projeto” não diz qual falha reproduzir nem o que pode ser alterado. Inclua mensagem de erro, entrada mínima e comando de teste, removendo segredos, tokens e dados pessoais.

Objetivo: corrigir a validação sem mudar a resposta pública da API.
Ambiente: versão e dependências informadas no projeto.
Reprodução: comando e entrada de teste abaixo.
Critérios: teste atual passa, novo caso inválido falha e nenhum segredo é exibido.
Limite: não alterar banco nem dependências sem justificar.

Código sugerido ainda exige revisão, testes e análise de segurança. Pedir “código seguro” não substitui modelagem de ameaça, controle de acesso ou atualização de dependências. Se a mudança for destrutiva, defina aprovação humana e forma de recuperação fora do prompt.

O erro comum é criar um “superprompt universal” cheio de seções vazias. Isso torna a revisão lenta e incentiva preencher informação irrelevante. Comece pelo menor contrato que cobre a decisão, acrescente evidência proporcional ao risco e remova o que não muda a entrega. Você concluiu a aula quando consegue explicar por que dois trabalhos usam a mesma estrutura geral, mas passam por provas diferentes.