Los secretos de Anthropic para escribir un buen prompt

Hace un tiempo, Anthropic compartió en una charla interna algo que rara vez se ve: la plantilla que usan sus propios equipos para construir prompts en producción. La diapositiva en torno a la que gira la charla divide el proceso en diez bloques, en un orden concreto, y lo ilustra con un ejemplo real: un asistente de orientación profesional llamado Joe, creado para una empresa ficticia, AdAstra Careers.

No es una lista de trucos sueltos. Es la estructura que meten dentro del prompt de sistema cuando necesitan que funcione bien a la primera, sin margen para respuestas raras delante de usuarios reales.

Los diez bloques, uno por uno

1. Contexto de la tarea. La primera frase le dice al modelo quién es: un coach de carrera creado por AdAstra Careers. También explica la situación, para que entienda que los usuarios llegarán confundidos si no responde en personaje.

2. Contexto de tono. Una sola línea: mantener un tono de atención al cliente, cercano. Nada más. Anthropic separa esto del contexto de la tarea a propósito, para que el modelo no mezcle «qué hacer» con «cómo sonar».

3. Datos de fondo, documentos e imágenes. Aquí entra la guía de orientación profesional que Joe debe consultar, inyectada con una variable tipo {{DOCUMENT}}. Es la parte donde metes el conocimiento externo (manuales, políticas, catálogos) que el modelo necesita para no inventarse cosas.

4. Descripción detallada de la tarea y reglas. La parte larga: mantenerse siempre en personaje, qué decir si no entiende una pregunta, qué responder si alguien pregunta algo irrelevante al tema. Son los casos límite, los que si no cubres, el modelo improvisa mal.

5. Ejemplos. Un ejemplo etiquetado con <example> de una interacción estándar: el usuario pregunta cómo se creó Joe, y Joe responde presentándose. Fija el formato y el tono mejor que cualquier descripción abstracta. Un buen ejemplo vale más que tres párrafos explicando cómo debe sonar el bot.

6. Historial de conversación. Se inyecta con otra variable, {{HISTORY}}, y puede llegar vacía si es el primer mensaje. Separarlo de la pregunta actual evita que el modelo confunda lo que ya se dijo con lo que se está preguntando ahora.

7. Petición inmediata. La pregunta real del usuario, envuelta en etiquetas <question>. Llega casi al final del prompt, no al principio.

8. Pensar paso a paso. Una instrucción explícita: piensa la respuesta antes de responder. Es el chain-of-thought de siempre, colocado justo antes de pedir la respuesta final.

9. Formato de salida. Le piden que ponga la respuesta entre etiquetas <response></response>. Así, la web o la app que procese la salida después puede extraer solo el texto útil sin parsear ruido.

10. Respuesta prellenada. El turno del asistente empieza ya con <response> escrito. Un truco simple: si el modelo ve que su respuesta arranca con esa etiqueta, es mucho más difícil que se salga del formato pedido.

Por qué el orden no es casualidad

Lo que más llama la atención de la diapositiva no son los bloques en sí, sino dónde los colocan. El ejemplo y el historial van casi al final, justo antes de la pregunta real. Las reglas de comportamiento, en cambio, van bastante antes, junto a los documentos de referencia.

Tiene sentido si piensas en cómo un modelo pondera lo que acaba de leer frente a lo que leyó al principio del prompt. Cuanto más cerca esté algo del punto donde el modelo empieza a generar, más peso tiene en la respuesta inmediata. Por eso la pregunta va casi al final, y por eso el ejemplo de formato se coloca justo antes del historial: interesa que lo último que «vea» el modelo antes de escribir sea el patrón exacto que debe seguir.

Cómo aplicarlo en tus propios prompts

No hace falta copiar los diez bloques literalmente en cada prompt que escribas. Para tareas simples, con dos o tres sobra. Pero para un asistente que va a hablar con usuarios reales, sin supervisión, cubrir estos diez puntos evita la mayoría de los problemas típicos: que se salga de personaje, que invente información, que rompa el formato que espera tu aplicación.

Los bloques mas infravalorados y que mas se suelen omitir serían el 4 y el 8. Las reglas explícitas sobre qué hacer cuando el modelo no sabe qué responder evitan que improvise mal justo en el peor momento. Y pedirle que piense antes de contestar, aunque parezca un paso menor, cambia bastante la calidad de la salida en tareas que requieren algo de razonamiento. Estos bloques son una forma muy breve y concisa de aprender como funciona Claude.


Si te ha gustado este artículo y quieres recibir más contenido sobre innovación y tecnología directamente en tu correo, suscríbete a nuestra newsletter y mantente siempre actualizado. No somos de los que llenan tu bandeja, solo compartimos los lunes.

RELACIONADOS