//
Busque em todas as páginas da documentação
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.
| 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 |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
É 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
anthropicpara 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.