Prompting 101 — Los Pilares de Anthropic

Hannah y Christian del equipo Applied AI de Anthropic publicaron "Prompting 101" — los 10 pilares fundamentales que aplican cuando prompteán Claude en proyectos productivos. No es teoría. Cada pilar viene con caso real de análisis de un parte de accidente sueco (un proyecto de cliente, anonimizado), demostrando antes/después de prompts.

Esta nota traduce los 10 pilares al español y agrega los ejemplos en código pegable. Cubre estructura del system prompt, cuándo usar XML tags, prefill de respuesta, y extended thinking como muleta.

Por qué Applied AI vs. ML research

El equipo Applied AI de Anthropic es el que trabaja con clientes. No publican papers — publican patrones que funcionan en negocios reales. Sus pilares vienen de millones de prompts probados, no de benchmarks académicos.

Eso significa: lo que dicen funciona, y lo que omiten probablemente no es crítico.

Los 10 pilares

Pilar 1: Separá rol, tarea y restricciones

Un prompt productivo tiene tres partes distintas:

Rol: qué es Claude en este contexto. Tarea: qué tiene que hacer. Restricciones: qué NO tiene que hacer.

Mal:

Hola Claude, analiza este texto y dame los datos importantes.

Bien:

<rol>
Sos analista de siniestros para una aseguradora sueca. Tu trabajo es 
extraer datos estructurados de partes de accidente para alimentar 
nuestro sistema interno.
</rol>

<tarea>
Procesá el parte de accidente. Identificá: fecha, ubicación, vehículos 
involucrados, daños declarados, lesiones, declaraciones de las partes.
</tarea>

<restricciones>
- No infieras datos que no estén explícitos en el documento.
- Si un campo no aparece, marcalo como "no_disponible".
- No agregues comentarios editoriales.
</restricciones>

Pilar 2: XML tags para estructura clara

Claude está entrenado con XML tags. Los usa para parsear estructura. No son opcionales para prompts serios.

<input_documento>
[acá pegás el texto del parte]
</input_documento>

<schema_output>
{
  "fecha": "ISO 8601",
  "ubicacion": "string",
  "vehiculos": [array],
  "daños": [array],
  "lesiones": [array],
  "declaraciones": [array]
}
</schema_output>

<formato_respuesta>
JSON único, sin texto adicional antes ni después.
</formato_respuesta>

Las XML tags hacen que Claude sepa qué es contenido a procesar vs. instrucción a seguir.

Pilar 3: Ejemplos > explicaciones

Mostrale 1-2 ejemplos del output esperado en lugar de describir cómo debe verse.

<ejemplo_input>
"Den 14 mars 2026, kl 14:32, vid Stortorget i Malmö, kolliderade en 
röd Volvo XC60 (ABC123) med en blå Saab 9-3 (XYZ789). Föraren av 
Volvon fick whiplash. Volvon fick skador på fronten, Saaben på 
sidan."
</ejemplo_input>

<ejemplo_output>
{
  "fecha": "2026-03-14T14:32:00",
  "ubicacion": "Stortorget, Malmö",
  "vehiculos": [
    { "marca": "Volvo", "modelo": "XC60", "color": "rojo", "patente": "ABC123" },
    { "marca": "Saab", "modelo": "9-3", "color": "azul", "patente": "XYZ789" }
  ],
  "lesiones": [{ "tipo": "whiplash", "vehiculo": "ABC123" }],
  "daños": [
    { "patente": "ABC123", "area": "frontal" },
    { "patente": "XYZ789", "area": "lateral" }
  ],
  "declaraciones": []
}
</ejemplo_output>

Con un ejemplo, Claude entiende el formato. Sin ejemplo, vas a recibir variaciones impredecibles.

Pilar 4: Restricciones positivas > negativas

"Mostrale lo que querés, no lo que no querés" funciona mejor.

Mal:

No incluyas explicaciones. No agregues markdown. No escribas más de 100 palabras.

Bien:

Respondé con JSON puro, una sola estructura, máximo 100 palabras de contenido total.

Pilar 5: Una tarea por prompt

Si tu prompt pide 5 cosas, Claude las hace todas pero ninguna excelente. Dividilo.

Mal (todo junto):

Analizá este parte. Extraé datos estructurados, evaluá la severidad, 
sugerí qué documentos adicionales pedir, y recomendá si aprobar el 
reclamo.

Bien (sub-tareas separadas):

# Prompt 1: extracción
Analizá este parte. Extraé datos estructurados (schema X).

# Prompt 2 (con output del 1 como input):
Con esta data estructurada, evaluá la severidad en escala 1-5.

# Prompt 3:
Con la severidad determinada, sugerí qué documentos adicionales pedir.

# Prompt 4 (con todo lo anterior):
Recomendá aprobar/rechazar/escalar con justificación.

Cada paso tiene mejor calidad, y debugeable individualmente.

Pilar 6: Prefill de respuesta

Si el output debe arrancar de cierta forma, prefilleá el inicio. Claude continúa desde ahí.

En API:

messages=[
  { "role": "user", "content": "..."},
  { "role": "assistant", "content": "{" }  # prefill
]

Eso fuerza a Claude a responder JSON empezando con {. No va a divagar con "Aquí está la respuesta: { ... }".

Útil para:

• Forzar formato JSON.
• Forzar que arranque con código.
• Forzar tono específico ("Mi análisis es:").

Pilar 7: Extended thinking como muleta para casos complejos

Extended thinking (el "thinking" mode de Claude) es útil pero no es siempre necesario. Los pilares aplican: si el caso es complejo, prendelo. Si es simple, ahorrás tokens.

Cuándo prender:

• Análisis multi-paso.
• Decisiones con tradeoffs.
• Edge cases ambiguos.

Cuándo NO prender:

• Extracción simple.
• Tareas con respuesta determinística.
• Volumen alto con cada caso simple.

En API:

thinking={ "type": "enabled", "budget_tokens": 4000 }

Pilar 8: Mostrá tu mejor ejemplo, no el más extraño

Tentación natural: dar ejemplos del caso más raro porque "ahí es donde necesito ayuda". Mala estrategia. Los ejemplos deben representar el caso típico. Claude infiere el patrón general.

Para edge cases, agregá una sección separada:

<ejemplos_tipicos>
[3 ejemplos del caso normal]
</ejemplos_tipicos>

<edge_cases>
- Si el documento está incompleto, marcar campos faltantes.
- Si hay contradicciones, registrar ambas versiones.
- Si la fecha es ambigua, usar formato YYYY-MM-DD-AMBIGUOUS.
</edge_cases>

Pilar 9: Iterá con casos reales, no sintéticos

El antipatrón: armar un prompt, probarlo con 5 inputs inventados, declarar "funciona", llevarlo a producción, descubrir que en producción falla 30% del tiempo.

El patrón correcto:

1. Juntá 20-50 casos reales (anonimizados).
2. Probá el prompt con los 50.
3. Mirá los outputs uno por uno.
4. Identificá patrones de error.
5. Ajustá el prompt.
6. Repetí.

Cuando llevás a producción, ya viste los modos de falla.

Pilar 10: El system prompt es lazy

Importante saberlo: el system prompt no es "siempre activo". Claude le da más peso a los mensajes recientes. Si tu system prompt dice "respondé siempre en español" y después en la conversación largo te pasás al inglés, Claude puede responder en inglés.

Workarounds:

• Reforzar reglas críticas en cada user message.
• Para reglas inmutables, usar prefill en lugar de system.
• Para conversaciones largas, reinjectar el system prompt cada N turns.

Caso completo: parte de accidente sueco

Acá está el prompt final que el equipo Applied AI ajustó para el caso:

<rol>
Sos analista senior de siniestros vehiculares para una aseguradora 
sueca. Procesás partes de accidente para alimentar el sistema de 
gestión de reclamos. Trabajás en sueco e inglés.
</rol>

<tarea>
Extraé datos estructurados del parte que está en <input_parte>.
Identificá: fecha/hora, ubicación, vehículos involucrados, daños,
lesiones, y declaraciones de las partes.
</tarea>

<schema_output>
{
  "fecha_hora": "ISO 8601 o null",
  "ubicacion": "string detallado o null",
  "vehiculos": [
    {
      "marca": "string",
      "modelo": "string",
      "color": "string",
      "patente": "string",
      "rol": "vehiculo_a | vehiculo_b | tercero"
    }
  ],
  "daños": [
    {
      "patente": "string",
      "area": "frontal | trasera | lateral_izquierda | lateral_derecha | techo | bajos",
      "severidad": "leve | moderado | grave"
    }
  ],
  "lesiones": [
    {
      "vehiculo_patente": "string",
      "ocupante": "conductor | pasajero | peaton",
      "tipo": "string",
      "severidad": "leve | moderado | grave"
    }
  ],
  "declaraciones": [
    {
      "parte": "vehiculo_a | vehiculo_b | testigo",
      "version": "string textual"
    }
  ],
  "campos_no_extraibles": ["array de strings con nombres de campos"]
}
</schema_output>

<restricciones>
- Solo datos explícitos. No inferir.
- Si una unidad está ambigua, marcar campo como null y agregar a 
  "campos_no_extraibles".
- Severidad de daños y lesiones según escala del manual interno 
  (anexo a este prompt si está disponible).
- Mantener nombres propios en su grafía original.
</restricciones>

<input_parte>
[acá va el documento real]
</input_parte>

<formato>
Respondé con JSON únicamente. Sin texto adicional, sin markdown 
code blocks.
</formato>

Output esperado: JSON limpio, listo para inserción en DB.

Errores típicos al adoptar los pilares

Error 1: Aplicar todos los pilares siempre

Para tareas simples (chat conversacional, ayuda a redactar mail), no necesitás XML tags ni prefill. Los pilares son herramientas, usalas cuando aplican.

Error 2: Sobre-restringir

Si tu prompt tiene 20 restricciones, Claude se confunde. Mantenelo a 5-7 restricciones críticas. Las menos críticas, manejalas con validación post-hoc.

Error 3: Olvidarse de iterar

Los pilares no te dan el prompt perfecto a la primera. Te dan la estructura. La iteración con casos reales (pilar 9) es lo que pule el output.

Conclusión

Los 10 pilares de Applied AI son la base de prompts profesionales con Claude. Si los adoptás, tus outputs pasan de "más o menos lo que quería" a "exactamente lo que necesito". Si los ignorás, vas a pelearte con respuestas inconsistentes y resultados frágiles.

Imprimí los pilares y tenelos al lado del teclado. Cada prompt importante que escribas, pasalo por la checklist mental.

Tags: prompt-engineering, anthropic, applied-ai, claude, xml-tags, extended-thinking, prefill