Nuestro flujo de contenido con IA funciona con GPT-6 Sol y genera menos imágenes que antes
Actualizado el 24 de septiembre de 2026: esta publicación describía originalmente el flujo con GPT-5.6. Ahora funciona con GPT-6 Sol, con la traducción en GPT-6 Luna, y los nombres de los modelos y el código que aparecen a continuación reflejan ese cambio.
Todos los prompts de generación de contenido del flujo de Green Yoga Inc usan ahora GPT-6 Sol. Esa parte consiste en cambiar una línea por archivo. Lo que merece la pena contar es qué pasó con la generación de imágenes, que hemos eliminado por completo del flujo.
Dónde se elige realmente el modelo
Los prompts están en ai-prompts/ como archivos de texto sin formato con una cabecera, nunca como cadenas literales en el código fuente de Lambda. Actualmente hay 23, además de un manifiesto JSON para lotes puntuales de imágenes. Dieciséis incluyen MODEL: gpt-6-sol.
Los demás no lo incluyen, a propósito:
21-content-translation.txtfunciona congpt-6-luna, el modelo más pequeño de GPT-6. Traduce el sitio a ocho idiomas y es la tarea en la que el volumen importa más que el último incremento de calidad.- Los tres archivos de prompts
gptimage-*que Lambda todavía lee no tienen ninguna cabeceraMODEL:, porque Lambda ya no envía nada a OpenAI con ellos. Más detalles a continuación. - Los tres restantes son dos fragmentos de contexto que se insertan en otros prompts y un prompt de imagen a vídeo que utiliza otro proveedor.
Ambas Lambdas —ai-content-engine y yoga-script— resuelven lo que indique la cabecera mediante normalizeModel():
function normalizeModel(raw?: string): string {
if (!raw) return "gpt-6-sol";
// Legacy GPT-5.x ids -> current model
if (m === "gpt-5" || m === "gpt-5.1" || ... || m === "gpt-5.6" || m === "gpt-image-1.5") {
return "gpt-6-sol";
}
if (m === "gpt-4o" || m === "gpt4o") return "gpt-4o";
return m;
}
Cualquier identificador antiguo —de gpt-5 a gpt-5.6, así como el antiguo gpt-image-1.5— se convierte en gpt-6-sol. Un archivo de prompts que nadie haya tocado en seis meses no puede invocar un modelo retirado: se le asigna silenciosamente el actual. gpt-4o y gpt-4o-mini se mantienen sin cambios, porque una ruta de código todavía necesita gpt-4o de forma deliberada.
Ambas Lambdas se comunican mediante Chat Completions
La generación de texto utiliza POST /v1/chat/completions desde ambas Lambdas. Si leíste nuestra publicación de abril, esto supone un cambio de rumbo: nos habíamos pasado a la API Responses. Hemos vuelto atrás. Chat Completions es la opción sencilla y conocida para lo que hacen realmente estas dos funciones: recibir un prompt de sistema y un prompt de usuario y devolver texto.
Lo único que sigue usando POST /v1/responses son los scripts de desarrollo que se ejecutan manualmente desde una estación de trabajo. scripts/generate-pose-images.mjs utiliza la herramienta image_generation con gpt-6-sol a 1024x1024, y dos scripts puntuales para imágenes hacen lo mismo a 1536x1024. Son trabajos por lotes locales, no tráfico del navegador, y llaman directamente a OpenAI a propósito.
El Constructor de secuencias de yoga gestiona su propio tiempo
El Constructor de secuencias de yoga genera guiones para la enseñanza mediante la Lambda yoga-script, que utiliza 05-yoga-script-generator.txt con GPT-6 Sol. La generación de guiones es lenta y variable, así que la Lambda dedica la mayor parte de su lógica a los cálculos, no a los prompts:
- un único intento principal tiene un límite de siete minutos, para que una llamada lenta no consuma toda la ejecución
- se reservan 25 segundos al final para serializar y devolver una respuesta
- existe una alternativa con
gpt-4o, pero solo se ejecuta si quedan al menos dos minutos de margen
Esta última regla es la importante. Si el intento principal falla cuando queda poco tiempo y no hay margen suficiente, la Lambda se niega a iniciar la alternativa y devuelve un error explícito: Skipping gpt-4o fallback: insufficient Lambda time remaining. Iniciar una llamada que no puedes terminar solo convierte un error claro en un tiempo de espera agotado, lo que es mucho peor a la hora de depurar.
Hemos dejado de generar imágenes automáticamente
Este es el cambio real desde abril.
generateImage() en ai-content-engine es ahora un esqueleto que no hace nada. Recibe los argumentos, los ignora y devuelve la imagen de portada alternativa:
/** Kept as a no-op stub for callers that still reference it directly. */
async function generateImage(imagePrompt: string, s3Key: string): Promise<string> {
void imagePrompt;
void s3Key;
return FALLBACK_COVER_IMAGE;
}
Lo que lo ha sustituido no es otro modelo, sino una persona. generateOrReuseImage() escribe el prompt de imagen en DynamoDB con una clave S3 vacía y devuelve la imagen de portada alternativa; el correo de aprobación envía ese prompt a una persona. Cuando llega la respuesta con una imagen adjunta, otra Lambda, media-receiver, incorpora el recurso definitivo.
El prompt se guarda en tres campos separados —clipL, t5xxl y negative— en lugar de en un único bloque, porque quien lo renderiza generalmente no utiliza OpenAI. Son campos para prompts de modelos de difusión, y mantenerlos separados permite al operador pegar cada uno en el campo adecuado en lugar de tener que deshacer una cadena concatenada.
Por qué un flujo más lento es el flujo adecuado
La generación automática de portadas era la función con más probabilidades de publicar algo embarazoso en el sitio sin que nadie lo viera antes. El texto ya pasa por un correo de aprobación. Las imágenes no: se generaban, se subían y se publicaban en un único proceso sin supervisión.
Eliminar esa función sí ha ralentizado las publicaciones. También significa que una persona ha revisado todas las imágenes de este sitio antes de que se publicaran, que es justo lo que queríamos. El modelo ha mejorado y le hemos dado menos tareas que hacer sin supervisión. No son cosas incompatibles.
Los prompts están en ai-prompts/; las Lambdas, en lambda/ai-content-engine y lambda/yoga-script. Si quieres ayuda para diseñar un flujo de aprobación para tu propio flujo de contenido con IA, ponte en contacto.
