Melhores Práticas das Regras Claude

Esta página destila todas as listas de regras na seção Claude Rules & Best Practices em um único checklist autônomo - a versão positiva e aplicável de cada regra, agrupada por categoria, destinada a ser trabalhada durante uma revisão de prontidão para produção ou uma auditoria periódica da equipe.

Como Usar Este Checklist

• Trabalhe por categoria, não de cima para baixo por número - uma equipe que adota essas regras pela primeira vez geralmente começa com A e D antes de abordar o restante.
• Trate cada item de verificação como algo para o qual você pode apontar evidências - um valor de configuração, uma regra de lint, um comentário de revisão ou um ADR - não apenas uma crença.
• Use-o como um portão de prontidão para produção antes que um recurso com Claude chegue a usuários reais ou a um orçamento real.
• Revise a lista completa em uma cadência fixa e imediatamente após qualquer incidente cuja causa raiz remonte a uma regra ausente.

A - Seleção de Modelo

• Combine o nível do modelo com a complexidade da tarefa por padrão. Classificação e extração começam com Haiku, trabalho geral com Sonnet, raciocínio complexo de várias etapas com Opus e o trabalho agentico de longo horizonte mais exigente com Fable.
• Exija evidências antes de escalar para um nível mais pesado. Uma mudança de nível é apoiada por uma revisão de amostra falha ou uma lacuna de qualidade medida, não por um palpite.
• Diminua o nível de rotas comprovadas em uma cadência regular. Qualquer rota onde um nível mais barato tenha correspondido à qualidade em uma amostra representativa é movida para baixo e monitorada.
• Mantenha caminhos síncronos voltados para o usuário fora do nível mais pesado, a menos que a UX possa tolerar a latência. Raciocínio pesado tolerante à latência é movido para processamento assíncrono ou em lote.
• Documente a decisão de nível para cada rota de produção. Uma entrada de configuração ou comentário nomeando o modelo e o motivo evita alterações silenciosas e não revisadas posteriormente.

B - Higiene de Prompt e Contexto

• Estruture cada prompt em seções claramente rotuladas. Papel, tarefa, restrições e formato de saída recebem seus próprios blocos em vez de serem misturados em prosa não estruturada.
• Exija um proprietário e um motivo para cada adição de prompt do sistema. Prompts que crescem por acréscimo não revisado degradam de maneiras que ninguém consegue rastrear até uma mudança específica.
• Apare o contexto proativamente, não reativamente. Resultados de ferramentas obsoletos e turnos substituídos são descartados antes que degradem a qualidade da resposta, não depois que um usuário percebe que algo está errado.
• Mantenha o formato de saída consistente para o mesmo tipo de tarefa em todos os locais de chamada. Um parser escrito para uma rota deve funcionar para todas as rotas que produzem esse mesmo tipo de saída.
• Pode instruções que ninguém pode justificar atualmente. Se ninguém na equipe puder explicar por que uma linha está no prompt do sistema, isso é um sinal para testar a remoção dela, não para deixá-la indefinidamente.

C - Design de Ferramentas

• Escopo cada ferramenta para exatamente uma ação bem definida. Uma ferramenta que faz várias coisas não relacionadas é dividida até que cada peça possa ser raciocinada e permissãoada independentemente.
• Nomeie ferramentas pelo que elas fazem, não como são implementadas. A nomeação permanece consistente em todo o conjunto de ferramentas para que a seleção de ferramentas do modelo seja previsível.
• Valide as entradas e saídas da ferramenta separadamente, ambas antes de cruzarem um limite de confiança. Entrada ruim atinge sistemas reais; saída ruim corrompe o próximo turno do modelo - ambos precisam de sua própria verificação.
• Bloqueie chamadas de ferramentas destrutivas ou irreversíveis por confirmação. Exclusões, pagamentos e gravações de produção nunca executam automaticamente sem uma etapa humana ou uma exceção revisada.
• Revise todo o conjunto de ferramentas em busca de propósito sobreposto, não apenas cada ferramenta isoladamente. Ambiguidade entre duas ferramentas que podem realizar uma tarefa é resolvida antes que cause comportamento inconsistente em produção.

D - Controle de Custos

• Armazene em cache prefixos de prompt estáveis atrás de um breakpoint. Prompts do sistema e definições de ferramentas que não variam por solicitação são posicionados para que possam ser realmente reutilizados.
• Roteie trabalho em lote não sensível à latência através da API de Lotes. Preços em tempo real são reservados para solicitações que genuinamente precisam de uma resposta síncrona.
• Defina um orçamento de tokens rastreável e alertável por equipe. Cada equipe que consome a API Claude tem um teto de gastos sobre o qual alguém é alertado antes de ser excedido, não depois que a fatura chega.
• Meça o uso real de tokens contra estimativas pré-chamada. Suposições de custo são verificadas contra campos de usage com frequência suficiente para capturar desvios enquanto ainda são pequenos.
• Reavalie as alavancas de custo sempre que a linha de modelos mudar. Uma estratégia de cache ou lote ajustada para uma geração de modelo é verificada novamente contra a próxima.

E - Guardrails de Segurança

• Aplique o menor privilégio a todas as credenciais que um sistema com Claude pode alcançar. Nenhuma ferramenta, servidor MCP ou integração possui acesso mais amplo do que sua tarefa estritamente exige.
• Trate a saída do modelo como entrada não confiável em todos os lugares onde ela toca um sistema real. Texto gerado e argumentos de ferramentas são validados e parametrizados, nunca interpolados diretamente em um comando, consulta ou caminho.
• Registre cada chamada de ferramenta sensível independentemente da transcrição da conversa. Chamadas destrutivas ou que tocam dados têm uma trilha de auditoria que sobrevive mesmo que a transcrição seja editada, truncada ou perdida.
• Mantenha segredos fora de prompts, mensagens do sistema e arquivos de memória completamente. Credenciais vivem em um cofre ou variável de ambiente, nunca em texto que o modelo possa ler de volta.
• Isole conteúdo externo não confiável de instruções em nível de operador. Documentos recuperados e conteúdo da web são estruturalmente separados da autoridade em nível de sistema para que uma instrução incorporada não possa se disfarçar como um deles.

F - Governança e Prática de Equipe

• Atribua um proprietário explícito para as regras Claude da equipe. Regras degradam para inconsistência no momento em que ninguém é responsável por mantê-las atualizadas.
• Transforme a causa raiz de cada incidente em uma regra, não apenas em uma correção pontual. Um erro que não é capturado como uma regra aplicável tende a recorrer em um local de chamada diferente escrito por um engenheiro diferente.
• Revise os conjuntos de regras em uma cadência fixa, não apenas depois que algo quebrar. Uma passagem trimestral captura regras que ficaram obsoletas à medida que a linha de modelos ou o produto mudou.
• Torne os desvios de uma regra uma exceção explícita e revisada. Um padrão que é silenciosamente substituído em um lugar é desvio de decisão; um padrão que é deliberadamente substituído com uma razão documentada é uma decisão.
• Mantenha o conjunto de regras pequeno o suficiente para que a equipe possa realmente tê-lo em mente. Um conjunto de regras muito grande para lembrar é ignorado, o que é funcionalmente o mesmo que não ter regras.

FAQs

Relacionados

• Como Regras Opinativas Previnem Incidentes de Produção do Claude - o modelo mental por trás de por que cada item nesta página é escrito como uma regra aplicável.
• As Regras Principais do Claude: Um Guia Rápido - o mesmo conjunto de regras organizado por categoria com links para detalhes completos.
• Regras de Guardrail de Segurança Que Todo Tech Lead Deve Aplicar - os detalhes completos por trás da categoria E.
• Regras de Controle de Custos: Cache, Lote e Disciplina de Orçamento de Tokens - os detalhes completos por trás da categoria D.

Versões de Stack: 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 - e o SDK oficial anthropic para Python (último lançamento 0.x). Nomes de modelos, preços e versões de SDK mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.