Ya has escrito el mismo prompt de atención al cliente diecisiete veces. Nombres diferentes, misma estructura. Claude maneja la variación bien, pero estás perdiendo tiempo en repeticiones y la inconsistencia se está infiltrando.
Una biblioteca de plantillas de prompts soluciona esto. No un documento lleno de ejemplos genéricos. Un enfoque sistemático para capturar patrones que realmente usas, versionarlos y llevarlos a producción sin romper lo que ya está funcionando.
¿Qué es Realmente una Biblioteca de Plantillas?
Una biblioteca de plantillas es una colección de patrones de prompts controlada por versiones, organizada por caso de uso, con entradas, salidas claras y modos de fallo conocidos documentados junto a ella. Es la diferencia entre «Tengo un buen prompt» y «Tengo un patrón probado que puedo modificar con confianza».
La mayoría de las bibliotecas de plantillas fallan porque se tratan como colecciones de recetas: bonitas pero desconectadas de cómo trabajas realmente. Una biblioteca funcional es más pequeña, más concisa y se basa en tres cosas: las tareas específicas que tu negocio ejecuta repetidamente, las entradas variables que esas tareas necesitan y las configuraciones del modelo que funcionan para cada una.
Empieza con tus Prompts Reales
Audita lo que ya estás haciendo. No diseñes plantillas en el vacío.
Busca prompts que hayas escrito más de una vez. Extrae el patrón, identifica las variables y documenta lo que falla. Si estás escribiendo prompts para la clasificación de consultas de clientes, anota el modelo que usaste (Claude Sonnet 3.5 vs. GPT-4o importa), la configuración de temperatura y el recuento máximo de tokens que mantuvo la salida consistente.
Aquí tienes un ejemplo real de un flujo de trabajo de soporte SaaS:
# Versión mala — prompt único
Clasifica este mensaje del cliente:
{inquiry}
Responde con: categoría, sentimiento, prioridadEsto funciona a veces. Pero lo has escrito de cuatro maneras diferentes en tu base de código, la temperatura varía entre 0.3 y 0.7, y una versión pide explícitamente JSON mientras que otra no. Cuando necesitas reentrenar a un miembro del equipo o entregar a otro desarrollador, no hay una única fuente de verdad.
# Versión mejor — plantilla con estructura clara
{{
"template_name": "customer_inquiry_classifier_v2",
"model": "claude-3-5-sonnet-20241022",
"temperature": 0.3,
"max_tokens": 256,
"system_prompt": "Eres un agente de triaje de atención al cliente. Clasifica las consultas por gravedad y tipo. Sé consistente en la categorización.",
"user_template": "Clasifica este mensaje del cliente y responde ÚNICAMENTE con JSON válido:\n\nMensaje: {inquiry}\n\nResponde con JSON: {{"category": ..., "sentiment": ..., "priority": ...}}",
"output_format": "json",
"known_issues": "La clasificación de sentimiento falla el 15% de las veces en mensajes sarcásticos. La prioridad ocasionalmente cambia a CRÍTICA para solicitudes urgentes educadas."
}}Ahora tienes una referencia. La temperatura está bloqueada. El modelo está nombrado. Los modos de fallo están documentados. Eso es una plantilla.
Estructura tu Biblioteca por Tarea, No por Herramienta
Organiza las plantillas por lo que hacen, no por qué modelo las ejecuta. Una plantilla de clasificación, una plantilla de extracción, una plantilla de resumen: esas son tus categorías. Dentro de cada una, puedes tener múltiples versiones (diferentes modelos, diferentes compensaciones de calidad/velocidad).
templates/
├── classification/
│ ├── customer_inquiry_classifier_v2.json
│ ├── spam_detector_v1.json
│ └── sentiment_analyzer_v1.json
├── extraction/
│ ├── invoice_data_extractor_v2.json
│ └── named_entity_extractor_v1.json
├── summarization/
│ ├── support_ticket_summary_v2.json
│ └── email_brief_v1.json
└── generation/
├── response_draft_v2.json
└── email_reply_v1.jsonCada archivo incluye el nombre del modelo, la temperatura, el prompt del sistema, la plantilla del mensaje del usuario, el formato de salida esperado y al menos un caso límite documentado. Esa estructura hace trivial encontrar «la plantilla de clasificación que estamos usando actualmente» en lugar de buscar en un documento de Notion «algo parecido a lo que hicimos para soporte».
Versiona tus Plantillas Deliberadamente
Cuando cambies un prompt, no lo sobrescribas. Crea una nueva versión.
La V1 funcionó bien. Decides ajustar las categorías de clasificación y reducir el recuento de tokens. Esa se convierte en la V2. Tu sistema de producción sigue ejecutando la V1 hasta que estés listo para probar la V2 con datos reales. Si la V2 introduce errores, no pierdes la V1: reviertes, analizas qué falló e iteras.
Esto suena a sobrecarga. No lo es. En el momento en que quieras revertir un cambio de prompt a las 11 PM porque la precisión de la categoría bajó, entenderás por qué el versionado ahorra tiempo.
Git funciona aquí. También lo hace un sistema simple de versionado JSON en S3. El mecanismo importa menos que la disciplina: una plantilla activa en producción, historial de cambios disponible y una forma clara de probar nuevas versiones antes de implementarlas.
Carga Plantillas en tu Código sin Fricción
Una biblioteca de plantillas que vive en una wiki pero no se conecta a tu código es solo documentación. Conéctala.
import json
import boto3
class PromptTemplateLoader:
def __init__(self, bucket_name: str, region: str = 'us-east-1'):
self.s3 = boto3.client('s3', region_name=region)
self.bucket = bucket_name
def load_template(self, template_path: str) -> dict:
"""Carga una plantilla desde S3 por ruta, ej: 'classification/customer_inquiry_classifier_v2.json'"""
response = self.s3.get_object(Bucket=self.bucket, Key=f"templates/{template_path}")
return json.loads(response['Body'].read())
def render_prompt(self, template: dict, variables: dict) -> str:
"""Rellena las variables de la plantilla. Las variables deben coincidir con los marcadores en user_template."""
return template['user_template'].format(**variables)
# Uso
loader = PromptTemplateLoader(bucket_name='my-templates')
template = loader.load_template('classification/customer_inquiry_classifier_v2.json')
user_prompt = loader.render_prompt(template, {"inquiry": "Your invoice is missing a line item"})
print(f"Model: {template['model']}")
print(f"Temperature: {template['temperature']}")
print(f"Prompt: {user_prompt}")Ahora tu código carga plantillas en tiempo de ejecución. Cambia una plantilla, implementa el cambio en S3, y tu aplicación lo recoge sin modificar el código. Esto escala a docenas de plantillas en múltiples servicios.
Documenta Modos de Fallo, No Solo Caminos Felices
Una plantilla que no señala dónde falla está incompleta.
Si tu plantilla de clasificación falla en casos límite —mensajes contradictorios del cliente, consultas extremadamente largas, sarcasmo— anótalo. Incluye un caso de prueba que reproduzca el fallo. Cuando un miembro del equipo encuentre ese caso límite en producción tres meses después, no pensará que la plantilla está rota. Reconocerá una limitación conocida y ajustará la entrada, añadirá preprocesamiento o usará una solución alternativa.
"known_issues": [
{
"description": "Clasificación de sentimiento errónea en mensajes sarcásticos",
"example": "'Oh genial, otro bug.' clasificado como positivo",
"frequency": "~15% de entradas sarcásticas",
"workaround": "Preprocesar con detector de tono o aumentar la temperatura a 0.5 para casos ambiguos"
},
{
"description": "La prioridad a veces escala solicitudes urgentes educadas a CRÍTICA",
"example": "'Cuando tengas un momento, esto es algo urgente' marcado como CRÍTICA",
"frequency": "~8% de solicitudes educadas",
"workaround": "Añadir contexto explícito: 'La educación no indica menor prioridad'"
}
]
Haz Esto Hoy
Elige una tarea para la que hayas escrito un prompt más de una vez. Extrae ese prompt a un archivo de plantilla estructurado. Documenta el modelo, la temperatura y un caso de fallo conocido. Compártelo en control de versiones.
Esa única plantilla es la semilla. No necesitas una arquitectura de biblioteca perfecta antes de empezar: necesitas una plantilla funcional que puedas reutilizar y un lugar consistente para almacenarla. Crece a partir de ahí.
