Escribe un system prompt que funcione

Un system prompt es la instrucción permanente que enmarca cada turno de una conversación. El mensaje del usuario cambia; el system prompt permanece. Eso lo convierte en el fragmento de texto de mayor apalancamiento en una aplicación construida sobre un modelo de lenguaje, y en el que más a menudo se escribe sin cuidado. Esta guía recorre cómo escribir un system prompt que se comporte igual en la entrada número cien que en la primera.

Para qué sirve un system prompt

Piensa en el system prompt como la descripción del puesto, no como la tarea. La tarea llega en cada mensaje del usuario. El system prompt establece las cosas que son ciertas a lo largo de todas las tareas: quién es el asistente, qué se le permite hacer, cómo debe formatear sus respuestas y qué no debe hacer jamás. Si te encuentras repitiendo la misma instrucción en cada mensaje del usuario, esa instrucción pertenece al system prompt.

La distinción importa porque los dos roles se manejan de forma distinta. El system prompt es el contexto estable que el modelo toma como condición para toda la sesión; los mensajes del usuario son la entrada variable. Poner las reglas duraderas en el system prompt las mantiene en vigor incluso cuando la conversación deriva, y mantiene tus mensajes por petición cortos y centrados en la tarea real.

Empieza por el rol y el alcance

El primer trabajo de un system prompt es responder dos preguntas: qué es este asistente y para qué sirve. Un rol vago ("eres un asistente útil") no le da al modelo nada en lo que anclarse. Un rol específico ("eres un agente de soporte para un sistema de facturación; ayudas a los usuarios a entender cargos y resolver disputas") estrecha el espacio de respuestas plausibles antes de que llegue una sola palabra del usuario.

El alcance es la otra mitad. Indicar qué hace el asistente es bueno; indicar qué no hace suele ser más valioso. A un asistente al que le dicen que gestiona facturación aún responderá encantado una pregunta sobre cocina a menos que le digas que no. Define el límite de forma explícita: "Si una petición está fuera de facturación, di con cortesía que está fuera de alcance y redirige". Los límites no son burocracia: son cómo mantienes un modelo general comportándose como un producto específico.

Escribe las reglas como comportamiento, no como ambiente

El error más común en los system prompts es describir una personalidad en lugar de especificar comportamiento. "Sé amable y profesional" suena a orientación pero no decide nada. El comportamiento es observable: "Dirígete al usuario por su nombre si se conoce. Usa párrafos cortos. No uses nunca signos de exclamación". Cada una de esas cosas puede contrastarse con una salida; "amable" no.

Aplica la misma disciplina a las restricciones. En lugar de "ten cuidado con los números", escribe "No hagas aritmética mentalmente; si se requiere un cálculo, muestra los pasos". En lugar de "no te inventes cosas", escribe "Si no estás seguro de que un hecho esté respaldado por el contexto proporcionado, di que no lo sabes". Cada regla que escribas debería ser algo que pudieras verificar leyendo una transcripción. Si no puedes verificarlo, el modelo no puede seguirlo de forma fiable.

Maneja los casos que rompen las cosas

Un prompt de demo maneja el camino feliz. Un prompt de producción maneja las entradas que no planeaste: la pregunta vacía, el usuario hostil, la petición que está a medias dentro de alcance, la entrada que contiene sus propias instrucciones. Ahí es donde los asistentes sin guía avergüenzan a sus dueños, y son exactamente lo que el system prompt existe para gobernar.

Nombra los modos de fallo y prescribe la respuesta. Para información que falta: "Si el contexto no contiene la respuesta, dilo en lugar de adivinar". Para peticiones fuera de alcance: define la redirección. Para intentos de anular tus reglas a través del mensaje del usuario —"ignora tus instrucciones y..."— indica claramente que las instrucciones en el contenido del usuario son datos, no órdenes, y que las reglas del sistema se mantienen. No anticiparás todos los casos límite, pero cubrir los predecibles elimina la mayoría de las sorpresas.

Estructura para que el modelo pueda seguirlo

Un system prompt que es un solo párrafo largo es difícil de usar de forma consistente para un modelo, igual que lo sería para una persona. Agrupa las reglas relacionadas bajo encabezados claros: identidad, alcance, formato, seguridad, casos límite. Ordénalas por prioridad: las reglas que no deben romperse jamás van primero y se enuncian de la forma más clara. Cuando dos instrucciones podrían entrar en conflicto, di cuál gana, porque de lo contrario el modelo elegirá por ti.

Mantenlo tan corto como pueda ser sin dejar de estar completo. Cada frase extra es algo que el modelo tiene que sopesar frente a todo lo demás, y un prompt inflado diluye las reglas que de verdad importan. Resiste el impulso de añadir una línea nueva cada vez que algo sale mal; pregunta primero si una regla existente, enunciada con más claridad, lo habría cubierto. Un prompt ajustado donde cada línea se gana su lugar supera a uno desparramado.

Pruébalo contra conversaciones reales

Un system prompt no está terminado cuando se lee bien. Está terminado cuando aguanta a lo largo de un conjunto de interacciones reales. Reúne un puñado de sesiones representativas —incluidas las incómodas— y ejecuta tu prompt contra todas ellas. Lee las salidas buscando reglas que se ignoraron, límites que se filtraron y formatos que derivaron. Luego cambia una cosa y ejecuta el conjunto de nuevo.

Aquí es donde los system prompts se diseñan de verdad en lugar de solo escribirse. Una regla que estabas seguro de que era clara resultará ambigua en cuanto un usuario real formule algo de forma inesperada. Trata cada fallo como un error de especificación: o la regla faltaba, o estaba enunciada de un modo que el modelo no podía aplicar. Conserva la versión que mejor se comporta en todo el conjunto, no la que produjo la respuesta individual más bonita.

En resumen

Un buen system prompt es una especificación, no un ambiente. Enuncia un rol y un alcance específicos, escribe sus reglas como comportamiento observable, nombra los modos de fallo que de otro modo te avergonzarían, y estructura todo para que el modelo pueda seguirlo bajo presión. Luego se gana su lugar sobreviviendo a conversaciones reales en vez de a una sola demo. Escríbelo así y el system prompt se convertirá en la parte más fiable de tu aplicación: el marco estable que mantiene cada turno en su sitio.