Coleção completa de prompts do Kimi K3.1 Pro: 5 cenários para copiar e obter resultados direto

O Kimi K3.1 Pro já está disponível no HiAPI, e novos usuários ganham 200 créditos ao se cadastrar. A seguir, 5 prompts realmente utilizáveis, cobrindo diagnóstico de falhas, revisão de código, comparação de soluções, análise de documentos longos e processamento de dados. Todos podem ser copiados diretamente; ao clicar no link, eles são preenchidos automaticamente.

1. Diagnóstico de sistema: localizar a causa raiz a partir do log de erro

Envie o log de erro ao modelo e peça que ele investigue camada por camada seguindo a cadeia de chamadas, retornando a causa raiz e os passos de correção, em vez de uma resposta genérica como "verifique a conexão de rede".

Referência de saída de exemplo: o modelo lista a cadeia de investigação (por exemplo, configuração do proxy reverso Nginx → status de saúde do serviço de backend → pool de conexões do banco de dados), fornece em cada camada os comandos de verificação, os resultados esperados e os sintomas anormais, e por fim identifica a causa raiz (por exemplo, "esgotamento do pool de conexões do PostgreSQL fez novas requisições ficarem em fila até o timeout") e apresenta um plano de correção em duas etapas.

Você é um engenheiro de diagnóstico de backend. A seguir há um trecho de log de erro de ambiente de produção. Faça a investigação seguindo os passos abaixo:

1. Interprete linha por linha os pontos-chave de tempo e os códigos de erro no log
2. Analise camada por camada as possíveis causas seguindo a cadeia de chamadas (entrada → middleware → serviço → banco de dados)
3. Aponte as causas raiz mais prováveis (no máximo 3)
4. Para cada causa raiz, forneça comandos de verificação e passos de correção

Formato de saída:
## Interpretação do log
## Investigação camada por camada
## Análise de causa raiz
## Passos de correção

Log:
[cole aqui seu log de erro]

Usar este prompt para diagnosticar →

kimi-k3.1-pro, reasoning_effort: high. Referência: cerca de $0.03 (entrada de cerca de 3000 tokens + saída de cerca de 2000 tokens).

Pontos-chave: o prompt define a estrutura de saída e a cadeia de investigação, então o modelo não pula etapas nem dá sugestões inúteis como "tente reiniciar". Para problemas de diagnóstico, definir reasoning_effort como high ou max é mais útil — com low, às vezes ele pula as camadas intermediárias e adivinha a conclusão.

2. Revisão de código: saída em JSON estruturado

Peça ao modelo para revisar o código e retornar JSON, que pode ir direto para o banco e ser usado em verificações de CI. O modo json_schema do K3.1 Pro garante que os campos, tipos e valores de enum da saída correspondam exatamente à sua definição.

Referência de saída de exemplo: o modelo retorna um objeto JSON contendo o array issues (cada item com file, line, severity, category, description, suggestion), o objeto summary (com a contagem de cada nível de severidade) e overall_score (0-100). Os níveis de severidade são estritamente classificados em quatro faixas: critical / major / minor / style.

Você precisa revisar o código abaixo. Retorne o resultado da revisão estritamente conforme o JSON Schema, sem produzir nenhum texto fora do JSON.

Dimensões de revisão:
- Erros de lógica e condições de contorno
- Problemas de desempenho (consultas N+1, laços desnecessários)
- Riscos de segurança (injeção de SQL, XSS, entradas não validadas)
- Estilo de código e legibilidade

JSON Schema de saída:
{
  "issues": [
    {
      "file": "string",
      "line": "number",
      "severity": "critical | major | minor | style",
      "category": "logic | performance | security | style",
      "description": "string",
      "suggestion": "string"
    }
  ],
  "summary": {
    "critical": "number",
    "major": "number",
    "minor": "number",
    "style": "number"
  },
  "overall_score": "number (0-100)"
}

Código:
[cole aqui seu código]

Usar este prompt para revisar o código →

kimi-k3.1-pro, response_format: json_schema. Referência: cerca de $0.04 (entrada de cerca de 4000 tokens + saída de cerca de 2500 tokens).

Pontos-chave: é obrigatório passar response_format: {"type": "json_schema", "json_schema": {...}} para fixar o formato de saída. Escrever o Schema também no prompt é uma garantia dupla — mesmo que o json_schema não tenha efeito, o modelo ainda segue o formato. Use valores de enum em severity em vez de linguagem natural descritiva, garantindo que o sistema downstream possa fazer decisões de ramificação diretamente.

3. Comparação de soluções técnicas: tabela de pontuação multidimensional

Quando duas soluções técnicas estão empatadas, pedir ao modelo para pontuar em vários aspectos e calcular o total é mais justo do que deixar colegas decidirem por intuição.

Referência de saída de exemplo: o modelo gera uma tabela comparativa com aspectos como desempenho, manutenibilidade, maturidade do ecossistema, custo de aprendizado, aderência da equipe, entre 5 e 6 itens; cada item recebe uma nota de 1 a 10 e uma justificativa em uma frase; por fim, calcula a pontuação total ponderada e apresenta uma recomendação.

Preciso escolher entre duas soluções técnicas: Solução A e Solução B. Compare os 6 aspectos abaixo, um a um, atribuindo pontuação (1-10) e uma justificativa em uma frase para cada aspecto; ao final, calcule a pontuação total ponderada e apresente a recomendação.

Aspectos de comparação e pesos:
- Desempenho (peso 25%)
- Manutenibilidade (peso 20%)
- Maturidade do ecossistema (peso 20%)
- Custo de aprendizado (peso 15%)
- Aderência à stack tecnológica atual da equipe (peso 15%)
- Atividade da comunidade (peso 5%)

Formato de saída:
| Aspecto | Pontuação da Solução A | Pontuação da Solução B | Justificativa |
|---|---|---|---|
| Desempenho | | | |
| ... | | | |
| **Pontuação total ponderada** | | | |

Último parágrafo: justificativa da recomendação (no máximo 3 frases)

Solução A: [descreva a Solução A, por exemplo, stack tecnológica, arquitetura, dependências principais]
Solução B: [descreva a Solução B, por exemplo, stack tecnológica, arquitetura, dependências principais]
Contexto: [opcional: tamanho da equipe, stack atual, cenário de negócio]

Usar este prompt para comparar soluções →

kimi-k3.1-pro, reasoning_effort: high. Referência: cerca de $0.04 (entrada de cerca de 3000 tokens + saída de cerca de 3000 tokens).

Pontos-chave: ajuste os pesos conforme sua situação real. Se a equipe já tem uma preferência, basta incluir os pesos no prompt e o modelo os refletirá no cálculo. Não forneça apenas os nomes das soluções — descreva claramente as escolhas tecnológicas principais, dependências e situação da equipe de cada solução para que o modelo possa dar pontuações fundamentadas.

4. Análise de documentos longos: extrair informações-chave de um manual inteiro

Envie dezenas de páginas de documentação técnica, atas de reunião ou feedback de usuários e peça ao modelo para extrair os pontos que realmente importam para você. A janela de contexto de 1M tokens do K3.1 Pro é suficiente para absorver um manual inteiro.

Referência de saída de exemplo: o modelo primeiro resume o tema e a estrutura do documento, depois responde item por item às perguntas-chave e, por fim, lista condições de contorno e contradições fáceis de passar despercebidas.

A seguir há um documento técnico completo. Extraia as informações-chave conforme a estrutura abaixo:

1. Visão geral do tema e da estrutura do documento (um parágrafo)
2. Responda às seguintes perguntas específicas:
   - [Pergunta 1]
   - [Pergunta 2]
   - [Pergunta 3]
3. Todas as restrições e premissas mencionadas no documento (liste item por item)
4. Condições de contorno fáceis de passar despercebidas (pelo menos 3)
5. Pontos contraditórios ou pouco claros no documento (se houver)

Documento:
[cole aqui o texto completo do documento]

Usar este prompt para analisar o documento →

kimi-k3.1-pro, reasoning_effort: max, max_tokens: 8000. Referência: cerca de $0.07 (entrada de cerca de 15000 tokens + saída de cerca de 3000 tokens). Os tokens de entrada de documentos longos dependem do tamanho real do documento; aqui, uma estimativa conservadora de cerca de 10 mil caracteres chineses.

Pontos-chave: substitua as perguntas 2 e 3 pelo que você realmente quer saber do documento; não deixe os placeholders [Pergunta 1] do modelo. Para documentos muito longos, defina reasoning_effort como max; com low, é fácil perder informações em contexto longo. Ao analisar repetidamente o mesmo documento longo, a partir da segunda vez a leitura em cache custa apenas $0.2156/M tokens (1/10 do preço de entrada).

5. Análise de dados: gerar relatório de insights a partir de dados brutos

Forneça um trecho de dados CSV ou JSON e peça que ele faça estatísticas automaticamente, identifique tendências, encontre anomalias e produza diretamente um relatório pronto para colar no relatório semanal.

Referência de saída de exemplo: o modelo começa com uma visão geral dos dados (número de linhas, campos, intervalo de tempo), depois apresenta estatísticas das métricas principais, descrição de tendências, marcação de pontos de dados anômalos e, por fim, dá 2-3 recomendações acionáveis.

Você é um analista de dados. A seguir há um conjunto de dados brutos. Realize a análise abaixo e produza um relatório:

1. Visão geral dos dados: número de linhas, lista de campos, intervalo de tempo, completude dos dados (taxa de ausência)
2. Estatísticas das métricas principais: escolha automaticamente estatísticas adequadas conforme o tipo de campo
   - Campos numéricos: média, mediana, valor máximo, valor mínimo, desvio padrão
   - Campos categóricos: Top 5 categorias e proporção
3. Análise de tendências: se houver campo de tempo, agregue as principais métricas por semana/mês e descreva a tendência
4. Detecção de anomalias: marque pontos de dados que se desviam da média em mais de 2 desvios padrão
5. Conclusões e recomendações: 2-3 recomendações acionáveis

Formato de saída: relatório em Markdown, com títulos por seção e números-chave em negrito.

Dados:
[cole aqui seus dados CSV ou JSON]

Usar este prompt para analisar os dados →

kimi-k3.1-pro, reasoning_effort: high. Referência: cerca de $0.03 (entrada de cerca de 2000 tokens + saída de cerca de 2000 tokens). Com grande volume de dados, os tokens de entrada aumentam proporcionalmente.

Pontos-chave: não inclua informações sensíveis nos dados (IDs reais de usuários, números de celular, chaves). Se houver muitas linhas de dados, as primeiras 200 linhas já bastam para o modelo identificar tendências e anomalias — o K3.1 Pro não precisa do conjunto completo para dar conclusões estatísticas precisas.

Boas práticas gerais para prompts

O K3.1 Pro é um modelo de raciocínio, então não é preciso escrever prefixos genéricos como "você é um XX profissional". Três pontos principais:

1. Dê estrutura, não raciocínio: defina o formato de saída e as dimensões que devem ser cobertas, deixando o modelo raciocinar sobre como preencher; isso funciona melhor do que ensinar passo a passo.
2. Faça perguntas específicas: em vez de "analise este log", use algo como "encontre a primeira anomalia que aparece nas 500 linhas deste log, seu chamador upstream e quais configurações precisam ser alteradas para a correção".
3. Escolha reasoning_effort por cenário: use high ou max para diagnóstico e documentos longos; use low para perguntas e respostas simples e conversão de formato; a diferença de custo pode ser de várias vezes.

Abra a página do modelo Kimi K3.1 Pro, escolha um cenário, copie o prompt e comece a gerar.

Série de artigos sobre o Kimi K3.1 Pro

• Página do modelo
• Como usar a API? Faça a primeira chamada em 5 minutos
• Comparação de preços
• Kimi K3.1 Pro vs Claude Opus 5.5