Como testar e avaliar uma Skill
Em resumo
- Monte um conjunto de casos com entrada e resultado esperado.
- Meça acertos antes e depois de cada mudança.
Sem teste, você não sabe se a Skill melhora ou piora o resultado.
Monte um conjunto de casos com entrada e resultado esperado.
Guia completo e atualizadoPassei semanas mexendo em uma Skill achando que estava melhorando. Quando finalmente montei um conjunto de casos e medi, descobri que a versão de três semanas antes acertava mais. Eu vinha adicionando instruções para casos raros e piorando os casos comuns. Desde então, nenhuma Skill minha muda sem passar por teste, e este artigo é o método.
Você vai ver como montar casos de teste, como medir sem ferramenta especial, como comparar versões e quando parar de mexer.
Por que testar
Uma Skill é um texto que influencia um modelo probabilístico. Mudar uma frase pode melhorar um caso e piorar três. Sem medir, você confia na impressão da última resposta que viu, e impressão é péssima métrica. Testar transforma "acho que melhorou" em "acertou 8 de 10, antes eram 6".
Biblioteca de Skills: organização e versionamento
Como manter dezenas de Skills sem virar bagunça. →
Montando os casos
Cinco a dez pedidos reais, de datas e situações diferentes, incluindo os difíceis: o mês com promoção, a planilha com coluna faltando, o cliente que mudou de meta no meio do mês. Para cada um, escreva o que seria uma resposta aceitável: os números certos, o formato, o que não pode faltar.
Guarde tudo em uma planilha: pedido, material, resultado esperado, resultado obtido, nota. Sem ferramenta, sem framework. A planilha é o suficiente para começar e continua servindo por muito tempo.
Rodando a avaliação
Execute os casos com a Skill e sem ela. Dê nota (certo, parcial, errado) a cada resultado. Se a Skill não muda a nota, ela não está agregando: ou o modelo já fazia bem, ou a Skill está mal escrita. Depois, a cada mudança, rode de novo e compare com a rodada anterior.
Uma mudança que sobe a nota em um caso e derruba em dois é uma piora. Reverta.
Repetição
Modelos variam entre execuções. Para casos importantes, rode duas ou três vezes e olhe se o resultado é estável. Instabilidade em um caso costuma indicar instrução ambígua.
O que medir além de certo e errado
Formato: a saída veio na estrutura pedida? Completude: todos os itens obrigatórios estão lá? Precisão: os números batem com a fonte? Concisão: tem enchimento que você cortaria? Estabilidade: a mesma entrada dá resultado parecido em duas execuções? Cada critério vira uma coluna na planilha, com nota simples.
Separar os critérios mostra onde a Skill falha. Uma Skill pode acertar todos os números e errar o formato toda vez, e a correção é um exemplo, não mais instrução de cálculo. Sem essa separação, a nota geral esconde qual bloco precisa de ajuste.
Testando mudanças de modelo
Quando sai um modelo novo, o mesmo conjunto de casos diz se a Skill continua funcionando. É comum uma Skill afinada para um modelo precisar de ajuste em outro, geralmente em instruções que dependiam de um comportamento específico. Rode os casos antes de trocar, não depois de o cliente reclamar. Guarde o resultado de cada modelo na mesma planilha: com o tempo você vê qual modelo rende melhor em cada tipo de Skill e escolhe por dado, não por lançamento.
Diagnosticando o erro
Quando um caso erra, pergunte ao modelo por que fez daquele jeito. A resposta costuma apontar a frase da Skill que ele interpretou de outra forma. Corrija a frase, não adicione outra por cima: Skills que crescem por remendo ficam contraditórias, e contradição é o que gera instabilidade.
Avaliação automática, quando vale
Quando os casos passam de vinte ou você muda a Skill toda semana, vale automatizar: um script roda os casos, e um segundo modelo compara cada resultado com o esperado usando critérios que você escreveu. Calibre esse avaliador com alguns casos julgados por você antes de confiar. Para a maioria das Skills, a planilha manual basta por meses.
Quando parar de mexer
Quando os casos passam de forma estável e as correções param de aparecer no uso real. Nesse ponto, a Skill entra em manutenção: só muda quando um caso novo falha ou quando o processo muda. Continuar ajustando sem motivo é como eu piorei a minha por três semanas.
Na minha rotina
Cada Skill tem uma planilha de oito a doze casos, com material e resultado esperado. Antes de qualquer mudança, rodo os casos; depois, rodo de novo. Levo uns vinte minutos por Skill e já evitei pelo menos três regressões que teriam ido para relatório de cliente. A Skill que eu piorei por semanas hoje acerta os doze casos e não é alterada há dois meses, o que é exatamente o que uma Skill madura deveria fazer.
Perguntas frequentes
Preciso de ferramenta especial?
Não. Uma planilha com pedido, esperado, obtido e nota resolve por muito tempo.
Quantos casos são suficientes?
Cinco a dez para começar, incluindo os difíceis. Cresce conforme aparecem falhas novas.
Devo testar com dados reais?
Sim, anonimizados. Casos inventados não têm as surpresas que quebram Skills.
Um modelo pode avaliar o outro?
Pode, com critérios escritos por você e calibração em casos que você julgou primeiro.
Fontes e método
- Guia de avaliação de prompts da Anthropic
- Planilhas de casos das Skills próprias, 2025 e 2026
Continue sua pesquisa
Próximos passos selecionados para esta jornada.
Biblioteca de Skills: organização e versionamento
Como manter dezenas de Skills sem virar bagunça.
Entender →Custos de tokens: como estimar antes de construir
Conta simples para prever quanto seu sistema vai gastar por mês.
Ver como fazer →Grok: o assistente do X
O que o Grok oferece e onde ele se diferencia.
Comparar →