Guía anti-gurú para promptear frontier models: razonar, iterar y olvidarse del prompt perfecto

Llevas tiempo escribiendo prompts. Puede que incluso hayas leído algún hilo de Twitter donde alguien prometía "el mega-prompt definitivo para hacer X". Lo copiaste, lo pegaste, y el resultado fue… correcto pero genérico. O directamente inútil.

El problema no era el prompt. Era la idea de que existe un prompt perfecto.

No existe.

Lo que existe es un proceso: una forma de trabajar con el modelo que produce resultados consistentes independientemente de la tarea. Y ese proceso tiene cuatro pasos concretos que puedes empezar a usar hoy. Tanto si usas el chat de Claude, ChatGPT o Gemini como si tienes montado un flujo con Claude Code o Codex: el proceso es el mismo.

El mito del prompt mágico y por qué sigue vivo

La industria del "prompting" lleva años vendiendo la fantasía de la frase exacta que desbloquea al modelo. Cursos de 300 euros, newsletters de pago, hilos virales con "el prompt secreto de ChatGPT que los expertos no quieren que conozcas".

Todo mentira.

La calidad de la respuesta depende directamente de la calidad del prompt, sí, pero no en el sentido de encontrar la frase mágica: depende de si el prompt reduce la ambigüedad y guía al modelo hacia tu intención real. La diferencia es enorme. Un prompt ambiguo no se arregla añadiendo más palabras bonitas; se arregla estructurando la información de forma que el modelo no tenga que adivinar qué quieres.

Y aquí está la trampa en la que cae casi todo el mundo: los frontier models actuales (GPT-5.2, Claude Sonnet 4, Gemini Pro 3.1) son tan buenos completando texto que parecen entenderte aunque no les hayas explicado nada. Te devuelven algo plausible, algo que suena bien, y tú asumes que lo han entendido. No lo han entendido. Han inferido lo más probable dado tu input, que es muy distinto.

El síntoma: produces mucho output con la IA, pero luego tienes que corregir, reescribir o descartar una parte importante. No es que el modelo sea malo. Es que el proceso que usas garantiza malentendidos.

Paso 1: Rol y contexto antes de pedir nada

El modelo sin contexto es un becario sin briefing. Inteligente, con mucha energía, dispuesto a hacer lo que sea. Pero sin saber para qué empresa trabaja, qué problema hay que resolver ni qué formato se espera, va a inventarse el contexto. Y el contexto que inventa es el más genérico posible.

Asignar un rol específico ("eres un senior data analyst que audita archivos de ventas") produce outputs cualitativamente distintos a una instrucción sin rol ("analiza estos datos"). El rol no es decoración; le dice al modelo qué conocimiento debe activar, qué tono debe usar y qué nivel de detalle se espera.

Cómo se hace en la práctica:

Empieza siempre con la instrucción de rol, separada de la tarea.
Incluye el contexto de negocio: para quién trabajas, cuál es el problema, qué restricciones hay.
Después del rol y el contexto, pega los datos o el material.
Al final, la tarea concreta.

Ejemplo malo:

¿Por qué han caído las ventas este mes? [datos adjuntos]

Ejemplo bueno:

Eres un senior data analyst. Trabajas para la empresa XYZ, 
que vende software B2B. Tu función ahora mismo es auditar 
los archivos de ventas de Q2 y verificar los datos clave 
antes de la reunión de dirección.

[datos]

Con esos datos, identifica las tres principales causas 
de la caída de ventas este mes. Sé específico con cifras.

La diferencia no es solo estética. La técnica de System/Role/Context Priming funciona exactamente así: System define el comportamiento general, Role asigna la perspectiva experta, Context proporciona los hechos de fondo. Juntos, alinean el output con lo que realmente necesitas en vez de con lo que el modelo cree que necesitas.

"Cuanto más específico el rol, menos relleno genérico te devuelve el modelo. 'Senior data analyst que audita' es diferente a 'experto en datos'."

Un matiz importante: no mezcles el rol con la tarea en la misma frase. El modelo procesa mejor la información cuando está estructurada. Rol primero. Contexto después. Tarea al final. Este orden no es arbitrario; reduce la ambigüedad que lleva a respuestas vagas.

Esto aplica igual si estás en el chat de Claude.ai o en el de ChatGPT que si tienes un system prompt configurado en un agente. La lógica es la misma; solo cambia dónde pegas cada parte.

Paso 2: Diagnóstico previo a la ejecución

Este es el paso que más diferencia hace y que casi nadie usa.

La idea es simple: antes de que el modelo ejecute la tarea, le pides que te explique cómo ha interpretado la instrucción. Si su interpretación coincide con lo que querías, adelante. Si no coincide, corriges ahí, antes de que produzca 500 palabras en la dirección equivocada.

El prompting es una conversación, no un comando. Empiezas simple, revisas, refinas. El diagnóstico previo formaliza ese proceso y lo hace explícito.

Cómo añadir el diagnóstico a cualquier prompt:

Al final de tu instrucción, añade literalmente esto:

Antes de ejecutar cualquier tarea, dime si has entendido 
bien la instrucción y elabora un diagnóstico de lo que 
vas a hacer: qué asumes, qué datos vas a usar y qué 
formato va a tener el output.

Cuando el modelo responde con el diagnóstico, tienes tres opciones:

Coincide con lo que querías: le dices "adelante" y ejecuta.
Hay una discrepancia menor: la corriges en una línea y luego "adelante".
Ha interpretado algo completamente distinto: corriges la instrucción completa antes de gastar tiempo en un output inútil.

Este paso solo tiene una desventaja: añade un mensaje más al loop. Eso es todo. A cambio, te elimina el ciclo vicioso de "produje output → no era lo que quería → volví a intentarlo → tampoco → frustración → busco el prompt perfecto en Google". Ese ciclo no se arregla con un prompt mejor. Se arregla con un diagnóstico previo.

La técnica conecta directamente con el Chain-of-Thought prompting: al pedirle al modelo que razone antes de ejecutar, llegas a resultados más correctos y explicables. El diagnóstico es, en esencia, Chain-of-Thought aplicado a la comprensión de la instrucción en vez de a la tarea en sí.

Paso 3: Loops de iteración por bloques

El tercer error más común después de "no dar rol" y "no pedir diagnóstico" es lanzar toda la tarea de golpe y esperar que el resultado sea perfecto en una sola pasada.

No funciona así. Los prompts muy complejos y largos pueden restringir la creatividad del modelo y dar resultados no naturales. Paradójicamente, darle más instrucciones de golpe no siempre produce mejores outputs.

La alternativa es el loop por bloques:

Pide una primera versión parcial: "Dame solo el primer bloque del análisis."
Revisa. Ajusta. Dale feedback específico.
"Continúa con el siguiente bloque teniendo en cuenta esta corrección."
Repite hasta tener el resultado completo.

Few-Shot Prompting: útil, pero con trampas

Cuando revisas y corriges cada bloque, estás implícitamente mostrando al modelo qué nivel de detalle y qué formato esperas. Eso es, en esencia, few-shot prompting: darle ejemplos del resultado que quieres para que replique el patrón.

El few-shot funciona especialmente bien cuando necesitas un formato muy específico (fichas de producto, JSONs, informes con campos concretos). Pero tiene dos riesgos que conviene tener claros:

Sesgo de imitación. Algunos modelos, especialmente los más capaces, tienden a copiar los ejemplos con demasiada fidelidad. Si tus ejemplos tienen una estructura muy marcada, el modelo puede replicar esa estructura aunque no encaje con el caso que estás procesando. El resultado: outputs que parecen correctos pero son mecánicos o no se adaptan al matiz de cada input. La solución es revisar que el modelo no está copiando; está aprendiendo el patrón.
Coste en volumen. Cada ejemplo que añades al prompt aumenta su longitud. Si usas few-shot en llamadas a la API y procesas centenares o miles de requests, ese aumento de tokens se acumula de forma significativa en el coste. Para uso en el chat de Claude o ChatGPT no es un problema, pero si escalas a producción, calcula cuántos ejemplos necesitas de verdad frente a cuántos simplemente añaden longitud sin mejorar el output.

Un matiz que el material técnico no resuelve del todo: puedes empezar con un prompt simple (y añadir elementos) o con uno detallado (que reduce pasos pero puede ser más difícil iterar). Ambos enfoques funcionan, pero para tareas complejas y nuevas, empezar simple y añadir capas es casi siempre más eficiente. Para tareas repetitivas donde ya sabes exactamente qué quieres, el prompt detallado desde el inicio te ahorra rondas.

Los loops no son solo para código o análisis de datos. Funcionan igual para copywriting, estrategia, síntesis de documentos o cualquier tarea donde el output final tiene varias partes.

Paso 4: Separa al que genera del que revisa

Este paso es el menos intuitivo y el más potente.

El modelo que generó el output tiene un problema estructural: tiende a defender sus propias decisiones cuando le preguntas si están bien. No por malicia; porque estadísticamente, la continuación más probable de "¿está bien esto que acabo de escribir?" es "sí, está bien". El modelo optimiza para la coherencia del hilo, no para la crítica objetiva.

La solución: usa un segundo modelo, una segunda conversación, o (si trabajas con Claude Code o Codex) un segundo agente con una instrucción de revisor crítico. Pero esto no requiere herramientas de programación: abrir una segunda pestaña del chat de Claude o ChatGPT y pegar el output ahí ya te da el efecto que buscas.

Cómo se hace:

Copia el output del primer modelo.
Abre una segunda conversación (o instancia nueva).
Instrucción: "Eres un revisor crítico. Tu trabajo es encontrar errores, incoherencias, lagunas y afirmaciones sin soporte en este análisis. No seas amable. Sé específico."
Pega el output a revisar.
Usa las observaciones para corregir en el hilo original.

Este patrón encaja con la arquitectura de doble agente que algunos equipos ya usan en producción: uno que genera, uno que destruye. El resultado después de una ronda de crítica real es cualitativamente mejor que tras cinco rondas de "mejora esto un poco más".

La técnica del Step-Back Prompting tiene una lógica similar: antes de atacar la tarea específica, hacer una pregunta más amplia activa conocimiento general del modelo y produce respuestas más fundamentadas. En el caso del revisor, el "paso atrás" es cambiar completamente el encuadre: de "cómo continúo esto" a "qué falla en esto".

Técnicas avanzadas: cuándo y cómo usarlas

Las cuatro técnicas anteriores son el núcleo. Pero hay situaciones donde necesitas herramientas adicionales.

Chain-of-Thought para tareas de diagnóstico o lógica

Cuando el problema es complejo (diagnóstico de causa raíz, análisis de datos con múltiples variables, razonamiento legal o médico), añade explícitamente al prompt: "Pensemos paso a paso." No es magia; es que al escribir el razonamiento intermedio, el modelo llega a resultados más correctos.

Importante: Chain-of-Thought reduce errores en razonamiento lógico, pero no elimina alucinaciones. El modelo puede razonar paso a paso de forma coherente hacia una conclusión incorrecta si el dato de partida es falso. Úsalo como herramienta de transparencia, no como garantía de verdad.

Few-Shot cuando necesitas formato muy específico

Si el output necesita seguir un formato exacto (una ficha de producto, un informe con campos concretos, un JSON), los ejemplos dentro del prompt son más eficaces que cualquier descripción verbal del formato. Muéstrale un ejemplo de lo que quieres y luego pide los siguientes. El modelo replica el patrón.

El riesgo (como se explicó antes) es doble: sesgo de imitación si los ejemplos son demasiado rígidos, y coste adicional por tokens si usas esto en volumen vía API. Antes de añadir ejemplos, asegúrate de que son exactamente lo que quieres replicar y de que el número de ejemplos es el mínimo necesario.

Prompting para generación de video: las reglas cambian

Si trabajas con modelos de texto a vídeo como Runway, la lógica es diferente. Aquí el prompt debe incluir descripciones visuales (qué se ve, cómo luce, iluminación, composición) y descripciones de movimiento (acción del sujeto, movimiento de cámara, timing).

La estructura sugerida:

[Cámara] toma de [sujeto/objeto] [acción] en [entorno]. 
[Descripciones de apoyo: iluminación, estilo, movimiento ambiental].

Para imagen a vídeo, el prompt se centra casi exclusivamente en el movimiento, ya que la imagen de entrada ya define composición y estilo. Esto no aplica directamente a modelos de lenguaje; son dominios distintos con reglas distintas.

Errores comunes que hacen perder el tiempo

Lanzar la tarea sin rol y sin diagnóstico. El modelo ejecuta con su interpretación por defecto. El output parece útil hasta que lo lees con atención y ves que ha respondido a la pregunta que él creyó que hacías, no a la que hacías tú.

Buscar el prompt único y definitivo. Ya lo hemos dicho, pero vale la pena repetirlo porque es el error más caro en tiempo: no existe. Lo que existe es el proceso.

Confundir "más detalle en el prompt" con "mejor prompt". Un prompt de 500 palabras con instrucciones contradictorias produce peores resultados que un prompt de 80 palabras bien estructurado. La longitud no es virtud; la claridad sí.

No separar partes del prompt. Cuando mezclas el rol, la tarea, los datos y las restricciones en un solo bloque de texto, el modelo tiene que inferir qué es qué. Usa delimitadores (líneas en blanco, etiquetas como [DATOS], [INSTRUCCIÓN], [FORMATO]) para que la estructura sea explícita.

Rendirse después de una iteración fallida. El prompting es una conversación. Una primera respuesta mala no significa que el modelo no pueda hacer la tarea; significa que la instrucción necesita un ajuste. El diagnóstico previo hace que ese ajuste ocurra antes de producir el output, no después.

Abusar del few-shot sin pensar en el coste. En el chat no duele. En la API, con volumen, cada ejemplo extra se convierte en tokens extra multiplicados por miles de llamadas. Revisa si de verdad necesitas tres ejemplos o con uno es suficiente.

Preguntas frecuentes

¿Qué es el Chain-of-Thought prompting y para qué sirve?

Chain-of-Thought (CoT) es la técnica de pedir al modelo que razone paso a paso antes de dar una respuesta final. Se activa añadiendo "pensemos paso a paso" o incluyendo ejemplos con razonamiento explícito. Mejora los resultados en tareas lógicas, diagnósticos y análisis de causa raíz. No elimina alucinaciones, pero hace el razonamiento transparente y más fácil de corregir.

¿Cuál es la diferencia entre zero-shot y few-shot prompting?

Zero-shot es dar una instrucción sin ejemplos; el modelo usa solo su conocimiento previo. Funciona bien para tareas simples como resúmenes o traducciones. Few-shot incluye uno o varios ejemplos del resultado que quieres; el modelo aprende el patrón y lo replica. Few-shot es más eficaz cuando necesitas un formato específico, pero añade longitud al prompt (lo que puede encarecer el coste si usas la API en volumen) y en algunos modelos genera sesgo de imitación si los ejemplos son demasiado rígidos.

¿Cómo se estructura un buen prompt para tareas complejas?

Un prompt efectivo para tareas complejas incluye cuatro elementos: (1) rol o perspectiva del modelo ("eres un senior data analyst"), (2) contexto de negocio relevante, (3) los datos o material a trabajar, y (4) la tarea concreta con el formato de salida esperado. Al final, añade la instrucción de diagnóstico previo para que el modelo confirme su interpretación antes de ejecutar. Funciona igual en el chat de Claude o ChatGPT que en un system prompt de un agente.

¿El prompting de texto funciona igual para generar vídeo con IA?

No. Para modelos de texto a vídeo como Runway, el prompt debe incluir descripciones visuales (sujeto, entorno, iluminación, composición) y descripciones de movimiento (acción, movimiento de cámara, timing). Para imagen a vídeo, el prompt se centra casi exclusivamente en el movimiento, ya que la imagen define el resto. Las reglas del prompting de lenguaje no se trasladan directamente a generación de vídeo.