Prompt engineering en español no es magia: es especificar el trabajo para que un modelo produzca algo usable. La mayoría de los prompts malos no fallan por falta de trucos. Fallan porque el encargo cabe en una línea y el trabajo real necesita una página de contexto.
Plantilla de brief
Esta plantilla cubre lo mínimo para una tarea de trabajo:
Rol: [experto en X]
Tarea: [verbo + entregable]
Contexto: [datos, restricciones]
Formato: [tabla / bullets / JSON]
Criterios: [qué es un buen resultado]
No hagas: [alucinar cifras, tono X]
Cada línea evita una adivinanza. El rol ajusta vocabulario y nivel. La tarea con verbo y entregable impide respuestas decorativas. El contexto pone los datos y los límites reales. El formato decide si la salida se usa o se reescribe. Los criterios definen cuándo está listo. La línea de "no hagas" prohíbe los dos fallos más caros: inventar cifras y adoptar el tono equivocado.
Por qué tu brief actual falla
Tres causas se repiten. Primera, tarea sin entregable: "ayúdame con el reporte" no dice qué debe salir. "Redacta el resumen ejecutivo de 200 palabras con tres riesgos" sí. Segunda, contexto ausente: el modelo no sabe para quién escribes ni con qué datos cuentas, así que escribe para nadie con datos inventados. Tercera, sin criterio de aceptación: si no definiste qué es bueno, cada salida parece aceptable y ninguna sirve.
Antes de culpar al modelo, revisa tu brief contra esas tres. Ocho de cada diez prompts que "no funcionan" se arreglan agregando entregable, contexto y criterios.
Ejercicio de 20 minutos
- Elige una tarea real de tu trabajo.
- Escribe el brief con la plantilla.
- Genera 2 salidas con modelos distintos.
- Puntúa claridad, exactitud y acción con una rúbrica de 1 a 3 por criterio.
- Guarda la versión ganadora en tu biblioteca.
La rúbrica es lo que convierte opinar en medir. Claridad: ¿se entiende a la primera? Exactitud: ¿todo dato es verificable? Acción: ¿puedes usar la salida en el siguiente paso sin reescribirla? Nueve puntos posibles; un brief que saca menos de seis necesita trabajo, no otro modelo.
Compara con la misma muestra en ambos modelos y anota fecha y versión. Los modelos cambian; tu registro te dice si el ganador de hoy sigue ganando en un mes.
Versiona como parte del trabajo
Cuando un prompt se usa cada semana, trátalo como documento vivo: nombre, versión, fecha, para qué tarea sirve y dos ejemplos de salida esperada. Guarda cada cambio con una línea de motivo. Ese hábito, prestado del software, evita el problema clásico del equipo donde cada persona tiene su propia versión del mismo prompt y nadie sabe cuál rinde.
La biblioteca de prompts sirve para practicar con material real. Y cuando el flujo se repite cada semana, el paso siguiente es convertirlo en sistema, como explica prompts gratis vs sistema de prompts.
Cuándo el problema no es el prompt
Hay tres casos donde ningún brief ayuda. Si faltan los datos, consigue los datos primero. Si la tarea está mal definida ("mejorar las ventas" sin más), define la tarea con un humano antes de pedir nada. Si el modelo no tiene la capacidad (razonamiento largo, contexto enorme, herramienta específica), cambia de modelo o de enfoque. Insistir con mejores prompts en esos casos es pulir la herramienta equivocada.
Para decisiones sensibles, la revisión de una persona calificada sigue siendo obligatoria. Un brief excelente produce borradores excelentes; la responsabilidad de publicarlos es humana.
Próximo paso
Explora /prompts y los cursos de prompt engineering en Aulas de IA (precios). Elige una tarea real, escribe el brief, evalúa con tres ejemplos y guarda el ganador. Repite con la siguiente tarea. En un mes tendrás una biblioteca pequeña que rinde todos los días.