Cómo usar Qwen 3.5 de forma eficaz: patrones de prompts para escribir, programar e investigar

¿Qué necesita Qwen 3.5 para pasar de una respuesta que suena bien a un resultado que puedas utilizar? Un artículo con datos comprobables, un cambio de código que puedas revisar y un resumen que respete sus fuentes exigen algo más que pedirle que «lo haga bien».

La pregunta práctica es esta:

¿Puede Qwen 3.5 producir respuestas fiables y bien estructuradas cuando la tarea tiene requisitos reales, o empieza a perder el hilo en cuanto se complica?

La respuesta depende mucho de cómo plantees la tarea, aunque el prompt no lo resuelve todo. También importan el modelo concreto, las fuentes, las herramientas disponibles y la revisión posterior. La ficha de Qwen3.5-397B-A17B describe una arquitectura de mezcla de expertos —MoE— con 397.000 millones de parámetros en total y 17.000 millones activos. Esa capacidad no garantiza que cada respuesta sea correcta.

Vamos a ver cómo dividir el trabajo, limitar lo que puede inventar y comprobar los resultados sin convertir cada petición en un documento interminable.

Cómo acceder a Qwen 3.5: las opciones habituales

Conviene distinguir Qwen3.5-Plus, disponible mediante la API alojada de Alibaba Cloud Model Studio, de Qwen3.5-397B-A17B, cuyos pesos puedes descargar para desplegarlo por tu cuenta o utilizar a través de un proveedor.

También hay que separar el modelo de la aplicación con la que lo usas. Qwen Chat es una interfaz de conversación; Qwen Code es un asistente de programación que puede conectarse a distintos modelos y servicios.

Estas son las vías principales, con las condiciones de acceso revisadas el 11 de noviembre de 2026:

La configuración de Qwen3.5-Plus en Model Studio confirma la ventana de un millón de tokens. Para el modelo de pesos abiertos, la ficha distingue 262.144 tokens nativos de una ampliación que requiere configuración adicional. No son límites intercambiables.

En OpenRouter, los precios de entrada y salida se muestran por separado. Y hay una corrección importante para Qwen Code: su antigua cuota gratuita mediante OAuth terminó el 15 de abril de 2026, según sus condiciones de acceso y autenticación. No cuentes con las antiguas 1.000 peticiones gratuitas al día para calcular el coste de un proyecto nuevo.

Sea cual sea la vía, un resumen puede ser fluido y contener errores de hecho. Cuando eso ocurre, conviene revisar tanto las fuentes como la petición, en vez de atribuir el problema únicamente al modelo o al prompt.

Prompts de escritura para reducir las alucinaciones

Un error habitual con Qwen 3.5, como con otros modelos, es tratar una respuesta generada como si fuera una búsqueda verificada. Si no has aportado fuentes ni utilizado una función de búsqueda, no puedes dar por hecho que haya comprobado los datos.

La API de Qwen3.5-Plus admite búsqueda web en determinadas regiones, pero que la función exista no significa que esté disponible o activada en cada petición. Para escribir con datos, empieza por aclarar qué información puede utilizar y qué necesita verificación.

Primero la estructura

En lugar de pedir el artículo entero de una vez, solicita un esquema y desarrolla después cada apartado. Así puedes corregir el enfoque antes de revisar páginas de texto que no van por donde querías.

En vez de esto:

Escribe un artículo de 1.500 palabras sobre buenas prácticas
para gestionar equipos en remoto.

Prueba con esto:

Tarea: escribir un artículo de 1.500 palabras sobre la gestión
de equipos en remoto.

Paso 1: propón un esquema de 5 apartados, con una frase que explique
qué cubrirá cada uno.
No escribas todavía el artículo completo.
Espera mi aprobación antes de continuar.

Cuando el esquema encaje, pide cada apartado por separado:

Ahora escribe solo el apartado 2:
[pega el título y la frase descriptiva del esquema aprobado].

Limítate a 250 palabras.
Utiliza un ejemplo concreto de una empresa real si resulta pertinente.

Trabajar por bloques facilita comprobar si cada sección cumple su función y reduce la cantidad de texto que hay que rehacer cuando cambia el enfoque. No garantiza que el modelo deje de desviarse.

Ojo con el ejemplo de la empresa: pedir que sea real no demuestra que lo sea. Si vas a publicarlo, aporta una fuente o comprueba después tanto el caso como la interpretación que hace el modelo.

Prompts con restricciones claras

Pedir contraejemplos, señalar incertidumbres y solicitar una revisión final puede ayudarte a detectar problemas. El contexto debe ser breve, pero suficiente: objetivo, límites y referencias necesarias.

Un bloque de restricciones al principio de la petición puede tener esta forma:

RESTRICCIONES:
- Extensión máxima: 300 palabras.
- Tono: directo, sin jerga.
- NO inventes estadísticas. Si mencionas una cifra, márcala con
  [PENDIENTE DE VERIFICACIÓN].
- Si no estás seguro, di «No estoy seguro de este dato» en lugar de adivinar.

La última instrucción deja claro que una duda reconocida es preferible a una respuesta inventada. Aun así, ni una frase prudente ni una puntuación de confianza del propio modelo sirven como prueba de exactitud. Las cifras y afirmaciones importantes necesitan una comprobación externa.

Un proceso de programación útil: planificar → modificar → verificar

En una canalización de datos en Python, un extractor web sencillo o un transformador de JSON, una respuesta puede parecer correcta y romper un caso que no habías considerado. La capacidad para generar código no sustituye a un cambio bien delimitado.

El proceso que recomiendo es planificar → modificar → verificar: acordar qué debe cambiar, revisar el parche y ejecutar las pruebas antes de darlo por bueno.

Primero el diff, después las pruebas

Pedir una reescritura completa puede dejarte con doscientas líneas nuevas que revisar para resolver un problema pequeño. Si la función ya hace casi todo lo que necesitas, pide únicamente el cambio.

Esta es mi función actual:
[pega el código existente]

Necesito que también gestione una entrada vacía sin lanzar una excepción:
debe devolver una lista vacía.
NO reescribas toda la función.
Muestra SOLO las líneas que cambian, en formato diff unificado.

Un fragmento ilustrativo del cambio sería:

-    if not data:
-        raise ValueError("Input cannot be empty")
+    if not data:
+        return []

Es un cambio pequeño y fácil de examinar, no una garantía de que puedas aplicarlo sin revisar. Comprueba qué valores admite data y qué considera vacíos la condición if not data. Para aplicar un parche como diff unificado completo también hacen falta las cabeceras y el contexto correspondientes.

Después añade una condición de verificación:

Después del diff, escribe una prueba unitaria con pytest que cubra
el nuevo comportamiento.
La prueba debe fallar con el código ANTIGUO y pasar con el código NUEVO.

Esto te da una forma concreta de comprobar el caso que quieres corregir. Pero pedir una prueba no equivale a ejecutarla: comprueba el fallo en la versión anterior, el resultado en la nueva y que las pruebas existentes sigan pasando. Una prueba que pasa solo acredita lo que realmente comprueba.

Plantilla para investigar: esquema → fuentes → síntesis

La ventana de hasta un millón de tokens de Qwen3.5-Plus permite trabajar con documentos largos. No garantiza que el modelo encuentre todos los detalles relevantes ni que conserve cada matiz. Para una investigación, importa tanto lo que puede leer como la manera en que relaciona las respuestas con las fuentes.

Puedes dividir la petición en tres fases.

Fase 1: identifica lo que necesitas averiguar.

Tema: [tu pregunta de investigación]

Antes de responder, enumera las 5 subpreguntas más importantes
que tendrías que resolver para dar una respuesta completa.
No las respondas todavía.

Fase 2: limita la síntesis a las fuentes aportadas.

Estos son 3 documentos relevantes para el tema:
[pega los fragmentos]

Responde a cada una de las 5 subpreguntas de la fase 1 utilizando
SOLO información de los documentos proporcionados.
Si los documentos no abordan una subpregunta, escribe:
«No se trata en las fuentes».

Fase 3: localiza las lagunas.

A partir de las respuestas anteriores, ¿qué subpreguntas siguen
teniendo incertidumbres importantes o información insuficiente?
¿Qué tipo de fuente permitiría resolver cada laguna?

Esta secuencia ayuda a separar lo que aparece en los documentos de lo que falta por investigar. La tercera fase es especialmente útil: un resumen puede parecer completo simplemente porque está bien escrito.

Antes de publicarlo, contrasta las conclusiones con los pasajes que las respaldan. La instrucción «usa solo estas fuentes» limita la tarea, pero no impide por sí sola que el modelo añada una inferencia o interprete mal un fragmento.

Cómo mejorar los prompts: lleva un registro y cambia una sola variable

Si cambias el tono, el formato, las fuentes y la extensión a la vez, será difícil saber qué ha mejorado la respuesta. Un registro sencillo permite comparar intentos sin depender de la memoria.

Puede bastar con un archivo de texto por proyecto. Este es un ejemplo ilustrativo, no el resultado de una prueba medida:

[2026-02-18] Intento 1
Prompt: [pega la petición]
Calidad de la respuesta: 3/5
Problemas: ha inventado una estadística en el apartado 2.

[2026-02-18] Intento 2
Cambio: añadida la restricción [PENDIENTE DE VERIFICACIÓN].
Calidad de la respuesta: 4/5
Problemas: la conclusión sigue siendo demasiado larga.

Una variable por iteración. Mantén tareas representativas de tu trabajo y compara las respuestas con los mismos criterios: exactitud, cobertura, formato, datos sin respaldo y tono. Si utilizas una escala, define qué significa cada nota para que la comparación sirva de algo.

Hay tres cambios que merece la pena observar por separado:

1. Especificar el formato de salida. Indicar los campos o la estructura esperados facilita detectar desviaciones. Si una aplicación consume la respuesta, valida también ese formato fuera del modelo.
2. Asignar un papel cuando aporte algo. «Eres un desarrollador de Python que escribe código defensivo» puede orientar una tarea técnica. Para un texto general, quizá sea más útil describir al lector y el tono que añadir un cargo que vuelva la redacción innecesariamente formal.
3. Pedir una revisión final. Puede señalar contradicciones o detalles dudosos, pero no es una comprobación independiente. Revisa las fuentes y ejecuta las pruebas que correspondan.

No hace falta atribuir a estos cambios un porcentaje universal de mejora. Lo que necesitas saber es si funcionan en tus tareas, con el modelo, las herramientas y la configuración que utilizas.

Para obtener respuestas más fiables, empieza por hacer visible el trabajo: qué debe producir el modelo, en qué información puede apoyarse y cómo comprobarás el resultado. Si sigue fallando, el registro te ayudará a distinguir una petición poco clara de una limitación del modelo o de las herramientas.

Si además buscas una IA personal que recuerde el contexto que compartes y te ayude a convertir una necesidad cotidiana en una pequeña app, Macaron propone ese tipo de experiencia. Eso es distinto de ejecutar una cadena de tareas con Qwen 3.5: no debe darse por hecho que Macaron se conecte a ese modelo o valide automáticamente sus resultados.

Puedes probar Macaron con una tarea concreta y valorar el resultado, sin contratar una suscripción para empezar a usar sus funciones básicas. Comparte solo la información necesaria y revisa las opciones de privacidad antes de añadir contenido sensible. Para código e investigación, conserva las comprobaciones anteriores: un contexto recordado no sustituye a una prueba ejecutada ni a una fuente leída.

Artículos Relacionados

• 15 prompts de Gemini Personal Intelligence para aprovechar tus datos de Google
• Inyección de prompts en DeepSeek V4: patrones de seguridad para asistentes de código
• ¿Es segura la app Macaron? Privacidad, permisos y uso de datos
• ¿Kimi AI es gratis? Precios, acceso y qué incluye en 2027
• Cómo descargar e instalar la app de Codex en macOS (guía de 2027)