Modelos de prompt para depurar problemas de produção

Use IA para depuração em produção como um fluxo de trabalho de evidência até validação: colete fatos, formule hipóteses, verifique-as, faça a menor correção respaldada e valide com segurança. Não peça a um assistente que corrija um problema ativo a partir de um sintoma vago e aplique o resultado cegamente.

Os modelos abaixo mantêm a investigação fundamentada. Remova segredos, tokens de acesso, dados pessoais e identificadores de clientes antes de compartilhar logs ou traces.

A sequência de depuração em produção

evidências -> hipóteses -> verificação -> menor correção -> validação

Todo prompt deve incluir o comportamento esperado, o comportamento observado, o ambiente, informações de reprodução, alterações recentes relevantes e o limite seguro do trabalho solicitado.

Modelo: triagem inicial de incidente

Precisamos investigar um problema de produção. Ainda não proponha uma alteração de código.

Sintomas: [O que usuários ou monitoramento mostram.]
Comportamento esperado: [O que deveria acontecer.]
Comportamento observado: [O que realmente acontece.]
Impacto: [Quem é afetado, frequência, gravidade e fallback seguro, se conhecido.]
Ambiente: [Versão, implantação, navegador/SO, região, feature flags ou detalhes
de runtime.]
Alterações recentes: [Implantações, migrações, configuração ou dependências relevantes.]
Evidências: [Logs sanitizados, erros, métricas, IDs de trace, capturas de tela, comandos.]
Reprodução: [Etapas confiáveis ou informe que é intermitente.]

Retorne:
1. uma linha do tempo concisa de fatos confirmados;
2. as principais hipóteses ordenadas por probabilidade e impacto;
3. a próxima observação segura ou etapa de reprodução para cada hipótese;
4. qualquer informação ausente que bloqueie materialmente o diagnóstico.

Isso dá a um assistente material suficiente para raciocinar sem fingir que tem acesso aos seus sistemas de produção.

Modelo: reproduza antes de corrigir

Tente reproduzir este problema localmente ou no ambiente aprovado que não é de produção.

Esperado: [Resultado esperado.]
Observado: [Resultado real.]
Configuração: [Fixture, estado de conta, comando, configuração ou dados de teste.]
Alteração recente a investigar: [Commit, release ou alteração de comportamento.]

Não edite o código de produção até que a falha seja reproduzida ou tenhamos uma
explicação baseada em evidências para o motivo de a reprodução não ser possível.
Capture o menor teste que falha, sequência de logs ou saída de comando que diferencie
as hipóteses principais.

Se a reprodução for impossível, declare a incerteza e recomende instrumentação segura ou uma decisão de reversão — não um patch especulativo.

Modelo: analise logs sanitizados

Analise estes logs sanitizados para uma falha de produção.

Contexto: [Serviço/funcionalidade e fluxo de solicitação esperado.]
Janela de tempo: [Início/fim e fuso horário.]
Comportamento esperado: [Caminho de sucesso esperado.]
Comportamento observado: [Erro ou comportamento degradado.]
Alterações recentes: [Alterações de implantação/configuração/dependência.]
Logs: [Entradas sanitizadas em ordem cronológica.]

Separe fatos de inferências. Correlacione eventos apenas quando IDs, timestamps
ou evidências causais os sustentarem. Liste hipóteses plausíveis, o log ou métrica
que confirmaria cada uma e a próxima observação de menor risco.

Não deixe um assistente tratar timestamps vizinhos como prova de causalidade.

Modelo: investigue a falha de um comando ou script

Investigue por que este comando de manutenção de produção falhou.

Comando: [Comando exato com segredos removidos.]
Saída esperada: [Sinal de sucesso esperado.]
Saída observada: [stderr/stdout sanitizado exato e código de saída.]
Ambiente: [Shell, diretório de trabalho, versão do SO/runtime, arquivos relevantes.]
Alterações recentes: [Alterações no script ou na implantação.]

Primeiro, explique o que o comando realmente faz e identifique a primeira etapa
que falha. Proponha comandos de diagnóstico seguros que não alterem dados. Somente
depois que a falha for compreendida, proponha a menor correção e como validá-la em
um ambiente que não seja de produção.

Para falhas no terminal, a entrada e a saída exatas costumam ser mais valiosas do que um resumo em prosa.

Modelo: investigue uma regressão de rollout

Avalie se esta regressão está relacionada ao rollout recente.

Linha de base: [Comportamento/versão antes do rollout.]
Alteração: [Release, flag, migração ou diferença de configuração.]
Regressão observada: [Quem é afetado e como.]
Evidências: [Métricas, logs, traces, capturas de tela ou uma reprodução.]
Restrições: Não altere o rollout nem migre dados até que as evidências
fundamentem uma decisão. Preserve o caminho de reversão.

Compare os caminhos de linha de base e alterado. Identifique o menor experimento,
verificação de feature flag ou teste fora de produção que poderia confirmar a
causalidade. Recomende reversão, mitigação ou investigação de código com a
confiança e os trade-offs de cada opção.

A resposta certa pode ser uma reversão ou um ajuste de feature flag, não uma alteração de código.

Modelo: solicite uma correção segura

Use isto somente depois que as evidências sustentarem uma causa:

Causa confirmada: [Causa raiz respaldada por evidências.]
Escopo: [Arquivos, módulo ou configuração a alterar.]
Comportamento a preservar: [Caminho de sucesso existente, contrato público,
permissões, dados, localidade, desempenho ou comportamento de reversão.]

Proponha a menor correção. Inclua:
- por que ela trata a causa confirmada;
- o teste de regressão ou a verificação reproduzível;
- validação em um ambiente aprovado que não seja de produção;
- considerações sobre rollout, monitoramento e reversão;
- comportamento que permanece incerto.

Não inclua refatoração não relacionada nesta alteração.

O prompt impede que um incidente real se torne uma oportunidade para uma reescrita impossível de revisar.

Modelo: valide após a correção

Valide a correção em relação ao incidente original.

Verifique:
1. a reprodução original ou o teste que falhava agora passa;
2. o caminho normal de sucesso permanece inalterado;
3. os caminhos de erro e extremos relevantes ainda se comportam com segurança;
4. os sinais de implantação ou monitoramento mostram a recuperação esperada;
5. a condição de reversão permanece disponível.

Relate as evidências para cada verificação e nomeie explicitamente tudo o que não foi verificado.

A validação deve responder à pergunta original do incidente, não apenas confirmar que um novo caminho de código foi executado.

Use IA como uma investigadora disciplinada

A IA pode ajudar a organizar evidências, gerar hipóteses, explicar código desconhecido e sugerir testes. Ela não pode substituir controle de acesso, responsabilidade pelo incidente, proteções de produção nem revisão humana.

Comece com como escrever prompts melhores para IA para a estrutura geral. Use erros de assistentes de programação com IA e como evitá-los para reconhecer atalhos inseguros e use modelos de prompt para refatorar código somente depois de compreender o incidente.

Se as evidências incluírem comandos de shell, reproduza o fluxo de trabalho com segurança antes de alterá-lo. Pratique cenários de linha de comando no navegador para criar o hábito de verificar sinais de entrada, saída e falha.