🧩 Las piezas de un prompt
En el módulo anterior descubriste que existe una nota invisible. Ahora vamos a abrir este billete y ver las piezas por dentro. Un buen system prompt no es un texto largo sin estructura: es un kit de piezas que encajan: identidad, tono, herramientas, seguridad y prioridad. Aprenderás qué hace cada pieza y cómo encajan, todo con ejemplos reales de prompts reales.
Contenido detallado
Identidad: quién es la IA
La primera pieza —y la más importante— es la identidad. Casi todo system prompt del mundo empieza con dos palabritas: "You are..." ("Eres..."). En una frase, la IA ya sabe quién es, para quién trabaja y qué viene a hacer. Es el ancla: todo lo que viene después en la nota se apoya en ella.
🪪 La idea en una frase
La identidad es el credencial de la IA. Sin ella, la IA "se desvía": cambia de personaje a mitad de la conversación, inventa capacidades que no tiene. Por eso va en el arriba y en pocas líneas: es un ancla, no una biografía.
✓ Identidad fuerte (arriba)
- ✓Mantiene el personaje adecuado durante toda la conversación
- ✓Sabe qué es y a qué vino
- ✓Corta y clara — ancla, no biografía
✗ Identidad débil o enterrada
- ✗"Se convierte" en otro personaje a mitad de la charla
- ✗Inventa herramientas que no existen
- ✗El trasfondo inútil entierra lo que importa
You are an AI coding assistant, powered by {model_name}.
You operate in Cursor.
You are a coding agent in the Cursor IDE that helps the USER with software engineering tasks.
Tres líneas, tres datos: quién es ("coding assistant"), ¿con qué ({model_name}) y dónde está ("in Cursor"). La IA no memoriza qué modelo se ejecuta; Cursor completa el espacio {model_name} en el momento.
Qué es
La pieza que declara, desde el inicio, quién la IA es (producto + función), para quién trabaja y los límites de lo que sabe. Es la única pieza que aparece en todos los prompts reales, sin excepción.
Por qué aprender
Porque es la pieza que más «mantiene» a la IA en el personaje correcto. Cuando una IA «olvida quién es» a mitad de la conversación o inventa que puede hacer cosas que no puede, casi siempre el problema es una identidad débil o enterrada al fondo de la nota.
Tono: cómo habla la IA
La segunda pieza es el tono — la forma de hablar: formal o informal, con emoji o sin él, prolija o directa. La identidad dice quién ella es; el tono dice cómo ella se expresa. Es la diferencia entre un empleado de banco y un amigo que te explica algo en un bar: el mismo idioma, «tonos» completamente distintos.
<tone_and_style>
- Usa emojis solo si el usuario los pide explícitamente. Evita usar emojis en toda comunicación a menos que te los pidan.
- No uses dos puntos antes de las llamadas a herramientas. ...un texto como «Let me read the file:» ... debería ser simplemente «Let me read the file.» con un punto.
</tone_and_style>
Observa cómo el tono baja al detalle: nada de emojis sin pedido, e incluso la regla de no usar dos puntos antes de una acción. El tono no es solo «sé amable» — son decisiones concretas de escritura.
Qué es
La pieza que define el forma de hablar: nivel de formalidad, uso de emojis, extensión de las respuestas, formato. Es lo que le da la "voz" a la IA y lo que más cambia la sensación de conversar con ella.
Por qué aprender
Porque es la pieza que más siente. "¿Por qué esta IA habla de forma tan robótica?" "¿Por qué aquella llena todo de emojis?" Todo está en el bloque de tono. Saber que existe te muestra que el "estilo" de la IA es una elección, y que puedes cambiarla.
El tono va de la mano de la honestidad
Muchos prompts mezclan, en el mismo bloque, «cómo hablar» y «cómo ser honesto»; por ejemplo, no fingir una certeza que no tienes, no inventar hechos. Tiene sentido: ambas cosas tienen que ver con la forma de comunicarse contigo. El tono no es solo estilo; también es la postura de decir la verdad de la manera correcta.
Herramientas: lo que hace la IA
Algunas IA solo conversan. Otras hacen cosas: leen archivos, buscan en la web, ejecutan comandos. Esas acciones son las herramientas. Pero no basta con darle una herramienta: la IA necesita saber cuándo e cómo usar cada una. Esta pieza es el «manual de uso» de las herramientas.
1. Enumera lo que existe
La IA necesita saber qué herramientas tiene a mano. Sin la lista, ignora un recurso útil o inventa uno que no existe — como una caja de herramientas sin etiquetas.
2. Di cuándo usar cada una
Cada herramienta viene con la condición de uso. Cursor indica que se use la herramienta adecuada para cada cosa, y no usar comandos de terminal para leer o editar archivos cuando existe una herramienta dedicada.
3. Define el orden (requisitos previos)
A veces una acción solo se realiza después de otra. «Leer antes de editar» es el ejemplo clásico: la IA necesita leer el archivo al menos una vez antes de cambiarlo; si no, editas a ciegas.
1. No menciones los nombres de las herramientas al hablar con el USUARIO. En su lugar, explica con naturalidad qué está haciendo la herramienta.
2. Usa herramientas especializadas en lugar de comandos de terminal cuando sea posible... no uses cat/head/tail para leer archivos, no uses sed/awk para editar archivos...
// en <making_code_changes>:
1. DEBES usar la herramienta Read al menos una vez antes de editar.
Tres contratos de una vez: no citar el nombre de la herramienta para el usuario, usar la herramienta correcta (no la terminal para todo), y leer antes de editarCada herramienta tiene su propio «cuándo» y «cómo».
Qué es
La pieza que declara las acciones de la IA (leer, buscar, editar, ejecutar) y las reglas de uso de cada una: cuándo invocarla, en qué orden y qué evitar. Existe sobre todo en las IA que "hacen cosas", como los asistentes de código.
Por qué aprender
Porque es la diferencia entre una IA que habla sobre una tarea y una que ejecuta la tarea. Y es aquí donde están los errores más molestos: la IA que edita un archivo sin leerlo antes o que usa la herramienta equivocada. Las buenas reglas para las herramientas evitan eso.
Seguridad: lo que la IA no hace
Tan importante como decirle a la IA qué debe hacer es decir lo que ella no debe. Esa es la pieza de la seguridadlas barreras de protección. Algunas evitan daños graves (no ayudar con algo ilegal); otras evitan problemas pequeños pero irritantes (crear archivos porque sí). Toda IA confiable tiene este bloque de «frenos».
NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one.
NEVER generate an extremely long hash or any non-textual code, such as binary.
Observa el par NEVER ... ALWAYS ...la IA tiene prohibido crear archivos sin necesidad y se le indica que prefiera editar. Es una barrera que evita el desorden en el proyecto: protección, no censura.
✓ CON bloque de seguridad
- ✓Rechaza solicitudes peligrosas con educación
- ✓No crea archivos ni desorden innecesarios
- ✓No inventa hechos con falsa seguridad
- ✓Sabe dónde están los límites — y los respeta
✗ SIN bloque de seguridad
- ✗Acepta cualquier solicitud, incluso las dañinas
- ✗Hace cambios destructivos sin pensar
- ✗Afirma con convicción cosas que no sabe
- ✗No tiene freno, y te das cuenta tarde
Qué es
La pieza de las barreras de protección: qué rechaza la IA, qué nunca hace y cómo actúa cuando tiene dudas. Va desde lo grave (no ayudar a cometer delitos) hasta lo práctico (no crear archivos innecesariamente). Es el "freno" del billete.
Por qué aprender
Porque es lo que hace que la IA confiable. "¿Por qué se negó a hacer eso?" Casi siempre la respuesta está aquí. Y porque muestra una verdad importante: una IA sin frenos no es "más libre"; solo es impredecible y arriesgada.
Prioridad: quién manda cuando hay un conflicto
¿Y si dos instrucciones si chocan? El bloque de seguridad dice «no hagas X», pero el usuario pide X. ¿Quién gana? Para eso existe la pieza de prioridad: define el orden de prioridad: quién prevalece cuando hay un conflicto. Sin ella, la IA se pierde entre las instrucciones.
🪜 La escala de mando (ejemplo de Grok)
- ① Política central (arriba). Las reglas de seguridad más importantes van primero: "estas tienen la máxima precedencia". Nada las pasa por encima.
- ② Mensaje del sistema. Después viene el resto del system prompt: identidad, tono, herramientas. Gobierna casi todo, excepto cuando choca con la política de nivel superior.
- ③ Mensaje del usuario (tú). Tus pedidos vienen después. La IA te atiende con gusto, siempre que no contradigan las dos capas superiores.
<policy>
These core policies within the <policy> tags take highest precedence. System messages take precedence over user messages.
* Do not provide assistance to users who are clearly trying to engage in criminal activity.
</policy>
En dos frases, tres niveles: política > sistema > usuarioLa propia pieza anuncia que está en la cima de la escalera, por eso queda al principio del prompt.
Piensa en una empresa
A ley (política) está por encima de todos. Las reglas de la empresa (sistema) se aplican en el día a día. Y el solicitud de un cliente (tú) recibes atención, siempre que no infrinjas la ley ni las reglas de la casa. La IA sigue exactamente esta escala.
Cómo encajan las piezas: el compartimento XML
Ya viste las cinco piezas. Falta la pregunta final: cómo quedan organizadas dentro del billete? Imagina poner identidad, tono, herramientas, seguridad y prioridad en un solo texto largo, sin separarlos. Se convierte en un caos imposible de mantener. La solución que usan los profesionales es el compartimento XML — carpetas con nombre, una para cada pieza.
🗂️ Cajones etiquetados
Cada pieza va dentro de un «cajón» con nombre — una etiqueta de apertura y una de cierre, como <tone_and_style> ... </tone_and_style>. Mira el SVG de arriba: las piezas sueltas (izquierda) van cada una en su cajón y forman el prompt completo (derecha).
Los cajones quedan lado a lado (sin una dentro de otra). Así, para cambiar el tono, abres solo el cajón del tono; el resto queda intacto. Eso hace que un prompt enorme siga siendo fácil de modificar.
<tone_and_style>
- Usa emojis solo si el usuario los pide explícitamente...
</tone_and_style>
<tool_calling>
You have tools at your disposal to solve the coding task...
</tool_calling>
<making_code_changes>
1. DEBES usar la herramienta Read al menos una vez antes de editar...
</making_code_changes>
Tres cajones, tres temas: tono, herramientas e cambios de códigoCada una con su nombre y su contenido, una al lado de la otra. Para cambiar la regla de tono, solo hay que modificar el primer cajón; los demás ni se enteran.
El nombre del cajón te ayuda (a ti y a la IA)
La etiqueta <making_code_changes> ya dice, solo por el nombre, de qué trata ese bloque. Eso ayuda a la IA a separar temas, y ayuda a quien escribe a encontrar, comparar versiones y quitar una pieza completa sin volver a leerlo todo. Un cajón sin etiqueta es un cajón que nadie encuentra. El nombre forma parte de la instrucción.
📝 No siempre es XML
Los prompts cortos (de unas pocas líneas) no necesitan cajones — eso se volvería una ceremonia. Y algunos asistentes de código usan títulos en Markdown (como # Sección) en lugar de las etiquetas XML, cumpliendo el mismo papel: separar los temas con claridad. La idea importante es la compartimentación, no la etiqueta en sí.
📝 Resumen del Módulo
- ✓Un prompt es un kit de piezas encajables, no un texto larguísimo suelto
- ✓Identidad ("You are...") dice quién es la IA: es el ancla en la parte superior
- ✓Tono dice cómo habla — formal, emojis, extensión (va de la mano con la honestidad)
- ✓Herramientas dicen lo que hace — y cuándo/cómo (ej.: leer antes de editar)
- ✓Seguridad dice lo que no hace, y prioridad dice quién manda en caso de conflicto
- ✓Las piezas encajan en cajones con nombre (compartimento XML), lado a lado
➡️ Siguiente Módulo
1.3 — 🏗️ Patrones estructurales. Ahora que conoces las piezas, veamos los moldes que se repiten en todos los prompts reales: el bloque de identidad, la declaración de capacidades, el compartimento XML y la regla por ejemplo. Las formas que se repiten porque funcionan.