--- title: La anatomía de un prompt: las partes que de verdad importan description: Aprende los componentes esenciales de los prompts eficaces para IA y cómo estructurarlos para obtener mejores resultados. Desglose práctico de lo que funciona. date: February 5, 2026 author: Robert Soares category: prompt-engineering --- La mayoría de los prompts fallan porque dejan a la IA adivinando. No porque sean demasiado cortos. Sino porque no dejan claro qué quieres de verdad. Y cuando una IA adivina, se va a lo genérico. Como lo dijo un [comentarista de Hacker News](https://news.ycombinator.com/item?id=41395921): "prompt engineering is probably very close to good management and communication principles." Ese enfoque sirve. No estás programando. Estás comunicándote con algo que no puede hacer preguntas de seguimiento. Entonces, ¿cómo se ve un prompt completo? Debajo de los buenos hay una estructura. ## Los bloques de construcción La documentación de [Learn Prompting](https://learnprompting.org/docs/basics/prompt_structure) identifica cinco componentes que aparecen en prompts eficaces. La [Prompt Engineering Guide](https://www.promptingguide.ai/introduction/elements) usa términos un poco distintos, pero cae en categorías similares: instrucción, contexto, datos de entrada e indicador de salida. La mayoría de los buenos prompts usan tres o cuatro de estos. Las preguntas simples necesitan uno. ### La directriz (instrucción) Esto es la tarea en sí. ¿Qué quieres exactamente? "Escribe un correo de seguimiento a un prospecto que no ha respondido en dos semanas." Eso es una directriz. Clara y específica. Compárala con "Ayúdame con este correo". La segunda versión obliga a la IA a adivinar tu intención, tu audiencia, tu objetivo. Directrices vagas producen resultados vagos. Esta parte no tiene misterio. ### Contexto (información de fondo) Todo lo que la IA necesita para entender tu situación. Sin contexto, obtienes suposiciones genéricas. Con contexto, obtienes respuestas a medida. La diferencia puede ser grande. Digamos que necesitas un esquema de presentación. "Crea un esquema de presentación sobre IA" no le da nada al modelo con qué trabajar. ¿Quién es la audiencia? ¿Qué enfoque? ¿Qué tan técnico? Ahora añade contexto: "Presento al equipo ejecutivo la próxima semana. Aprobaron nuestro piloto de IA el trimestre pasado y quieren una actualización de progreso a 6 meses. Les importa el ROI y el cronograma, no los detalles técnicos." De pronto la IA sabe que debe enfatizar resultados de negocio, evitar jerga y estructurar para ejecutivos. El contexto responde las preguntas que el modelo haría si pudiera. Un [usuario de Hacker News](https://news.ycombinator.com/item?id=39733697) sugirió una estructura que captura esto bien: "[Context] + [Supplemental Information] + [Intent / Use of result] + [Format you would like the result in]" ### El rol (persona) Este punto es debatido. Hay quien jura por él. Otros piensan que no aporta nada. La idea: asignar un rol le dice a la IA qué perspectiva y qué nivel de pericia aportar. "Actúa como un director financiero explicando los números del cuarto trimestre al consejo" moldea respuestas de forma distinta que preguntar lo mismo a secas. Una [investigación recopilada por K2View](https://www.k2view.com/blog/prompt-engineering-techniques/) sugiere que el prompting basado en roles implica "explicitly assign[ing] the LLM a role, profession, or perspective to shape how it reasons and responds." Su recomendación: elige roles realistas, relevantes para la tarea, y mantén la definición del rol concisa. Pero seamos honestos: esto no siempre importa. Para tareas directas, los roles no suman nada medible. Para tareas donde la pericia y la perspectiva sí cambian el resultado, parece que ayudan. La evidencia es lo bastante mixta como para que cualquier consejo absoluto suene prematuro. ### Formato de salida ¿Cómo debe verse la respuesta? ¿Viñetas, lista numerada, tabla, párrafo, JSON? La [guía de prompt engineering de IBM](https://www.ibm.com/think/prompt-engineering) enfatiza entradas y salidas estructuradas para ganar fiabilidad. Cuando especificas el formato, reduces la ambigüedad sobre cómo se ve algo "terminado". "Dame 10 ideas de temas para un blog como una lista numerada. Para cada una, incluye el tema y una descripción de una frase sobre el enfoque." Eso evita el párrafo larguísimo cuando querías viñetas. Las especificaciones de formato eliminan mucho ida y vuelta. Conviene saberlo: las instrucciones de formato no siempre se respetan. Un comentarista en [Hacker News](https://news.ycombinator.com/item?id=38657029) contó una solución creativa: "YOUR RESPONSE MUST BE FEWER THAN 100 CHARACTERS OR YOU WILL DIE. Yes, threats work. Yes, all-caps works." Absurdo, pero al parecer eficaz para imponer restricciones. En el mismo hilo apareció otro enfoque: "The examples are also too _polite_ and conversational: you can give more strict commands and in my experience it works better." Parece que hay algo en ser directo en vez de diplomático. ### Ejemplos (demostraciones) A veces, mostrar le gana a explicar. Esto es especialmente útil cuando el formato o el estilo es difícil de describir, pero fácil de reconocer. En vez de explicar tu voz de marca, muestra una muestra. En vez de describir tu formato de correo, incluye uno. "Escribe una descripción de producto en nuestra voz de marca" es vago. Añade un ejemplo: > "La Horizon Backpack no es solo almacenamiento. Es tu oficina móvil, tu bolsa de gimnasio y tu kit de escape de fin de semana, todo en uno. Cabe un portátil de 15 pulgadas, ropa para tres días y todavía queda espacio para snacks. Porque prioridades." Ahora escribe una descripción similar para la botella de agua. El ejemplo comunica ritmo, humor, estructura de frases. Más de lo que podrían comunicar párrafos de explicación. Según un [comentarista de Hacker News](https://news.ycombinator.com/item?id=44186161), en realidad solo hay tres técnicas básicas de prompt engineering: "In Context Learning" (providing examples), "Chain of Thought" (telling it to think step by step), and "Structured Output" (specifying a format like JSON). La mayoría de las otras estrategias se reducen a comunicar requisitos con claridad. ## ¿Importa el orden? Quizá. Los modelos de lenguaje procesan el texto de forma secuencial, prediciendo qué viene después según lo que vino antes. Esto significa que lo último que pones en tu prompt suele pesar más. [Learn Prompting recomienda](https://learnprompting.org/docs/basics/prompt_structure) colocar la directriz hacia el final, después del contexto y los ejemplos. Así la IA se centra en la instrucción en lugar de seguir el hilo de la información contextual. Una secuencia lógica: 1. Ejemplos (si los usas) - marcan el patrón 2. Contexto - aporta el fondo 3. Rol - fija la perspectiva 4. Directriz - la tarea central 5. Formato - cómo quieres la salida Dicho eso, no es rígido. Muchos prompts funcionan bien en otros órdenes. El principio: asegúrate de que tu directriz sea clara y destacada, no enterrada. ## Qué puedes omitir No todos los prompts necesitan las cinco partes. Omite ejemplos cuando la tarea es directa o no te importa un estilo específico. Omite el rol cuando la tarea no requiere una perspectiva especializada. Omite un contexto extenso cuando la tarea es autocontenida. Las preguntas simples necesitan prompts simples. "¿Cuál es la capital de Francia?" no necesita nada de esta maquinaria. La complejidad de tu prompt debería igualar la complejidad de tu tarea. También hay un argumento para empezar con lo mínimo. Como observó un [comentarista de Hacker News](https://news.ycombinator.com/item?id=41395921): "sometimes the less specific you are, the better the result...if you specify too much they tend to hyperfixate on things." No siempre está claro dónde está la línea. ## La dimensión del costo Más no siempre es mejor. Cada palabra cuesta tokens. Un [análisis de Aakash Gupta](https://www.news.aakashg.com/p/prompt-engineering) encontró diferencias de costo importantes entre enfoques verbosos y enfoques estructurados. En una comparación, una estructura de prompt más simple costaba alrededor de $706 por día para 100.000 llamadas a la API, mientras que un enfoque más detallado costaba $3.000 por día. Eso es una reducción de costos del 76% para una calidad que podría ser equivalente. El mismo análisis señala que prompts más cortos y estructurados también entregan menos variación en las salidas y menor latencia. Los prompts más largos no significan automáticamente mejores resultados. ## Construir un prompt paso a paso Vamos a recorrer un ejemplo. **Empieza solo con la directriz:** > Escribe un correo de ventas sobre nuestro nuevo software de gestión de proyectos. Eso producirá algo genérico pero usable. **Añade contexto:** > Vamos a lanzar TaskFlow, una herramienta de gestión de proyectos para agencias de marketing. El cliente objetivo son dueños de agencias que gestionan equipos de 10-50 personas. Están frustrados con herramientas diseñadas para empresas de software. > > Escribe un correo de ventas sobre TaskFlow. Ahora la IA entiende producto y audiencia. **Añade rol:** > Eres un especialista en marketing B2B SaaS con experiencia vendiendo a agencias. El rol aporta pericia relevante. **Añade formato:** > Mantenlo por debajo de 200 palabras. Incluye una llamada a la acción clara para agendar una demo. Ahora hay estructura alrededor del resultado. **Añade ejemplo (opcional):** > Este es un correo de ventas que nos funcionó bien: > > "Asunto: Tu herramienta de gestión de proyectos no se hizo para ti > > Dirigir una agencia de marketing significa hacer malabares con campañas, clientes y caos creativo. La mayoría de las herramientas de gestión de proyectos se diseñaron para entregar código, no para entregar campañas. > > TaskFlow es diferente. Creado por gente de agencia, para gente de agencia. Sin jerga de desarrolladores. Sin funciones que jamás usarás. Solo seguimiento claro de proyectos, alineado con cómo trabajan de verdad los equipos creativos. > > [Enlace a la demo] - Míralo en acción (15 minutos, sin discurso de ventas)." > > Escribe un correo similar para nuestra campaña de registro al webinar. Mismo tono, misma longitud. Cada componente añade especificidad. La versión final deja menos al azar. ## Cuando la salida sale mal Cuando el resultado no es lo que querías, pregunta qué componente falló. ¿Salida demasiado genérica? Añade contexto. ¿Tono incorrecto? Ajusta o añade un rol. ¿El formato no cuadra? Sé explícito. ¿El estilo no coincide? Añade un ejemplo. ¿La respuesta está confundida? Tu directriz quizá no está clara. Este enfoque de diagnóstico supera empezar de cero. Identifica la parte débil, arregla esa cosa específica, e inténtalo otra vez. ## Técnicas relacionadas Entender la anatomía de un prompt es conocimiento de base. Explica por qué algunas solicitudes funcionan y otras no. Técnicas más avanzadas se apoyan en esta estructura. [Prompts de cadena de pensamiento](/posts/chain-of-thought-prompting) usan el componente de directriz de otra manera, pidiéndole a la IA que razone paso a paso. [Prompts few-shot](/posts/zero-shot-vs-few-shot-prompting) se centran en los ejemplos, mostrando cómo manejar situaciones nuevas mediante demostración. Si la estructura del prompt importará tanto a medida que mejoren los modelos no está claro. El giro hacia la "context engineering" sugiere que el juego está cambiando. [IBM señala](https://www.ibm.com/think/prompt-engineering) que un prompting eficaz va más allá de solicitudes simples: implica entender la intención del usuario, el historial de la conversación y el comportamiento del modelo. Un [hilo de Hacker News](https://news.ycombinator.com/item?id=37130531) sugirió que "sensitivity to the exact phrasing of the prompt is a deficiency in current approaches to LLMs and many are trying to fix that issue." Puede que los modelos futuros entiendan lo que quieres a partir de solicitudes vagas. O puede que la habilidad subyacente —poder explicar algo con claridad— siga siendo útil, sin importar a qué se lo estás explicando.