Hay decenas de “técnicas de prompting” flotando por internet. La mayoría son ruido. Estas cinco son las que uso en producción y que tienen impacto medible.
1. Rol + contexto específico, no genérico
“Eres un experto en X” es demasiado vago. El rol útil incluye contexto específico del dominio y las restricciones que aplican.
En lugar de: "Eres un experto en TypeScript", prueba: "Eres un senior engineer revisando código TypeScript para producción. El codebase usa Node.js 20, strict mode, y Drizzle ORM. Priorizas la seguridad sobre la brevedad." La diferencia en calidad de output es notable.
2. Output format explícito
Si no dices cómo quieres el output, Claude elegirá. A veces elige bien; a menudo no. Especifica: tipo (lista, JSON, código, markdown), longitud aproximada, y qué incluir/excluir.
"Responde con un JSON array. Cada objeto tiene: { error: string, severity: 'low'|'medium'|'high', fix: string }. Sin explicaciones adicionales."
3. Chain-of-thought para tareas complejas
Para razonamiento complejo, pedir el proceso explícitamente mejora la calidad del resultado. "Piensa paso a paso antes de responder" activa un modo de razonamiento más cuidadoso. Es especialmente útil en debugging y análisis de código donde el primer impulso suele ser incorrecto.
4. Ejemplos few-shot para formato exacto
Cuando el formato importa (y casi siempre importa), un ejemplo vale más que mil palabras de descripción. Muestra input → output esperado antes de dar la tarea real. Con dos o tres ejemplos, Claude replica el patrón con alta fidelidad.
5. Restricciones negativas explícitas
“No hagas X” es tan importante como “haz Y”. Las restricciones negativas evitan comportamientos por defecto que no quieres: "No expliques el código que generes", "No uses comentarios", "No añadas error handling innecesario".
Sin restricciones explícitas, Claude tiende a ser “helpful” añadiendo cosas que no pediste. En un pipeline automatizado eso es ruido, no valor.