Dos expertos te dicen cómo hacer 'prompts' en Claude y que lo haga "perfecto"
Si alguna vez has pedido a un modelo que “analice esto” y te ha devuelto una respuesta brillante… sobre otra cosa, no es que el modelo sea malo: es que el prompt era un colador. Eso es lo que muestran Hannah Moran y Christian Ryan en su sesión “Prompting 101” para Claude: un caso realista de aseguradora sueca que necesita leer un parte de accidente en sueco (formulario con casillas + croquis a mano) y decidir qué pasó y quién tuvo la culpa.
El primer experimento —prompt mínimo, temperatura a 0 y tokens de sobra— produce un fallo tan humano que da miedo: Claude cree que se trata de un accidente de esquí en una calle sueca. No inventa por maldad: completa huecos porque el prompt no le marcó el terreno. La lección es brutal: cuando falta contexto, el modelo lo rellena. Y lo que parece “alucinación” es, muchas veces, una instrucción mal diseñada.
A partir de ahí, Moran y Ryan convierten el prompting en algo que muchos equipos aún se resisten a aceptar: una práctica iterativa, casi experimental, pero con reglas claras. La diferencia entre un prompt “de chat” y un prompt “de producto” es que el segundo debe funcionar a la primera, con una sola llamada, sin ping-pong.
Protocolo, no conversación
La estructura recomendada por Anthropic parece simple, pero cambia el resultado:
- Task description (qué eres, qué haces, para qué)
- Content (lo dinámico: imágenes, texto, documentos)
- Detailed instructions (pasos, orden, criterios de verificación)
- Examples (casos guía para escenarios grises)
- Reminder (repetir lo crítico y lanzar la ejecución)
La obsesión aquí no es estética. Es control. Si tu aplicación es un sistema de reclamaciones, no puedes permitirte respuestas “creativas”. Necesitas trazabilidad: qué ha visto, qué ha inferido y por qué. Y, sobre todo, necesitas que Claude sepa cuándo callarse.
Contexto y tono: el antídoto contra el “me lo invento”
La segunda versión del prompt añade lo que el primer intento no tenía: contexto operativo. Claude ya no está “hablando” con un usuario, está ayudando a un tramitador de siniestros. Y se le ordena algo esencial: mantenerse factual y no evaluar si no está seguro.
Esa regla —“no hagas assessment si no estás completamente confiado”— es el primer seguro de calidad. En la demo, el cambio es inmediato: Claude deja el esquí, entiende que hay dos vehículos (A y B), identifica casillas marcadas y, lo más importante, reconoce incertidumbre cuando falta información. No es un detalle: en producción, preferir un “no lo sé” a un “me parece” es la diferencia entre automatización y riesgo legal.
“Queremos que Claude se mantenga factual y confiado; si no lo entiende, que no adivine”, resumen los expertos. Y ese principio funciona como regla de oro: si no fuerzas el tono, el modelo tenderá a ser útil… incluso cuando no debería.
System prompt: lo fijo se paga una vez, lo variable se interpreta mejor
El salto grande llega cuando incorporan el “background” permanente al system prompt. El formulario sueco no cambia: siempre tiene 17 filas, dos columnas (vehículo A y B) y una semántica conocida (qué significa cada casilla). Eso es oro para un LLM: es contexto estable y repetible.
Moran lo plantea como una idea casi contable: si algo es constante, ponlo arriba para que el modelo no tenga que “descubrir” el formulario cada vez. Resultado: Claude invierte menos esfuerzo en entender la plantilla y más en leer correctamente qué está marcado, incluso si el humano ha hecho un círculo, un garabato o una X imperfecta.
En un producto real, ese enfoque además permite optimizar costes (por ejemplo, con caching del prompt estable) y, sobre todo, elevar consistencia: el modelo deja de improvisar qué es un “checkbox”.
Orden de análisis: primero formulario, luego dibujo
Uno de los puntos más valiosos de la sesión es casi psicológico: el orden importa. El croquis a mano es ambiguo; el formulario aporta estructura. Por eso recomiendan indicar explícitamente el orden:
- primero, leer el formulario “muy cuidadosamente”,
- después, interpretar el dibujo a la luz de lo leído,
- finalmente, sintetizar y decidir.
Este detalle reduce errores de interpretación porque replica lo que haría un humano competente. En términos de prompting, es una forma de evitar que Claude se enganche a una señal visual confusa y genere narrativa alrededor.
Aquí aparece un riesgo interesante: si pides “revisa cada casilla”, Claude puede volverse demasiado verboso. Es un trade-off real: más verificación suele significar más tokens. La solución no es quitar el paso, sino exigir output por capas: lo que necesitas para la app y lo que solo sirve como auditoría.
Delimitadores y XML: el modelo entiende mejor lo que está etiquetado
Anthropic insiste en que Claude “ama la estructura”. Por eso recomiendan delimitadores, especialmente XML tags, para encapsular información y salidas: <form_analysis>, <sketch_analysis>, <final_verdict>. No es una manía: es un método para que el modelo sepa qué parte del prompt es qué y para que el sistema receptor pueda parsear sin sufrimiento.
La clave está en la fricción real del dato: un output bonito en lenguaje natural puede ser inútil si tienes que meterlo en una base de datos. Con tags, puedes ignorar el preámbulo y quedarte con el veredicto.
Ejemplos: el arma más potente para “casos grises”
Christian Ryan lo llama sin rodeos: los ejemplos (few-shot) son el mecanismo más poderoso para “empujar” al modelo hacia el comportamiento deseado. Y no es teoría: en seguros, hay decenas de escenarios borderline donde una frase o un trazo mal dibujado cambia la culpabilidad.
La recomendación es simple: si tienes accidentes “difíciles” que el humano resuelve bien, conviértelos en ejemplos dentro del system prompt. Incluso puedes incluir imágenes de ejemplo. La idea es entrenar comportamiento por demostración: “cuando veas algo así, responde así”.
Esto convierte el prompting en una ciencia empírica: detectas dónde falla, añades ejemplo, vuelves a medir. No es elegante, pero es eficaz.
Formato de salida: sin esto no hay producto
En la parte final, subrayan algo que separa demos de soluciones reales: output formatting. Si eres data engineer, quieres JSON o un bloque etiquetado, no un ensayo. Por eso recomiendan forzar el veredicto dentro de una etiqueta o incluso “poner palabras en la boca” al modelo con respuestas pre-rellenadas.
El objetivo no es limitar a Claude, sino hacerlo integrable. Un modelo que acierta pero no se puede parsear es un modelo que no escala.
Extended thinking: usar la mente del modelo como herramienta de depuración
Ryan añade una palanca avanzada: habilitar el “extended thinking” (cuando el modelo lo permite) para ver cómo razona. No para publicarlo, sino para diagnosticar: entender por qué se equivoca, qué señal prioriza, qué parte del formulario le confunde. Luego, esa información se convierte en mejores instrucciones o ejemplos.
La consecuencia es clara: el prompting deja de ser intuición y se vuelve ingeniería. Y el prompt final —con rol, contexto, estructura, ejemplos, verificación y formato— transforma a Claude de “chatbot listo” en “componente fiable”.
