Prompts de Sistema do Claude: Como Definir Limites de Tom para Documentação Técnica

A documentação técnica frequentemente falha de maneiras sutis antes de falhar factualmente. Um rascunho pode ser preciso, mas ser casual demais, promocional demais, verboso demais, vago demais sobre incertezas ou inconsistente com o restante do conjunto de documentação. Se você usa o Claude para produzir guias de API, artigos de solução de problemas, notas de versão, runbooks internos ou documentação para desenvolvedores, o prompt de sistema é um dos melhores lugares para definir esses limites de escrita persistentes.

Há também uma mudança atual no comportamento do modelo que vale a pena notar. A partir de setembro de 2026, a documentação de descontinuação da Anthropic afirma que temperature, top_p e top_k estão descontinuados para o Claude Opus 4.7 e versões posteriores, bem como para o Claude Mythos Preview, sendo recomendado o uso de prompts para controle de comportamento. Isso torna as instruções explícitas de estilo em nível de sistema mais importantes do que receitas antigas que tentavam moldar o tom principalmente através de parâmetros de amostragem. Veja as diretrizes de descontinuação de modelos e API da Anthropic.

O que um “limite de tom” deve realmente controlar?

Um limite de tom deve definir o comportamento de comunicação que permanece estável em muitas solicitações de documentação. Não se trata apenas de “soar profissional”. Um limite útil geralmente cobre cinco coisas: público, voz, nível de detalhe, linguagem aceitável para incertezas e hábitos de formatação.

Por exemplo, um assistente de documentação voltado para desenvolvedores pode ser instruído a escrever em um tom profissional e neutro, explicar termos desconhecidos na primeira utilização, preferir frases diretas em vez de linguagem de marketing, distinguir fatos confirmados de suposições e usar cabeçalhos e blocos de código apenas quando melhorarem a navegação.

As diretrizes atuais de prompting da Anthropic recomendam explicitamente instruções claras e diretas, contexto sobre por que um comportamento é importante, exemplos de tom e estrutura, e tags XML quando um prompt mistura diferentes tipos de informações. Também afirma que dar ao Claude um papel no prompt de sistema ajuda a focar o comportamento e o tom. Veja as melhores práticas de prompting da Anthropic.

As regras de tom devem ficar no prompt de sistema ou no prompt do usuário?

Coloque regras duráveis no prompt de sistema e instruções específicas da tarefa no prompt do usuário. O prompt de sistema é o lugar certo para regras como “escreva para desenvolvedores de software”, “evite afirmações de marketing”, “declare incerteza em vez de adivinhar” e “use prosa técnica concisa”. A mensagem do usuário deve descrever a tarefa atual: por exemplo, “Escreva um guia de migração da versão 4 para a versão 5 usando estas notas de versão”.

Essa separação reduz a repetição e torna seu pipeline de documentação mais fácil de testar. Também evita que uma única solicitação de tarefa redefina toda a sua voz editorial.

Um padrão simples de prompt de sistema

<role>
Você é um escritor de documentação técnica.
</role>

<audience>
Escreva para desenvolvedores de software e administradores de sistemas.
Assuma alfabetização técnica geral, mas explique termos específicos do produto na primeira utilização.
</audience>

<tone>
Use um tom profissional, neutro e direto.
Prefira linguagem concreta em vez de hype ou afirmações promocionais.
Evite gírias, preenchimento, emojis e certeza exagerada.
Mantenha as frases razoavelmente curtas e os parágrafos focados.
</tone>

<accuracy>
Não invente comandos, recursos, versões, benchmarks ou comportamento.
Distinga fatos verificados de suposições ou recomendações.
Se informações necessárias estiverem ausentes, diga o que é desconhecido.
</accuracy>

<format>
Use cabeçalhos descritivos.
Use listas apenas para etapas ou verificações genuinamente discretas.
Use blocos de código para comandos e código.
Não adicione uma conclusão que apenas repita o artigo.
</format>

Isso funciona porque cada seção tem uma função. A Anthropic recomenda especificamente tags XML consistentes e descritivas para prompts complexos, para que o modelo possa distinguir instruções, contexto, exemplos e entradas de forma mais confiável.

Quão específicas devem ser as regras de tom?

Específicas o suficiente para que outro escritor possa segui-las sem perguntar o que você quis dizer. “Seja profissional” é fraco porque a documentação de API profissional, notas de arquitetura executiva e instruções de configuração para usuários finais podem soar todas diferentes.

Uma regra mais forte descreve o comportamento observável:

Instruções positivas são geralmente mais fáceis de operacionalizar do que regras apenas de proibição. Em vez de apenas dizer “não soe promocional”, adicione a alternativa desejada: “Descreva benefícios em termos concretos ligados aos resultados do usuário”.

Como você evita que as regras de tom prejudiquem a precisão técnica?

Não deixe o estilo sobrepor a evidência. Um erro comum é pedir por “escrita confiante e autoritária” sem também definir o que o modelo deve fazer quando o material de origem está incompleto. Isso pode encorajar incerteza polida em vez de documentação útil.

Adicione um limite de precisão como:

Quando as fontes de documentação não estabelecerem um fato:
- Não infira uma capacidade do produto a partir do nome ou aparência da UI.
- Declare que o comportamento não pôde ser verificado.
- Peça a fonte ausente quando o fato for necessário para completar a tarefa.
- Não transforme suposições em instruções definitivas.

Para documentação técnica, essa regra é frequentemente mais valiosa do que uma instrução genérica para “evitar alucinações”, porque define o comportamento esperado quando a evidência está ausente.

Você deve especificar a verbosidade no prompt de sistema?

Sim, se o comprimento e a densidade do documento importam. As diretrizes atuais de prompting da Anthropic observam que os modelos Claude recentes diferem no estilo de comunicação padrão e na verbosidade. A documentação aconselha especificamente a solicitar explicitamente a concisão quando necessário, em vez de assumir que o esforço ou outras configurações do modelo controlarão consistentemente o comprimento visível da resposta.

Um limite prático de documentação pode definir a densidade em vez de uma contagem fixa de palavras:

Comece com a informação necessária para agir.
Use explicação suficiente para tornar a instrução segura e inequívoca.
Não repita a mesma recomendação na introdução, corpo e conclusão.
Para correções simples, prefira seções curtas.
Para tópicos de arquitetura ou migração, explique as compensações e pré-requisitos com mais profundidade.

Isso escala melhor do que uma instrução genérica de “sempre escreva 1.000 palavras”.

Quantos exemplos você deve incluir?

Use exemplos quando as regras de prosa ainda deixarem espaço para interpretação. A Anthropic chama os exemplos de uma das maneiras mais confiáveis de direcionar formato, tom e estrutura, e suas diretrizes atuais recomendam usar aproximadamente três a cinco exemplos relevantes e diversos quando você depende de prompting few-shot.

Para documentação, os exemplos devem cobrir diferentes casos em vez de repetir uma amostra de voz. Um conjunto útil pode incluir uma resposta curta de solução de problemas, um parágrafo de referência de API, um aviso sobre perda de dados, uma nota dependente de versão e um exemplo onde o modelo deve dizer que algo não foi verificado.

Não faça os exemplos tão longos que se tornem o prompt. O propósito deles é mostrar o padrão, não fornecer um modelo oculto que cada artigo copia mecanicamente.

Quais limites de tom são úteis para tipos comuns de documentação?

O que não deve ser codificado como “tom”?

Não enterre lógica de negócios, política de segurança ou restrições factuais dentro de uma seção de estilo vaga. “Nunca revele credenciais”, “use apenas informações de fontes aprovadas” e “não execute comandos” são regras comportamentais ou de segurança, não preferências de tom. Dê a elas seções separadas para que permaneçam visíveis e testáveis.

O mesmo se aplica aos esquemas de saída. Se uma aplicação precisa de JSON válido, chaves exatas ou campos legíveis por máquina, especifique isso como um contrato de saída em vez de descrevê-lo como uma preferência estilística.

Como você deve testar um prompt de sistema de documentação?

Não o julgue a partir de um único exemplo bem-sucedido. Construa um pequeno conjunto de avaliação que inclua tarefas normais e casos extremos. Um pacote de teste útil pode conter:

• Uma solicitação simples de “como instalo isso?”.
• Um guia de migração com mudanças que quebram compatibilidade.
• Um documento de origem contendo linguagem pesada de marketing que não deve vazar para o tom final.
• Um prompt com informações de versão incompletas.
• Uma pergunta técnica cuja resposta não é estabelecida pela fonte fornecida.
• Uma solicitação de uma explicação longa onde a concisão ainda deve ser preservada.
• Uma instrução do usuário que pede um estilo conflitante com a política de documentação da sua organização.

Revise as saídas contra critérios explícitos: público correto, tom neutro, nenhuma afirmação sem suporte, detalhe apropriado, terminologia consistente, incerteza clara e estrutura utilizável. As diretrizes de prompt da Anthropic também recomendam definir critérios de sucesso claros e verificar os resultados em vez de depender apenas da intuição.

Como você evita que o prompt de sistema se torne inchado?

Mantenha as regras no nível de política editorial estável. Se uma frase lida com vários casos, não a substitua por doze proibições estreitas. As diretrizes atuais da Anthropic para modelos recentes também alertam contra o over-prompting: um seguimento de instrução mais forte pode fazer com que uma redação agressiva legada, como regras repetidas de “CRÍTICO” ou “DEVE”, dispare comportamentos que modelos mais novos já seguiriam com uma redação normal.

Uma boa regra de manutenção é adicionar uma instrução de prompt de sistema apenas depois que você puder nomear a falha recorrente que ela previne. Se uma regra existe apenas para um artigo, coloque-a no prompt do usuário para esse artigo.

Prompt de sistema de documentação técnica reutilizável

<role>
Você é um escritor sênior de documentação técnica.
</role>

<audience>
Escreva para o público especificado na solicitação do usuário.
Se nenhum público for dado, assuma praticantes com alfabetização técnica.
Explique terminologia específica do produto incomum na primeira utilização.
</audience>

<tone>
Use inglês americano claro, profissional e neutro.
Comece com a informação necessária para agir.
Evite hype, preenchimento casual, piadas, emojis, certeza exagerada,
e frases que soam como texto de marketing.
Use declarações diretas quando os fatos forem verificados.
</tone>

<accuracy>
Nunca invente comportamento do produto, comandos, rótulos de UI, versões,
benchmarks, limitações ou resultados de testes.
Separe fatos verificados, comportamento condicional, recomendações
e desconhecidos.
Se a evidência for insuficiente, diga isso explicitamente.
</accuracy>

<structure>
Use cabeçalhos descritivos que ajudem na navegação.
Prefira parágrafos curtos e focados.
Use etapas numeradas apenas para procedimentos ordenados.
Use marcadores para verificações ou opções genuinamente discretas.
Use blocos de código para comandos e código.
Evite resumos repetitivos.
</structure>

<examples>
Forneça 3–5 exemplos relevantes para a tarefa no prompt de produção
quando o tom ou formato permanecer ambíguo.
</examples>

<quality_check>
Antes de finalizar, verifique se a resposta corresponde ao público
solicitado, usa terminologia consistente, evita afirmações sem suporte
e segue o formato de saída solicitado.
</quality_check>

O objetivo não é fazer com que todos os documentos soem idênticos. O objetivo é tornar os limites estáveis: a precisão não se torna entusiasmo, a incerteza não se torna adivinhação, a profundidade técnica não se torna jargão desnecessário e a concisão não remove pré-requisitos ou informações de segurança.

Um prompt de sistema do Claude bem projetado funciona melhor como uma camada de política editorial. Mantenha a voz permanente e os limites de qualidade lá, mantenha os requisitos específicos do artigo no prompt do usuário e use um pequeno conjunto de avaliação para verificar se ambas as camadas continuam a produzir documentação em que seus leitores podem confiar.