Ingeniería de prompts

Ingeniería de prompts: pedir bien a la primera

Un buen prompt no es una fórmula mágica: es un encargo bien hecho, como el que le harías a un profesional que no te conoce. Esta guía te da la estructura, las técnicas que de verdad marcan la diferencia y plantillas para copiar.

La estructura: cinco piezas

Casi todos los buenos prompts tienen estas piezas. No hace falta ponerlas siempre todas, pero sí pensarlas:

Pieza	Qué es	Ejemplo
Rol	Desde dónde debe responder	«Actúa como técnico de prevención de riesgos»
Contexto	La situación, el público y el objetivo	«Es para encargados de obra sin formación técnica»
Tarea	Qué quieres, con un verbo claro	«Redacta un procedimiento de 10 pasos»
Formato	Extensión, estructura y tono	«Lista numerada, frases cortas, tú»
Criterios	Cómo sabrás que está bien	«Cada paso con su riesgo y su medida»

Plantilla básica

Actúa como [rol].
Contexto: [situación, público y para qué es].
Tarea: [qué necesito, con un verbo claro].
Formato: [extensión, estructura, tono].
Criterios: [qué tiene que cumplir para estar bien].
Si te falta información importante, pregúntame antes de responder (máximo 3 preguntas).

Las técnicas que más cambian el resultado

1. Da contexto de verdad

El error número uno es pedir sin contexto. «Escribe un correo a un cliente» da un correo genérico. «Escribe un correo a un cliente que lleva 3 semanas esperando una pieza; queremos disculparnos sin prometer fecha y ofrecer una alternativa» da el correo que necesitas.

2. Enseña con ejemplos

Si tienes un ejemplo de lo que quieres (un informe bueno, un tono, un formato), dáselo. Con dos o tres ejemplos el modelo imita estructura, extensión y estilo mucho mejor que con cualquier descripción. Se llama *few-shot*.

3. Separa las instrucciones de los datos

Cuando pegues un documento, márcalo para que el modelo no confunda lo que le pides con lo que tiene que analizar. Las etiquetas tipo XML funcionan muy bien:

Instrucciones y datos separados

Resume el contrato que va entre las etiquetas en 5 puntos para alguien sin formación jurídica. Cita la cláusula de cada punto.
<contrato>
[pega aquí el contrato]
</contrato>

4. Pide que piense en los problemas difíciles

Para cálculos, lógica, diagnósticos o planes, pide que razone por pasos antes de dar la respuesta, o activa el modo de razonamiento de la herramienta. Para tareas sencillas no hace falta: solo tarda más.

5. Pide un formato concreto

Tabla, lista, JSON, «máximo 120 palabras», «en tres apartados con estos títulos». Si el resultado va a otro programa, pide JSON y describe los campos.

6. Dale permiso para decir «no lo sé»

Añade «si no está en el documento o no estás seguro, dilo». Reduce mucho las invenciones.

7. Itera en vez de empezar de cero

Si la primera respuesta no es buena, corrige en la misma conversación: «más corto», «el tercer punto es incorrecto porque…», «cambia el tono a…». Cada corrección le da contexto.

Patrones útiles para copiar

Que me entreviste antes de hacer el trabajo

Quiero [resultado]. Antes de hacerlo, hazme las preguntas que necesites, de una en una, hasta tener lo necesario para hacerlo muy bien. Cuando lo tengas, dime «Ya tengo lo necesario» y hazlo.

Crítica y mejora

Aquí tienes mi [texto/plan/código]. Critícalo como un experto exigente: 3 problemas importantes con su porqué y una versión mejorada. No suavices.
<borrador>
[pega aquí]
</borrador>

Varias opciones con criterio

Dame 3 opciones distintas para [problema]. Para cada una: en qué consiste, ventajas, inconvenientes, coste aproximado y cuándo la elegirías. Termina con tu recomendación y por qué.

Salida estructurada para otro programa

Extrae de este texto los datos y devuelve SOLO un JSON válido con estos campos: {"cliente": texto, "fecha": "AAAA-MM-DD", "importe": número, "pendiente": true/false}. Si un campo no aparece, pon null. No inventes valores.

Errores típicos

Pedir sin contexto y quejarse de que es genérico.
Varias tareas a la vez en un solo prompt largo: mejor por pasos.
Prohibiciones en negativo sin alternativa («no seas formal»): di lo que sí quieres («escribe como hablarías a un compañero»).
No dar ejemplos cuando tienes uno a mano.
Fiarse de la primera respuesta en cifras, citas y normas.
Repetir el mismo prompt cuando falla en vez de cambiar qué le das.

De prompt a sistema

Cuando un prompt te funcione y lo uses a menudo, no lo vuelvas a escribir: guárdalo como instrucciones de un proyecto, un GPT, una skill o un Gem. Así lo mejoras una vez y lo usas siempre. En el kit gratuito tienes una biblioteca de prompts y plantillas de skills.

Fuentes

Siguiente guía: Ingeniería de contexto: el 80 % del resultado