Colección completa de prompts de Kimi K3.1 Pro: 5 escenarios para copiar y obtener resultados directamente

Kimi K3.1 Pro ya está disponible en HiAPI, y los nuevos usuarios registrados reciben 200 créditos de regalo. A continuación te presentamos 5 prompts realmente útiles que cubren diagnóstico de fallos, revisión de código, comparación de soluciones, análisis de documentos extensos y procesamiento de datos. Cada prompt se puede copiar directamente y, al hacer clic en el enlace, se rellenará automáticamente.

1. Diagnóstico de sistemas: localizar la causa raíz a partir de los registros de error

Pasa los registros de error al modelo y pídele que investigue capa por capa siguiendo la cadena de llamadas, y que entregue la causa raíz y los pasos de corrección, en lugar de un vago "comprueba la conexión de red".

Ejemplo de salida de referencia: el modelo enumerará la cadena de diagnóstico (por ejemplo, configuración del proxy inverso de Nginx → estado de salud del servicio backend → pool de conexiones de la base de datos), y para cada capa indicará los comandos de comprobación, los resultados esperados y los síntomas anómalos; por último, identificará la causa raíz (por ejemplo, "el agotamiento del pool de conexiones de PostgreSQL provoca que las nuevas solicitudes se encolen y agoten el tiempo de espera") y propondrá un plan de corrección en dos pasos.

Eres un ingeniero de diagnóstico de backend. A continuación se muestra un registro de errores de un entorno de producción. Investiga siguiendo estos pasos:

1. Interpreta línea por línea los puntos temporales clave y los códigos de error del registro
2. Analiza capa por capa las posibles causas siguiendo la cadena de llamadas (entrada → middleware → servicio → base de datos)
3. Indica las causas raíz más probables (no más de 3)
4. Para cada causa raíz, proporciona los comandos de verificación y los pasos de corrección

Formato de salida:
## Interpretación del registro
## Diagnóstico capa por capa
## Análisis de la causa raíz
## Pasos de corrección

Registro:
[pega aquí tu registro de errores]

Usar este prompt para diagnosticar fallos →

kimi-k3.1-pro, reasoning_effort: high. Referencia: aproximadamente $0.03 (entrada de unos 3000 tokens + salida de unos 2000 tokens).

Puntos clave: el prompt define la estructura de salida y la cadena de diagnóstico, de modo que el modelo no se salta pasos ni ofrece sugerencias inútiles como "reinicia y prueba". Para problemas de diagnóstico, configurar reasoning_effort en high o max resulta más útil; con low a veces se salta las capas intermedias y adivina la conclusión directamente.

2. Revisión de código: salida JSON estructurada

Pide al modelo que revise el código y emita JSON, que se puede almacenar directamente para usarlo en comprobaciones de CI. El modo json_schema de K3.1 Pro garantiza que los campos, tipos y valores de enumeración de la salida coincidan estrictamente con tu definición.

Ejemplo de salida de referencia: el modelo devolverá un objeto JSON que contiene un array issues (cada elemento incluye file, line, severity, category, description, suggestion), un objeto summary (con el recuento de cada nivel de gravedad) y overall_score (0-100). Los niveles de gravedad se clasifican estrictamente en las cuatro categorías critical / major / minor / style.

Necesitas revisar el siguiente código. Emite el resultado de la revisión estrictamente según el JSON Schema, sin escribir ningún texto fuera del JSON.

Dimensiones de revisión:
- Errores lógicos y condiciones límite
- Problemas de rendimiento (consultas N+1, bucles innecesarios)
- Riesgos de seguridad (inyección SQL, XSS, entradas no validadas)
- Estilo de código y legibilidad

JSON Schema de salida:
{
  "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:
[pega aquí tu código]

Usar este prompt para revisar código →

kimi-k3.1-pro, response_format: json_schema. Referencia: aproximadamente $0.04 (entrada de unos 4000 tokens + salida de unos 2500 tokens).

Puntos clave: es obligatorio pasar response_format: {"type": "json_schema", "json_schema": {...}} para fijar el formato de salida. Escribir también el Schema en el prompt es una doble garantía: aunque json_schema no surta efecto, el modelo seguirá emitiendo el formato indicado. Usar valores de enumeración en severity en lugar de descripciones en lenguaje natural garantiza que las etapas posteriores puedan tomar decisiones directamente.

3. Comparación de soluciones técnicas: tabla de puntuación multidimensional

Cuando no puedes decidirte entre dos soluciones técnicas, pedir al modelo que puntúe desde múltiples dimensiones y calcule la puntuación total es más justo que dejar que un compañero decida a ojo.

Ejemplo de salida de referencia: el modelo generará una tabla comparativa con dimensiones como rendimiento, mantenibilidad, madurez del ecosistema, coste de aprendizaje y ajuste al equipo, entre 5 y 6 elementos; para cada uno dará una puntuación de 1 a 10 y una razón en una frase, y al final calculará la puntuación total ponderada y ofrecerá una recomendación.

Necesito elegir entre dos soluciones técnicas: la solución A y la solución B. Compáralas una por una en las siguientes 6 dimensiones, puntúa cada dimensión (1-10) y escribe una razón en una frase; al final calcula la puntuación total ponderada y da una recomendación.

Dimensiones de comparación y pesos:
- Rendimiento (peso 25%)
- Mantenibilidad (peso 20%)
- Madurez del ecosistema (peso 20%)
- Coste de aprendizaje (peso 15%)
- Ajuste al stack tecnológico actual del equipo (peso 15%)
- Actividad de la comunidad (peso 5%)

Formato de salida:
| Dimensión | Puntuación solución A | Puntuación solución B | Razón |
|---|---|---|---|
| Rendimiento | | | |
| ... | | | |
| **Puntuación total ponderada** | | | |

Último párrafo: razones de la recomendación (no más de 3 frases)

Solución A: [describe la solución A, por ejemplo, stack tecnológico, arquitectura, dependencias clave]
Solución B: [describe la solución B, por ejemplo, stack tecnológico, arquitectura, dependencias clave]
Contexto: [opcional: tamaño del equipo, stack tecnológico actual, escenario de negocio]

Usar este prompt para comparar soluciones →

kimi-k3.1-pro, reasoning_effort: high. Referencia: aproximadamente $0.04 (entrada de unos 3000 tokens + salida de unos 3000 tokens).

Puntos clave: ajusta los pesos según tu situación real. Si el equipo ya tiene una preferencia, escribe los pesos directamente en el prompt y el modelo lo reflejará al calcular la puntuación. No des solo el nombre de la solución: describe claramente las elecciones tecnológicas clave, las dependencias y la situación del equipo de cada solución para que el modelo pueda dar puntuaciones fundamentadas.

4. Análisis de documentos extensos: extraer información clave de un manual completo

Pasa decenas de páginas de documentación técnica, actas de reuniones o comentarios de usuarios y pide al modelo que extraiga los puntos que realmente te interesan. El contexto de 1M tokens de K3.1 Pro es suficiente para procesar un manual completo.

Ejemplo de salida de referencia: el modelo resumirá primero el tema y la estructura del documento, luego responderá punto por punto cada pregunta clave y, por último, enumerará las situaciones límite y contradicciones fáciles de pasar por alto.

A continuación se muestra un documento técnico completo. Extrae la información clave según la siguiente estructura:

1. Tema y resumen de la estructura del documento (un párrafo)
2. Responde a las siguientes preguntas concretas:
   - [pregunta 1]
   - [pregunta 2]
   - [pregunta 3]
3. Todas las restricciones y supuestos previos mencionados en el documento (enuméralos uno por uno)
4. Situaciones límite fáciles de pasar por alto (al menos 3)
5. Puntos contradictorios o poco claros del documento (si los hay)

Documento:
[pega aquí el texto completo del documento]

Usar este prompt para analizar documentos →

kimi-k3.1-pro, reasoning_effort: max, max_tokens: 8000. Referencia: aproximadamente $0.07 (entrada de unos 15000 tokens + salida de unos 3000 tokens). Los tokens de entrada de documentos extensos se calculan según la longitud real del documento; aquí se estima de forma conservadora en unos 10 000 caracteres chinos.

Puntos clave: sustituye las preguntas 2 y 3 por lo que realmente quieres saber del documento; no dejes los [pregunta 1] de la plantilla. Cuando el documento sea muy largo, configura reasoning_effort en max; con low es fácil perder información en contextos largos. Al analizar repetidamente el mismo documento extenso, a partir de la segunda vez la lectura de caché cuesta solo $0.2156/M tokens (1/10 del precio de entrada).

5. Análisis de datos: generar un informe de insights a partir de datos brutos

Proporciona un fragmento de datos CSV o JSON y pide al modelo que haga estadísticas automáticas, detecte tendencias, encuentre anomalías y emita directamente un informe que puedas pegar en el informe semanal.

Ejemplo de salida de referencia: el modelo hará primero una visión general de los datos (número de filas, campos, rango temporal), luego emitirá estadísticas de indicadores clave, descripción de tendencias, marcado de puntos de datos anómalos y, por último, ofrecerá 2-3 recomendaciones ejecutables.

Eres un analista de datos. A continuación se muestran datos brutos. Realiza el siguiente análisis y emite un informe:

1. Visión general de los datos: número de filas, lista de campos, rango temporal, integridad de los datos (tasa de valores faltantes)
2. Estadísticas de indicadores clave: selecciona automáticamente las medidas estadísticas adecuadas según el tipo de campo
   - Campos numéricos: media, mediana, valor máximo, valor mínimo, desviación estándar
   - Campos categóricos: Top 5 categorías y su porcentaje
3. Análisis de tendencias: si hay campos temporales, agrega los indicadores principales por semana/mes y describe la tendencia
4. Detección de anomalías: marca los puntos de datos que se desvíen de la media más de 2 desviaciones estándar
5. Conclusiones y recomendaciones: 2-3 recomendaciones ejecutables

Formato de salida: informe en Markdown, títulos por secciones, cifras clave en negrita.

Datos:
[pega aquí tus datos CSV o JSON]

Usar este prompt para analizar datos →

kimi-k3.1-pro, reasoning_effort: high. Referencia: aproximadamente $0.03 (entrada de unos 2000 tokens + salida de unos 2000 tokens). Cuando el volumen de datos sea grande, los tokens de entrada aumentarán en consecuencia.

Puntos clave: no incluyas información sensible en los datos (IDs de usuario reales, números de teléfono, claves). Si hay muchas filas de datos, las primeras 200 filas son suficientes para que el modelo detecte tendencias y anomalías; K3.1 Pro no necesita todos los datos para dar conclusiones estadísticas precisas.

Forma general de escribir prompts

K3.1 Pro es un modelo de razonamiento, por lo que los prompts no necesitan prefijos comodín del tipo "eres un XX profesional". Tres puntos clave:

1. Da estructura, no pasos: define el formato de salida y las dimensiones que deben cubrirse; deja que el modelo razone por sí mismo cómo rellenarlo, lo que funciona mejor que enseñarle los pasos uno a uno.
2. Haz preguntas concretas: "analiza este registro" es inferior a "encuentra la primera anomalía que aparece en estas 500 líneas de registro, su llamador ascendente y qué configuraciones hay que cambiar para corregirla".
3. Elige reasoning_effort según el escenario: usa high o max para diagnóstico de fallos y documentos extensos, y low para preguntas y respuestas simples y conversión de formato; el coste puede variar varias veces.

Abre la página del modelo Kimi K3.1 Pro, elige un escenario, copia el prompt y empieza a generar.

Artículos de la serie Kimi K3.1 Pro

• Página del modelo
• ¿Cómo usar la API? Realiza tu primera llamada en 5 minutos
• Comparación de precios
• Kimi K3.1 Pro vs Claude Opus 5.5