Convertir la retroalimentación en requisitos

El equipo de marketing de una distribuidora de insumos industriales usa Claude para redactar las descripciones del catálogo online. Marketing está conforme: salen rápido y se leen bien. El equipo de e-commerce, que las publica, devuelve muchas. Dicen que faltan especificaciones obligatorias, como la carga máxima y los materiales, y que el tono entusiasta de consumo masivo no les sirve a los gerentes de compras que usan el catálogo.

¿Quién tiene razón? El que usa la salida.

Quién juzga la salida

La primera lección del dominio ya planteó que la retroalimentación (feedback) más útil viene de quien recibe el resultado. Esta es sobre cómo convertirla en cambios concretos.

Que quien escribe el prompt esté conforme no dice nada sobre si la salida sirve. Marketing mide “se lee bien”; e-commerce mide “se puede publicar”. La segunda es la que importa, porque si no se publica, el trabajo no sirvió.

De la queja al requisito

“No nos sirven” no se puede poner en un prompt. Hay que traducirlo en requisitos (requirements) que Claude pueda cumplir:

1. Pedí ejemplos aceptados y rechazados (accepted and rejected examples). Diez descripciones que e-commerce publicó tal cual y diez que devolvió, con el motivo.
2. Buscá el patrón. ¿Qué tienen las aceptadas que les falta a las rechazadas? Podés pedirle ayuda a Claude para compararlas, pero la conclusión la valida e-commerce.
3. Escribilo como instrucción concreta. No “más técnico”, sino: “incluí siempre carga máxima, material y dimensiones; si falta alguno en la ficha, marcalo como FALTA en lugar de inventarlo; tono informativo para compradores profesionales, sin exclamaciones”.
4. Convertilo en criterios de aceptación (acceptance criteria): la lista con la que se va a decidir si una descripción sirve. Es la misma lista con la que vas a medir el cambio.

Lo que dice la queja	Requisito que va al prompt
“Muy largas”	“Máximo 80 palabras, primero el uso principal”
“No sirve para compradores”	“Público: gerentes de compras; tono informativo”
“Faltan datos”	“Siempre carga, material y medidas; si falta, marcarlo”
“Inventa cosas”	“Usá solo los datos de la ficha que te paso”

Probar en chico, con quien se quejó

Antes de rehacer 150 descripciones prioritarias, probá el prompt ajustado en una tanda de prueba (test batch) de diez o quince, y revisala con e-commerce. Si aprueban, avanzás; si no, ajustás de nuevo. Cambiá una cosa por vez para saber qué funcionó.

Seguir midiendo

La retroalimentación no es un evento, es un circuito. Después de implementar:

• llevá la cuenta de cuántas salidas se aceptan sin cambios;
• cada rechazo nuevo, con su motivo, es un caso para sumar al grupo de prueba;
• si la tasa de rechazo vuelve a subir, revisá qué cambió (los productos, el público, el prompt).

Las trampas típicas

• Dejar el prompt como está porque quien lo escribe está conforme.
• Cambiar prompt, modelo y plantilla de una vez para “arreglar todo en una vuelta”.
• Pedirle a Claude que se ponga nota del 1 al 10 y mandar solo las de 9: es la misma herramienta juzgándose.
• Traducir la queja en un adjetivo (“más profesional”) en lugar de un requisito.
• Aplicar el cambio a todo el catálogo sin probarlo en una tanda chica.

En el examen

Si el escenario muestra que los destinatarios rechazan la salida, buscá la opción que junta ejemplos de lo que aceptan y rechazan y los convierte en requisitos del prompt, y la que prueba el cambio en una tanda chica con ellos antes de escalar. En las de “elegí dos”, suelen ir juntas. Descartá la conformidad del autor, la autoevaluación de Claude y los cambios en bloque.