System prompts e instructions: dirigir el modelo a propósito | Cleon

Un modelo capaz con una instrucción vaga es un empleado inteligente al que le pasaste un brief de una línea y lo dejaste adivinar el resto. Va a hacer algo — con fluidez, con seguridad, y solo a veces lo que querías. El arreglo no es un modelo más fuerte; es escribir a propósito la parte de la dirección del contexto. Esta página es sobre esa parte: el system prompt y las instructions que le dicen al modelo quién es y qué está haciendo, y las técnicas que confiablemente lo mantienen en tarea. Las instrucciones vagas son la causa más grande de un modelo que se va por las ramas — la misma lección que el lado nativo de la plataforma aprende a través de las Instructions de Agentforce (mirá Agentforce agents), acá al nivel del prompt crudo.

Esto es una referencia, no una receta. Las técnicas de abajo son las que aguantan a través de tareas; cuáles necesita una tarea dada, y cuánto, lo decide un set de eval (principio 3 — si no lo podés evaluar, no lo podés lanzar). El hilo común debajo de todas: la estructura le gana al volumen. Más reglas no es más control.

El system prompt y el user turn

La mayoría de las APIs de modelos separan dos tipos de input: el system prompt y el user turn. No son intercambiables, y vale la pena entender la diferencia antes que cualquier técnica.

El system prompt es donde armás el marco durable — como quién está actuando el modelo, para qué sirve, qué no tiene que hacer, y la forma que toman sus respuestas. Es la instrucción permanente que aguanta a través de cada turno de una conversación. El user turn es el pedido específico de esta vez — la pregunta, el documento, la instancia de la tarea. La división mapea limpia: la dirección estable va en el system prompt, el input variable va en el user turn. El contenido de system arma una base fuerte y consistente para el comportamiento justamente porque no se vuelve a litigar en cada mensaje; es el marco al que llega el pedido del usuario.

Poner la dirección en el lugar equivocado es un error común y silencioso. Enterrá el role y las reglas dentro de cada mensaje del usuario y las repetís para siempre, derivás entre fraseos, y diluís el pedido alrededor del que las envolviste. Subilas al system prompt una vez y cada turno hereda el mismo marco gratis.

Anatomía del system prompt

Un system prompt que aguanta tiene cuatro partes. Nombralas y podés debuggear un modelo que se va por las ramas preguntando cuál parte está floja.

Role — como quién está actuando el modelo. "Sos un asistente de soporte para un producto de facturación B2B" no es adorno; fija el registro, el conocimiento asumido, y los defaults de todo lo que viene después. Un modelo sin role asume uno genérico y responde como el internet abierto.
Task — qué está haciendo, en concreto. No "ayudá al usuario" sino "respondé preguntas de facturación desde el registro de cuenta recuperado, y resolvé disputas hasta el límite de tus instructions". La task es la columna de la que cuelga el resto.
Límites — qué no tiene que hacer, y cuándo derivar. Los rechazos, los temas fuera de alcance, el punto en el que frena y rutea a un humano. Es la misma disciplina que los límites de un agente — un modelo sin bordes declarados trata cada pedido como dentro de alcance (se ata al principio 8: la no-determinación necesita una compuerta humana donde da a la cara del cliente).
Formato de salida — qué forma toma la respuesta. Una oración, un objeto JSON, una lista con bullets, una estructura específica. Declararlo acá es la diferencia entre una respuesta que podés parsear y una con la que tenés que pelear (la mecánica completa es su propia página — structured output).

Estas cuatro son un checklist, no un template fijo. El punto es la cobertura: un prompt al que le faltan los límites produce un modelo que nunca declina; uno al que le falta el formato de salida produce respuestas con una forma distinta cada vez.

Ser claro y directo — y decir por qué

El arreglo de prompting de mayor frecuencia es el menos ingenioso: decí exactamente lo que querés, en instrucciones simples, y contale al modelo por qué la regla importa. Lo explícito le gana a lo implícito, y lo directo le gana a lo recargado. A un modelo no se lo premia por leer entre líneas — una instrucción que tiene que inferir es una que puede inferir mal.

Dos movidas cargan la mayor parte de esto.

Ser claro y directo. Preferí un imperativo simple — "respondé en dos oraciones", "no menciones precios", "citá el registro que usaste" — por sobre una pista que el modelo tiene que decodificar. El fraseo vago ("sé útil y conciso") deja al modelo adivinar qué significa conciso acá, y adivina distinto en cada corrida. Precisión en la instrucción es precisión en la salida.
Dar contexto y motivación. Decirle al modelo por qué existe una regla mejora de forma medible qué tan bien la sigue. "No des asesoramiento legal — no sos abogado y una respuesta equivocada acá tiene consecuencias reales para el usuario" aguanta mejor que el escueto "no des asesoramiento legal", porque ahora el modelo puede generalizar la intención a casos que tu regla no enumeró. El porqué convierte una lista frágil de qué-hacer y qué-no en algo desde lo que el modelo puede razonar.

Esta es la misma falla que la página de Agentforce agents nombra desde el lado de la plataforma: las Instructions vagas son la causa número uno de un agente que se va de la tarea. Al nivel del prompt crudo la cura es idéntica — instrucción explícita, motivación declarada.

Few-shot: mostrar, no solo contar

Para cualquier tarea con una forma consistente, la técnica de mayor leverage es el prompting few-shot (también llamado multishot): incluí un par de ejemplos trabajados de input→output dentro del prompt mismo. Los ejemplos hacen lo que a la prosa le cuesta — fijan formato y razonamiento a la vez, por demostración en vez de descripción. Un modelo al que le mostrás dos ejemplos de la salida exacta que querés la va a igualar mucho más confiablemente que uno al que se la pedís con palabras.

Los ejemplos se ganan el lugar más rápido en tareas donde la forma de una buena respuesta es difícil de describir pero fácil de mostrar — un formato de extracción particular, un estilo de la casa para un resumen, una clasificación con casos límite no obvios. Dos o tres ejemplos bien elegidos suelen rendir más que párrafos de instrucción, porque el modelo generaliza desde la demostración en vez de parsear una especificación. Mantené los ejemplos representativos (cubrí los casos que varían, incluido uno complicado) y consistentes (cada ejemplo obedece el formato que estás pidiendo — un ejemplo inconsistente enseña inconsistencia).

# Un par de ejemplos trabajados fijan el formato que la prosa solo puede gesticular.

Input: "Me cobraron la tarjeta dos veces por la factura 4471."
Output: { "category": "duplicate_charge", "invoice": "4471", "needs_human": true }

Input: "¿Cómo descargo el recibo del mes pasado?"
Output: { "category": "self_service", "invoice": null, "needs_human": false }

Fijate que el segundo ejemplo lleva un null y un false — está ahí justamente para mostrar la forma cuando faltan campos, algo que un único ejemplo del camino feliz dejaría al modelo adivinar.

Chain-of-thought: lugar para razonar

Para análisis y trabajo de varios pasos — cualquier cosa donde la respuesta depende de una cadena de razonamiento, no de una búsqueda — dale al modelo lugar para razonar antes de responder. Esto es el prompting chain-of-thought: "pensá paso a paso", un conjunto de pasos guiados para recorrer, o una sección de razonamiento dedicada que el modelo llena antes de su respuesta final. Razonar en voz alta mejora de forma medible la precisión en tareas de matemática, lógica y múltiples restricciones, porque el modelo trabaja el problema en vez de saltar a una conclusión.

Un punto hay que decirlo con exactitud, porque el encuadre es fácil de equivocar: un modelo no puede pensar en privado. Su "razonamiento" son solo más tokens de salida — texto que genera camino a la respuesta. No hay un borrador oculto en el que calcula y después descarta. Así que el chain-of-thought solo ayuda cuando al razonamiento se le permite ser salida. Pedirle a un modelo "pensá con cuidado pero mostrame solo la respuesta final" no te da ni el beneficio del razonamiento ni una forma de chequearlo — le dijiste que haga la parte útil y después la tire. Si querés la ganancia de precisión del razonamiento, dejá que el razonamiento aterrice en la respuesta; si no lo querés ensuciando la respuesta final, separalo en vez de suprimirlo.

La forma limpia de separar el razonamiento de la respuesta es darle a cada uno su propia sección con tags, mantenida en un bloque cercado para que los signos de mayor/menor queden afuera de la prosa:

Pensá paso a paso dentro de tags <thinking>, después dá tu respuesta final
dentro de tags <answer>. Solo el contenido de <answer> se le muestra al usuario.

<thinking>
... el modelo trabaja el problema acá, y esto es salida real, no oculta ...
</thinking>
<answer>
... la respuesta final, de cara al usuario ...
</answer>

Ese patrón conserva la ganancia de precisión (el razonamiento se produce de verdad) mientras deja que tu código muestre río abajo solo la sección <answer>. Es honesto sobre la mecánica: el pensamiento es salida que elegís ocultarle al usuario, no pensamiento que el modelo hizo en secreto.

Decomposition: encadená los prompts

Algunas tareas son demasiado grandes para que un prompt las haga bien. Un pedido que junta tres trabajos distintos — extraer, después transformar, después formatear — en una sola instrucción tiende a hacer cada uno peor que un prompt enfocado solo en él, porque el modelo parte su atención y el conjunto de instrucciones se infla. El arreglo es decomposition, también llamado prompt chaining: partí la tarea en prompts más chicos, cada uno haciendo una cosa, y alimentá la salida de uno al siguiente.

Una cadena cambia un poco de orquestación por mucha confiabilidad. Cada paso ahora es lo bastante simple como para instruirlo con precisión y evaluarlo por su cuenta, y una falla queda localizada en un eslabón en vez de embarrada a lo largo de un monolito. Esta es la forma determinista de la página de orchestration patterns vista desde el lado del prompting — una cadena es una secuencia fija que vos controlás, distinta de entregarle el trabajo entero a un agente y esperar que secuencie los pasos solo. Cuando un único prompt está forzándose a sostener demasiadas instrucciones, descomponerlo suele ser la movida antes de ir por algo más elaborado.

La disciplina, redicha

Las técnicas difieren, pero la regla debajo de todas es una oración: cada cambio a un prompt se puntúa contra un set de eval, no se mira a ojo (principio 3). "Se lee mejor" no es una medición — una instrucción que suena más clara puede bajar la precisión en silencio, un ejemplo de más puede tirar al modelo hacia la forma equivocada, y no vas a saber cuál sin un conjunto de casos que lo puntúe. La otra mitad de la disciplina es que la estructura le gana al volumen: a un modelo lo dirige la saliencia y el orden de lo que le decís, no la cantidad pura, y pasado un punto más reglas diluyen las que importan (principio 10 — el contexto es un presupuesto, no un balde). Así que la pregunta antes de agregar otro párrafo a un prompt es la misma siempre — ¿muestra el eval que esto se gana el lugar, y está puesto donde el modelo de verdad lo va a pesar? Acertá eso y el prompt queda chico y afilado. Equivocate y hacés crecer una pared de instrucciones que nadie puede cambiar. (Mirá prompting gotchas para las formas en que esto sale mal en producción, y what is context engineering para dónde se sienta la dirección dentro de todo el contexto que ve el modelo.)

What is context engineering — dónde se sienta el system prompt dentro de todo el contexto sobre el que razona el modelo
Structured output — la parte del formato de salida del prompt, hecha para que puedas parsear el resultado
Prompting gotchas — los modos de falla, incluidas las instrucciones vagas y el razonamiento suprimido
Agentforce agents — Instructions que dirigen el comportamiento, la forma nativa de la plataforma de esta disciplina
Orchestration patterns — dónde una cadena de prompts se vuelve la forma determinista en un sistema de agentes
Grounding gotchas — la dirección de arriba groundea el modelo; esto es lo que pasa cuando el grounding está mal
Prompting Style Guide — the bar a prompt clears before it ships
Debugging prompts — isolate the variable, then fix
AI Engineering principles — evaluá antes de lanzar (3), la no-determinación necesita una compuerta humana (8), el contexto es un presupuesto (10)

Reference: