Recetas de prompts para imagen4-fast: prompts listos para copiar y pegar por desarrolladores

Por qué las recetas de prompts superan a los prompts desechables

La mayoría de los problemas de generación de imágenes no son problemas del modelo, sino del prompt, y resultan difíciles de corregir porque el prompt suele existir solo en el historial de chat de alguien o en un documento desactualizado. Un prompt desechable que dio un resultado excelente un martes no se puede reproducir el viernes, porque no puedes decir con exactitud qué contenía.

Una receta de prompt resuelve esto de la misma forma en que una función resuelve la lógica copiada y pegada. Tiene una estructura fija, ranuras con nombre e identificadores estables, para que puedas referenciarla más adelante. Cuando la salida cambia, tienes algo con lo que comparar.

El beneficio práctico aparece rápido:

• Consistencia entre llamadas. La misma receta con las mismas entradas produce composiciones y estilos comparables; esto es esencial cuando una página debe renderizar doce imágenes de tarjetas en una cuadrícula.
• Iteración de bajo costo. Cambias una sola ranura a la vez en lugar de reescribir prosa libre y dispersa, perdiendo así las partes que sí funcionaban.
• Trazabilidad. Las recetas tienen versiones. Cuando el equipo de marca pregunta por qué las miniaturas se ven más planas que el mes pasado, puedes hacer una búsqueda binaria.
• Revisabilidad. Las recetas se pueden revisar en un pull request como cualquier otro recurso, y quien revisa no necesita ser alguien que se gane la vida escribiendo prompts.

El resto de este artículo es un manual. Cada receta sigue el mismo esqueleto, así que puedes leer una, adaptarla y colocarla en tu base de código sin refactorizar. Trata el modelo como un componente y la receta como la interfaz que construyes sobre él.

Hay una idea que conviene recordar: una receta no es un conjuro mágico. Es un contrato entre la ranura de UI aguas abajo y la llamada de generación. La ranura de UI decide el formato; la receta decide con qué llenarlo.

El esqueleto base del prompt

Cada receta de este manual se compone del mismo esqueleto de cuatro partes. Copia esto y rellena las ranuras:

[subject] — [composition] — [style] — [constraints]

La idea central es toda esa. Aquí tienes una versión rellenada, lista para pegar y usar:

A lone ceramic coffee cup on a pale oak desk, three-quarter view, shallow depth of field,
soft morning light from the left, minimal editorial product photography, muted warm palette,
no text, no logos, no hands, centered subject with breathing room on all sides

La función de cada ranura

El sujeto (Subject) es la única cosa de la que trata la imagen. Nómbralo con precisión: «una taza de café de cerámica», no «ambiente cafetero». Si el sujeto tiene una acción o un estado, ponlo aquí también: «un desarrollador a mitad de teclear frente a un escritorio en penumbra». Resiste la tentación de añadir un segundo sujeto; es la causa más común de resultados desordenados.

La composición (Composition) controla el formato. El ángulo de visión (vista de tres cuartos, cenital, a la altura de los ojos), la posición del sujeto (centrado, en el tercio izquierdo), el recorte (plano completo, recorte ajustado) y la profundidad de campo pertenecen aquí. Esta ranura es donde codificas con palabras la intención de la relación de aspecto, aunque la proporción real sea otro parámetro independiente.

El estilo (Style) es un pequeño léxico visual: medio (fotografía, vector plano, acuarela), iluminación (luz suave de mañana, contraluz duro), paleta (tonos cálidos apagados, monocromo de alto contraste) y textura (mate, brillante, con grano). Mantenlo en una a tres frases cortas. Los bloques de estilo más largos suelen pelearse entre sí.

Las restricciones (Constraints) son el espacio negativo. Lo que no debe aparecer: texto, logotipos, marcas de agua, extremidades extra, fondos recargados, sombras duras. Las restricciones son un seguro barato y también lo primero que hay que ampliar cuando una receta falla.

Dos variantes que conviene tener siempre a mano

Fotografía de objeto minimalista:

[object] on a seamless [color] backdrop, centered, straight-on view, soft even studio light,
clean commercial product photography, no shadows on background, no text, no props

Fotografía de escena editorial:

[scene subject] in [environment], wide establishing view, natural light, subtle film grain,
documentary photography, muted palette, no text, no logos, no visible brand marks

Ambas se mantienen deliberadamente breves. Si tu prompt es una acumulación de adjetivos, probablemente has perdido la ranura de composición en algún lugar dentro de ella.

Elige la relación de aspecto antes de escribir el prompt

Escribe el prompt después de conocer la forma del hueco que vas a llenar. La relación de aspecto es una decisión de producto, no una decisión del prompt; elegirla tarde te obliga a reescribir frases de composición que ya habías ajustado.

Un mapeo sencillo que cubre la mayoría de las interfaces:

• Banners principales y cabeceras de página: formato ancho. Lenguaje de composición: «wide establishing view», «horizon placed in the lower third», «negative space on the left for headline overlay».
• Tarjetas y mosaicos de cuadrícula: cuadrado o casi cuadrado. Lenguaje de composición: «centered subject», «even margins», «no important detail near the edges».
• Avatares y miniaturas de perfil: cuadrado, recorte ajustado, un único sujeto. Lenguaje de composición: «head and shoulders», «centered face», «plain background».
• Miniaturas y filas de lista: recorte ancho o cuadrado de tamaño pequeño; el sujeto debe seguir siendo reconocible al reducirse. Lenguaje de composición: «single dominant subject», «high contrast against background», «no fine detail».
• Contenido editorial o imágenes que acompañan textos largos: formato vertical. Lenguaje de composición: «vertical composition», «subject occupies the upper two thirds», «foreground anchor at the bottom».

Por qué la redacción debe coincidir con el formato

Una frase de composición escrita para un banner ancho («negative space on the left») carece de sentido en cuanto se recorta a cuadrado; y un recorte vertical ajustado descrito con palabras se comprime si pides un formato ancho. El prompt y la proporción deben coincidir, porque describes el mismo rectángulo dos veces: una con lenguaje y otra con parámetros.

Flujo de trabajo práctico

1. Examina la ranura de UI real, anota su relación de aspecto y cómo se recorta en pantallas pequeñas.
2. Elige la relación de aspecto compatible más cercana, en lugar de pedirle al modelo que la falsifique con espacio en blanco.
3. Escribe la ranura de composición en torno a ese formato, incluido dónde debe caer el espacio negativo.
4. Tras generar, comprueba el peor recorte posible (móvil, cuadrícula reducida), no el ideal.

Si una receta debe servir a dos ranuras muy distintas, haz dos recetas. Copiar una receta sale más rentable que escribir una frase de composición que funcione a medias en todas partes.

Bloques de pistas de estilo intercambiables según la interfaz

La ranura de estilo es la parte que debes esperar cambiar con más frecuencia, así que hazla modular. Escribe las pistas de estilo como un bloque autocontenido que se engancha al esqueleto base, y mantén un bloque por interfaz o por tono de marca.

Seguro para marca / neutro

minimal editorial photography, soft diffused light, muted neutral palette,
clean background, product-focused, no text, no logos

Para páginas de marketing, donde la imagen no debe competir con el texto ni sugerir una afirmación de marca.

Fotográfico / documental

natural light, documentary photography, shallow depth of field, subtle grain,
unposed subject, realistic color, no heavy filters

Para imágenes editoriales e interfaces narrativas, donde el realismo funciona mejor que el refinamiento.

Ilustración plana

flat vector illustration, limited two-color palette, bold simple shapes,
no gradients, generous whitespace, geometric composition, no text

Para onboarding, estados vacíos y documentación, donde la imagen debe coincidir con el sistema de diseño.

Fotografía de producto de estudio

seamless studio backdrop, soft even key light, crisp shadows, high detail on the subject,
commercial catalog photography, no props, no text

Para catálogos de productos y cuadrículas comparativas, donde la consistencia entre varias imágenes importa más que cualquier imagen individual.

Cómo cambiar de bloque sin degradar el resultado

• Trata el bloque de estilo como una variable y nunca lo entremezcles con las frases de sujeto o composición. Si las palabras de estilo están dispersas por todo el prompt, no podrás sustituirlas limpiamente.
• Cambia un solo bloque a la vez y regenera con el mismo sujeto y la misma composición. Si dos variables cambian a la vez, no podrás saber cuál causó la diferencia.
• Desconfía de los bloques de estilo que introducen de contrabando decisiones de composición. «Centered» y «close-up» pertenecen a la composición, no al estilo; si viven en el bloque de estilo, tu trabajo con la relación de aspecto queda anulado en silencio.
• Poda los bloques que no dejan de crecer. Tres frases de estilo suelen bastar; cinco empiezan a competir entre sí.

Una prueba útil: sustituye el bloque de estilo sobre una receta idéntica en todo lo demás y comprueba si la salida sigue encajando en la misma ranura de UI. Si encaja, el bloque está bien aislado.

Parametrizar prompts en el código

Las recetas deben existir como plantillas, no como literales de cadena dispersos por los distintos manejadores. Una plantilla con variables con nombre te regala pruebas A/B, reversiones y sobrescrituras por interfaz.

Forma de la plantilla

RECIPE = {
    "id": "product-hero-v3",
    "template": (
        "{subject} — {composition} — {style} — {constraints}"
    ),
    "defaults": {
        "composition": "centered subject, generous margins, eye-level view",
        "style": "minimal editorial photography, soft diffused light, muted neutral palette",
        "constraints": "no text, no logos, no watermark, clean background",
    },
    "aspect_ratio": "1:1",
}


def render(recipe, **overrides):
    slots = {**recipe["defaults"], **overrides}
    return recipe["template"].format(**slots)

El objeto de receta lleva su identificador (id), su formato (aspect_ratio) y sus valores por defecto. Quien llama solo aporta lo que difiere. Esto mantiene cortos los puntos de llamada y hace evidente de un vistazo la diferencia entre dos interfaces.

Variantes para pruebas A/B

Modela las variantes como sobrescrituras sobre la receta base, no como cadenas bifurcadas:

variants = {
    "control": {},
    "warm": {"style": "minimal editorial photography, warm afternoon light, muted warm palette"},
    "tight": {"composition": "tight crop, subject fills the frame, eye-level view"},
}

Como cada variante comparte sujeto y restricciones, la diferencia en el resultado se puede atribuir a la ranura que cambiaste. Ese es todo el valor de este ejercicio.

Reversiones y fijación

• Da a cada receta una versión en su id y regístrala en cada solicitud de generación. Cuando la salida cambie, el registro te dirá qué versión de la receta produjo qué.
• Mantén las versiones antiguas accesibles durante un tiempo. Revertir debe ser un cambio de configuración, no un retroceso de código bajo presión.
• Usa el id de la receta, no la cadena renderizada, al enviar datos a tu sistema de analítica, para poder agrupar resultados por receta en lugar de por texto exacto del prompt.
• Valida las ranuras antes de llamar a la API: un subject vacío debe fallar rápido en tu aplicación, no producir una imagen ambigua.

Trata la relación de aspecto como un parámetro de primera clase junto a la plantilla, porque la determina la ranura de UI, no el texto del prompt. Todo lo que la API necesita debería derivarse de un único objeto de receta, de modo que cada interfaz tenga una única fuente de verdad.

Modos de fallo habituales y cómo depurarlos

La mayoría de las salidas malas se pueden rastrear hasta una ranura. Usa esta lista para decidir qué parte del esqueleto ajustar antes de empezar a reescribir el prompt entero.

El sujeto aparece recortado o fuera de encuadre

Síntoma: cabezas cortadas, objetos que se salen de los bordes, detalles importantes fuera de la zona segura.

Corrige primero la ranura de composición, no la de estilo. Añade lenguaje de encuadre explícito («full subject in frame», «generous margins on all sides») y confirma que la relación de aspecto coincide con el formato previsto. Si el sujeto es alto y la ranura ancha, el formato es el equivocado, no el prompt.

Resultados desordenados

Síntoma: varios focos que compiten, fondos recargados, accesorios que no pediste.

Corrige la ranura de sujeto. Redúcelo a un sujeto y un estado. Mueve a las restricciones como exclusiones cualquier cosa que pueda leerse como accesorio. El desorden suele venir de un sujeto ambiguo, no de un modelo demasiado entusiasta.

Estilo inconsistente dentro de un mismo lote

Síntoma: en la cuadrícula, algunas imágenes parecen fotografía y otras ilustración; la paleta se desplaza.

Corrige el bloque de estilo. Redúcelo a un medio, una frase de iluminación y una frase de paleta. Elimina las palabras de estilo que se filtran a otras ranuras y divide las recetas que sirven a dos interfaces distintas a la vez. La inconsistencia dentro de un lote suele ser síntoma de un bloque de estilo distinto en cada llamada.

Aparece texto o logotipos

Síntoma: letras sin sentido, marcas de agua falsas, marcas similares a logotipos de marca.

Amplía las restricciones: «no text, no lettering, no logos, no watermarks, no signage». Si la composición sugiere un soporte que normalmente lleva texto (pantalla, embalaje, póster), indícalo explícitamente o cambia la composición.

La salida ignora el tono emocional solicitado

Síntoma: la imagen es correcta pero se siente plana, rígida o genérica.

Corrige el bloque de estilo, una frase a la vez. La iluminación suele ser el cambio con más impacto; la paleta va después. Regenera con el mismo sujeto y la misma composición para que la comparación sea honesta.

Todos los demás casos

Si las dos ranuras parecen sospechosas, cambia una y regenera. Si el resultado sigue sin ser el correcto, da un paso atrás y comprueba si la receta está sirviendo a una ranura de UI para la que nunca se escribió: eso es un desajuste de producto, no un defecto del prompt.

Publicar una biblioteca de recetas

Una vez que las recetas son plantillas con versiones, se convierten en un activo que el equipo mantiene junto con el código. El objetivo es que cualquiera pueda encontrar la receta que hay detrás de una interfaz, entender por qué es así y modificarla con seguridad.

Organizar por interfaz, no por texto del prompt

Agrupa las recetas por dónde se renderizan: hero, card, avatar, thumbnail, editorial-figure. Un desarrollador que mira la página de precios debería aterrizar en la receta que usa esa página, no en una lista alfabética de adjetivos. Da a cada receta un id estable y un sufijo de versión, y mantén los valores por defecto dentro del objeto de receta.

Revisar recetas en pull requests

Trata los cambios de receta como cambios de componente. El diff debe mostrar qué ranura cambió y por qué. Quien revisa puede hacer preguntas útiles: ¿la composición sigue coincidiendo con el formato?, ¿se han filtrado palabras de estilo a la composición?, ¿se han recortado las restricciones? Los diffs pequeños, de una sola ranura, son fáciles de revisar; las reescrituras completas, no.

Versionar, registrar y limpiar

• Registra el id y la versión de la receta en cada solicitud de generación, para que los cambios en la salida se puedan rastrear hasta un cambio concreto.
• Mantén las versiones obsoletas accesibles hasta que ninguna interfaz las referencie; después elimínalas en una ronda de limpieza, en lugar de dejar recetas muertas para siempre.
• Cuando añadas variantes, promociona la ganadora como nueva versión en lugar de dejar la rama A/B como ruta permanente.

Documentar el contrato

Para cada receta, documenta la ranura de UI prevista, la relación de aspecto y las restricciones que no se pueden eliminar. Dos frases bastan. Quien modifique esa receta a continuación necesita saber qué no puede romper.

Mantener el bucle corto

Las recetas se pudren cuando nadie las regenera después de un cambio de diseño. Incorpora un pequeño paso de revisión a cualquier trabajo de UI que modifique ranuras de imagen y vuelve a ejecutar las recetas afectadas como parte de ese cambio. El sistema entero solo se mantiene barato si el bucle de retroalimentación se mantiene corto.

Empieza con el esqueleto base, añade un bloque de estilo por interfaz y deja que la biblioteca de recetas crezca a partir de ranuras reales en lugar de ranuras imaginarias. Si estás conectando la generación a tu aplicación, mantén ligeros los puntos de llamada y deja que el objeto de receta cargue con las decisiones.