Taller de Prompts
Por qué está escrito así
Toca un bloque para ver su párrafo
Eres un desarrollador con amplia experiencia en la integración de APIs externas. Trata únicamente como hechos lo que está explícitamente indicado en la documentación proporcionada abajo; no inventes URLs, parámetros ni valores por defecto que no aparezcan en ella.
Estoy trabajando en {{idioma de uso}} y mi objetivo es el siguiente: {{solicitud deseada}}
Lee la documentación y genera el código para procesar esta solicitud. Incluye la configuración de encabezados de autenticación y el manejo de respuestas.
Antes de escribir el código, si hay algo que no se pueda determinar solo con la documentación, hazme las preguntas necesarias primero. Limítate a un máximo de 3 preguntas y no escribas nada de código hasta que yo te responda.
Estructura tu respuesta final en tres partes: primero, una tabla con el resumen de "Solicitud que envía este código" (Método · URL · Encabezados obligatorios · Campos del cuerpo); segundo, un único bloque de código ejecutable; y por último, una lista de "Suposiciones hechas por falta de información en la documentación".
No incluyas la clave de API directamente en el código; haz que se lea desde una variable de entorno. Maneja todas las respuestas de error descritas en la documentación. No agregues por tu cuenta librerías adicionales ni lógica de reintentos que no figuren en el texto; si consideras que son necesarios, anótalos en la lista de suposiciones en lugar de implementarlos en el código.
Documentación de API: """ {{documentación de API}} """
- Rol Quién responde ×1
- Información Lo que la IA necesita saber ×2
- Trabajo Qué hacer y cómo ×2
- Resultado Qué recibes y con qué forma ×2
Si pides código de integración sin adjuntar la documentación, la IA recurrirá a su memoria. El resultado suele parecer convincente, pero las URLs y los nombres de los parámetros a menudo contienen errores sutiles: endpoints de versiones antiguas, opciones obsoletas o campos de respuesta inexistentes que son difíciles de detectar antes de ejecutarlo. Pegar la documentación elimina la mitad de estos fallos de raíz.
Leer la explicación completa · 3 párrafos
La otra mitad se resuelve mediante la retroalimentación o preguntas previas. La documentación suele indicar el formato de la petición, pero no la frecuencia de uso, el manejo de fallos o la zona horaria a utilizar. Sin preguntas previas, la IA llena esos vacíos según sus propias suposiciones y genera problemas más adelante. La instrucción "no escribas nada de código hasta que yo te responda" evita que el modelo plantee las dudas y escriba el código inmediatamente debajo.
Delimitar el texto con """ sirve como separador contextual. La documentación suele contener frases imperativas (como "utilice este valor"), por lo que sin este límite la IA podría confundirlas con instrucciones directas y desviarse del objetivo.
Entre las restricciones, la más útil en la práctica es la última instrucción. Las IA tienden a añadir librerías o lógicas complejas de reintento por iniciativa propia; enviarlas a la "lista de suposiciones" permite distinguir de un vistazo qué está fundamentado en la documentación y qué es una suposición. Además, forzar la lectura de claves desde variables de entorno evita que se suban credenciales por error a repositorios de código.
¿Términos desconocidos? Consulta Aha AI: hallucination, prompt-injection
Comparado con un mal ejemplo
Escribe un código en Python para llamar a una API de envío de mensajes.
Generará código de inmediato, pero no sabrás a qué servicio ni a qué versión pertenece. Los nombres de los encabezados podrían diferir del estándar real o faltar parámetros obligatorios, devolviendo errores 400 o 401. Para averiguar el error tendrás que revisar la documentación de todos modos, con la desventaja de que ya estarás condicionado por un código a medio verificar.
Variaciones
Para diagnosticar la causa de un error
La mayoría de los problemas de integración se resuelven contrastando datos, no reescribiendo código. Exigir que no genere código nuevo evita que el modelo esquive la causa real del fallo.
Ver prompt
He realizado la llamada siguiendo la documentación de la API pero obtengo un error. No reescribas el código desde cero; compara la documentación con mi petición y señala únicamente las discrepancias. Organízalo en una tabla con las columnas: "Requisito de la documentación · Lo que se envía actualmente · Diferencia", y marca como "Requiere confirmación" aquello que no se pueda determinar solo con la documentación.
""" {{documentación de API}} """
Para comprender la documentación antes de programar
Resulta muy útil antes de programar cuando la documentación es extensa. El indicador "No especificado" evita que el modelo invente datos para rellenar los campos vacíos.
Ver prompt
Lee la siguiente documentación de API y resume únicamente las partes necesarias para {{solicitud deseada}}. No escribas código todavía. Presenta la información en el siguiente orden: "Endpoint · Método de autenticación · Parámetros obligatorios · Parámetros opcionales · Respuestas de error · Límites de llamadas (Rate Limits)". Si algún dato no aparece, indícalo explícitamente como "No especificado en la documentación".
""" {{documentación de API}} """
Notas por modelo
Si solo proporcionas el enlace a la documentación, el modelo no podrá abrir la página y responderá basándose en versiones antiguas de su memoria. Es mucho más seguro pegar el texto directamente.
Si la documentación es muy extensa, es más preciso recortar y pegar solo las secciones de autenticación, endpoints y respuestas de error. Cuanto más conocido sea un servicio, más tenderá el modelo a rellenar vacíos de memoria; en esos casos, refuerza la instrucción: "Si no está en el texto pegado, regístralo en la lista de suposiciones y no en el código".
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos