Ingeniería de prompts
Encadena prompts complejos para un rendimiento más sólido
Aprende sobre Claude
- Casos de uso
- Modelos
- Seguridad y cumplimiento
Construir con Claude
Probar y evaluar
- Fortalecer las barreras de protección
- Usando la Herramienta de Evaluación
Recursos
Centro legal
Ingeniería de prompts
Encadena prompts complejos para un rendimiento más sólido
Cuando se trabaja con tareas complejas, Claude a veces puede perder el hilo si intentas manejar todo en un solo prompt. El prompt de cadena de pensamiento (CoT) es excelente, pero ¿qué pasa si tu tarea tiene múltiples pasos distintos que requieren cada uno un pensamiento en profundidad?
Aquí 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: Las subtareas más simples significan instrucciones y resultados más claros.
- Trazabilidad: Identifica y corrige fácilmente problemas en tu cadena de prompts.
Cuándo encadenar prompts
Usa el encadenamiento de prompts para tareas de múltiples 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 en la cadena recibe la atención completa de Claude!
Consejo de depuración: Si Claude omite un paso o tiene un mal desempeño, 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 basándote en el desempeño de Claude.
Ejemplos de flujos de trabajo encadenados:
- Análisis de múltiples pasos: Ver los ejemplos legales y de negocios a continuación.
- Tuberías de creación de contenido: Investigación → Esquema → Borrador → Edición → Formato.
- 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 → Re-revisar.
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 auto-corrección
¡Puedes encadenar prompts para que Claude revise su propio trabajo! Esto detecta errores y refina los resultados, especialmente para tareas de alta importancia.
Prompt 1
| Rol | Contenido |
|---|---|
| User | Resume este artículo de investigación médica. <paper>{{RESEARCH_PAPER}}</paper> Enfócate en metodología, hallazgos e implicaciones clínicas. |
| Assistant {{SUMMARY}} | Metodología: ECA doble ciego con 500 pacientes con diabetes Tipo 2. Grupo A (n=250) recibió nuevo agonista dual GLP-1/GIP; Grupo B (n=250) recibió agonista GLP-1 estándar. Ensayo de 24 semanas, punto final primario: reducción de HbA1c. Hallazgos: - Grupo A: reducción media de HbA1c de 1.8% - Grupo B: reducción media de HbA1c de 1.1% - 68% del Grupo A vs. 52% del Grupo B alcanzó HbA1c <7% - Grupo A: pérdida de peso media de 5.2kg - Grupo B: pérdida de peso media de 3.1kg Seguridad: Perfiles similares de eventos adversos, sin eventos serios atribuidos al tratamiento. Implicaciones Clínicas: El agonista dual muestra control glucémico y pérdida de peso superiores comparado con la terapia estándar. Podría ser un cambio revolucionario, especialmente para diabéticos obesos. |
Prompt 2
| Rol | Contenido |
|---|---|
| User | Tu tarea es proporcionar retroalimentación sobre un resumen de 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 por precisión, claridad y completitud en una escala de calificación A-F. |
| Assistant {{FEEDBACK}} | 1. Precisión: A - Reportó correctamente estadísticas clave: reducciones de HbA1c, pérdida de peso. - Anotó con precisión el perfil de seguridad y falta de eventos adversos serios. - La afirmación de “cambio revolucionario” está justificada por resultados significativamente mejores. 2. Claridad: A- - Conciso y bien estructurado con secciones claras. - Buen uso de lenguaje comparativo (ej., “subió 3% desde Q1”) para contexto. - Problema menor: Acrónimos como “ECA,” “GLP-1,” y “GIP” no están definidos. Considerar deletrear en primer uso. 3. Completitud: B+ - Cubre todas las áreas solicitadas: metodología, hallazgos, implicaciones clínicas. - Falta: Características basales de los grupos (¿estaban bien emparejados?). - Falta: Cualquier punto final secundario (ej., presión arterial, lípidos). - Considerar: Implicaciones a largo plazo o necesidad de investigación adicional. En general, el resumen es preciso y claro, proporcionando ideas clave para una comprensión rápida del estudio. Para elevar a A+, definir acrónimos, mencionar estadísticas basales de grupos, notar cualquier resultado secundario y tocar brevemente la necesidad de estudios a largo plazo. |
Prompt 3
| Rol | Contenido |
|---|---|
| User | Tu tarea es mejorar un resumen de artículo dada la retroalimentación. Aquí está el primer borrador 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á la retroalimentación: <feedback> {{FEEDBACK}} </feedback> Actualiza el resumen basado en la retroalimentación. |
| Assistant | Metodología: Ensayo controlado aleatorizado (ECA) doble ciego con 500 pacientes con diabetes Tipo 2. Grupo A (n=250) recibió un nuevo agonista dual del péptido similar al glucagón-1/polipéptido insulinotrópico dependiente de glucosa (GLP-1/GIP); Grupo B (n=250) recibió un agonista GLP-1 estándar. El ensayo de 24 semanas tuvo como punto final primario la reducción de HbA1c. Los grupos estaban bien emparejados por edad, IMC y HbA1c basal. Hallazgos: - Grupo A: reducción media de HbA1c de 1.8% - Grupo B: reducción media de HbA1c de 1.1% - 68% del Grupo A vs. 52% del Grupo B alcanzó HbA1c <7% - Grupo A: pérdida de peso media de 5.2kg - Grupo B: pérdida de peso media de 3.1kg Los puntos finales secundarios mostraron mejoras en la presión arterial y perfiles lipídicos para ambos grupos, con el Grupo A mostrando resultados ligeramente mejores. Seguridad: Perfiles similares de eventos adversos, sin eventos serios atribuidos a ningún tratamiento. Implicaciones Clínicas: El agonista dual GLP-1/GIP demuestra control glucémico y pérdida de peso superiores comparado con la terapia GLP-1 estándar. Estos resultados sugieren que podría ser un avance significativo, particularmente para diabéticos obesos. Sin embargo, se necesitan estudios a más largo plazo para confirmar la eficacia y seguridad sostenidas, así como para investigar beneficios potenciales en resultados cardiovasculares. |
Ejemplos
Nota que Claude omite la instrucción de proporcionar cambios propuestos en su borrador de correo electrónico.
| Rol | Contenido |
|---|---|
| User | Eres nuestro Director Legal. Revisa este contrato SaaS para riesgos, enfocándote en privacidad de datos, SLAs y límites de responsabilidad. <contract> {{CONTRACT}} </contract> Luego redacta un correo electrónico al proveedor con tus preocupaciones y cambios propuestos. |
| Assistant | Después de revisar el contrato SaaS, he identificado varias preocupaciones: 1. Privacidad de Datos (Sección 7): - Problema: El proveedor tiene amplios derechos para usar datos del cliente para “mejora del servicio”. - Riesgo: Podría llevar a compartir o monetización no autorizada de datos. 2. SLAs (Sección 5): - Problema: Garantía de tiempo de actividad del 99.5% está por debajo del estándar de la industria. - Riesgo: El tiempo de inactividad excesivo podría impactar nuestras operaciones. 3. Responsabilidad (Sección 9): - Problema: Límite establecido en 3 meses de tarifas. - Riesgo: Inadecuado para potenciales violaciones de datos o fallas del servicio. Borrador de correo: Estimado {{VENDOR}}, Después de revisar el acuerdo SaaS, tenemos preocupaciones: 1. Privacidad de Datos: Requerimos que nuestros datos solo se usen para provisión directa del servicio, no para “mejora del servicio” general. Por favor modifique la Sección 7. 2. SLAs: 99.5% de tiempo de actividad es insuficiente. Necesitamos 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 |
|---|---|
| User | Eres nuestro Director Legal. Revisa este contrato SaaS para riesgos, enfocándote en privacidad de datos, SLAs y límites de responsabilidad. <contract> {{CONTRACT}} </contract> Genera tus hallazgos en etiquetas <risks>. |
| Assistant {{CONCERNS}} | 1. Privacidad de Datos (Sección 7): - Problema: El proveedor tiene amplios derechos para usar datos del cliente para “mejora del servicio”. - Riesgo: Podría llevar a compartir o monetización no autorizada de datos del cliente. - Impacto: Potencial violación de confianza del cliente, multas regulatorias (GDPR, CCPA). 2. SLAs (Sección 5): - Problema: 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 tiempo 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 potenciales violaciones de datos, robo de PI o fallas prolongadas del servicio. - Impacto: Compensación insuficiente por daños que podrían exceder ampliamente el límite, como demandas colectivas o multas regulatorias. |
Prompt 2
| Rol | Contenido |
|---|---|
| User | 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> |
| Assistant {{EMAIL}} | Estimado {{VENDOR}}, Después de una revisión exhaustiva del acuerdo 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 datos del cliente para “mejora del servicio”. - Preocupación: Potencial compartición o monetización no autorizada de datos. - Cambio Propuesto: Limitar el uso de datos a provisión directa del servicio. Cualquier uso para mejora, análisis o marketing debe ser opcional, revocable y anonimizado. 2. SLAs (Sección 5): - Actual: Garantía de tiempo de actividad del 99.5%. - Preocupación: Hasta 43.8 horas de tiempo de inactividad por año, arriesgando interrupciones operativas. - Cambio Propuesto: 99.99% de tiempo de actividad con créditos de servicio escalonados. Ej., 10% de crédito por <99.99%, 25% por <99.9%, 50% por <99.5%. 3. Responsabilidad (Sección 9): - Actual: Límite en 3 meses de tarifas. - Preocupación: Groseramente inadecuado para violaciones de datos, robo de PI 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 PI. Estos cambios son no negociables para nosotros. Se alinean con los estándares de la industria y nuestro compromiso con la seguridad de datos, excelencia operativa y 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 dispuestos a discutir más para asegurar el entendimiento y acuerdo mutuo. Saludos cordiales, {{CLO_NAME}} |
Prompt 3
| Rol | Contenido |
|---|---|
| User | Tu tarea es revisar un correo electrónico y proporcionar retroalimentación. Aquí está el correo electrónico: <email> {{EMAIL}} </email> Da retroalimentación sobre tono, claridad y profesionalismo. |
| Assistant | 1. Tono: - Profesional y asertivo sin ser confrontacional. - El uso de “no negociables” es fuerte pero justificado dada la criticidad de los problemas. - El lenguaje colaborativo (“valoramos,” “dispuestos a discutir”) balancea 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 (ej., “EBITDA,” “créditos de servicio escalonados”) son apropiados para un contexto SaaS B2B. - Los elementos de acción son claros: equipo legal del proveedor debe revisar e incorporar cambios. 3. Profesionalismo: - Se enfoca en beneficio mutuo y 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 con entender y resolver problemas. En general, el correo logra el balance correcto de 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; proceder con el envío. |
Prompt 1
| Rol | Contenido |
|---|---|
| User | Como arquitecto de soluciones senior, revisa y analiza esta estrategia de multitenancy para nuestro nuevo producto SaaS empresarial. <strategy> {{STRATEGY}} </strategy> Enfócate en escalabilidad, seguridad y costo-efectividad. |
| Assistant {{ANALYSIS}} | 1. Escalabilidad: + El sharding de base de datos por inquilino reduce la contención, soporta alto crecimiento. + Los microservicios permiten escalar componentes independientemente. - Los servidores de aplicación compartidos podrían ser un cuello de botella bajo carga extrema. - No se menciona auto-escalado o balanceo de carga para la capa de aplicación. 2. Seguridad: + El aislamiento de datos de inquilinos vía sharding mitiga fugas de datos. + JWT con expiración corta y tokens de actualización es la mejor práctica de la industria. - No se menciona encriptación (en reposo, en tránsito) o gestión de claves. - La estrategia IAM carece de detalles sobre roles, permisos o RBAC. 3. Costo-efectividad: + Los servidores de aplicación compartidos reducen costos de recursos inactivos. + Funciones serverless para tareas infrecuentes optimizan costos. - DB por inquilino podría aumentar costos a escala vs. DB multi-inquilino optimizada. - No hay discusión de instancias reservadas o instancias spot para ahorro de costos. |
Prompt 2
| Rol | Contenido |
|---|---|
| User | Redacta un documento de revisión de estrategia para el liderazgo de ingeniería basado en este análisis de una estrategia de multitenancy. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Incluye un resumen ejecutivo, análisis detallado y recomendaciones. |
| Assistant {{STRATEGY_DOC}} | # Revisión de Estrategia de Multitenancy: Producto SaaS Empresarial ## Resumen Ejecutivo La estrategia propuesta demuestra una base sólida en principios de escalabilidad y seguridad pero tiene brechas en detalles de implementación. Sobresale en aislamiento de datos y escalado a nivel de componentes pero carece de escalado robusto de la capa de aplicación y medidas de seguridad avanzadas. Las optimizaciones de costos están presentes pero pueden fallar a gran escala. Con mejoras dirigidas, esta estrategia puede soportar efectivamente nuestras ambiciones SaaS empresariales. ## Análisis Detallado ### 1. Escalabilidad: B+ Fortalezas: - El sharding de base de datos por inquilino es excelente. Minimiza la latencia de consultas, soporta alto crecimiento de datos y facilita el escalado sin problemas por inquilino. - La arquitectura de microservicios permite escalar componentes individuales basado en demanda, crucial para manejar cargas de trabajo empresariales diversas. Debilidades: - Los servidores de aplicación compartidos arriesgan convertirse en cuello de botella. A medida que el conteo de inquilinos y tráfico crecen, estos podrían degradar el rendimiento en todos los inquilinos. - La ausencia de auto-escalado y balanceo de carga para la capa de aplicación es una omisión crítica. Estos son esenciales para manejar picos de tráfico sin sobre-aprovisionamiento. ### 2. Seguridad: B- Fortalezas: - Las bases de datos fragmentadas proporcionan fuerte aislamiento de datos de inquilinos, mitigando 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 OWASP, reduciendo ventanas de vulnerabilidad de tokens. Debilidades: - No se menciona encriptación de datos en reposo o en tránsito (TLS 1.3). Esto es no negociable para datos empresariales. - Falta estrategia de gestión de claves. ¿Cómo se gestionan y rotan las claves de encriptación, secretos JWT y credenciales de DB? - 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. Costo-efectividad: B Fortalezas: - Los servidores de aplicación compartidos reducen costos de capacidad inactiva, buenos para tráfico en estado estable. - Serverless para tareas infrecuentes (ej., reportes) es inteligente; pagar solo cuando estos recursos se usan. Debilidades: - Las bases de datos por inquilino pueden no ser costo-efectivas a escala comparadas con una base de datos multi-inquilino bien diseñada con particionamiento de datos robusto. - No se mencionan medidas de ahorro de costos como instancias reservadas para cargas de trabajo predecibles o instancias spot para tareas tolerantes a fallos. - La falta de auto-escalado de la capa de aplicación podría llevar a sobre-aprovisionamiento, aumentando costos. ## Recomendaciones 1. Resiliencia de Capa de Aplicación: Implementar auto-escalado con Kubernetes o servicios cloud-native (EKS, GKE). Desplegar a través de zonas de disponibilidad con CDN para activos estáticos. 2. Fortalecimiento de Seguridad: a. Encriptar datos en reposo (AES-256) y en tránsito (TLS 1.3). b. Usar un KMS gestionado (AWS KMS, GCP KMS) para gestión de claves. c. Mejorar IAM con RBAC, ABAC y SAML/OIDC para SSO empresarial. 3. Optimización de Costos: a. Evaluar DB columnar multi-inquilino (ej., Snowflake) vs. sharding a escala. b. Usar instancias reservadas para servidores de aplicación, instancias spot para cargas de trabajo no críticas. c. Implementar monitoreo proactivo y dimensionamiento correcto para evitar sobre-aprovisionamiento. 4. Prueba de Concepto (PoC): Antes de la implementación completa, conducir una PoC con simulación de alta escala: a. Probar DB fragmentada vs. DB multi-inquilino optimizada para costo y rendimiento. b. Probar estrés de capa de aplicación con picos de tráfico simulados a nivel empresarial. c. Conducir auditoría de seguridad de terceros, enfocándose en aislamiento de datos y controles de acceso. Con estas mejoras, nuestra estrategia de multi-tenancy será de grado empresarial: escalable, segura y costo-efectiva. La PoC validará nuestras elecciones de diseño e inspirará confianza en nuestros clientes empresariales. |
Prompt 3
| Rol | Contenido |
|---|---|
| User | Califica este documento de revisión de estrategia por claridad, accionabilidad y alineación con prioridades empresariales. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistant | 1. Claridad: A + Estructura clara con Resumen Ejecutivo, Análisis Detallado y Recomendaciones. + El análisis usa un sistema de calificación (B+, B-) para rápida comprensión de fortalezas/debilidades. + Los términos técnicos (RBAC, ABAC, TLS) están explicados o contextualizados, ayudando al liderazgo no técnico. + Las ayudas visuales (puntos, sangría) mejoran la legibilidad. 2. Accionabilidad: A- + Las recomendaciones son específicas y técnicas (ej., “Implementar auto-escalado con Kubernetes”). + El plan PoC con objetivos claros proporciona una hoja de ruta. - Falta: Líneas de tiempo, requerimientos de recursos o asignaciones de equipo para cada recomendación. + Considerar: Agregar una sección “Próximos Pasos” con acciones inmediatas, roles y una línea de tiempo de alto nivel. 3. Alineación Empresarial: A+ + Aborda directamente prioridades empresariales: - Escalabilidad: Discute manejo de picos de tráfico a nivel empresarial. - Seguridad: Se enfoca en aislamiento de datos, encriptación e IAM empresarial. - Costo: Estrategias alineadas con FinOps empresarial (instancias reservadas, dimensionamiento correcto). + PoC con “simulación de alta escala” y auditoría de seguridad muestra compromiso con calidad de grado empresarial. + El lenguaje resuena con preocupaciones empresariales: “riesgo inaceptable,” “grado empresarial,” “inspirar confianza.” En general, el documento sobresale en claridad y alineación empresarial. La accionabilidad es fuerte pero podría elevarse a A+ con una sección “Próximos Pasos”. La profundidad técnica, junto con explicaciones claras, hace esto altamente efectivo tanto para liderazgo técnico como no técnico. ¡Excelente 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 encontrados en nu
estra 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.