# Prompt engineering desde cero: técnicas para mejores instrucciones

**Categoría:** Inteligencia artificial · **Nivel:** Intermedio · **Lectura:** 11 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/inteligencia-artificial/prompt-engineering-desde-cero/

## Respuesta rápida

El **prompt engineering** es el conjunto de técnicas para escribir las instrucciones (los *prompts*) que se le dan a un **modelo de lenguaje**, de modo que devuelva resultados mejores y más confiables. Un mismo modelo puede dar una respuesta inservible o excelente según cómo se lo instruya, y estas técnicas convierten esa diferencia en algo sistemático. Las principales: dar **contexto y un rol** claros («sos un asistente legal, respondé para un público sin formación jurídica»); mostrar **ejemplos** del resultado deseado (*few-shot*), que suele funcionar mejor que explicarlo; pedir **razonamiento paso a paso** (*chain-of-thought*) en tareas que requieren pensar, no solo recordar; **forzar el formato de salida** (por ejemplo, JSON con campos fijos) cuando otra parte del sistema va a procesar la respuesta; y **descomponer** tareas complejas en pasos. La regla que lo ordena todo: **iterar midiendo**, no adivinando —cambiar el prompt y comprobar con casos reales si mejoró, en vez de confiar en la impresión—. Esta guía sistematiza las técnicas para construir aplicaciones; para el uso cotidiano, ver [cómo escribir buenos prompts](../como-escribir-buenos-prompts/index.md).

## Qué es (y qué no) el prompt engineering

Un **modelo de lenguaje** genera su respuesta a partir de las instrucciones que recibe. Como esas instrucciones condicionan fuertemente el resultado, aprender a escribirlas bien tiene un impacto enorme: el mismo modelo, con el mismo conocimiento, puede resolver o arruinar una tarea según cómo se le pida. El **prompt engineering** es la práctica de escribir esas instrucciones de forma deliberada y reproducible.

> **No es magia ni «palabras mágicas»**
>
> Circulan listas de «frases mágicas» que supuestamente desbloquean al modelo. Eso no es prompt engineering: es superstición. Las técnicas reales son entendibles y tienen una lógica —dar contexto, mostrar ejemplos, pedir razonamiento— y su efecto se puede **medir**. La diferencia entre prompt engineering y probar frases al azar es la misma que entre [depurar con método](../../programacion/como-depurar-errores-de-programacion/index.md) y cambiar cosas hasta que funcione.

Conviene distinguirlo del **uso cotidiano**. Pedirle a un asistente que resuma un correo es uso cotidiano, cubierto en [cómo escribir buenos prompts](../como-escribir-buenos-prompts/index.md). El prompt engineering entra cuando se construye una **aplicación** sobre el modelo: ahí el prompt es parte del código, se versiona, se prueba y se optimiza.

## Contexto y rol

La primera y más rentable técnica es dar **contexto** y un **rol**. Un prompt vago como «resumí esto» deja al modelo adivinando para quién, con qué extensión y con qué tono. Decirle quién debe ser y para quién responde orienta todo:

```texto
Sos un asistente que resume artículos técnicos para personas
sin formación en el tema. Resumí el siguiente texto en 3 viñetas,
en lenguaje simple, sin tecnicismos sin explicar.

[texto...]
```

El rol fija el **tono** y la **profundidad**; el contexto sobre el destinatario fija el **vocabulario**. Con eso solo, la calidad del resultado suele dar un salto. Es el equivalente a especificarle bien una tarea a una persona en vez de darle una orden ambigua.

## Ejemplos y razonamiento paso a paso

Dos técnicas muy potentes se apoyan en cómo funcionan estos modelos, que aprenden de patrones:

- **Ejemplos (*few-shot*).** En vez de *describir* lo que querés, *mostralo*: incluí uno o varios ejemplos de entrada y su salida deseada, y el modelo imita el patrón. Suele funcionar mejor que cualquier explicación, sobre todo para formatos o estilos difíciles de poner en palabras. Sin ejemplos, se lo llama *zero-shot*.
- **Razonamiento paso a paso (*chain-of-thought*).** Para tareas que requieren *pensar* —lógica, matemática, decisiones con varios factores— pedirle al modelo que razone en pasos antes de dar la respuesta final mejora notablemente la precisión. En cambio, para tareas de simple recuperación de datos aporta poco.

La clave es elegir la técnica según la tarea: los ejemplos brillan cuando importa el *formato o el estilo*; el razonamiento paso a paso, cuando importa la *corrección de un proceso*. Combinarlas —ejemplos que además muestran el razonamiento— es una práctica avanzada habitual.

## Formato de salida e iteración

Cuando el resultado del modelo lo va a consumir **otra parte del sistema** —no una persona—, hace falta que la salida sea predecible. Ahí entra **forzar el formato**: pedir explícitamente, por ejemplo, un objeto JSON con campos fijos.

```texto
Devolvé SOLO un objeto JSON con esta forma, sin texto adicional:
{"sentimiento": "positivo|neutro|negativo", "confianza": 0.0-1.0}
```

Así la respuesta se puede procesar con código en lugar de tener que interpretar texto libre. Muchos modelos ofrecen además un modo de salida estructurada que garantiza el formato. Y por encima de todas las técnicas está la que las vuelve confiables:

> **Atención**
>
> Un prompt casi nunca sale perfecto a la primera. La forma correcta de mejorarlo no es cambiar palabras «a ver si sale mejor» y quedarse con la impresión, sino **probar contra un conjunto de casos reales** y medir si mejoró. Esto es [evaluación de aplicaciones con modelos de lenguaje](../evaluacion-de-aplicaciones-con-modelos-de-lenguaje/index.md), y es lo que separa el prompt engineering serio del ensayo y error. Sin medición, «mejorar» un prompt es una ilusión: puede que hayas arreglado un caso y roto tres.

## Errores frecuentes

- **Creer en «palabras mágicas».** Las técnicas tienen una lógica; las frases secretas son superstición.
- **Prompts vagos sin contexto ni rol.** «Resumí esto» deja al modelo adivinando el tono, la extensión y el público.
- **Describir en vez de mostrar.** Para formatos y estilos, un ejemplo vale más que un párrafo de explicación.
- **Pedir razonamiento donde no aporta.** En tareas de simple recuperación, el paso a paso solo alarga sin mejorar.
- **No forzar el formato cuando lo consume un programa.** El texto libre es impredecible de procesar.
- **Iterar por impresión.** Sin medir contra casos reales, no se sabe si el cambio mejoró o empeoró.
- **Confiar ciegamente en la salida.** El modelo puede equivocarse con seguridad; hay que validar lo crítico.

## Preguntas frecuentes

**¿Qué es el prompt engineering?**
Es el conjunto de técnicas para escribir las instrucciones, llamadas prompts, que se le dan a un modelo de lenguaje, con el objetivo de obtener resultados mejores y más confiables. Su fundamento es que un mismo modelo, con el mismo conocimiento, puede dar una respuesta inservible o una excelente según cómo se lo instruya, de modo que aprender a formular bien las instrucciones tiene un impacto enorme sobre la calidad de lo que se obtiene. El prompt engineering convierte esa diferencia en algo sistemático y reproducible, en lugar de dejarla librada a la suerte. Sus técnicas principales incluyen dar contexto y un rol claros, mostrar ejemplos del resultado deseado, pedir razonamiento paso a paso en tareas que lo requieren, forzar un formato de salida cuando otra parte del sistema va a procesar la respuesta, y descomponer las tareas complejas. Por encima de todas está la práctica de iterar midiendo el resultado contra casos reales, que es lo que distingue el trabajo serio del ensayo y error.

**¿En qué se diferencia de la guía sobre cómo escribir buenos prompts?**
La guía sobre cómo escribir buenos prompts está orientada al uso cotidiano de los asistentes de inteligencia artificial: cómo pedirle a una herramienta como ChatGPT o Gemini que resuma un texto, redacte un correo o responda una consulta de la mejor manera posible. Es la introducción práctica para quien usa estas herramientas en su día a día. Esta guía, en cambio, sistematiza las técnicas de prompt engineering pensando en quien construye aplicaciones sobre modelos de lenguaje, donde el prompt deja de ser un mensaje suelto y pasa a ser parte del código: se versiona, se prueba, se optimiza y se mide. Aquí el foco está en entender por qué funciona cada técnica —contexto y rol, ejemplos, razonamiento paso a paso, formato de salida, descomposición— y en cómo iterar de forma medible. La recomendación es empezar por la guía de uso cotidiano para lo general, y usar esta cuando se necesite integrar un modelo en un producto o automatización de forma profesional.

**¿Qué son few-shot y chain-of-thought?**
Son dos de las técnicas más potentes del prompt engineering, y ambas se apoyan en que estos modelos aprenden de patrones. Few-shot, que significa con pocos ejemplos, consiste en no limitarse a describir lo que uno quiere, sino en mostrar dentro del prompt uno o varios ejemplos de entrada junto con su salida deseada, para que el modelo imite ese patrón; suele funcionar mejor que cualquier explicación, especialmente cuando importa el formato o el estilo, que son difíciles de poner en palabras. Cuando no se dan ejemplos, se habla de zero-shot. Chain-of-thought, o cadena de pensamiento, consiste en pedirle al modelo que razone paso a paso antes de dar la respuesta final; esto mejora notablemente la precisión en tareas que requieren pensar, como problemas de lógica, matemática o decisiones que involucran varios factores, porque obliga al modelo a desplegar el razonamiento en lugar de saltar a una conclusión. En cambio, para tareas de simple recuperación de datos aporta poco y solo alarga la respuesta.

**¿Cuándo conviene forzar un formato de salida como JSON?**
Conviene siempre que la respuesta del modelo no la vaya a leer una persona, sino que la vaya a consumir otra parte del sistema, como un programa que necesita extraer datos concretos de ella. Si un modelo responde en texto libre, ese texto es impredecible en su estructura y resulta frágil y complicado de procesar automáticamente. En cambio, si se le exige explícitamente que devuelva, por ejemplo, un objeto JSON con campos fijos y sin ningún texto adicional, la salida se vuelve predecible y un programa puede interpretarla de forma confiable. Muchos modelos ofrecen además un modo de salida estructurada que garantiza que la respuesta cumpla un esquema definido, lo cual es aún más robusto que pedirlo solo en el texto del prompt. En resumen, cuando hay una persona del otro lado, el texto natural está bien; cuando hay código del otro lado, forzar un formato estricto es casi obligatorio para construir una aplicación fiable.

**¿Por qué es tan importante iterar midiendo?**
Porque sin medición, mejorar un prompt es una ilusión. Un prompt casi nunca sale perfecto a la primera, y la tentación natural es cambiar algunas palabras, mirar una respuesta y quedarse con la impresión de que ahora funciona mejor. El problema es que esa impresión es engañosa: al ajustar el prompt para arreglar un caso, es muy fácil romper otros sin darse cuenta, porque solo se miró un ejemplo. La forma correcta de mejorar un prompt es probarlo contra un conjunto de casos reales y representativos, y medir de forma objetiva si el resultado global mejoró o empeoró. Esto es evaluación de aplicaciones con modelos de lenguaje, y es exactamente lo que distingue el prompt engineering serio del ensayo y error a ciegas. La analogía con la programación es directa: cambiar un prompt sin medir es como modificar código sin pruebas, confiando en que la única vez que se probó representa todos los casos, cuando casi nunca es así.

**¿El prompt engineering resuelve las alucinaciones del modelo?**
Las reduce y las gestiona, pero no las elimina, y es importante tener esto claro para no confiar de más. Las alucinaciones son respuestas que el modelo presenta con seguridad pero que son incorrectas o inventadas, y provienen de la naturaleza misma de cómo funcionan estos modelos, que generan texto plausible sin una noción de verdad. Un buen prompt engineering puede disminuir su frecuencia: pedir que el modelo cite sus fuentes, que indique cuándo no está seguro, que se base solo en un texto proporcionado en lugar de en su memoria, o que razone paso a paso, ayuda a acotar el problema. Para tareas donde la exactitud factual es crítica, la técnica más efectiva es combinar el prompt con la recuperación de información desde fuentes confiables, un enfoque conocido como RAG, de modo que el modelo responda apoyándose en documentos reales. Pero incluso con todas estas precauciones, la salida de un modelo debe validarse cuando es crítica, porque ninguna técnica de prompt garantiza la ausencia total de errores.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Integración de modelos de lenguaje en aplicaciones.
2. **Underc0de, foro.** [Sección Informática](https://underc0de.org/foro/informatica/). Uso general de herramientas de IA.

### Documentación oficial

1. **OpenAI.** [Prompt engineering](https://platform.openai.com/docs/guides/prompt-engineering). Guía oficial de técnicas, citada en el texto.
2. **Anthropic.** [Prompt engineering overview](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview). Técnicas y buenas prácticas.
3. **Google.** [Prompting strategies](https://ai.google.dev/gemini-api/docs/prompting-strategies). Estrategias de la documentación de Gemini.
4. **DAIR.AI.** [Prompt Engineering Guide](https://www.promptingguide.ai/). Compendio abierto de técnicas y su evidencia.

## Guías relacionadas

- [Cómo escribir buenos prompts](../como-escribir-buenos-prompts/index.md)
- [Crear un sistema RAG](../como-crear-un-sistema-rag-con-documentos-propios/index.md)
- [Evaluar aplicaciones con LLM](../evaluacion-de-aplicaciones-con-modelos-de-lenguaje/index.md)
- [Qué es ChatGPT](../que-es-chatgpt-y-como-usarlo/index.md)
- [Índice de Inteligencia artificial](../index.md)