Guía de prompt engineering: técnicas, principios y errores frecuentes

El prompt engineering es el proceso de diseñar instrucciones para modelos de lenguaje que produzcan el output deseado de forma consistente. Es parte técnica, parte redacción, parte depuración.

En 2025, con modelos más capaces y context windows más grandes, el prompt engineering ha evolucionado: ya no se trata solo de formular preguntas, sino de construir el contexto completo que necesita el modelo para hacer bien su trabajo.

Qué es y qué no es prompt engineering

Es:

Diseñar instrucciones claras y específicas que el modelo pueda seguir
Estructurar el contexto que el modelo necesita para la tarea
Iterar sistemáticamente hasta obtener resultados consistentes
Definir el formato del output de forma explícita

No es:

Trucos mágicos o "palabras clave" que desbloquean capacidades ocultas
Algo que se aprende de una vez (los mejores prompts se descubren con iteración)
Sustituto de buena ingeniería (un sistema mal diseñado no se arregla con mejor prompt)

Los 6 principios fundamentales

1. Sé específico sobre la tarea

El error más común es describir vagamente lo que quieres. Cuanto más específica es la instrucción, más predecible y consistente es el output.

| Vago | Específico | |------|-----------| | "Resume este texto" | "Resume este texto en 3 bullet points de máximo 20 palabras cada uno, enfocados en las implicaciones para el negocio" | | "Traduce esto" | "Traduce al español de España, manteniendo el tono formal. Los términos técnicos en inglés pueden mantenerse si no tienen traducción estándar establecida" | | "Responde como experto" | "Eres un ingeniero backend con 10 años de experiencia en sistemas distribuidos. Tu audiencia son desarrolladores junior que acaban de unirse al equipo" |

2. Define el formato del output explícitamente

Si el output tiene que ser procesado por código, necesita ser predecible. Si el output es para un usuario, define el estilo.

Responde SIEMPRE con este JSON:
{
  "categoria": "soporte_tecnico" | "facturacion" | "general",
  "urgencia": "alta" | "media" | "baja",
  "resumen": "máximo 50 palabras"
}
No añadas explicación ni texto fuera del JSON.

3. Proporciona ejemplos (few-shot)

Mostrar ejemplos de input/output es una de las técnicas más efectivas. El modelo aprende el patrón deseado de los ejemplos mejor que de instrucciones abstractas.

Clasifica el sentimiento del texto.

Texto: "El envío llegó tarde pero el producto es bueno"
Sentimiento: mixto

Texto: "Excelente atención, resolvieron mi problema en minutos"
Sentimiento: positivo

Texto: "Llevo tres días esperando respuesta y nadie me ha contactado"
Sentimiento: negativo

Texto: [INPUT]
Sentimiento:

4. Asigna un rol claro

Dar un rol al modelo mejora la coherencia del estilo y el nivel de expertise que aplica. No es un truco — es context engineering: le estás dando información sobre cómo debe comportarse.

Eres un asistente de soporte técnico de una empresa de SaaS.
Tu objetivo es resolver el problema del usuario en el menor número de pasos.
Si la solución requiere más de 3 pasos, ofrece primero la opción más rápida.
Si el problema está fuera de tu alcance, escala al equipo de ingeniería con un resumen del problema.

5. Gestiona casos edge explícitamente

Si no dices qué hacer en casos límite, el modelo improvisa. Improvisa bien a veces, mal otras.

Si el usuario pregunta sobre algo fuera del scope de esta herramienta:
- Di claramente que no puedes ayudar con eso
- Sugiere la alternativa más cercana que sí puedas ofrecer
- No inventes respuestas sobre temas que no conoces

Si el mensaje está en un idioma que no sea español o inglés:
- Responde en ese idioma si puedes
- Si no, responde en español e indica que no puedes continuar en ese idioma

6. Instruye la longitud y el estilo

Sin instrucción de longitud, el modelo tiende a elaborar más de lo necesario.

Respuestas concisas: máximo 150 palabras.
Usa bullet points cuando haya más de 2 puntos.
Sin introducción ni conclusión: ve directo al contenido.
Tono profesional pero cercano. Sin jerga técnica excepto si el usuario la usa primero.

Técnicas avanzadas

Chain-of-Thought (CoT)

Pide al modelo que razone paso a paso antes de dar la respuesta final. Mejora significativamente la precisión en tareas que requieren razonamiento.

Antes de responder, razona paso a paso:
1. ¿Qué está preguntando exactamente el usuario?
2. ¿Qué información relevante tengo disponible?
3. ¿Cuál es la respuesta más correcta y completa?

Luego da tu respuesta final.

Para tareas de razonamiento complejo, simplemente añadir "Piensa paso a paso" mejora los resultados.

Few-Shot vs Zero-Shot

Zero-shot: Solo instrucciones, sin ejemplos. Funciona bien para modelos modernos y tareas generales.

Few-shot: Incluye 2-5 ejemplos de input/output. Más efectivo cuando:

El formato de output es específico o inusual
La tarea requiere un estilo muy particular
Zero-shot produce outputs inconsistentes

Cuántos ejemplos: 2-3 ejemplos suelen ser suficientes. Más de 5-6 raramente mejora los resultados y añade tokens innecesarios.

Self-consistency

Para preguntas con respuesta única correcta (matemáticas, razonamiento lógico), genera la respuesta varias veces con temperatura > 0 y toma la respuesta mayoritaria.

responses = []
for _ in range(5):
    response = llm.generate(prompt, temperature=0.7)
    responses.append(extract_answer(response))

# Respuesta más frecuente
final_answer = Counter(responses).most_common(1)[0][0]

Role + Audience + Goal

Una estructura que funciona bien para system prompts:

ROL: Quién eres y qué expertise tienes
AUDIENCIA: A quién te diriges y su nivel de conocimiento
OBJETIVO: Qué intentas lograr en cada interacción
RESTRICCIONES: Lo que no debes hacer o decir
FORMATO: Cómo estructurar las respuestas

Proceso de iteración

El buen prompt engineering no se hace de una sola vez. El proceso:

Escribe el primer prompt: simple, claro, directo
Prueba con 10-20 inputs representativos del uso real
Identifica los fallos: ¿qué patrones de input producen output incorrecto?
Añade instrucciones específicas para los casos que fallan
Repite hasta que la tasa de error sea aceptable
Versiona el prompt (git o similar) para poder comparar versiones

Errores frecuentes

Instrucciones contradictorias: "Sé conciso pero completo" no es accionable. Elige uno.

Instrucciones negativas sin alternativa: "No seas agresivo" es peor que "Mantén siempre un tono empático y resolutivo".

Prompt demasiado largo: Un prompt de 2000 palabras que repite las mismas instrucciones de cinco formas distintas. El modelo no lee más cuidadosamente porque le des más instrucciones — se confunde.

No separar instrucciones de contenido: Mezclar instrucciones sobre cómo comportarse con el contenido sobre el que tiene que actuar dificulta que el modelo priorice correctamente. Usa delimitadores claros:

[INSTRUCCIONES]
Resume el siguiente texto en 3 bullets.

[TEXTO]
{texto_a_resumir}

Asumir que el prompt funciona igual en todos los modelos: GPT-4o, Claude y Gemini tienen sensibilidades distintas a la misma instrucción. Lo que funciona en uno puede necesitar ajustes en otro.

Recursos relacionados:

Técnicas de prompting avanzadas — Chain-of-Thought, Tree-of-Thoughts y más
Cómo estructurar un system prompt profesional — del prompt al system prompt
Prompt Engineering vs Context Engineering — cuándo cada enfoque es el correcto
Evaluador de System Prompts — evalúa tu prompt en 8 dimensiones