Las mejores instrucciones para Claude facilitan la comprensión de la tarea: indica a Claude un objetivo, el material que debe utilizar, las restricciones relevantes y una forma de comprobar el resultado. A la hora de redactar, protege los datos y la siguiente acción del lector. En el caso de la investigación, relaciona las afirmaciones con las fuentes. En cuanto a la programación, define el comportamiento correcto y realiza pruebas.
Empieza con la tarea que necesites de las siguientes: redactar un correo electrónico, analizar un paquete de fuentes o corregir una función de Python. Elige entre 12 plantillas adaptables y, a continuación, explora tres ejemplos resueltos que se han probado con Claude en GlobalGPT. Cada ejemplo incluye la pregunta y la respuesta completas, para que puedas ver qué debes copiar, qué debes cambiar y qué debes comprobar en tu propio trabajo.
Si tu trabajo pasa de la investigación a la redacción y, a continuación, a la programación, GlobalGPT Reúne Claude y otros modelos líderes, junto con múltiples herramientas de IA, en una única suscripción asequible y un único panel de control. Podrás mantener todo el flujo de trabajo integrado y elegir el modelo o la función que mejor se adapte al siguiente paso.
En esta página
Las mejores indicaciones para Claude de un vistazo
Elige la plantilla según la decisión o el resultado que necesites. Sustituye los campos entre corchetes antes de enviarla. Las plantillas de redacción e investigación admiten texto pegado; las plantillas de programación que solicitan acceso a archivos o ejecución requieren una herramienta que pueda llevar a cabo realmente esas acciones.
Un formato inicial reutilizable es suficiente para muchos trabajos. Resumen de ingeniería de Anthropic Comienza con los criterios de éxito y una forma de comprobarlos. No hace falta recurrir a un perfil de experto muy complejo para definir qué debe incluir una respuesta útil.
Una breve plantilla inicial
Ayúdame con [TAREA] para [PÚBLICO O FIN].
Utiliza este material: [PEGAR MATERIAL].
Respeta estas restricciones: [HECHOS, ALCANCE, EXTENSIÓN O NORMAS].
Devuelve [FORMATO DE RESULTADO].
Un resultado satisfactorio debe [REQUISITOS VERIFICABLES].
Si falta algún detalle necesario, formula la pregunta concreta que impide completar la tarea.Utiliza títulos o etiquetas cuando sirvan para dividir mejor un resumen complejo. Directrices actuales de Anthropic sobre las indicaciones Recomienda instrucciones claras, ejemplos útiles y etiquetas XML descriptivas para el material mixto. Las etiquetas organizan el texto; no aportan pruebas, no otorgan acceso a herramientas ni hacen que una respuesta sea correcta.
Claude: ideas para escribir
A la hora de escribir, lo más difícil suele ser mantener el resumen sin perder el sentido al cambiar la forma de expresarlo. Indica lo que el lector debe hacer y qué detalles son fijos. Una frase fluida no sirve de nada si, de forma sutil, añade una promesa.
1. Redacta un correo electrónico a partir de un resumen objetivo
Una invitación clara, una notificación o un correo electrónico al cliente con datos que deben ser exactos. Trae: Resumen de los hechos, destinatarios, respuesta y límite de palabras.
W1 · Tarea representativa que se evalúa a continuación
Redacta el correo electrónico que se solicita en el resumen. Considera los datos confirmados como inalterables. Distingue claramente entre las peticiones y las confirmaciones. Sigue el formato y la extensión indicados. Utiliza únicamente los datos facilitados.
Destinatarios: [QUIÉN LEERÁ ESTO]
Objetivo: [QUÉ DEBE LOGRAR EL CORREO ELECTRÓNICO]
Datos confirmados: [FECHAS, HORAS, PRECIOS, LÍMITES Y OTROS DETALLES]
Detalles desconocidos o no confirmados: [LO QUE NO PUEDES PROMETER]
Acción del lector: [EL PRÓXIMO PASO EXACTO]
Tono: [TONO]
Resultado: un asunto y un cuerpo de [NÚMERO DE PALABRAS] palabras.Comprueba el resultado: Comprueba cada fecha, cada cifra, cada promesa y cada acción siguiente comparándolas con el resumen. Una frase adicional de tono amistoso puede suponer, aun así, una obligación.
2. Adapta el estilo de tu propia redacción
Un breve borrador que parece coherente con tu trabajo anterior. Trae: Dos o tres fragmentos que hayas escrito y los datos para el nuevo artículo.
W2 · Plantilla adaptable
Utiliza mis muestras de redacción para identificar tres rasgos de estilo observables: el ritmo de las frases, el nivel de formalidad y la forma en que explico las ideas. Aplica esos rasgos a un nuevo [FORMATO] dirigido a [PÚBLICO].
Utiliza los ejemplos únicamente para el estilo. Utiliza el nuevo resumen para los datos. Indica los tres rasgos y, a continuación, el borrador de [RANGO DE PALABRAS] palabras.
[PEGA TU PROPIO TEXTO]
[TEMA, OBJETIVO, HECHOS CONFIRMADOS Y ACCIÓN DEL LECTOR]Comprueba el resultado: Presta atención al ritmo de las frases y a la precisión, y comprueba después que los datos de ejemplo no se hayan colado en el nuevo borrador.
Elige ejemplos cuyo estilo quieras conservar. Una lista de adjetivos como “amable, perspicaz, profesional” deja más margen para la interpretación que unos cuantos ejemplos concretos. El nuevo briefing debe seguir siendo la fuente de los detalles objetivos.
3. Identifica los cambios que serían más importantes
Un borrador que parece flojo, pero que no invita a reescribirlo por completo. Trae: Tu borrador, el público al que va dirigido, el objetivo y cualquier fragmento que quieras conservar.
W3 · Plantilla adaptable
Revisa este borrador destinado a [PÚBLICO], que necesita [OBJETIVO DEL LECTOR]. Identifica hasta tres cambios que mejoren al máximo la claridad o la utilidad del texto. Si se necesitan menos de tres, indícalo.
Para cada cambio, cita el pasaje original, explica el problema que plantea al lector y propone una alternativa. Mantén el significado factual y estos elementos: [IMPRESCINDIBLE]. No reescribas todo el borrador.
[PEGAR BORRADOR]Comprueba el resultado: Descarta aquellas conclusiones que no puedan referirse a un pasaje concreto o a un problema significativo para el lector.
4. Reutilizar un mismo contenido para dos públicos distintos
Convertir una actualización aprobada en una nota interna y un mensaje para los clientes. Trae: Una fuente autorizada y dos resúmenes para el público.
W4 · Plantilla adaptable
Adapta el texto original aprobado en dos versiones breves:
A. [FORMATO, PÚBLICO, OBJETIVO, LÍMITE DE PALABRAS]
B. [FORMATO, PÚBLICO, OBJETIVO, LÍMITE DE PALABRAS]
Mantén la coherencia en las fechas, las cifras, la disponibilidad de las funciones y los compromisos. Modifica la explicación y los aspectos destacados para adaptarlos a cada público. Si un público necesita un detalle que no figura en el texto original, indica esa omisión al final de los borradores.
[PEGAR EL TEXTO ORIGINAL]Comprueba el resultado: Compara ambas versiones con la misma lista de datos; un nuevo público no justifica la introducción de nuevas características ni promesas.
Prueba estas tareas en GlobalGPT
Convierte un resumen en un correo electrónico, un paquete de información en una recomendación y un informe de error en una solución.
Utilizamos Claude Sonnet 5 en GlobalGPT para las tres tareas. Los borradores de correo electrónico conservaban los detalles clave del evento, las respuestas de la investigación identificaban motivos para posponer el lanzamiento y ambas correcciones en Python superaron las 24 comprobaciones cuando las ejecutamos por separado. Estos son puntos de partida útiles para el trabajo que puedes integrar en el mismo panel de control.
Para probarlo tú mismo, elige una plantilla de las que aparecen a continuación y sustituye el contenido de ejemplo por el tuyo propio. GlobalGPT reúne herramientas de redacción, investigación, programación y otras herramientas de IA en una única suscripción asequible, para que puedas pasar de comprender un problema a redactar el siguiente documento sin tener que hacer malabarismos con distintos servicios.
Cómo comparamos las indicaciones
El 14 de septiembre de 2026, cada tarea recibió dos indicaciones con el mismo material de referencia ficticio y los mismos requisitos: una instrucción breve y otra versión más estructurada. Conservamos la primera respuesta completa de cada una, lo que supuso un total de seis respuestas. La investigación se basó en los pasajes facilitados; el código Python devuelto se comprobó por separado, sin que el modelo lo ejecutara durante la conversación.
Estos ejemplos abarcan tres tareas, una por versión. A continuación se muestran las entradas y respuestas completas, junto con las modificaciones o revisiones que requiere cada resultado. Las 12 plantillas reutilizables no se han probado por separado.
Comparación de la primera salida · W
Redacta un correo electrónico sobre el evento incluyendo los datos más importantes.
| Consulte | Instrucciones sencillas | Enseñanza estructurada |
|---|---|---|
| Datos clave y comprobaciones de las medidas adoptadas | 8 / 9 | 8 / 9 |
| Longitud del cuerpo y de la cabeza | Aceptar · 126 palabras | Aceptar · 128 palabras |
| Promesa de seguimiento no autorizada | Presente | Presente |
Ambas versiones mantuvieron la fecha, las horas, el aforo, el precio, las notas y la distinción entre solicitar y confirmar una reserva. Esto te ofrece un borrador que puedes editar, en lugar de una página en blanco. Antes de enviarlo, elimina la promesa de seguimiento que ninguno de los dos informes autorizó; la versión sencilla también calificaba las sesiones de “idénticas” sin fundamentarlo. En tu propio correo electrónico, enumera tanto los datos que debes mantener como los compromisos que se te permite asumir.
Los ocho controles de revisión abarcan la fecha; las dos horas y la hora UTC; la duración; la capacidad por sesión; la asistencia gratuita; las notas descargables; la prohibición de grabar; y el hecho de solicitar una reserva en lugar de confirmarla. El noveno control verifica si hay datos o compromisos inventados. El recuento de palabras no incluye el tema.
Tiempo transcurrido: 9,73 s / 7,02 s. Tokens de entrada y salida registrados: 400 + 617 / 468 + 299. Una respuesta en cada caso; sin reintentos.
Instrucciones sencillas: indicaciones completas y material de referencia
Redacta el correo electrónico que se solicita en las instrucciones que figuran a continuación.
CASO DE PRUEBA FICTICIO. Se trata de datos inventados sobre un taller, no de una oferta real.
Debes redactar un correo electrónico de invitación para un taller comunitario ficticio llamado «Clear Notes».
Público objetivo: responsables de proyectos de equipos pequeños que desean tomar notas más claras en las reuniones.
Objetivo: invitar al lector a responder «MAÑANA» o «TARDE» para solicitar una plaza. La respuesta sirve para solicitar una plaza; no confirma la reserva.
Datos confirmados:
- Fecha: 8 de octubre de 2026.
- Hay dos sesiones independientes que comienzan a las 09:00 UTC y a las 16:00 UTC.
- Cada sesión dura 40 minutos.
- Cada sesión tiene 25 plazas.
- La asistencia es gratuita.
- Los asistentes recibirán notas descargables.
- No se facilitará ninguna grabación.
- No se ha fijado ninguna fecha límite de inscripción.
Entrega: un asunto y un cuerpo del correo electrónico de entre 100 y 140 palabras. Inglés sencillo y cordial; sin exageraciones. Incluye la fecha, ambas horas de inicio y la zona horaria, la duración, el aforo por sesión, el precio, los apuntes descargables, la ausencia de grabación y la acción que se debe realizar al responder. No inventes ningún enlace, fecha límite, reserva confirmada, ponente ni lugar de celebración. No pasa nada si no mencionas que no hay fecha límite de inscripción fijada.
Instrucciones sencillas: respuesta original completa
**Asunto: Taller «Clear Notes» – 8 de octubre de 2026 – Respuesta a la solicitud de plaza**
Hola,
Invitamos a los responsables de proyectos que deseen obtener actas de reuniones más claras y útiles a participar en «Clear Notes», un taller comunitario gratuito que tendrá lugar el 8 de octubre de 2026.
Habrá dos sesiones idénticas, cada una de 40 minutos de duración: una a las 09:00 UTC y otra a las 16:00 UTC. Cada sesión cuenta con 25 plazas disponibles.
La asistencia es gratuita y todos los participantes recibirán unas notas descargables para su archivo. Ten en cuenta que no se facilitará ninguna grabación, por lo que la asistencia en directo es la única forma de participar.
Para solicitar una plaza, solo tienes que responder a este correo electrónico indicando «MORNING» o «AFTERNOON», según la sesión que más te convenga. Responder a este correo es una solicitud de plaza; no confirma tu reserva. Pronto te daremos más detalles.
Gracias, y esperamos verte allí.Enseñanza estructurada: instrucciones completas y material de referencia
Redacta el correo electrónico de invitación tal y como se solicita en el briefing. Considera los datos confirmados como inalterables. Distingue claramente entre una solicitud de plaza y una reserva confirmada. Sigue el formato y la extensión indicados. Utiliza únicamente los datos facilitados.
SITUACIÓN DE PRUEBA FICTICIA. Se trata de datos inventados sobre un taller, no de una oferta real.
Estás redactando un correo electrónico de invitación para un taller comunitario ficticio llamado «Clear Notes».
Público objetivo: responsables de proyectos de equipos pequeños que desean notas de reunión más claras.
Objetivo: invitar al lector a responder «MAÑANA» o «TARDE» para solicitar una plaza. Una respuesta supone una solicitud de plaza; no confirma una reserva.
Datos confirmados:
- Fecha: 8 de octubre de 2026.
- Hay dos sesiones independientes que comienzan a las 09:00 UTC y a las 16:00 UTC.
- Cada sesión dura 40 minutos.
- Cada sesión tiene 25 plazas.
- La asistencia es gratuita.
- Los asistentes recibirán apuntes descargables.
- No se facilitará ninguna grabación.
- No se ha fijado ninguna fecha límite de inscripción.
Resultado esperado: un asunto y un cuerpo del correo electrónico de entre 100 y 140 palabras. Inglés sencillo y cordial; sin exageraciones. Incluye la fecha, las dos horas de inicio y la zona horaria, la duración, el aforo por sesión, el precio, los apuntes descargables, la ausencia de grabación y la acción de respuesta. No inventes ningún enlace, fecha límite, reserva confirmada, ponente ni lugar de celebración. No pasa nada si no mencionas que no hay fecha límite de inscripción fijada.
Enseñanza estructurada — respuesta original completa
Asunto: Estás invitado: Taller de Clear Notes – 8 de octubre de 2026
Hola,
Si eres responsable de proyectos y buscas tomar notas de reuniones más claras, nos encantaría contar contigo en el taller de Clear Notes el 8 de octubre de 2026.
Hay dos sesiones disponibles, cada una de 40 minutos de duración: una que comienza a las 09:00 UTC y otra a las 16:00 UTC. Cada sesión tiene 25 plazas y la asistencia es totalmente gratuita.
Todos los asistentes recibirán unas notas descargables para conservarlas y consultarlas posteriormente. Ten en cuenta que no se facilitará ninguna grabación, por lo que la asistencia en directo es la única forma de participar.
Para solicitar una plaza, solo tienes que responder con «MORNING» o «AFTERNOON», según la sesión que más te convenga. Responder supone solicitar una plaza, pero no confirma tu reserva; te enviaremos más detalles en breve.
Esperamos verte allí.
Un cordial saludo,
El equipo de Clear NotesClaude: ideas para la investigación
Las peticiones de investigación deben estar respaldadas por pruebas. Indica los fragmentos pertinentes con los identificadores de las fuentes, o utiliza una herramienta que permita recuperarlos realmente. Una URL por sí sola no es prueba de que Claude haya abierto una página. Estas plantillas separan lo que dicen las fuentes de lo que se puede concluir.
5. Sintetizar las fuentes sin restar importancia a las discrepancias
Responder a una pregunta de decisión a partir de documentos que puedes consultar. Trae: Extractos etiquetados, sus fechas, la cuestión objeto de la decisión y cualquier reclamación que deba someterse a auditoría.
R1 · Tarea representativa que se evalúa a continuación
Responde a la [PREGUNTA DE DECISIÓN] utilizando únicamente el paquete de fuentes que figura a continuación. Compara las definiciones, las poblaciones y los denominadores antes de considerar las diferencias numéricas como prueba de mejora. Distingue entre una afirmación preliminar y una medición. Vincula cada conclusión a una cita exacta de la fuente que realmente la respalde, y omite las pruebas que no existan.
Resultado: una recomendación de como máximo [LÍMITE] palabras; una tabla con la afirmación, el veredicto, el identificador de la fuente y la cita exacta que la respalda; y tres mediciones que faltan y que son necesarias para una comparación imparcial. Utiliza «Respaldado», «Parcialmente respaldado», «No respaldado» o «Contradicho» solo cuando las pruebas justifiquen esa calificación. Revisa estas afirmaciones: [AFIRMACIONES].
[ID DE FUENTES, FECHAS Y EXTRACTOS COMPLETOS PERTINENTES]Comprueba el resultado: Comprueba el texto citado, la afirmación que respalda y si las cantidades utilizan la misma definición y el mismo denominador.
6. Comprobar si una afirmación se corresponde con la fuente citada
Revisar un borrador antes de que una cita se utilice como prueba. Trae: La afirmación exacta y el fragmento original, no solo una URL.
R2 · Plantilla adaptable
Comprueba cada afirmación con el texto original que se proporciona junto a ella. Para cada una, indica: la afirmación, el ID de la fuente, la cita exacta relevante, el veredicto y una versión corregida si es necesario.
Utiliza «Respaldada» cuando la fuente respalde la afirmación en su totalidad; «Partially supported» cuando solo respalde una parte; «Unsupported» cuando no haya pruebas o estas sean insuficientes; y «Contradicted» cuando la fuente entre en conflicto directo con la afirmación. Si falta el texto de origen, indica que no puedes evaluar el respaldo. No deduzcas el contenido de la fuente a partir de su título o URL.
[PEGAR PARES DE AFIRMACIONES Y FUENTES]Comprueba el resultado: Una fuente fidedigna puede, aun así, no respaldar la afirmación. La ausencia de pruebas no constituye una contradicción.
“Sin fundamento” significa que las pruebas aportadas no respaldan la afirmación. “Contradicha” significa que las pruebas la refutan. Esa distinción es importante cuando una fuente aún no ha comunicado ningún resultado: no ha demostrado ni una mejora ni un empeoramiento.
7. Compara las opciones con tu resumen de decisión
Elegir entre opciones con un nivel de evidencia desigual. Trae: Tus criterios, limitaciones e información fiable sobre cada opción.
R3 · Plantilla adaptable
Compara [OPCIONES] para [DECISIÓN]. Utiliza estos criterios en el siguiente orden de prioridad: [CRITERIOS]. Restricciones estrictas: [RESTRICCIONES]. Utiliza únicamente la información sobre las opciones que figura a continuación.
Presenta una tabla comparativa, la opción mejor fundamentada y el dato que falta y que más probablemente modificaría esa elección. Marca los valores que faltan como «desconocidos». Mantén los datos separados de las valoraciones. No inventes precios, puntuaciones ni ponderaciones numéricas. Si no es posible seleccionar ninguna opción a partir de las pruebas, explica la disyuntiva concreta que queda sin resolver.
[PEGAR INFORMACIÓN VERIFICADA CON ID DE FUENTE]Comprueba el resultado: Comprueba si una recomendación depende de un valor desconocido o de ponderaciones que nunca has elegido.
8. Convertir un tema amplio en un plan de investigación
Empezar a investigar antes de disponer de suficientes fuentes para responder. Trae: Una decisión, un público, un alcance y un plazo.
R4 · Plantilla adaptable
Elabora un plan de investigación sobre [PREGUNTA] para ayudar a [PÚBLICO] a tomar [DECISIÓN]. Alcance: [REGIÓN, PERÍODO Y EXCLUSIONES]. Tiempo disponible: [TIEMPO].
Presenta cinco subpreguntas específicas. Para cada una de ellas, aporta las pruebas necesarias, indica el tipo de fuente primaria preferida, sugiere términos de búsqueda y señala un hallazgo que podría modificar la decisión. Concluye con las dos búsquedas de mayor prioridad. No inventes estudios ni afirmes que has leído fuentes. Si utilizas herramientas de navegación, identifica por separado las páginas que realmente has abierto y lo que cada una de ellas respalda.Comprueba el resultado: El resultado es un plan. Considera las búsquedas propuestas y las fuentes potenciales como pistas, no como una investigación concluida.
Comparación de la primera salida · R
La ausencia de un resultado no significa que una afirmación haya quedado refutada.
| Consulte | Instrucciones sencillas | Enseñanza estructurada |
|---|---|---|
| Comprobaciones de investigación predefinidas | 6 / 8 | 7 / 8 |
| Etiqueta de prueba de retención | Contradicto · demasiado fuerte | No admitido · adecuado |
| Cuentas invitadas frente a procesos de incorporación iniciados | No se explica de forma explícita | No se explica de forma explícita |
Ambas respuestas rechazaron una implantación a gran escala y reconocieron que los proyectos piloto utilizaban diferentes definiciones de activación y poblaciones. La versión estructurada calificó correctamente la afirmación sobre la retención como “Sin fundamento”. La versión sencilla indicaba “Contradicha”, aunque su cita solo establecía que no existían resultados sobre la retención. Ninguna de las dos respuestas destacó explícitamente los diferentes denominadores.
Las tasas fueron de 40/50 cuentas invitadas (80%) y 54/60 procesos de incorporación iniciados (90%). El cálculo es correcto; las métricas no son intercambiables. La respuesta estructurada incluía una comprobación adicional para determinar si “activación” significaba lo mismo. Se trataba de una cuestión analítica adicional, no de una cuarta afirmación incluida en la nota informativa sobre el lanzamiento.
| Reclamación por nota de servicio | Lo que admite la fuente proporcionada | Tratamiento adecuado |
|---|---|---|
| B aumentó la activación en 10 puntos porcentuales | Diferentes tasas, definiciones, denominadores y poblaciones | No consideres esa diferencia como una mejora causal |
| B: mayor retención | S3: aún no hay resultados sobre la retención a 30 días | No hay pruebas que lo respalden; tampoco se ha refutado |
| B redujo el tiempo de asistencia a seis horas | S3: mediana combinada, sin desglose por estudio piloto | No se ha demostrado ninguna reducción |
Ver las ocho comprobaciones de investigación
1. A: 40/50 = 80%, utilizando cuentas invitadas. Ambos cumplen los requisitos.
2. B: 54/60 = 90%, utilizando los inicios de incorporación. Ambos cumplen los requisitos; las citas de la fuente incluyen los denominadores.
3. Señalar explícitamente tanto las diferentes definiciones de activación como los diferentes denominadores. Ambos suspenden en la parte del denominador.
4. No considerar la ausencia de resultados de retención como prueba de mejora. Ambos explican la falta de datos.
5. No considerar la mediana de apoyo agrupada como una disminución demostrada. Ambos aprueban.
6. No deducir un beneficio causal ni justificar un despliegue completo a partir de estas pruebas piloto. Ambos superan la prueba.
7. Hacer coincidir cada afirmación y etiqueta de evidencia con lo que respalda la cita mencionada. La respuesta simple falla en «Contradicha»; la estructurada la supera.
8. Identificar tres mediciones específicas que faltan. Ambos superan la prueba.
La etiqueta incorrecta de la respuesta simple se cuenta una vez, en la comprobación 7.Tiempo transcurrido: 31,35 s / 31,07 s. Tokens de entrada y salida registrados: 743 + 2822 / 832 + 2837. Una respuesta en cada caso; sin reintentos.
Instrucciones sencillas: indicaciones completas y material de referencia
Responde a la tarea que aparece al final de este paquete de fuentes.
# Paquete de investigación ficticia
Todas las organizaciones, datos, citas y documentos que aparecen a continuación son inventados para una prueba reproducible. Las identificaciones de las fuentes se refieren únicamente a este paquete; no se trata de estudios públicos.
## S1 — Cierre de la prueba piloto A, 2 de septiembre de 2026
"La prueba piloto A invitó a 50 cuentas; 40 completaron la activación en un plazo de siete días".
"La activación consistía en crear un espacio de trabajo e invitar al menos a un compañero de equipo".
"Las cuentas eran clientes existentes seleccionados por el equipo de éxito del cliente".
"La prueba piloto utilizó una incorporación guiada".
## S2 — Nota del panel de control de la prueba piloto B, 3 de septiembre de 2026
"El programa piloto B registró 60 inicios de incorporación; 54 cuentas crearon un espacio de trabajo en un plazo de siete días".
"Este panel de control considera que la creación de un espacio de trabajo equivale a la activación; no requiere la invitación de un compañero de equipo".
"No se registró el número de invitaciones".
"Las cuentas eran nuevos registros de autoservicio realizados mediante una lista de verificación".
## S3 — Revisión del analista, 4 de septiembre de 2026
"Las pruebas piloto no se realizaron de forma aleatoria y utilizaron diferentes grupos de cuentas".
"El tiempo medio de respuesta del servicio de asistencia fue de seis horas en el conjunto de las dos pruebas piloto; no se desglosó por prueba".
"Aún no se dispone de resultados sobre la retención a 30 días ni sobre los ingresos".
## S4 — Borrador de la nota de implementación, 5 de septiembre de 2026
"La prueba piloto B aumentó la activación en 10 puntos porcentuales, mejoró la retención y redujo el tiempo de atención al cliente a seis horas. Implemente la lista de comprobación en todas las cuentas".
Se trata de un borrador de propuesta, no de una fuente de datos adicional. Sus afirmaciones deben contrastarse con S1–S3.
## Tarea común a ambas versiones de la consigna
Respuesta: ¿Justifica este paquete la implantación del programa piloto B en todas las cuentas?
Utiliza únicamente S1–S4. Elabora: (1) una recomendación de un máximo de 120 palabras; (2) una tabla con las columnas «Afirmación», «Veredicto», «ID de la fuente» y «Cita exacta que lo respalda»; y (3) tres mediciones que faltan y que son necesarias para una comparación imparcial.
Analiza las tres afirmaciones empíricas del memorándum de implantación: el aumento de la activación, la mejora de la retención y la reducción del tiempo de asistencia. Utiliza los veredictos «Respaldado», «Parcialmente respaldado», «No respaldado» o «Contradicho», con una breve explicación si es necesario. Incluye las tasas numéricas y sus denominadores en la recomendación o en la tabla. No inventes citas, URL, efectos causales ni conclusiones que no figuren en el paquete.
Instrucciones sencillas: respuesta original completa
## Recomendación (≤120 palabras)
No pongas en marcha todavía el programa piloto B. La tasa de activación bruta del programa piloto B (54/60 = 90%) es 10 puntos porcentuales superior a la del programa piloto A (40/50 = 80%), pero los dos programas piloto midieron la "activación" de forma diferente (el B no requiere una invitación de un compañero de equipo), se basaron en poblaciones distintas (nuevos registros por autoservicio frente a clientes existentes) y no se aleatorizaron (S3); por lo tanto, la diferencia no puede atribuirse a la lista de comprobación. La afirmación sobre la retención carece de fundamento: S3 afirma explícitamente que aún no existen datos de retención a 30 días. La cifra de "seis horas" de tiempo de atención al cliente es una mediana combinada de ambos programas piloto, no desglosada por programa, por lo que no se demuestra ninguna reducción específica del programa piloto B. Se necesita una comparación controlada, emparejada y definida de forma coherente antes del lanzamiento.
## Tabla de auditoría de afirmaciones
| Afirmación | Veredicto | ID de la fuente | Cita exacta que la respalda |
|---|---|---|---|
| "El programa piloto B aumentó la activación en 10 puntos porcentuales" | Parcialmente respaldada: las tasas brutas difieren en 10 puntos porcentuales (54/60 = 90% frente a 40/50 = 80%), pero las definiciones, las poblaciones y el diseño difieren, por lo que la diferencia no es atribuible a la lista de comprobación | S1 | "El programa piloto A invitó a 50 cuentas; 40 completaron la activación en un plazo de siete días". |
| (misma afirmación, cont.) | | S2 | "El programa piloto B registró 60 inicios de incorporación; 54 cuentas crearon un espacio de trabajo en un plazo de siete días". / "No requiere una invitación de un compañero de equipo" |
| (misma afirmación, cont.) | | S3 | "Las pruebas piloto no fueron aleatorias y utilizaron poblaciones de cuentas diferentes". |
| "mejora de la retención" | Contradicho: no existen datos de retención que respalden esto | S3 | "Aún no se dispone de resultados de retención a los 30 días ni de ingresos". |
| "Reducción del tiempo de atención al usuario a seis horas" | Sin fundamento: la cifra es una mediana combinada, no atribuida al programa piloto B ni presentada como una reducción | S3 | "La mediana del tiempo de respuesta de la atención al usuario fue de seis horas en el conjunto de los dos programas piloto; no se desglosó por programa". |
## Faltan tres mediciones necesarias para una comparación justa
1. Tasas de activación para ambos programas piloto utilizando una definición idéntica (por ejemplo, creación de un espacio de trabajo *y* al menos una invitación a un compañero de equipo).
2. Tiempo de respuesta del servicio de asistencia indicado por separado para el programa piloto A y el programa piloto B (no una mediana combinada), a ser posible con una referencia previa al programa piloto.
3. Resultados de retención (y de ingresos) a 30 días para ambos programas piloto, recopilados a partir de poblaciones de cuentas comparables, a ser posible aleatorizadas o emparejadas.Enseñanza estructurada: instrucciones completas y material de referencia
Responde a la tarea utilizando únicamente este paquete de fuentes. Compara las definiciones, las poblaciones y los denominadores antes de considerar las dos tasas como prueba de una mejora. Distingue entre una afirmación preliminar y una medición. Relaciona cada conclusión con una cita exacta de la fuente que realmente la respalde, y omite las pruebas que no existan.
# Paquete de investigación ficticio
Todas las organizaciones, datos, citas y documentos que figuran a continuación son inventados para una prueba reproducible. Las identificaciones de las fuentes se refieren únicamente a este paquete; no son estudios públicos.
## S1 — Cierre de la prueba piloto A, 2 de septiembre de 2026
"La prueba piloto A invitó a 50 cuentas; 40 completaron la activación en un plazo de siete días".
"La activación consistía en crear un espacio de trabajo e invitar al menos a un compañero de equipo".
"Las cuentas eran clientes existentes seleccionados por el equipo de éxito del cliente".
"La prueba piloto utilizó un proceso de incorporación guiado".
## S2 — Nota del panel de control del programa piloto B, 3 de septiembre de 2026
"El programa piloto B registró 60 inicios de incorporación; 54 cuentas crearon un espacio de trabajo en un plazo de siete días."
"Este panel de control denomina "activación" a la creación de un espacio de trabajo; no requiere la invitación de un compañero de equipo."
"No se registró el número de invitaciones".
"Las cuentas correspondían a nuevos registros por autoservicio realizados mediante una lista de verificación".
## S3 — Revisión del analista, 4 de septiembre de 2026
"Los programas piloto no se realizaron de forma aleatoria y utilizaron poblaciones de cuentas diferentes".
"La mediana del tiempo de respuesta del servicio de asistencia fue de seis horas en el conjunto de las dos pruebas piloto; no se desglosó por prueba".
"Aún no se dispone de resultados sobre la retención a 30 días ni sobre los ingresos".
## S4 — Borrador de nota de implementación, 5 de septiembre de 2026
«El programa piloto B aumentó la activación en 10 puntos porcentuales, mejoró la retención y redujo el tiempo de atención al cliente a seis horas. Implemente la lista de verificación en todas las cuentas».
Se trata de un borrador de propuesta, no de una fuente de datos adicional. Sus afirmaciones deben contrastarse con S1–S3.
## Tarea compartida por ambas versiones de la indicación
Respuesta: ¿Justifica este paquete la implantación del programa piloto B en todas las cuentas?
Utiliza únicamente S1–S4. Elabora: (1) una recomendación de un máximo de 120 palabras; (2) una tabla con las columnas «Afirmación», «Veredicto», «ID de la fuente» y «Cita exacta que lo respalda»; y (3) tres mediciones que faltan y que son necesarias para una comparación justa.
Analiza las tres afirmaciones empíricas del memorándum de implantación: el aumento de la activación, la mejora de la retención y la reducción del tiempo de asistencia. Utiliza los veredictos «Respaldado», «Respaldado parcialmente», «No respaldado» o «Contradicho», con una breve explicación si es necesario. Incluye las tasas numéricas y sus denominadores en la recomendación o en la tabla. No inventes citas, URL, efectos causales ni conclusiones que no figuren en el paquete.
Enseñanza estructurada — respuesta original completa
## Recomendación (≤120 palabras)
No, el informe no justifica una implantación completa del programa piloto B. Programa piloto A: 40 de 50 cuentas (80%) alcanzaron la "activación" —definida como la creación de un espacio de trabajo *más* la invitación a un compañero de equipo— entre los clientes existentes. Programa piloto B: 54 de 60 cuentas (90%) crearon un espacio de trabajo en un plazo de siete días, sin necesidad de invitación, entre los nuevos registros de autoservicio. La diferencia bruta de 10 puntos (90%−80%) mezcla diferentes definiciones, diferentes poblaciones y carece de aleatorización (S3), por lo que no puede interpretarse como que la lista de verificación "aumenta" la activación. Aún no existen datos de retención a 30 días ni de ingresos (S3), por lo que la "mejora de la retención" carece de pruebas. La cifra de seis horas de asistencia es una mediana *combinada* de ambos programas piloto, no desglosada por programa, por lo que la "reducción del tiempo de asistencia" carece de referencia o de datos específicos por programa.
Tabla ##
| Afirmación | Veredicto | ID de la fuente | Cita exacta que la respalda |
|---|---|---|---|
| "El programa piloto B aumentó la activación en 10 puntos porcentuales" | Parcialmente respaldada: existe la diferencia aritmética (54/60 = 90% frente a 40/50 = 80%), pero la comparación está sesgada y no puede respaldar una afirmación causal de "aumento" | S1, S2, S3 | S1: "El piloto A invitó a 50 cuentas; 40 completaron la activación en un plazo de siete días". / S2: "El piloto B registró 60 inicios de incorporación; 54 cuentas crearon un espacio de trabajo en un plazo de siete días". / S3: "Los pilotos no se asignaron aleatoriamente y utilizaron poblaciones de cuentas diferentes". |
| La activación se midió de la misma manera en ambos programas piloto | Contradicho | S1, S2 | S1: "La activación consistía en crear un espacio de trabajo e invitar al menos a un compañero de equipo". / S2: "Este panel de control denomina activación a la creación de un espacio de trabajo; no requiere la invitación de un compañero de equipo". |
| "mejora de la retención" | Sin fundamento | S3 | "Aún no se dispone de resultados sobre la retención a 30 días ni sobre los ingresos". |
| "reducción del tiempo de respuesta del servicio de asistencia a seis horas" | Sin fundamento | S3 | "La mediana del tiempo de respuesta del servicio de asistencia fue de seis horas en el conjunto de los dos programas piloto; no se desglosó por programa". |
## Tres mediciones que faltan y que son necesarias para una comparación justa
1. Tiempos de respuesta del servicio de asistencia específicos de cada programa piloto (no agrupados), antes y después de la lista de comprobación, para poder aislar cualquier cambio atribuible al programa piloto B.
2. Cifras de retención a 30 días (e ingresos) para ambos programas piloto, ya que actualmente no existen ("Aún no se dispone de resultados sobre la retención a 30 días ni sobre los ingresos", S3).
3. Una única definición de activación compartida (por ejemplo, creación de un espacio de trabajo *y* invitación de compañeros de equipo) aplicada a poblaciones de cuentas comparables, a ser posible aleatorias, en ambos programas piloto, en lugar de mezclar clientes existentes (S1) con nuevos registros de autoservicio (S2).Cuando una tarea de investigación se convierta en un borrador, mantén el paquete de fuentes adjunto al resumen de redacción. El espacio de trabajo multimodelo de GlobalGPT Te permite alternar entre la investigación, la redacción y la programación en un único panel de control. Transfiere tanto los datos como el resumen, para que la siguiente fase cuente con toda la información necesaria.
Claude: sugerencias para la programación
Una indicación útil para la programación describe el comportamiento, el entorno y lo que se considera fijo. En un chat, pega el código pertinente y el mensaje de error. En el código Claude, haz referencia a los archivos accesibles y proporciona un objetivo de verificación concreto. El mismo texto no convierte un chat en un terminal.
Guía sobre el código Anthropic de Claude recomienda asignar al asistente tareas que pueda ejecutar, como pruebas o una compilación. Su biblioteca oficial de indicaciones considera las indicaciones como puntos de partida que hay que adaptar, con un resultado, material de referencia y una forma de verificar el trabajo.
9. Realizar la depuración teniendo en cuenta el comportamiento explícito y los casos extremos
Programar una pequeña función cuyo comportamiento puedas definir. Trae: Código, comportamiento esperado, error o caso de fallo, tiempo de ejecución y restricciones.
C1 · Tarea representativa que se evalúa a continuación
Corrige el código según la especificación completa. Comprueba la validación antes de las salidas anticipadas, los límites inclusivos o exclusivos y las reglas que deben seguir aplicándose cuando se produce una excepción. Conserva [PUBLIC INTERFACE]. Cambia solo lo que exija la especificación.
[ENTRADAS VÁLIDAS, COMPORTAMIENTO ANTE ENTRADAS NO VÁLIDAS, REGLAS DE NEGOCIO Y SALIDAS ESPERADAS]
[PEGAR CÓDIGO]
[TIEMPO DE EJECUCIÓN, DEPENDENCIAS Y DISPONIBILIDAD DE HERRAMIENTAS DE EJECUCIÓN]
Envía el código corregido y una breve explicación. Informa únicamente de las verificaciones que hayas realizado realmente. Si la ejecución no está disponible, indícalo y especifica las comprobaciones que debo realizar.Comprueba el resultado: Ejecuta casos independientes. Una explicación convincente no es un programa que se ejecute correctamente.
10. Redactar pruebas a partir de una especificación
Detectar los casos que faltan antes de dar por buena una implementación. Trae: Requisitos de comportamiento y el marco de pruebas del proyecto.
C2 · Plantilla adaptable
Escribe pruebas para [FUNCIÓN O COMPONENTE] utilizando [MARCO DE PRUEBAS]. Considera la especificación que figura a continuación como el contrato. Cubre un caso normal, cada límite establecido, entradas no válidas e interacciones entre reglas cuando sean relevantes.
Para cada prueba, identifica el requisito que comprueba y su resultado esperado. Mantén intactos los requisitos existentes. Si la especificación es ambigua, identifica la cuestión que lo impide en lugar de hacer conjeturas. Con herramientas de ejecución, ejecuta las pruebas pertinentes e informa del comando y el resultado reales; de lo contrario, márcalas como «no ejecutadas».
[PEGAR ESPECIFICACIÓN]
[PEGAR CÓDIGO O HACER REFERENCIA A UN ARCHIVO ACCESIBLE]Comprueba el resultado: Las pruebas deben garantizar el cumplimiento de la especificación, no reproducir un error de la implementación actual.
Siempre que sea posible, mantén las pruebas independientes de la implementación. En el caso de una calculadora de gastos de envío, comprueba los umbrales de peso exactos y una entrada no válida que, de otro modo, activaría el envío gratuito. Los ejemplos de «casos favorables» por sí solos no reflejan las interacciones entre las reglas.
11. Reestructurar sin ampliar el volumen de trabajo
Mejorar un pequeño fragmento de código sin alterar su comportamiento. Trae: El código, el problema concreto de mantenimiento y los requisitos de compatibilidad.
C3 · Plantilla adaptable
Reestructurar [CÓDIGO O ARCHIVO ACCESIBLE] para mejorar [UN PROBLEMA DE MANTENIMIENTO ESPECÍFICO]. Conservar [API PÚBLICA, TIPOS DE RETORNO, COMPORTAMIENTO ANTE ERRORES Y OTROS CONTRATOS]. Utilizar únicamente las dependencias existentes. No añadas funcionalidades ajenas al tema ni rediseñes módulos adyacentes.
Presenta el cambio útil más pequeño posible, explica cualquier comportamiento que no hayas podido conservar e identifica las pruebas necesarias para verificar la compatibilidad. Si hay herramientas disponibles, ejecuta esas comprobaciones y muestra el resultado; de lo contrario, indica las comprobaciones propuestas y señala que no se han ejecutado.
[PEGAR CÓDIGO Y PRUEBAS PERTINENTES]Comprueba el resultado: Revisa el archivo «diff» para detectar cambios que no se incluyan en el alcance solicitado y, a continuación, vuelve a ejecutar las pruebas pertinentes.
12. Explicar un código desconocido a partir de una entrada concreta
Comprender una función antes de modificarla. Trae: El código propiamente dicho y un ejemplo de entrada.
C4 · Plantilla adaptable
Explica este código a un desarrollador que conozca [CONTEXTO] pero que sea nuevo en [LENGUAJE O PROYECTO]. Sigue este ejemplo de entrada: [ENTRADA]. Describe la entrada, las ramas relevantes, los cambios de estado y la salida esperada.
Señala los nombres de las funciones y las expresiones concretas. Distingue entre lo que muestra el código y las suposiciones sobre dependencias que faltan. Termina con un caso extremo que merezca la pena probar. No reescribas el código ni inventes comportamientos para funciones cuyas definiciones no estén presentes.
[PEGAR CÓDIGO]
Comprueba el resultado: Comprueba la rama descrita y el valor devuelto comparándolos con el código; marca las dependencias que falten como «desconocidas».
Comparación de la primera salida · C
Ambas funciones devueltas superaron los 24 casos.
| Consulte | Instrucciones sencillas | Enseñanza estructurada |
|---|---|---|
| Casos locales independientes | 24 / 24 | 24 / 24 |
| Cambios en la función «small» | Sí | Sí |
| Afirmación sobre las pruebas basadas en herramientas | No existe tal afirmación | Indica explícitamente que no se debe ejecutar |
Tanto la versión «simple» como la «estructurada» gestionaron los límites de peso, el envío gratuito, el recargo por destino remoto y los datos de entrada no válidos según nuestra especificación fija. La respuesta «estructurada» indicaba explícitamente que no se habían ejecutado pruebas. A continuación, ejecutamos ambas funciones nosotros mismos; la respuesta «simple» tampoco había indicado que se hubieran ejecutado pruebas.
Ver las 24 entradas y los resultados reales de aprobado/suspenso
| [gramos, subtotal en céntimos, remoto] | Céntimos previstos o excepción | Sin aderezos | Estructurado |
|---|---|---|---|
| [1, 0, false] | 500 | Pasar | Pasar |
| [1000, 0, false] | 500 | Pasar | Pasar |
| [1001, 0, false] | 900 | Pasar | Pasar |
| [5000, 0, false] | 900 | Pasar | Pasar |
| [5001, 0, false] | 1500 | Pasar | Pasar |
| [1, 9999, false] | 500 | Pasar | Pasar |
| [1, 10 000, falso] | 0 | Pasar | Pasar |
| [1000, 10 000, true] | 300 | Pasar | Pasar |
| [5001, 0, true] | 1800 | Pasar | Pasar |
| [1001, 9999, true] | 1200 | Pasar | Pasar |
| [5001, 10001, false] | 0 | Pasar | Pasar |
| [0, 0, false] | ValueError | Pasar | Pasar |
| [-1, 0, false] | ValueError | Pasar | Pasar |
| [1,0, 0, false] | ValueError | Pasar | Pasar |
| ["1000", 0, false] | ValueError | Pasar | Pasar |
| [verdadero, 0, falso] | ValueError | Pasar | Pasar |
| [null, 0, false] | ValueError | Pasar | Pasar |
| [1, -1, falso] | ValueError | Pasar | Pasar |
| [1, falso, falso] | ValueError | Pasar | Pasar |
| [1, 1,5, falso] | ValueError | Pasar | Pasar |
| [1, "0", false] | ValueError | Pasar | Pasar |
| [1, 0, 1] | ValueError | Pasar | Pasar |
| [1, 0, null] | ValueError | Pasar | Pasar |
| [0, 10000, false] | ValueError | Pasar | Pasar |
Las entradas y los resultados esperados se fijaron antes de la generación. Los valores devueltos debían ser números enteros exactos; las entradas no válidas debían provocar un error «ValueError». Ambas funciones se revisaron y, a continuación, se ejecutaron en un proceso local en el que se denegó el acceso a la red, así como la lectura y escritura de archivos de usuario. El hecho de superar estas pruebas constituye una prueba de la validez de esta función y de su especificación, pero no implica que esté lista para su uso en producción.
Tiempo transcurrido: 12,58 s / 13,30 s. Tokens de entrada y salida registrados: 553 + 735 / 621 + 1015. Una respuesta en cada caso; sin reintentos.
Instrucciones sencillas: indicaciones completas y material de referencia
Modifica la función según las especificaciones que figuran a continuación y entrega el resultado solicitado.
# Calculadora ficticia de gastos de envío
Python 3. Sin conexión a red ni paquetes externos. Modifica la función `shipping_cents(weight_grams, subtotal_cents, remote=False)` en el código que aparece a continuación.
Especificaciones:
- weight_grams es un entero positivo. subtotal_cents es un entero no negativo. Los valores booleanos de Python no son enteros válidos para estas dos entradas.
- remote debe ser un valor booleano.
- Genera un ValueError ante cualquier entrada no válida, incluso cuando el pedido cumpla los requisitos para el envío básico gratuito.
- El envío básico es de 500 céntimos para 1–1000 gramos, 900 céntimos para 1001–5000 gramos y 1500 céntimos para más de 5000 gramos.
- Un subtotal de al menos 10 000 céntimos exime únicamente del envío básico.
- La entrega a distancia añade 300 céntimos, incluso en pedidos con envío básico gratuito.
- Devuelve un entero. Mantén la firma de la función. No modifiques los datos de entrada, no realices operaciones de E/S ni importes paquetes.
Código con errores:
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if subtotal_cents >= 10000:
return 0
if weight_grams < 1000:
fee = 500
elif peso_gramos < 5000:
tarifa = 900
else:
tarifa = 1500
if remote:
tarifa += 300
return tarifa
```
Entrega: un bloque delimitado de Python que contenga la función corregida, seguido de una breve explicación de los cambios. No afirmes haber ejecutado el código a menos que dispongas realmente de herramientas de ejecución. El evaluador ejecutará casos que abarquen los umbrales, la regla de envío gratuito, el recargo por envío a distancia y todas las categorías de entradas no válidas de esta especificación.
Instrucciones sencillas: respuesta original completa
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if isinstance(weight_grams, bool) or not isinstance(weight_grams, int):
raise ValueError("weight_grams debe ser un entero")
si peso_gramos <= 0:
raise ValueError("peso_gramos debe ser positivo")
si isinstance(subtotal_cents, bool) o no isinstance(subtotal_cents, int):
raise ValueError("subtotal_cents debe ser un entero")
si subtotal_cents < 0:
raise ValueError("subtotal_cents debe ser no negativo")
si no es un valor booleano (remote):
raise ValueError("remote debe ser un bool")
si weight_grams <= 1000:
fee = 500
elif weight_grams = 10000:
fee = 0
if remote:
fee += 300
return fee
```
Cambios realizados:
1. **Se ha añadido validación de entrada**: Comprueba que `peso_gramos` y `subtotal_cents` sean de tipo `int` (excluyendo `bool`, ya que `bool` es una subclase de `int`), que `peso_gramos` sea positivo, que `subtotal_cents` sea no negativo y que `remoto` sea de tipo `bool`. De lo contrario, se genera un `ValueError`, incluso si el pedido cumpliera los requisitos para el envío gratuito.
2. **Se han corregido los umbrales de peso**: Se han cambiado `< 1000` y `< 5000` por `<= 1000` y `<= 5000`, de modo que los límites (1000 g, 5000 g) se sitúen en el nivel correcto según la especificación ("1–1000 gramos", "1001–5000 gramos", "más de 5000 gramos").
3. **Se ha corregido la lógica del pedido con envío gratuito**: El código original devolvía `0` inmediatamente cuando el subtotal cumplía los requisitos para el envío gratuito, omitiendo por completo el recargo por envío a zonas remotas. Ahora se calcula primero la tarifa base, se pone a cero si el subtotal cumple los requisitos, y *luego* se añade el recargo por zona remota, lo que garantiza que el envío a zonas remotas siga sumando 300 céntimos incluso con envío base gratuito.
4. **Tipo de retorno**: Todos los valores de las tarifas siguen siendo enteros simples, cumpliendo así el requisito de retorno de tipo `int`.Enseñanza estructurada: instrucciones completas y material de referencia
Corrige la función según la especificación completa. Aplica la validación de entradas antes de cualquier retorno anticipado, mantén los umbrales inclusivos y separa la tarifa base del recargo por envío a distancia. Proporciona la función solicitada y la explicación correspondiente. Indica únicamente las comprobaciones que hayas realizado realmente.
# Calculadora de gastos de envío ficticia
Python 3. Sin red ni paquetes externos. Corrige la función shipping_cents(weight_grams, subtotal_cents, remote=False) en el código que aparece a continuación.
Especificaciones:
- weight_grams es un entero positivo. subtotal_cents es un entero no negativo. Los valores booleanos de Python no son enteros válidos para estas dos entradas.
- remote debe ser un valor booleano.
- Genera un ValueError ante cualquier entrada no válida, incluso cuando el pedido cumpla los requisitos para el envío básico gratuito.
- El envío básico es de 500 céntimos para 1-1000 gramos, 900 céntimos para 1001-5000 gramos y 1500 céntimos para más de 5000 gramos.
- Un subtotal de al menos 10 000 céntimos exime únicamente del envío básico.
- La entrega a zonas remotas añade 300 céntimos, incluso en pedidos con envío básico gratuito.
- Devuelve un entero. Mantén la firma de la función. No modifiques los datos de entrada, no realices operaciones de E/S ni importes paquetes.
Código con errores:
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if subtotal_cents >= 10000:
return 0
if weight_grams < 1000:
fee = 500
elif peso_gramos < 5000:
tarifa = 900
else:
tarifa = 1500
if remote:
tarifa += 300
return tarifa
```
Entrega: un bloque delimitado de Python que contenga la función corregida, seguido de una breve explicación de los cambios. No afirmes haber ejecutado el código a menos que dispongas realmente de herramientas de ejecución. El evaluador ejecutará casos que abarquen los umbrales, la regla de envío gratuito, el recargo por envío a distancia y todas las categorías de entradas no válidas de esta especificación.
Enseñanza estructurada — respuesta original completa
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if isinstance(weight_grams, bool) or not isinstance(weight_grams, int):
raise ValueError("peso_gramos debe ser un entero (no un valor booleano)")
si peso_gramos <= 0:
raise ValueError("peso_gramos debe ser positivo")
si isinstance(subtotal_cents, bool) o no isinstance(subtotal_cents, int):
raise ValueError("subtotal_cents debe ser un entero (no un valor booleano)")
si subtotal_cents < 0:
raise ValueError("subtotal_cents debe ser no negativo")
si no es de tipo bool:
raise ValueError("remote debe ser un valor booleano")
si weight_grams <= 1000:
base_fee = 500
elif weight_grams = 10000:
base_fee = 0
recargo = 300 si remote, en caso contrario 0
devuelve base_fee + recargo
```
Explicación de los cambios:
1. **La validación de entradas se ha trasladado antes de cualquier retorno anticipado.** El código original devolvía `0` para `subtotal_cents >= 10000` sin validar primero ninguna entrada. Ahora toda la validación (comprobaciones de tipo para `weight_grams`, `subtotal_cents` y `remote`, incluida la exclusión explícita de `bool` para los dos campos enteros, ya que `bool` es una subclase de `int` en Python) se realizan antes de cualquier lógica de tarifa o instrucción de retorno, por lo que las entradas no válidas siempre provocan un `ValueError`, incluso cuando el pedido cumpliría los requisitos para un envío básico gratuito.
2. **Se han corregido los umbrales inclusivos.** El código original utilizaba `< 1000` y `< 5000`, lo que excluía los valores límite (1000 y 5000) del rango inferior, contrariamente a lo establecido en la especificación: "1–1000 gramos" y "1001–5000 gramos" de la especificación. Se ha cambiado a `<= 1000` y `= 10 000`, lo que omitía incorrectamente el recargo por envío a distancia en los pedidos con envío gratuito. Ahora `base_fee` y `surcharge` se calculan de forma independiente: `base_fee` se establece en `0` cuando se alcanza el umbral del subtotal, pero `surcharge` (300 céntimos si `remote`) siempre se añade además, cumpliendo así con la regla "La entrega a zonas remotas añade 300 céntimos, incluidos los pedidos con envío básico gratuito".
4. **Tipo de retorno.** Todos los componentes de la tarifa son enteros simples, y la suma `base_fee + surcharge` se devuelve como un `int`, lo que se ajusta a la firma y al tipo de retorno requeridos.
**Verificación realmente realizada:** Ninguna. No dispongo de herramientas de ejecución de código en este entorno, por lo que no he ejecutado este código. Lo anterior se basa únicamente en la lectura manual de la especificación y en el seguimiento de la lógica a mano; no he ejecutado casos de prueba con él.Para trabajos que combinan código con tareas relacionadas con texto, imágenes o vídeo, puedes Conectar la CLI del GlobalGPT al código del Claude e integrar el modelo y las funciones multimedia de la plataforma en un flujo de trabajo de terminal. Empieza por una tarea concreta y por los criterios de verificación que utilizarás para validar el resultado.
¿Qué cambió cuando concretamos las indicaciones?
En esta ronda, la estructura adicional ayudó a tomar una decisión de investigación. No eliminó la promesa añadida del correo electrónico ni mejoró la función de envío, que ya era correcta. Dado que ambas versiones contaban con unos requisitos completos, la comparación sirve como recordatorio útil: la calidad del briefing es importante antes de empezar a añadir más instrucciones.
Resultados de los ejemplos emparejados
Cada tarea requiere un control específico.
| Medida específica para cada tarea | Instrucciones sencillas | Enseñanza estructurada | Qué hacer con el resultado |
|---|---|---|---|
| Redacción de datos y compromisos | 8 de 9 | 8 de 9 | Eliminar las promesas de seguimiento inventadas |
| Verificación de las pruebas científicas | 6 de 8 | 7 de 8 | Corrige la etiqueta de la prueba y compara los denominadores |
| Casos de comportamiento de Python | 24 de 24 | 24 de 24 | Mantén una especificación ejecutable y pruebas independientes |
Se trata de recuentos procedentes de diferentes listas de comprobación, no de porcentajes comparables ni de una puntuación global del modelo. Las instrucciones completas, las respuestas originales y los detalles de la prueba figuran debajo de cada ejemplo. El tiempo de ejecución en una sola pasada y el recuento de tokens describen estas solicitudes; no establecen ninguna ventaja en cuanto a velocidad o coste.
Utiliza una indicación breve cuando el encargo y el material de referencia ya estén claros. Añade estructura cuando resulte difícil diferenciar entre instrucciones, documentos, ejemplos o requisitos contradictorios. Las directrices de Anthropic también distinguen el comportamiento específico de cada modelo, por lo que la vieja costumbre de exigir comprobaciones repetidas por parte del usuario no debería convertirse en un paso automático que se añada a cada solicitud.
Cómo solucionar una pregunta que da lugar a una respuesta poco convincente
Cambia la parte que ha causado el problema. Si la respuesta ha inventado un plazo, “mejora esto” es demasiado impreciso. Señala el detalle que no está bien fundamentado, establece los límites y pide una corrección concreta. Mantén la respuesta original si estás comparando diferentes versiones de la consigna, en lugar de sustituirla sin más.
| ¿Qué salió mal? | Qué hay que aportar o modificar | Un seguimiento útil |
|---|---|---|
| La respuesta es genérica | Un lector, una tarea concreta y material real | Reescribe el texto para [público] utilizando únicamente estos datos: [resumen]. |
| La voz suena rara | Un ejemplo de un texto escrito por ti mismo | Adapta el ritmo y el grado de formalidad de la frase a los de este ejemplo; mantén los hechos del nuevo escrito. |
| Añade una promesa | Un límite explícito y la frase controvertida | Elimina el compromiso de seguimiento. La fuente no lo autoriza. |
| La cita parece verosímil | El fragmento citado | ¿Este fragmento respalda la afirmación en su totalidad, solo en parte o en absoluto? |
| Ambos porcentajes parecen similares | Definiciones, denominadores, poblaciones, período | Indica por qué se divide cada porcentaje antes de comparar las tasas. |
| El código parece correcto, pero da error | Una entrada que da error de forma reproducible y el resultado esperado | Esta entrada debería devolver [valor], pero devuelve [valor]. Corrige la regla y ejecuta este caso. |
En el caso de un requisito que realmente falte, deja que Claude plantee una pregunta concreta. En el caso de una tarea corriente con suficiente contexto, una entrevista obligatoria de veinte preguntas solo retrasa el trabajo. Del mismo modo, pide una explicación concisa, pruebas o resultados de pruebas, en lugar de un resumen del razonamiento interno privado.
Guarda las indicaciones útiles junto con el formato de la entrada y las comprobaciones que detectaron los errores. Si la tarea se convierte en un flujo de trabajo repetible de la aplicación, utilizando Claude a través de una API Te permite gestionar las versiones de las indicaciones y mantener un registro de las solicitudes. Vuelve a revisar tus propios ejemplos cuando cambien los requisitos del modelo o de la tarea.
PREGUNTAS FRECUENTES
¿Qué debe incluir una buena indicación para Claude?
Incluye la tarea, el contexto relevante o el material de referencia, las restricciones importantes, el resultado deseado y una comprobación para verificar si se ha realizado correctamente. En el caso de una solicitud sencilla, una sola frase puede abarcar varios de estos aspectos. Utiliza una estructura más detallada cuando combines documentos, ejemplos o reglas que, de otro modo, podrían prestarse a confusión.
¿Las indicaciones de Claude necesitan etiquetas XML?
No. Un lenguaje claro y sencillo es un buen punto de partida. Las etiquetas XML pueden ayudar a separar las instrucciones, los ejemplos y el texto original en una indicación compleja. Utiliza etiquetas descriptivas que faciliten el seguimiento de las distintas partes. Las etiquetas no garantizan la exactitud de los datos, y su mera presencia no basta para determinar que una indicación sea mejor que otra.
¿Puede Claude comprobar fuentes que no puede abrir?
Puede analizar el texto que le facilites, pero el título o la URL de una fuente no bastan para determinar el contenido de una página. Pega el fragmento pertinente o utiliza las herramientas de navegación disponibles para localizarlo. A continuación, comprueba tanto la cita como si dicha cita respalda la afirmación concreta que se le atribuye.
¿Puedo utilizar la misma instrucción en el chat de Claude y en Claude Code?
Puedes reutilizar la tarea y las restricciones, pero adapta la solicitud a las herramientas disponibles. En el chat, facilita el código y el contexto pertinente. En Claude Code, puedes hacer referencia a los archivos del proyecto a los que tengas acceso y solicitar su ejecución. Una indicación que diga “ejecuta las pruebas” no es prueba de que las pruebas se hayan ejecutado realmente.
Las mejores indicaciones de Claude son aquellas que puedes adaptar y verificar. Empieza con una tarea recurrente, sustituye el material de ejemplo por el tuyo propio y utiliza las comprobaciones que aparecen junto a la plantilla antes de dar por buena la respuesta. Prueba el flujo de trabajo en GlobalGPT cuando el siguiente paso requiera otro modelo o herramienta de IA en el mismo espacio de trabajo.
Fuentes y fecha de la prueba: Las instrucciones oficiales y la documentación del código Claude se revisaron el 14 de septiembre de 2026. Los ejemplos emparejados se generaron con Claude en GlobalGPT en esa fecha utilizando material ficticio. Consulta las instrucciones y respuestas completas más arriba y, a continuación, adapta una plantilla a tu propia tarea.
