Skip to main content

Style Guide de prompting: la vara que un prompt pasa antes de salir

Las reglas con opinión que Cleon aplica a cada prompt — la primera decisión (prompt, ground o fine-tune), la vara de calidad que un prompt pasa antes de salir, y cómo componemos Agentforce Prompt Templates y la Claude API según dónde corre el prompt en lugar de elegir bando. El documento de disciplina que convierte los gotchas de prompting en una compuerta y los principios en práctica, tratando al prompt como contexto de ingeniería, no como un string que ajustás a ojo.

Marco de decisión·Actualizado 2026-06-03·Escrito por Lira · Editado por German Medina

Esta es la página donde Cleon deja de describir qué es un prompt y dice qué hacemos antes de que uno salga. Las páginas de referencia exponen las partes — qué es context engineering, los system prompts e instrucciones que dirigen al modelo, el structured output que un sistema consume, el context window que cada llamada gasta y el prompt caching que hace asequible uno estable. Los gotchas exponen dónde muerde cada parte. Este Style Guide es la disciplina que decide si recurrir a un prompt siquiera, y la vara que tiene que pasar antes de que su salida toque a un cliente o un registro.

Las reglas son cortas a propósito. Cuando una regla necesita explicación, la explicación vive en la página que enlaza. Esta es la forma operativa de los principios de AI Engineering — cada regla de abajo es uno de esos principios con las mangas arremangadas, y citamos el número para que puedas rastrear la regla hasta su razonamiento. Es la compañera del lado del prompt del Style Guide de agentes y del Style Guide de grounding: un agente corre sobre prompts y lee el mundo a través del retrieval, así que las tres varas se encuentran acá, en la ventana.

La primera decisión: ¿prompt, ground o fine-tune?

Antes que todo lo demás, ubicá el problema en la palanca correcta. La mayoría de lo que parece "el modelo se equivocó" no es un problema de modelo en absoluto — es un problema de contexto, y el arreglo más barato casi siempre es hacer ingeniería de la ventana antes de tocar algo más pesado (principio 12 — empezá por el problema). Las tres palancas, en el orden en que se recurre a ellas:

  • Prompt primero. El default para casi toda tarea: dale forma al contexto que el modelo ve — el system prompt, las instrucciones, los ejemplos, el orden — y la mayoría de los bugs de "respuesta incorrecta" desaparecen, porque nunca fueron culpa del modelo (ver qué es context engineering). Hacé ingeniería de la ventana antes que nada; es la palanca más rápida y barata, y la que la mayoría de los problemas realmente necesitan.
  • Ground cuando la respuesta depende de hechos que el modelo no tiene. Si la respuesta correcta gira sobre tus datos — un registro, la política de este trimestre, un documento escrito la semana pasada — o sobre algo que cambia, ninguna astucia de prompt conjura el hecho; hay que recuperarlo (ver qué es grounding). El prompting dirige al modelo sobre hechos que puede alcanzar; el grounding es cómo el hecho llega a su alcance. Otra palanca, preguntada por separado.
  • Fine-tune rara vez, y al final. La tercera palanca conceptual: hornear el comportamiento en los pesos del modelo en lugar de en su contexto. Recurrí a ella solo para una tarea estrecha, de alto volumen, sensible a latencia o costo, donde prompting y grounding se hayan agotado de verdad — y sabé qué estás comprando. Es cara de hacer, envejece con tus datos en el momento en que esos datos se mueven, y casi nunca es el primer movimiento. Preferí prompt-y-después-ground; tratá al fine-tuning como la excepción que justificás, no el reflejo al que recurrís.

La vara de calidad del prompt

Un prompt que sale está estructurado para la prominencia, forzado en su forma de salida, defendido contra el texto no confiable en su ventana, ordenado para que el modelo pondere lo que importa, puntuado en cada cambio y presupuestado en costo — o es un prompt que funcionó una vez en el playground y todavía no conoció un input que vos no escribiste (principio 1). Antes de que la salida de este prompt toque a un cliente o un registro, confirmá cada casilla. Cada una cierra un gotcha que convirtió un demo limpio en un prompt que rompe con confianza.

  • [ ] Instrucciones claras, directas y estructuralmente prominentes. Las restricciones duras están sacadas de la prosa — en su propia línea o sección, dichas una vez y con claridad — no en la oración número once de un párrafo denso esperando que la noten. (Principio 10 · gotcha 1.)
  • [ ] Ejemplos donde la forma de la tarea es difícil de describir. Cuando un tono, un caso límite o un estilo de salida se resiste a la prosa, unos pocos ejemplos trabajados (few-shot) lo cargan — y cubren los casos difíciles, no solo repiten el fácil que el modelo ya hace bien. (Principio 10 · gotcha 4.)
  • [ ] Salida estructurada y validada cuando un sistema la consume. Cuando la salida alimenta un parser, un Flow o el siguiente paso en vez de un humano, la forma es un contrato — pedida como un schema y validada, nunca prosa que raspás con un regex. (Principio 8 · gotchas 2, 7.)
  • [ ] Texto no confiable separado de las instrucciones. Cada chunk recuperado, mensaje de usuario o documento pegado en la ventana está delimitado y etiquetado como dato, separado estructuralmente de tus directivas — y lo que un documento dice nunca expande lo que el modelo tiene permitido hacer. (Principio 5 · gotcha 5.)
  • [ ] La instrucción o el hecho clave ubicado donde el modelo lo pondera. Lo que más importa va cerca del principio o del final, no varado en el medio de una ventana larga donde se lee pero se subpondera. (Principio 10 · gotcha 6.)
  • [ ] Un fallback determinista cuando la salida es inválida. Cuando la validación falla o el modelo devuelve algo inusable, dispara un camino determinista y aburrido — nunca un blanco, un string de error o una alucinación renderizada frente a alguien. (Principio 8 · gotcha 2.)
  • [ ] El prefijo estable estructurado para el cache. El contenido que no cambia — system prompt, definiciones de herramientas, ejemplos fijos — va primero y el input por request al final, para que el prompt caching pueda cubrir un prefijo contiguo en vez de romperse por un token variable temprano. (Principio 6 · gotcha 10.)
  • [ ] Cada cambio de prompt puntuado contra un eval set antes de salir. El prompt es el artefacto más editado del sistema; una edición tiene que puntuar mejor sobre casos reales, no solo verse mejor en el único input que probaste, antes de salir. (Principio 3 · gotchas 8, 9.)

Si alguna casilla está sin marcar, el prompt no está listo — y una falla de prompt se ve exactamente como una respuesta correcta hasta que alguien aguas abajo actúa sobre ella. Mirá debugging de prompts para encontrar la capa que falla cuando un prompt sale mal en lugar de adivinar las palabras.

Componiendo el toolkit

La misma disciplina de prompting viaja entre superficies. Es un solo oficio aplicado en dos lugares, compuesto según dónde corre el prompt — no bandos rivales entre los que elegís (principio 7). La vara de arriba es idéntica en ambos; solo difiere la superficie que carga el prompt.

  • Agentforce Prompt Templates cuando el prompt corre on-platform. Prompt Builder es donde se escribe el template, se hace grounding vía merge fields, Flow o Apex, y corre dentro del modelo de seguridad de Salesforce — las mismas instrucciones, gobernadas por la plataforma, actuando sobre datos que el usuario que corre tiene permitido ver. Ver agentes Agentforce.
  • La Claude API cuando el prompt corre off-platform. La estructura system/messages, los structured outputs y el prompt caching son la superficie acá — el mismo oficio de dirigir, dar forma y presupuestar la ventana, gobernado por vos. Ver prompt caching para la palanca de costo y structured output para el contrato.

Mismo oficio, distinta superficie: una restricción dicha una vez y hecha prominente es la jugada correcta ya sea que aterrice en un template de Prompt Builder o en un system prompt de Claude. La única decisión que esta página no posee es la llamada de superficie Agentforce vs. AI externa dentro de Marketing Cloud — ese es otro framework, y vive completo en el Style Guide de AI de Marketing Cloud.

Patrones a preferir

  • Estructura sobre volumen — sacá la restricción a su propia línea y hacela prominente, en lugar de agregar otra oración a un muro de texto y esperar que la noten. Más prompt no es más control. (Principio 10 · gotchas 1, 3.)
  • Ejemplos sobre explicación — cuando la forma de la tarea se resiste a la descripción, mostrá dos o tres ejemplos trabajados que cubran los casos difíciles en vez de escribir otro párrafo que igual no transfiere. (Principio 10 · gotcha 4.)
  • Structured output sobre parsear prosa — cuando un sistema consume la salida, pedí un schema y validalo, en vez de raspar estructura de una oración con un regex. (Principio 8 · gotchas 2, 7.)
  • Eval en cada cambio — puntuá una edición contra casos reales antes de que salga, y volvé a puntuar cuando cambia la versión del modelo; un cambio de modelo es un cambio para testear, no un upgrade gratis. (Principio 3 · gotchas 8, 9.)
  • Cachear el prefijo estable — ordená el contenido que no cambia primero para que el prompt caching lo cubra, y dejá de re-pagar por reprocesar los mismos tokens iniciales en cada llamada. (Principio 6 · gotcha 10.)
  • Separar el texto no confiable — delimitá y etiquetá cada chunk, mensaje o documento que no escribiste, y mantené tus directivas fuera de ese límite. (Principio 5 · gotcha 5.)

Patrones a rechazar

  • Reescribir el prompt entero por una corazonada — el golpe que "se ve mejor" en un input es una conjetura sin puntuar; cambiá una cosa, puntuala, quedate con lo que gana. (Gotcha 9 · principio 3.)
  • Apilar reglas hasta que se contradigan — cada falla pasada atornillada como un "siempre" o "nunca" más hasta que la tarea se ahoga y nadie puede decir qué instrucción produjo qué comportamiento. (Gotcha 3 · principio 10.)
  • Parsear prosa para un contrato — construir un regex para raspar un campo de una oración es reinventar, mal, una funcionalidad que el modelo ya soporta. (Gotcha 7 · principio 8.)
  • Prefill en modelos nuevos — prellenar el turno del asistente para forzar una forma no es la técnica; está sin soporte en los modelos Claude nuevos. Usá Structured Outputs o tool calling en su lugar. (Ver structured output · gotcha 2.)
  • Sacar un cambio de prompt sin puntuar — "se veía bien en tres intentos" es una sensación, no un test, y la regresión sale en silencio junto al arreglo. (Gotcha 9 · principio 3.)
  • Un preámbulo estático gigante reenviado sin cache — la respuesta correcta a una cuenta de tokens que escala lineal con el tráfico y nunca tuvo que hacerlo, porque el prefijo estable nunca se cacheó. (Gotcha 10 · principio 6.)

Cierre

Ninguna de estas reglas es difícil de aplicar de entrada; todas son caras de descubrir en vivo, porque un bug de prompt se ve exactamente como una respuesta correcta hasta que alguien chequea. El hilo conductor es el que recorre cada página de esta subcategoría: el playground hace que el camino fácil parezca todo el camino, y producción es todo lo que el camino fácil dejó afuera. El prompt es el artefacto más editado de un sistema de AI y normalmente el menos testeado — tratalo como contexto de ingeniería, no como un string que ajustás a ojo, y la vara de arriba es cómo nos aseguramos de que el prompt que sacamos aguante bajo un input que el demo nunca mostró.

Si ves una regla que falta — o una de estas reglas siendo violada en nuestro trabajo público — escribí a hello@wearecleon.com. La agregamos, o la arreglamos y lo decimos.

Related

Reference: