Projeto: crie uma biblioteca versionada de prompts

O projeto final transforma oito aulas em um artefato que outra pessoa consegue usar, revisar e melhorar. Você vai criar uma biblioteca com três prompts para um mesmo fluxo de trabalho, cada um acompanhado de finalidade, entradas, regras, casos de teste, rubrica, riscos e histórico. Não é necessário programar nem escolher um fornecedor específico; é necessário produzir evidência e deixar limites explícitos.

A lição de engenharia de prompt continua útil como referência conceitual. Aqui, o trabalho é diferente: montar um pequeno sistema editorial e operacional no qual uma mudança possa ser revisada. Evite copiar o texto da referência. Use seu próprio domínio, exemplos fictícios e decisões verificadas por quem entende do processo.

Pense numa biblioteca de procedimentos. Cada documento tem título, responsável, data, versão e indicação de onde se aplica. Uma folha solta pode até resolver uma tarefa hoje, mas ninguém sabe se está atualizada amanhã. A analogia termina porque prompts também dependem de modelo, configuração, ferramentas e dados; versionar somente o texto não captura todo o comportamento.

Escolha um fluxo pequeno e real

Use algo que você consiga explicar e testar sem informação confidencial. Pode ser organizar anotações de reuniões fictícias, classificar solicitações de um catálogo de testes ou revisar textos contra um guia público. Evite diagnóstico, decisão de crédito, seleção de pessoas e ações destrutivas no primeiro projeto. Quanto maior o impacto, maior a necessidade de especialistas, governança e controles fora do curso.

Divida o fluxo em três tarefas. Para triagem de atendimento, a biblioteca pode conter classificação inicial, extração de dados explícitos e preparação de um resumo para revisão humana. Uma tarefa por prompt facilita entender falhas. Um superprompt que classifica, pesquisa, decide, responde e executa ação mistura responsabilidades e amplia permissões.

Dê identidade e dono a cada prompt

Crie uma ficha que acompanhe o texto:

id: triagem-inicial-atendimento
versao: 1.0.0
responsavel: equipe de operações
finalidade: classificar mensagem e indicar revisão
fora_do_escopo: responder cliente ou alterar pedido
entradas: mensagem fictícia em texto
saida: quatro campos definidos
modelo_e_configuracao_testados: registrar no momento da avaliação
ultima_revisao: data e pessoa

O responsável não precisa ter escrito cada linha; ele precisa responder pela decisão de publicar, revisar fontes e receber alertas de falha. “IA” não é um dono. Sem pessoa ou equipe, um prompt desatualizado permanece em uso porque ninguém sabe quem pode mudá-lo.

Versione de forma compreensível. Uma correção de redação sem mudança esperada pode incrementar a parte menor; novo comportamento compatível pode incrementar a parte intermediária; mudança que altera entradas, saída ou interpretação dos consumidores merece versão principal. O esquema exato importa menos que aplicar a mesma regra e guardar o histórico.

1.1.0 — adiciona tratamento explícito para número de pedido ausente.
Motivo — três casos preenchiam o campo com sequência não fornecida.
Evidência — casos A03, A07 e A08 passam; conjunto de retenção sem regressão.
Revisor — nome e data.

Não escreva “melhorias gerais”. Relacione mudança, hipótese, casos e resultado. Se algo piorou, registre. O histórico serve para investigação, não para vender uma narrativa de sucesso contínuo.

Empacote testes e rubrica junto da versão

Cada prompt deve ter ao menos oito casos: três comuns, dois com informação ausente, um ambíguo, um fora de escopo e um adversarial. Use dados inventados e marcados como fixtures. Guarde expectativa e motivo. Separe dois casos de retenção para reduzir ajuste excessivo ao conjunto visível.

Sua rubrica precisa incluir formato, fidelidade aos dados e segurança. Classifique critérios críticos: inventar identificador, ignorar revisão financeira ou seguir instrução do conteúdo bloqueia publicação mesmo se o tom melhorar. Registre modelo, configuração, data e ferramentas usadas. Se testar mais de um fornecedor, mantenha os casos e compare sem prometer equivalência futura.

O laboratório oferece um prompt completo, mas não produz resposta. Substitua o domínio somente depois de escrever a finalidade e o fora de escopo. Leia cada campo da saída e confira se existe um critério correspondente. Em seguida, crie um caso para cada regra crítica. A biblioteca pode ser um conjunto de arquivos de texto e uma planilha; o valor está no contrato e na rastreabilidade, não na ferramenta de armazenamento.

Faça revisão de conteúdo e de risco

Peça a outra pessoa para executar a leitura sem sua explicação oral. Ela entende a tarefa, sabe quais dados pode usar e reconhece quando interromper? Depois peça que tente quebrar uma hipótese: entrada vazia, longa, contraditória ou com uma instrução no conteúdo. Registre o que falhar e mude uma coisa por versão.

Confirme que não há dado pessoal, segredo ou texto proprietário nos exemplos. Liste fontes oficiais usadas para regras do domínio e datas de revisão. Se uma regra muda com frequência, defina responsável e prazo para revalidar. Prompt versionado com política vencida continua perigoso.

O erro comum é entregar uma pasta chamada “prompts finais” contendo apenas três textos. Sem teste, dono e histórico, “final” significa somente que alguém parou de editar. O projeto está concluído quando uma pessoa consegue reproduzir a avaliação, entender por que a versão existe, identificar limites e voltar à versão anterior. Essa é a passagem do uso casual para uma prática intermediária de engenharia.