gpt-image-2.5-sunburst prompts: recetas de texto a imagen listas para copiar y pegar, orientadas a desarrolladores

La estructura de estas recetas de prompts

Cada receta de este artículo sigue la misma estructura de cinco campos. Una vez que veas el patrón, podrás leer cualquier prompt de aquí como si fuera la firma de una función: cada campo es una entrada con nombre y un rol claro; cambia uno y la salida cambiará de forma predecible.

• subject (sujeto): lo concreto que se representa. Mantenlo específico y único. "Una botella de cerámica mate" supera a "un producto", porque elimina de antemano toda una clase de decisiones que el modelo tendría que tomar.
• style (estilo): el lenguaje de renderizado: vector plano, render 3D suave, line art editorial, fotografía. Los términos de estilo se acumulan, así que normalmente dos bastan; con cinco empiezan a entrar en conflicto.
• composition (composición): dónde está el sujeto y qué espacio ocupa. Centrado con espacio en blanco, descentrado, en mosaico, a sangre. Este campo controla el diseño de forma más fiable que cualquier otro.
• lighting (iluminación): dirección, suavidad y contraste. "Luz direccional suave desde la parte superior izquierda" es una instrucción útil; "buena iluminación" no lo es.
• constraints (restricciones): las barandillas. Qué no debe aparecer, qué debe seguir siendo legible, qué rango de color se permite. Es el campo que más gente omite, y también el que hace que un prompt sea reutilizable.

Escrito como plantilla, se ve así:

{subject}, {style}, {composition}, {lighting}, {constraints}

El valor de esta estructura no está en la estética. Está en que cada campo se convierte en una variable que puedes rellenar por programa, comparar entre versiones y someter a pruebas de regresión entre llamadas. Una cadena de prompt desechable es un número mágico; una plantilla de cinco campos es un esquema.

Cuando escribas tus propias recetas, mantén estable el orden de los campos. En la práctica, el modelo presta más atención a los tokens iniciales, y un orden consistente hace que los cambios en la salida puedan atribuirse a la variable que realmente modificaste, y no a un prompt cuyo orden se ha alterado.

Montar un flujo de trabajo de recetas listas para copiar y pegar

Este flujo de trabajo se mantiene deliberadamente aburrido: plantilla, rellenar, llamar, almacenar. Lo aburrido es justo lo que hace que la generación de imágenes sea lo bastante reproducible como para llevarla a producción.

1. Guarda plantillas, no cadenas

Guarda cada receta como una plantilla con marcadores de posición con nombre. No pegues el prompt terminado directamente en el código de la llamada; de lo contrario, cuando quieras cambiarlo más adelante, tendrás que hacer arqueología para recuperarlo.

template = (
    "{subject}, {style}, {composition}, {lighting}, {constraints}"
)

def build_prompt(**kwargs):
    return template.format(**kwargs)

2. Rellena las variables desde un diccionario

Trata el conjunto de variables como datos. Así, la misma receta puede generar un lote de imágenes a partir de un archivo de configuración o de una fila de base de datos.

recipe = {
    "subject": "a single matte ceramic bottle with a minimalist label",
    "style": "clean product photography, soft 3D render",
    "composition": "centered, generous negative space on the right",
    "lighting": "soft directional light from upper left, gentle falloff",
    "constraints": "no text artifacts, no clutter, neutral background",
}

prompt = build_prompt(**recipe)

3. Llama al endpoint

Mediante la interfaz unificada de HiAPI.ai, envía el prompt ensamblado a gpt-image-2.5-sunburst/text-to-image. Coloca los parámetros de la solicitud (tamaño, formato, cantidad) en el mismo objeto de configuración que las variables, de modo que un solo registro describa una generación completa.

4. Registra la entrada completa, no solo la salida

Guarda de forma persistente el prompt rellenado, la versión de la receta y el conjunto de parámetros junto con cada imagen devuelta. Si tres semanas después la salida no parece correcta, el registro te dirá si lo que cambió fue el prompt o el modelo.

Este ciclo de cuatro pasos es todo el sistema. El resto del contenido de este artículo son solo recetas que se conectan a este sistema.

Receta 1: imagen principal de estilo producto

Esta es la receta principal para landing pages, cabeceras de documentación y tarjetas de tienda. Funciona porque el campo de composición se encarga del diseño y el campo de restricciones garantiza que quede espacio para los títulos.

Prompt

{subject}, clean product photography with soft 3D render finish,
centered subject with generous negative space on the right,
soft directional light from upper left with gentle falloff,
neutral seamless background, no text artifacts, no clutter, no harsh shadows

Un ejemplo rellenado:

a single matte ceramic bottle with a minimalist label, clean product
photography with soft 3D render finish, centered subject with generous
negative space on the right, soft directional light from upper left with
gentle falloff, neutral seamless background, no text artifacts, no
clutter, no harsh shadows

Qué muestra la salida real

En la práctica, esta receta coloca el sujeto cerca del centro y deja una zona clara de fondo vacío a la derecha, lista para superponer títulos sin necesidad de retoque. La iluminación se percibe como una única fuente suave, no como una luz ambiental plana, lo que da al lado iluminado del objeto un borde nítido y al otro lado una transición suave hacia la sombra.

Las palabras de restricción tienen aquí un efecto medible. Sin "no text artifacts", las etiquetas suelen hacer aparecer letras de la nada; con ella, la etiqueta se mantiene abstracta. Sin "no harsh shadows", el desvanecimiento se aprieta y se acerca más a una luz dura de estudio. Ambos cambios son visibles, y ambos son el tipo de regresión que quieres detectar antes de que llegue a la página.

Variar con seguridad

Puedes cambiar subject libremente: botellas, auriculares, cajas y dispositivos mantienen la composición. No toques composition ni lighting salvo que haya una razón de diseño específica; estos dos campos son justo lo que hace que la salida pueda encajar directamente en la plantilla sin necesidad de rediseñarla.

Receta 2: ilustración editorial de paleta coherente

La receta editorial es donde la variable de paleta demuestra su valor. El objetivo es una ilustración que parezca parte de una serie —una docena de artículos que comparten la misma familia visual— sin tener que regenerarla desde cero cada vez.

Prompt

{subject}, flat editorial illustration with subtle line texture,
{composition}, limited palette of {palette},
soft even lighting with no dramatic shadows,
no gradients, no photorealism, no text elements

Un ejemplo rellenado:

an abstract diagram of connected ideas, flat editorial illustration with
subtle line texture, centered composition with breathing room around the
edge, limited palette of deep teal, warm sand, and off-white, soft even
lighting with no dramatic shadows, no gradients, no photorealism, no
text elements

Cómo se comporta la variable de paleta

Nombrar dos o tres colores más un neutro mantiene la coherencia de forma estable. La salida respeta los matices nombrados como familia dominante y usa el neutro como color base, que es justo lo que mantiene cohesionada la serie.

En la salida real aparecen dos modos de fallo. Primero, nombrar cinco colores o más produce un efecto más cercano al arcoíris: la paleta deja de leerse como limitada y la ilustración pierde la contención editorial. Segundo, si omites por completo el neutro ("verde azulado profundo y arena cálida" y nada más), el fondo suele rellenarse con uno de los dos colores de acento, lo que aplana el contraste que buscabas.

Disciplina de serie

Congela style y constraints en toda la serie, y varía solo subject y, ocasionalmente, composition. Cuando un artículo nuevo necesite su propia ilustración, cambias un solo campo y obtienes un hermano, no un extraño. Eso es todo el sentido de la receta: la coherencia visual es un subproducto de la disciplina de parámetros, no una tarea de dirección de arte que haya que repetir cada semana.

Receta 3: patrón de fondo discreto para UI

Las texturas de fondo son la receta menos vistosa y la que más a menudo causa problemas en producción, porque una textura que se ve bien por sí sola puede arruinar la legibilidad del texto en cuanto se coloca detrás de un párrafo.

Prompt

{subject}, subtle abstract texture pattern, {scale} scale repetition,
low contrast with soft tonal variation, muted palette of {palette},
even flat lighting, no focal point, no text, no high-frequency detail,
keeps center area clear and low-contrast for text overlay

Un ejemplo rellenado:

organic flowing line shapes, subtle abstract texture pattern, medium
scale repetition, low contrast with soft tonal variation, muted palette
of pale slate and warm grey, even flat lighting, no focal point, no
text, no high-frequency detail, keeps center area clear and low-contrast
for text overlay

Por qué importan las palabras de restricción

"no focal point" es la frase que sostiene todo. Sin ella, la textura tiende a organizarse en torno a una forma dominante en el centro del encuadre, que es exactamente donde vas a poner el título. "no high-frequency detail" evita que las motas finas se conviertan en ruido visual detrás de cuerpos de texto pequeños, sobre todo en monitores de DPI bajo.

La última cláusula —mantener el centro despejado y de bajo contraste— es una restricción de composición, no de estilo. Empuja las partes más recargadas del patrón hacia los bordes, lo que te da una zona segura para el texto sin necesidad de una capa de máscara adicional.

La escala como variable

scale se puede cambiar con seguridad y altera notablemente la sensación de la textura. Una escala pequeña se lee como grano de papel, adecuada para paneles de UI densos; una escala grande se lee como fondo editorial a doble página, adecuada para cabeceras anchas. Vuelve a renderizar con las dos escalas y elige según la superficie, en lugar de intentar que una sola imagen sirva para todos los casos.

Sustituir variables de prompt sin romper la salida

No todos los campos son igual de importantes. Basándonos en las salidas reales de estas recetas, este es el mapa práctico de riesgos.

Sustituciones de bajo riesgo

• subject: la variable de mayor valor, normalmente segura siempre que se mantenga dentro de la misma categoría. Cambiar una botella por unos auriculares vale; cambiar una botella por una escena de multitudes no, porque el campo de composición está escrito para un único objeto centrado.
• palette (dentro de unos límites): puedes cambiar los nombres de color libremente, pero mantén la cantidad en dos o tres más un neutro.
• scale: cambia la apariencia sin romper la estructura.

Sustituciones de riesgo medio

• composition: moverse entre diseños compatibles es seguro (centrado, descentrado, en mosaico), pero cada cambio altera la cantidad de espacio negativo que obtienes. Si la plantilla posterior depende de una zona vacía concreta, verifícala después del cambio.
• lighting: los cambios de dirección se perciben con claridad y suelen funcionar; pasar de luz suave a luz dura cambia el tono general y puede entrar en conflicto con términos de estilo como "limpio" o "sutil".

Sustituciones de alto riesgo

• style: cambiar entre vector plano y fotografía equivale, en la práctica, a una receta nueva. La composición y las palabras de restricción están escritas para un lenguaje de renderizado y a menudo dejan de tener sentido en otro.
• constraints: eliminar restricciones es la causa más común de que un prompt que antes funcionaba produzca ahora salidas inutilizables. Trata la edición de restricciones como un cambio de código: hazlo de forma consciente y vuelve a revisar el resultado.

Una regla práctica

Cuando necesites una imagen nueva, cambia solo un campo a la vez y compárala con la salida anterior. Si cambias dos, no podrás saber cuál causó la regresión; la misma disciplina de depuración que aplicas a cualquier otro sistema parametrizado vale aquí, y es justo la diferencia entre una biblioteca de prompts que sigue siendo útil y una que se corrompe en silencio.

Evaluar y entregar las imágenes generadas

Antes de que una imagen entre en la interfaz del producto, revísala con una lista de comprobación breve y fija. Los criterios deben ser siempre los mismos, para que "aprobado" signifique lo mismo entre llamadas, entre recetas y entre miembros del equipo.

La comprobación de cuatro puntos

1. Cumplimiento de restricciones. ¿La salida respeta realmente las cláusulas negativas? Sin texto que aparezca de la nada, sin un punto focal que no debería existir, con la paleta dentro de los límites nombrados. Esta es la primera puerta, porque los fallos de restricción son los más difíciles de corregir después.
2. Estabilidad de la composición. ¿El sujeto está donde la receta promete, con el espacio negativo que necesita tu diseño? Si la plantilla espera una zona despejada a la derecha, mídela; no te fíes solo de la vista.
3. Legibilidad en contexto. Para cualquier contenido que vaya detrás o al lado de texto, compruébalo con el tamaño de fuente real y el texto real superpuestos. Las texturas e ilustraciones que parecen correctas por sí solas fallan a menudo aquí.
4. Coherencia de serie. Si la imagen forma parte de un conjunto, colócala junto a dos imágenes hermanas. La misma familia de paleta, el mismo grosor de línea, el mismo nivel de detalle. Un valor atípico rompe el conjunto más que una imagen mediocre.

Disciplina de entrega

Adjunta la versión de la receta, el prompt rellenado y el conjunto de parámetros a cada imagen que conserves. Cuando más tarde la salida no parezca correcta, podrás volver a ejecutar exactamente la misma llamada para determinar si lo que cambió fue la entrada o el comportamiento del modelo, y podrás regenerar toda la serie a partir de la receta guardada sin tener que rebuscar en el historial de chat.

La copia y pega es el hilo conductor de todo: cualquier miembro del equipo debería poder tomar una receta de este artículo, rellenar las variables y reproducir el resultado sin reajustar ni una sola palabra. Si construyes la biblioteca de prompts así, la generación de imágenes deja de ser una negociación imagen por imagen y pasa a ser un servicio que el equipo invoca.