CommunityImagengithub.com

skill-image-qwen

Genera o edita imágenes usando el modelo Qwen-Image-3.0. V3 con cadena de tokens de tres etapas: optimizar, preparar y generar.

¿Qué es skill-image-qwen?

skill-image-qwen es un skill para agentes de IA (como Claude Code, Cursor, Codex) que permite generar y editar imágenes utilizando el modelo Qwen-Image-3.0 (T2I e I2I). Su versión V3 introduce una cadena de tokens de tres etapas: **optimizar** (revisión y optimización del prompt según guías oficiales, registro de cambios y generación del Token A, sin llamar a la API), **preparar** (consumo del Token A, presentación de la comparación al usuario para confirmación, generación del Token B y destrucción del Token A, sin llamar a la API) y **generar** (solo si el Token B es válido, se llama a la API y luego se destruye el Token B). Este flujo obligatorio evita que el modelo salte a la generación sin revisión humana y garantiza calidad y control de costos. Soporta múltiples tamaños (1K y 2K) y versiones (estándar y Pro). El skill incluye un flujo de trabajo completo: clarificación de intención, optimización del prompt, confirmación del usuario, preparación y generación iterativa.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add 962753401-cloud/skill-image-qwen

Installed? Explore more Imagen skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

skill-image-qwen Skill

Genera o edita imágenes usando el modelo Qwen-Image-3.0. El modelo soporta tanto texto a imagen (T2I) como imagen a imagen / edición de imágenes (I2I), permitiendo generar imágenes directamente a partir de un prompt de texto, o editar con precisión basándose en 1-3 imágenes de referencia. El objetivo central pasa de "que se vea bien" a "que sea útil": la imagen generada debe ser un producto final entregable. Principio clave: aprovechar al máximo la capacidad del modelo mediante el prompt; poner la máxima prioridad en la "clarificación de requisitos", "revisión y optimización del prompt" y "confirmación previa a la generación".

Mejora clave V3: Cadena de tokens de tres etapas (resguardo en código, única 100% efectiva)

La V2 tenía dos fases (preparar/generar), el modelo podía saltar la revisión y optimización del prompt en teoría. La V3 añade la "fase de revisión y optimización del prompt" como una puerta de control a nivel de código, formando una cadena de tokens de tres etapas:

  • Etapa 1 optimizar: El modelo completa la revisión y optimización siguiendo la plantilla oficial (paradigma de 6 pasos), y registra la información: forzoso incluir "comparativa antes/después + explicación de cambios" (para evitar trabajo superficial). El código genera el Token A (vinculado a la huella sha256 del prompt optimizado) y lo guarda en disco. Nunca llama a la API real.
  • Etapa 2 preparar: El código verifica el Token A (sin Token A -> rechazo, indicando "primero debe completarse la fase de revisión y optimización"); si pasa, presenta al usuario la comparativa original "solicitud original -> prompt optimizado -> explicación de cambios" para confirmación; genera el Token B, destruye el Token A (consumir y listo). Nunca llama a la API real.
  • Etapa 3 generar: El código verifica el Token B (sin Token B / sin coincidencia / contenido alterado -> rechazo); si pasa, realiza la llamada a la API, destruye el Token B tras éxito (consumir y listo).

Relevo de tokens: optimizar ->(Token A)-> preparar ->(Token B)-> generar; si falta una "entrada", la puerta no se abre; el modelo no puede saltar de la solicitud original directamente a la generación.

El token es un subproducto del flujo, no una contraseña fija: el código genera dinámicamente una huella de contenido (sha256(prompt)), el modelo no puede falsificarla ni siquiera leyendo el código fuente; solo completando honestamente la fase correspondiente se obtiene la clave.

El token está vinculado al contenido: cada solicitud tiene un token diferente; si el contenido enviado no coincide con la versión registrada/confirmada, se rechaza, evitando "mostrar una cosa, generar otra".

Ámbito del token: la huella solo cubre el contenido del prompt; parámetros técnicos como tamaño/formato se toman del registro, no se incluyen en la huella. El bloqueo se centra en el contenido confirmado; los parámetros técnicos se manejan de forma flexible para evitar tener que reiniciar todo el flujo al cambiar el tamaño.

Consumir y listo: preparar consume el Token A y lo destruye; generar destruye el Token B tras éxito, evitando reutilizar tokens antiguos para saltar pasos.

Enseñanza inversa con mensajes de rechazo: el texto de error es una guía del flujo; al ser rechazado, el modelo puede autocorregirse y seguir el flujo correcto.

Mecanismo anti-trabajo superficial: El registro de optimizar exige forzosamente "comparativa antes/después + explicación de cambios"; preparar lo presenta tal cual al usuario para confirmación. Si se quiere simular, se debe inventar una razón para el cambio, lo que aumenta el coste de superficialidad; el usuario puede verificar la justificación de la optimización y detectar si la dirección se desvía (ej. "estilo realista" cambiado a "estilo cartoon"). Un mismo resultado actúa como "tarea anti-trabajo superficial" y "base de confirmación del usuario", sin añadir pasos extra.

Modelo y versiones

VersiónID del modeloEnfoquePrecio por generación
Estándar (por defecto)qwen-image-3.0Equilibrio calidad-velocidad, ideal para uso diario1K/2K ambos 0.18 yuan/imagen
Pro (opcional)qwen-image-3.0-proMaquetación densa, detalles extremos, conocimiento profundo1K 0.25 yuan/imagen, 2K 0.50 yuan/imagen

Capacidades clave del modelo ("Tres reales" oficiales):

CapacidadDescripciónIndicador clave
Contenido realCabe una página entera: exámenes, periódicos, guías ilustradas, infografías generadas en una sola vezLongitud de instrucción aumentada a 4.5K tokens
Detalle realResiste el zoom: textura que se acerca a materiales realesTexto pequeño de 10px legible, poros y cabellos visibles
Conocimiento realSabe de todo: multilingüe, multidisciplinarCubre 12 idiomas, 100+ estilos artísticos y varias interfaces de usuario
  • Por defecto se usa la versión estándar. Solo se cambia a Pro cuando el usuario lo solicita explícitamente o cuando se necesita maquetación densa (texto en imagen), detalles faciales/poros/cabellos, o el usuario lo pide.
  • El precio de entrada es el mismo para ambas versiones (0.02 yuan/imagen). Ver references/pricing_and_models.md.
  • Límites de capacidad del modelo y recomendaciones de selección en references/pricing_and_models.md.

Flujo de trabajo (obligatorio)

① Identificación y clarificación de intención -> ② Selección de versión -> ③ Construcción del prompt y llamada a optimizar -> ④ Presentación y confirmación -> ⑤ preparar confirmación -> ⑥ generar e iterar -> ⑦ Reportar consumo.

Primer paso: Identificación de intención y clarificación de requisitos (cuestión de suma importancia, no saltar)

Como experto en generación de imágenes por IA, determinar si la solicitud del usuario es lo suficientemente clara y detallada. La solicitud inicial del usuario suele ser vaga; este paso es clave para la calidad de la imagen; se debe confirmar con el usuario repetidamente.

  1. Analizar la intención: Combinando la pregunta textual del usuario + los archivos adjuntos (imágenes de referencia/borradores/capturas), determinar inicialmente:
    • Tipo de tarea: ¿creación desde cero (T2I)? ¿Edición basada en imágenes existentes (I2I)?
    • ¿Implica personas reales específicas, marcas u objetos que deban ser fieles?
    • Número de imágenes de referencia y el rol de cada una (objetivo de edición / referencia de estilo / fuente del sujeto).
  2. Detallar en múltiples dimensiones (confirmar una por una si es vago, se puede usar request_user_input para preguntas masivas o preguntas naturales; si ya es detallado, confirmar ligeramente):
    1. Contenido principal 2. Estilo 3. Composición y ángulo 4. Ambiente e iluminación 5. Tamaño y proporción 6. Cantidad 7. Uso final 8. Imágenes de referencia 9. Requisitos de fidelidad
  3. Si implica personas reales: Preguntar y registrar características distintivas de cada persona (peinado/color de pelo/gafas/tono de piel/forma de la cara/vestimenta/tipo de cuerpo/edad) como anclas en el prompt.
  4. Resumir en una "especificación de imagen" y presentarla al usuario para confirmación.

Principio de eficiencia: Si la solicitud es clara, solo hacer una confirmación ligera (repetir + preguntar "¿es correcto? ¿necesitas ajustes?"), no seguir la lista completa mecánicamente; solo profundizar en dimensiones ambiguas o de alto riesgo (fidelidad, rol de las imágenes de referencia).

Segundo paso: Seleccionar la versión

Basándose en los requisitos clarificados en el primer paso, seleccionar la versión según las recomendaciones (ver references/pricing_and_models.md):

EscenarioVersión recomendada
Pósteres cotidianos, ilustraciones, imágenes para redes sociales, prototipos de UI, generación por lotesEstándar (por defecto)
Salida de alta resolución 2K sin necesidad de detalles extremosEstándar (2K mismo precio, más económico)
Composición de imágenes de productos de e-commerce en escenarios del hogar (I2I con múltiples imágenes)Estándar es suficiente; si se busca textura extrema, elegir Pro
Maquetación densa: páginas de periódico, exámenes, storyboards, menús, infografíasPro
Retratos fotográficos, primeros planos de productos (expresiones, poros, cabellos)Pro
Guías ilustradas de conocimiento, infografías históricas (múltiples módulos + multilingüe)Pro
  • Por defecto se usa la versión estándar; si se necesita Pro, informar al usuario de la diferencia de coste (en 2K, Pro es un 178% más caro).
  • Si el usuario no especifica la versión, usar la estándar y explicarlo en la propuesta de generación.

Tercer paso: Construir el prompt y llamar a optimizar (revisión y registro, nunca llamar a la API)

Basándose en la intención y especificaciones del primer paso, combinando las mejores prácticas y la biblioteca de casos, revisar y optimizar el prompt y seleccionar el modo; luego llamar a optimizar (en lugar de generar directamente). optimizar es el paso clave para maximizar la capacidad del modelo: la solicitud original suele ser breve y vaga; se debe expandir a un prompt con suficiente descripción visual siguiendo el paradigma oficial de 6 pasos, y registrar la "comparativa antes/después + explicación de cambios".

3.1 Revisar mejores prácticas y biblioteca de casos

Primero consultar references/best_practices.md y references/case_library.md para ver si hay casos oficiales similares, aprender su estructura de promps y técnicas clave, identificar errores comunes y evitarlos.

Búsqueda rápida de caso a escenario:

Escenario del usuarioCaso de referenciaEnfoque del prompt
Maquetación de exámenes/documentos/informesCaso 1 (Examen de lengua)Descripción escaneando área por área + texto palabra por palabra
Fotografía macro / primer plano de productoCaso 2 (Macro de bordado)Fibra del material + momento de la acción + poca profundidad de campo
Notas manuscritas / fórmulas matemáticasCaso 3 (Notas de matemáticas)Anotaciones de tres colores + fórmulas palabra por palabra + figuras geométricas
Composición de imágenes de productos de e-commerce en escenariosCaso 4 (Composición de imagen de producto I2I)Reglas de edición (extraer/ignorar/conservar/generar)
Diseño de personajes / consistencia multiánguloCaso 5 (Boceto de diseño de personaje)Descripción muy detallada de una persona + división en zonas multiángulo
Mapas dibujados a mano / infografíasCaso 6 (Mapa gastronómico)Descripción por zonas + puntos numerados + sistema de leyendas
Menús / listas de preciosCaso 7 (Menú de Teochew)Secciones por columnas + lista de platos + fotos incrustadas
Guías ilustradas de conocimiento / pósteres divulgativosCaso 8 (Guía ilustrada de ruqun)Descripción modular + personaje principal visual + módulos auxiliares
Infografías de movimiento vectorial / guías de recorridosCaso 9 (Mapa de senderismo)Estilo vectorial inglés + sistema de colores + puntos de ruta
Enseñanza histórica / infografías multilingüeCaso 10 (Rebelión de An-Shi)Modo bilingüe + formato apaisado panorámico + restricciones negativas
Retrato fotográfico comercialCaso 11 (Retrato callejero italiano)Narrativa de fondo multicapa + descripción muy detallada de la persona + efecto de película
Retrato fotográfico con iluminaciónCaso 12 (Retrato con sombrero de paja e iluminación)Causa y ubicación de la luz + parámetros fotográficos + restricciones negativas

El análisis completo de la estructura de los promps y las técnicas clave de los 12 casos oficiales se encuentra en references/case_library.md; los promps originales completos están en Qwen-Image-3.0官方最佳实践案例与完整提示词手册.md.

3.2 Elegir el modo (según el objetivo)

ObjetivoModoLlamada
Creación desde cero, sin imágenes de referenciaTexto a imagen T2ISolo prompt, no pasar --image
Conservar/extender el personaje o contenido de una imagen existenteImagen a imagen I2IPrompt + 1~3 --image

3.3 Escribir el prompt (paradigma oficial de 6 pasos)

Organizar el contenido siguiendo el esqueleto de estructura de prompts resumido por los 12 casos oficiales (ver references/best_practices.md capítulo 3):

  1. Apertura y tono: Una frase que describa el tipo de imagen, orientación, estilo general y ambiente. Ej.: "Este es un póster vertical..., el fondo general es..."
  2. Recorrido espacial: Describir estrictamente en orden espacial (de arriba a abajo, de izquierda a derecha, del sujeto al fondo) área por área, indicando las relaciones de posición relativa de cada elemento.
  3. Escribir el texto palabra por palabra: Todo el texto que deba aparecer (títulos/cuerpo/etiquetas/precios/pie de página) debe escribirse con comillas y especificar la fuente, tamaño, color y posición.
  4. Cinco elementos de detalle: Dar nombres de colores específicos, palabras de textura para los materiales, dirección y dureza de la luz, estilo de la fuente, capas de composición.
  5. Restricciones de cierre: Listar las restricciones negativas con "evitar..." (caracteres extraños, desalineación, distorsión, sobreexposición, marcas de agua, etc.), también se puede usar el parámetro --negative-prompt.
  6. Parámetros de formato y fotografía: Para escenas realistas/retratos, se pueden incluir proporción de formato, distancia focal, apertura, etc. (ej. "vertical 3:4, 85mm, f/2").

3 consejos de uso oficiales:

  • La instrucción puede ser "larga": 4.5K tokens para maquetaciones complejas; describir cada área, cada texto, cada posición relativa.
  • El texto pequeño debe "nombrarse": Escribir el texto exacto directamente en la instrucción, marcarlo con comillas y especificar fuente/tamaño/color/posición.
  • El estilo debe "explicarse por completo": Para estilo fotográfico, describir luz, ambiente, distancia focal/apertura/exposición/grano de película; para estilo ilustración, describir textura, colores, trazos.

Puntos especiales para edición/referencia (I2I): Escribir claramente "conservar X, solo cambiar Y"; en iteraciones, reafirmar las invariables para evitar desviaciones. En composiciones con múltiples imágenes, el enfoque está en las reglas de edición (qué extraer/qué ignorar/qué conservar/qué generar), usar palabras de restricción fuertes como "debe" "no debe" para asegurar el uso completo de las imágenes de referencia.

3.4 Llamar a optimizar (registrar comparativa+explicación, devolver Token A, nunca llamar a la API)

Una vez completada la revisión y optimización del prompt, llamar a la fase optimizar (en lugar de generar directamente). optimizar verifica anti-trabajo superficial (original/optimizado/explicación de cambios presentes y con contenido sustancial), valida parámetros, calcula la huella del prompt optimizado, guarda el registro de revisión y devuelve el Token A; nunca llama a la API real, no consume costes:

optimizar T2I: python scripts/generate_image.py optimize --original-prompt "Solicitud original" --optimized-prompt "Prompt optimizado" --change-explanation "Explicación de cambios" --size 1024*1024
optimizar I2I: python scripts/generate_image.py optimize --original-prompt "Solicitud original" --optimized-prompt "Prompt optimizado" --change-explanation "Explicación de cambios" --image ref.png --model qwen-image-3.0-pro
optimizar multi-imagen: python scripts/generate_image.py optimize --original-prompt "..." --optimized-prompt "..." --change-explanation "..." --n 4

Parámetros obligatorios de optimizar: --original-prompt (solicitud original), --optimized-prompt (prompt optimizado), --change-explanation (explicación de cambios: qué se ha optimizado y por qué; es la base para confirmación del usuario y evita el trabajo superficial). Parámetros comunes: --model (por defecto qwen-image-3.0), --image (1-3 imágenes de referencia), --size ancho*alto, --n (1-6), --negative-prompt, --seed, --watermark, --no-prompt-extend, --prompt-extend-mode direct|agent, -o ruta de salida. Todos los parámetros se bloquean en el registro durante optimizar y no se pueden alterar en las fases posteriores (solo -o en generar puede sobrescribir la ruta de salida).

Los parámetros de tipo prompt admiten sintaxis @archivo: si el valor comienza con @, se lee el contenido del archivo en la ruta indicada (para promps muy largos, evitando el límite de longitud de línea de comandos), ej. --optimized-prompt @optimized.txt.

Salida de optimizar: solicitud original, prompt optimizado, explicación de cambios, plan de generación (modo/modelo/tamaño/cantidad/modo de reescritura/coste estimado), token de auditoría (Token A). Llevar todo esto al cuarto paso.

Cuarto paso: Presentación y confirmación (forzoso esperar confirmación del usuario)

Mostrar al usuario la "solicitud original -> prompt optimizado -> explicación de cambios" + plan de generación + Token A devueltos por optimizar, y esperar confirmación explícita:

  • Confirmación del usuario -> Pasar al quinto paso, usar el Token A para llamar a preparar.
  • El usuario solicita modificaciones -> Volver al tercer paso, re-optimizar y optimizar de nuevo (generar nuevo Token A; el Token antiguo se invalida/se limpia automáticamente), luego volver a presentar para confirmación.
  • ⚠️ No llamar a preparar/generar antes de la confirmación del usuario. La verificación de código no valida si "el usuario realmente ha visto", pero preparar debe depender de un Token A de optimizar válido; la presentación y confirmación es un control de calidad y coste. El usuario puede verificar si la dirección de optimización se desvía comparando la explicación de cambios (ej. "estilo realista" cambiado a "estilo cartoon").

Quinto paso: preparar confirmación (consumir Token A, devolver Token B, no llamar a la API)

Tras la confirmación del usuario, llamar a preparar con el Token A + el prompt optimizado exactamente igual al registrado en optimizar:

preparar: python scripts/generate_image.py prepare --token <Token A> --optimized-prompt "<Prompt optimizado registrado en optimizar>"
  • El script verifica tres condiciones (registro de auditoría existe / Token A coincide / prompt optimizado coincide con la versión registrada); si pasa, presenta tal cual "solicitud original -> prompt optimizado (versión confirmada) -> explicación de cambios" + plan de generación, devuelve el token de confirmación (Token B) y destruye el Token A (consumir y listo).
  • Los parámetros técnicos (imágenes/tamaño/cantidad, etc.) se toman del registro de optimizar y se bloquean; no se pueden alterar en la fase preparar.
  • Sin Token A o contenido no coincidente -> Rechazo (el texto de error es la guía del flujo).

Sexto paso: generar e iterar punto a punto

Llamar a generar con el Token B + el prompt exactamente igual a la versión confirmada en preparar:

generar: python scripts/generate_image.py generate --token <Token B> --prompt "<Prompt versión confirmada>" [-o ruta de salida]
  • El script verifica tres condiciones (registro de confirmación existe / Token B coincide / prompt coincide con la versión confirmada) antes de llamar a la API; el resto de parámetros se toman del registro y se bloquean; no se pueden alterar en la fase generar.
  • Tras éxito, muestra automáticamente las dimensiones reales, uso y coste, y destruye el Token B (de un solo uso, no reutilizable).
  • Muestra la imagen con ruta absoluta.
  • Iteración: Cambiar solo una cosa a la vez -> optimizar de nuevo (nuevo Token A) -> presentar y confirmar -> preparar (nuevo Token B) -> generar. Si el resultado no es satisfactorio, priorizar ajustar "estilo/ambiente" o "composición", o volver al tercer paso para cambiar de estrategia.

Séptimo paso: Reportar consumo

Tras la generación, el script muestra automáticamente el uso y coste de esta ejecución (versión, nivel de entrada/salida, número de imágenes, precio unitario, total). En la respuesta, resumir al usuario:

  • Versión y modo utilizados (T2I/I2I), ID del modelo.
  • Tamaño de salida, cantidad generada, nivel de facturación (1K/2K).
  • Coste de entrada, coste de salida, coste total (yuanes).
  • ID de solicitud (para trazabilidad).

Las reglas de cálculo de costes y ejemplos se encuentran en references/pricing_and_models.md.

Mecanismo de tokens y registros (cadena de tres etapas, detalles de resguardo en código)

  • Formato de token: sha256(prompt)-nonce8 (la huella se vincula al contenido del prompt; el nonce asegura que registros múltiples con el mismo prompt no se sobrescriban entre sí). Token A y Token B tienen el mismo contenido y huella pero diferentes nonces; son dos tokens distintos.
  • Relevo de tokens: optimizar produce Token A -> preparar consume Token A y produce Token B (destruye A) -> generar consume Token B (lo destruye tras éxito). Falta un eslabón y se rechaza.
  • Almacenamiento de registros: Dos directorios en el directorio temporal del sistema: skill_image_qwen_optimize/<tokenA>.json (Token A, contiene original_prompt/optimized_prompt/change_explanation/params), skill_image_qwen_pending/<tokenB>.json (Token B, contiene la versión confirmada y parámetros recuperados). optimizar solo guarda rutas/URLs de imágenes, no lee el contenido de las imágenes, los registros se mantienen ligeros.
  • Ámbito del token: La huella solo cubre el contenido del prompt (sha256(prompt)); los parámetros técnicos como tamaño/formato se toman del registro, no se incluyen en la huella. Cambiar el tamaño no requiere reiniciar todo el flujo (a menos que el tamaño/marca de agua sea un elemento normativo que el usuario deba confirmar).
  • Anti-trabajo superficial: El registro de optimizar exige forzosamente "comparativa antes/después + explicación de cambios"; la explicación de cambios debe tener una longitud mínima; preparar lo presenta tal cual al usuario para confirmación.
  • Ciclo de vida: Tras éxito en preparar, el Token A se destruye inmediatamente; tras éxito en generar, el Token B se destruye inmediatamente (un solo uso, evita reutilización); si la llamada a la API falla, se conserva el Token B permitiendo reintentar con el mismo token (sin necesidad de reconfirmación); los registros caducan y se limpian automáticamente tras 2 horas.
  • Bloqueo de parámetros: Las imágenes/tamaño/cantidad/modo de reescritura, etc., se bloquean en el registro durante optimizar; las fases posteriores los recuperan del registro, no se pueden alterar; generar solo puede usar -o para sobrescribir la ruta de salida.
  • Los archivos de imagen deben seguir existiendo en generar: optimizar solo verifica su existencia y guarda la ruta; generar lee el disco y lo convierte a data URI.

Normas de construcción del prompt

  • Paradigma de 6 pasos: Apertura y tono -> Recorrido espacial -> Escribir texto palabra por palabra -> Cinco elementos de detalle -> Restricciones de cierre -> Parámetros de formato y fotografía (ver references/best_practices.md).
  • Características de Qwen: Prefiere descripciones largas y visuales (límite de 4.5K tokens); prompt_extend está activado por defecto para mejorar promps cortos.
  • Texto en la imagen: Resaltar el contenido con comillas, especificar fuente/tamaño/color/posición, exigir renderizado palabra por palabra.
  • Edición/referencia: Escribir claramente "conservar X, solo cambiar Y"; en iteraciones, reafirmar las invariables para evitar desviaciones.
  • Tamaño: Usar ancho*alto (separado por asterisco, ej. 1920*1080); si no se especifica, el modelo lo recomienda automáticamente.
  • La guía completa de mejores prácticas y preguntas frecuentes está en references/best_practices.md; el análisis de la estructura de los 12 casos oficiales está en references/case_library.md; los parámetros de la API están en references/api_reference.md.

Índice de archivos de referencia

ArchivoContenido
references/best_practices.mdVisión general de las tres capacidades reales, 3 consejos oficiales, paradigma de prompt de 6 pasos, soluciones a problemas comunes, niveles de tamaño, recomendaciones de iteración
references/case_library.mdÍndice de clasificación de los 12 casos oficiales, análisis de estructura de prompts, técnicas clave, búsqueda rápida de modo a escenario
references/api_reference.mdPuntos finales de API, estructura del cuerpo de la solicitud, descripción de parámetros, cuerpo de la respuesta, campo usage, códigos de error
references/pricing_and_models.mdComparativa de modelos, tabla de precios, cálculo de costes, recomendaciones de selección
Qwen-Image-3.0官方最佳实践案例与完整提示词手册.mdTexto original oficial: 12 casos con prompts completos, consejos de uso, precios de API
scripts/generate_image.pyScript de generación en tres fases (optimizar/preparar/generar, T2I/I2I, biblioteca estándar pura, cadena de tokens de tres etapas forzosa con revisión+confirmación, anti-trabajo superficial, facturación automática)

Restricciones importantes

  • Seguridad de la clave: Leer solo de la variable de entorno DASHSCOPE_API_KEY; nunca escribirla en archivos del skill, nunca pedir la clave en texto plano al usuario en el chat. Si no está configurada, dar instrucciones y esperar.
  • No se pueden saltar las tres fases: Sin Token A de optimizar, preparar es rechazado; sin Token B de preparar, generar es rechazado; optimizar/preparar no llaman a la API, no consumen costes. El modelo no puede saltar de la solicitud original directamente a la generación.
  • Anti-trabajo superficial forzoso: optimizar debe registrar "comparativa antes/después + explicación de cambios" con contenido sustancial; preparar lo presenta tal cual al usuario para confirmación.
  • Presentación y confirmación forzosa: Tras optimizar, se debe mostrar al usuario "solicitud original -> prompt optimizado -> explicación de cambios" + plan de generación para confirmación; antes de esa confirmación, no se puede preparar/generar.
  • Clarificar antes de generar: Sin completar el primer paso (identificación y clarificación de intención), no se debe llamar al script.
  • Ubicación de salida: Por defecto se guarda en output/ dentro del directorio de trabajo actual; si la imagen es para el proyecto actual, moverla a una ubicación adecuada dentro del proyecto.
  • No sobrescribir: A menos que el usuario solicite explícitamente reemplazar, usar nombres de archivo con número de versión.
  • Caducidad de la imagen: La URL de la imagen devuelta por la API tiene una validez de 24 horas; el script ya la descarga automáticamente a local.

Preparación del entorno

  • Se debe configurar la variable de entorno DASHSCOPE_API_KEY (clave API de Alibaba Cloud Bailian).
  • Configuración temporal en PowerShell (introducir según indicación, la clave no entra en el historial de comandos): $env:DASHSCOPE_API_KEY = Read-Host -Prompt 'DASHSCOPE_API_KEY'
  • Configuración persistente: Escribir DASHSCOPE_API_KEY a través de la interfaz de variables de entorno del sistema, o usar setx y reiniciar la terminal. No escribir el valor real en archivos del repositorio.
  • Opcional DASHSCOPE_BASE_URL: Sobrescribe el punto final por defecto https://dashscope.aliyuncs.com (por ejemplo, si se usa un dominio específico del espacio de trabajo).
  • Obtención de la clave API: https://help.aliyun.com/zh/model-studio/get-api-key

Skills relacionados