As Regras Essenciais do Claude: Uma Lista de Referência Rápida
Esta página condensa todas as regras aplicáveis que este site destila para o envio do Claude em produção - seleção de modelo, higiene de prompt e contexto, design de ferramentas, controle de custos e salvaguardas de segurança - em uma única página que você pode digitalizar durante uma revisão de código ou uma retrospectiva de incidente.
Intencionalmente, não há longas explicações.
Cada linha se vincula ao artigo que cobre o raciocínio completo, exemplos e casos extremos.
- Mantenha esta página aberta durante a revisão de pull requests para qualquer código que chame a API do Claude.
- Trate cada regra como um padrão, não como um absoluto - desvios devem ser uma exceção deliberada e revisada, não uma silenciosa.
- Releia esta página sempre que a linha de modelos mudar (nova versão do Opus, Sonnet, Haiku ou Fable) - várias regras são específicas do nível do modelo.
- Use as tabelas de categoria para integrar um novo engenheiro às convenções de Claude da equipe em uma única sessão.
- Combine esta página com Melhores Práticas das Regras do Claude, que reafirma cada regra aqui como um item de checklist aplicável.
| Regra | Padrão | Detalhe completo |
|---|
| Corresponder o nível do modelo à complexidade da tarefa | Haiku para classificação/extração, Sonnet para trabalho geral, Opus para raciocínio complexo de várias etapas, Fable para o trabalho de agente de longo prazo mais exigente | Regras de Seleção de Modelo |
| Nunca use o modelo mais capaz por padrão "para garantir" | Comece com o nível mais barato que atende ao padrão de qualidade, escale apenas com evidências | Regras de Seleção de Modelo |
| Reavaliar a escolha do nível a cada lançamento de modelo | Uma regra fixada a um perfil de custo/latência antigo de um modelo pode ficar desatualizada da noite para o dia | Regras de Seleção de Modelo |
| Roteie caminhos sensíveis à latência para longe do nível mais pesado | Opus e Fable trocam latência por profundidade; não os coloque em um caminho síncrono voltado para o usuário sem um motivo | Regras de Seleção de Modelo |
| Regra | Padrão | Detalhe completo |
|---|
| Estruturar prompts com seções explícitas | Papel, tarefa, restrições e formato de saída recebem seu próprio bloco claramente rotulado | Regras de Higiene de Prompt e Contexto |
| Manter prompts do sistema anexáveis em revisão, não anexáveis na prática | Cada adição precisa de um proprietário nomeado e um motivo; remova instruções que ninguém mais pode justificar | Regras de Higiene de Prompt e Contexto |
| Aparar o contexto antes de cada solicitação, não depois que ele falha | Descarte resultados de ferramentas obsoletos e turnos substituídos em vez de deixar a transcrição crescer sem limites | Regras de Higiene de Prompt e Contexto |
| Manter o formato de saída consistente entre os locais de chamada | O mesmo tipo de tarefa deve produzir saída analisável da mesma forma em todos os lugares onde é solicitada | Regras de Higiene de Prompt e Contexto |
| Regra | Padrão | Detalhe completo |
|---|
| Escopo das ferramentas de forma restrita | Uma ferramenta, uma ação bem definida - não uma ferramenta de propósito geral "faça qualquer coisa" | Regras de Design de Ferramentas |
| Nomear ferramentas pelo que elas fazem, não como são implementadas | reembolsar_pedido, não chamar_endpoint_de_cobrança | Regras de Design de Ferramentas |
| Validar toda entrada da ferramenta antes de executá-la | Nunca confie nos argumentos do modelo como pré-sanitizados | Regras de Design de Ferramentas |
| Validar toda saída da ferramenta antes que ela reentre no contexto | Um resultado malformado ou inesperadamente grande deve ser capturado, não passado silenciosamente de volta para o modelo | Regras de Design de Ferramentas |
| Bloquear chamadas de ferramentas destrutivas ou irreversíveis com confirmação | Exclusões, pagamentos e gravações em produção nunca são "dispare e esqueça" | Regras de Design de Ferramentas |
| Regra | Padrão | Detalhe completo |
|---|
| Armazenar em cache prefixos de prompt estáveis | Prompts do sistema e definições de ferramentas que não mudam por solicitação pertencem a um ponto de interrupção de cache | Regras de Controle de Custos |
| Agrupar solicitações não sensíveis à latência | Use a API de Lotes para trabalho em massa em vez de pagar preços em tempo real | Regras de Controle de Custos |
| Definir um orçamento de tokens por equipe | Cada equipe que consome a API do Claude recebe um teto de gastos rastreável e que gera alertas | Regras de Controle de Custos |
| Medir o uso real de tokens, não estimá-lo | Compare os campos usage com as estimativas pré-chamada para detectar desvios precocemente | Regras de Controle de Custos |
| Regra | Padrão | Detalhe completo |
|---|
| Escopo de permissões de API e ferramentas de forma restrita | O menor privilégio se aplica a todas as credenciais que um sistema com tecnologia Claude pode alcançar | Regras de Salvaguarda de Segurança |
| Validar a saída do modelo antes de agir sobre ela | Trate o texto gerado e os argumentos da ferramenta como entrada não confiável, não como uma instrução confiável | Regras de Salvaguarda de Segurança |
| Registrar todas as chamadas de ferramentas sensíveis | Chamadas destrutivas ou que manipulam dados precisam de uma trilha de auditoria independente da transcrição da conversa | Regras de Salvaguarda de Segurança |
| Nunca coloque segredos em um prompt ou arquivo de memória | Credenciais pertencem a um cofre ou variável de ambiente, nunca em texto que o modelo possa ler | Regras de Salvaguarda de Segurança |
Esta página é um substituto para os artigos completos das regras?
Não. É um auxílio de escaneamento - cada linha existe para lembrá-lo de que uma regra existe e apontá-lo para o artigo com o raciocínio completo, exemplos e exceções.
Por que esta página substitui uma página de noções básicas da seção?
Como esta seção é um livro de receitas de regras/listas de verificação em vez de uma seção de tutorial, uma única referência condensada cumpre o papel que uma introdução "básica" teria em uma seção de receitas de código - é a página em que um leitor pousa primeiro para se orientar.
Qual categoria de regra um novo membro da equipe deve ler primeiro?
Regras de Seleção de Modelo, porque a escolha do nível do modelo afeta o perfil de custo e latência de todas as outras decisões nesta página. Regras de Controle de Custos é o próximo passo natural.
Com que frequência esta página deve ser revisitada?
No mínimo, sempre que a linha de modelos mudar, e sempre que uma revisão de incidente revelar uma regra que esta página não possui ou tem incorreta.
Estas regras são obrigatórias ou padrões?
Padrões. Cada linha pode ser substituída por um motivo deliberado e revisado - o ponto é que os desvios são decisões explícitas, não acidentes.
Qual é a diferença entre esta página e as Melhores Práticas das Regras do Claude?
Esta página agrupa as regras por categoria com uma única linha de padrão e um link. Melhores Práticas das Regras do Claude reafirma cada regra como um item de caixa de seleção autônomo que você pode marcar durante a revisão, sem precisar do agrupamento por categoria.
Por que a validação de entrada da ferramenta é listada separadamente da validação de saída da ferramenta?
Porque elas falham de maneiras diferentes. Entrada não validada permite que um argumento malformado ou malicioso chegue aos seus sistemas; saída não validada permite que um resultado ruim da ferramenta corrompa silenciosamente a próxima vez do modelo. Ambas precisam de uma verificação, e confundi-las tende a significar que apenas uma é construída.
O "escopo restrito das ferramentas" entra em conflito com dar a um agente capacidade suficiente para ser útil?
Não - escopo restrito significa que cada ferramenta individual faz uma coisa bem definida, não que o agente tenha poucas ferramentas no geral. Um agente com dez ferramentas restritas é mais seguro e mais depurável do que um com duas ferramentas amplas que fazem várias coisas não relacionadas.
Por que o controle de custos inclui uma regra sobre a medição do uso real?
Porque um modelo de custo que nunca é verificado contra os campos de usage reais se desvia silenciosamente - cache, lotes e orçamentos assumem que você pode dizer quando eles param de funcionar, e a única maneira de saber é medindo.
O cache de prompt vale a pena para todas as solicitações?
Não - ele compensa apenas quando um prefixo estável é reutilizado em um número suficiente de solicitações para cobrir o custo de gravação do cache. Veja Regras de Controle de Custos para a matemática de ponto de equilíbrio.
O que conta como uma chamada de ferramenta "sensível" que precisa ser registrada?
Qualquer coisa que leia ou escreva dados fora da própria conversa - gravações em banco de dados, pagamentos, e-mails enviados, arquivos excluídos ou qualquer chamada para um sistema com seus próprios requisitos de auditoria. Veja Regras de Salvaguarda de Segurança para a lista completa.
Esta página deve ser o único documento de regras que uma equipe mantém?
É um ponto de partida, não um teto. Equipes com riscos específicos de domínio (dados regulamentados, transações financeiras) devem estender essas categorias com suas próprias regras em vez de tratar esta lista como exaustiva.
Versões da Pilha: 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 (última versão 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.