Prompt engineering para diseñadores: escribir instrucciones que un modelo siga
Prompt engineering es diseñar las instrucciones, el contexto y los ejemplos de un modelo. Qué recomiendan Anthropic, OpenAI y Google y un método para iterar.
¿Qué es un prompt?
Un prompt es todo lo que el modelo recibe antes de responder: las instrucciones de rol, el contexto, los ejemplos, el historial y la pregunta. En muchas aplicaciones, buena parte de ese texto lo escribe el equipo, no el usuario, y el usuario solo aporta su parte.
El campo es joven y su vocabulario no está estandarizado. The Prompt Report, un estudio de 2024, propuso una taxonomía de 58 técnicas de prompting para modelos de lenguaje con texto y 33 términos de vocabulario. Sus autores señalan que el área sufre de terminología en conflicto. Para un diseñador, eso significa concentrarse en pocas técnicas bien entendidas y no en una lista interminable.
¿Qué técnicas básicas recomiendan los proveedores?
Las guías oficiales de Anthropic, OpenAI y Google coinciden en una base común:
- Instrucción clara y específica. Indica la tarea, el público y el objetivo. Anthropic propone una prueba: enséñale el prompt a un colega sin contexto y pídele que lo siga; si se confunde, el modelo también. “Resume esta reunión para un gerente que no asistió” funciona mejor que “resume esto”.
- Contexto y motivo. Anthropic recomienda explicar por qué importa una regla. En vez de “nunca uses puntos suspensivos”, escribe que la respuesta la leerá en voz alta un sintetizador de voz que no sabe pronunciarlos. Google y OpenAI coinciden en aportar el material de apoyo.
- Ejemplos. Dos o tres casos resueltos muestran el patrón (few-shot o multi-shot prompting). Anthropic sugiere de 3 a 5, relevantes y variados. Google pide que sean específicos y con formato consistente, y advierte que demasiados pueden causar sobreajuste. OpenAI pide cubrir un rango diverso de entradas.
- Estructura con delimitadores. Anthropic usa etiquetas XML para separar instrucciones, contexto y ejemplos. OpenAI sugiere Markdown para las secciones y XML para marcar dónde empieza y termina un documento. Google menciona delimitadores consistentes.
- Formato de salida. Indica si quieres una tabla, una lista o un párrafo. Google propone incluso empezar tú la respuesta, por ejemplo con la primera línea de un esquema.
- Rol. Anthropic indica que fijar un rol en el system prompt enfoca el comportamiento y el tono, aunque sea con una sola frase.
¿Hay que pedir razonamiento paso a paso?
Depende del modelo. La técnica de chain of thought, que hace que el modelo escriba pasos intermedios antes de responder, se describió en 2022 (Jason Wei y otros, de Google Brain). Hoy muchos modelos razonan por dentro, y las tres guías lo reflejan:
- OpenAI recomienda dar objetivos de alto nivel a los modelos de razonamiento, no instrucciones paso a paso.
- Anthropic dice que una instrucción como “piensa a fondo” suele funcionar mejor que un plan escrito a mano. Si el razonamiento interno está apagado, pedir pasos sigue siendo un recurso.
- Google indica que sus modelos Gemini 2.5 y 3 piensan internamente, así que normalmente no necesitas pedir los pasos en la salida.
Con un modelo sin razonamiento integrado, pedir pasos todavía puede ayudar. Con uno que razona, probablemente solo gasta tokens. Lo que decide es tu evaluación, no la costumbre. Más en modelos de razonamiento.
Otra técnica del campo es la autoconsistencia: generar varias respuestas y quedarse con la conclusión que más se repite. Sirve cuando hay una respuesta verificable, pero multiplica el costo.
¿Qué técnica usar en cada caso?
| Problema | Técnica probable | Costo en tokens |
|---|---|---|
| El formato cambia en cada respuesta | Formato de salida explícito y un ejemplo | Bajo |
| El tono no es el de la marca | Instrucción de voz con dos ejemplos aprobados | Bajo a medio |
| Errores en tareas de varios pasos | Objetivo claro y, según el modelo, razonamiento | Medio, más salida |
| Respuestas inconsistentes en tareas verificables | Autoconsistencia | Alto, varias ejecuciones |
| El modelo no conoce un dato | No es de prompt: usa RAG | Depende del contexto |
¿Cómo se estructura un prompt de producto?
Un prompt de producto suele tener cinco bloques: rol, tarea, contexto, restricciones y formato. Es una variante de lo que proponen las guías; OpenAI, por ejemplo, divide el mensaje en identidad, instrucciones, ejemplos y contexto. Mantener los bloques separados facilita ver qué cambió:
- Rol: quién responde y para quién.
- Tarea: qué debe producir, en una frase.
- Contexto: la información que el modelo necesita y no tiene. Con textos largos, Google sugiere poner primero el material y al final las instrucciones.
- Restricciones: lo que no debe hacer, con límites medibles.
- Formato: la estructura exacta de la salida.
¿Cómo se itera un prompt?
Antes de iterar, Anthropic pide tener definidos los criterios de éxito y una forma de probarlos. Sin eso no sabes si mejoraste algo. Un método que funciona para equipos de diseño:
- Escribe el prompt más simple que describa la tarea.
- Reúne unos 20 casos reales, incluidos los difíciles.
- Anota qué falla en cada respuesta, con una categoría: formato, tono, dato inventado, omisión.
- Cambia una cosa a la vez. Si cambias tres instrucciones, no sabrás cuál mejoró el resultado.
- Vuelve a correr los casos y compara con la versión anterior.
- Guarda la versión con su fecha y el modelo usado.
Los prompts son sensibles a la redacción y al orden del contenido: Google incluye entre sus estrategias de iteración reformular el prompt y cambiar el orden de ejemplos, contexto y entrada. OpenAI recomienda fijar una versión concreta del modelo en producción, mantener los prompts en el código con revisión como cualquier cambio y correr de nuevo las evaluaciones al actualizar el modelo. Para el trabajo conversacional del día a día, mira iterar por prompts.
¿Cuándo NO conviene escribir un prompt largo?
Cuando el problema no es de instrucciones. Anthropic aclara que no todo criterio que falla se arregla con prompts: a veces cambiar de modelo mejora la latencia y el costo con menos esfuerzo. Si el modelo no tiene la información necesaria, un prompt más largo solo añade ruido. Si la tarea tiene reglas exactas, como calcular un impuesto, conviene código. Si hay que cambiar el estilo de forma profunda y repetida, compara con fine-tuning vs. prompting. Y si el prompt crece sin control, se vuelve difícil de mantener y encarece cada petición. Revisa también la ventana de contexto para no llenarla sin necesidad.
Ejemplo
Ejemplo ilustrativo: un equipo quiere que un asistente redacte descripciones cortas para tarjetas de producto. El primer prompt dice “escribe una descripción”. Los resultados varían en longitud, algunos incluyen precios y otros usan lenguaje técnico. El segundo prompt define el público, un máximo de 140 caracteres, prohíbe precios y da dos ejemplos aprobados. Después de 20 casos reales, el equipo ve que el tono sigue fallando en productos premium y agrega una línea específica para ese caso. Cada cambio se prueba por separado y el prompt final queda versionado.
Errores comunes
- Escribir instrucciones vagas y culpar al modelo.
- Cambiar varias cosas a la vez y no saber qué funcionó.
- Probar solo con el ejemplo que el equipo tenía en mente.
- Dar ejemplos casi idénticos: Anthropic advierte que el modelo puede aprender patrones que no querías.
- Dictar pasos de razonamiento a un modelo que ya razona por su cuenta.
- Dejar un prompt sin versionar que luego nadie puede reproducir.
- Creer que un prompt perfecto sirve para cualquier modelo. Cada cambio de modelo exige revisar.