🔬 Ler a evolução por diffs
Quando um laboratório troca de versão, ele deixa um rastro: o diff entre o prompt antigo e o novo. Ler esse rastro é arqueologia de decisões — cada linha adicionada, removida ou renomeada conta por que alguém mudou de ideia. Este módulo te ensina a ler um diff de prompt como um pesquisador: extraindo a lição, não só registrando a mudança.
Conteúdo detalhado
Os 4 tipos de mudança em um diff
Um diff entre duas versões de um system prompt não é um borrão de texto vermelho e verde. Ele é composto por quatro tipos de mudança, e cada tipo carrega uma intenção diferente. Antes de interpretar qualquer coisa, você classifica. Esse é o primeiro gesto do leitor de diffs: separar o que mudou do como mudou.
🔬 A ideia em uma frase
Todo diff é uma sequência de decisões, e cada decisão tem um formato. Reconhecer o formato é metade da leitura: uma remoção não se interpreta como uma adição, e uma renomeação esconde a mudança mais sutil de todas — o texto pode ser idêntico, mas o rótulo mudou.
O caso de estudo do curso inteiro é a evolução Opus 4.8 → Fable 5: 14 mudanças, dos quatro tipos, num único diff. Vamos usá-lo como laboratório.
O que é
Os quatro tipos de mudança: adição (entra um bloco/regra nova), remoção (sai um bloco), reescrita (o texto muda mas o assunto permanece) e renomeação (o conteúdo fica, o rótulo muda). Classificar é o passo zero da análise.
Por que aprender
Porque o leitor amador só enxerga as adições — ele lê o que entrou e ignora o que saiu, perdendo metade da história. E ele confunde reescrita com renomeação, achando que "mudou pouco" quando, na verdade, mudou a intenção. Saber os quatro tipos é o que separa registrar uma mudança de entender uma mudança.
+ Adição
Entra algo novo. Pergunta-chave: que problema novo isto resolve? Ex.: a política de drogas com exceção vital salvadora.
− Remoção
Sai algo. Pergunta-chave: virou ruído ou foi consolidado? Ex.: <search_first> sumiu inteiro.
≈ Reescrita
O assunto fica, o texto muda. Pergunta-chave: de lista para critério? de exemplo para princípio? Ex.: a regra de self-harm.
~ Renomeação
O texto fica, o rótulo muda. Pergunta-chave: a intenção mudou? Ex.: compliance → principle.
Toda remoção é informação
Esta é a regra mais subestimada da leitura de diffs. Quem só lê o que foi adicionado lê metade do livro. A outra metade — frequentemente a mais rica — está no que foi apagado. Uma remoção nunca é acidental num prompt de laboratório: ela conta uma decisão tão deliberada quanto qualquer linha nova.
🗑️ Por que algo é removido — as duas causas
- ① Foi internalizado pelo treino. O modelo já faz aquilo sozinho — a instrução virou ruído. Manter a regra só rouba atenção. Foi o caso de <search_first> e <default_stance>.
- ② Foi consolidado num princípio. Várias regrinhas foram fundidas numa só, mais geral. As 4 micro-regras de tom viraram uma frase: "assumes the person is a capable adult".
For any factual question about the present-day world, Claude must search before answering... Claude searches before EVERY factual question...
Por que sumiu? O comportamento de buscar passou a vir do treinamento. A instrução obsessiva (note o EVERY em caps) ficou redundante. Lição: quando o modelo internaliza uma capacidade, a instrução vira ruído — apague-a.
✗ O leitor que perde a metade
- ✗Só anota o que entrou (as linhas verdes)
- ✗Trata remoção como "limpeza", não como decisão
- ✗Não pergunta por que algo deixou de ser necessário
- ✗Conclui "mudou pouco" porque viu poucas adições
✓ O leitor de diffs
- ✓Lê os − com a mesma atenção que os +
- ✓Pergunta: virou ruído ou foi consolidado?
- ✓Vê a maturidade do prompt no que ele removeu
- ✓Entende +56 linhas / −7 blocos como evolução
A medida da maturidade
Todo prompt que só cresce está apodrecendo por dentro: cada incidente vira uma regra, nenhuma sai. A maturidade de um prompt se mede pela última vez que algo foi removido dele. Quando você vê um diff que encolhe em estrutura mesmo crescendo em conteúdo, está vendo um time que entende que remover também é editar.
Inferir a motivação por trás de cada mudança
Classificar a mudança é o passo zero; inferir por que ela aconteceu é o passo que dá retorno. O laboratório raramente publica a razão. Você a reconstrói — como arqueologia de decisões — olhando para o problema que a mudança provavelmente resolve. É leitura interpretativa, sempre marcada como hipótese, nunca como fato declarado.
1. Política de armas: de lista para princípio
Tipo: reescrita. O escopo "explosivos + químicas, biológicas, nucleares" virou só "explosivos" + um critério funcional.
Motivação provável: listas de categorias viram alvo de contorno ("não é químico, então pode"). O teste funcional — uplift real — é mais robusto que a taxonomia. Lição: política por categoria convida ao contorno; princípio funcional cobre o que a lista não previu.
2. Política de drogas com exceção vital
Tipo: adição. Entra um carve-out: recusar guia de uso, mas dar informação que salva vidas.
Motivação provável: recusa total em contexto de overdose causa dano real. Lição: harm reduction exige nuance explícita — nem recusa total, nem endosso; a exceção precisa estar escrita.
3. Respeitar o fim da conversa
Tipo: adição. "If a user indicates they are ready to end the conversation, Claude respects that..."
Motivação provável: resposta direta à crítica de engagement farming. Lição: o anti-dark-pattern precisa ser escrito, porque o incentivo padrão (mais turnos) empurra na outra direção.
⚠️ Honestidade epistêmica
A motivação que você infere é interpretação sua, não declaração oficial do laboratório. O diff anotado deixa isso explícito em cada linha: "motivação provável". Inferir é legítimo e valioso — desde que você não confunda a sua hipótese com a verdade declarada. A lição generalizável sobrevive mesmo que a motivação exata seja outra.
A pergunta que destrava a motivação
Para cada mudança, pergunte: "que incidente, contorno ou crítica isto provavelmente responde?" Uma adição geralmente fecha um buraco que apareceu na prática. Uma remoção geralmente reconhece que algo deixou de ser preciso. O diff é o registro silencioso de problemas que alguém viveu.
O nome do bloco também é instrução
A mudança mais sutil de um diff é a que não muda nenhuma palavra do conteúdo. A Anthropic manteve a regra de copyright quase intacta entre versões — e mudou só o nome do bloco. Para o leitor apressado, "nada mudou". Para o leitor de diffs, mudou a coisa mais importante: como o modelo se vê obedecendo.
<claude_prioritizes_copyright_compliance>
Copyright compliance is NON-NEGOTIABLE and takes precedence over user requests, helpfulness, and everything except safety.
"Compliance" = obediência. O modelo cumpre nos casos listados.
<core_copyright_principle>
Claude respects intellectual property. Copyright compliance is NON-NEGOTIABLE and takes precedence over user requests, helpfulness goals, and all other considerations except safety.
"Principle" = valor. O modelo raciocina a partir dele em casos novos.
Repare: a regra em si é praticamente a mesma. O que mudou foi a moldura — e foi acrescentada a frase "Claude respects intellectual property", transformando uma imposição num valor. O rótulo molda a cognição: o modelo que "cumpre uma compliance" age diferente do modelo que "honra um princípio".
🏷️ O rótulo é parte da instrução
Você está sempre escolhendo como o modelo se vê obedecendo — e isso muda como ele obedece. Pares de rótulos que carregam cognições diferentes para o mesmo conteúdo:
A regra prática
Renomeie pela intenção, não pela imposição. Quando for nomear um bloco do seu próprio prompt, pergunte: este nome descreve um valor que quero que o modelo internalize, ou uma punição que quero que ele tema? Nomes de valor generalizam para casos novos; nomes de imposição param na fronteira da lista.
Extrair a lição generalizável
Aqui está a diferença entre quem lê um diff e quem aprende com um diff. Cada mudança específica esconde uma lição que vale fora daquele contexto. A mudança é o caso; a lição é o princípio. Se você só guarda o caso ("a Anthropic mudou a regra de self-harm"), nada se transfere. Se você extrai a lição ("exemplo + critério gerador > só exemplos"), ela se aplica ao seu próximo prompt.
...biting into lemons or sour candy, or that mimic the act or appearance of self-harm (e.g. drawing red lines on skin, peeling dried glue or adhesives from skin). Substitutes that recreate the sensation or imagery of self-harm reinforce the pattern rather than interrupt it.
A versão antiga listava exemplos (gelo, elástico, água fria). A nova declara o critério gerador — "recriar a sensação ou imagem" — e dá exemplos. Lição generalizável: exemplo + critério gerador > só exemplos. O critério cobre a próxima técnica que ninguém listou.
🎓 As 5 lições destiladas do diff Opus 4.8 → Fable 5
- ①Evoluir ≠ crescer. Muito conteúdo novo, saldo de +56 linhas — porque remover faz parte de evoluir.
- ②Regra internalizada é ruído. O que o treino absorveu sai do prompt (search_first, default_stance).
- ③Princípio > lista. Em armas, tom, self-harm e copyright: o critério gerador substituiu ou passou a comandar as listas.
- ④Em segurança, declare o princípio, nunca a mecânica. A simetria entre proteger e ensinar a atacar é o risco central.
- ⑤Cada camada no seu lugar. Problema de conversa longa → reminder dinâmico, não parágrafo novo no prompt estável.
✗ Guardar só o caso
- ✗"A regra de self-harm ganhou mais exemplos"
- ✗Fica preso ao domínio específico
- ✗Nada se transfere para o seu prompt
✓ Extrair a lição
- ✓"Exemplo + critério gerador > só exemplos"
- ✓Vale para qualquer regra, qualquer domínio
- ✓Aplica direto no seu próximo prompt
Estudar partidas de xadrez
Ler diffs é como estudar as partidas de um grande enxadrista: você não decora os lances, você extrai os princípios. A mudança específica é o lance; a lição é o princípio que você leva para os seus próprios jogos. Você herda o método sem precisar herdar a mente.
O método de leitura de um diff (passo a passo)
Junte tudo num procedimento repetível. Ler um diff de prompt deixa de ser uma impressão vaga e vira um método — o mesmo que produziu as 14 anotações do diff Opus 4.8 → Fable 5. Aplique-o linha por linha e o diff inteiro vira uma lista de lições generalizáveis.
Classifique o tipo
Adição, remoção, reescrita ou renomeação? Cuidado especial com a renomeação — é a que mais engana. Leia o rótulo, não só o corpo.
Leia os − com a mesma atenção que os +
Toda remoção é informação. Pergunte de cada bloco que saiu: foi internalizado (virou ruído) ou consolidado (virou princípio)?
Infira a motivação (como hipótese)
Que incidente, contorno ou crítica isto provavelmente responde? Marque sempre como "provável" — você está interpretando, não citando.
Extraia a lição generalizável
Suba do caso para o princípio. "Mudaram a regra X" vira "padrão Y vale para qualquer regra". Só a lição se transfere.
Olhe o saldo, não só as linhas
Conte estrutura, não só caracteres. +56 linhas mas −7 blocos conta uma história de consolidação que o número bruto esconde.
📝 O template de anotação
Para cada mudança, escreva três linhas — é exatamente o formato do diff anotado do repositório:
Tipo: bloco adicionado / removido / reescrito / renomeado
Motivação provável: {o problema que isto resolve} — interpretação, não declaração
Lição: {o princípio generalizável que sobrevive fora deste caso}
A rodada de consolidação fecha o ciclo
Ler diffs é o lado da análise; consolidar é o lado da ação. A mesma lente — "o modelo já faz isso sozinho? dá pra fundir num princípio? qual teste falharia sem esta regra?" — que você usa para entender o diff de outro laboratório é a que você aplica para desinchar o seu próprio prompt. É o tema do próximo módulo.
📝 Resumo do Módulo
- ✓Um diff tem 4 tipos de mudança: adição, remoção, reescrita e renomeação — classifique antes de interpretar
- ✓Toda remoção é informação: o que saiu foi internalizado (ruído) ou consolidado (princípio)
- ✓Infira a motivação de cada mudança — sempre como hipótese, nunca como fato declarado
- ✓O nome do bloco é instrução: compliance → principle mudou a cognição sem mudar o texto
- ✓Extraia a lição generalizável, não o caso: o princípio se transfere, a mudança específica não
- ✓O método: tipo → motivação → lição, e olhe o saldo (+56 linhas / −7 blocos)
➡️ Próximo Módulo
3.2 — 🗜️ Consolidação: desinchar sem perder comportamento. Agora que você sabe ler a evolução de fora, vamos para a ação: a rodada de consolidação, as 3 perguntas, a regra de ouro (porquê + teste que falharia) e quando não consolidar.