Cómo probar flujos de trabajo de IA de WordPress en staging o Playground

Pruebe un flujo de trabajo de IA de WordPress en un entorno de navegador desechable, un sitio local o un sitio de staging antes de producción. El entorno debe contener contenido sintético o saneado, el artefacto exacto del plugin en prueba, identidades separadas y fixtures de aceptación conocidos.

Una buena prueba demuestra recuperación, acción prevista, acción denegada, reversión y revocación. También registra las versiones para que el resultado pueda reproducirse.

En una frase: un laboratorio seguro hace predecibles tanto el éxito como el fracaso antes de que el flujo de trabajo pueda afectar a usuarios reales.

Lo que esta guía le ayuda a lograr

Esta guía define un laboratorio de pruebas reutilizable para escenarios de contenido, SEO y conexión. Ayuda a Codex a crear capturas de pantalla y vídeos reales sin fabricar interfaces de producto ni exponer datos de clientes.

Un flujo de trabajo de IA útil no se define solo por la calidad de la respuesta. También se define por los datos a los que el asistente puede acceder, las acciones que tiene permitido realizar, las pruebas que puede inspeccionar después y la facilidad con la que se puede retirar el acceso.

Por qué importa

Los sistemas de producción contienen datos cambiantes, credenciales activas y consecuencias empresariales. Son malos lugares para aprender cómo gestiona un conector la paginación, los fallos o llamadas de herramientas inesperadas. Un entorno desechable da al equipo control sobre el resultado esperado.

WordPress Playground puede ejecutar WordPress en un navegador y resulta útil para demostraciones y experimentos aislados, aunque no todos los flujos de red externa o de licencias se comportarán exactamente igual que en producción. Los entornos locales y de staging siguen siendo necesarios para algunas pruebas.

Resultado esperado

Una ejecución satisfactoria debe producir:

• Un fixture de WordPress repetible con contenido sintético.
• Versiones instaladas del plugin y del conector.
• Identidades definidas y capacidades esperadas.
• Casos de prueba permitidos, denegados, de reversión y de revocación.
• Capturas y registros saneados adecuados para documentación.

Elija el entorno

Use Playground para demostraciones rápidas en el navegador y ejemplos autocontenidos. Use WordPress local cuando se requiera control del sistema de archivos, CLI o paquetes. Use staging cuando la pila de alojamiento, los plugins o la autenticación deban parecerse a producción. Nunca suponga que un entorno demuestra todos los demás.

Cree fixtures deterministas

Agregue entradas, páginas, categorías y borradores conocidos con ID estables o títulos identificables. Incluya un objetivo permitido y uno prohibido. Use nombres falsos, dominios falsos y ningún dato de cliente.

Pruebe todo el ciclo de vida

Pruebe la instalación, conexión, descubrimiento, una tarea útil, un rechazo, cierre de sesión o eliminación de credenciales, desactivación del plugin y recuperación. Para pruebas de escritura, conserve una instantánea o revisión y confirme la reversión.

Capture pruebas de forma segura

Las capturas de pantalla deben provenir del plugin distribuido real y de la interfaz de cliente real. Sanee URL, nombres de usuario, estado de licencia y credenciales. Las ilustraciones generadas pueden explicar conceptos, pero nunca deben sustituir las pruebas de ejecución.

Un flujo de trabajo seguro

1. Elija Playground, local o staging según la superficie requerida.
2. Instale el artefacto exacto del plugin distribuido.
3. Cree contenido sintético y resultados esperados conocidos.
4. Cree identidades dedicadas para los modos probados.
5. Configure el conector con credenciales temporales.
6. Ejecute pruebas de éxito, rechazo, reversión y revocación.
7. Capture pruebas saneadas y metadatos de versión.
8. Destruya o restablezca el entorno después de la prueba.

Receta de prompt

Antes de copiar este prompt, sustituya todos los valores entre corchetes. No pegue credenciales, datos de clientes ni información privada en la instrucción.

Ejecute la siguiente prueba de aceptación de IA de WordPress en el entorno designado que no es de producción.

Fixture:
- Registro esperado legible: [ID/title]
- Acción prohibida esperada: [action]
- Objetivo de borrador esperado: [ID/title or none]

Secuencia de prueba:
1. Confirme las versiones del entorno y del plugin.
2. Recupere el registro esperado legible.
3. Intente la acción prohibida y capture el rechazo.
4. Si una escritura está dentro del alcance, cree solo el borrador aprobado e informe su ID y estado.
5. Revoque la credencial.
6. Repita la lectura inocua y confirme que ahora falla la autenticación.
7. Devuelva un manifiesto de pruebas conciso. No exponga secretos.

Por qué el prompt está estructurado así

El prompt convierte la demostración en una prueba de aceptación con fixtures predefinidos. También exige prueba de revocación y un manifiesto de pruebas en lugar de una afirmación narrativa.

Límite de acceso recomendado

Use una identidad Read Only. El asistente puede inspeccionar los datos de WordPress incluidos en su alcance, pero debe rechazarse cualquier intento de crear, editar, eliminar o publicar contenido.

Bajo no significa cero. Revise el alcance de entrada y asegúrese de que la salida no contenga información privada ni irrelevante.

El nivel de acceso es una recomendación inicial, no una autorización universal. Las capacidades exactas de WordPress disponibles para una identidad deben proceder de la versión del producto instalada y de su cobertura publicada, no de este artículo por sí solo.

Lo que debe permanecer fuera de la tarea

• Ningún dato de cliente o de producción en los fixtures.
• Ninguna captura de pantalla generada presentada como prueba.
• Ninguna prueba ni activación de licencia contra una cuenta real sin autorización.
• Ninguna suposición de que Playground reproduce todos los comportamientos de alojamiento o red.

Cómo encaja WP Agent Control

Obtén información estructurada del sitio e inspecciona páginas publicadas seleccionadas después de conectar. Esta lectura pública no requiere una tarea temporal. También puedes navegar por páginas públicas sin el plugin; Agent Control añade acceso estructurado y continuidad hacia operaciones autorizadas en WordPress.

Autoriza una tarea de borrador y selecciona las referencias necesarias. El asistente puede crear y revisar borradores creados por esa tarea. Las referencias existentes siguen siendo de solo lectura, aunque también sean borradores. Revisa el resultado en WordPress.

Con Solo, Pro o Agency, autoriza una tarea de propuesta para contenidos y campos seleccionados. Examina la comparación completa en WordPress y selecciona las propuestas que apruebas. La aprobación queda vinculada al objeto, sus campos y contenido actual; un cambio en la fuente o tarea puede invalidarla. Aprobar un cambio de contenido no autoriza su publicación. Solo, Pro o Agency también necesita una tarea de publicación que cubra la aprobación aún válida. Comprueba personalmente el resultado publicado.

Conectar tu IA: docs first profile · Ver funciones y compatibilidad: coverage

Lista de verificación

• ☐ Se utiliza el artefacto distribuido exacto.
• ☐ Los fixtures son sintéticos y deterministas.
• ☐ Los resultados de éxito y rechazo coinciden con las expectativas.
• ☐ Las operaciones de escritura son reversibles.
• ☐ Las credenciales son temporales y están revocadas.
• ☐ Las capturas y registros están saneados.

Modos de fallo comunes

• Usar una rama de desarrollo como prueba: el sitio público afirma un comportamiento no vinculado al artefacto comercial.
• Probar solo el camino feliz: se desconocen los límites de permisos y revocación.
• Usar datos de producción: el trabajo de documentación crea riesgos de privacidad y operativos.
• Tratar un entorno como universal: se ignoran las diferencias de alojamiento, red o licencias.

Nota avanzada

Almacene los escenarios de prueba como datos con la versión del fixture, hash del artefacto, entorno, cliente, conector, modo de identidad, herramientas esperadas, salidas esperadas y rutas de pruebas. Un futuro trabajo de CI puede volver a ejecutar escenarios no sensibles y señalar desviaciones de compatibilidad sin publicar automáticamente.

Guías relacionadas

• La forma más segura de empezar a usar IA en WordPress
• Cómo conectar Claude Code a WordPress
• Cómo conectar Codex a WordPress
• Cómo revocar el acceso de un asistente de IA a WordPress

Continuar

Siguiente paso: use ¿Qué nivel de acceso de WordPress debe dar a una IA? para convertir este principio en un perfil concreto de acceso a WordPress. Pruebe el flujo de trabajo antes de considerar un permiso más amplio.