IA /

IA: Prompts Vagos vs Prompts profesionales

Diferencias entre Promtps

Un prompt vago se caracteriza por instrucciones imprecisas, sin contexto ni criterios claros, lo que deja demasiado espacio a la interpretación y suele producir respuestas genéricas o poco útiles. En cambio, un prompt profesional define con precisión el objetivo, el tono, el formato y las restricciones, permitiendo obtener resultados coherentes, específicos y alineados con la intención real del usuario.

Además, los prompts vagos suelen omitir detalles clave sobre el propósito o el público, mientras que los prompts profesionales incorporan información contextual que guía la generación de contenido hacia un resultado más estratégico y de mayor calidad. Si quieres profundizar, puedo mostrarte ejemplos de prompts vagos o de prompts profesionales.

Ejemplo 01: Manejo de errores

Prompt vago:

  1.  Añade manejo de errores al servidor
[$[Get Code]]

Con este prompt, Claude suele tomar decisiones muy diversas: a veces añade un try-catch genérico, a veces crea un middleware complejo con clases de error personalizadas, a veces toca archivos que no debería. El resultado es impredecible porque "manejo de errores" puede significar cien cosas distintas.

Versión profesional:

  1.     Contexto: Snap es un servidor Express + TypeScript. Solo tiene
  2.     un endpoint GET /health. Próximamente añadiremos más rutas.
  3.  
  4.     Tarea: Añade dos middlewares de Express al final de la cadena:
  5.     - Un handler para rutas no encontradas que devuelva 404
  6.       con un JSON indicando que la ruta no existe
  7.     - Un handler global de errores que capture cualquier excepción
  8.       no manejada y devuelva 500 con un mensaje genérico
  9.       (sin exponer detalles internos)
  10.  
  11.     Restricciones:
  12.     - No modifiques el endpoint /health
  13.     - No instales dependencias nuevas, Express ya soporta esto
  14.     - En desarrollo (NODE_ENV !== "production") el error handler
  15.       puede incluir el mensaje del error; en producción no
  16.  
  17.     Verificación: Añade tests que comprueben que una ruta
  18.     inexistente devuelve 404, y que el servidor no se cae
  19.     ante un error inesperado. Ejecútalos.
[$[Get Code]]

Por qué funciona mejor: El contexto es mínimo pero suficiente (Express + TS, solo tiene /health). La tarea especifica exactamente qué dos cosas hacer. Las restricciones evitan que Claude se desborde con dependencias o cambie código existente. La verificación es concreta y ejecutable.

Ejemplo 02: Manejo creación de módulo

Prompt vago:

  1.     Haz un módulo de configuración
[$[Get Code]]

Con este prompt, Claude puede crear desde un simple objeto con constantes hasta un sistema completo con archivos .env, dotenv, validación de variables, schemas tipados con Zod... todo a su criterio. El estudiante no controla qué obtiene.

Versión profesional:

  1.     Contexto: Snap es un servidor Express + TypeScript. Ahora mismo
  2.     el puerto y otros valores están hardcodeados en el código.
  3.  
  4.     Tarea: Crea un módulo src/config.ts que centralice la
  5.     configuración de la aplicación. Debe leer de variables de
  6.     entorno con fallbacks sensatos para desarrollo:
  7.     - Puerto del servidor (default 3000)
  8.     - Entorno (development/production, default development)
  9.     - Nombre de la base de datos SQLite (default "snap.db")
  10.  
  11.     Restricciones:
  12.     - No instales dotenv ni ninguna dependencia extra;
  13.       usa process.env directamente
  14.     - Exporta un objeto tipado con TypeScript, no variables sueltas
  15.     - Si una variable obligatoria falta en producción, que lance
  16.       un error claro al arrancar (no en mitad de una petición)
  17.  
  18.     Verificación: Escribe un test que compruebe que el módulo
  19.     devuelve los valores por defecto cuando no hay variables de
  20.     entorno configuradas, y que lanza error si falta una variable
  21.     obligatoria en producción. Ejecútalos.
[$[Get Code]]

Por qué funciona mejor: El prompt vago no dice qué configurar ni cómo. El profesional especifica exactamente qué valores centralizar, la estrategia técnica (process.env directo, sin dotenv), el comportamiento en producción, y cómo verificar que funciona.

Ejemplo 03: Añadir funcionalidad de LOGS

Prompt vago:

  1.     Añade logs al servidor
[$[Get Code]]

Este es especialmente problemático: Claude puede instalar Winston, Pino, Morgan, o cualquier librería de logging. Puede añadir logs a nivel de petición, de aplicación, de errores, o de todos. Puede crear archivos de log, rotar logs, configurar niveles... El resultado depende enteramente de su interpretación.

Versión profesional:

  1.     Contexto: Snap es un servidor Express + TypeScript en fase
  2.     inicial. No tiene logging de peticiones todavía.
  3.  
  4.     Tarea: Añade un middleware que registre cada petición HTTP
  5.     entrante con: método, ruta, código de respuesta, y tiempo
  6.     que tardó en milisegundos. Formato de ejemplo:
  7.     GET /health → 200 (12ms)
  8.  
  9.     Restricciones:
  10.     - Usa console.log, no instales librerías de logging
  11.       (ya las añadiremos cuando el proyecto lo necesite)
  12.     - El middleware debe ir al principio de la cadena para
  13.       capturar todas las peticiones
  14.     - No loguees el body de las peticiones (puede tener passwords)
  15.  
  16.     Verificación: Arranca el servidor, haz un curl a /health,
  17.     y muéstrame que el log aparece en la terminal con el formato
  18.     esperado.
[$[Get Code]]

Por qué funciona mejor: En vez del inabarcable "añade logs", el prompt define exactamente qué logear (peticiones HTTP), qué datos incluir (método, ruta, status, tiempo), qué formato (el ejemplo concreto), y qué NO hacer (no instalar dependencias, no logear bodies). Claude tiene todo lo necesario para producir exactamente lo que queremos.

Nota: Observa que en los tres pares la versión profesional no es más larga por capricho. Cada línea extra elimina una decisión ambigua que Claude tendría que tomar por su cuenta. El tiempo que inviertes escribiendo un prompt preciso lo ahorras no teniendo que corregir, rehacer o descartar resultados que no eran lo que esperabas. Además, reducirás el número de tokens que vas a utilizar, lo que en última instancia se traduce en un menor coste económico.

Patrones de prompt para Claude Code

Claude Code es un agente que toma decisiones: qué archivos leer, qué enfoque seguir, qué herramientas usar. La calidad de esas decisiones depende directamente de la calidad de tus instrucciones. Este artículo recoge los patrones de prompt más útiles para el trabajo diario con Claude Code, todos construidos sobre una misma estructura.

La estructura detrás de cada patrón

Todo prompt profesional se compone de hasta cinco piezas:

  • Contexto: Qué necesita saber Claude de la situación.
  • Tarea: Qué tiene que hacer exactamente.
  • Restricciones: Qué no debe hacer o qué límites tiene.
  • Formato: Cómo quieres el resultado.
  • Verificación: Cómo confirmar que está bien.

No todos los prompts necesitan las cinco. Un fix rápido puede necesitar solo tarea y verificación. Pero cuando el resultado no es el esperado, casi siempre falta una de estas piezas. Cada patrón de este artículo es una forma concreta de combinar estos componentes para un tipo de tarea específico.

1. Implementar una feature

El patrón más frecuente. Quieres añadir funcionalidad nueva a un proyecto existente.

Esquema

  1.     Contexto: [Qué proyecto es, qué stack usa, qué existe ya]
  2.  
  3.     Tarea: Implementa [feature] con estos requisitos:
  4.     - [requisito concreto 1]
  5.     - [requisito concreto 2]
  6.     - [requisito concreto 3]
  7.  
  8.     Restricciones:
  9.     - [qué no cambiar]
  10.     - [patrones del proyecto a respetar]
  11.     - [dependencias que no instalar]
  12.  
  13.     Verificación: [tests a crear y ejecutar, o comando para comprobar]
[$[Get Code]]

Ejemplo

  1.     Contexto: Snap es un acortador de URLs. Express + TypeScript + SQLite.
  2.     Ya tiene endpoints de creación y redirect de URLs funcionando.
  3.  
  4.     Tarea: Implementa tracking de clicks. Cada vez que alguien visita
  5.     un código corto y es redirigido, registra el click con timestamp,
  6.     IP y user-agent. Añade un endpoint para que el dueño de una URL
  7.     pueda consultar el total de clicks y un desglose por día de los
  8.     últimos 7 días.
  9.  
  10.     Restricciones:
  11.     - El redirect no debe volverse más lento. Registra el click
  12.       después de enviar la respuesta al usuario.
  13.     - Sigue la misma estructura de módulos que ya tiene el proyecto.
  14.     - No cambies la interfaz de los endpoints existentes.
  15.  
  16.     Verificación: Escribe tests que cubran el registro de clicks
  17.     y la consulta de estadísticas. Ejecuta todos los tests del
  18.     proyecto al terminar.
[$[Get Code]]

Por qué funciona

El contexto evita que Claude invente una estructura propia. Los requisitos son concretos y contables (puedes verificar cada uno). Las restricciones protegen lo que ya funciona. Y la verificación cierra el ciclo: si los tests no pasan, Claude lo sabe antes que tú.

2. Depurar un problema

El error más común al reportar un bug a Claude es decir "no funciona" y esperar que adivine. Claude necesita lo mismo que necesitaría un compañero de equipo: el error exacto, dónde ocurre y qué estabas haciendo.

  1.     Contexto: [Qué estaba haciendo cuando ocurrió]
  2.  
  3.     Tarea: Tengo este error:
  4.     [pegar error completo con stack trace]
  5.     Archivo: [archivo y línea si lo sabes]
  6.  
  7.     Formato: Antes de corregir nada, necesito que:
  8.     1. Identifica la causa raíz, no el síntoma
  9.     2. Explica por qué ocurre
  10.     3. Propón el fix y justifícalo
  11.     4. ¿Qué más podría verse afectado?
  12.  
  13.     Verificación: Añade un test que reproduzca el bug antes del fix
  14.     y que pase después. Ejecuta todos los tests.
[$[Get Code]]

Ejemplo

  1.     Contexto: Estoy probando el registro de usuarios en Snap.
  2.  
  3.     Tarea: Cuando intento registrar un usuario con el email
  4.     "Ana@Email.COM" y después otro con "ana@email.com", el segundo
  5.     registro se crea sin error. Debería fallar porque es el mismo
  6.     email. El error no lanza excepción, simplemente crea un duplicado.
  7.  
  8.     Formato: Antes de corregir:
  9.     1. Identifica la causa raíz, no el síntoma
  10.     2. Explica por qué ocurre
  11.     3. Propón el fix y justifícalo
  12.     4. ¿Qué más podría verse afectado?
  13.  
  14.     Verificación: Escribe un test que registre el mismo email con
  15.     distintas mayúsculas y verifique que el segundo intento falla.
  16.     Ejecuta los tests.
[$[Get Code]]

Por qué funciona

El escenario reproducible vale más que cualquier descripción. El formato de "antes de corregir" obliga a Claude a pensar antes de actuar, lo que produce fixes más precisos. Y pedir que identifique efectos secundarios previene que un arreglo cree dos problemas nuevos.

3. Refactorizar

Refactorizar es el patrón donde más fácil es que Claude se desborde. Sin restricciones claras, "refactoriza este módulo" puede convertirse en una reescritura completa que rompe media aplicación. La clave es definir qué no debe cambiar.

  1.     Contexto: [Qué módulo y por qué quieres refactorizarlo]
  2.  
  3.     Tarea: Refactoriza [archivo/módulo] para [objetivo concreto].
  4.  
  5.     Restricciones:
  6.     - La API pública NO debe cambiar
  7.     - Los tests existentes deben seguir pasando sin modificarlos
  8.     - Sigue el patrón [patrón del proyecto]
  9.  
  10.     Formato: Antes de tocar código:
  11.     1. Muéstrame qué cambiarías y por qué
  12.     2. Lista los archivos afectados
  13.     3. Identifica riesgos
  14.  
  15.     Verificación: Ejecuta todos los tests sin cambiarlos.
  16.     Si alguno falla, el refactoring rompió algo.
[$[Get Code]]

Ejemplo

    Contexto: En Snap hay lógica de validación dispersa por varios
    servicios: validación de URLs en el servicio de URLs, validación
    de emails en el servicio de auth, validación de alias en otro
    archivo. Quiero centralizarla.

    Tarea: Extrae toda la validación a un módulo dedicado que los
    demás servicios importen.

    Restricciones:
    - Los endpoints deben devolver exactamente los mismos errores
      que antes. Ningún cliente debería notar el cambio.
    - Los tests actuales deben pasar tal cual, sin tocarlos.
    - El módulo de validación debe seguir la misma convención de
      naming y exports que los módulos existentes.

    Formato: Antes de implementar, muéstrame:
    1. Muéstrame qué cambiarías y por qué
    2. Lista los archivos afectados
    3. Identifica riesgos

    Verificación: Ejecuta todos los tests del proyecto. Si pasan
    sin cambios, el refactoring es correcto.

Por qué funciona

La restricción "los tests existentes pasan sin cambiarlos" es la red de seguridad más potente que puedes darle a Claude. Convierte un cambio potencialmente destructivo en algo verificable objetivamente. Y pedir el plan antes de la implementación te da un punto de control donde puedes detener un refactoring mal planteado antes de que toque un solo archivo.

4. Explorar un proyecto

Este patrón no produce código. Produce comprensión. Es el primer paso antes de cualquier cambio significativo, y es el que más gente se salta.

  1.  
  2.     Tarea: Analiza [proyecto/módulo/archivo] y responde:
  3.     - [pregunta sobre estructura]
  4.     - [pregunta sobre patrones]
  5.     - [pregunta sobre dependencias]
  6.     - [pregunta sobre convenciones]
  7.  
  8.     Formato: [Si quieres un diagrama, una lista, una explicación
  9.     narrativa, etc.]
  10.  
  11.     Restricciones: No modifiques nada. Solo lectura.
[$[Get Code]]

Ejemplo

  1.     Tarea: Analiza el proyecto Snap tal como está y responde:
  2.     1. ¿Qué patrón sigue para separar rutas de lógica de negocio?
  3.     2. ¿Cómo se inicializa y se accede a la base de datos?
  4.     3. ¿Qué convenciones de naming usan los archivos y funciones?
  5.     4. Si quiero añadir un módulo nuevo (ej: "notifications"),
  6.        ¿qué archivos necesitaría crear para seguir el mismo patrón?
  7.  
  8.     Formato: Dame un resumen breve por pregunta y un diagrama ASCII
  9.     de la estructura de carpetas relevante.
  10.  
  11.     Restricciones: No crees ni modifiques ningún archivo.
[$[Get Code]]

Por qué funciona

Cuando Claude explora antes de implementar, ancla sus decisiones en la realidad del código en lugar de en suposiciones genéricas. El resultado directo: el código que genere después será consistente con lo que ya existe. El resultado indirecto: tú también entiendes mejor tu propio proyecto al leer el análisis.

5. Escribir tests

Los tests no son algo que "se añade al final". Pero cuando necesitas generar cobertura para código existente, hay una forma de pedirlo que produce tests útiles en vez de tests superficiales que solo verifican que "la función no lanza error".

  1.     Contexto: [Qué módulo/servicio quieres testear y qué hace]
  2.  
  3.     Tarea: Genera tests para [archivo]. Para cada función pública:
  4.     - Un test del caso normal (happy path)
  5.     - Un test de caso edge [ejemplos relevantes]
  6.     - Un test de error [ejemplos relevantes]
  7.  
  8.     Restricciones:
  9.     - [framework de testing a usar]
  10.     - [patrones de test del proyecto]
  11.  
  12.     Verificación: Ejecuta los tests. Después ejecuta con cobertura
  13.     y muéstrame qué porcentaje tiene el archivo.
[$[Get Code]]

Ejemplo

  1.     Contexto: El servicio de autenticación de Snap tiene funciones
  2.     para register y login. Usa bcrypt para passwords y JWT para tokens.
  3.  
  4.     Tarea: Genera tests para src/auth/auth.service.ts. Para cada función:
  5.     - Happy path: registro exitoso devuelve usuario y token,
  6.       login exitoso devuelve token válido
  7.     - Edge cases: email con mayúsculas mezcladas, password en el
  8.       límite mínimo de longitud, email con espacios alrededor
  9.     - Errores: email duplicado, password incorrecto, email
  10.       inexistente, campos vacíos
  11.  
  12.     Restricciones:
  13.     - Usa Vitest con describe/it
  14.     - Cada test debe ser independiente (no depender del orden)
  15.  
  16.     Verificación: Ejecuta los tests. Después ejecuta vitest --coverage
  17.     y muéstrame la cobertura de auth.service.ts.
[$[Get Code]]

Por qué funciona

Especificar las tres categorías (happy path, edge, error) con ejemplos concretos produce tests que realmente encuentran bugs. Sin esos ejemplos, Claude tiende a generar tests genéricos que verifican lo obvio. La verificación con cobertura cierra el ciclo y te dice si quedaron ramas sin cubrir.

6. Documentar

El patrón más sencillo en estructura pero el que más se beneficia de especificar el formato. Sin indicar qué quieres, Claude produce documentación genérica que no ayuda a nadie.

  1.     Contexto: [Qué va a leer esta documentación y para qué]
  2.  
  3.     Tarea: Genera documentación para [archivo/módulo/API] incluyendo:
  4.     - [qué secciones necesitas]
  5.     - [qué nivel de detalle]
  6.  
  7.     Formato: [Markdown, JSDoc, README section, etc.]
  8.     [Incluir o no ejemplos de uso]
  9.  
  10.     Verificación: Lee el resultado y verifica que cubre todos los
  11.     [endpoints/funciones/módulos] que existen actualmente.
[$[Get Code]]

Ejemplo

  1.     Contexto: Nuevos desarrolladores van a incorporarse al proyecto
  2.     Snap y necesitan una referencia de la API para empezar a trabajar.
  3.  
  4.     Tarea: Genera un archivo docs/API.md con la documentación completa:
  5.     - Descripción breve del proyecto
  6.     - Instrucciones para instalar, ejecutar y testear
  7.     - Cada endpoint: método HTTP, ruta, si requiere autenticación,
  8.       qué parámetros espera, qué devuelve, y los posibles errores
  9.     - Un ejemplo con curl para cada endpoint
  10.  
  11.     Formato: Markdown con secciones por módulo (Auth, URLs, Dashboard).
  12.  
  13.     Verificación: Compara el archivo generado con las rutas registradas
  14.     en el código. Si falta algún endpoint, añádelo.
[$[Get Code]]

Por qué funciona

Definir quién va a leer la documentación cambia radicalmente el resultado. "Documentación para onboarding de desarrolladores" produce algo distinto a "documentación para el equipo de QA" o "documentación para el cliente". Y la verificación cruzada contra el código real previene la documentación desactualizada desde el minuto cero.

7. Pedir justificación

Este no es un patrón de implementación. Es un patrón de revisión. Lo usas después de que Claude haya hecho algo para entender por qué tomó esas decisiones y si hay alternativas mejores.

  1.     Tarea: Sobre [la implementación que acabas de hacer]:
  2.     1. ¿Qué alternativas consideraste y por qué elegiste esta?
  3.     2. ¿Qué trade-offs tiene tu decisión?
  4.     3. ¿Qué podría fallar con este enfoque?
  5.     4. ¿Qué harías diferente con más tiempo o a mayor escala?
[$[Get Code]]

Ejemplo

  1.     Sobre la implementación del tracking de clicks:
  2.     1. ¿Qué alternativas consideraste para registrar los clicks
  3.        sin bloquear el redirect?
  4.     2. ¿Qué pasa si la escritura en base de datos falla? ¿Se pierde
  5.        el click silenciosamente?
  6.     3. Si una URL recibe 10.000 clicks por segundo, ¿qué parte
  7.        del sistema falla primero?
  8.     4. Si tuvieras que escalar esto para millones de URLs,
  9.        ¿qué cambiarías de la arquitectura?
[$[Get Code]]

Por qué funciona

Claude no suele explicar sus decisiones a menos que se lo pidas. Y muchas veces la primera solución que propone es correcta pero no es la mejor. Este patrón convierte a Claude en un revisor de su propio código. Las respuestas te ayudan a decidir si aceptas la implementación tal cual, si pides cambios, o si necesitas un enfoque completamente distinto.

Combinando patrones: la cadena

Los patrones no se usan aislados. Una tarea compleja es una secuencia donde cada prompt usa un patrón distinto:

  • Explorar → "Analiza cómo funciona el módulo X"
  • Implementar → "Siguiendo ese patrón, añade Y"
  • Tests → "Genera tests para lo que acabas de implementar"
  • Justificar → "¿Qué alternativas consideraste?"
  • Documentar → "Actualiza la documentación con los cambios"

La regla es que cada prompt de la cadena produce algo que puedes verificar antes de lanzar el siguiente. Si no puedes comprobar el resultado, el paso es demasiado grande o le falta el componente de verificación.

Con el tiempo, estos patrones dejan de ser plantillas que consultas y se convierten en una forma de pensar. No te preguntas "¿qué patrón uso?", sino que naturalmente incluyes contexto, restricciones y verificación en cada instrucción. Eso es lo que separa un uso casual de Claude Code de un uso profesional.

IA : Prompts : Claude : Copilot : Prompts

Última modificación de la página el 20 May 2026 a las 19h01
Powered by PmWiki