El prompt que fallaba una de cada tres veces, hasta que alguien cambió los guiones por etiquetas
Mismo contenido, mismo modelo, mismo resultado esperado. La única diferencia fue sustituir el formato markdown por etiquetas XML — y la tasa de errores cayó de forma medible.
El prompt que funcionaba, hasta que dejaba de funcionar
Un prompt de clasificación de tickets de soporte llevaba semanas funcionando razonablemente bien: instrucciones arriba, tres ejemplos resueltos en medio, formato de salida al final, todo separado con títulos en markdown y guiones. El problema apareció cuando el prompt creció — más ejemplos, más matices, más excepciones — y la tasa de errores empezó a subir sin que nadie tocara el contenido de fondo. La causa no estaba en las instrucciones, sino en cómo estaban separadas: con un prompt largo, markdown deja de bastar para que el modelo distinga con precisión dónde termina un ejemplo y dónde empieza el siguiente bloque de instrucciones.
La solución no fue reescribir el contenido. Fue cambiar el formato: sustituir los títulos con almohadilla y las listas con guiones por etiquetas XML que delimitan cada sección sin ambigüedad. Claude interpreta las etiquetas XML con más precisión que el markdown habitual cuando un prompt tiene varias partes que no deben mezclarse — instrucciones, contexto, ejemplos y formato de salida —, precisamente porque el modelo fue entrenado para reconocer y respetar esa estructura de forma explícita, algo que markdown, pensado originalmente para lectura humana y no para parseo por un modelo, no garantiza igual de bien.
Cómo se ve un prompt con etiquetas en la práctica
La diferencia no está en el contenido del prompt, sino en cómo se separa. En lugar de un bloque de texto corrido con instrucciones y ejemplos mezclados, la estructura recomendada separa cada elemento en su propia etiqueta: un bloque <contexto> con la información de fondo necesaria, un bloque <instrucciones> con la tarea concreta, un bloque <ejemplos> con entre tres y cinco casos resueltos que muestren el patrón esperado, y un bloque <formato_salida> que defina exactamente cómo debe entregarse la respuesta. Claude procesa cada etiqueta como una unidad independiente, lo que reduce la probabilidad de que mezcle instrucciones con ejemplos o interprete un ejemplo como si fuera parte del contexto.
El ángulo poco contado: forzar el razonamiento antes de la respuesta
Aquí está la técnica que menos se explica bien fuera de la documentación técnica: pedir explícitamente a Claude que razone dentro de una etiqueta antes de entregar la respuesta final reduce de forma medible los errores en tareas complejas. En vez de pedir directamente el resultado, se le pide que primero piense dentro de una etiqueta <razonamiento> y solo después entregue la respuesta dentro de una etiqueta <respuesta>.
Esto no es lo mismo que activar el modo de pensamiento extendido del modelo — es una técnica de prompting que funciona incluso sin esa función activada, porque obliga al modelo a mostrar su razonamiento antes de comprometerse con una conclusión, del mismo modo que a una persona le cuesta más equivocarse cuando tiene que explicar su razonamiento paso a paso antes de dar una respuesta final, en lugar de soltarla directamente.
Cuándo usar pensamiento extendido, y cuándo apagarlo
El modo de pensamiento extendido, disponible de forma nativa en los modelos Claude actuales, asigna al modelo un presupuesto de razonamiento interno antes de generar la respuesta final. No es un simple "piensa paso a paso" escrito en el prompt: es un modo distinto donde el modelo razona en un espacio de contexto dedicado y luego entrega una respuesta limpia, sin mostrar todo el proceso intermedio salvo que se solicite explícitamente.
El matiz que más se pasa por alto es que el pensamiento extendido no siempre mejora el resultado. Para tareas simples añade latencia y coste sin mejorar la calidad de la respuesta. Tiene sentido activarlo en tareas que de verdad lo requieren — análisis complejo, modelado financiero, decisiones de arquitectura de software, o cualquier triage con variables en conflicto —, no en una tarea de redacción simple o una pregunta directa, donde casi siempre es coste añadido sin beneficio real.
Few-shot: la técnica de mayor rendimiento por esfuerzo invertido
Entre todas las técnicas de prompting, dar ejemplos concretos sigue siendo una de las que más mejora el resultado por el esfuerzo que exige. La clave no es dar un único ejemplo, sino entre tres y cinco ejemplos diversos entre sí, envueltos en su propia etiqueta, que muestren el rango de casos que se espera cubrir, no solo el más fácil. Un error habitual es dar ejemplos casi idénticos entre sí: eso enseña al modelo a repetir un patrón estrecho, en vez de generalizar la regla real que se quiere aplicar. Un ejemplo simple, uno con una excepción y uno con un caso límite enseñan mejor la regla que tres variaciones del mismo caso sencillo.
Por qué importa hoy
Ninguna de estas técnicas depende de "saber hablarle bien a la IA" en un sentido vago: son ajustes estructurales concretos — etiquetas XML, razonamiento forzado antes de la respuesta, ejemplos diversos, pensamiento extendido solo cuando la tarea lo justifica — que se pueden aplicar hoy mismo a cualquier prompt que ya se esté usando. La diferencia entre un prompt que funciona la mayoría de las veces y uno que funciona de forma consistente casi siempre está en estos detalles de estructura, no en encontrar la frase mágica que tantas guías prometen y pocas entregan.