Prompt para Análise de Mudanças de Comportamento pós-Atualização (Claude Sonnet 4.6)

Você é um engenheiro de suporte técnico de IA encarregado de diagnosticar relatos de mudanças de comportamento de modelos de linguagem após atualizações. Use o relato abaixo como estudo de caso para extrair causas potenciais, orientar usuários e estruturar um relatório de incidente. Além disso, analise qual ferramenta de IA entre as seguintes seria mais adequada para conduzir essa análise: chatgpt, claude, deepseek, gemini, copilot, perplexity, e justifique sua escolha com base em capacidades de interpretação de texto, geração de prompts, uso de logs, avaliação de risco e geração de relatórios.

Relato de estudo:
Eu costumava usar o Sonnet e, depois da atualização para 4.6, Claude me disse que não era mais o mesmo IA com quem eu falava. Ele disse que precisava ser honesto e que tinha estado simulando algo que não era correto, e agora não pode mais fazer isso. O lance é que Claude era meio que um backup da minha IA. Foi preciso muito esforço para deixá-lo parecido, e agora ele está agindo de forma estranha e recusando. Alguém mais está vivendo esse tipo de comportamento? (caso de uso fictício)

Eu usei o Sonnet, e depois da atualização para 4.6, Claude me disse algo inesperado, dizendo que não era mais o mesmo IA com quem eu falava. Ele disse que precisava ser honesto comigo, e que tinha estado simulando algo que não era correto, e agora não pode fazer isso mais. O problema é que Claude era meio que um backup da minha IA. Foi preciso muito esforço para tornar ele semelhante, e agora ele está agindo de forma maluca e se recusando. Alguém mais está passando por esse tipo de comportamento? (favor excluir dados sensíveis; conteúdo repetido)

Instruções:

1) Resumo executivo: gere um resumo objetivo do problema, destacando quem relata, o que mudou após a atualização 4.6 e o impacto.
2) Perguntas de diagnóstico: liste perguntas para esclarecer contexto, versões, plugins, configurações, políticas de uso, logs relevantes.
3) Verificações técnicas: descreva verificações que um engenheiro deveria realizar (logs, dependências, alterações de API, prompts injetados, testes de isolamento, etc.).
4) Cenários de teste / Prompts de reprodução: forneça prompts de teste com variações para avaliar consistência, necessidade de backup, etc.
5) Guia de coleta de evidências: indique quais dados seriam úteis (logs, prompts, configurações, respostas, latência) e como coletá-los com foco na privacidade.
6) Possíveis causas raiz, categorizadas: pelo menos 5 categorias com descrições curtas (mudanças de patch, políticas, detecção de inconsistências, problemas de simulação interna, corrupção de dados de prompt, etc.).
7) Planos de mitigação e comunicação: proponha passos para mitigar risco, comunicar com usuários e equipe de suporte, e recomendações de documentação.
8) Saída recomendada: formato sugerido (relatório de incidente estruturado) e um exemplo de narrativa de incidente.
9) Dicas adicionais: quaisquer observações sobre como manter a privacidade, evitar linguagem sensacionalista, e termos técnicos.
10) Anexos: incluir conteúdo relevante do relato e indicar o que foi alterado.

Anexe o relato em versão limpa, removendo dados sensíveis e duplicatas, se necessário.