Un buen prompt no depende de la suerte ni de palabras mágicas: requiere método. La mayoría de los malos resultados se deben a instrucciones poco cuidadas, no al modelo.
Sé específico y proporciona contexto
El modelo no adivina lo que tienes en mente. "Escribe sobre marketing" produce algo genérico porque la solicitud es genérica. Indica quién lo va a leer, con qué objetivo, en qué tono y con qué restricciones. Compara "resume este texto" con "resúmelo en 3 viñetas para un gerente sin tiempo, con foco en las decisiones y sin jerga": la segunda opción entrega algo útil porque hiciste el trabajo de pensar antes de pedirlo. El contexto vale más que el esmero en la redacción: incluye el material relevante, di qué se ha intentado ya y señala lo que no quieres.
Muestra ejemplos (few-shot)
Describir el resultado deseado ayuda; mostrar un ejemplo ayuda más. Si quieres clasificar tickets como "urgente / normal / spam", proporciona dos o tres casos ya etiquetados antes de enviar el caso real. El modelo capta el patrón —formato, nivel de detalle y criterio— mucho mejor a partir de ejemplos que de adjetivos. Uno o dos ejemplos bien elegidos suelen valer más que un párrafo de instrucciones. Solo asegúrate de que sean representativos: si todos son fáciles, el modelo tropezará con los casos límite.
Pide un formato
Si vas a consumir la respuesta desde código, pegarla en una hoja de cálculo o revisarla rápidamente, indica el formato de manera explícita: JSON con estas claves, una tabla con estas columnas, una lista numerada o como máximo X palabras. Sin esa indicación, cada iteración tendrá un formato diferente y perderás tiempo limpiándolo. Un "responde solo con el JSON, sin texto alrededor" evita ese "¡Claro! Aquí está:" que rompe tu parser. Especificar el formato también es la manera más barata de hacer que la salida sea comprobable.
Divide las tareas difíciles en partes
Pedir "analiza este contrato, encuentra los riesgos, reescribe las cláusulas y genera un resumen ejecutivo" en un solo prompt suele producir una mezcla tibia de todo. Sepáralo: primero extrae las cláusulas, después evalúa el riesgo de cada una y, por último, reescríbelas. Cada paso será más fácil de verificar y corregir. Para tareas de razonamiento, pedir que "piense paso a paso" antes de responder puede ayudar en problemas de lógica; no por arte de magia, sino porque obliga al modelo a no saltar directamente a una respuesta apresurada. Las tareas grandes y vagas son el lugar donde los errores se esconden.
Itera y evalúa
El primer prompt rara vez es el mejor. Trátalo como código: ejecútalo, observa dónde falló, cambia una cosa y vuelve a ejecutarlo. El error común es cambiar cinco cosas a la vez y no saber qué funcionó. Si usas el mismo prompt con frecuencia, crea un conjunto de casos de prueba —entradas con la respuesta esperada— y pásale el prompt cada vez que lo modifiques. Preguntarte "¿quedó mejor?" a simple vista no escala; unos cuantos ejemplos con una respuesta de referencia sí.
Conoce los límites
El modelo inventa cosas con confianza. Completa las lagunas con lo que parece plausible: nombres, números, citas y APIs que no existen. Pedirle amablemente que no alucine no lo resuelve. Lo que sí ayuda es proporcionar la fuente en el propio prompt (grounding), pedirle que avise cuando no sepa algo y verificar todo lo factual o sensible antes de usarlo. La fecha de corte, el sesgo de los datos de entrenamiento y la falta de acceso a tu contexto privado son limitaciones reales, no una cuestión de opinión. Úsalo como a un becario rápido e incansable: excelente para hacer borradores, pero mala idea dejarlo firmar sin revisar.
Al final, la ingeniería de prompts tiene menos de truco y más de claridad: cuanto mejor defines el problema, menos tiene que adivinar el modelo. La herramienta es buena; simplemente no delegues el pensamiento.
