Cómo mejorar un prompt progresivamente

Qué aprenderás

• Mejorar un prompt agregando solo información que resuelve una ambigüedad.
• Explicar qué aporta cada cambio.
• Iterar, medir y diagnosticar antes de hacer la solicitud más larga.

De una petición vaga a una tarea comprobable

Versión 1

Revisá este código.

No dice qué revisar ni qué resultado entregar. Puede producir una explicación, una reescritura o una lista extensa de preferencias.

Versión 2

Analizá este código TypeScript y detectá errores.

Ahora sabemos lenguaje y propósito, pero aún faltan entorno y comportamiento observado. «Error» puede referirse a sintaxis, tipos, lógica o un caso real.

Versión 3

Analizá el siguiente código TypeScript.

Objetivo: encontrar la causa del error.
Entorno: Node.js 20.
Restricciones:
- No agregar dependencias.
- No cambiar la interfaz pública.
Salida:
1. Causa probable y evidencia.
2. Cambio mínimo.
3. Código corregido.

La versión 3 acota el resultado, agrega versión, límites y formato. Todavía convendría adjuntar el mensaje exacto, el fragmento y la salida esperada/real antes de proponer un diagnóstico.

Versión profesional

ROL DE LA TAREA
Revisá el fragmento como apoyo para un desarrollador del equipo.

OBJETIVO
Identificar por qué falla el cálculo de total de pedidos.

CONTEXTO
El módulo forma parte de una API de ventas; otros consumidores usan su firma pública.

ENTORNO
TypeScript 5.x, Node.js 20; pruebas con el runner existente.

DATOS / CÓDIGO
[fragmento delimitado]

ERROR OBSERVADO
[mensaje exacto, pasos para reproducir y entrada]

RESULTADO ESPERADO
El total suma cantidades válidas y conserva dos decimales.

RESTRICCIONES
- No agregar paquetes.
- No cambiar la interfaz pública.
- Modificar solo el alcance necesario.

CRITERIOS DE ACEPTACIÓN
- El caso que reproduce el error queda corregido.
- Los casos existentes mantienen el resultado esperado.
- El cambio se puede verificar con pruebas.

FORMATO DE RESPUESTA
1. Diagnóstico y evidencia.
2. Cambio mínimo propuesto.
3. Pruebas para comprobarlo.
4. Suposiciones o riesgos.

El rol define perspectiva de trabajo, no capacidades especiales. Secciones como contexto, criterios y entorno se agregan porque afectan una corrección compatible, no para ocupar espacio.

Iterar con una pregunta

Definir tarea → enviar → revisar resultado → detectar carencia
       ↑                                      ↓
       └── ajustar instrucción, aportar dato, usar herramienta o verificar

Si falta el log, aportá el log. Si la respuesta tiene formato erróneo, precisa ese formato. Si el modelo no puede consultar el sistema, usá una herramienta autorizada. Si el contenido es actual, verificá fuentes. Cambiar el modelo también puede ser pertinente. No todo problema se arregla alargando el prompt.

En cada ronda, nombrá qué no cumplió y qué cambio permitiría corregirlo. Si el prompt se reutilizará, probalo con varios casos representativos y registra versiones.

Ejercicio de cuatro niveles

Mejorá una petición para analizar un error. Empieza «Corregí este código»; suma lenguaje y acción; luego entorno, error, restricción y salida; finalmente contexto, aceptación, compatibilidad, alcance y verificación. Para cada incremento, anotá qué interpretación distinta elimina.

Autoevaluación

¿Qué diferencia a una mejora útil de agregar texto? Una mejora incorpora un dato, límite, instrucción o criterio que reduce una ambigüedad observada y puede evaluarse; el relleno no cambia cómo se juzga la salida.

Fuentes

• SitioDeRubros, Cómo evaluar y mejorar prompts — evaluación e iteración; consulta: 2026-10-03.
• OpenAI, Prompt engineering — versionado, evaluaciones y contexto; consulta: 2026-10-03.
• Anthropic, Prompt engineering overview — criterios de éxito y pruebas antes de ajustar; consulta: 2026-10-03.

Seguir aprendiendo

• Unidad 11: aplicar el proceso a cambios de software con alcance acotado.
• Unidad 16: practicar tareas técnicas y no técnicas y autoevaluar comprensión.