Ingeniería de prompts
Encadena prompts complejos para un rendimiento más sólido
Ingeniería de prompts
Encadena prompts complejos para un rendimiento más sólido
Cuando se trabaja con tareas complejas, Claude a veces puede fallar si intentas manejar todo en un solo prompt. El prompting de cadena de pensamiento (CoT) es genial, pero ¿qué pasa si tu tarea tiene múltiples pasos distintos que requieren un pensamiento profundo?
Entra el encadenamiento de prompts: dividir tareas complejas en subtareas más pequeñas y manejables.
¿Por qué encadenar prompts?
- Precisión: Cada subtarea recibe la atención completa de Claude, reduciendo errores.
- Claridad: Subtareas más simples significan instrucciones y resultados más claros.
- Trazabilidad: Identifica y soluciona fácilmente problemas en tu cadena de prompts.
Cuándo encadenar prompts
Usa el encadenamiento de prompts para tareas de varios pasos como síntesis de investigación, análisis de documentos o creación iterativa de contenido. Cuando una tarea involucra múltiples transformaciones, citas o instrucciones, el encadenamiento evita que Claude omita o maneje mal los pasos.
Recuerda: ¡Cada eslabón de la cadena recibe la atención completa de Claude!
Consejo de depuración: Si Claude omite un paso o se desempeña mal, aísla ese paso en su propio prompt. Esto te permite ajustar los pasos problemáticos sin rehacer toda la tarea.
Cómo encadenar prompts
- Identifica subtareas: Divide tu tarea en pasos distintos y secuenciales.
- Estructura con XML para transferencias claras: Usa etiquetas XML para pasar resultados entre prompts.
- Ten un objetivo de tarea única: Cada subtarea debe tener un objetivo único y claro.
- Itera: Refina las subtareas según el rendimiento de Claude.
Ejemplos de flujos de trabajo encadenados:
- Análisis de varios pasos: Ver los ejemplos legales y comerciales a continuación.
- Pipelines de creación de contenido: Investigar → Esquematizar → Redactar → Editar → Formatear.
- Procesamiento de datos: Extraer → Transformar → Analizar → Visualizar.
- Toma de decisiones: Recopilar información → Listar opciones → Analizar cada una → Recomendar.
- Bucles de verificación: Generar contenido → Revisar → Refinar → Revisar nuevamente.
Consejo de optimización: Para tareas con subtareas independientes (como analizar múltiples documentos), crea prompts separados y ejecútalos en paralelo para mayor velocidad.
Avanzado: Cadenas de autocorrección
¡Puedes encadenar prompts para que Claude revise su propio trabajo! Esto detecta errores y refina los resultados, especialmente para tareas de alto riesgo.
Prompt 1
| Rol | Contenido |
|---|---|
| Usuario | Resume este artículo de investigación médica. <paper>{{RESEARCH_PAPER}}</paper> Enfócate en la metodología, los hallazgos y las implicaciones clínicas. |
| Asistente {{SUMMARY}} | Metodología: ECA doble ciego con 500 pacientes con diabetes tipo 2. Grupo A (n=250) recibió un nuevo agonista dual de GLP-1/GIP; Grupo B (n=250) recibió un agonista estándar de GLP-1. Ensayo de 24 semanas, criterio de valoración principal: reducción de HbA1c. Hallazgos: - Grupo A: reducción media de HbA1c del 1,8% - Grupo B: reducción media de HbA1c del 1,1% - 68% del Grupo A vs. 52% del Grupo B alcanzó HbA1c <7% - Grupo A: pérdida de peso media de 5,2 kg - Grupo B: pérdida de peso media de 3,1 kg Seguridad: Perfiles de eventos adversos similares, sin eventos graves atribuidos al tratamiento. Implicaciones clínicas: El agonista dual muestra un control glucémico y una pérdida de peso superiores en comparación con la terapia estándar. Podría ser un cambio de juego, especialmente para diabéticos obesos. |
Prompt 2
| Rol | Contenido |
|---|---|
| Usuario | Tu tarea es proporcionar comentarios sobre un resumen de un artículo de investigación. Aquí hay un resumen de un artículo de investigación médica: <summary> {{SUMMARY}} </summary> Aquí está el artículo de investigación: <paper> {{RESEARCH_PAPER}} </paper> Revisa este resumen en cuanto a precisión, claridad e integridad en una escala de calificación de A a F. |
| Asistente {{FEEDBACK}} | 1. Precisión: A - Informó correctamente las estadísticas clave: reducciones de HbA1c, pérdida de peso. - Señaló con precisión el perfil de seguridad y la falta de eventos adversos graves. - La afirmación de “cambio de juego” está justificada por resultados significativamente mejores. 2. Claridad: A- - Conciso y bien estructurado con secciones claras. - Buen uso del lenguaje comparativo (por ejemplo, “un 3% más que en el Q1”) para el contexto. - Problema menor: Acrónimos como “ECA”, “GLP-1” y “GIP” no definidos. Considere escribir el primer uso completo. 3. Integridad: B+ - Cubre todas las áreas solicitadas: metodología, hallazgos, implicaciones clínicas. - Falta: Características basales de los grupos (¿estaban bien emparejados?). - Falta: Cualquier criterio de valoración secundario (por ejemplo, presión arterial, lípidos). - Considere: Implicaciones a largo plazo o necesidad de más investigación. En general, el resumen es preciso y claro, proporcionando información clave para una comprensión rápida del estudio. Para elevarlo a A+, defina los acrónimos, mencione las estadísticas de referencia del grupo, señale los resultados secundarios y toque brevemente la necesidad de estudios a largo plazo. |
Prompt 3
| Rol | Contenido |
|---|---|
| Usuario | Tu tarea es mejorar un resumen de un artículo dado los comentarios. Aquí está el primer borrador de un resumen de un artículo de investigación médica: <summary> {{SUMMARY}} </summary> Aquí está el artículo de investigación: <paper> {{RESEARCH_PAPER}} </paper> Aquí están los comentarios: <feedback> {{FEEDBACK}} </feedback> Actualiza el resumen basándote en los comentarios. |
| Asistente | Metodología: Ensayo controlado aleatorizado (ECA) doble ciego con 500 pacientes con diabetes tipo 2. El Grupo A (n=250) recibió un nuevo agonista dual del péptido similar al glucagón-1/polipéptido insulinotrópico dependiente de la glucosa (GLP-1/GIP); el Grupo B (n=250) recibió un agonista estándar de GLP-1. El criterio de valoración principal del ensayo de 24 semanas fue la reducción de HbA1c. Los grupos estaban bien emparejados en cuanto a edad, IMC y HbA1c inicial. Hallazgos: - Grupo A: reducción media de HbA1c del 1,8% - Grupo B: reducción media de HbA1c del 1,1% - 68% del Grupo A vs. 52% del Grupo B alcanzó HbA1c <7% - Grupo A: pérdida de peso media de 5,2 kg - Grupo B: pérdida de peso media de 3,1 kg Los criterios de valoración secundarios mostraron mejoras en la presión arterial y los perfiles lipídicos para ambos grupos, con el Grupo A mostrando resultados ligeramente mejores. Seguridad: Perfiles de eventos adversos similares, sin eventos graves atribuidos a ninguno de los tratamientos. Implicaciones clínicas: El agonista dual de GLP-1/GIP demuestra un control glucémico y una pérdida de peso superiores en comparación con la terapia estándar con GLP-1. Estos resultados sugieren que podría ser un avance significativo, particularmente para los diabéticos obesos. Sin embargo, se necesitan estudios a más largo plazo para confirmar la eficacia y seguridad sostenidas, así como para investigar los beneficios potenciales sobre los resultados cardiovasculares. |
Ejemplos
Ten en cuenta que Claude omite la instrucción de proporcionar cambios propuestos en su borrador de correo electrónico.
| Rol | Contenido |
|---|---|
| Usuario | Eres nuestro Director Jurídico. Revisa este contrato de SaaS en busca de riesgos, centrándote en la privacidad de los datos, los SLA y los límites de responsabilidad. <contract> {{CONTRACT}} </contract> Luego redacta un correo electrónico al proveedor con tus preocupaciones y cambios propuestos. |
| Asistente | Después de revisar el contrato de SaaS, he identificado varias preocupaciones: 1. Privacidad de datos (Sección 7): - Problema: El proveedor tiene amplios derechos para usar los datos del cliente para “mejora del servicio”. - Riesgo: Podría conducir a un intercambio o monetización no autorizados de datos. 2. SLA (Sección 5): - Problema: La garantía de tiempo de actividad del 99,5% está por debajo del estándar de la industria. - Riesgo: Un tiempo de inactividad excesivo podría afectar nuestras operaciones. 3. Responsabilidad (Sección 9): - Problema: Límite establecido en 3 meses de tarifas. - Riesgo: Inadecuado para posibles violaciones de datos o fallas del servicio. Borrador de correo electrónico: Estimado {{VENDOR}}, Después de revisar el acuerdo de SaaS, tenemos las siguientes preocupaciones: 1. Privacidad de datos: Requerimos que nuestros datos solo se utilicen para la prestación directa del servicio, no para una amplia “mejora del servicio”. Por favor, modifique la Sección 7. 2. SLA: Un tiempo de actividad del 99,5% es insuficiente. Necesitamos un 99,99% con penalizaciones claramente definidas. Por favor, revise la Sección 5. 3. Responsabilidad: El límite actual de 3 meses de tarifas es inadecuado. Proponemos un límite de 12 meses de tarifas, sin límite para violaciones de datos o mala conducta intencional. Valoramos nuestra potencial asociación y creemos que estos cambios nos prepararán para el éxito. Por favor, envíe un acuerdo revisado. Saludos cordiales, {{CLO_NAME}} |
Prompt 1
| Rol | Contenido |
|---|---|
| Usuario | Eres nuestro Director Jurídico. Revisa este contrato de SaaS en busca de riesgos, centrándote en la privacidad de los datos, los SLA y los límites de responsabilidad. <contract> {{CONTRACT}} </contract> Muestra tus hallazgos en etiquetas <risks>. |
| Asistente {{CONCERNS}} | 1. Privacidad de datos (Sección 7): - Problema: El proveedor tiene amplios derechos para usar los datos del cliente para “mejora del servicio”. - Riesgo: Podría conducir a un intercambio o monetización no autorizados de los datos del cliente. - Impacto: Posible violación de la confianza del cliente, multas regulatorias (GDPR, CCPA). 2. SLA (Sección 5): - Problema: La garantía de tiempo de actividad del 99,5% está por debajo del estándar de la industria (típicamente 99,99%). - Riesgo: Hasta 43,8 horas de inactividad por año vs. 52,6 minutos al 99,99%. - Impacto: Interrupciones operativas, pérdida de ingresos, insatisfacción del cliente. 3. Responsabilidad (Sección 9): - Problema: Límite de responsabilidad establecido en 3 meses de tarifas. - Riesgo: Inadecuado para posibles violaciones de datos, robo de propiedad intelectual o fallas prolongadas del servicio. - Impacto: Compensación insuficiente por daños que podrían exceder con creces el límite, como demandas colectivas o multas regulatorias. |
Prompt 2
| Rol | Contenido |
|---|---|
| Usuario | Redacta un correo electrónico a un proveedor de productos SaaS describiendo las siguientes preocupaciones y proponiendo cambios. Aquí están las preocupaciones: <concerns> {{CONCERNS}} </concerns> |
| Asistente {{EMAIL}} | Estimado {{VENDOR}}, Después de una revisión exhaustiva del acuerdo de SaaS propuesto, nuestro equipo legal ha identificado varias preocupaciones de alta prioridad que deben abordarse antes de que podamos proceder: 1. Privacidad de datos (Sección 7): - Actual: Amplios derechos para usar los datos del cliente para “mejora del servicio”. - Preocupación: Posible intercambio o monetización no autorizada de datos. - Cambio propuesto: Limitar el uso de datos a la prestación directa del servicio. Cualquier uso para mejora, análisis o marketing debe ser opcional, revocable y anonimizado. 2. SLA (Sección 5): - Actual: Garantía de tiempo de actividad del 99,5%. - Preocupación: Hasta 43,8 horas de inactividad por año, con riesgo de interrupciones operativas. - Cambio propuesto: 99,99% de tiempo de actividad con créditos de servicio escalonados. Por ejemplo, 10% de crédito por <99,99%, 25% por <99,9%, 50% por <99,5%. 3. Responsabilidad (Sección 9): - Actual: Límite de 3 meses de tarifas. - Preocupación: Totalmente inadecuado para violaciones de datos, robo de propiedad intelectual o interrupciones prolongadas. - Cambio propuesto: 12 meses de tarifas para responsabilidad general. Sin límite para violaciones de datos, mala conducta intencional, infracción de propiedad intelectual. Estos cambios no son negociables para nosotros. Se alinean con los estándares de la industria y nuestro compromiso con la seguridad de los datos, la excelencia operativa y la responsabilidad fiduciaria. Valoramos el potencial de nuestra asociación, y abordar estos puntos establecerá una base sólida. Por favor, haga que su equipo legal revise e incorpore estos cambios. Estamos encantados de discutir más para asegurar un entendimiento y acuerdo mutuo. Saludos cordiales, {{CLO_NAME}} |
Prompt 3
| Rol | Contenido |
|---|---|
| Usuario | Tu tarea es revisar un correo electrónico y proporcionar comentarios. Aquí está el correo electrónico: <email> {{EMAIL}} </email> Da tu opinión sobre el tono, la claridad y la profesionalidad. |
| Asistente | 1. Tono: - Profesional y asertivo sin ser confrontativo. - El uso de “no negociable” es fuerte pero justificado dada la criticidad de los problemas. - El lenguaje colaborativo (“valoramos”, “encantados de discutir”) equilibra la firmeza, manteniendo un tono constructivo. 2. Claridad: - Excelente estructuración: Estado actual, preocupación y cambio propuesto para cada problema. - Los términos técnicos (por ejemplo, “EBITDA”, “créditos de servicio escalonados”) son apropiados para un contexto de SaaS B2B. - Los elementos de acción son claros: el equipo legal del proveedor debe revisar e incorporar los cambios. 3. Profesionalidad: - Se centra en el beneficio mutuo y los estándares de la industria, no solo en nuestras demandas. - Menciona responsabilidades más amplias (seguridad de datos, excelencia operativa, deber fiduciario), elevando la discusión. - Ofrece más discusión, mostrando compromiso para entender y resolver problemas. En general, el correo electrónico logra el equilibrio adecuado entre asertividad y colaboración. Articula claramente nuestras preocupaciones, propone soluciones específicas y mantiene un tono profesional orientado a la asociación. No se necesitan revisiones; proceda con el envío. |
Prompt 1
| Rol | Contenido |
|---|---|
| Usuario | Como arquitecto de soluciones senior, revisa y analiza esta estrategia de multitenencia para nuestro nuevo producto SaaS empresarial. <strategy> {{STRATEGY}} </strategy> Enfócate en la escalabilidad, la seguridad y la rentabilidad. |
| Asistente {{ANALYSIS}} | 1. Escalabilidad: + El sharding de la base de datos por inquilino reduce la contención, admite un alto crecimiento. + Los microservicios permiten escalar componentes de forma independiente. - Los servidores de aplicaciones compartidos podrían ser un cuello de botella bajo carga extrema. - No se menciona el escalado automático o el balanceo de carga para el nivel de aplicación. 2. Seguridad: + El aislamiento de datos de inquilinos a través del sharding mitiga las fugas de datos. + JWT con expiración corta y tokens de actualización es la mejor práctica de la industria. - No se menciona el cifrado (en reposo, en tránsito) o la gestión de claves. - La estrategia de IAM carece de detalles sobre roles, permisos o RBAC. 3. Rentabilidad: + Los servidores de aplicaciones compartidos reducen los costos de recursos inactivos. + Las funciones sin servidor para tareas infrecuentes optimizan los costos. - La base de datos por inquilino podría aumentar los costos a escala vs. una base de datos multiinquilino optimizada. - No se discuten las instancias reservadas o las instancias spot para el ahorro de costos. |
Prompt 2
| Rol | Contenido |
|---|---|
| Usuario | Redacta un documento de revisión de estrategia para el liderazgo de ingeniería basado en este análisis de una estrategia de multitenencia. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Incluye un resumen ejecutivo, un análisis detallado y recomendaciones. |
| Asistente {{STRATEGY_DOC}} | # Revisión de estrategia de multitenencia: Producto SaaS empresarial ## Resumen ejecutivo La estrategia propuesta demuestra una base sólida en los principios de escalabilidad y seguridad, pero tiene lagunas en los detalles de implementación. Se destaca en el aislamiento de datos y el escalado a nivel de componentes, pero carece de un escalado robusto del nivel de aplicación y medidas de seguridad avanzadas. Las optimizaciones de costos están presentes pero pueden fallar a gran escala. Con mejoras específicas, esta estrategia puede respaldar eficazmente nuestras ambiciones de SaaS empresarial. ## Análisis detallado ### 1. Escalabilidad: B+ Fortalezas: - El sharding de la base de datos por inquilino es excelente. Minimiza la latencia de consulta, admite un alto crecimiento de datos y facilita el escalado perfecto por inquilino. - La arquitectura de microservicios permite escalar componentes individuales según la demanda, crucial para manejar diversas cargas de trabajo empresariales. Debilidades: - Los servidores de aplicaciones compartidos corren el riesgo de convertirse en un cuello de botella. A medida que crecen el número de inquilinos y el tráfico, estos podrían degradar el rendimiento en todos los inquilinos. - La ausencia de escalado automático y balanceo de carga para el nivel de aplicación es una omisión crítica. Estos son esenciales para manejar picos de tráfico sin un aprovisionamiento excesivo. ### 2. Seguridad: B- Fortalezas: - Las bases de datos con sharding proporcionan un fuerte aislamiento de datos de inquilinos, mitigando los riesgos de fugas de datos o acceso no autorizado entre inquilinos. - JWT con expiración corta y tokens de actualización se alinean con las mejores prácticas de OWASP, reduciendo las ventanas de vulnerabilidad de tokens. Debilidades: - No se menciona el cifrado de datos en reposo o en tránsito (TLS 1.3). Esto es innegociable para los datos empresariales. - Falta la estrategia de gestión de claves. ¿Cómo se gestionan y rotan las claves de cifrado, los secretos JWT y las credenciales de la base de datos? - IAM carece de profundidad. Necesitamos RBAC con roles bien definidos, control de acceso basado en atributos (ABAC) para permisos granulares e integración con proveedores de identidad empresarial (SAML, OIDC). ### 3. Rentabilidad: B Fortalezas: - Los servidores de aplicaciones compartidos reducen los costos de capacidad inactiva, buenos para el tráfico en estado estable. - Sin servidor para tareas infrecuentes (por ejemplo, informes) es inteligente; pague solo cuando se usen estos recursos. Debilidades: - Las bases de datos por inquilino pueden no ser rentables a escala en comparación con una base de datos multiinquilino bien diseñada con un sólido particionamiento de datos. - No se mencionan medidas de ahorro de costos como instancias reservadas para cargas de trabajo predecibles o instancias spot para tareas tolerantes a fallas. - La falta de escalado automático del nivel de aplicación podría llevar a un aprovisionamiento excesivo, aumentando los costos. ## Recomendaciones 1. Resiliencia del nivel de aplicación: Implementar escalado automático con Kubernetes o servicios nativos de la nube (EKS, GKE). Desplegar en zonas de disponibilidad con una CDN para activos estáticos. 2. Endurecimiento de seguridad: a. Cifrar datos en reposo (AES-256) y en tránsito (TLS 1.3). b. Usar un KMS administrado (AWS KMS, GCP KMS) para la gestión de claves. c. Mejorar IAM con RBAC, ABAC y SAML/OIDC para SSO empresarial. 3. Optimización de costos: a. Evaluar una base de datos multiinquilino columnar (por ejemplo, Snowflake) vs. sharding a escala. b. Usar instancias reservadas para servidores de aplicaciones, instancias spot para cargas de trabajo no críticas. c. Implementar monitoreo proactivo y ajuste de tamaño para evitar el aprovisionamiento excesivo. 4. Prueba de concepto (PoC): Antes de la implementación completa, realizar una PoC con una simulación a gran escala: a. Probar la base de datos con sharding vs. la base de datos multiinquilino optimizada para costo y rendimiento. b. Prueba de estrés del nivel de aplicación con picos de tráfico simulados a nivel empresarial. c. Realizar una auditoría de seguridad de terceros, centrándose en el aislamiento de datos y los controles de acceso. Con estas mejoras, nuestra estrategia de multitenencia será de nivel empresarial: escalable, segura y rentable. La PoC validará nuestras elecciones de diseño e infundirá confianza en nuestros clientes empresariales. |
Prompt 3
| Rol | Contenido |
|---|---|
| Usuario | Califica este documento de revisión de estrategia en cuanto a claridad, capacidad de acción y alineación con las prioridades empresariales. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Asistente | 1. Claridad: A + Estructura clara con Resumen ejecutivo, Análisis detallado y Recomendaciones. + El análisis utiliza un sistema de calificación (B+, B-) para una rápida comprensión de las fortalezas/debilidades. + Los términos técnicos (RBAC, ABAC, TLS) se explican o contextualizan, ayudando al liderazgo no técnico. + Las ayudas visuales (viñetas, sangría) mejoran la legibilidad. 2. Capacidad de acción: A- + Las recomendaciones son específicas y técnicas (por ejemplo, “Implementar escalado automático con Kubernetes”). + El plan de PoC con objetivos claros proporciona una hoja de ruta. + Falta: Plazos, requisitos de recursos o asignaciones de equipo para cada recomendación. + Considere: Agregar una sección de “Próximos pasos” con acciones inmediatas, roles y un cronograma de alto nivel. 3. Alineación empresarial: A+ + Aborda directamente las prioridades empresariales: - Escalabilidad: Discute el manejo de picos de tráfico a nivel empresarial. - Seguridad: Se enfoca en el aislamiento de datos, el cifrado y el IAM empresarial. - Costo: Las estrategias se alinean con FinOps empresarial (instancias reservadas, ajuste de tamaño). + La PoC con “simulación a gran escala” y auditoría de seguridad muestra el compromiso con la calidad de nivel empresarial. + El lenguaje resuena con las preocupaciones empresariales: “riesgo inaceptable”, “nivel empresarial”, “infundir confianza”. En general, el documento se destaca en claridad y alineación empresarial. La capacidad de acción es sólida pero podría elevarse a A+ con una sección de “Próximos pasos”. La profundidad técnica, junto con explicaciones claras, lo hace altamente efect ivo tanto para el liderazgo técnico como no técnico. ¡Gran trabajo! |
Biblioteca de prompts
Inspírate con una selección curada de prompts para varias tareas y casos de uso.
Tutorial de prompting en GitHub
Un tutorial lleno de ejemplos que cubre los conceptos de ingeniería de prompts que se encuentran en nuestra documentación.
Tutorial de prompting en Google Sheets
Una versión más ligera de nuestro tutorial de ingeniería de prompts a través de una hoja de cálculo interactiva.