El prompting preciso es especificación del contexto
20 de junio de 2026 · 10 min de lectura
Resumen
Existe una checklist conocida para empezar con prompting: definir la tarea, la audiencia, el tono, el rol, el contexto, las restricciones, los ejemplos y el formato de salida. Es útil. Pero no basta.
Mi hipótesis es que el prompting preciso se parece cada vez menos a completar una checklist universal y cada vez más a elegir los detalles que realmente importan para un modelo, una tarea, un flujo de trabajo, un nivel de riesgo y un método de evaluación concretos. Dicho de otra forma: la precisión de un prompt no es su longitud. Es su ajuste.
Este artículo revisa guías prácticas de OpenAI, Anthropic y Microsoft, además de trabajos académicos sobre taxonomías de prompting, prompt patterns, optimización automática de prompts, tareas de ingeniería de software y context engineering. Las fuentes apuntan en la misma dirección: los detalles útiles en un prompt cambian mucho según el contexto. Un prompt para extraer JSON estructurado necesita elementos diferentes de un prompt para síntesis legal, generación frontend, tutoría, uso de herramientas por agentes o reparación de código.
La tesis sigue siendo una hipótesis de trabajo. Pero ya es práctica.
El problema de la checklist de prompts
La mayoría de las personas que han usado LLMs durante más de unas semanas conocen el consejo básico.
Dile al modelo qué quieres. Dale un rol. Define la audiencia. Especifica el tono. Añade ejemplos. Indica el formato de salida. Tal vez añade restricciones.
No está mal. Es un buen punto de partida. Pero cuando empecé a usar LLMs para crear prompts más detallados, noté algo un poco molesto y bastante interesante: la lista de detalles útiles cambiaba constantemente.
Para una revisión de literatura, los detalles decisivos eran la jerarquía de fuentes, el estilo de citación, el lenguaje de incertidumbre y la separación entre evidencia e interpretación.
Para una tarea frontend, los detalles decisivos eran el comportamiento responsive, el design system existente, los estados de interacción, la accesibilidad y los activos visuales.
Para un flujo agentic, los detalles decisivos eran los permisos de herramientas, los límites de aprobación, los criterios de parada, los pasos de verificación y el estado que debía conservarse.
La misma palabra: "prompt". Un objeto de ingeniería muy distinto.
Así que el problema no es si un prompt debe tener "más detalle". Esa pregunta es demasiado burda. La mejor pregunta es:
¿Qué detalles son operativamente relevantes para esta tarea?
Llamaría operativo a un detalle cuando añadirlo cambia la probabilidad de que el modelo produzca un resultado aceptable.
Suena un poco formal, pero importa. Un prompt largo puede seguir siendo vago. Un prompt corto puede ser preciso. La diferencia está en si el prompt nombra las variables que realmente guían al modelo.
Cómo miré las fuentes
Esta es una revisión narrativa, no un benchmark. Busqué fuentes que cubrieran cinco ángulos:
| Tipo de fuente | Ejemplos | Por qué importa |
|---|---|---|
| Documentación de proveedores | OpenAI, Anthropic, Microsoft | Muestra cómo el consejo cambia por modelo, flujo y tipo de salida |
| Taxonomías de prompting | The Prompt Report y surveys relacionados | Muestra el prompting como un espacio de diseño amplio |
| Prompt patterns | White et al. | Trata los prompts como patrones reutilizables pero adaptables |
| Optimización y estudios empíricos | APE, estudios sobre prompts de código | Muestra que los detalles se pueden descubrir, probar y mejorar |
| Context engineering | Surveys recientes | Cambia el foco de la redacción al paquete completo de contexto |
El objetivo no era demostrar que todo prompt deba ser complejo. Al contrario. La afirmación útil es más estrecha: los detalles correctos dependen del trabajo que el prompt debe realizar.
Lo que ya sugieren las guías de proveedores
La documentación actual de OpenAI sobre prompt engineering y generación de prompts muestra bien las dos caras del asunto. Hay consejos generales, pero la guía se vuelve pronto específica por tipo de salida. La guía de generación de prompts trata el tipo de output, los esquemas, los ejemplos, el orden entre razonamiento y conclusión, las constantes y la complejidad de la tarea como variables que se deben inspeccionar, no como una plantilla fija [1][2].
Anthropic es aún más explícita al empezar por criterios de éxito. Su overview de prompt engineering dice que antes de mejorar un prompt deberías tener una definición clara de éxito, alguna forma de probarla y un primer borrador de prompt [3]. Es importante. Presenta el prompting como iteración hacia un objetivo, no como una frase mágica.
Las buenas prácticas de Anthropic separan después muchas situaciones: ejemplos, estructura XML, roles, contexto largo, formato de salida, uso de herramientas, thinking, sistemas agentic, frontend, migración entre versiones de modelos y más [4]. Eso se parece menos a "esta es la fórmula" y más a "cada flujo expone controles distintos".
La documentación de Microsoft Azure OpenAI añade una advertencia útil: construir prompts es más arte que ciencia, y los modelos se comportan de forma diferente [5]. No lo tomaría como excusa para prompts descuidados. Lo tomaría como una razón para probarlos.
| Señal | Qué sugiere |
|---|---|
| OpenAI separa tarea, salida, esquema y ejemplos | Los detalles deben elegirse según el output esperado |
| Anthropic parte de criterios de éxito y pruebas | Un prompt es una hipótesis sobre lo que el modelo necesita |
| Anthropic separa contexto largo, herramientas, agentes y frontend | El "buen prompting" depende del flujo |
| Microsoft recuerda que los modelos difieren | La precisión también depende del modelo |
La literatura hace visible el espacio de diseño
El apoyo académico más fuerte viene de la amplitud del propio campo.
The Prompt Report cataloga 58 técnicas de prompting para LLMs y 40 técnicas para otras modalidades [6]. Eso no es una hoja de trucos para principiantes. Es señal de que "prompting" cubre problemas muy distintos.
El catálogo de prompt patterns de White et al. es útil por otra razón [7]. Trata los prompts como patrones de software: soluciones reutilizables para problemas recurrentes en un contexto particular. Esa última parte es clave. Un patrón es reutilizable, pero no es independiente del contexto.
Automatic Prompt Engineer va un paso más allá. Zhou et al. tratan las instrucciones como candidatas que pueden generarse, puntuarse y seleccionarse contra el rendimiento de la tarea [8]. Es un modelo mental distinto de "escribir un buen prompt". La calidad depende de la tarea, la función de puntuación y el espacio de búsqueda.
El estudio de Shin et al. sobre ingeniería de software encaja también. Compara prompting básico, in-context learning y prompting específico de tarea para generación, resumen y traducción de código. El prompt engineering no supera al fine-tuning en todos los casos, y el prompting conversacional mejora cuando las personas añaden contexto, feedback e instrucciones específicas [9].
Eso coincide con la experiencia diaria. Descubres lo que falta en el prompt mirando cómo falla el modelo.
Los detalles cambian con la tarea
La versión práctica del argumento es esta:
| Contexto de tarea | Detalles que suelen importar |
|---|---|
| Síntesis de documentos largos | Jerarquía de fuentes, reglas de citas, metadatos, conflictos, política de citación |
| Generación de código | Convenciones del repo, archivos objetivo, tests, arquitectura, dependencias, seguridad |
| Frontend | Design system, responsive, estados de interacción, accesibilidad, activos visuales |
| Análisis legal o policy | Jurisdicción, fecha, autoridad de la fuente, incertidumbre, calidad de fuentes, escalación |
| Extracción estructurada | Esquema, valores permitidos, tratamiento de null, validación, casos límite |
| Tutoría | Nivel del aprendiz, malentendidos, ritmo, feedback, cuándo hacer preguntas |
| Agentes con herramientas | Permisos, aprobaciones, criterios de parada, verificaciones, auditoría |
| Trabajo creativo | Género, audiencia, voz, ejemplos negativos, restricciones, criterios de novedad |
Una checklist genérica diría: "añade contexto". Bien. Pero en un repositorio de código, contexto puede significar arquitectura local y comando de tests. En una síntesis legal, puede significar jurisdicción y fecha de la norma. En una extracción, puede significar esquema y reglas para campos ausentes.
La palabra es la misma. El arreglo de detalles no.
Precisión no significa verbosidad
Aquí muchas conversaciones sobre prompting se tuercen.
La gente oye "sé preciso" y lo traduce como "añade más instrucciones". A veces funciona. A menudo solo crea un prompt más largo con más puntos donde las instrucciones pueden chocar.
Una mejor definición sería:
El prompting preciso es la selección de contexto, restricciones, ejemplos y criterios de evaluación relevantes para la tarea que afectan materialmente al comportamiento del modelo.
Así se separa precisión de longitud.
Un prompt que dice "escribe con tono profesional para una audiencia general" no es preciso si el problema real es la fidelidad de las citas. Un prompt que dice "extrae claims en JSON con claim, source_quote, confidence y needs_verification; usa null cuando la fuente no dice nada" puede ser preciso aunque sea corto.
Uno suena pulido. El otro cambia el comportamiento.
Context engineering como marco más amplio
La literatura reciente de context engineering formula el mismo punto a mayor escala. Mei et al. describen context engineering como la optimización del paquete de información dado a un LLM, incluyendo retrieval, procesamiento de contexto, memoria, herramientas, RAG, razonamiento con herramientas y sistemas multiagente [10].
El término puede volverse borroso si se pone de moda. Pero la idea central es útil: el prompt visible del usuario es solo una parte de la ventana de contexto.
En una aplicación LLM seria, el modelo puede recibir también:
- instrucciones de sistema
- instrucciones de developer
- documentos recuperados
- memoria
- definiciones de herramientas
- reglas de política
- preferencias del usuario
- ejemplos
- esquemas
- salidas anteriores
- rúbricas de evaluación
Visto así, la vieja checklist se queda pequeña. El trabajo no es solo redactar la petición. Es montar el entorno de información en el que el modelo puede hacer la tarea.
Un pequeño modelo para el prompting preciso
Las fuentes sugieren un modelo de trabajo sencillo. No lo llamaría teoría todavía. Más bien un andamio práctico.
| Capa | Pregunta | Ejemplo |
|---|---|---|
| Alineación con la tarea | ¿Qué hace correcta o útil la salida? | Citar fuentes primarias |
| Alineación con el modelo | ¿Qué necesita este modelo? | Pedir explícitamente detalles frontend |
| Alineación con el flujo | ¿Qué herramientas, archivos o estado intervienen? | Leer archivos, pedir permiso antes de escribir |
| Alineación con el riesgo | ¿Qué puede salir mal si actúa con exceso de confianza? | Marcar incertidumbre legal |
| Alineación con la evaluación | ¿Cómo se comprobará el éxito? | JSON válido, tests pasan, citas verificadas |
Esto también explica por qué los LLMs ayudan a escribir prompts. Cuando pido a un LLM que mejore un prompt, a menudo saca categorías que yo había olvidado: casos límite, rúbricas, política de fuentes, ejemplos negativos, modos de fallo, permisos de herramientas.
Pero esas sugerencias no son automáticamente correctas. Son detalles candidatos. Hay que probarlos.
Qué significa en la práctica
Si mantienes una biblioteca de prompts, no guardes solo el prompt final. Guarda el tipo de tarea, el modelo, los criterios de éxito, los fallos conocidos y la razón por la que ciertos detalles se incluyeron.
Si pides a un LLM que mejore un prompt, no pidas solo "un prompt mejor". Pídele que identifique qué categorías de detalle probablemente afecten al resultado.
Si un prompt falla, no lo hagas más largo de inmediato. Pregunta qué tipo de contexto faltaba.
Algunos prompts necesitan ejemplos. Algunos un esquema. Algunos una jerarquía de fuentes. Algunos una política de herramientas. Algunos una definición de éxito más fuerte. Algunos necesitan menos instrucción, porque el modelo se aferra demasiado a tus restricciones.
Esta es la parte incómoda: buen prompting no es una sola habilidad. Es una familia de pequeñas habilidades diagnósticas.
Limitaciones
Este artículo es especulativo en el buen sentido: parte de una observación práctica y comprueba si la literatura apunta en la misma dirección. Lo hace, pero no es un experimento controlado.
El siguiente paso útil sería operacionalizar los "detalles" y probarlos por familias de tareas. ¿Una política de citación mejora una revisión de literatura más que una guía de tono? ¿El detalle del esquema importa más que los ejemplos en extracción? ¿Qué detalles se transfieren entre familias de modelos?
Sería un buen benchmark. También sería desordenado, porque los prompts reales están llenos de detalles que interactúan.
Conclusión
La literatura apoya la hipótesis: el prompting se mueve de la checklist universal hacia la especificación contextual.
La checklist inicial sigue siendo útil. Tarea, audiencia, tono, ejemplos y formato son buenos defaults. Pero el prompting avanzado empieza cuando dejamos de preguntar "¿qué necesita todo prompt?" y empezamos a preguntar "¿qué debe saber, restringir, usar, evitar y demostrar el modelo para esta tarea?"
Ese es el cambio.
El prompting preciso no consiste en añadir detalles en todas partes. Consiste en encontrar los detalles que cambian el resultado.
Referencias
[1] OpenAI, Prompt engineering, OpenAI API documentation.
[2] OpenAI, Prompt generation, OpenAI API documentation.
[3] Anthropic, Prompt engineering overview, Claude API documentation.
[4] Anthropic, Prompting best practices, Claude API documentation.
[5] Microsoft, Prompt engineering techniques, Microsoft Learn.
[6] S. Schulhoff et al., The Prompt Report: A Systematic Survey of Prompting Techniques, arXiv:2406.06608, 2024.
[7] J. White et al., A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, arXiv:2302.11382, 2023.
[8] Y. Zhou et al., Large Language Models Are Human-Level Prompt Engineers, arXiv:2211.01910, 2022.
[9] J. Shin et al., Prompt Engineering or Fine Tuning: An Empirical Assessment of Large Language Models in Automated Software Engineering Tasks, arXiv:2310.10508, 2023.
[10] L. Mei et al., A Survey of Context Engineering for Large Language Models, arXiv:2507.13334, 2025.