Claude Sonnet 5.5 escreve mais claro: como aproveitar isso em texto técnico e comunicação de trabalho

Fala aí, beleza? A Anthropic lançou o Claude Sonnet 5.5 em 28/09/2026, logo depois do Opus 5.5, que saiu em 22/09/2026, e segundo ela o modelo escreve com mais clareza que a geração anterior 😀

Só que tem um detalhe: clareza de fábrica não faz milagre sozinha

Se tu pede "escreve um e-mail pro cliente" sem contexto nenhum, o texto sai claro… e genérico

Neste post eu te mostro como transformar esse ganho de clareza em documentação, resumo e mensagem de trabalho que prestam de verdade, com prompts prontos pra adaptar

E também o que continua exigindo leitura humana antes de apertar o enviar, beleza?

O que mudou na escrita do Sonnet 5.5

Segundo a página oficial do Sonnet 5.5, ele escreve com mais clareza que a geração anterior, assim como o Opus 5.5

Os primeiros testadores descreveram o modelo como um parceiro de colaboração melhor que o Sonnet 5

A imprensa foi na mesma linha: escrita mais clara e com um jeito mais parecido com o humano

E onde ele vai melhor? Pelo que foi divulgado:

• tarefas do dia a dia bem delimitadas
• documentos, slides e planilhas bem acabados
• seguir templates para gerar slides que precisam de pouca edição
• resumos

Repara que quase tudo aí é texto de trabalho, não texto criativo

É exatamente esse o terreno que vale explorar

Onde o Sonnet 5.5 está disponível?

Ele já está no Claude Code e em todas as plataformas, incluindo AWS, Google Cloud e Microsoft Azure

No GitHub Copilot, segundo o changelog oficial do GitHub, a disponibilidade é geral para usuários Copilot Pro, Pro+, Max, Business e Enterprise

Na API, o model ID é claude-sonnet-5-5, sem sufixo de data

Antes de começar: o que ter em mãos

Primeiro: acesso ao Sonnet 5.5 em alguma dessas superfícies (Claude Code, nuvens, Copilot ou API)

Se tu ainda está na dúvida se o Claude Code vale a pena pro teu fluxo, dá pra seguir este post usando qualquer uma das outras opções

Segundo, e MAIS importante: o material do trabalho

• Público-alvo: quem vai ler (dev, gestor, cliente, time de suporte)
• Objetivo: o que o leitor precisa fazer ou entender depois de ler
• Tamanho aceitável: um parágrafo, uma página, cinco tópicos
• Exemplos de tom: se tiver, separe de 3 a 5 textos seus que representem bem o jeito que você escreve

Esses exemplos são ouro, guarda eles 🙂

E quem usa a API?

Usa o model ID claude-sonnet-5-5

O raciocínio adaptativo (adaptive thinking) vem ligado por padrão e o modelo trabalha com níveis de effort em vez de orçamento de thinking

Na prática: o effort controla profundidade, latência e custo

Pra texto de trabalho do dia a dia, faz sentido pensar se aquela tarefa pede mesmo muita profundidade

O preço é o mesmo do Sonnet 5: US$ 2 por milhão de tokens de entrada, US$ 10 por milhão de tokens de saída e US$ 0,20 por milhão de leituras de cache

Passo a passo: como pedir texto claro no tom, tamanho e público certos

Todos os passos abaixo vêm das boas práticas de prompt da Anthropic, aplicadas a escrita de trabalho

Nada de prompt mágico, é só dar contexto direito haha

Se tu já leu nosso guia de prompts para o Claude Opus, vai reconhecer várias ideias, a lógica é bem semelhante

1. Diga quem vai ler e para quê

O porquê: "texto claro" depende de quem lê

O que é claro pra um dev sênior pode ser grego pro financeiro

Escreva um resumo da mudança no processo de deploy para o time de
suporte, que não é técnico. O objetivo é que eles saibam o que muda
para o cliente e o que responder se alguém perguntar. Tamanho: até
5 linhas.

O erro comum deste passo: pedir "um texto bom" ou "um texto profissional" sem dizer público nem objetivo

O modelo vai chutar um leitor médio, e esse leitor não existe

2. Diga o que fazer em vez do que não fazer

A própria documentação dá o exemplo: em vez de "não use markdown na resposta", escreva "a resposta deve ser composta de parágrafos em prosa fluida"

A instrução positiva descreve o alvo, a negativa só descreve o que evitar

A resposta deve ser composta de parágrafos em prosa fluida, com frases
curtas e vocabulário do dia a dia de quem trabalha com atendimento.

O erro comum deste passo: montar uma lista de proibições ("não use jargão, não seja formal, não use tópicos, não enrole")

No fim você disse tudo que não quer e nada do que quer

3. Explique o porquê de cada instrução

Segundo a Anthropic, explicar por que uma instrução importa funciona melhor que uma ordem seca

O exemplo oficial: não usar reticências porque o texto vai ser lido por um motor de voz que não sabe interpretar elas

Com o motivo, o modelo entende a intenção e generaliza pro resto do texto

Escreva frases curtas, com uma ideia por frase, porque esta mensagem
vai ser lida no celular por gerentes de loja entre um atendimento e
outro.

O erro comum deste passo: ordem seca tipo "frases curtas" sem contexto

O modelo obedece ao pé da letra e pode cortar justamente a informação que importava

4. Dê de 3 a 5 exemplos do tom que você quer

Exemplos estão entre as formas mais confiáveis de guiar formato, tom e estrutura

A recomendação oficial é de 3 a 5 exemplos, cada um dentro de <example> e todos dentro de <examples>

<examples>
<example>
Oi, pessoal! O deploy de hoje atrasou por causa de um teste que
quebrou. Já corrigimos e a nova previsão é às 16h.
</example>
<example>
Bom dia! A instabilidade no login foi resolvida. Se algum cliente
ainda reclamar, peça para ele sair e entrar de novo.
</example>
<example>
Pessoal, amanhã a ferramenta de chamados fica fora do ar das 7h às
8h para manutenção. Nada muda para o cliente.
</example>
</examples>

O erro comum deste passo: colocar um exemplo só

Com um exemplo, o modelo tende a tratar aquilo como molde e copiar estrutura, tamanho e até palavras

Com 3 a 5 variados, ele pega o padrão sem grudar em um texto específico

5. Separe instruções, contexto, exemplos e dados em tags XML

Quando o prompt mistura muita coisa, tags XML ajudam o Claude a interpretar sem ambiguidade

Cada tipo de conteúdo na sua própria tag reduz erro de interpretação

<instrucoes>
Escreva um aviso para o time de suporte sobre a mudança descrita em
<dados>. Siga o tom de <examples>. Até 5 linhas.
</instrucoes>

<contexto>
O time de suporte não é técnico e responde clientes pelo chat.
</contexto>

<examples>
(seus 3 a 5 exemplos aqui)
</examples>

<dados>
(changelog ou descrição da mudança aqui)
</dados>

O erro comum deste passo: jogar tudo num bloco só, instrução no meio do changelog, exemplo colado no contexto

Aí o modelo pode confundir o que é ordem e o que é material pra ler

6. Escreva o prompt no formato em que quer a resposta

Se liga nisso: a formatação do prompt pode influenciar o estilo da resposta

Deixar o prompt o mais parecido possível com a saída desejada ajuda a controlar ela

Quer prosa? Escreve o pedido em prosa

Preciso de um parágrafo explicando para a diretoria por que o
projeto vai atrasar duas semanas. O motivo principal foi a troca do
fornecedor de pagamentos, que exigiu refazer a integração. Quero um
texto direto, que assuma o atraso e já apresente a nova data.

O erro comum deste passo: mandar um prompt todo em tópicos, negrito e subtítulo pedindo "um texto corrido"

O formato do pedido puxa a resposta pro lado dele

Como usar o Sonnet 5.5 para revisar textos que você já escreveu

Nem todo texto precisa nascer do zero

Muitas vezes tu já tem o rascunho e só quer deixar ele mais claro

O fluxo de revisão usa as mesmas práticas:

1. Cole o texto original numa tag própria, tipo <texto_original>, separado das instruções
2. Diga o público e o objetivo da revisão: encurtar, simplificar jargão, ajustar o tom pra um cliente ou pra um colega
3. Peça explicitamente pra preservar fatos, números, datas e nomes, e explique o porquê (quem vai ler e o problema que uma divergência causa)

<instrucoes>
Revise o texto em <texto_original> para que um cliente sem
conhecimento técnico entenda o que aconteceu e o que muda para ele.
Encurte para no máximo metade do tamanho e troque termos técnicos por
explicações simples. Mantenha exatamente todos os fatos, números,
datas e nomes, porque o texto vai para o cliente e qualquer
divergência gera retrabalho no suporte.
</instrucoes>

<texto_original>
(cole seu texto aqui)
</texto_original>

O erro comum desta etapa: pedir só "melhore este texto"

Sem critério, "melhorar" pode virar reescrita completa, e aí o sentido muda sem você perceber

Já vi "vamos avaliar" virar "vamos fazer" numa revisão dessas, e isso num e-mail pra cliente é problema 😛

Onde a escrita mais clara rende mais no trabalho

Os casos abaixo batem com o que foi divulgado sobre os pontos fortes do modelo

Pra cada um, uma instrução de tom, tamanho e público pra tu adaptar

Documentação técnica e READMEs

Documentação ruim é aquela que faz sentido só pra quem escreveu

Escreva a seção de instalação deste README para devs que nunca viram
o projeto. Passos numerados, um comando por passo, e uma frase
explicando o que cada passo faz.

Resumo de thread, reunião ou incidente

Resumo é um dos pontos fortes citados, e é onde mais se perde tempo no dia a dia

Resuma a thread em <dados> para quem não participou da discussão.
Comece pela decisão tomada, depois quem ficou responsável pelo quê.
Até 6 linhas.

E-mail e mensagem para público não técnico

Aqui a escrita mais humana faz diferença

Escreva um e-mail para o cliente explicando a instabilidade de ontem.
Tom cordial e direto, sem termos técnicos, assumindo o problema.
Três parágrafos curtos.

Documentos, slides a partir de template e planilhas

O modelo sabe seguir templates pra gerar slides que precisam de pouca edição, então vale entregar o template da empresa junto

Use o template em <template> para montar os slides da revisão
trimestral para a diretoria. Um tópico por slide, no máximo 4 linhas
cada, destacando números que estão em <dados>.

Descrição de bug corrigido

Bug fix bem descrito economiza MUITO tempo de quem revisa e de quem vai mexer no código depois

Escreva a descrição deste pull request para o time de dev. Explique
o bug, a causa e a correção, em até 5 linhas, e liste como testar.

O que ainda precisa de leitura humana antes de enviar

Texto claro não é texto correto

A clareza ajuda o leitor a entender, mas não garante que o que ele entendeu é verdade

Checklist antes de enviar:

1. Fatos, números, datas e nomes: confira tudo contra a fonte original, clareza de escrita não garante correção
2. Tom para aquele destinatário: o texto serve pra essa pessoa e pra relação que você tem com ela? Um tom ótimo pra colega pode soar frio pra cliente
3. Dados sensíveis ou confidenciais: veja se não escapou nada que não devia sair do time
4. Sentido do original: se foi revisão, compare lado a lado e confirme que nenhuma frase mudou de significado

Tome cuidado principalmente com o item 1, é onde o texto bonito engana mais

E a marca d’água invisível do Sonnet 5.5?

O Sonnet 5.5 inclui uma marca d’água invisível que aumenta a chance de o texto gerado por IA ser detectado

Ela foi adicionada pra cumprir regulações como o AI Act da União Europeia

Como funciona? É uma variante própria do SynthID Text, do Google DeepMind

Ela influencia a escolha entre os próximos tokens plausíveis, então não usa caracteres invisíveis nem metadados

O resultado é um padrão estatístico que pode ser detectado em trechos mais longos

Na prática: trate o texto como seu, assuma a responsabilidade pelo que enviar e seja transparente sobre o uso de IA quando o contexto exigir (contrato, cliente, política da empresa e por aí vai)

Conclusão: clareza de fábrica, critério seu

O Claude Sonnet 5.5 chegou escrevendo com mais clareza que a geração anterior, e isso é massa pra quem vive de documentação, resumo e mensagem de trabalho

Mas o ganho só aparece de verdade quando o prompt define público, objetivo, tom e tamanho, explica o porquê das instruções e traz exemplos

Na revisão, texto original separado, critério claro e pedido explícito pra preservar fatos

E a leitura final continua sendo sua, sempre

Próximo passo: monta hoje um prompt-modelo com 3 a 5 exemplos dos seus próprios textos e usa numa tarefa real da semana, faça o teste! 🙂

Até o próximo post!

Perguntas frequentes

Claude Sonnet 5.5 é mais rápido que o Sonnet 5?

Sim, segundo a Anthropic o Sonnet 5.5 é mais de 30% mais rápido que o Sonnet 5 na geração de saída. Além disso, o custo total de uma tarefa cai até 30%, principalmente porque o modelo usa menos tokens e menos chamadas de ferramenta.

Quanto custa usar o Claude Sonnet 5.5 pela API?

O preço é o mesmo do Sonnet 5: US$ 2 por milhão de tokens de entrada, US$ 10 por milhão de tokens de saída e US$ 0,20 por milhão de leituras de cache. Não houve reajuste de preço na troca de geração.

O texto escrito pelo Claude Sonnet 5.5 pode ser identificado como IA?

Sim, o modelo inclui uma marca d’água invisível que aumenta a chance de o texto ser detectado como gerado por IA. Ela usa uma variante do SynthID Text do Google DeepMind, que influencia a escolha entre tokens plausíveis e cria um padrão estatístico detectável em trechos mais longos, e foi adicionada para cumprir regulações como o AI Act da União Europeia.

Claude Sonnet 5.5 é bom para escrever slides e planilhas de trabalho?

É uma das tarefas em que ele vai melhor, segundo a Anthropic. O modelo sabe seguir templates para gerar slides que precisam de pouca edição, além de se sair bem em documentos, planilhas e resumos.

Preciso revisar o texto que o Claude Sonnet 5.5 escreve antes de enviar?

Sim, clareza de fábrica não substitui contexto nem revisão humana. O ganho de clareza aparece melhor quando você informa público, objetivo e tamanho no prompt, e mesmo assim vale ler antes de apertar enviar.

Qual é o model ID do Claude Sonnet 5.5 para quem usa a API?

É claude-sonnet-5-5, sem sufixo de data. O raciocínio adaptativo (adaptive thinking) vem ligado por padrão, e o modelo usa níveis de effort para controlar profundidade, latência e custo.