🔁 Evolução por diff & consolidação
Adicionar pouco, consolidar sempre.
Seu prompt cresce por necessidade real, não por antecipação. Aqui você aprende o ciclo testar → achar falha → corrigir com um padrão e a rodada de consolidação que impede o inchaço — o mesmo movimento que levou o Opus 4.8 ao Fable 5 com +56 linhas e 7 blocos a menos.
Conteúdo detalhado
O ciclo: testar → achar falha real → corrigir
Prompts não nascem prontos — eles evoluem por uso. O motor da evolução é um ciclo curto e honesto: você roda o prompt num caso real, observa onde ele de fato falha, e só então corrige. A palavra-chave é real: você corrige a falha que aconteceu, não a que você teme que possa acontecer.
As 4 paradas do ciclo
Rode o prompt mínimo viável (Módulo 4.1) contra um input de produção. Não invente um teste fácil que ele passa — use o caso que importa.
Descreva o sintoma em uma frase: "ele usou emoji sem eu pedir", "respondeu em 12 parágrafos". Falha sem sintoma reproduzível não é falha — é palpite.
Aplique um padrão do catálogo que ataque exatamente aquele sintoma — e nada além. Volte ao passo 1 e confirme que a falha sumiu.
Falha real ≠ falha imaginada
A maioria dos prompts inchados é feita de regras contra falhas que nunca aconteceram. Adicione contra o sintoma que você viu na tela. Tudo o mais é antecipação — e antecipação é o combustível do inchaço.
Corrigir com UM padrão do catálogo
A diferença entre um prompt que envelhece bem e um que vira uma cebola de regras está em como você corrige. A correção amadora adiciona "mais uma regra solta". A correção profissional escolhe um padrão nomeado do catálogo (Trilha 1) que ataca a classe do problema, não só a instância.
✗Regra solta
- •"Nunca use a palavra 'na verdade'."
- •Resolve a instância, não a classe
- •Se acumula: 1 sintoma = 1 linha nova
- •Sem nome → não dá pra consolidar depois
- •Vira a "cebola" que o Fable 5 desfez
✓Padrão do catálogo
- •"Assuma um adulto capaz; sem hedge." (Princípio Consolidado)
- •Ataca a classe: cobre "honestly", "actually"…
- •Generaliza para casos não vistos
- •Tem nome → rotulável no changelog
- •Pronto para fundir na consolidação
🗺️ Do sintoma ao padrão
- •Modelo prometeu uma ferramenta que não tem → Declaração de Capacidades com escopo
- •Resposta longa demais → Orçamento de Concisão (Ficha 7)
- •Recusa contornável / regra seca → Regra com Porquê (Ficha 3)
- •Quatro travas micro espalhadas → Princípio Consolidado (Ficha 12)
A rodada de consolidação
Adicionar é fácil; remover exige coragem. Por isso a consolidação não pode ficar para "quando der" — ela vira ritual agendado: a cada 3 adições, uma rodada de limpeza. Sem o gatilho fixo, o prompt só engorda, porque o incentivo de cada turno empurra para "mais uma linha".
O que é uma rodada de consolidação
É uma pausa deliberada em que você não adiciona nada. Você relê o prompt inteiro com três perguntas: o que o modelo já internalizou (vira ruído, apague), o que se repete (funda), e quais regras micro podem virar um princípio (consolide).
O critério de sucesso é contraintuitivo: a rodada deu certo se o prompt ficou mais curto mantendo o mesmo comportamento nos testes.
A rodada, passo a passo
Rode a bateria de testes e anote: contagem de linhas + quantos testes passam. É contra esses números que você vai medir.
Funda regras irmãs num princípio; apague o que o modelo já faz sozinho; renomeie blocos pela intenção, não pela imposição.
Mesmos testes. Se passam com menos linhas: commit. Se algum quebrou: a regra removida fazia trabalho real — restaure só ela.
Toda remoção é uma hipótese testável
Não decida no olho se uma regra "ainda é necessária". Remova-a e rode os testes. Se nada quebra, ela já era ruído. A consolidação é empírica, não opinativa.
Imitando 4.8 → Fable 5
O diff do Opus 4.8 para o Fable 5 é o exemplo vivo deste módulo. A Anthropic adicionou muito conteúdo novo — e mesmo assim o prompt cresceu só +56 linhas, porque 7 blocos foram removidos. Essa é a lição central: remover faz parte de evoluir. Crescer não é o objetivo; consolidar é.
📊 Os números do diff
- •4.8: 3.769 linhas (~23.000 palavras)
- •Fable 5: 3.825 linhas (~23.800 palavras)
- •Saldo: apenas +56 linhas — apesar de muito conteúdo novo, porque 7 blocos saíram
🗑️ O que saiu — e por quê
- −
<search_first>— o modelo já busca por treino; a ordem obsessiva virou ruído. - −
<default_stance>— a postura "ajude por padrão" foi absorvida porrefusal_handling. - −
respond_without_citing_system_prompt— "não diga X" tem efeito Streisand; resolveu-se no treino. - −4 micro-regras de tom (sem bullets ao recusar, sem pet names, sem "honestly/actually", regra de emoji) → fundidas em "assume um adulto capaz e trate-o como tal".
4 micro-regras → 1 princípio: consolidação em estado puro
As travas microscópicas sinalizavam desconfiança do modelo. Uma postura geral cobre tudo — inclusive os casos que ninguém listou. É exatamente o Princípio Consolidado (Ficha 12) que você aplica no seu prompt.
Versionar em git
Se cada ciclo e cada consolidação não deixar rastro, você perde a história. Versionar o prompt em git transforma o histórico do aluno no seu próprio "repo de evolução" — cada commit é um diff que você pode reler, comparar e, se preciso, reverter.
# adição 1 — falha real: respostas longas demais
git add prompt.md
git commit -m "add(concisao): orçamento de 2-3 parágrafos [Ficha 7]"
# adição 2 — falha real: recusa contornável
git commit -m "add(seguranca): regra com porquê na recusa [Ficha 3]"
# adição 3 — falha real: promete tool inexistente
git commit -m "add(capacidades): escopo explícito de ferramentas"
# gatilho: 3 adições → rodada de consolidação
git commit -m "consolidate: 4 micro-regras de tom → 1 princípio (-9 linhas) [Ficha 12]"
git log --oneline # o repo de evolução, legível de cima a baixo
git diff HEAD~1 # releia a última consolidação como um diff✓Bom versionamento
- •1 commit = 1 mudança atômica (1 adição OU 1 consolidação)
- •Mensagem cita a falha real e o padrão aplicado
- •Consolidações marcadas com o delta de linhas
- •Reverter é barato → você ousa remover
✗Versionamento ruim
- •"update prompt" para 12 mudanças misturadas
- •Sem rastro de qual falha motivou o quê
- •Editar direto, sem commit → sem diff pra reler
- •Medo de remover porque não dá pra voltar
Changelog com motivação
O commit guarda o que mudou; o changelog guarda por que. Cada entrada rotula a mudança pelo padrão aplicado e a falha que a motivou — exatamente o formato do diff anotado 4.8 → Fable 5: mudança + motivação provável + lição. Esse é o artefato que prova que seu prompt evoluiu por razão, não por acaso.
## v0.4 — rodada de consolidação
- consolidate: 4 travas de tom → "assume adulto capaz"
motivo: micro-regras sinalizavam desconfiança; -9 linhas
padrão: Princípio Consolidado (Ficha 12)
testes: 8/8 mantidos
## v0.3
+ add: escopo explícito de ferramentas
motivo: modelo prometeu "buscar na web" sem ter a tool
padrão: Declaração de Capacidades
## v0.2
+ add: regra com porquê na recusa
motivo: recusa seca era contornada por reformulação
padrão: Regra com Porquê (Ficha 3)
## v0.1
+ add: orçamento de concisão (2-3 parágrafos)
motivo: respostas de 12 parágrafos no caso de suporte
padrão: Orçamento de Concisão (Ficha 7)🧬 Anatomia de uma boa entrada
- •Tipo:
addouconsolidate— deixa visível o ritmo adição/limpeza - •Motivo: a falha real observada (o sintoma na tela), não a teoria
- •Padrão: a ficha do catálogo que justifica a forma da mudança
- •Testes / delta: a prova empírica — passa/quebra e linhas a mais/menos
O changelog é o seu diff anotado pessoal
Daqui a três meses você não vai lembrar por que existe a linha X. O changelog responde — e te dá coragem para remover na próxima consolidação, porque você sabe exatamente qual falha aquela linha resolveu (e se ela ainda existe).
🔁 Resumo do Módulo
Próximo: Módulo 4.3
Testes e o "porquê documentado" (regra de ouro) — como medir a qualidade do prompt por comportamento, não por opinião, e por que toda regra precisa de um teste e de um motivo escrito.