Dividindo uma Tarefa Grande em um Plano que o Claude Pode Executar
Uma solicitação vaga e grande raramente produz um bom resultado do Claude na primeira tentativa.
"Escreva um relatório sobre o desempenho de marketing do nosso Q3" é um objetivo, não uma instrução que o Claude pode executar de forma limpa, pois oculta uma dúzia de decisões menores sobre escopo, estrutura e ordem.
Dividir esse objetivo em um plano numerado, coletar os dados, delinear as seções, redigir cada seção e, em seguida, revisar tudo, transforma uma solicitação pouco clara em uma sequência de etapas pequenas e verificáveis.
Esta página detalha como construir esse plano, como entregá-lo ao Claude e como manter o controle do trabalho à medida que ele avança em cada etapa.
Resumo
- Ideia Central: Uma tarefa grande se torna executável assim que é decomposta em uma lista numerada e ordenada de etapas menores que o Claude executa uma de cada vez.
- Por que Importa: O Claude realiza um trabalho visivelmente melhor em uma etapa estreita e bem definida do que em um objetivo aberto, e um plano é o que transforma o segundo no primeiro.
- Conceitos Chave: decomposição de tarefas (dividir uma solicitação grande em partes menores), o plano (a lista numerada em si, o ponto de referência compartilhado), execução de etapa (o Claude trabalhando em um item do plano de cada vez), elaboração de plano (pedir ao Claude para propor o plano antes de qualquer trabalho começar).
- Quando Usar: Qualquer solicitação que levaria mais de uma sessão para uma pessoa concluir, que tenha múltiplos resultados distintos, ou que você naturalmente descreveria com a palavra "e" várias vezes.
- Limitações / Compromissos: Planejar primeiro adiciona uma viagem de ida e volta antes que o trabalho real comece, e um plano muito granular se transforma em um trabalho árduo próprio, aprovando etapas triviais que não precisavam de um checkpoint.
- Tópicos Relacionados: como é a delegação multi-etapas, checkpoints e portões de revisão, refinamento iterativo, padrões de orquestração.
Fundamentos
Decomposição de tarefas é o ato de dividir uma solicitação grande em uma série de partes menores e mais específicas.
Um plano, neste contexto, é simplesmente essa decomposição escrita como uma lista numerada, na ordem em que as partes devem acontecer.
A numeração importa mais do que parece.
Um plano numerado dá a você e ao Claude um ponto de referência compartilhado, então "refazer a etapa 4" significa algo preciso, em vez de "refazer a parte sobre precificação", que depende de ambos se lembrarem do mesmo limite mental sobre o que conta como "a parte de precificação".
Pense no plano como um índice do trabalho, não no trabalho em si.
Um bom plano diz o que acontecerá e em que ordem, sem ainda conter o relatório redigido, o código escrito ou a análise finalizada; esses vêm da execução de cada etapa em sequência.
A maneira mais simples de obter um plano é, muitas vezes, pedir ao Claude por um antes de pedir que ele faça qualquer outra coisa.
Antes de começar, divida isso em um plano numerado: Preciso de um relatório de desempenho de marketing do Q3 cobrindo gastos por canal, tendências de conversão e uma recomendação para o orçamento do Q4. Não escreva o relatório ainda, apenas o plano.
O Claude normalmente retornará algo como uma lista de cinco ou seis itens: coletar os dados de origem, resumir os gastos por canal, resumir as tendências de conversão, redigir a recomendação e, em seguida, montar o relatório completo.
Essa lista agora é um plano que você pode examinar, editar, reordenar ou reduzir, antes que uma única palavra do relatório real seja escrita.
Mecânicas e Interações
Uma vez que um plano existe, o próximo passo natural é fazer com que o Claude o execute uma etapa de cada vez, em vez de tudo de uma vez.
Isso importa porque um plano executado passo a passo oferece um lugar natural para parar e analisar o trabalho no meio do processo, em vez de ver apenas um resultado final que você terá que desconstruir se algo no início deu errado.
Um padrão típico se parece com isso em termos simples.
Você pede ao Claude para redigir o plano.
Você revisa o plano e o ajusta, talvez combinando duas etapas ou adicionando uma que o Claude perdeu.
Você pede ao Claude para executar apenas a etapa um e parar por aí.
Você analisa a saída da etapa um e a aprova ou pede uma revisão.
Uma vez que a etapa um esteja correta, você passa para a etapa dois, carregando o que quer que a etapa um tenha produzido.
Esse ciclo se repete até que o plano seja concluído.
Elaborar Plano -> Revisar/Ajustar Plano -> Executar Etapa 1 -> Verificar -> Executar Etapa 2 -> Verificar -> ... -> Concluído
Cada seta nessa cadeia é um ponto de decisão, não uma transferência automática.
Você pode parar após qualquer etapa, alterar o plano no meio do caminho se a etapa dois revelar algo que a etapa um não previu, ou pedir ao Claude para pular uma etapa que se mostrou desnecessária.
Isso é diferente de entregar ao Claude a solicitação grande inteira e deixá-lo executar do início ao fim por conta própria.
Uma única instrução ininterrupta pede ao Claude para tomar todas as decisões de escopo por si mesmo, em que ordem fazer as coisas, quanta detalhe pertence a cada parte, onde estão os limites naturais, tudo isso sem verificar nenhuma dessas chamadas com você ao longo do caminho.
Um plano numerado expõe essas mesmas decisões como uma lista curta que você pode examinar em segundos, antes que qualquer trabalho real tenha sido produzido.
O plano em si não precisa ser longo para ser útil.
Um plano de três ou quatro etapas para uma tarefa moderadamente grande é normal, e um plano muito mais longo do que sete ou oito etapas é frequentemente um sinal de que a tarefa deve ser dividida em duas delegações separadas, em vez de um plano muito longo.
Considerações Avançadas e Aplicações
O quanto você depende do planejamento depende da forma da tarefa, não apenas do seu tamanho.
Uma tarefa com um único resultado, mas muitas sub-decisões ocultas, como um relatório longo, se beneficia de um plano porque são as sub-decisões que tendem a dar errado, não a formatação final.
Uma tarefa com vários resultados genuinamente separados, como "auditar nossos e-mails de onboarding e, separadamente, redigir três novos", se beneficia de um plano porque cada resultado merece seu próprio checkpoint, em vez de ser revisado como um bloco único.
Uma tarefa que é grande, mas mecanicamente repetitiva, como renomear o mesmo tipo de item em cinquenta registros, geralmente não precisa de um plano rico; uma única instrução clara com um exemplo do padrão geralmente é suficiente.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Uma instrução grande, sem plano | Mais rápido de enviar, sem viagem de ida e volta extra | Oculta decisões de escopo dentro do julgamento do Claude; erros surgem tarde, no resultado final | Tarefas pequenas e bem definidas com uma forma óbvia |
| Planejar primeiro, depois executar etapa por etapa | Expõe decisões cedo; cada etapa é verificável antes que a próxima comece | Adiciona uma viagem de ida e volta de planejamento; muitas etapas se transformam em sobrecarga de aprovação | Tarefas grandes com múltiplas seções, resultados ou sub-decisões ocultas |
| Planejar primeiro, depois executar todas as etapas de uma vez | Uma viagem de ida e volta para o plano, uma para o resultado completo; mais rápido que etapa por etapa | Perde os checkpoints intermediários; um problema na etapa um ainda aparece em todas as etapas posteriores | Tarefas onde você confia no plano, mas quer velocidade, e erros são baratos de corrigir depois |
Um plano também é uma ferramenta útil mesmo quando você já sabe aproximadamente o que quer, porque escrevê-lo expõe lacunas que você não havia notado.
Pedir ao Claude para redigir um plano para algo que você acha simples às vezes revela que a tarefa na verdade tem cinco partes distintas, não duas, o que é exatamente o tipo de coisa que é barato de capturar em um plano de um parágrafo e caro de capturar depois que um longo documento já foi escrito da maneira errada.
Qual modelo você delega a etapa de planejamento pode importar tanto quanto a estrutura do plano em si.
Para um plano com decisões estruturais reais, redigi-lo com um modelo de raciocínio mais forte, como o Claude Opus 4.8, tende a produzir uma divisão mais limpa do que um modelo mais rápido e leve, enquanto uma etapa de execução bem definida, uma vez que o plano esteja estabelecido, muitas vezes funciona perfeitamente bem no Claude Sonnet 5, o padrão atual, ou até mesmo no Claude Haiku 4.5 para etapas simples e mecânicas.
Conceitos Equivocados Comuns
- "Um plano tem que ser exaustivo para ser útil." Um plano curto com os limites corretos entre as etapas é mais útil do que um plano longo que lista cada sub-ação menor; o objetivo são etapas verificáveis, não cobertura total.
- "Pedir ao Claude para planejar primeiro apenas atrasa as coisas." Uma viagem de ida e volta de planejamento geralmente leva alguns segundos; é muito mais barato do que descobrir um erro de escopo depois que o Claude já produziu um rascunho completo baseado nele.
- "Uma vez que o plano é aprovado, ele está fixo." Um plano é um rascunho de trabalho, não um contrato; é normal ajustá-lo depois que a etapa um ou dois revela algo que o plano original não antecipou.
- "Executar etapa por etapa é sempre mais seguro do que executar tudo de uma vez." Etapa por etapa adiciona checkpoints, mas também adiciona sobrecarga; para um plano em que você confia e erros de baixo custo, executar o plano inteiro de uma vez pode ser a escolha mais eficiente.
- "Um plano numerado só é útil para tarefas muito grandes e complexas." Mesmo uma tarefa de tamanho moderado com três ou quatro partes distintas se beneficia de um plano numerado curto, principalmente porque lhe dá algo concreto para apontar ao dar feedback.
Perguntas Frequentes
O que conta como uma "tarefa grande" que precisa de um plano?
Qualquer coisa que você descreveria naturalmente com vários "e"s, qualquer coisa com mais de um resultado distinto, ou qualquer coisa que você esperaria que levasse mais de uma sessão se você a fizesse sozinho.
Eu tenho que escrever o plano sozinho, ou o Claude pode redigi-lo?
O Claude pode redigir o plano diretamente quando solicitado; um padrão comum é pedir um plano numerado primeiro e dizer explicitamente para não começar o trabalho ainda.
Quantas etapas um bom plano deve ter?
Um plano de três a sete etapas é típico para a maioria das tarefas grandes; um plano muito mais longo do que sete ou oito etapas é frequentemente um sinal de que a tarefa deve ser dividida em duas delegações separadas.
O Claude deve executar o plano inteiro de uma vez, ou uma etapa de cada vez?
Ambos podem funcionar; uma etapa de cada vez oferece um checkpoint após cada peça, enquanto executar o plano inteiro de uma vez é mais rápido, mas perde esses pontos de revisão intermediários.
O que acontece se a etapa dois revelar um problema com o plano original?
O plano pode simplesmente ser ajustado no meio do caminho; é uma referência de trabalho, não um contrato fixo, e mudá-lo após novas informações aparecerem é normal.
Planejar primeiro vale sempre a pena a viagem de ida e volta extra?
Para uma tarefa pequena e bem definida, provavelmente não, uma única instrução clara é suficiente. Para qualquer coisa com múltiplos resultados ou sub-decisões ocultas, a etapa de planejamento geralmente vale a pena.
Como um plano numerado é diferente de apenas dar ao Claude uma instrução detalhada?
Uma instrução detalhada ainda é um bloco que o Claude tem que interpretar e estruturar por conta própria; um plano numerado torna essa estrutura explícita e visível para você antes que qualquer trabalho real aconteça.
Posso pular uma etapa do plano depois que ela for aprovada?
Sim, se uma etapa se mostrar desnecessária quando você vir os resultados anteriores, você pode dizer ao Claude para pulá-la e seguir para a próxima.
Um plano numerado ajuda a dar feedback depois?
Sim, referir-se à "etapa 4" é preciso de uma forma que descrever uma seção de memória não é, o que torna o feedback mais rápido e menos ambíguo para ambos os lados.
Qual modelo Claude deve redigir o plano versus executar as etapas?
Um modelo de raciocínio mais forte, como o Claude Opus 4.8, tende a produzir uma divisão estrutural mais limpa, enquanto etapas de execução bem definidas geralmente funcionam bem no Claude Sonnet 5, o padrão atual, ou no Claude Haiku 4.5 para etapas simples e mecânicas.
E se o primeiro rascunho do plano do Claude estiver errado ou faltando algo?
Trate-o da mesma forma que qualquer outro rascunho: aponte o que está faltando ou desordenado e peça um plano revisado antes que a execução comece, em vez de prosseguir com um plano que você já sabe que está incorreto.
Um plano é a mesma coisa que um checkpoint?
Não, o plano é a estrutura numerada do trabalho; um checkpoint é a pausa de revisão que você insere entre as etapas, o plano é o que faz essas pausas pousarem em locais sensatos.
Relacionados
- Como é a Delegação Multi-Etapas com o Claude - o conceito mais amplo de dar ao Claude um objetivo e um plano em vez de uma instrução.
- Noções Básicas de Delegação Multi-Etapas - um primeiro passo prático para dar ao Claude uma tarefa multi-etapas com um checkpoint.
- Checkpoints e Portões de Revisão Humana em um Fluxo de Trabalho Delegado - como inserir pausas de revisão entre as etapas de um plano.
- Quando Delegar Totalmente vs Manter o Claude em um Loop Fechado - decidindo quanta parte de um plano deixar o Claude executar sem verificar.
- Percorrendo um Ciclo de Refinamento Iterativo com o Claude - o que acontece dentro de uma única etapa quando o primeiro resultado precisa de revisão.
- Padrões Comuns de Orquestração para Encadear Habilidades e Rotinas - padrões para conectar as etapas de um plano em um fluxo de trabalho maior.
Versões do modelo: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão), e Claude Haiku 4.5. Nomes de modelos, preços e recursos de produtos mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.