Prompting 101 — los pilares de Anthropic
Hannah y Christian del equipo Applied AI de Anthropic dieron una clase llamada Prompting 101: 10 pilares para escribir prompts profesionales y un caso real de seguros donde el mismo prompt evoluciona en 5 versiones — de confundir un choque con un accidente de esquí a entregar el veredicto en <final_verdict> listo para tu base de datos. Aquí lo destilamos en español con plantillas listas para copiar.
10 pilares · 5 versiones · 4 ejes · 1 plantilla
La metodología que el equipo Applied AI usa por dentro
Empezamos por los 4 ejes que sostienen todo (instrucciones claras, contexto, cómo arreglas la información, iteración empírica), bajamos a los 10 pilares en orden, mostramos cómo el prompt del seguro sueco subió de v1 a v5, cuándo conviene XML tags vs prosa, cómo usar extended thinking como muleta de diagnóstico y prefill para forzar la forma del output. Cierre con tres prompts copiables: plantilla de los 10 pilares, audita tu prompt actual y aplica el flujo v1 → v5 a tu propio caso.
el contexto · por qué esta clase importa
Prompting es una ciencia empírica — y Anthropic lo enseña con un caso real
Prompting 101 · Anthropic Applied AI Team (Hannah · Christian) deja claro algo de entrada: prompt engineering es la práctica de escribir instrucciones claras para el modelo, dándole el contexto que necesita y pensando cómo arreglas esa información para sacar el mejor resultado. No es magia ni receta. Es ciencia empírica: lanzas, lees el output, identificas qué falló y vuelves a lanzar.
Para mostrarlo en vivo escogieron un caso de un cliente real de seguros suecos: un parte de accidente con 17 filas de checkboxes y un sketch dibujado a mano. Dos artefactos, dos lenguajes, mucha intuición humana detrás. La primera versión del prompt — solo revisa este parte y dime quién tuvo la culpa — termina con Claude diciendo que es un accidente de esquí en una calle sueca. Fue una alucinación predecible: sin contexto, el modelo adivinó el dominio entero.
En 5 iteraciones, el mismo problema pasa de accidente de esquí a veredicto en XML listo para parsear. Cada versión añade un pilar. Esta página es la traducción operativa de esa clase: los 10 pilares en orden, las 5 versiones lado a lado, cuándo XML, cuándo extended thinking, cuándo prefill, y plantillas copiables.
Instrucciones claras
Le dices exactamente qué hacer, no "ayúdame con esto". Verbos específicos, scope explícito, criterios de éxito.
Contexto suficiente
Pasas el background que la tarea exige (formato del input, dominio, glosario). Sin esto, Claude rellena con suposiciones.
Cómo arreglas la información
El orden importa. Sistema vs usuario, qué va al inicio, qué se repite al final, qué se envuelve en XML.
Iteración empírica
Cada prompt es un experimento. Lanzas, lees el output, identificas qué falló, ajustas. La calidad sube por capas.
Para quién es esta página: cualquiera que esté metiendo un prompt en producción y quiera el método con el que el equipo Applied AI de Anthropic guía a sus clientes. Es la versión vault de la clase. El caso es de seguros pero los pilares aplican a cualquier tarea: clasificación, extracción, summarización, agentes, generación de código.
los 10 pilares · en orden
La estructura completa del system + user prompt
Anthropic recomienda construir el prompt como una sola pieza con 10 elementos en orden. No todos aplican siempre, pero si lo armas en este orden te aseguras de que cada vez que falte algo sea por decisión tuya, no por descuido. Los primeros 6 normalmente viven en el system prompt; los últimos 4 modelan la respuesta.
Task description / role
Le dices a Claude qué papel toma y para qué está aquí. Sin esto, adivina el dominio (en el demo del seguro, terminó hablando de un accidente de esquí).
Cuándo: Siempre, al inicio del system prompt.
Ejemplo: Eres un asistente AI de un ajustador humano de seguros que revisa partes de accidente de auto en sueco y determina responsabilidad.
Tone context
Cómo debe sonar Claude. En tareas factuales como esta: confiado, conciso, sin adivinar. Si no está seguro de algo, lo dice; no rellena con creatividad.
Cuándo: Cuando el output va a ser leído por otro humano o un sistema downstream y no toleras invenciones.
Ejemplo: Mantente factual y confiado. Si no puedes determinar algo con certeza desde la evidencia, dilo en lugar de adivinar.
Background data, documents & images
La parte que NO cambia entre llamadas. Estructura del formulario, glosario, ejemplos del dominio, imágenes de referencia. Va al system prompt y es ideal para activar prompt caching.
Cuándo: Si tu app llama a Claude más de una vez con el mismo contexto base.
Ejemplo: El formulario sueco tiene 17 filas numeradas, dos columnas (vehículo A y B) y los humanos lo llenan a mano con X, círculos o tachones.
Detailed task description & rules
Paso a paso de cómo razonar sobre la tarea. El ORDEN importa: en el demo, leer primero el formulario y después el sketch sube la calidad del veredicto porque el sketch sin contexto es solo cajas y líneas.
Cuándo: Cuando hay varios artefactos que combinar o decisiones intermedias.
Ejemplo: 1) Lee el formulario fila por fila y lista qué vehículo marcó qué. 2) Cruza esa lista con el sketch y verifica consistencia. 3) Solo entonces emite el veredicto.
Examples (few-shot)
Casos en gris donde tu intuición humana ya tiene la verdad. Le pasas a Claude los ejemplos difíciles que viste y cómo los resolverías; en producción esto puede ser decenas o cientos de ejemplos etiquetados.
Cuándo: Cuando el formato del output importa más que la instrucción, o cuando hay casos límite recurrentes.
Ejemplo: <example><input>...form A...</input><output><final_verdict>Vehículo B responsable...</final_verdict></output></example>
Conversation history
Solo si hay historia que cargue contexto real. En apps con conversación viva: turnos previos, decisiones del usuario, preferencias. En batch jobs como este, normalmente no aplica.
Cuándo: Apps user-facing con sesión larga. No abuses si los turnos previos no aportan.
Ejemplo: <conversation_history>El usuario ya confirmó que el vehículo A es del cliente y aceptó cobertura básica.</conversation_history>
Immediate task description
El recordatorio del aquí-y-ahora al final del prompt. Después de toda la preamble, le dices a Claude qué quieres EN ESTA llamada. Reduce la deriva.
Cuándo: Siempre, justo antes del cierre.
Ejemplo: Para este parte específico: lee el formulario, después el sketch, y emite el veredicto siguiendo las reglas de arriba.
Thinking step-by-step
Chain of thought explícito o extended thinking. Pides a Claude que muestre su razonamiento antes de concluir. Sube la calidad en tareas multi-paso y te da una traza para diagnosticar errores.
Cuándo: Cuando la tarea tiene lógica que se puede romper en sub-pasos. En thinking-native models úsalo con cuidado para no degradar.
Ejemplo: Antes del veredicto, escribe tu razonamiento dentro de <thinking></thinking>: qué viste, qué descartaste y por qué.
Output formatting
Cómo quieres el resultado. JSON, XML, Markdown, longitud, tipo de archivo. Si lo dejas libre, Claude escoge — y rara vez coincide con lo que tu parser espera.
Cuándo: Siempre que el output entre a otro sistema (DB, frontend, downstream LLM).
Ejemplo: Envuelve tu veredicto final dentro de <final_verdict>...</final_verdict>. El resto puede ser preamble, lo ignoro.
Prefilled response
Empezar a hablar por Claude. Pones la primera palabra (o tag) en su mensaje y obligas la forma del output sin tener que pedirla en prosa.
Cuándo: Cuando quieres JSON estricto o XML sin preamble. También cuando el modelo se está saliendo de personaje.
Ejemplo: Pre-llenas el assistant message con `{` para forzar JSON, o con `<final_verdict>` para forzar el wrapping del veredicto.
Regla de pulgar: si tu app llama a Claude más de una vez con la misma estructura, los pilares 1 al 6 son candidatos para system prompt + prompt caching. Los pilares 7 al 10 modelan la respuesta y suelen ir en el último mensaje del usuario o como prefill del assistant.
el demo · v1 → v5
El mismo prompt, evolucionando con cada pilar añadido
Esta es la columna vertebral de la clase: un solo prompt para revisar partes de accidente sueco que, en 5 versiones, pasa de adivinar mal el dominio a entregar el veredicto envuelto en <final_verdict>. Léelo en orden: cada versión añade exactamente un pilar y resuelve el error de la anterior.
Prompt vago
Qué se añadió
Solo "revisa este parte y dime quién tuvo la culpa".
Qué pasó en el output
Claude lo confunde con un accidente de esquí en una calle sueca. La intuición de "esto es un parte de auto" no está en ningún lado del prompt.
Lo que aún fallaba
Sin rol, sin tono, sin background. Adivina el dominio entero.
Task + tone context
Qué se añadió
Rol (asistente de un ajustador humano que revisa partes en sueco), tono (no adivines si no estás seguro).
Qué pasó en el output
Identifica que es un choque vehicular. Lee correctamente que el vehículo A marcó la fila 1 y el B la fila 12. Pero responde inseguro y sin veredicto.
Lo que aún fallaba
Aún no sabe qué significa cada fila ni para qué sirve el formulario.
Background data en system prompt
Qué se añadió
Estructura del formulario sueco metida en el system prompt: 17 filas, dos columnas, cómo se llena (humanos, marcas variadas: X, círculos, tachones), propósito.
Qué pasó en el output
Lee el formulario con confianza, da veredicto: vehículo B responsable. Aprovecha que el system prompt es estático y se cachea.
Lo que aún fallaba
El output es libre, narra de más, no es parseable por un sistema downstream.
Detailed rules + orden de análisis
Qué se añadió
Reglas paso a paso: 1) leer formulario fila por fila, 2) listar qué vehículo marcó qué, 3) cruzar con el sketch, 4) emitir veredicto solo si hay consistencia.
Qué pasó en el output
Razonamiento ordenado: primero lista cada checkbox del formulario, después cruza con el sketch, después emite el veredicto. La calidad sube en casos difíciles.
Lo que aún fallaba
Sigue narrando demasiado para un parser. La utilidad para humanos es alta, para máquinas no tanto.
Output formatting + prefill
Qué se añadió
Importance guidelines (claro, conciso, exacto) + regla de output: envolver el veredicto final en XML. Opcional: prefill del assistant con `<final_verdict>` para forzar la forma.
Qué pasó en el output
Veredicto envuelto en <final_verdict>...</final_verdict>, listo para parser. Toda la preamble la ignoras desde tu app y guardas solo el bloque.
Lección operativa: no salgas a producción con v1. Pero tampoco intentes escribir v5 de un golpe. Empieza simple, observa el error específico, añade UN pilar, vuelve a correr. La calidad sube por capas y queda evidencia escrita de por qué cada parte del prompt está ahí.
estructura · xml tags vs prosa
Por qué Claude lee mejor con XML — y cuándo conviene usarlo
Claude está fine-tuneado para reconocer bloques XML como secciones con propósito distinto. No es magia ni decoración: cuando envuelves contenido en <background>, <rules> o <output_format>, Claude lo trata como una intención separada. Markdown también ayuda, pero XML es más explícito y mucho más fácil de referenciar después.
Sin XML (prosa plana)
Eres un asistente de seguros que revisa formularios suecos. Sé factual. El formulario tiene 17 filas y los humanos no los llenan perfecto. Lee primero el formulario después el sketch y dame el veredicto al final, en formato libre. Si no estás seguro dilo.
Con XML
<role>...</role> + <tone>...</tone> + <background>...</background> + <rules>...</rules> + <output_format>...</output_format> + <task>...</task>. Claude lee cada bloque como una intención separada — está fine-tuneado para esto.
Ejemplo · system prompt completo con XML
Este es el system prompt del demo del seguro sueco, ya con los pilares 1 al 4, 7 y 9 envueltos en XML. Cópialo, adapta el dominio y úsalo de plantilla.
<role> Eres un asistente AI de un ajustador humano de seguros. Revisas partes de accidente de auto en sueco y determinas responsabilidad. </role> <tone> Mantente factual y confiado. Si no puedes determinar algo con certeza, dilo. No adivines. </tone> <background> El formulario es un parte sueco estándar con 17 filas numeradas y dos columnas (vehículo A, vehículo B). Los humanos marcan con X, círculos o tachones — no esperes formato perfecto. Cada fila representa una acción del vehículo en el momento del accidente. </background> <rules> 1) Lee el formulario fila por fila. Lista qué vehículo marcó qué. 2) Cruza esa lista con el sketch del accidente. 3) Solo si la evidencia es consistente, emite veredicto. Si no, marca "insuficiente". </rules> <output_format> Razona dentro de <thinking>...</thinking>. Tu veredicto final va dentro de <final_verdict>...</final_verdict>. Lo demás lo ignoro. </output_format> <task> Para este parte específico, ejecuta el flujo de <rules> y respeta <output_format>. </task>
Cuando NO usar XML: tareas muy cortas (una sola pregunta directa) o cuando estás en chat-mode con Claude para explorar — ahí el XML solo agrega ruido. Pero en cuanto tu prompt entre a producción y haga la misma cosa muchas veces, vale la pena estructurarlo.
extended thinking · la muleta del prompt engineer
Cómo usar el scratchpad de Claude 4.x para diagnosticar prompts
Tanto Claude 3.7 como Claude 4.x son modelos híbridos de razonamiento: cuando activas extended thinking, el modelo escribe su razonamiento dentro de tags de pensamiento antes de responder. Christian lo plantea sin rodeos: extended thinking es la muleta del prompt engineer. No es una optimización mágica, es una herramienta de diagnóstico.
El flujo: prendes thinking, lees el transcript del scratchpad, ves en qué paso Claude se desliza, y metes esa intuición de regreso al system prompt. Después de unas iteraciones tu prompt está tan afilado que ya no necesitas tener thinking encendido — porque el razonamiento ya vive escrito en tu system prompt en forma de reglas explícitas.
Como muleta de prompt engineering
Activas extended thinking, lees el scratchpad y descubres en qué paso Claude se está perdiendo. Después metes esa intuición de regreso al system prompt.
Token efficient
Cuando el problema lo merece, pensar antes de hablar produce mejor output con MENOS tokens finales. Más razonamiento adentro, menos verbosidad afuera.
Diagnóstico en producción
Si un caso falló, miras el thinking y entiendes el por qué. Es feedback para tu siguiente versión del prompt, no solo logging.
No siempre lo prendas
En tareas simples (clasificación, extracción directa) pensar de más mete latencia y costo sin mejorar resultado. Mide antes de dejarlo on por default.
Pista del demo: en la versión 4 del prompt sueco, Claude escribe algo como checkbox 1: vacío, checkbox 2: marcado con X, checkbox 3: tachón, checkbox 4: círculo... — eso vive ahora en thinking. Esa narración detallada paso a paso es exactamente lo que después puedes destilar en una regla para tu system prompt y dejar el thinking apagado.
Documentación oficial: docs.claude.com / extended-thinking.
prefill + caching · cierre del prompt
Pon palabras en boca de Claude — y cachea lo que no cambia
El último pilar del transcript es prefilled response. La idea: cuando el modelo te responde, lo hace continuando el texto que tú le pongas en su mensaje. Si pre-llenas el assistant message con {, Claude saldrá con JSON. Si lo pre-llenas con <final_verdict>, va directo al veredicto sin meter preamble. Es la forma más barata de garantizar formato.
Forzar JSON estricto
{Pre-llenas el mensaje del assistant con `{`. Claude completa el JSON sin preamble. Tu parser ya no se rompe.
Forzar wrapping XML
<final_verdict>Pre-llenas con la apertura del tag de output. Claude llega directo al veredicto y cierra el tag al final.
Forzar lista numerada
1.Útil cuando quieres N ítems sin que Claude meta una intro. Combina con "genera N puntos" en el prompt.
Mantener personaje
[Como ajustador senior]:Si el modelo se desliza fuera del rol, prefill recuerda quién está hablando antes de empezar.
Bonus · prompt caching del system prompt estático
El bloque grande de background, role y rules es el mismo en cada llamada. Activa prompt caching en esa parte: pagas el costo completo de tokens la primera vez y ~10% en las siguientes. Para apps batch (procesar 1.000 partes), el ahorro es de varios órdenes.
Documentación oficial: docs.claude.com / prompt-caching.
prompts copiables · aplica los pilares ya
Cuatro plantillas para llevarte la metodología a tu propio caso
Tres prompts que toman la metodología del transcript y la convierten en acción inmediata: arranca con la plantilla de los 10 pilares, audita un prompt que ya tengas en producción y replica el flujo iterativo v1 → v5 sobre tu propio caso de uso. Cierro con un cuarto prompt para refactorizar un mensaje gigante a la estructura system + user.
Plantilla · system prompt de los 10 pilares
Esqueleto en blanco con cada pilar marcado y comentado. Pégalo en tu app, llena los placeholders y ya tienes una v3-v4 lista de salida.
<role>
[Pilar 1] Eres un [rol específico] que [misión clara, una línea].
</role>
<tone>
[Pilar 2] Mantente [factual / cálido / técnico]. Si [condición de incertidumbre], [acción explícita en lugar de adivinar].
</tone>
<background>
[Pilar 3] Contexto que NO cambia entre llamadas:
- Estructura del input que vas a recibir.
- Glosario o convenciones del dominio.
- Reglas de negocio fijas.
</background>
<examples>
[Pilar 5] Casos difíciles ya resueltos por humanos:
<example>
<input>...</input>
<output>...</output>
</example>
</examples>
<rules>
[Pilar 4] Cómo razonar sobre la tarea, paso a paso:
1) [Primer paso, el más simple]
2) [Segundo paso, depende del primero]
3) [Veredicto / output, solo si los pasos previos son consistentes]
</rules>
<conversation_history>
[Pilar 6, opcional] Solo si tu app tiene sesión viva con turnos relevantes.
</conversation_history>
<output_format>
[Pilar 9] Envuelve el resultado final dentro de [<tag>...</tag> o JSON estricto].
[Pilar 8] Antes del resultado, razona dentro de <thinking>...</thinking>.
</output_format>
<task>
[Pilar 7] Para este input específico, ejecuta el flujo de <rules>.
</task>
<!-- Pilar 10 (prefill) lo aplicas en el assistant message: empieza con "{" o "<...>" según el formato deseado. -->Audita tu prompt actual contra los 10 pilares
Le pegas tu prompt en producción y Claude lo califica pilar por pilar, te dice cuáles 3 dan más impacto al añadirse, y te entrega la versión afilada.
Voy a pegarte mi prompt actual. Quiero que lo audites contra los 10 pilares de Prompting 101 de Anthropic Applied AI: 1) Task description / role 2) Tone context 3) Background data, documents & images 4) Detailed task description & rules 5) Examples (few-shot) 6) Conversation history 7) Immediate task description 8) Thinking step-by-step 9) Output formatting 10) Prefilled response PROMPT ACTUAL: """ [pega aquí tu prompt completo] """ CASO DE USO: [describe en 1-2 líneas qué hace este prompt en producción] ENTRÉGAME: 1. Tabla con los 10 pilares marcando ✅ presente / ⚠️ débil / ❌ ausente y una línea de evidencia. 2. Los 3 pilares con mayor impacto al añadirlos en este prompt específico — y qué mejora esperas. 3. La versión afilada del prompt, listo para copiar, con XML tags si aplica. 4. Una sola línea de estrategia: qué cambió y por qué.
Aplica el flujo v1 → v5 a tu caso
Mismo patrón del demo del seguro sueco, pero con TU tarea. Claude entrega 5 versiones del prompt, cada una añadiendo un pilar y corrigiendo el error de la anterior.
Quiero aplicar el flujo iterativo V1 → V5 de Prompting 101 de Anthropic a MI caso de uso. Sigue exacto el patrón del demo del seguro sueco: MI TAREA: """ [describe en 2-3 líneas qué quieres que Claude haga, qué inputs recibe y qué output esperas] """ ENTRÉGAME LAS 5 VERSIONES: v1 — Prompt vago, una sola línea. Para mostrar el modo error. v2 — v1 + role + tone context. Sin background todavía. v3 — v2 + background data en lo que iría al system prompt (estructura del input, glosario, reglas fijas). v4 — v3 + reglas paso a paso de cómo razonar, en orden. v5 — v4 + output formatting (XML o JSON) + sugerencia de prefill. Para cada versión: - Marca qué pilar añadiste con respecto a la previa. - Pega el prompt completo en bloque copiable. - En una línea, explica qué error de v(n-1) corrige. Cierra con: cuál versión recomiendas correr en producción y por qué.
Refactor · de un mensaje gigante a system + user
Si arrastras un prompt monolítico, este lo parte en system prompt cacheable + user message con placeholders, te dice qué cachear y sugiere prefill.
Tengo este prompt todo en un solo mensaje de usuario. Quiero refactorizarlo a la estructura system + user que recomienda Anthropic Applied AI:
PROMPT ACTUAL (todo junto):
"""
[pégalo entero aquí]
"""
ENTRÉGAME:
1) SYSTEM PROMPT — lo que NO cambia entre llamadas:
- <role>...</role>
- <tone>...</tone>
- <background>...</background>
- <rules>...</rules>
- <examples>...</examples> (si los hay)
- <output_format>...</output_format>
2) USER MESSAGE TEMPLATE — lo que SÍ cambia por cada llamada:
- Placeholders {{...}} marcados.
- Pilar 7 (immediate task) al inicio o al final.
3) NOTA DE PROMPT CACHING — qué bloque del system prompt te conviene cachear y cuánto ahorras aproximado.
4) PREFILL SUGERIDO — qué meter en el primer mensaje del assistant para forzar el formato deseado.Cómo encadenarlos: si arrancas de cero, usa la plantilla de los 10 pilares y luego corre el flujo v1 → v5 para ir capa por capa. Si ya tienes algo corriendo, audita primero, después refactoriza a system + user, y solo entonces aplica v5 con prefill.
Guía de la comunidad
Esta entrada destila Prompting 101 del equipo Applied AI de Anthropic. Es parte de la bóveda de tododeia, una colección libre de recursos para quienes usan Claude todos los días. La fuente original es la clase pública del equipo Applied AI; documentación de respaldo en docs.claude.com.
Anthropic — Prompt engineering overview
Documentación oficial. Cubre los pilares con ejemplos canónicos y guías por capacidad.
Prompt library
Catálogo de prompts probados por Anthropic. Útil para arrancar con un esqueleto sólido.
Extended thinking
Cómo activar y leer el scratchpad. La muleta para diagnosticar prompts en Claude 4.x.
Prompt caching
Cómo cachear el system prompt estático y bajar el costo a una fracción en apps batch.
Prompt Master
La skill que afila tus prompts
Hablarle a Claude
El tono que mueve mejores outputs
Mejores prácticas
El compendio del día a día
¿Por dónde empezar si tu prompt ya está roto?
Corre el prompt de auditoría primero. Te va a dar el diagnóstico de cuáles pilares te faltan y cuáles tres dan más palanca al añadirse. Después aplica el flujo v1 → v5 — pero arrancando desde tu mejor versión actual, no desde cero. Es la forma más rápida de subir calidad sin reescribir todo.
¿Para quién no aplica esta página?
Si solo usas Claude en chat-mode para conversar y explorar, los 10 pilares son overkill. Esta metodología es para cuando un prompt entra a producción y va a correr cientos o miles de veces. En esos casos, cada pilar pagado se traduce en menos errores, menos tokens y outputs que tu sistema downstream sí puede parsear.