7 técnicas para escribir prompts eficaces
No hay un prompt perfecto ni una fórmula mágica que funcione igual en cualquier modelo o tarea. Lo que sí existe son técnicas de prompt eficaces en las que coinciden las guías oficiales de OpenAI, Anthropic, Google y Microsoft: siete principios prácticos para conseguir mejores respuestas, ya sea que escribas el prompt a mano en un chat o que lo construyas dentro de una aplicación.
1. Define el objetivo con precisión
Indica exactamente qué debe hacer el modelo, para quién y con qué finalidad. Verbos como "mejora", "analiza" o "hazlo profesional" no dicen nada si no explicas qué significan en tu caso concreto.
Prompt débil: Analiza estas ventas. Prompt mejorado: Analiza las ventas del último trimestre para detectar los tres productos con mayor caída, identificar posibles causas y proponer tres acciones comerciales priorizadas por impacto y coste.
La guía de prompt engineering de OpenAI insiste en describir con detalle la tarea, el resultado esperado, la longitud, el formato y el estilo. La de Anthropic sitúa la claridad y la definición explícita de la tarea como principio de partida, antes que cualquier técnica más avanzada.
2. Da contexto relevante y fiable
Un modelo responde mejor cuando recibe la información que necesita para resolver el problema, sobre todo si se trata de datos privados, políticas internas, documentación técnica o información reciente que el modelo no puede conocer por sí mismo.
Conviene incluir: los datos de entrada, el público objetivo, el sector o contexto de la empresa, definiciones específicas, restricciones legales o de negocio, la documentación de referencia y la fecha de esa información.
En una aplicación empresarial, no le pidas al modelo que recuerde tus políticas internas: dáselas como documento, mediante una base documental o RAG, y exígele que se limite a ese material.
Usa únicamente la política de devoluciones incluida entre las etiquetas <politica>. Si la política no responde a la pregunta, indica: "No consta en la documentación proporcionada". No inventes excepciones ni plazos. <politica> [pegar aquí la política vigente] </politica>
3. Estructura el prompt con bloques y delimitadores
Separa las instrucciones, el contexto, los ejemplos y el formato de salida en secciones claras. Los encabezados en Markdown, las etiquetas XML y delimitadores como las triples comillas o --- reducen la confusión entre lo que es instrucción y lo que es dato.
Una estructura que funciona bien en contextos empresariales:
## Rol Eres [tipo de especialista] con experiencia en [dominio]. ## Objetivo Debes [resultado concreto] para [audiencia o proceso]. ## Contexto [datos, documentos, definiciones y fecha de la información] ## Tarea 1. [acción concreta] 2. [acción concreta] 3. [acción concreta] ## Restricciones - Usa únicamente [fuentes o datos autorizados]. - No inventes información. - Si falta un dato, indica [comportamiento esperado]. - Respeta [límites legales, técnicos o comerciales]. ## Formato de salida Devuelve [formato], con [campos obligatorios] y un máximo de [longitud].
4. Incluye ejemplos del resultado que esperas
Los ejemplos, lo que se conoce como few-shot prompting, le muestran al modelo cómo interpretar los casos y cómo tiene que producir la respuesta. Son especialmente útiles para clasificación, extracción de datos, tono de marca y formatos estructurados.
Un buen ejemplo es representativo del caso real, correcto, corto, distinto de los demás ejemplos que le acompañan y compatible con el formato final que quieres obtener.
Clasifica cada incidencia como CRÍTICA, ALTA, MEDIA o BAJA.
Ejemplo:
Entrada: "La aplicación no permite iniciar sesión a ningún cliente."
Salida: {"nivel":"CRÍTICA","motivo":"Afecta a todos los usuarios"}
Ejemplo:
Entrada: "Un usuario ve un botón ligeramente desplazado."
Salida: {"nivel":"BAJA","motivo":"No impide utilizar la aplicación"}
Ahora clasifica:
Entrada: "[nueva incidencia]"
5. Especifica restricciones y un formato verificable
Pedir "una buena respuesta" no basta. Define qué debe incluir, qué tiene que evitar y cómo debe presentarse: formato (Markdown, JSON, tabla, CSV, XML o texto), extensión máxima, número de elementos, idioma, tono, audiencia, campos obligatorios, criterios de aceptación y qué hacer cuando falte un dato.
Para integraciones de software, un JSON validado contra un esquema suele ser más fiable que dejar la respuesta libre.
Devuelve únicamente JSON válido con esta estructura:
{
"prioridad": "alta|media|baja",
"resumen": "string",
"acciones": [
{
"descripcion": "string",
"responsable": "string",
"plazo_dias": 0
}
]
}
No incluyas Markdown ni texto fuera del JSON.
Si faltan datos, utiliza null y explica la ausencia en "resumen".
6. Divide las tareas complejas en fases
Un prompt que intenta investigar, razonar, comparar, calcular y redactar todo a la vez suele ser más difícil de controlar. Dividir el proceso en subtareas concretas, y validar cada una antes de pasar a la siguiente, da resultados más predecibles.
En vez de: Investiga el mercado, analiza a los competidores, prepara una estrategia y redacta el informe. Usa una cadena de tareas: Fase 1: Extrae los datos relevantes de los documentos. Fase 2: Compara los competidores usando únicamente los datos extraídos. Fase 3: Identifica oportunidades y riesgos. Fase 4: Redacta una recomendación ejecutiva de 500 palabras.
En un producto de software, esto además permite validar cada etapa por separado, registrar dónde falla y repetir solo la fase que no funcionó, en lugar de relanzar todo el proceso.
7. Itera, prueba y evalúa el prompt
Un prompt que funciona de verdad se trata como una pieza de software: se prueba con casos reales, se comparan versiones entre sí y se vigila su comportamiento cuando cambia el modelo que hay detrás.
El ciclo que recomiendan las guías del sector: escribir una primera versión, probarla con 20 o 50 casos reales, registrar los errores y las respuestas indeseadas, ajustar una sola variable cada vez, comparar la nueva versión con la anterior, conservar los casos difíciles como referencia y publicar el cambio solo si mejora las métricas que hayas definido de antemano.
Esas métricas suelen incluir exactitud, cumplimiento del formato pedido, tasa de respuestas inventadas, coste por solicitud, latencia, necesidad de intervención humana y satisfacción de quien lo usa.
La fórmula que reúne las siete técnicas
Para la mayoría de tareas empresariales, esta estructura combina los siete principios en una sola plantilla:
## Rol Eres [tipo de especialista] con experiencia en [dominio]. ## Objetivo Debes [resultado concreto] para [audiencia o proceso]. ## Contexto [datos, documentos, definiciones y fecha de la información] ## Tarea 1. [acción concreta] 2. [acción concreta] 3. [acción concreta] ## Restricciones - Usa únicamente [fuentes o datos autorizados]. - No inventes información. - Si falta un dato, indica [comportamiento esperado]. - Respeta [límites legales, técnicos o comerciales]. ## Ejemplo Entrada: [caso de ejemplo] Salida esperada: [respuesta de ejemplo] ## Formato de salida Devuelve [formato], con [campos obligatorios] y un máximo de [longitud].
Ejemplo completo aplicado a una decisión de producto
## Rol Eres un consultor senior de producto especializado en software SaaS B2B. ## Objetivo Evaluar si una nueva función debe incluirse en la próxima versión del producto. ## Contexto La función permite exportar informes en PDF. Clientes objetivo: despachos profesionales de entre 10 y 50 empleados. Datos disponibles: - 42 solicitudes de clientes en seis meses. - Coste estimado de desarrollo: 80 horas. - Uso esperado: 35 % de las cuentas activas. - No existe información sobre el impacto en la retención. ## Tarea 1. Evalúa la demanda. 2. Calcula el esfuerzo relativo. 3. Identifica los datos que faltan. 4. Recomienda incluir, posponer o descartar la función. 5. Explica los principales riesgos. ## Restricciones - No inventes métricas de ingresos, retención o conversión. - Diferencia claramente entre datos observados y estimaciones. - Si una conclusión depende de información ausente, dilo expresamente. ## Formato de salida Devuelve: 1. Una recomendación de una frase. 2. Una tabla con demanda, esfuerzo, impacto y nivel de confianza. 3. Tres riesgos. 4. Tres acciones siguientes. Máximo: 600 palabras.
Fíjate en el detalle que sostiene todo el ejemplo: se le dice al modelo qué datos no tiene, y se le prohíbe expresamente rellenar ese hueco por su cuenta. Esa línea es, en la práctica, la diferencia entre un informe útil y uno que suena bien pero mezcla datos reales con cifras inventadas sin avisar.
Qué conviene evitar
Prompts vagos como "hazlo perfecto", que no le dan al modelo ningún criterio contra el que medirse. Introducciones largas que no aportan información antes de la instrucción real. Instrucciones que se contradicen entre sí dentro del mismo prompt. Mezclar datos no fiables con instrucciones sin delimitarlos con claridad, de forma que el modelo no sepa distinguir una orden de un dato de entrada. Pedirle al modelo que invente una respuesta cuando no conoce el dato, en lugar de dejarle decir que no lo sabe. Exigir un razonamiento interno detallado paso a paso, cuando suele ser más útil pedir conclusiones, comprobaciones y criterios verificables. Decidir que un prompt funciona a partir de un único caso de prueba. Y cambiar el prompt y el modelo a la vez, sin forma de saber cuál de los dos causó la mejora o el empeoramiento.
Trata el prompt como código
En producción, la calidad de un sistema con IA depende tanto del prompt como del modelo, la recuperación de contexto, las herramientas conectadas, los controles de seguridad y las evaluaciones que lo acompañan. Por eso conviene mantener el prompt estructurado, versionado, probado y, cuando sea posible, validado contra un esquema, igual que se trataría cualquier otra pieza de código que forma parte de un producto.
Fuentes
- OpenAI, guía de prompt engineering
- OpenAI, buenas prácticas de seguridad en prompts
- OpenAI Help Center, buenas prácticas de prompt engineering para ChatGPT
- Anthropic, resumen de prompt engineering
- Anthropic, ingeniería de contexto eficaz para agentes de IA
- Anthropic, prompt engineering para el rendimiento del negocio
- Google for Developers, diseño de prompts
- Microsoft Learn, técnicas de prompt engineering (Azure AI Foundry)
- Microsoft Learn, pautas de prompt engineering para soluciones empresariales
Escribir un buen prompt suelto es un primer paso. Conectarlo a tus datos reales, con las restricciones y las evaluaciones que necesita un sistema en producción, es otro trabajo. En IA2Net ayudamos con las dos partes: conoce nuestro servicio de inteligencia artificial o revisa el glosario de inteligencia artificial si algún término de este artículo no te suena.
Preguntas frecuentes
¿Sirve el mismo prompt para ChatGPT, Claude y Gemini?
La estructura general (objetivo, contexto, restricciones, formato) funciona en cualquiera de los tres. Lo que cambia es el nivel de detalle: los modelos de razonamiento suelen rendir mejor con instrucciones de alto nivel, mientras que otros modelos necesitan instrucciones más precisas y explícitas. Conviene probar el mismo prompt en el modelo real que vas a usar en producción, no dar por hecho que se comporta igual en todos.
¿Qué es el few-shot prompting?
Es la técnica de incluir varios ejemplos de entrada y salida dentro del propio prompt para que el modelo aprenda el patrón por imitación, en lugar de solo por descripción. Es especialmente útil cuando necesitas un formato de salida exacto o un criterio de clasificación que es difícil de explicar solo con palabras.
¿Cuántos ejemplos debo incluir en un prompt?
No hay un número fijo. Con dos o tres ejemplos bien elegidos y diversos entre sí suele bastar para tareas de clasificación o extracción. Más ejemplos no siempre mejoran el resultado: si son parecidos entre ellos o poco representativos, solo consumen espacio sin añadir información nueva.
¿Cómo evito que la IA invente datos que no tiene?
Dile expresamente qué hacer cuando falte información: por ejemplo, que responda "No consta en la documentación proporcionada" en lugar de completar el hueco por su cuenta. Combinado con darle solo las fuentes autorizadas como contexto, es la medida más efectiva contra las respuestas inventadas.
¿Necesito saber programar para aplicar estas técnicas?
No. Las siete técnicas funcionan igual de bien en un chat como ChatGPT o Claude que dentro de una aplicación conectada por API. Lo único que cambia es que, en una aplicación, además conviene validar la salida contra un formato o esquema de forma automática.
¿Cómo sé si un prompt "funciona bien" de verdad?
Probándolo contra un conjunto de casos reales, no contra uno solo, y midiendo algo concreto: exactitud, si respeta el formato pedido, cuántas veces inventa datos, o cuántas veces necesita que una persona corrija el resultado. Sin esa medición, cualquier cambio en el prompt es una impresión, no una mejora comprobada.