¿Cuál es el problema de verdad?
No es que no haya dónde guardarlos. Es que un buen prompt nace una vez y luego se pierde.
Alguien dedica media hora a montar una instrucción que da exactamente la carta de presupuesto que hace falta. Dos semanas después ya no se acuerda de cuál era la versión buena. Su compañero ni sabe que existe y escribe la suya, peor. Medio año más tarde tres personas usan tres prompts distintos para lo mismo, y nadie sabe cuál es el mejor.
No construyas una herramienta
La primera idea siempre es una interfaz aparte o un software dedicado. No lo hagas — está condenado, porque hay que ir allí, y nadie va.
La biblioteca de prompts va donde el equipo ya trabaja: la unidad compartida, el wiki, la app de notas, el gestor de proyectos. Una hoja de cálculo o unos cuantos documentos bastan de sobra hasta los primeros cien prompts.
La pregunta no es cuál es la solución más bonita, sino dónde van a mirar de verdad.
¿Qué debe contener una entrada?
Seis campos. Menos es poco, más no se rellenará.
- Nombre — para qué sirve, en lenguaje humano. «Carta de presentación de presupuesto para pyme», no «prompt_v3_final».
- Cuándo usarlo — una frase. Es lo que impide que lo saquen para la situación equivocada.
- El prompt — exactamente como hay que pegarlo, con los marcadores incluidos:
[nombre del cliente],[texto de la carta]. - Un ejemplo — una entrada real y la salida buena que le correspondió. Es el campo más valioso: es lo que le muestra al siguiente qué puede esperar.
- Responsable — un nombre. Alguien a quien avisar cuando deje de funcionar.
- Última revisión — una fecha. De esto, más en un momento.
La fecha sin la cual todo envejece
Un prompt no es para siempre. Cuando el proveedor actualiza o retira el modelo, los prompts ajustados a él se comportarán de otra manera — y eso no es un riesgo teórico sino un hecho periódico.
El síntoma es traicionero: nada falla, la salida solo sale un poco distinta. Más larga. Con otro formato. Le falta un campo. Nadie lo nota en meses, porque cada uno supone que solo ese caso fue raro.
Por eso hace falta la fecha de «última revisión», y por eso conviene guardar también el ejemplo: si la salida de hoy difiere de forma apreciable de la guardada, sabes que algo ha cambiado.
Si tienes un conjunto de pruebas de veinte tareas — de eso trata Cómo leer un benchmark de IA —, ese mismo conjunto sirve para mantener la biblioteca de prompts. Al cambiar de modelo lo pasas, y en media hora sabes qué se ha roto.
¿Cómo nombrarlos?
Por tarea, no por tecnología. La gente busca lo que quiere hacer.
Bien: Reclamación de cliente — borrador de respuesta, Acta — destacar las decisiones, Extraer datos de factura de una foto.
Mal: Prompt GPT 4, Marketing v2, Prompt probado.
Si acaban siendo muchos, que la agrupación también vaya por puesto — ventas, atención al cliente, finanzas —, no por modelo o técnica.
Empieza con cinco
El error más común es sentarse a recopilar cincuenta prompts de golpe. El resultado es una lista larga de la que se usan diez, y el resto hace ruido.
Empieza por las cinco tareas que de verdad hacéis todas las semanas. Si funcionan y se usan de verdad, la cosa crece sola. Si no se usan, cincuenta tampoco habrían servido.
En cuanto a escribir los prompts, para eso está el meta-prompting : también puedes hacer que el modelo los monte, si la formulación se te atraganta.
¿Qué va en el system prompt en su lugar?
Lo que es igual en todas las tareas — el nombre de la empresa y cómo se escribe, el tono, los temas vetados — no va en la biblioteca sino en el system prompt. Allí lo configuras una vez y no hace falta copiarlo en cada entrada.
Una señal práctica: si el mismo párrafo aparece en tres entradas, entonces en realidad es marco, no tarea.
Dos cosas que conviene prohibir
Datos de clientes en los ejemplos. El ejemplo guardado es útil, pero no con nombre y cifra reales. Entra una vez, luego se queda ahí, y la biblioteca la ve mucha gente.
Una clave o contraseña en el prompt. Parece obvio, y aun así pasa, cuando alguien pega una llamada a una API como plantilla.
Qué llevarte
Cinco entradas donde el equipo ya trabaja, cada una con un ejemplo, un responsable y una fecha. Este sistema no es bonito, pero funciona — y el mantenimiento depende de que alguien los vuelva a pasar cuando cambie el modelo.