Hablarle bien a una IA: el prompt como especificación

Hay una industria entera vendiendo «prompts mágicos»: listas de fórmulas que supuestamente desbloquean respuestas superiores. Casi todo eso es humo, y envejece en semanas.

Lo que sí funciona es más aburrido y no caduca: tratar el prompt como una especificación de trabajo. No le estás hablando a un oráculo. Le estás encargando una tarea a alguien competente, rápido y sin contexto, que no va a preguntarte nada si algo no queda claro — se lo inventará.

Esa última parte es la clave. Un becario que no entiende el encargo te pregunta. El modelo no. Rellena el hueco con lo más probable y sigue adelante con total seguridad.

Las cuatro cosas que sí cambian el resultado

1. El contexto. Lo que sabe del problema. No «escribe un email a un cliente», sino qué cliente, qué pasó antes, en qué tono os habláis, qué quieres conseguir. La mayoría de respuestas genéricas son respuestas a preguntas genéricas.

2. La tarea concreta. Un verbo y un resultado. «Extrae», «reescribe», «clasifica», «compara». Si tu instrucción contiene tres tareas encadenadas, sepáralas: los encargos compuestos salen peor que los mismos pasos hechos por separado.

3. El formato de salida. Esto es lo que más rendimiento da y lo que casi nadie hace. Si vas a leer tú la respuesta, da igual. Si la va a leer un sistema, tienes que fijar la forma: qué campos, en qué orden, qué pasa si un dato no está. Un modelo al que le pides «los datos de la factura» te devuelve un párrafo distinto cada vez. Uno al que le pides tres campos concretos, uno por línea, y `null` cuando falte, te devuelve algo con lo que se puede trabajar.

4. Los ejemplos. Uno o dos ejemplos de entrada y salida correcta valen más que tres párrafos explicando el criterio. Es la forma más eficiente de transmitir un matiz que no sabes verbalizar.

El truco real: pedirle que piense antes de responder

Los modelos aciertan más cuando se les deja razonar antes de dar el resultado. Si le pides directamente la conclusión, la genera de golpe y con ella se arrastran los errores. Si le pides que exponga primero el razonamiento y después concluya, cada paso condiciona al siguiente y el resultado mejora — sobre todo en tareas con varios pasos.

En la práctica, para un sistema, esto tiene un coste: el razonamiento ocupa tokens y no te sirve para nada. La solución habitual es pedirle que razone y después entregue el resultado final claramente separado, y que tu sistema se quede solo con esa última parte.

Lo que hay que dejar de hacer

Dejar de ser educado por costumbre. «Por favor», «eres un experto de talla mundial», «tómate tu tiempo». No hacen daño, pero ocupan contexto y no aportan. Escribe como escribirías un encargo por escrito a alguien a quien no vas a poder aclarar nada después.

Dejar de pedir «lo mejor». «Dame el mejor titular» no significa nada operativo. «Dame cinco titulares de menos de 60 caracteres, sin signos de exclamación, que mencionen el problema y no la solución» sí.

Dejar de aceptar la primera respuesta. La primera versión de un modelo es un borrador. Decirle qué falla y pedirle que lo corrija es más eficaz que reescribir el prompt desde cero.

Dejar de confiar en lo que suena bien. Un texto fluido y seguro puede estar completamente equivocado. La fluidez no es señal de veracidad — es exactamente lo que el modelo optimiza.

Cuándo dejar de pelear con el prompt

Hay tareas que no se arreglan escribiendo mejor. Si el modelo necesita un dato que no tiene, no hay prompt que lo salve: hay que dárselo. Si necesita hacer un cálculo exacto, dale una calculadora. Si necesita consultar la documentación de tu cliente, hay que conectarla.

Saber cuándo el problema es de instrucción y cuándo es de arquitectura te ahorra tardes enteras. Como regla: si has reescrito la instrucción cuatro veces y sigue fallando en lo mismo, el problema ya no es la instrucción.

El prompt de sistema

Cuando montes asistentes y automatizaciones, vas a separar dos cosas: la instrucción fija —quién es, qué hace, qué no hace nunca, en qué formato responde— y la entrada variable de cada ejecución.

Esa instrucción fija es tu producto real. Es lo que vas a versionar, probar y mejorar. Trátala como código: guárdala en algún sitio donde puedas ver qué cambiaste y cuándo, porque el día que un sistema en producción empiece a comportarse raro, la primera pregunta será qué tocaste.