Por qué está escrito así
Al documentar APIs con ChatGPT, el error más común es que se incluyan parámetros inventados. Si solo se proporciona el código, la IA suele asumir convenciones comunes de REST e inventa parámetros como page, limit o sort. Quien intente usar la API basándose en esa documentación terminará enviando datos inexistentes y recibiendo errores 400.
Por eso, la sección de la tarea especifica "únicamente los endpoints que estén explícitamente definidos". Listar qué campos extraer (ruta, método, solicitud, respuesta, errores) evita que la IA se limite a dar solo la ruta y un resumen, saltándose el cuerpo de la petición. Incluir las respuestas de error es crucial: una documentación que solo describe casos de éxito ayuda muy poco al frontend.
Declarar el marco de trabajo al inicio ayuda a interpretar correctamente las reglas de ruteo y decoradores (por ejemplo, si @RequestParam es query o body, o si req.params son variables de ruta). La columna "Ubicación (Path/Query/Body)" en el formato garantiza que esta distinción quede registrada.
Las restricciones de poner "No verificable en el código" y "(estimado)" actúan como red de seguridad: cuando se le da a la IA una etiqueta explícita para lo que no sabe, prefiere usarla antes que inventar. Delimitar el código con """ previene que comentarios internos como "TODO: ignorar esto" sean leídos como instrucciones.
¿Términos desconocidos? Consulta Aha AI: hallucination, output-format
Comparado con un mal ejemplo
Crea la documentación de la API con este código router.post('/api/orders', auth, async (req, res) => { ... (código pegado)
Generará una tabla, pero mezclará parámetros no existentes como page o limit, y omitirá si son obligatorios o su ubicación (path/query/body), provocando fallos al integrarla. A menudo se omiten los errores y, al procesar varios endpoints juntos, el formato se vuelve inconsistente.
Variaciones
Cuando necesitas ejemplos de llamadas
Para cada endpoint del siguiente código en {{marco de trabajo}}, genera un ejemplo de solicitud (un comando curl de una sola línea) y ejemplos JSON de respuestas exitosas y con error. Utiliza únicamente los campos presentes en el código; si debes rellenar algún valor no definido, usa el término sample y marca su posición.
""" {{código fuente}} """
Solicita ejemplos prácticos para pruebas directas. Forzar a marcar los valores arbitrarios evita que los ejemplos se tomen como datos reales definitivos.
Para explicar a perfiles no técnicos
Organiza los endpoints del siguiente código en {{marco de trabajo}} en una tabla de tres columnas comprensible para gestores de producto: "Qué función cumple · Cuándo se ejecuta · Qué necesita para funcionar". Omite nombres de campos técnicos y tipos de datos; explica el comportamiento desde la perspectiva del usuario en pantalla.
""" {{código fuente}} """
Ideal para acordar el alcance funcional. Al retirar los tipos de datos técnicos, el documento es breve y la discusión se centra en el comportamiento del producto.
Notas por modelo
Si el código está dividido en varios archivos, envía los archivos de rutas uno por uno y, al final, solicita: "Combina las tablas creadas hasta ahora en una sola".
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos