O problema
"Resuma esse relatório de forma profissional." É um prompt razoável e é também um contrato vago o bastante pra falhar de três formas diferentes: o modelo pode resumir demais e perder um número importante, pode manter formatação inconsistente com o resto do documento, ou pode simplesmente interpretar "profissional" de um jeito que não é o que quem pediu tinha em mente. Nenhuma dessas três é "o modelo errou" — é o prompt que não definiu o que conta como sucesso.
Um prompt de produção não é uma instrução em linguagem natural esperando boa vontade. É um contrato: critérios de sucesso explícitos, formato esperado, e as subtarefas que compõem o resultado final. Cenários de arquitetura testam justamente isso — não se você sabe escrever um prompt gramaticalmente correto, mas se você sabe transformar um pedido ambíguo num contrato que pode ser verificado.
Critérios de avaliação antes do prompt
A ordem importa: defina como você vai saber se a saída está certa antes de escrever a instrução que gera essa saída. Se você não consegue enunciar o critério, o prompt vai carregar a ambiguidade pra dentro da resposta.
Critérios de avaliação úteis são específicos e verificáveis: "o resumo preserva todos os valores numéricos citados no documento original" é verificável. "O resumo é bom" não é. Um critério verificável também vira, quase de graça, um caso de teste — você pode checar programaticamente se os números batem, sem precisar de outro julgamento humano.
Decompor em subtarefas verificáveis
Uma tarefa ambígua raramente é uma tarefa — é várias tarefas empilhadas sem fronteira clara. "Analise esses dados de vendas e me diga o que fazer" esconde pelo menos três subtarefas: extrair os números relevantes, identificar padrões nesses números, e recomendar uma ação com base no padrão identificado.
Decompor essas subtarefas trás dois ganhos. Primeiro, cada subtarefa fica pequena o bastante pra ter um critério de sucesso próprio — "os números extraídos batem com a fonte" é verificável isoladamente, "a recomendação é boa" não é, mas fica mais fácil de avaliar quando já se sabe que os números e o padrão estão corretos. Segundo, decompor expõe onde a incerteza realmente mora: normalmente não é na extração (mecânica, verificável), é na recomendação final (julgamento, precisa de critério explícito ou revisão humana).
Exemplos fixam o padrão de julgamento
Instrução sozinha ("seja conciso", "use tom formal") deixa a interpretação do "quanto" pro modelo decidir sozinho, e a decisão dele pode não bater com a sua. Um ou dois exemplos do formato e do padrão de julgamento esperado fixam isso de forma muito mais confiável do que adjetivos.
O ganho de exemplos é maior exatamente onde o critério é mais difícil de descrever em palavras — um exemplo de "resposta educada mas firme, sem soar passivo-agressivo" comunica em uma linha o que levaria um parágrafo pra descrever, e ainda assim deixaria espaço pra interpretação.
O distrator comum
Um cenário típico oferece uma alternativa que "reescreve o prompt com instruções mais claras" quando o problema real não é falta de clareza na instrução — é falta de contexto de fonte, ou falta de um caso de teste pra verificar o resultado. Reescrever o prompt não resolve um problema que na verdade é de dado ausente ou de critério não verificável. Antes de mexer no texto do prompt, pergunte se o problema é mesmo de instrução, ou se é de contrato mal definido.
Coloque em prática
O laboratório desta lição implementa um validador de contrato de prompt: dado um conjunto de critérios de sucesso e uma saída candidata, ele verifica quais critérios passam e sinaliza quando a decomposição em subtarefas deixou algum critério sem forma de ser checado — o mesmo raciocínio que você aplica ao ler um pedido ambíguo e decidir o que precisa virar critério explícito antes de escrever o prompt.