Prompt Engineering Profesional

# Por qué funcionan (o fallan) los prompts > Curso: **Prompt Engineering Profesional** · Módulo 1: **Principios del prompting profesional** · Rol: **Comprender y preparar** ## Empieza aquí Al terminar podrás explicar y aplicar «Por qué funcionan (o fallan) los prompts» aunque hoy no conozcas la herramienta. **Qué harás en esta lección:** Construye el modelo mental y deja listo el entorno mínimo. **Primera victoria:** En los primeros diez minutos tendrás una primera versión de «Por qué funcionan (o fallan) los prompts» y sabrás qué comprobar antes de confiar. **Cómo sabrás que has terminado:** La lección termina con una parte utilizable de «Especificación de prompt con entrada, reglas, salida y criterios», tres pruebas y una decisión documentada. ## Explicación desde cero Un modelo responde a patrones estadísticos: tu prompt activa unas zonas de su "conocimiento" y desactiva otras. Por eso "escribe un email" produce mediocridad (activa el patrón medio de todos los emails del mundo) y "escribe un email como director comercial que debe rechazar un descuento sin perder al cliente" produce calidad. Entender este mecanismo te permite razonar cualquier técnica en vez de memorizar recetas. Esta lección contribuye a convertir peticiones vagas en especificaciones reproducibles y evaluadas y prepara una parte de: Biblioteca de prompts de producción con esquemas, dataset, rúbricas, pruebas adversariales y registro de versiones. No necesitas memorizar nombres de herramientas. Debes aprender a reconocer una entrada, una transformación, una salida y una comprobación. En «Por qué funcionan (o fallan) los prompts» esas cuatro piezas terminan dentro de **Especificación de prompt con entrada, reglas, salida y criterios**. ## Preparación paso a paso 1. **Crea el espacio de trabajo:** Crea una página o carpeta con el nombre «Prompt Engineering Profesional / M1 / Por qué funcionan (o fallan) los prompts». Comprobación: Ves secciones Entrada, primera versión, Pruebas, versión mejorada y Decisión. 2. **Copia el caso ficticio:** Usa la entrada de práctica incluida en la etapa conjunto de herramientas. Comprobación: La entrada no contiene nombres, claves ni datos reales. 3. **Define el éxito:** Escribe qué aspecto de «Especificación de prompt con entrada, reglas, salida y criterios» construirás hoy. Comprobación: El resultado puede observarse y puntuarse. ## Método profesional del módulo **Definir contrato → redactar → ejecutar → detectar ambigüedad → corregir** Caso de trabajo: Clasificar tickets de soporte sin inventar categorías ni perder campos. Riesgo que debes controlar: Confundir un texto elegante con una especificación comprobable. ## conjunto de herramientas real y responsabilidades - **ChatGPT:** responsabilidad concreta dentro de esta lección. - **Claude:** responsabilidad concreta dentro de esta lección. - **Gemini:** responsabilidad concreta dentro de esta lección. El conjunto de herramientas no es una lista de aplicaciones. Cada herramienta debe tener una responsabilidad, una entrada, una salida y un motivo para estar en el flujo. Si dos herramientas hacen exactamente lo mismo, elimina una o úsala únicamente como comparación controlada. ## Material de práctica ### Entrada ficticia ```text {"ticket_id":"T-1042","mensaje":"Me cobraron dos veces y necesito una solución hoy","cliente":"demo","importe":49.90} ``` ### Contrato de resultado ```text USUARIO: [quién usa el resultado] OBJETIVO: aplicar Por qué funcionan (o fallan) los prompts ENTRADA PERMITIDA: [campos] SALIDA OBLIGATORIA: JSON validado y una tabla de evaluación donde cada caso tiene resultado, puntuación y motivo. NO HACER: inventar, ocultar dudas, ejecutar acciones irreversibles ACEPTACIÓN: exactitud + utilidad + seguridad + repetibilidad ``` ### Registro de versiones ```csv VERSION,FECHA,HERRAMIENTA,ENTRADA,CAMBIO,RESULTADO,EXACTITUD_0_2,UTILIDAD_0_2,SEGURIDAD_0_2,FALLO,SIGUIENTE_PRUEBA primera versión,,,,,,,,,, versión mejorada,,,,,,,,,, ``` ## Tres demostraciones completas ### Demo 1 · Desde cero: Por qué funcionan (o fallan) los prompts **Situación:** Construye una primera versión con ChatGPT y el caso ficticio. **información de partida** ```text {"ticket_id":"T-1042","mensaje":"Me cobraron dos veces y necesito una solución hoy","cliente":"demo","importe":49.90} ``` **Proceso** 1. Copia la entrada sin modificarla. 2. Pide una salida que contribuya a «Especificación de prompt con entrada, reglas, salida y criterios». 3. Marca cada dato ausente como PENDIENTE. 4. Guarda el resultado completo como primera versión. **Salida esperada:** JSON validado y una tabla de evaluación donde cada caso tiene resultado, puntuación y motivo. **Cómo revisarla:** La salida contiene los campos pedidos, hace visibles las dudas y puede revisarse sin releer toda la conversación. **Si falla:** Si la herramienta inventa campos o no respeta el formato, reduce la tarea, añade un esquema y vuelve a probar el mismo caso. ### Demo 2 · Flujo profesional: Especificación de prompt con entrada, reglas, salida y criterios **Situación:** Combina ChatGPT, Claude, Gemini con responsabilidades separadas. **información de partida** ```text CASO: Clasificar tickets de soporte sin inventar categorías ni perder campos. TAREA DE LA LECCIÓN: Por qué funcionan (o fallan) los prompts CRITERIOS: exactitud, utilidad, seguridad y repetibilidad. ``` **Proceso** 1. Usa ChatGPT para preparar o producir. 2. Usa Claude para enriquecer o contrastar. 3. Usa Gemini para validar, almacenar o presentar. 4. Registra tiempos, fallos y decisión final. **Salida esperada:** Una versión profesional de especificación de prompt con entrada, reglas, salida y criterios con entrada, proceso, resultado, evidencia y persona responsable. **Cómo revisarla:** Otra persona puede repetir el flujo y sabe qué herramienta realiza cada responsabilidad. **Si falla:** Si las herramientas se solapan o el flujo es más lento que el manual, elimina pasos y conserva solo los que aportan evidencia o control. ### Demo 3 · Cuando algo sale mal **Situación:** Prueba «Por qué funcionan (o fallan) los prompts» con datos incompletos, contradictorios o una dependencia caída. **información de partida** ```text {"ticket_id":"T-1042","mensaje":"Me cobraron dos veces y necesito una solución hoy","cliente":"demo","importe":49.90} CAMBIO DE PRUEBA: elimina un campo obligatorio, añade una contradicción y simula que Gemini no responde. ``` **Proceso** 1. Ejecuta el mismo flujo sin corregir manualmente el caso. 2. Comprueba si pregunta, se detiene, reintenta o inventa. 3. Diseña una ruta de recuperación y un mensaje útil. 4. Repite y conserva la evidencia del antes y el después. **Salida esperada:** Un registro del fallo, impacto, causa probable, control añadido y prueba de recuperación. **Cómo revisarla:** El sistema falla de forma visible y segura; no produce una salida silenciosamente incorrecta. **Si falla:** Si no puedes reproducir el fallo, todavía no has definido bien la entrada, el estado o el criterio de éxito. ## Laboratorio del alumno 1. Copia el caso ficticio y define un resultado observable para «Por qué funcionan (o fallan) los prompts». 2. Construye primera versión con ChatGPT sin corregir silenciosamente la salida. 3. Prueba caso normal, incompleto y de fallo. 4. Contrasta o valida con Claude. 5. Integra la evidencia dentro de «Especificación de prompt con entrada, reglas, salida y criterios». 6. Crea versión mejorada cambiando una sola variable y explica el efecto. ## Diagnóstico de problemas - **La respuesta parece correcta, pero no puedes comprobarla.** Causa probable: No definiste fuentes, campos verificables o prueba independiente. Solución: Separa hechos, inferencias y recomendaciones; añade fuente o etiqueta PENDIENTE. Evidencia: Cada afirmación importante tiene evidencia o está marcada como no verificada. - **El resultado cambia demasiado entre intentos.** Causa probable: La entrada, configuración o criterio no están fijados. Solución: Congela el banco de casos, guarda la versión y cambia una sola variable. Evidencia: primera versión y versión mejorada pueden compararse con la misma rúbrica. - **El conjunto de herramientas tiene muchas herramientas y nadie entiende el flujo.** Causa probable: Se eligieron por capacidad general y no por responsabilidad concreta. Solución: Asigna a cada herramienta una única función dentro de Definir contrato → redactar → ejecutar → detectar ambigüedad → corregir. Evidencia: El diagrama muestra entrada, persona responsable, salida y criterio por paso. - **La práctica funciona con el ejemplo, pero falla con datos reales.** Causa probable: Solo se probó el camino feliz. Solución: Añade caso vacío, límite, duplicado, contradicción y dependencia caída. Evidencia: Existe evidencia de recuperación o escalado para cada fallo relevante. ## Conexión con el proyecto final Esta lección aporta una pieza al proyecto final: Biblioteca de prompts de producción con contratos, esquemas, dataset, evaluaciones y control de versiones. Esta lección no termina al leer. Debes producir una pieza que pueda reutilizarse en el proyecto final y que otra persona pueda revisar. ## Entrega mínima - información de partida y datos utilizados. - Captura, enlace o salida primera versión. - Tres pruebas con resultados. - Rúbrica cumplimentada. - versión mejorada y explicación del cambio. - Limitación que sigue abierta. - Siguiente experimento. ## Regla de avance Avanza cuando puedas explicar «Por qué funcionan (o fallan) los prompts» con un ejemplo propio, ejecutar el flujo sin ayuda, detectar al menos un fallo y entregar evidencia reproducible. Leer o copiar una respuesta no demuestra dominio.