Automatización de ecommerce con IA y criterios de revisión

Automatiza la entrega, no solo el prompt

Un flujo de contenido repetible debe responder qué producto cambió, qué revisión de origen se usó, qué trabajo queda y quién puede publicarlo. Un prompt programado con un CSV adjunto no puede responder esas preguntas por sí solo. Trata el prompt como un paso de un trabajo cuyo estado se almacena fuera de la conversación.

Empieza con contenido exportable y una cola de revisión offline. Da a cada trabajo un registro duradero y una acción siguiente explícita. Mantén desactivadas las actualizaciones de productos en vivo hasta ejercitar el adaptador de destino y las comprobaciones de aprobación en una tienda controlada. Así puedes construir la generación y la revisión antes de añadir permisos de publicación.

Da a cada trabajo una identidad estable

Usa la revisión de origen, el identificador del producto, el locale, la revisión del glosario y la revisión del prompt para identificar el trabajo previsto. Un reintento del mismo trabajo no debe crear un candidato no relacionado ni aplicar dos veces la misma importación. Un cambio en el origen o en las reglas debe crear trabajo nuevo con una relación visible con el candidato anterior.

No identifiques los trabajos por número de fila: ordenar una exportación cambia las posiciones. Mantén los precios y las unidades en la instantánea de origen, pero permite que la salida generada solo cubra campos de texto aprobados. El registro siguiente es un contrato ilustrativo de aplicación que debes adaptar a tu almacén de trabajos.

{
  "productId": "SYNTHETIC-CATALOG-A",
  "locale": "de",
  "sourceRevision": "source-revision-required",
  "glossaryRevision": "glossary-revision-required",
  "promptRevision": "prompt-revision-required",
  "state": "queued",
  "approval": null,
  "importReceipt": null
}

Persiste las transiciones de estado observables

Guarda la salida candidata antes de avanzar a la validación. Guarda los problemas de validación antes de asignar un revisor. Vincula la aprobación a las revisiones exactas del candidato y del origen. El publicador debe rechazar los registros cuyo contenido haya cambiado después de la aprobación, aunque se hubiera aceptado una versión anterior.

Usa un estado retenido para los resultados ambiguos. Por ejemplo, una pérdida de conexión durante una importación no demuestra que la tienda rechazara la escritura. Lee y concilia los campos almacenados actuales antes de reintentar. Implementa los estados propuestos de abajo en tu capa de orquestación, con comprobaciones de transición junto a la operación que persiste cada resultado.

Separa el cliente del modelo del adaptador de tienda

Da al trabajador de redacción solo el subconjunto de origen aprobado y las credenciales del modelo. Coloca las credenciales de la tienda en un adaptador separado con una operación limitada, como preparar un parche de descripción. Una solicitud de IA que termine correctamente no debería poder publicar un producto como efecto secundario.

La ruta de traducción documentada de Shopify usa contenido y digests específicos del recurso; WooCommerce documenta un importador de productos CSV. Da a cada interfaz su propio mapeador y paso de verificación. Configura las credenciales del modelo en el cliente de redacción y mantén las lecturas de origen y las escrituras autorizadas de tienda en el adaptador de destino. Prueba estos límites por separado antes de unir el flujo.

Limita los reintentos y aísla los registros defectuosos

Reintenta los fallos temporales de transporte con una política finita y registra los intentos. Repetir una respuesta estructuralmente inválida sin cambiar la causa puede desperdiciar tanto uso como tiempo del revisor. Mantén separadas las categorías de fallo: autenticación, modelo no disponible, generación incompleta, campos inválidos y contenido rechazado necesitan intervenciones diferentes.

Permite que los registros correctos sigan disponibles mientras retienes los fallidos. Conserva todos los intentos del producto afectado, incluidos los candidatos que no superaron la validación. Un reinicio del trabajador debe reanudar desde el estado persistido, no regenerar todo el catálogo. Prueba también la cancelación: detener la generación no debe dejar un proceso de importación ejecutándose en silencio.

Mide el trabajo aceptado y su coste completo

Asocia los registros de uso al trabajo y al intento, incluidas las solicitudes fallidas cuando exista evidencia de facturación. Sigue por separado las llamadas de redacción, revisión y revisión posterior. Conserva el uso ausente como desconocido; un recibo ausente no convierte una solicitud en gratuita. Mantén separado el tiempo del editor del registro de API en lugar de mezclar mediciones diferentes en una sola cifra.

Define el trabajo aceptado según tus criterios de publicación, como una revisión de producto-locale aprobada. Divide los costes registrados por el trabajo aceptado solo cuando el denominador no sea cero y la muestra esté claramente acotada. Usa la información de facturación actual del proveedor o gateway y conserva la fecha y la fuente de facturación junto al informe.

Concilia las importaciones y prepara la reversión

Crea una propuesta de importación que contenga solo cambios aprobados y guarda los valores anteriores de esos campos. Vuelve a comparar la revisión de origen inmediatamente antes de una escritura autorizada. Si otro editor ha cambiado el producto, pausa y solicita una nueva revisión en lugar de sobrescribir su trabajo.

Después de importar, vuelve a leer los campos previstos y clasifica las discrepancias por producto y locale. Una reversión debe restaurar solo los cambios de este lote cuando la tienda todavía coincida con la revisión importada; de lo contrario necesita una revisión de conflicto. Mantén los permisos de importación independientes del permiso para generar texto.

Verifica un flujo pequeño que incluya fallos

Usa productos sintéticos para probar un candidato aceptado, una infracción de campo protegido y un conflicto de origen cambiado. Reinicia el trabajador entre la redacción y la aprobación. Comprueba que el trabajo aprobado sobreviva y que el trabajo retenido no pueda entrar en una propuesta de importación. Estas comprobaciones ejercitan el contrato de estado de forma más directa que probar repetidamente la redacción del prompt.

Después prueba el adaptador en una tienda de staging con permiso explícito. Conserva la instantánea de origen, la revisión generada, la aprobación, el recibo de importación y la comparación de lectura posterior. Una simulación local del trabajo demuestra únicamente el comportamiento de la orquestación; no demuestra la calidad del modelo ni una integración correcta con la tienda.

Preguntas frecuentes