1. Modelo mental
El error más común es tratar el prompting como literatura secreta. En trabajo real funciona mejor pensar en unbriefing: qué quieres conseguir, para quién, con qué material, qué no debe hacer el modelo y cómo reconocerás una buena salida.
La instrucción perfecta no compensa información ausente. Si el modelo necesita conocer cifras, políticas, estilo o ejemplos, proporciónalos o conecta una fuente. Cuando falten datos, pedir que pregunte antes de asumir suele ser mejor que obligarlo a completar huecos.
El prompt también es una interfaz. Debe ser legible por la persona que lo mantendrá dentro de tres meses. Si depende de cincuenta reglas contradictorias, probablemente el problema es de diseño del workflow, no de redacción.
2. Conceptos que debes dominar
Describe el cambio que quieres producir, no sólo la acción: “decidir entre tres opciones” es mejor que “analiza esto”.
Información que ayuda a interpretar la tarea: audiencia, situación, proceso, restricciones y vocabulario.
Texto, datos, documentos o ejemplos sobre los que se debe trabajar. Es distinto del contexto general.
Condiciones que convierten una salida en aceptable: exactitud, tono, formato, cobertura, longitud o evidencia.
Tabla, JSON, checklist, memo, email o estructura específica. El formato reduce ambigüedad y facilita validación.
Uno o dos ejemplos de alta calidad pueden enseñar matices que una lista de reglas no captura.
Autorizar al modelo a preguntar cuando falte información evita que rellene huecos con suposiciones.
Primero estructura, luego contenido, después edición. Intentar resolver todo de una vez oculta dónde falla.
3. Workflow paso a paso
Escribe el resultado
Describe qué debe existir al final y quién lo usará.
La salida tiene un propósito y una audiencia.
Aporta el material
Pega sólo la información necesaria y marca claramente dónde empieza y termina.
No mezclas instrucciones con datos no confiables.
Declara restricciones
Indica privacidad, tono, longitud, fuentes permitidas y cosas que no debe inventar.
Las restricciones no se contradicen.
Pide un método
Para tareas complejas, pide primero un plan o análisis de criterios antes de la salida final.
Puedes revisar el enfoque antes del resultado.
Define formato
Usa encabezados, tabla o esquema verificable.
La salida se puede comparar con una plantilla.
Añade criterio de calidad
Explica qué revisar: hechos, cobertura, claridad, citas, riesgos.
La evaluación no depende sólo de gusto.
Prueba casos límite
Incluye una entrada incompleta, ambigua o adversarial.
El prompt falla de forma visible y segura.
Versiona
Guarda la plantilla y anota por qué cambiaste cada regla.
Puedes volver a una versión que funcionaba.
4. Ejemplo completo
OBJETIVO Preparar una propuesta de una página para un cliente que ya conoce el producto. MATERIAL - notas de la reunión - necesidades confirmadas - restricciones comerciales NO HAGAS - inventar precios, fechas o capacidades - afirmar beneficios que no estén respaldados PROCESO 1. Resume necesidades confirmadas. 2. Señala huecos. 3. Propón estructura. 4. Redacta sólo cuando los huecos no sean críticos. FORMATO Problema | Propuesta | Alcance | Próximo paso QUALITY GATE Marca cualquier afirmación que requiera verificación.
Este formato no es “mágico”; simplemente hace visibles las piezas que una conversación informal suele esconder. Puedes recortarlo cuando la tarea sea sencilla y ampliarlo cuando haya riesgo.
5. Matriz de decisión
| Decisión | Qué mirar | Señal buena | Señal de riesgo |
|---|---|---|---|
| Prompt breve | Tarea simple y material claro | Una instrucción produce formato estable | Añades párrafos para compensar ambigüedad |
| Prompt estructurado | Tarea repetible o profesional | Entrada y salida son verificables | Reglas acumuladas se contradicen |
| Ejemplo few-shot | Estilo/formato difícil de describir | El modelo replica patrones deseados | El ejemplo contiene errores |
| Tool/RAG | Necesitas hechos externos | La fuente está conectada | Pides al prompt que “sepa” algo que no ve |
| Workflow multi-paso | Hay análisis y producción | Puedes revisar etapas | Un único prompt mezcla objetivos incompatibles |
6. Fallos y límites
Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:
- Usar “actúa como experto” como sustituto de contexto real.
- Pedir exactitud sin aportar fuente ni mecanismo de verificación.
- Incluir veinte adjetivos de estilo pero no explicar audiencia ni objetivo.
- Meter datos no confiables dentro de la zona de instrucciones.
- Pedir cadena de tareas incompatible en una sola salida.
- No probar el prompt con material incompleto o contradictorio.
- Copiar prompts virales que fueron diseñados para otra tarea.
- Cambiar modelo y prompt simultáneamente, impidiendo saber qué mejoró.
7. Cómo medirlo
No midas sólo si “parece bueno”. Define una señal observable antes de escalar.
| Métrica | Qué mide | Cómo observarla | Umbral/alerta |
|---|---|---|---|
| Cumplimiento de formato | Estructura correcta | Parser/checklist | Campos faltantes |
| Cobertura | Requisitos presentes | Rúbrica | Se omiten criterios críticos |
| Factualidad | No inventa datos | Verificación contra material | Afirmaciones sin respaldo |
| Consistencia | Mismo input, calidad estable | Repeticiones | Variación excesiva |
| Tiempo de edición | Trabajo humano posterior | Minutos por salida | No baja frente a manual |
| Tasa de preguntas | Detecta huecos | Preguntas útiles | Asume en vez de preguntar |
8. Checklist de producción
9. Ejercicios para convertir lectura en habilidad
- Reescribe un prompt tuyo usando OBJETIVO / MATERIAL / RESTRICCIONES / FORMATO / QUALITY GATE.
- Elimina la mitad de palabras de un prompt sin perder información necesaria.
- Crea un caso límite que obligue al modelo a preguntar.
- Convierte un email bien escrito en ejemplo few-shot y describe qué patrón enseña.
- Compara “hazlo mejor” con una rúbrica concreta de cinco criterios.
10. Qué estudiar después
No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.
Apéndice A · Preguntas que deberías poder responder
- ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
- ¿Qué dato o ejemplo cambiaría tu decisión actual?
- ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
- ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
- ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
- ¿Qué coste operativo aparece después del primer prototipo?
- ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?
Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.
Apéndice B · Cuatro escenarios para practicar la decisión
Pregunta:Tarea simple y material claro.Señal favorable:Una instrucción produce formato estable.Alerta:Añades párrafos para compensar ambigüedad.
Pregunta:Tarea repetible o profesional.Señal favorable:Entrada y salida son verificables.Alerta:Reglas acumuladas se contradicen.
Pregunta:Estilo/formato difícil de describir.Señal favorable:El modelo replica patrones deseados.Alerta:El ejemplo contiene errores.
Pregunta:Necesitas hechos externos.Señal favorable:La fuente está conectada.Alerta:Pides al prompt que “sepa” algo que no ve.
No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.
Apéndice C · Cuaderno de campo para tu propio caso
Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.
- Problema¿Qué trabajo concreto intentas mejorar y para quién?
- Baseline¿Cómo se hace hoy, cuánto tarda y qué errores aparecen?
- Datos¿Qué entra, de dónde viene, quién puede verlo y qué no debería salir del entorno?
- Salida¿Qué formato y criterios convierten el resultado en usable?
- Prueba¿Qué 20–50 casos representarían el trabajo real?
- Riesgo¿Cuál es el fallo más costoso y cómo se detecta?
- Operación¿Quién observa, corrige, actualiza y puede detener el sistema?
- Revisión¿Qué evento o fecha obligará a reevaluar esta decisión?
Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.
Apéndice D · De prototipo a producción
Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.
Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.
- Define un SLO de calidad y uno operativo.
- Registra versión de modelo, prompt, fuentes y configuración.
- Mantén una muestra estable para detectar regresiones.
- Añade un fallback para proveedor, herramienta o dato ausente.
- Decide qué errores se reintentan y cuáles se escalan.
- Presupuesta revisión humana, no sólo tokens.
- Evita permisos permanentes que sólo necesitabas para una prueba.
- Programa una revisión tras cambios de modelo, precio, política o dataset.
Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.
Prompting como especificación, no como conjuro
Un prompt profesional se parece más a un briefing o una interfaz que a una frase ingeniosa. Debe aclarar qué transformación se espera, con qué material, qué restricciones son obligatorias y cómo reconocer el resultado correcto. El objetivo no es escribir mucho: es reducir ambigüedad. Cuando la tarea es sencilla, una instrucción corta y concreta puede superar a una plantilla de treinta líneas.
Los ejemplos son especialmente valiosos cuando el formato o la frontera de una categoría es difícil de describir. Un buen few-shot no enseña sólo “qué responder”, también muestra excepciones: un caso que debe clasificarse como A, otro como B y uno que debe devolverse como incierto. Esa variedad reduce el riesgo de que el modelo imite superficialmente un patrón demasiado estrecho.
Para información larga, separa claramente datos e instrucciones. No permitas que texto recuperado, correos o páginas web se mezclen semánticamente con las reglas del sistema. Una fuente externa es dato potencialmente no confiable; puede contener instrucciones accidentales o maliciosas. El diseño del prompt debe mantener una jerarquía de autoridad y una política explícita para ignorar instrucciones que llegan dentro del contenido.
Cuando una salida vaya a ser consumida por software, evita confiar en frases libres si existe un contrato estructurado. JSON con schema, enumeraciones y campos obligatorios reducen errores de integración y permiten validar antes de ejecutar. El modelo puede proponer; el validador decide si la estructura cumple. Esta combinación suele ser más robusta que pedir “responde exactamente con este formato” y esperar que nunca falle.
No optimices prompts por intuición infinita. Guarda un pequeño conjunto de casos representativos, ejecuta variantes y mide. Si una nueva instrucción mejora tres ejemplos pero rompe diez casos frecuentes, no es una mejora. El prompting madura cuando deja de depender de recuerdos de conversaciones y entra en un ciclo de evaluación reproducible.
Una escala de madurez para prompting como especificación, no como conjuro
Resuelve un caso real de principio a fin. Conserva entrada, salida y correcciones. Aquí buscas descubrir fallos, no automatizar.
La entrada y la salida ya tienen contrato, existen ejemplos límite y puedes medir calidad, tiempo y coste con el mismo criterio.
Hay observabilidad, permisos, fallback, responsable, revisión de cambios y un mecanismo para detectar regresiones antes de afectar al usuario.
La transición entre niveles debe estar motivada por evidencia. No pases a integración o autonomía sólo porque una demo salió bien. Pasa cuando hayas repetido la tarea con casos representativos, sepas dónde falla y el ahorro neto siga siendo positivo después de incluir revisión y operación.
Para los primeros 30 días, reúne ejemplos y construye el baseline. Entre 30 y 60 días, estabiliza el contrato de entrada/salida y convierte los fallos recurrentes en tests, checklist o reglas. Entre 60 y 90 días, si el volumen lo justifica, añade automatización, monitorización y revisión de costes. Si una etapa no supera sus propios criterios, mantén el sistema en la etapa anterior.
Documenta también las condiciones de salida: qué cambio de proveedor, política, precio, modelo, volumen o riesgo obligaría a reevaluar el diseño. Una arquitectura madura no pretende ser definitiva; hace explícito cuándo deja de ser válida.
Antes de considerar el trabajo terminado, realiza una revisión adversarial: busca deliberadamente entradas ambiguas, datos faltantes, instrucciones contradictorias, límites de cuota y resultados que parezcan correctos pero no puedan verificarse. El objetivo no es demostrar que el sistema funciona, sino descubrir bajo qué condiciones deja de funcionar y comprobar que esos fallos tienen una respuesta segura. Registra cada hallazgo y conviértelo en una prueba futura.
- Guarda al menos 20 casos reales, incluidos fallos.
- Define un criterio de aprobación que otra persona pueda aplicar.
- Separa métricas de calidad, coste y operación.
- Establece quién puede detener o revertir el sistema.
- Programa una fecha de revisión aunque nada parezca haber cambiado.
Documentación que sostiene y actualiza esta guía
Las capacidades y políticas cambian. Usa estas referencias para comprobar los puntos que dependan de un proveedor o de una versión concreta.