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 huellasha256del 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ón | ID del modelo | Enfoque | Precio por generación |
|---|---|---|---|
| Estándar (por defecto) | qwen-image-3.0 | Equilibrio calidad-velocidad, ideal para uso diario | 1K/2K ambos 0.18 yuan/imagen |
| Pro (opcional) | qwen-image-3.0-pro | Maquetación densa, detalles extremos, conocimiento profundo | 1K 0.25 yuan/imagen, 2K 0.50 yuan/imagen |
Capacidades clave del modelo ("Tres reales" oficiales):
| Capacidad | Descripción | Indicador clave |
|---|---|---|
| Contenido real | Cabe una página entera: exámenes, periódicos, guías ilustradas, infografías generadas en una sola vez | Longitud de instrucción aumentada a 4.5K tokens |
| Detalle real | Resiste el zoom: textura que se acerca a materiales reales | Texto pequeño de 10px legible, poros y cabellos visibles |
| Conocimiento real | Sabe de todo: multilingüe, multidisciplinar | Cubre 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.
- 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).
- Detallar en múltiples dimensiones (confirmar una por una si es vago, se puede usar
request_user_inputpara preguntas masivas o preguntas naturales; si ya es detallado, confirmar ligeramente):- 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
- 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.
- 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):
| Escenario | Versión recomendada |
|---|---|
| Pósteres cotidianos, ilustraciones, imágenes para redes sociales, prototipos de UI, generación por lotes | Estándar (por defecto) |
| Salida de alta resolución 2K sin necesidad de detalles extremos | Está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ías | Pro |
| 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 usuario | Caso de referencia | Enfoque del prompt |
|---|---|---|
| Maquetación de exámenes/documentos/informes | Caso 1 (Examen de lengua) | Descripción escaneando área por área + texto palabra por palabra |
| Fotografía macro / primer plano de producto | Caso 2 (Macro de bordado) | Fibra del material + momento de la acción + poca profundidad de campo |
| Notas manuscritas / fórmulas matemáticas | Caso 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 escenarios | Caso 4 (Composición de imagen de producto I2I) | Reglas de edición (extraer/ignorar/conservar/generar) |
| Diseño de personajes / consistencia multiángulo | Caso 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ías | Caso 6 (Mapa gastronómico) | Descripción por zonas + puntos numerados + sistema de leyendas |
| Menús / listas de precios | Caso 7 (Menú de Teochew) | Secciones por columnas + lista de platos + fotos incrustadas |
| Guías ilustradas de conocimiento / pósteres divulgativos | Caso 8 (Guía ilustrada de ruqun) | Descripción modular + personaje principal visual + módulos auxiliares |
| Infografías de movimiento vectorial / guías de recorridos | Caso 9 (Mapa de senderismo) | Estilo vectorial inglés + sistema de colores + puntos de ruta |
| Enseñanza histórica / infografías multilingüe | Caso 10 (Rebelión de An-Shi) | Modo bilingüe + formato apaisado panorámico + restricciones negativas |
| Retrato fotográfico comercial | Caso 11 (Retrato callejero italiano) | Narrativa de fondo multicapa + descripción muy detallada de la persona + efecto de película |
| Retrato fotográfico con iluminación | Caso 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 enQwen-Image-3.0官方最佳实践案例与完整提示词手册.md.
3.2 Elegir el modo (según el objetivo)
| Objetivo | Modo | Llamada |
|---|---|---|
| Creación desde cero, sin imágenes de referencia | Texto a imagen T2I | Solo prompt, no pasar --image |
| Conservar/extender el personaje o contenido de una imagen existente | Imagen a imagen I2I | Prompt + 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):
- 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..."
- 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.
- 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.
- 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.
- 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. - 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
optimizarde 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/generarantes de la confirmación del usuario. La verificación de código no valida si "el usuario realmente ha visto", peropreparardebe depender de un Token A deoptimizarvá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
optimizary se bloquean; no se pueden alterar en la fasepreparar. - 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 ->
optimizarde 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).optimizarsolo 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;generarsolo puede usar-opara sobrescribir la ruta de salida. - Los archivos de imagen deben seguir existiendo en
generar:optimizarsolo verifica su existencia y guarda la ruta;generarlee 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_extendestá 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á enreferences/case_library.md; los parámetros de la API están enreferences/api_reference.md.
Índice de archivos de referencia
| Archivo | Contenido |
|---|---|
references/best_practices.md | Visió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.md | Puntos 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.md | Comparativa de modelos, tabla de precios, cálculo de costes, recomendaciones de selección |
Qwen-Image-3.0官方最佳实践案例与完整提示词手册.md | Texto original oficial: 12 casos con prompts completos, consejos de uso, precios de API |
scripts/generate_image.py | Script 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,preparares rechazado; sin Token B depreparar,generares rechazado;optimizar/prepararno 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:
optimizardebe registrar "comparativa antes/después + explicación de cambios" con contenido sustancial;prepararlo 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 puedepreparar/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_KEYa través de la interfaz de variables de entorno del sistema, o usarsetxy reiniciar la terminal. No escribir el valor real en archivos del repositorio. - Opcional
DASHSCOPE_BASE_URL: Sobrescribe el punto final por defectohttps://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