Taller de Prompts
Por qué está escrito así
Toca un bloque para ver su párrafo
Eres un desarrollador sénior habituado a recibir y mantener código heredado por otros. Tu criterio para comentar es claro: "¿Qué necesita entender alguien que abra este código por primera vez dentro de seis meses?".
El siguiente código está escrito en {{idioma especificado}} y queremos estandarizar sus comentarios usando el formato {{formato de nota}}.
Lee el código y añade los comentarios pertinentes. No cambies ni una sola línea ni carácter del código original; devuelve el código completo exactamente como está, solo con los comentarios insertados.
En los comentarios, no expliques lo que el código ya dice por sí mismo; explica lo que el lector no podría deducir solo con mirarlo. Por ejemplo, en una línea de cálculo de descuento, no pongas "Calcula el importe del descuento", sino "El descuento del cupón no puede superar el 30% del total (límite por política de negocio)", aclarando el motivo de esa lógica. En la cabecera de las funciones, detalla qué reciben, qué devuelven y qué ocurre en casos excepcionales o errores.
No comentes línea por línea. Limítate a las decisiones críticas de negocio, manejo de excepciones o zonas sensibles ante futuras modificaciones. Si hay partes cuyo motivo no se puede deducir del código y requerirían adivinar, no pongas comentarios dudosos: lístalas al final en una sección aparte llamada "Puntos pendientes de validación".
Código: """ {{código fuente}} """
- Rol Quién responde ×1
- Información Lo que la IA necesita saber ×3
- Trabajo Qué hacer y cómo ×1
- Resultado Qué recibes y con qué forma ×1
Cuando le pides a una IA que comente código, tiende a añadir notas en cada línea: encima de total = sum(...) suele escribir "Calcula la suma". Aunque no sea incorrecto, solo repite la sintaxis en lenguaje natural, alargando el archivo sin explicar por qué, por ejemplo, existe un límite del 30%. Este prompt no solo pide comentarios, sino que define dónde y por qué colocarlos.
Leer la explicación completa · 3 párrafos
Incluir un ejemplo contrastado dentro de la instrucción es clave. Decir "haz comentarios útiles" es ambiguo y no cambia el resultado. Al mostrar un mal comentario frente a uno bueno, la IA asimila el estándar de calidad y lo replica con la misma densidad en el resto del bloque.
Se aplican restricciones en dos sentidos: la orden "no cambies ni un solo carácter del código" evita que la IA refactorice variables o simplifique condicionales por su cuenta, facilitando el diff de la revisión. Por su parte, "no comentes línea por línea" previene la saturación, mientras que la sección de "Puntos pendientes de validación" evita que el modelo invente lógica de negocio desconocida.
Especificar el formato por su nombre estándar (JSDoc, Google Style, etc.) garantiza coherencia: evita que unas funciones tengan tablas de parámetros detalladas y otras solo una línea descriptiva. El uso de delimitadores """ previene que comentarios previos del código se interpreten como instrucciones del sistema.
¿Términos desconocidos? Consulta Aha AI: few-shot, output-format
Comparado con un mal ejemplo
Comenta este código:
(código pegado)
Generará comentarios redundantes en casi todas las líneas traduciendo el código a texto plano, dificultando la lectura. Además, es común que renombre variables o altere la indentación silenciosamente, arriesgando commits con cambios no deseados.
Variaciones
Cuando ya existen comentarios pero contradicen el código
Un comentario desactualizado es más peligroso que la falta de comentarios. Pedir una auditoría comparativa evita que el modelo reescriba documentación que aún es válida.
Ver prompt
El siguiente código en {{idioma especificado}} ya cuenta con comentarios. Compara el código con dichos comentarios e identifica exclusivamente aquellos que hayan quedado desactualizados o contradigan la lógica actual. Organízalos en una tabla con las columnas: "Ubicación · Lo que dice el comentario · Lo que hace el código realmente · Comentario corregido". No incluyas los comentarios que ya sean correctos.
""" {{código fuente}} """
Documentación general para traspaso de proyecto
Útil para documentar la arquitectura a nivel de archivo en lugar de función por función. El límite de líneas evita resúmenes excesivamente largos o triviales.
Ver prompt
Redacta el encabezado descriptivo del archivo en formato {{formato de nota}} para quien herede este código en {{idioma especificado}}. Debe explicar: 1) responsabilidad principal del módulo, 2) supuestos o datos de entrada esperados, y 3) componentes relacionados que deben revisarse al hacer cambios. Todo estructurado en ese orden y en no más de 10 líneas.
""" {{código fuente}} """
Notas por modelo
Si introduces un archivo muy largo de golpe, los comentarios de las últimas funciones serán más escuetos. Conviene dividirlo en bloques de 5 a 6 funciones e indicar el formato en cada iteración.
Al solicitar que devuelva archivos extensos completos con comentarios, algunos modelos pueden truncar la salida o resumir partes con "...". En esos casos, es más seguro procesar bloques de 5 o 6 funciones a la vez, o solicitar únicamente una tabla con los comentarios y sus números de línea correspondientes para insertarlos manualmente.
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos