comunidadbóvedaprompting-101-anthropic

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.

Opus 4.7 · 10 pilares · 5 versiones · prompts copiables

Actualizada para Opus 4.7: Claude dejó de adivinar

Arrancamos con los 3 cambios que trajo Opus 4.7 — el modelo nuevo se siente “más tonto” solo porque dejó de adivinar y ahora hace literal lo que le pides. Después bajamos a la base atemporal: los 4 ejes, los 10 pilares en orden, cómo el prompt del seguro sueco subió de v1 a v5, cuándo usar XML tags, extended thinking y prefill. Cerramos con las reglas de oro 2026 y prompts copiables para afinar tus respuestas con el modelo nuevo.

Applied AI Team · AnthropicActualizado 2026 · Opus 4.7Los 3 cambios del modelo nuevo10 pilares · caso real del seguro sueco

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.

actualización 2026 · el modelo nuevo cambió las reglas

Opus 4.7: por qué Claude se siente “más tonto” (y los 3 cambios que tienes que hacer hoy)

Si usas Claude y sientes que se volvió más tonto, no es tu imaginación. El modelo nuevo, Opus 4.7, cambió cómo hay que pedirle las cosas — y casi nadie se enteró. La buena noticia: no se volvió peor, dejó de adivinar. Ahora hace tal cual lo que le pides. Estos son los tres cambios que salen verbatim de la guía oficial de Anthropic.

1

Claude dejó de adivinar (ahora es más literal)

Antes

Le aventabas algo vago como “límpiame este texto” y Claude adivinaba lo que querías: te arreglaba la ortografía, te acomodaba las frases, todo solo.

Ahora

Opus 4.7 hace literal lo que le dices. Ya no generaliza una instrucción de un caso a otro ni infiere lo que no pediste. La ventaja: precisión y menos sorpresas.

Qué hacer

Dale los pasos exactos: “arregla la ortografía y parte las frases largas”. Y si quieres que algo aplique a todo, dile el alcance: “aplícalo a todas las secciones, no solo a la primera”.

Doc oficial · More literal instruction following

2

El largo de la respuesta lo calibra solo

Antes

El modelo soltaba más o menos lo mismo siempre. Ahora juzga qué tan compleja es la tarea: respuestas cortas en preguntas simples, largas en análisis abiertos.

Ahora

Le dices “resúmeme esto” y te suelta una sola línea, porque cree que eso querías. Lo que no le pides, no te lo da.

Qué hacer

Pide el nivel de detalle: “dame el resumen a detalle” o “respuestas concisas, sin contexto de relleno”. Y dile lo que SÍ quieres ver, no solo lo que no — los ejemplos en positivo funcionan mejor.

Doc oficial · Response length and verbosity

3

Deja de gritar (nada de MAYÚSCULAS ni “DEBES”)

Antes

Todos aprendimos a escribirle fuerte: “CRÍTICO: TIENES que hacer esto”, en mayúsculas, para que obedeciera.

Ahora

Anthropic recomienda lo contrario. Con el lenguaje agresivo el modelo se traba y responde peor. Donde decías “CRÍTICO: DEBES usar esta herramienta cuando…”, ahora basta “Usa esta herramienta cuando…”.

Qué hacer

Háblale normal, como a una persona. Y mejor aún: dale el motivo de cada regla. “Nunca uses puntos suspensivos” funciona menos que “esto lo va a leer un lector de voz, por eso nunca uses puntos suspensivos” — Claude generaliza desde la explicación.

Doc oficial · Add context to improve performance

El patrón que une los tres

¿Ya viste el patrón? Los 3 son lo mismo: dale contexto y dile exacto lo que quieres. Claude dejó de adivinar; ahora hace tal cual lo que le pides. Entre mejor le expliques, mejor te sale.

Todo lo de aquí abajo — los 10 pilares, el caso del seguro sueco, las plantillas — sigue vigente y se vuelve más importante con Opus 4.7, justamente porque ahora el modelo te toma la palabra. La fuente completa es la guía oficial de prompting de Anthropic.

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.

1

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.

2

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.

3

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.

4

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.

5

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>

6

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>

7

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.

8

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é.

9

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.

10

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.

v1

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.

v2

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.

1. Task description / role2. Tone context
v3

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.

1. Task description / role2. Tone context3. Background data, documents & images
v4

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.

1. Task description / role2. Tone context3. Background data, documents & images4. Detailed task description & rules7. Immediate task description8. Thinking step-by-step
v5

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.

1. Task description / role2. Tone context3. Background data, documents & images4. Detailed task description & rules7. Immediate task description8. Thinking step-by-step9. Output formatting10. Prefilled response

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.

reglas de oro · lo que aplica a cualquier prompt en 2026

Cinco hábitos que vuelven cualquier prompt mejor con los modelos nuevos

Más allá de los tres cambios de Opus 4.7, la guía de Anthropic repite unas cuantas reglas que aplican a todo lo que le escribes a Claude, programes o no. Son baratas de adoptar y la diferencia se nota desde el primer prompt.

Di lo que SÍ quieres, no lo que NO

Las instrucciones en positivo se siguen mejor que las prohibiciones. En vez de listar lo que debe evitar, describe la forma exacta del resultado que buscas.

“No uses markdown” → “Escribe en prosa fluida, en párrafos completos.”

Dale el motivo de cada instrucción

Cuando explicas por qué algo importa, Claude entiende tu objetivo y generaliza a casos que no nombraste. El motivo vale más que la orden seca.

“Nunca uses puntos suspensivos” → “Esto lo lee un lector de voz que no sabe pronunciarlos, por eso nunca los uses.”

Enséñale con ejemplos, no solo reglas

De 3 a 5 ejemplos bien armados moldean el formato, el tono y la estructura mejor que cualquier párrafo de instrucciones. Que sean variados para que no agarre un patrón que no querías.

Envuelve cada uno en <example>…</example> para que los distinga de tus instrucciones.

“Hazlo” vs “¿puedes sugerir?”

Si pides “¿puedes sugerir cambios?”, a veces solo sugiere y no actúa. Si quieres que haga el cambio, dilo directo. El modelo ahora sigue tu instrucción al pie de la letra.

“¿Puedes sugerir mejoras a esta función?” → “Cambia esta función para que corra más rápido.”

La voz cambió: pídela si la quieres

Opus 4.7 es más directo y opinado: valida menos y usa menos emojis que antes. Si tu marca necesita un tono cálido o cercano, pídelo explícito en lugar de darlo por hecho.

“Usa un tono cálido y colaborativo. Reconoce lo que plantea la persona antes de responder.”

El hilo común: claridad y contexto. Cada regla es una forma distinta de decirle a Claude qué quieres y por qué — que es justo lo que el modelo nuevo premia. Si una respuesta te sale floja, casi siempre la falla no está en el modelo: está en lo que no le dijiste.

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.

prompts copiables · afina Claude para la era 4.7

Cuatro prompts para domar los cambios de Opus 4.7

Estos cuatro toman los tres cambios y las reglas de oro y los convierten en instrucciones listas para pegar: controla el largo, traduce un prompt “a gritos” a tono normal, fuerza el alcance cuando el modelo se queda corto y fija la voz que quieres. Cópialos y rellena los corchetes.

Controla el largo de las respuestas

Opus 4.7 calibra el largo solo. Este prompt le deja explícito cuándo ser conciso y cuándo darte todo a detalle, con ejemplo en positivo.

Quiero controlar el largo de tus respuestas. Opus 4.7 calibra el largo según qué tan compleja juzga la tarea, así que te lo dejo explícito.

ELIGE EL MODO SEGÚN LO QUE TE PIDA:

MODO CONCISO (por defecto):
"Da respuestas concisas y al grano. Sáltate el contexto de relleno y mantén los ejemplos al mínimo. Si una frase no agrega información nueva, bórrala."

MODO A DETALLE (cuando lo pida así):
"Dame la respuesta a detalle: explica el porqué de cada paso, incluye ejemplos y cubre los casos límite que se te ocurran."

REGLA EXTRA:
No me digas solo lo que NO debes hacer; muéstrame con un ejemplo corto cómo se ve el largo correcto antes de empezar.

Háblale normal — reescribe tu prompt gritón

Pega un prompt lleno de MAYÚSCULAS y “DEBES”. Claude lo devuelve en tono normal, con el motivo de cada regla y las prohibiciones convertidas en instrucciones positivas.

Tengo un prompt escrito “a gritos” (MAYÚSCULAS, “DEBES”, “CRÍTICO”, signos de admiración) porque así le hablaba a los modelos viejos. Con Opus 4.7 eso lo hace responder peor.

MI PROMPT ACTUAL:
"""
[pega aquí tu prompt tal cual, con todo y mayúsculas]
"""

REESCRÍBELO ASÍ:
1. Tono normal, como si le explicaras a una persona capaz. Sin MAYÚSCULAS de énfasis ni “DEBES / TIENES QUE / CRÍTICO”.
2. Cada regla importante con su motivo en una línea (por qué importa), porque eso me da mejores resultados que la orden seca.
3. Las prohibiciones conviértelas en instrucciones en positivo (qué SÍ quiero, no qué no).
4. Entrégame el prompt nuevo en un bloque copiable y, debajo, una línea de qué cambiaste y por qué.

Dale el alcance explícito

El modelo ya no extiende una instrucción a todo por su cuenta. Esta plantilla lo obliga a aplicar la tarea a cada elemento, no solo al primero, y a confirmarlo.

Opus 4.7 es literal: si le digo algo para “un” caso, no lo extiende solo a los demás. Quiero que apliques una instrucción a TODO, no solo al primer elemento.

LA TAREA:
"""
[describe qué quieres y sobre qué (todas las secciones, todos los archivos, cada fila, etc.)]
"""

HAZLO ASÍ:
1. Aplica la instrucción a cada elemento del conjunto, no solo al primero. Si hay 10 secciones, son las 10.
2. Antes de empezar, dime en una línea cuántos elementos detectaste y cuáles vas a tocar.
3. Al final, confirma que ninguno se quedó sin procesar.

Pide la voz que quieres

Opus 4.7 es más directo y valida menos por defecto. Elige voz cálida o voz ejecutiva y mantenla en toda la conversación.

Quiero fijar la voz de tus respuestas. Opus 4.7 por defecto es más directo y con menos validación, así que te la pido explícita.

ELIGE SEGÚN LA QUE NECESITE:

VOZ CÁLIDA / CERCANA:
"Usa un tono cálido y colaborativo. Reconoce lo que planteo antes de responder y escribe como si habláramos en persona, sin sonar a manual."

VOZ DIRECTA / EJECUTIVA:
"Ve al grano. Sin preámbulos del tipo 'claro, aquí tienes'. Afirma con seguridad y deja las salvedades solo cuando de verdad importen."

REGLA EXTRA:
Mantén esta voz en toda la conversación, no solo en la primera respuesta.

Cómo combinarlos: mete el de largo y el de voz en tu system prompt o en las instrucciones de tu proyecto para que apliquen siempre. El de “háblale normal” úsalo una vez para limpiar prompts viejos que arrastras de los modelos anteriores. El de alcance, cada vez que una tarea toque varios elementos a la vez.

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.

¿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.