🏗️ Patrones estructurales
En el módulo pasado abriste la nota y viste las piezas. Ahora vamos a mirar la forma de estas piezas: cómo los profesionales organizan un system prompt para que quede claro, organizado y fácil de mantener. Son cinco "moldes" que aparecen en casi todo prompt real, y una advertencia sobre cuándo no usar el más famoso de ellos.
Contenido detallado
El Bloque de Identidad: «You are...»
Casi todos los system prompts del mundo empiezan con las mismas dos palabritas: "You are..." ("Eres..."). Es el primera línea, y hace un trabajo enorme: ancla quién es la IA antes de cualquier regla. Sin ese ancla, la IA deriva — cambia de personalidad a mitad de la conversación, inventa que tiene herramientas que no tiene, habla de cosas que no conoce como si las conociera.
🪪 La idea en una frase
El Bloque de Identidad responde tres preguntas desde el comienzo: quién es la IA, dónde ella opera y el qué ella sabe (hasta dónde llega su conocimiento). Es el «ancla» a la que hace referencia todo lo demás del prompt.
Piensa en la credencial de un empleado en su primer día: nombre, cargo, área. En tres líneas, todo el mundo (y la propia IA) sabe con quién está hablando. Nada de biografía: solo lo esencial para fijar la autoimagen.
You are ChatGPT, a large language model trained by OpenAI, based on GPT 5.5.
Knowledge cutoff: 2025-08
Current date: 2026-06-01
Los tres elementos canónicos en tres líneas: persona ("You are ChatGPT..."), corte de conocimiento e fecha de hoy. Limpio, breve, sin rodeos.
You are Perplexity Computer.
Tu objetivo es resolver por tu cuenta tantas cosas como sea posible. Usa herramientas para responder tus propias preguntas y explorar.
Aquí la identidad viene con el objetivo pegado: quién es + qué vino a hacer. "Resuelve el máximo posible por tu cuenta" no es una regla aislada — es la misión que da sentido a todas las demás instrucciones.
✓ CON una buena identidad al principio
- ✓La IA mantiene la misma personalidad de principio a fin
- ✓Sabe qué puede y qué no puede hacer
- ✓No inventa hechos posteriores a la fecha de corte
- ✓Corta: de 3 a 5 líneas, solo quién/dónde/cuándo
✗ SIN identidad (o enterrada en medio)
- ✗"Se convierte" en otra IA a mitad de la conversación
- ✗Afirma tener herramientas que no existen
- ✗Responde sobre eventos que no conoce
- ✗Recargada con una historia de fondo que nadie usa
La Declaración de Capacidades: qué puede hacer
Justo después de decir quién sí, un buen prompt dice lo que la IA puede hacer. Parece obvio, pero es el paso que más gente olvida, y el resultado es una IA que se ofrece a generar una imagen que no sabe generar, o que ignora una herramienta que tenía todo el tiempo. La Declaración de Capacidades es la lista de superpoderes de la IA, cada uno con su regla sobre cuándo usarlo.
Qué es
Una sección que enumera cada capacidad con tres cosas: lo que hace, cuándo usar e a condición/límite ("si el usuario lo pide...", "solo cuando sea urgente..."). El secreto es que una capacidad sin condición se convierte en un caos: la IA termina usando la herramienta correcta en el momento equivocado.
Por qué aprender
Porque «dar poderes» no basta: hay que enseñar cuándo usarlos. La diferencia entre una IA que tantea y una que ejecuta directamente está aquí. Y ten en cuenta: cada capacidad real incluye una condición integrada, y eso es lo que evita que la IA se precipite.
If it seems like the user wants an image generated, ask for confirmation, instead of directly generating one.
Observa cómo la capacidad («generar imagen») ya viene con el protocolo ("pide confirmación primero"). No es solo "puedes generar imágenes", sino cuándo e cómo. Es una capacidad bien definida.
def concise_search(query: str, max_num_results: int = 3):
"""Does a search for the query and prints up to the max_num_results results."""
Google declara capacidades como firmas de función: el alcance, los parámetros e incluso el valor predeterminado (max_num_results = 3) quedan inequívocos. No queda ninguna duda sobre lo que se puede hacer.
Identidad ≠ Capacidades (no las confundas)
A Identidad dice quién la IA es; la Declaración de capacidades dice el qué ella puede hacer. En un chat sin herramientas, esta sección se convierte en «lo que yo no puedo hacerlo" — breve, pero útil para que la IA no prometa lo que no puede cumplir.
El Compartimento XML: cada tema en su cajón
Imagina un prompt de mil líneas escrito como un bloque de texto sin párrafos. Encontrar una regla ahí sería una pesadilla. La solución que adoptaron los labs es simple y poderosa: colocar cada tema en un «cajón» con etiqueta. Estos cajones son las etiquetas XML: <tone_and_style>, <tool_calling>, <safety> — y hacen que el prompt sea fácil de recorrer. Es el diagrama de arriba: bloques apilados, cada uno con su nombre.
1. La etiqueta de apertura — <tone_and_style>
Marca el inicio del cajón y le pone nombre.
El nombre de la etiqueta funciona como etiquetala IA «busca» el bloque correcto en el momento adecuado. Cuando la conversación pide un tono, va directamente al cajón tone.
2. El contenido — las reglas de ese tema
Todo lo relacionado con el tono (y solo con el tono) vive aquí dentro.
Nada de mezclar: la regla de seguridad no va en el cajón del tono. Cada tema aislado — eso es lo que hace que el prompt sea fácil de leer y modificar.
3. La etiqueta de cierre — </tone_and_style>
Cierra el cajón. El siguiente cajón (otro tema) empieza justo debajo.
Con un inicio y un final claros, puedes cambiar un cajón entero sin tocar las otras — y puedes comparar dos versiones del prompt y decir exactamente «cambió el bloque del tono».
<tone_and_formatting>
- Usa emojis solo si el usuario los pide explícitamente...
</tone_and_formatting>
<tool_calling>
You have tools at your disposal...
</tool_calling>
Para cambiar la política de tono, se edita solo el primer bloque — el resto queda intacto. Las etiquetas son planas (una al lado de la otra), no encajadas una dentro de otra. Volveremos a esta palabra "plana" en el Tema 6.
Por qué esto ayuda a las personas, no solo a la IA
Un prompt compartimentado se convierte en navegable por un equipoSe puede hacer una «revisión de código» de un bloque, comparar versiones y decir «Anthropic eliminó el bloque <search_first>" — una frase precisa. Sin los cajones, sería "cambió algo en algún lugar".
La regla del ejemplo: mostrar en vez de describir
"Formatea las citas adecuadamente." Adecuadamente cómo? Esa frase admite mil interpretaciones, y la IA va a elegir una, probablemente la equivocada. El molde que resuelve esto es simple: muestra un ejemplo en vez de (solo) describir. Un ejemplo concreto elimina de una vez la ambigüedad que tres párrafos de explicación no logran eliminar.
🎯 Mostrar > describir
La IA reconoce patrones mucho mejor de lo que sigue especificaciones verbales. En vez de explicar un formato en prosa, pegas un ejemplo de lo correcto (y, mejor aún, un par correcto × incorrecto). El ejemplo contiene la regla, a veces incluso antes de que la prosa la explique.
Es la diferencia entre decir «arma el mueble correctamente» y diseñar el mueble ensamblado. El diseño no deja dudas.
The anchor text must be the source name, publication, or a natural descriptive phrase — never a generic word like "source" or "link", and never a raw URL.
INCORRECTO: "The population grew 5% ([fuente](https://...))"
RIGHT: "The population grew 5% ([Banco Mundial](https://...))"
RIGHT: "According to [datos del Banco Mundial](https://...), the population grew 5%"
Observa la ingeniería: la regla en prosa ("el texto del enlace tiene que ser el nombre de la fuente, nunca una palabra genérica como 'source' o 'link'") ya sería buena, pero viene reforzada por un par INCORRECTO/CORRECTO que muestra exactamente lo incorrecto y lo correcto. Imposible interpretarlo mal.
Example: <database url="URL" inline>Title</database>
Example: <database url="URL" locked>Title</database>
Dos líneas de ejemplo sustituyen todo un párrafo que describe atributos. La IA ve el formato y lo copia patrón — no la palabra literal.
✓ Ejemplo bien usado
- ✓Muestra el formato y la mecánica
- ✓Usa el par correcto × incorrecto (WRONG/RIGHT)
- ✓Es corto — atajo, no enciclopedia
- ✓Deja claro qué debes «completar aquí»
✗ El peligro: «overfit» al ejemplo
- ✗La IA copia el ejemplo literalmente
- ✗Trata la lista de ejemplos como exhaustiva
- ✗Ejemplo tan largo como el resultado esperado
- ✗Usar un ejemplo para criterio (rigidiza)
Nombrar bloques: el nombre ya es una instrucción
Aquí viene un detalle precioso y fácil de pasar por alto: el nombre que le das a un bloque también le enseña a la IA. No es solo una etiqueta administrativa. Cambia el nombre —aunque dejes el contenido igual— y la IA empieza a comportarse de una manera diferente. Hay un caso real de Anthropic que lo demuestra de forma casi poética.
<claude_prioritizes_copyright_compliance>
<core_copyright_principle>
La regla estricta por dentro sigue siendo la misma («Copyright compliance is NON-NEGOTIABLE»). Solo el nombre del bloque cambió: de cumplimiento ("cumple las reglas") para principle ("respeta la propiedad intelectual").
🧠 Por qué esto lo cambia todo
"Compliance" es una ordenla IA obedece en los casos enumerados, y solo en ellos. «Principle» es un valorla IA razona a partir de él y cubre incluso los casos que nadie previó. El nombre cambia la postura de la IA ante una situación nueva.
Es decir: el nombre del bloque es la primera línea que la IA lee sobre ese tema, y ya «entra en el clima» adecuado gracias a él. Por eso elegir buenos nombres es parte del trabajo, no un adorno.
Nombra por valor, no por mecánica
Prefiere <respects_user_privacy> a <privacy_rules_v2>. El primer nombre indica porqué e invita a la IA a razonar; el segundo es solo un cajón sin alma. Este principio vuelve con fuerza en el Módulo 1.6 ("de regla a principio").
Cuándo NO usar XML (sí, a veces estorba)
Después de tantos elogios a los cajones XML, viene el contrapunto honesto: no todos los prompts las necesitan. Demasiada estructura, en el lugar equivocado, se vuelve una ceremonia: solo estorba. Saber cuándo no usar un molde es tan importante como saber usarlo. Aquí van los tres casos en los que sobra el XML.
⚠️ Los tres casos en que el XML sobra
- ① Prompt cortito (menos de ~50 líneas). Si cabe en una pantalla, las etiquetas se vuelven adorno. Un pedido de una sola tarea no necesita cajones: escríbelo directamente.
- ② Cuando Markdown ya resuelve el problema. Los agentes de código (como Claude Code) usan # Títulos en Markdown en lugar de XML: cumple la misma función de separar temas y resulta más natural allí.
- ③ Anidamiento profundo de etiquetas. Los prompts reales mantienen los bloques planes — rara vez superan los 2 niveles. Encajar un cajón dentro de otro cajón dentro de otro cajón se convierte en un laberinto.
✓ XML tiene sentido cuando...
- ✓El prompt es largo (muchos temas)
- ✓Será versionado y mantenido por un equipo
- ✓Quieres comparar versiones por bloque (diff)
- ✓Hay políticas que se benefician de límites claros
✗ XML sobra cuando...
- ✗Es una instrucción breve para una sola tarea
- ✗Markdown con títulos ya organiza bien
- ✗Te descubriste anidando 3+ niveles de etiquetas
- ✗La estructura ocupó más espacio que el contenido
La regla práctica
La estructura existe para servir a la claridad, no al revés. Si el cajón hace que el prompt más fácil de leer y mantener, úsala. Si solo agrega ruido, quita. El molde es una herramienta: tú lo controlas, no al revés.
📝 Resumen del Módulo
- ✓O Bloque de identidad ("You are...") ancla quién/dónde/cuándo desde la primera línea
- ✓A Declaración de capacidades lista lo que puede hacer la IA, cada cosa con su condición
- ✓O Compartimento XML pone cada tema en un cajón con nombre (<tag>), plana y modular
- ✓A Regla mediante ejemplo muestra el formato (par WRONG/RIGHT) en lugar de solo describirlo
- ✓O nombre del bloque también es una instrucción: cumplimiento (orden) vs. principle (valor)
- ✓No todo prompt necesita XML — en texto corto o código, se convierte en un ritual
➡️ Siguiente Módulo
1.4 — 🎚️ Patrones de comportamiento. Ya tienes el forma de los bloques. Ahora vamos al contenidocómo escribir las reglas dentro de ellos —con el porqué, con el contraste always/never, con un presupuesto de concisión— para que la IA no solo obedezca, sino entender.