ChatGPT vs Claude: cómo redactar prompts para cada uno

ChatGPT vs Claude: cómo redactar prompts para cada uno

El trabajo fiable con IA comienza con un acuerdo explícito sobre qué se debe producir y cómo se juzgará. Este artículo ofrece un marco operativo en lugar de una clasificación de productos o la promesa de que un truco de prompting resolverá cualquier tarea. Cuando las capacidades dependan de un modelo, cuenta o integración en particular, verifíquelas en el entorno que realmente utilice.

Puntos clave

• Defina el resultado deseado antes de elegir la sintaxis o las herramientas.
• Separe las instrucciones, las evidencias de respaldo y los ejemplos ilustrativos.
• Formule restricciones verificables y asigne responsables para las decisiones importantes.
• Evalúe resultados representativos en lugar de confiar en una sola respuesta impresionante.
• Utilice Brief Prompting (redacción de prompts basada en briefs) para recopilar el contexto faltante antes de la ejecución.

Comience con la misma definición de tarea

Las comparaciones a menudo se centran en la personalidad del modelo cuando la mayor fuente de variación es un brief incompleto. Ambos sistemas necesitan conocer el resultado previsto, la audiencia y los límites de las evidencias. Establezca estos puntos antes de adaptar la sintaxis. De lo contrario, podría atribuir una mejora al modelo cuando el segundo intento simplemente incluyó información omitida en el primero.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Objetivo: redactar un correo electrónico de incorporación. Audiencia: nuevos administradores. Resultado: configuración completada. Fuente: guía de configuración suministrada. Restricción: no inventar funciones ni prometer asistencia que no figure en la guía.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

Una comparación útil mantiene constante el entregable previsto. Si le pide a un sistema un resumen ejecutivo y al otro un análisis detallado, los resultados no permitirán juzgar con criterio la adecuación de los modelos. Normalice la tarea primero y luego examine en qué aspectos necesita corrección cada respuesta.

Utilice markdown como estándar para ChatGPT

Los encabezados de markdown facilitan que una persona inspeccione y revise una instrucción. Separe la tarea, el contexto, los requisitos y el formato de salida en lugar de mezclarlos en un solo párrafo. Esta es una convención práctica, no una regla que impida a ChatGPT interpretar XML o prosa ordinaria. Las etiquetas claras importan más que el formato decorativo.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

# Objetivo
Explicar el proceso de migración a un cliente no técnico.
# Fuentes
Utilizar únicamente la guía suministrada.
# Formato de salida
Cinco pasos numerados, seguidos de preguntas pendientes de resolución.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

No convierta una convención de formato en una superstición. Si una estructura simple de encabezados funciona bien en ambos sistemas, puede ser el estándar compartido más sencillo. Añada etiquetas cuando unos límites más claros ayuden, no porque cada tarea requiera un lenguaje de marcado elaborado.

Utilice XML como estándar para Claude

Las etiquetas de estilo XML son útiles para separar las instrucciones del material de referencia, especialmente cuando un brief contiene varios documentos o ejemplos. Elija nombres de etiquetas descriptivos y mantenga la anidación simple. Las etiquetas crean límites; no autentican el contenido ni evitan todos los errores de seguimiento de instrucciones. Claude también puede trabajar con markdown y lenguaje natural.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

<goal>Explicar el proceso de migración a un cliente no técnico.</goal>
<sources>Inserte aquí la guía de migración aprobada.</sources>
<output>Cinco pasos numerados seguidos de preguntas pendientes de resolución.</output>

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

Un ejemplo de referencia nunca debe ampliar de forma implícita el permiso para utilizar información confidencial. Antes de pegar material en cualquiera de los dos sistemas, compruebe si está aprobado para ese entorno. Elimine datos personales y contenido confidencial que no sean necesarios para la transformación prevista.

Traslade el significado, no solo la puntuación

Una conversión exitosa entre modelos preserva las prioridades y los límites de las fuentes. No se limite a envolver a ciegas un prompt confuso entre etiquetas asumiendo que ha mejorado. Primero elimine instrucciones contradictorias, aclare requisitos obligatorios y distinga los ejemplos de los hechos. Luego exprese el mismo brief utilizando la estructura que su equipo pueda mantener más fácilmente.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Conserve el objetivo, la audiencia, las restricciones fácticas y los criterios de aceptación. Convierta los encabezados en etiquetas descriptivas sin añadir nuevos requisitos ni debilitar las restricciones existentes.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

Una comparación útil mantiene constante el entregable previsto. Si le pide a un sistema un resumen ejecutivo y al otro un análisis detallado, los resultados no permitirán juzgar con criterio la adecuación de los modelos. Normalice la tarea primero y luego examine en qué aspectos necesita corrección cada respuesta.

Asigne a los ejemplos una función precisa

Los ejemplos pueden demostrar el tono, la granularidad o la estructura, pero el modelo necesita saber qué cualidad debe imitar. Un artículo de referencia puede tener el ritmo adecuado y afirmaciones fácticas erróneas. Etiquételo en consecuencia. Las referencias reales publicadas son útiles cuando se analiza su relevancia, no cuando se asumen como automáticamente autorizadas ni cuando se copian directamente en la respuesta final.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Utilice la referencia únicamente para la extensión de los párrafos y la claridad directa. No reutilice su redacción, estadísticas, nombres de empresas ni afirmaciones fácticas. Utilice la hoja informativa aprobada para el contenido.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

No convierta una convención de formato en una superstición. Si una estructura simple de encabezados funciona bien en ambos sistemas, puede ser el estándar compartido más sencillo. Añada etiquetas cuando unos límites más claros ayuden, no porque cada tarea requiera un lenguaje de marcado elaborado.

Haga explícito el tratamiento de las fuentes

Ni un tono seguro ni una cita elegante demuestran que una respuesta esté fundamentada. Suministre las fuentes directamente cuando la precisión dependa de documentos específicos y solicite referencias rastreables a dichas fuentes. Si la función de navegación web está disponible, defina el alcance y solicite verificación. La disponibilidad de herramientas varía según los productos, cuentas y configuraciones; no asuma que todas las conversaciones pueden realizar búsquedas.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Para cada afirmación fáctica sustantiva, identifique la sección de la fuente que la respalda. Si la fuente no corrobora la afirmación, omítala o indíquela como pendiente de resolver. No invente URL ni citas textuales.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

Un ejemplo de referencia nunca debe ampliar de forma implícita el permiso para utilizar información confidencial. Antes de pegar material en cualquiera de los dos sistemas, compruebe si está aprobado para ese entorno. Elimine datos personales y contenido confidencial que no sean necesarios para la transformación prevista.

Especifique los resultados del razonamiento, no transcripciones ocultas

Para tareas analíticas, solicite una explicación concisa, supuestos relevantes y comprobaciones que el lector pueda verificar. La instrucción de revelar cada pensamiento interno es innecesaria y puede no ser compatible. Céntrese en el trabajo observable: cálculos, evidencias, alternativas y limitaciones. Ajuste la profundidad de la explicación solicitada a la decisión que el lector deba tomar.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Recomiende una opción. Proporcione la evidencia determinante, los supuestos clave, el compromiso o desventaja principal y una comprobación que podría invalidar la recomendación. Mantenga la explicación concisa y auditable.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

Una comparación útil mantiene constante el entregable previsto. Si le pide a un sistema un resumen ejecutivo y al otro un análisis detallado, los resultados no permitirán juzgar con criterio la adecuación de los modelos. Normalice la tarea primero y luego examine en qué aspectos necesita corrección cada respuesta.

Trate los datos estructurados como un requisito independiente

Las tablas en markdown y las instrucciones delimitadas por XML no equivalen a una salida procesable por máquinas y validada. Si un software va a consumir la respuesta, defina el esquema real de la salida. Utilice las funciones nativas de salidas estructuradas cuando estén disponibles y valide el resultado de forma externa al modelo. La corrección de los tipos de datos no garantiza la corrección del significado; aplique las reglas de negocio por separado.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Devuelva un objeto JSON con status, summary y source_ids. Si faltan evidencias, utilice el status needs_review y un array source_ids vacío. No incluya comentarios adicionales.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

No convierta una convención de formato en una superstición. Si una estructura simple de encabezados funciona bien en ambos sistemas, puede ser el estándar compartido más sencillo. Añada etiquetas cuando unos límites más claros ayuden, no porque cada tarea requiera un lenguaje de marcado elaborado.

Compare modelos con pruebas controladas

Ejecute ambos sistemas con el mismo brief y conjunto de fuentes, y luego compárelos frente a una rúbrica explícita. Incluya pruebas repetidas cuando la variabilidad sea un factor relevante. Registre el modelo exacto y los parámetros pertinentes en lugar de tratar a ChatGPT o Claude como una capacidad única y permanente. Los nombres comerciales engloban modelos, herramientas y funciones a nivel de cuenta que evolucionan con el tiempo.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Puntúe ambos resultados según la fidelidad a las fuentes, la compleción de la tarea, la adecuación a la audiencia y el cumplimiento del formato. Cite pasajes específicos. No favorezca una respuesta simplemente por ser más extensa.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

Un ejemplo de referencia nunca debe ampliar de forma implícita el permiso para utilizar información confidencial. Antes de pegar material en cualquiera de los dos sistemas, compruebe si está aprobado para ese entorno. Elimine datos personales y contenido confidencial que no sean necesarios para la transformación prevista.

Itere con comentarios específicos

Cuando un borrador no cumpla con lo esperado, identifique el fallo con precisión. Pedir que «lo mejore» da poca orientación al modelo y puede estropear partes que ya funcionaban. Conserve las secciones aceptadas y especifique el cambio mínimo requerido. Si el problema es la falta de evidencias, proporcione las evidencias en lugar de solicitar una reescritura con un tono más convincente.

Una implementación práctica

Comience con una tarea real que alguien pueda revisar. Identifique la información que el modelo debe recibir, la decisión que se le permite tomar y el punto en el que una persona debe asumir la responsabilidad. Escriba esos límites en el brief antes de generar el entregable. Esto mantiene el flujo de trabajo comprensible incluso cuando el modelo subyacente cambia.

Mantenga la estructura y los hechos verificados. Reescriba únicamente la introducción para una audiencia técnica escéptica. Elimine los beneficios que carezcan de respaldo y enumere cualquier evidencia faltante por separado.

Revise el resultado en función de la solicitud, no de lo pulido que suene. Compruebe si la información requerida está presente, si han aparecido suposiciones sin respaldo y si el lector previsto puede actuar a partir de la respuesta. Si un requisito no se cumple, señale ese fallo explícitamente en lugar de pedir una mejora imprecisa.

Una comparación útil mantiene constante el entregable previsto. Si le pide a un sistema un resumen ejecutivo y al otro un análisis detallado, los resultados no permitirán juzgar con criterio la adecuación de los modelos. Normalice la tarea primero y luego examine en qué aspectos necesita corrección cada respuesta.

Lista de verificación operativa reutilizable

Fase	Decisión requerida	Evidencia de compleción
Brief	¿Qué resultado y audiencia importan?	Un objetivo y criterios de aceptación por escrito
Entradas	¿Qué fuentes mandan?	Material de origen etiquetado y actualizado
Ejecución	¿Qué tiene permitido hacer el modelo?	Límites explícitos de herramientas y formato de salida
Revisión	¿Quién verifica el resultado?	Revisor asignado y correcciones registradas
Mantenimiento	¿Cuándo deben cambiar las instrucciones?	Responsable de la versión y notas de evaluación

Utilice esta lista de verificación como guía de diálogo, no como un mero trámite de cumplimiento. Si una fila carece de una respuesta clara, es muy probable que la tarea no esté bien especificada. Resuelva la decisión pendiente o delimite deliberadamente el entregable. Un borrador provisional con límites claros suele ser más útil que una respuesta aparentemente completa construida sobre supuestos ocultos.

Ponga el brief en práctica

PromptDeck transforma una idea preliminar en un prompt listo para copiar y pegar mediante una entrevista basada en tarjetas de preguntas sucesivas. Quick utiliza unas ocho preguntas, Standard unas quince y Deep alrededor de veinticinco. Elija el nivel de profundidad en función de la complejidad y el impacto del resultado, en lugar de asumir que una entrevista más larga es siempre mejor.

El método recopila objetivo, audiencia, contexto, restricciones, tono, formato, ejemplos, qué evitar y criterios de éxito. PromptDeck redacta encabezados en markdown para ChatGPT y etiquetas XML para Claude. También puede buscar ejemplos de referencia reales publicados en la web, y cuenta con un conector para ChatGPT/Claude. Inspeccione siempre las referencias antes de confiar en sus datos o utilizarlas como guía de estilo.

Dispone de un prompt gratuito. Pro cuesta 9 € al mes con 100 créditos, o 79 € al año. Pruebe PromptDeck gratis con una tarea que ya conozca lo suficiente como para evaluarla. Compare el resultado con su proceso habitual y registre qué mejoró, qué necesitó revisión y qué respuesta ausente en el brief habría evitado esa revisión.

Para conocer el método subyacente, consulte la guía de Brief Prompting y aprenda Brief Prompting. Explore puntos de partida concretos en la biblioteca o revise los errores habituales en prompts. El objetivo no es acumular más plantillas, sino facilitar la especificación y verificación de cada solicitud importante.

Preguntas frecuentes

¿Un prompt mejor redactado garantiza un resultado preciso?

No. Las instrucciones claras mejoran las condiciones para obtener resultados útiles, pero los modelos aún pueden interpretar mal las fuentes o generar afirmaciones sin respaldo. Verifique los hechos relevantes y recurra a una revisión humana adecuada antes de tomar decisiones de impacto o publicar contenidos.

¿Los prompts más largos funcionan siempre mejor?

No. El contexto relevante y las prioridades claras importan más que la extensión. Elimine la información redundante y resuelva las contradicciones. Utilice un brief más largo cuando la complejidad lo exija, no como sustituto de decidir qué es lo importante.

¿Puede servir un mismo brief para ChatGPT y Claude?

Sí. Conserve el objetivo, las fuentes, las restricciones y los criterios de aceptación; luego, adapte la presentación si resulta conveniente. Los encabezados en markdown y las etiquetas XML son opciones prácticas de estructuración, no requisitos exclusivos ni garantías de rendimiento.

¿Cuándo debería un equipo usar una entrevista en lugar de una plantilla?

Utilice una entrevista cuando quien hace la solicitud tenga una idea aproximada pero no haya articulado la audiencia, los límites o la definición de éxito. Utilice una plantilla estable cuando esas decisiones ya se conozcan y el flujo de trabajo se repita con entradas predecibles.

¿Qué debemos hacer cuando faltan evidencias?

Solicite la fuente que falta, acote el alcance de la tarea o señale la conclusión como pendiente de resolución. No incite al modelo a rellenar vacíos de evidencia con un tono seguro. Un límite claramente expuesto es mucho más útil que una respuesta sin respaldo.