Errores frecuentes, ejercicios y autoevaluación

Qué aprenderás

• Reconocer fallos habituales antes de enviar un prompt.
• Transferir la estructura a áreas técnicas y no técnicas.
• Comprobar comprensión con 18 preguntas razonadas.

Errores frecuentes

• Objetivo ambiguo: «arreglá esto» no identifica el resultado.
• Falta de contexto: omitir audiencia, versión o proceso cuando cambia la respuesta.
• Exceso irrelevante: pegar material que no influye en la tarea.
• Instrucciones contradictorias: pedir «una frase» y «detalle exhaustivo» sin prioridad.
• Mezclar instrucciones y datos: el contenido analizado queda ambiguo.
• No indicar versión: recibir una solución que no funciona en el entorno.
• Demasiadas tareas simultáneas: mezclar analizar, traducir, corregir, resumir y decidir.
• Formato indefinido: cada respuesta llega con una forma distinta.
• Sin criterios de aceptación: decidir por impresión si el resultado alcanza.
• Suponer conocimiento interno: el modelo no conoce la política o sistema que no recibió.
• Aceptar sin verificar: una respuesta fluida puede contener errores.
• Buscar frases mágicas: el rol o una fórmula no reemplazan datos y criterio.
• Prompt largo sin propósito: más texto no implica mejor información.

Ejercicios progresivos técnicos

Partí de la misma necesidad —corregir un error— y avanzá:

Nivel 1

Corregí este código.

Nivel 2

Analizá este código TypeScript y corregí el error.

Nivel 3: añadí entorno/versiones, error literal, restricciones y salida esperada.

Nivel 4: añadí contexto, comportamiento esperado/real, criterios de aceptación, compatibilidad, alcance y verificación. Para cada paso respondé «¿qué ambigüedad concreta eliminé?». Si no hay respuesta, quizá agregaste texto innecesario.

El ejercicio equivalente en TypeScript, Python y SQL está desarrollado en la Unidad 11; SQL incluye motor, esquema y controles de transacción. La estructura permanece aunque cambie la tecnología.

Ejercicios profesionales no técnicos

1. Soporte — clasificar reclamos: agrupa los textos delimitados en categorías acordadas; entrega categoría y evidencia breve; marca «requiere revisión» si no hay información suficiente. Prueba con un caso ambiguo.
2. Administración — resumir documentos: resume el documento vigente para una audiencia definida; separa obligaciones, fechas y datos faltantes; no inventa cláusulas. Contrasta el resumen con la fuente.
3. Comercial — preparar una comparación: usa propuestas adjuntas, moneda y periodo; compara alcance, precio y vigencia; indica diferencias no comparables en vez de declarar un ganador ficticio.
4. Análisis funcional — aclarar requisitos: convierte «mejorar devoluciones» en preguntas de aclaración agrupadas por actores, reglas, excepciones y medición; no propongas solución aún.
5. QA — crear casos de prueba: parte de criterios de aceptación; genera casos positivos, negativos y de borde, con entrada, resultado esperado y criterio cubierto. Revisa que cada caso tenga una condición comprobable.
6. Liderazgo — preparar una decisión: sintetiza las opciones, impacto, incertidumbres y próximos pasos para una audiencia ejecutiva; usa solo las fuentes provistas y distingue hechos de recomendaciones.

Autoevaluación

Respondé primero con tus palabras; después compará con las respuestas razonadas.

Preguntas

1. ¿Qué es un prompt y cómo se relaciona con el contexto?
2. Nombra tres cosas que un prompt puede influir y dos que no puede garantizar.
3. ¿En qué se diferencia el objetivo de las instrucciones?
4. ¿Qué información de contexto incluirías para resumir un documento para soporte?
5. ¿Cuál es la diferencia entre restricción y criterio de aceptación?
6. ¿Para qué separar instrucciones y datos con delimitadores?
7. ¿Por qué pedir JSON no elimina la necesidad de validarlo?
8. Define zero-shot, one-shot y few-shot.
9. ¿Por qué few-shot puede rendir peor que una instrucción sin ejemplos?
10. ¿Markdown, XML o JSON es universalmente mejor? Explica la elección.
11. ¿Qué aportan los delimitadores y qué límites tienen?
12. En el ejercicio progresivo, ¿qué aporta especificar runtime y error observado?
13. ¿Qué contexto es importante para pedir cambios de programación?
14. ¿Qué evidencia permite hacer debugging en vez de adivinar?
15. ¿Qué datos agregarías a un pedido de optimización SQL y por qué importa el motor?
16. ¿Qué información hace verificable una migración y cómo se aborda una revisión de seguridad?
17. ¿Para qué sirven placeholders, versionado y campos opcionales en un template?
18. ¿Cómo verificás que una respuesta profesional satisface realmente la solicitud?

Respuestas razonadas

1. Es la entrada para pedir una tarea. Puede incluir instrucción y datos; el contexto es la información efectiva relevante disponible para generar la respuesta. El alcance de «prompt» varía según conversación o API.
2. Puede influir en claridad, relevancia y formato. No garantiza verdad ni acceso a una fuente inexistente; tampoco crea una capacidad que el modelo no tiene.
3. El objetivo define el resultado que buscamos; las instrucciones enumeran acciones para producirlo. «Entender por qué falla» es objetivo; «compará la entrada y salida y localizá la rama que difiere» es instrucción.
4. Audiencia y uso del resumen, documento y versión autorizada, extensión/formato y qué extraer. No hace falta enviar material ajeno a la decisión.
5. La restricción delimita soluciones permitidas; el criterio de aceptación es una condición observable para aceptar el resultado. «Sin dependencias nuevas» versus «los 10 casos acordados pasan».
6. Para que sea claro qué hacer y qué contenido analizar; esto reduce confusión, no reemplaza controles de seguridad de la aplicación.
7. El texto del prompt no garantiza sintaxis, esquema ni valores válidos. Hay que parsear, comprobar campos y tipos y tratar errores.
8. Zero-shot no incluye ejemplo; one-shot incluye uno; few-shot incluye varios ejemplos de entrada y salida.
9. Los ejemplos consumen contexto, pueden sesgar o enseñar un patrón incorrecto. Se agregan para aclarar una regla concreta y se evalúan.
10. No. Markdown facilita lectura y jerarquía; XML separa regiones etiquetadas; JSON representa datos procesables. La tarea y el consumidor determinan el formato.
11. Hacen visibles los límites entre regiones. No imponen cumplimiento, no validan salida ni hacen seguro el contenido por sí mismos.
12. Identifican las herramientas y sintaxis compatibles, y el error literal aporta evidencia. Sin ellos, el diagnóstico puede asumir otra ejecución o imaginar una causa.
13. Lenguaje/versiones, framework/runtime, código relevante, arquitectura, dependencias, comportamiento actual y esperado, alcance, restricciones y criterios.
14. Error exacto/stack trace, pasos para reproducir, entrada, salida esperada y real, entorno y fragmento mínimo relevante. Si algo falta, pedirlo o enumerar hipótesis verificables.
15. Motor/versión, esquema, relaciones, volúmenes, índices, consulta, parámetros, resultado, plan y tiempo observados, transacción y restricciones. Dialectos y optimizadores difieren; validar en el motor real.
16. Una migración identifica origen/destino, versiones, comportamiento a preservar, etapas, compatibilidad, pruebas y rollback. Una revisión de seguridad delimita superficie, evidencia y límites; se complementa con pruebas y especialistas.
17. Placeholders separan valores variables del texto estable; campos opcionales evitan completar información irrelevante; el versionado permite evaluar cambios y volver a una versión conocida.
18. Comparando la salida con criterios, datos y formato solicitados; para código, compilar/probar comportamiento; para SQL, contrastar resultados, plan y volumen; para texto, revisar estructura, fuentes, audiencia y cobertura. La verificación adecuada depende del riesgo.

Checklist final

• Puedo convertir una necesidad ambigua en objetivo, datos, límites y resultado esperado.
• Distingo qué controla mi instrucción de lo que debe comprobarse externamente.
• Elijo formato y ejemplos por su aporte concreto.
• Sé pedir análisis, modificación, debugging y SQL sin asumir que los dialectos coinciden.
• Verifico la salida antes de usarla en un proceso profesional.

Fuentes

• OpenAI, Prompt engineering — ejemplos, estructura, iteración y contexto; consulta: 2026-10-03.
• Anthropic, Prompt engineering overview — criterios de éxito, pruebas y elección de solución; consulta: 2026-10-03.
• SitioDeRubros, Cómo evaluar y mejorar prompts — referencia para desarrollar la evaluación; consulta: 2026-10-03.
• IETF, RFC 8259: JSON — contrato de sintaxis JSON; consulta: 2026-10-03.

Seguir aprendiendo

• Regresá a la unidad del componente que querés mejorar; no hace falta memorizar una fórmula.
• M4 desarrollará Context Engineering; M5 abordará el uso profesional, responsable y seguro.
• Usá el Manual completo de IA para continuar el recorrido.