Como pedir análise de um texto longo ao Claude sem receber um resumo genérico

Você joga um PDF de duzentas páginas no Claude, escreve “resuma isso” e recebe de volta um texto tão vago que poderia ter sido escrito sem ninguém abrir o arquivo

Aí vem a conclusão fácil: “esse modelo não leu o documento”

Só que o gargalo quase nunca é o modelo, é a forma do pedido

“Resuma” não diz o que importa, não diz qual pedaço olhar e não diz como a resposta deve sair, então o Claude devolve a média de tudo: um resumo correto e inútil

Neste post a gente monta o pedido de análise peça por peça (critério, recorte, formato e a ordem certa dentro do prompt), com exemplos prontos pra colar

Bora? 🙂

O que você precisa antes de montar o pedido

Antes do prompt, os limites, porque eles mudam o que dá pra fazer

No Claude.ai o teto é de 30 MB por arquivo, e PDF com mais de 1000 páginas volta erro de arquivo grande demais

Tem um detalhe que pega muita gente: até 100 páginas o Claude analisa o texto E os elementos visuais do PDF (imagens, gráficos). De 101 a 1000 páginas ele processa apenas o texto, sem os elementos visuais

Ou seja: se a sua análise depende de um gráfico que está na página 400, ela simplesmente não vai acontecer. Tome cuidado com isso antes de achar que o modelo “inventou”

E a janela de contexto? O Claude Sonnet 5 tem 1 milhão de tokens, suportada por padrão

Melhor ainda: esse 1M de contexto passou a ser cobrado pelo preço padrão por token, sem multiplicador por requisição longa

Isso muda o jogo pra documento grande, porque acabou o pedágio de mandar tudo de uma vez

Falta escolher ONDE a análise vai rodar:

• Chat individual: documento único, análise que começa e termina numa sessão
• Arquivos do projeto: quando o mesmo acervo vai ser consultado em várias conversas, com referência persistente
• API: quando a análise vira rotina e você quer repetir o mesmo pedido em cima de muitos documentos

Escolhido isso, o resto é a estrutura do pedido

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Passo a passo: como estruturar o pedido de análise

A ordem aqui não é decorativa, ela é a receita da documentação de long context da Anthropic

1. Coloque o documento no topo, antes de qualquer outra coisa

A recomendação oficial é colocar documentos e entradas longas (~20 mil tokens ou mais) perto do topo do prompt, antes da query, das instruções e dos exemplos

Parece bobo, mas é o passo que mais muda resultado sem custo nenhum

O erro comum deste passo: escrever a pergunta primeiro, caprichar nas instruções e colar o texto lá embaixo, tudo ao contrário

2. Envolva cada documento em tags <document> quando houver mais de um

Com vários documentos no mesmo prompt, a orientação é envolver cada um em uma tag <document>, com as subtags <document_content> e <source> (e outros metadados que fizerem sentido)

<document>
  <source>contrato-v1.pdf</source>
  <document_content>
  ...texto integral da primeira versão...
  </document_content>
</document>

<document>
  <source>contrato-v2.pdf</source>
  <document_content>
  ...texto integral da revisão...
  </document_content>
</document>

Agora o modelo consegue te responder “isso está no contrato-v2.pdf” em vez de “está no documento”

O erro comum deste passo: colar dois arquivos em sequência separados só por uma linha em branco e depois perguntar qual dos dois diz o quê

3. Separe os tipos de conteúdo em tags próprias

A mesma lógica vale dentro do prompt: envolver cada tipo de conteúdo na própria tag reduz interpretação errada

A documentação de uso de tags XML sugere coisas como <instructions>, <context> e <input>, com nomes de tag consistentes e aninhamento quando existe hierarquia natural

<context>
Este é o relatório trimestral enviado ao conselho
</context>

<instructions>
Sua tarefa é auditar as afirmações de risco
</instructions>

Se você conhece HTML, é o mesmo raciocínio de marcar o que é o quê: a tag não é enfeite, ela é fronteira

O erro comum deste passo: misturar instrução e material no mesmo bloco, e o modelo tratar um pedaço do documento como ordem sua

4. Declare o critério de análise em vez de pedir “resuma”

Critério é a pergunta por trás da pergunta: o que faz uma parte do texto ser relevante e outra não

Compare

Ruim:
Resuma este relatório

Bom:
Avalie este relatório sob um único critério: toda afirmação de risco
precisa vir com um número ou uma fonte citada no próprio documento
Liste as afirmações que não cumprem isso

O erro comum deste passo: achar que “resuma detalhadamente” ou “faça uma análise profunda” é critério. Não é, é volume

5. Delimite o recorte

Recorte é o alvo: qual parte, qual seção, qual período, qual pergunta

Considere apenas a seção 4 (Projeções) e o anexo B
Ignore a introdução e o glossário

O documento inteiro entra no prompt, mas a tarefa mira num pedaço. São coisas diferentes

O erro comum deste passo: mandar o acervo completo pra uma pergunta que vive em duas páginas e depois estranhar a resposta espalhada

6. Peça as citações relevantes antes da execução

Essa é a dica que mais gente ignora: em tarefas com documento longo, pedir que o Claude cite primeiro as partes relevantes ajuda a cortar o ruído do resto do conteúdo

Primeiro, extraia as citações literais do documento que se relacionam
com o critério acima
Depois, e só depois, faça a análise usando apenas essas citações

Bônus: você ganha rastreabilidade. Dá pra conferir cada conclusão contra o trecho que a gerou

O erro comum deste passo: pedir as citações DEPOIS da conclusão, aí elas viram justificativa e não fundamento

7. Especifique o formato de saída

Formato é o que separa uma resposta usável de um textão

Responda em uma tabela com as colunas:
Afirmação | Trecho citado | Tem número ou fonte? | Risco de erro (alto/médio/baixo)
Nada de parágrafo de introdução, comece pela tabela

O erro comum deste passo: pedir “de forma organizada”. Organizada pra quem? Diga a estrutura exata que você quer receber

8. Feche com a pergunta no final do prompt

A documentação da Anthropic afirma que colocar a query no fim do prompt melhora a qualidade da resposta em até 30% nos testes, especialmente com entradas complexas e de múltiplos documentos

Então a espinha do prompt fica assim: documento, contexto, instruções, formato, pergunta

O erro comum deste passo: terminar o prompt com o documento e deixar a pergunta perdida no meio do caminho

Quatro pedidos de análise que substituem o “resuma isso”

Aqui cada exemplo aplica a mesma tríade: critério, recorte e formato. Copia, troca o miolo e usa

Auditar contradições entre dois documentos:

<instructions>
Critério: encontre pontos em que os dois documentos afirmam coisas
incompatíveis sobre o mesmo assunto (prazo, valor, responsável, escopo)
Recorte: considere apenas cláusulas contratuais, ignore preâmbulo e anexos
Formato: tabela com Assunto | O que o doc A diz (citação) | O que o doc B diz
(citação) | Tipo de conflito
Primeiro extraia as citações, depois compare
</instructions>

Quais incompatibilidades existem entre os dois documentos?

Extrair decisões e responsáveis de uma ata longa:

<instructions>
Critério: uma decisão só conta se alguém ficou com a ação, ou se ficou
explícito que ninguém ficou
Recorte: apenas o que foi decidido, não o que foi debatido
Formato: lista com Decisão | Responsável | Prazo citado | Trecho da ata
Se o responsável não aparecer no texto, escreva “não definido na ata”
</instructions>

Quais decisões saíram desta reunião?

Repare no “se não aparecer, escreva não definido”: isso é o que impede o modelo de preencher buraco com achismo

Comparar uma proposta com um critério declarado:

<context>
Nossa régua de aprovação: prazo máximo de 90 dias, escopo fechado,
e suporte incluso por 6 meses
</context>

<instructions>
Critério: avalie a proposta item a item contra a régua acima
Recorte: apenas as seções de escopo, cronograma e suporte
Formato: para cada item da régua, responda Atende / Não atende / Não menciona,
com a citação que sustenta o veredito
</instructions>

Esta proposta passa na nossa régua?

Mapear o que o texto NÃO responde:

Esse é o meu favorito, e quase ninguém pede

<instructions>
Critério: liste as perguntas que um leitor cético faria e que este documento
deixa sem resposta
Recorte: o documento inteiro
Formato: lista de lacunas, cada uma com a seção onde a resposta deveria estar
Não sugira respostas, apenas aponte a ausência
</instructions>

O que falta neste documento?

O resumo te conta o que está lá. A lacuna te conta o que vai te morder depois 😀

O que a prática ensina sobre pedir análise longa

Aqui entra o que eu venho fazendo no dia a dia, e o laboratório foi o Claude Code, não um PDF de contrato

Mas o hábito é o mesmo, se liga

No vídeo eu mostro a criação de uma skill num arquivo skill.md com anatomia definida (nome do arquivo, nome, descrição e o que ela deve fazer) pra verificar a qualidade de um componente, listando dentro dela todos os pontos que deveriam ser checados

Isso é o passo 4 e o passo 7 escritos uma vez só, pra não repetir a cada pedido

E o resultado apareceu: quando rodei a skill num componente específico, a resposta veio no formato exato descrito no arquivo, com seção de pontos fortes e o que estava bom ou ruim, em vez de texto livre

Outra coisa que eu mostro é usar o arroba pra referenciar um arquivo específico no pedido, apontando a análise pra um componente concreto em vez de deixar o alvo em aberto

Recorte, de novo. O alvo explícito vale mais que qualquer adjetivo no prompt

Em tarefas mais críticas eu mudo pro modo de planejamento com shift+tab e peço primeiro as abordagens possíveis, cada uma descrita, pra comparar antes de escolher qual seguir

É a mesma ideia do passo 6: eu quero o material bruto na mesa antes do veredito

E eu quebro o pedido em etapas: primeiro entender o filtro ou o problema, depois planejar, só então implementar

Mandar tudo junto é o equivalente ao “resuma isso”

Tem também o lado chato da coisa: contexto acumulado na sessão deixa as respostas mais lentas e consome mais tokens

Eu uso /compact quando sinto a tarefa arrastada, e /clear quando mudo totalmente de assunto

O /compact mantém um lastro resumido do que estava sendo feito, e eu conferi esse resumo na tela depois de rodar o comando (vale muito a pena gerenciar o contexto no Claude Code com intenção, e não só quando trava)

Outro hábito: eu separo o contexto por áreas, com o arquivo principal apontando pra arquivos menores por assunto, e o modelo só consulta o arquivo da área quando a tarefa exige

E duas observações de bastidor que eu levei na cara

Quando adicionei uma regra escrevendo a frase com hashtag direto no terminal, além de gravar a regra o modelo já foi validar o código existente contra ela. Não pedi, ele foi

E comandos recém-criados só apareceram pra mim depois de reiniciar a sessão. Já perdi tempo achando que tinha errado a sintaxe

No vídeo abaixo eu mostro esses hábitos rodando na prática, e dá pra ver bem como o pedido estruturado muda a resposta:

Quando o documento não cabe: projetos e Files API

Uma hora o acervo passa do que cabe confortável numa conversa. Aí o caminho muda

1. Suba os arquivos na seção Files de um projeto

No Claude.ai dá pra enviar arquivos pro chat individual ou pra seção de arquivos de um projeto, e nesse segundo caso eles ficam como referência persistente entre conversas

O erro comum deste passo: reenviar o mesmo PDF em toda conversa nova, gastando tempo e contexto à toa

2. Deixe o RAG do projeto entrar sozinho

Quando o conhecimento do projeto se aproxima do limite da janela de contexto, os projetos ativam RAG automaticamente, sem configuração

A capacidade do projeto expande em até 10x e o Claude passa a buscar os trechos relevantes em vez de carregar tudo. Se o conhecimento diminuir, ele volta pro modo de contexto

Que RAG? É o modelo buscando os pedaços que interessam do seu acervo, em vez de tentar segurar o acervo inteiro na cabeça de uma vez

O erro comum deste passo: procurar um botão pra ligar isso. Não tem botão, é automático

3. Organize pra busca funcionar a seu favor

As boas práticas recomendadas são diretas: nomear bem os arquivos, agrupar documentos relacionados no mesmo projeto e citar o documento pelo nome na pergunta pra direcionar a busca

Usando o relatorio-q3-2026.pdf, quais projeções não têm fonte citada?

O erro comum deste passo: arquivo chamado documento-final-v3-REAL.pdf e depois perguntar “no relatório trimestral…”. Cite o nome que está lá

4. Na API, respeite os limites da requisição

A API tem régua própria, diferente do app: até 600 imagens ou páginas de PDF por requisição (100 em modelos com janela de 200 mil tokens) e limite de 32 MB por requisição nos endpoints padrão

O erro comum deste passo: assumir que o que passa no app passa na API

5. Use a Files API pra não reenviar conteúdo

Dá pra subir o arquivo pela Files API e referenciar por file_id, mantendo o payload pequeno em vez de mandar o conteúdo inteiro em cada requisição

Se você vai rodar vinte análises em cima do mesmo documento, esse passo é o que separa uma rotina barata de uma cara

Resumo dos limites, pra bater o olho:

Conclusão

A régua de bolso cabe em quatro palavras: critério, recorte, formato, pergunta no final

O documento vai pro topo do prompt, cada arquivo dentro da sua tag <document>, instrução separada do material, citações relevantes antes da conclusão e a query fechando o prompt

O resto (janela de 1 milhão de tokens, projeto com RAG, Files API) é infraestrutura. Ajuda muito, mas não conserta um pedido mal feito

Próximo passo, e faça o teste hoje mesmo: pega um documento real que você já jogou no Claude, reescreve o pedido nesse formato e roda os dois lado a lado

A diferença entre as duas saídas costuma ser desconfortável de tão grande 😛

Até o próximo post!