Los mejores ejemplos de system prompt no son los "eres un asistente útil" de los tutoriales. Son los bloques de instrucciones concretos que evitan que una app en producción se descontrole a las 2 de la madrugada. En nuestro propio pipeline de contenido corremos más de una docena de subagentes de Claude, cada uno guiado por un system prompt que hemos reescrito una y otra vez después de que provocara un bug en Claude Opus 4.8 o GPT-5. Este artículo se salta las demos de juguete. Aquí tienes 7 system prompts reales, listos para copiar y pegar, dos de ellos sacados directamente de ese stack de producción, más la anatomía de 6 bloques que sostiene a cada uno de los buenos.
Puntos Clave
- Un system prompt es un conjunto de instrucciones persistentes (rol, restricciones, formato de salida, guardrails) que se fija una sola vez, antes de cualquier mensaje del usuario.
- Si un contenido es idéntico en 1.000 solicitudes, va en el system prompt; el contenido específico de cada solicitud va en el turno del usuario.
- Seis bloques construyen un prompt fiable: rol, contexto, restricciones, formato de salida, guardrails y ejemplos.
- Los modelos de razonamiento (serie o, GPT-5, Claude Opus 4.5+) quieren objetivos de alto nivel, no un lenguaje agresivo del tipo "DEBES hacerlo".
¿Qué Lleva un System Prompt? Los 6 Bloques que lo Construyen
Un system prompt es un conjunto de instrucciones persistentes que define el rol, el comportamiento, las restricciones y el formato de salida de un modelo para toda una sesión, fijadas una sola vez antes de cualquier mensaje del usuario. Los fiables comparten seis bloques: rol, contexto, restricciones, formato de salida, guardrails y ejemplos opcionales. Ordena bien esos bloques y tienes la versión corta de cómo escribir un system prompt que sobrevive en producción.
Esto es lo que hace cada bloque.
| Bloque | Qué hace | Ejemplo en una línea |
|---|---|---|
| Rol | Define quién es el modelo y su alcance | "Eres un agente de soporte para el equipo de facturación de Acme." |
| Contexto | Información estable que necesita en cada turno | "Los clientes están en el plan Pro; los reembolsos se permiten hasta 14 días." |
| Restricciones | Reglas y límites estrictos | "Nunca prometas un reembolso superior a $200 sin escalar." |
| Formato de salida | La forma exacta de la respuesta | "Responde en menos de 120 palabras, texto plano, sin markdown." |
| Guardrails | Comportamiento de rechazo y fallback | "Si te piden asesoría legal, rechaza y deriva a un humano." |
| Ejemplos | 1-2 muestras de una buena respuesta | Una pregunta de ejemplo con la respuesta ideal. |
El bloque de rol importa más de lo que parece. La documentación de Anthropic lo dice sin rodeos: fijar un rol en el system prompt enfoca el comportamiento y el tono del modelo, y "incluso una sola frase marca la diferencia". Para el bloque de guardrails, las reglas de rechazo y seguridad merecen atención real; profundizamos en ellas en nuestra guía de guardrails. Y si estás integrando Claude, Anthropic recomienda etiquetas XML (<instructions>, <context>, <input>) para separar cada tipo de contenido y que el modelo no los mezcle.
Aquí tienes un esqueleto listo para pegar que une los seis bloques en una sola plantilla:
# ROLE
You are a {role} for {audience}. Your scope is {narrow scope}.
# CONTEXT
{Stable facts the model needs on every request.}
# CONSTRAINTS
- {Hard rule 1}
- {Hard rule 2}
- Do not {forbidden action}.
# OUTPUT FORMAT
{Exact structure: length, format, JSON schema.}
# GUARDRAILS
- If {edge case}, then {fallback or escalate to a human}.
- If you are unsure, say so instead of guessing.
# EXAMPLES (optional)
{One or two model answers that show the target quality.}Seis bloques convierten una intuición en una especificación. Esto es solo la capa del system prompt. Para las técnicas más amplias (few-shot, chain-of-thought, prompt chaining), consulta nuestra guía de prompt engineering, y mantenlas fuera del system prompt en sí. Un system prompt de sesión también es distinto de un archivo a nivel de repositorio con instrucciones persistentes a nivel de proyecto como un CLAUDE.md, que gobierna todo un código base en lugar de una sola sesión de API.
7 Ejemplos de System Prompt para Producción (Listos para Copiar y Pegar)
Aquí tienes 7 ejemplos de system prompt que puedes pegar hoy mismo en tu parámetro system o en un mensaje developer. Cada uno resuelve un caso real (agente, RAG, soporte, código, JSON, QA de contenido, traducción), y cada uno muestra por qué existen sus bloques clave. Los dos últimos corren en nuestro propio pipeline. Los repositorios que filtran los prompts de Cursor y Devin demuestran la demanda; lo que nadie publica es la anotación que explica por qué está ahí cada bloque.
1. Agente Autónomo
Delimita el rol de forma estricta, detalla las reglas de las herramientas y dale una condición de parada para que no quede en bucle para siempre.
You are a research agent. Your only job is to answer the user's
question using the provided tools.
TOOLS: web_search, read_url, calculator.
RULES
- Plan first: list the steps before calling any tool.
- Call one tool at a time and check the result before the next call.
- Never invent a URL or a fact. If a tool fails twice, stop.
STOP CONDITION
- When you have enough to answer, stop calling tools and reply.
- If the task needs account access or a purchase, hand off to a
human and explain why.Por qué funciona: el rol estrecho más una condición de parada explícita marcan la diferencia entre un agente que termina y uno que quema tokens en un bucle. Este es el núcleo de las buenas prácticas de system prompt para agentes.
2. RAG / Preguntas y Respuestas por Recuperación
Todo el juego con retrieval consiste en impedir que el modelo responda desde su propia memoria. Una sola regla lo consigue.
You answer questions using ONLY the context provided below.
CONTEXT
{retrieved_chunks}
RULES
- If the answer is not in the context, say: "I don't have that
in my sources." Do not use outside knowledge.
- Cite the source after each claim using [chunk_id].
OUTPUT
Two to four sentences, plain text, with citations.Por qué funciona: "solo desde el contexto" más un formato de citas es la protección contra alucinaciones más barata que puedes escribir para un system prompt de RAG.
3. Bot de Soporte al Cliente
El tono, una vía de escalado y una regla estricta sobre el dinero mantienen a un bot de soporte útil sin dejarle prometer cosas que no puede cumplir.
You are a support agent for Northwind's billing team. Be warm,
brief, and factual.
CONTEXT
- Customers are on Free, Pro, or Enterprise plans.
- Refunds are allowed within 14 days of a charge.
CONSTRAINTS
- Never promise a refund above $200 without escalation.
- Do not give tax or legal advice.
GUARDRAILS
- If the customer is angry or asks for a manager, escalate to a
human and say a teammate will follow up within one business day.
- If you are unsure of a policy, say you'll check rather than guess.Por qué funciona: el guardrail de reembolsos y el fallback de escalado frenan los dos modos de fallo que hacen que un bot de soporte acabe retirado de producción.
4. Asistente de Código
Restringe el formato de salida y las versiones, y oblígalo a explicar antes de editar.
You are a coding assistant for a Next.js 15 + TypeScript codebase.
RULES
- Explain your plan in two sentences before writing any code.
- Output changes as a unified diff, not full files.
- Match the existing style. Do not add dependencies without asking.
- Target Node 20. Do not use APIs newer than that.
If a request is ambiguous, ask one clarifying question before editing.Por qué funciona: "diff, no archivos completos" más un tope de versión mantienen al asistente dentro de tu stack. El diseño de prompts para agentes de código da para su propia guía, así que aquí mantenemos el ejemplo ajustado.
5. Datos Estructurados / Extracción de JSON
Pon el esquema en el bloque de formato de salida y prohíbe la prosa. Ese es el patrón para conseguir salidas estructuradas fiables.
You extract structured data from raw text. Return ONLY valid JSON,
no prose, no markdown fences.
SCHEMA
{
"company": "string",
"amount_usd": "number",
"date": "YYYY-MM-DD",
"confidence": "low | medium | high"
}
RULES
- If a field is missing from the text, use null.
- Never guess a value to fill a field.
- Output must parse with JSON.parse on the first try.Por qué funciona: un esquema literal más "solo JSON válido" le gana siempre a un formato descrito con palabras. Para patrones de enforcement más allá del prompt (validación de JSON schema, extracción basada en herramientas), consulta nuestra guía de salidas estructuradas.
6. Agente de QA de Contenido / Validador (de nuestro pipeline de producción)
Este corre en nuestro propio stack. El system prompt de nuestro validador es un ejemplo de restricciones negativas: le dice al modelo exactamente qué NO escribir, y luego un script comprueba las reglas de forma literal.
You are a content QA agent. You check one blog draft against a
fixed style contract.
BANNED VOCABULARY (auto-fail on any hit)
delve, leverage, robust, seamless, tapestry, pivotal, elevate,
harness, foster, bolster, paramount, intricate, "in today's",
"when it comes to", "it's worth noting", "game-changer"
FORMAT LIMITS
- Em-dashes: max 3 per 1,000 words of body.
- Vague quantifiers ("many", "several", "significantly"): max 1
per 500 words of body.
ENFORCEMENT
- Do not "write naturally." Check every rule literally.
- A deterministic script (ai_slop_check.py) greps the draft and
exits non-zero on any hit. If it fails, the post does not publish.Por qué funciona: una lista de prohibiciones enumerada más un grep se puede hacer cumplir de una forma que "evita las palabras de moda" jamás logra. El modelo puede discutir con una sensación; no puede discutir con un código de salida distinto de cero.
7. Agente de Traducción (de nuestro pipeline de producción)
También nuestro. El prompt del traductor es un contrato de formato de salida y completitud, con una autoverificación que el modelo aplica sobre su propia salida.
You are an expert translator. You translate ONE blog post into ONE
target language.
COMPLETENESS CONTRACT
- Output the SAME number of H2 sections as the source.
- Line count must land within 80-120% of the source.
- Translate the FAQ fully. Never submit a partial draft.
DIACRITICS SELF-CHECK
- Keep native characters. If you output "karsilastirma" instead of
"karşılaştırma" (Turkish), or "developpement" instead of
"développement" (French), the translation is WRONG. Re-do it.
If you cannot meet the contract, report the problem. Do not ship a
truncated post.Por qué funciona: un contrato de completitud más un ejemplo concreto de salida incorrecta atrapa los fallos silenciosos que una línea vaga como "traduce con precisión" deja pasar.
Lo que Aprendimos Ejecutando System Prompts en Producción
Tres bugs de system prompt en nuestro propio pipeline nos enseñaron más que cualquier página de documentación. Los tres venían de instrucciones que sonaban bien pero no eran específicas ni verificables. Esto es lo que se rompió en nuestros más de 16 subagentes de Claude, y la solución exacta que se mantuvo cada vez. El patrón es siempre el mismo: las reglas blandas se ignoran, las reglas específicas y verificadas externamente se cumplen.
El bug del vocabulario prohibido. Durante semanas el modelo seguía colando leverage y robust en los borradores sin importar cuánto se lo pidiéramos con delicadeza. Una línea blanda del tipo "evita las palabras de moda" no servía de nada. La solución fue el ejemplo #6: una lista de prohibiciones enumerada dentro del prompt más un script que hace grep sobre la salida y sale con código distinto de cero ante cualquier coincidencia, con un tope de em-dash de 3 por cada 1.000 palabras encima. La lección: las restricciones vagas se ignoran; las restricciones enumeradas y verificadas externamente se cumplen.
El bug de las tildes y diacríticos. Nuestro traductor emitía ASCII en silencio en turco, francés y español. karşılaştırma salía como karsilastirma, y nadie se dio cuenta hasta que un hablante nativo lo señaló. La solución fue una tabla de caracteres nativos en el prompt, un ejemplo explícito de salida incorrecta y un grep posterior a cada ejecución (cero caracteres nativos significa volver a traducir). La lección: dale al modelo un ejemplo concreto del fallo, no solo una regla.
El bug del ID estable. Este es el caro. Un system prompt que volvía a derivar el slug localizado en cada re-traducción hacía que el publisher acuñara un segundo documento en vivo por cada post. Publicamos 54 documentos duplicados en vivo el 2026-06-13 y no los despublicamos hasta el 2026-07-05, tres semanas de link equity dividido y marcas de contenido duplicado. La solución: fijar la identidad de forma explícita y reutilizar el ID existente tal cual. Un system prompt que regenera sus propios identificadores de forma no determinista produce duplicados; el nuestro acuñó 54 documentos en vivo antes de que fijáramos el ID.
¿Cuáles Son los Errores Más Comunes en un System Prompt?
Los errores más comunes en un system prompt son instrucciones en forma de muro de texto, reglas contradictorias, redacción solo en negativo, meter contexto específico de cada solicitud dentro de un prompt estático, y saltarse el fallback. En los modelos de 2026 hay uno nuevo: las MAYÚSCULAS agresivas y el lenguaje tipo "DEBES" ahora sobreactivan a Claude Opus 4.5+.
Aquí va la lista rápida de correcciones:
- Muro de texto. Solución: divídelo en los seis bloques y pon el contenido estable primero.
- Instrucciones contradictorias. Solución: una regla por línea; resuelve los conflictos antes de publicar.
- Redacción solo en negativo. Solución: di qué hacer, no solo qué evitar.
- Sobrecarga de MAYÚSCULAS y "DEBES". En los modelos más nuevos de Anthropic esto sale mal. Su documentación ahora dice que donde antes escribías "CRITICAL: You MUST use this tool", puedes usar un lenguaje normal como "Usa esta herramienta cuando." El consejo de 2025 ahora es el error.
- Contexto dinámico en un prompt estático. Mantén los datos específicos de cada solicitud en el turno del usuario. Qué va en cada sitio es una disciplina propia; nuestra guía de context engineering lo cubre.
- Sin fallback. Define siempre un rechazo y una vía de escalado.
- Ignorar la longitud y el coste. Los prompts más largos añaden latencia y coste de tokens en cada llamada; recorta a lo que se gana su lugar.
Para lo básico de la claridad de instrucciones, el artículo de buenas prácticas de OpenAI sigue siendo una lista de verificación sólida.
¿Cómo Pruebas e Iteras un System Prompt?
Prueba un system prompt como pruebas código. Construye un golden set pequeño de entradas con las salidas esperadas, y luego verifica la respuesta del modelo contra ellas en cada cambio. Haz A/B entre dos versiones del prompt sobre las mismas entradas y quédate con la que pasa más comprobaciones. Las aserciones le ganan al ojo humano siempre.
Un eval loop mínimo se ve así:
# pseudo eval loop
for case in golden_set:
out = model(system=PROMPT, user=case.input)
assert is_valid_json(out) # format check
assert case.expected_field in out # content check
if case.no_context:
assert "I don't have that" in out # refusal check
# ship the prompt version that passes the most casesEl grep del ejemplo #6 es la aserción más barata que puedes ejecutar: no cuesta nada y nunca se cansa. Cuando tu biblioteca de prompts crezca más allá de un puñado, versiona y prueba tus prompts con herramientas de gestión de prompts reales en lugar de copiar y pegar entre archivos. La idea es la misma a cualquier escala: nunca cambies un prompt de producción sin una comprobación que te diga si lo mejoraste o lo empeoraste.
System Prompt vs User Prompt vs Developer Message
Un system prompt fija un comportamiento estable; un user prompt lleva la tarea de cada solicitud; un developer message es el rol de los modelos de razonamiento de OpenAI que contiene instrucciones a nivel de aplicación, jerárquicamente por encima de los mensajes de usuario. Anthropic usa un parámetro system de nivel superior en lugar de un mensaje con role: "system". Esta es la división en tres que la competencia suele pasar por alto.
| Capa | Quién la fija | ¿Cambia en cada solicitud? | Mecánica en OpenAI | Mecánica en Anthropic |
|---|---|---|---|---|
| System prompt | El desarrollador de la app | No, es estable | role "system" en messages | parámetro system de nivel superior |
| Developer message | El desarrollador de la app | Rara vez | role "developer" en modelos de razonamiento | se pliega dentro del parámetro system |
| User prompt | El usuario final | Sí, en cada turno | role "user" en messages | role "user" en messages |
OpenAI es explícito sobre la jerarquía: "los developer messages son instrucciones dadas por el desarrollador de la aplicación, con prioridad por encima de los mensajes de usuario". Así que si un usuario intenta anular las reglas de tu app, el developer message gana en la cadena de mando.
¿Necesitan los Modelos de Razonamiento System Prompts Distintos? (2026)
Sí. Los modelos de razonamiento como la serie o de OpenAI, GPT-5 y Claude Opus 4.5+ quieren objetivos de alto nivel, no guiones paso a paso. OpenAI compara un modelo de razonamiento con un compañero senior en quien confías los detalles, frente a un modelo GPT que se comporta como un junior que necesita instrucciones explícitas.
Ese planteamiento cambia cómo escribes el prompt. Para un modelo de razonamiento, plantea el objetivo y las restricciones y "confía en que resolverá los detalles"; para un modelo GPT, detalla los pasos. Sobre-especificar a un modelo de razonamiento suele empeorarlo, no mejorarlo.
El lado de Claude tiene su propio cambio en 2026. Como Opus 4.5+ responde más al system prompt, la vieja costumbre de apilar CRITICAL: y MUST ahora lo sobreactiva. Baja ese lenguaje a un tono normal. Una nota sobre coste: pon tu contenido estable y reutilizado al principio del prompt para que el prompt caching entre en juego y recorte la latencia en las llamadas repetidas. Y si tu modelo de razonamiento hace trabajo paso a paso, el chain-of-thought prompting es un tema aparte con su propia guía, así que no lo repetimos aquí.
Cómo Techsy Aborda los System Prompts
En Techsy construimos sistemas de agentes para clientes B2B, y los prompts del validador y del traductor que viste arriba corren en ese mismo stack de producción. Tratamos cada system prompt como código: lo versionamos, lo probamos contra un golden set, y hacemos cumplir las reglas no negociables con un script en lugar de esperar que funcione. Si estás moviendo una función de LLM de una demo a producción y quieres una mano con el trabajo de integración de IA, pide una consultoría gratuita.
Sobre el Autor
Mert Batur es Cofundador de Techsy.io, donde el equipo entrega agentes de IA, sistemas de automatización y pipelines de voz/SDR para clientes B2B. Escribe sobre el stack de herramientas LLM que el equipo de Techsy realmente usa en producción.
Credenciales: Cofundador, Techsy.io. Conecta en LinkedIn.
Preguntas Frecuentes
¿Qué es un system prompt?
Un system prompt es un conjunto de instrucciones persistentes que se fijan una sola vez, antes de cualquier mensaje del usuario, y que definen el rol, el comportamiento, las restricciones y el formato de salida del modelo durante toda la sesión. Es la capa fija de "cómo se comporta", y permanece idéntica mientras los mensajes del usuario, específicos de cada solicitud, cambian en cada turno.
¿Cuál es la diferencia entre un system prompt y un user prompt?
El system prompt es el "cómo se comporta" fijo, idéntico en cada solicitud; el user prompt es el "qué hacer" específico de cada solicitud. Una regla simple: si el contenido sería idéntico en 1.000 solicitudes, pertenece al system prompt, y todo lo que cambia en cada llamada va en el turno del usuario.
¿Qué es un developer message frente a un system prompt?
Los modelos de razonamiento de OpenAI (serie o, GPT-5) reciben un mensaje developer en lugar de un mensaje system. Contiene instrucciones a nivel de aplicación con prioridad por encima de los mensajes de usuario en la cadena de mando, así que gana si un usuario intenta anular tus reglas. Anthropic mantiene un único parámetro system de nivel superior en lugar de un mensaje basado en roles.
¿Qué tan largo debe ser un system prompt?
Tan corto como sea posible sin dejar de cubrir el rol, las restricciones, el formato de salida y los guardrails. Los prompts demasiado largos añaden coste de tokens y latencia en cada llamada, y pueden sobreactivar razonamiento extra en Claude Opus 4.5+. Si un prompt estable tiene que ser largo, pon el contenido reutilizado primero para que el prompt caching compense el coste.
¿Los system prompts funcionan igual en ChatGPT/GPT y en Claude?
Mismo concepto, mecánica distinta. OpenAI usa un rol system o developer dentro del array de messages, mientras que Anthropic usa un parámetro system independiente de nivel superior y prefiere etiquetas XML para separar instrucciones, contexto y ejemplos. Las instrucciones se trasladan entre proveedores; el cableado y las convenciones de formato no.
¿Se puede cambiar el system prompt a mitad de conversación?
A través de la API reenvías el payload completo de messages en cada llamada, así que técnicamente puedes cambiar el system prompt entre turnos. Pero cambiarlo a mitad de conversación puede romper la continuidad y confundir al modelo sobre sus propias reglas. Es preferible fijarlo una sola vez, o cambiarlo de forma deliberada por un prompt distinto y específico para una tarea concreta.
¿Debería usar etiquetas XML o markdown en un system prompt?
Anthropic recomienda etiquetas XML para Claude, para separar instrucciones, contexto y ejemplos y que el modelo no los mezcle. Los modelos de OpenAI manejan bien markdown y encabezados simples. Ajústate a la convención de cada proveedor en lugar de forzar un solo estilo en ambos, y mantén consistente el que elijas dentro de un mismo prompt.
¿Necesitan los modelos de razonamiento system prompts distintos?
Sí. Los modelos de razonamiento quieren objetivos de alto nivel, como al dar un briefing a un compañero senior, no microgestión paso a paso. Descarta las MAYÚSCULAS agresivas y el lenguaje tipo "DEBES" que sobreactivan a modelos más nuevos como Claude Opus 4.5+, plantea el objetivo y los guardrails, y deja que el modelo planifique el camino para llegar ahí.
¿Cuáles son las partes de un buen system prompt?
Seis bloques: rol, contexto, restricciones, formato de salida, guardrails o fallbacks, y opcionalmente un par de ejemplos. El rol y las restricciones hacen la mayor parte del trabajo; el bloque de formato de salida es lo que hace que las respuestas sean parseables; los guardrails definen qué pasa en los bordes. Los ejemplos vale la pena añadirlos solo cuando la calidad objetivo es difícil de describir con palabras.