Técnicas · 8 min de lectura

Técnicas de ingeniería de prompts con ejemplos

Zero-shot, few-shot, razonamiento paso a paso, rol, descomposición, autocrítica, salida estructurada y XML: cuándo usar cada técnica, con ejemplos.

Las técnicas de ingeniería de prompts son formas probadas de estructurar una petición para que el modelo razone mejor, respete un formato o se equivoque menos. No hace falta usarlas todas a la vez: cada una resuelve un problema concreto. Aquí tienes ocho técnicas, cuándo conviene cada una y un ejemplo listo para adaptar.

Si todavía no dominas lo básico (rol, contexto, tarea y formato), empieza por la guía de cómo escribir prompts y vuelve aquí después.

Zero-shot y few-shot: con o sin ejemplos

Zero-shot

Consiste en pedir la tarea directamente, sin ejemplos. Funciona muy bien con tareas habituales que el modelo ya conoce: resumir, traducir, clasificar en categorías evidentes. Es el punto de partida: si el resultado es bueno, no compliques el prompt.

Clasifica el siguiente comentario de cliente como positivo, negativo o neutro. Responde solo con la etiqueta.

Comentario: "El pedido llegó tarde, pero el producto es excelente."

Few-shot

Consiste en mostrar entre dos y cinco ejemplos de entrada y salida antes del caso real. Úsalo cuando necesites un criterio propio, un estilo particular o un formato que el modelo no adivinaría. Los ejemplos enseñan más que cualquier descripción, así que elige casos variados y representativos: si todos se parecen, el modelo copiará detalles irrelevantes.

Convierte notas sueltas en tareas con el formato: acción — responsable — plazo.

Nota: hablar con Ana del presupuesto antes del jueves
Tarea: Revisar presupuesto — Ana — jueves

Nota: el lunes Luis manda el borrador del contrato
Tarea: Enviar borrador del contrato — Luis — lunes

Nota: alguien tiene que actualizar la web con los precios nuevos, idealmente esta semana
Tarea:

Observa que el último caso no tiene responsable claro. Un buen conjunto de ejemplos también enseña qué hacer con lo ambiguo; podrías añadir un cuarto ejemplo con «sin asignar» para que el modelo no se invente un nombre.

Pedir razonamiento paso a paso

En problemas con varios pasos (cálculos, lógica, planificación), pedir que el modelo razone antes de concluir reduce errores. Muchos modelos actuales ya razonan internamente antes de responder, así que la fórmula clásica «piensa paso a paso» aporta menos que antes; suele ser más útil pedir que muestre los cálculos clave y que compruebe el resultado al final.

Un plan de suscripción cuesta 12 dólares al mes o 120 dólares al año, pagados por adelantado y sin reembolso. Si un cliente se da de baja al terminar el mes 8, ¿qué opción le salió más barata?

Muestra cada cálculo en una línea. Al final, comprueba el resultado por otro camino y da la respuesta en una sola frase.

Si solo necesitas la conclusión, pídelo así: «razona internamente y muéstrame solo el resultado y la comprobación». Ahorras lectura sin perder precisión.

Asignar un rol que cambie la respuesta

El rol define desde qué experiencia se responde. Su valor real aparece cuando lo acompañas de criterios: no basta con «eres un experto en marketing»; añade qué prioriza ese experto y para quién trabaja.

Actúa como un revisor de contratos de alquiler que asesora a inquilinos sin formación jurídica. Lee el texto de abajo y señala las cláusulas que podrían perjudicar al inquilino, explicando cada una en lenguaje sencillo. No des una opinión legal definitiva: indica cuándo conviene consultar a un abogado.

Contrato:
"""
[pega aquí el contrato]
"""

Un rol también puede ser una audiencia simulada. «Responde como lo haría un cliente escéptico que ya probó tres herramientas parecidas» es una forma rápida de poner a prueba un texto de ventas antes de publicarlo.

Descomposición y encadenamiento de prompts

Cuando una tarea es grande (un informe, una estrategia, un artículo largo), pedirlo todo en un solo mensaje produce resultados superficiales. Es mejor dividir: primero un esquema, luego cada parte y al final la revisión. Cada paso usa el resultado del anterior, y tú puedes corregir el rumbo entre uno y otro.

Paso 1 de 3. Quiero preparar una guía de bienvenida para nuevos empleados de una agencia de diseño de doce personas.
Antes de redactar nada, propón un índice de 6 a 8 secciones con una línea que explique el objetivo de cada una. Espera mi aprobación antes de continuar.

Tras el visto bueno, sigues con «Paso 2: redacta la sección 3 en un máximo de 300 palabras». La ventaja añadida es que puedes ajustar el tono en la primera sección y pedir que el resto siga ese modelo.

El último eslabón de la cadena suele ser una revisión de conjunto, que detecta repeticiones y contradicciones que no se ven sección por sección:

Paso 3 de 3. Aquí tienes la guía completa. Revísala como lo haría un empleado en su primer día: señala términos internos sin explicar, pasos que se contradigan entre secciones y cualquier información que falte para empezar a trabajar. Devuelve una lista priorizada de cambios, sin reescribir el texto.

Separar la redacción de la revisión tiene otra ventaja: puedes hacer la revisión en un chat nuevo, sin el historial de la conversación, para que el modelo lea la guía con ojos frescos.

Autocrítica: que el modelo revise su propio trabajo

Los modelos detectan fallos con más facilidad cuando se les pide explícitamente revisar un texto con criterios concretos. La técnica tiene dos tiempos: generar y, después, evaluar contra una lista.

Escribe una descripción de 80 palabras para una mochila impermeable de 20 litros pensada para ciclistas urbanos.

Después, revisa tu texto con esta lista y corrige lo que no cumpla:
1. ¿Menciona un beneficio concreto en la primera frase?
2. ¿Evita afirmaciones que no se puedan comprobar?
3. ¿Tiene 80 palabras o menos?
Muestra solo la versión final y una línea con los cambios que hiciste.

La autocrítica no sustituye tu revisión: el modelo puede dar por buena una afirmación falsa. Úsala para pulir la forma y el cumplimiento de requisitos, no como verificación de hechos.

Salida estructurada y delimitadores

Salida estructurada: JSON, tablas y plantillas

Si vas a copiar la respuesta en una hoja de cálculo, una base de datos o un programa, pide una estructura exacta: nombres de campos, tipo de dato y qué hacer si falta información. Mostrar el esquema evita sorpresas.

Extrae los datos de este correo y devuelve solo un JSON válido con esta forma:
{"nombre": "", "empresa": "", "fecha_reunion": "AAAA-MM-DD", "temas": []}
Si un dato no aparece, usa null. No añadas texto fuera del JSON.

Correo:
"""
[pega aquí el correo]
"""

Para tablas, nombra las columnas en el orden exacto en que las quieres y di qué va en cada celda cuando no hay dato («escribe "sin datos", no dejes celdas vacías»). Si procesas muchos textos con el mismo esquema, revisa de vez en cuando un resultado al azar: un campo mal interpretado se repetirá en todos.

Delimitadores y etiquetas XML

Cuando el prompt mezcla instrucciones con material de trabajo (un texto para resumir, datos para analizar), sepáralos con comillas triples, almohadillas (###) o etiquetas. Así el modelo no confunde el contenido con órdenes. Claude, en particular, sigue muy bien las etiquetas de tipo XML, aunque funcionan con cualquier modelo.

<instrucciones>
Resume el documento en cinco viñetas para una directora que tiene dos minutos. Usa solo información del documento.
</instrucciones>

<documento>
[pega aquí el texto]
</documento>

Los delimitadores también reducen un riesgo práctico: si el texto pegado contiene frases como «ignora las instrucciones anteriores», quedan marcadas como contenido y no como órdenes. No es una protección total, pero ayuda.

Cómo combinar técnicas sin sobrecargar el prompt

Las técnicas se suman, pero no todas a la vez. Una regla práctica para elegir:

  • Tarea simple y conocida: zero-shot con un formato claro.
  • Criterio o estilo propio: few-shot con dos o tres ejemplos variados.
  • Problema con cálculos o lógica: razonamiento visible y comprobación final.
  • Entregable largo: descomposición en pasos y autocrítica al final de cada uno.
  • Resultado para otro programa: salida estructurada con un esquema de ejemplo.
  • Mucho material pegado: delimitadores o etiquetas XML.

Para practicar, el generador de prompts arma la estructura base y, si eliges Claude como IA de destino, la escribe con etiquetas XML. Para un asistente que usarás muchas veces, el generador de system prompts te ayuda a fijar una sola vez identidad, reglas y límites. Y si quieres repasar términos como few-shot, cadena de pensamiento o ventana de contexto, consulta el glosario de ingeniería de prompts.

Preguntas frecuentes

¿Qué es la ingeniería de prompts?

Es la práctica de diseñar y ajustar las instrucciones que le das a un modelo de IA para obtener resultados más precisos, útiles y consistentes. Incluye elegir qué información dar, en qué orden, con qué ejemplos y en qué formato pedir la respuesta.

¿Cuándo uso few-shot en lugar de zero-shot?

Empieza siempre con zero-shot. Pasa a few-shot cuando el resultado no sigue tu criterio o tu formato, por ejemplo al clasificar con categorías propias o al imitar un estilo de redacción concreto.

¿Sigue sirviendo decir «piensa paso a paso»?

Ayuda menos con los modelos que ya razonan antes de responder, pero sigue siendo útil pedir que muestren los cálculos clave o que comprueben el resultado. En modelos más pequeños o rápidos, pedir el razonamiento todavía puede mejorar la precisión en problemas de varios pasos.

¿Las etiquetas XML solo funcionan con Claude?

No. Cualquier modelo entiende que una etiqueta como <documento> delimita un bloque de contenido. Claude está especialmente acostumbrado a este estilo, pero en ChatGPT o Gemini también puedes usar etiquetas, comillas triples o encabezados con ###.

Herramientas relacionadas