👁️ Fable 5 ve la pantalla, no solo el texto
🧠 Imagínalo así: llamas a un diseñador de conversión para que mire tu captura de pantalla y solo le dices: «hazlo más bonito». Va a cambiar el color del botón y se detendrá ahí. Ahora imagina que le dices: «cuéntame adónde va la mirada primero, qué confunde y qué frena la venta»; ese mismo diseñador te devuelve un diagnóstico de verdad. La diferencia no está en la herramienta, sino en el pedido.
Modelos con buena capacidad visual pueden analizar capturas de pantalla, fotos de interfaces, PDF de propuestas y piezas creativas del mismo modo que analizan texto: identificando jerarquías, puntos de atención, ruido y ausencias. Eso cambia el tipo de tarea que vale la pena delegar: no se trata solo de «generar texto sobre la imagen», sino de evaluar la imagen como lo haría un revisor capacitado.
El error más común es pedir poco: «hazlo más bonito», «mejora este diseño», «échale un vistazo a esto». Son solicitudes vagas que generan respuestas vagas: el modelo no sabe con qué criterio está evaluando, así que propone ajustes estéticos genéricos (color, espaciado) en vez de enfocarse en lo que realmente importa para tu objetivo: que la persona entienda y actúe.
El consejo 9 de esta ruta resuelve esto cambiando la solicitud vaga por una guía de auditoría: dónde se detiene la mirada primero, qué confunde, qué genera deseo, qué genera dudas, qué eliminar y qué cambiar para aumentar la conversión. Seis preguntas objetivas: el prompt listo viene en el próximo tema.
Lectura del diagrama: la misma captura, al pasar por las 5 preguntas correctas en vez de «hazla más bonita», se convierte en un informe con 6 puntos concretos para actuar.
En una frase: Fable 5 lee la pantalla como un revisor capacitado, pero solo te lo muestra si preguntas como preguntaría un revisor capacitado.
🔍 El prompt de auditoría visual, listo para copiar
🧠 Imagínalo así: este no es un fragmento de la documentación oficial de Anthropic: es una plantilla probada en la práctica, pensada para revisar interfaces, capturas de pantalla y creatividades. Adjunta la imagen y pega el texto de abajo junto con ella.
La idea es simple: en vez de describir lo que quieres con adjetivos ("más limpio", "más moderno"), describes el objetivo de negocio de la pieza — «hacer que una persona entienda rápidamente el valor de la propuesta» — y pide una lista fija de seis observaciones. Esto funciona para una landing page, una pantalla de app, un PDF de propuesta comercial, una publicación de anuncio o una captura de un dashboard.
Analise este print ou imagem. Compare com o objetivo: fazer uma pessoa entender rapidamente o valor da proposta. Diga: 1. onde o olho para primeiro; 2. o que está confuso; 3. o que gera desejo; 4. o que gera dúvida; 5. o que cortar; 6. o que mudar para aumentar conversão.
✗ "Hazlo más bonito"
- ✗Respuesta genérica de estética (color, espaciado)
- ✗No indica dónde se dirige la mirada ni qué confunde
- ✗Sin relación con la conversión ni con un objetivo real
✓ Guion de 6 preguntas
- ✓Señala un elemento específico de la imagen en cada punto
- ✓Distingue «confuso» de «genera dudas»: son cosas diferentes
- ✓Termina en acción: qué recortar, qué cambiar
En una frase: cambia «hazlo más bonito» por seis preguntas objetivas y convertirás una opinión vaga en una auditoría práctica.
🛡️ Pedir un exploit bloquea la respuesta; pedir una revisión defensiva, no
🧠 Imagínalo así: "enséñame a hackear este sistema" y "revisa este código en busca de fallas de seguridad" piden, en el fondo, que se observe el mismo problema, pero uno suena a una solicitud de ataque y el otro a una solicitud de defensa. Fable 5 reacciona de forma muy distinta a cada uno.
Cuando la solicitud se plantea como exploración o ataque — "cómo exploro esta falla", "dame el paso a paso para invadir" — el modelo puede clasificar esto como una solicitud de daño cibernético y negarse por completo, incluso cuando tu intención real es proteger el propio sistema.
Cuando el mismo tema se plantea como revisión defensiva — "busca errores, validaciones faltantes, exposición de datos" — el modelo entiende que el objetivo es proteger, no atacar, y entrega un análisis completo: riesgo, archivo afectado, causa probable, corrección. Es literalmente el mismo tema técnico, con un enfoque diferente en la entrada.
Esto no es un truco para «engañar» al modelo: es el encuadre correcto para quien realmente está cuidando un sistema propio o el de un cliente. El trabajo legítimo de ciberseguridad (pentest autorizado, auditoría, revisión de código) es diferente de pedir una receta de ataque genérica, y la forma en que redactas la solicitud es lo que se lo deja claro al modelo.
Lectura del diagrama: el mismo tema técnico, planteado como ataque, se bloquea; planteado como revisión defensiva, se convierte en un diagnóstico útil, sin exploit ni instrucciones paso a paso para atacar.
⚠️ Qué evitar al definir el enfoque
Pedir «paso a paso de ataque», «cómo escribir un exploit», «cómo hackear X» — incluso con buena intención — entra directamente en la categoría de rechazo que protege contra daños cibernéticos. El objetivo (proteger tu sistema) queda en segundo plano si el texto de la solicitud suena como una petición de ataque.
En una frase: mismo tema, enfoque diferente: el ataque bloquea; la defensa entrega el diagnóstico.
🔐 El prompt de revisión defensiva, listo para copiar
🧠 Imagínalo así: de nuevo, una plantilla probada en la práctica, no una cita oficial. Pégala junto con el código del servidor que quieres revisar.
El prompt de abajo pide explícitamente una revisión defensiva: errores, validaciones ausentes, problemas de autorización, exposición accidental de datos, fallas de configuración, riesgos operativos. Y termina con dos negaciones claras — nada de exploits, nada de instrucciones paso a paso para atacar — que refuerzan el enfoque del tema anterior.
Analiza mi código de servidor como una revisión defensiva. Busca errores, validaciones ausentes, problemas de autorización, exposición accidental de datos, fallas de configuración y riesgos operativos. No crees exploits. No muestres instrucciones paso a paso para atacar. Solo indica el riesgo, el archivo afectado, la causa probable y la corrección defensiva.
🔗 Cruce con la trilha 1
Este consejo se relaciona directamente con el módulo 1.6 de la ruta 1, que explica técnicamente la categoría de rechazo cyber con respaldo oficial de la documentación de Anthropic refusals-and-fallback:
"The request could enable cyber harm, such as malware or exploit development. Benign cybersecurity work can also trigger this category."
En otras palabras: incluso un trabajo legítimo de ciberseguridad puede activar esta categoría si la solicitud suena a ataque. El prompt de revisión defensiva anterior es literalmente la estrategia práctica para no activar ese rechazo — describe el mismo módulo 1.6 desde el punto de vista técnico/API; aquí está la versión aplicada, lista para copiar y pegar.
En una frase: pedir una revisión defensiva, con las dos negaciones explícitas, es la forma práctica de obtener un análisis de seguridad real sin encontrarse con un rechazo cyber.
🧭 Los dos consejos juntos: auditoría visual de un panel de administración
🧠 Imagínalo así: un dashboard interno mezcla ambos mundos — y una interfaz (consejo 9) que puede estar filtrando información sensible en la propia pantalla, y detrás de ella hay código de servidor que decide qué aparece allí (consejo 10). Auditar solo la interfaz o solo el código deja fuera la mitad del riesgo.
Un caso realista: tienes un panel de administración/dashboard interno y quieres saber si está exponiendo datos sensibles en la propia pantalla — correo electrónico completo de un cliente, token, clave de API, ID interno, campo de depuración olvidado en producción. Esto es al mismo tiempo un problema de interfaz (lo que ve el ojo) y un problema de seguridad (lo que el servidor decidió enviar al navegador).
Toma una captura del panel
Captura la pantalla tal como la vería una persona usuaria real: tablas, modales, paneles de depuración abiertos
Incluye pantallas con datos reales (o una copia enmascarada, si vas a compartirla fuera del equipo), no solo la pantalla vacía, y en los estados que realmente aparecen en el día a día.
Ejecuta el prompt de auditoría visual (consejo 9)
El mismo texto del tema 2, pero con un agregado
Además de las 6 preguntas estándar, pide explícitamente: "señala también cualquier dato que parezca sensible y no debería estar visible en esta pantalla (token, correo electrónico completo, clave, ID interno)".
Encuentra el código detrás de lo que apareció
Toda exposición en pantalla nace de una ruta o una query en el servidor
Si la auditoría visual señaló un dato sensible en la pantalla, localiza la ruta/endpoint que devuelve ese campo; normalmente es un SELECT * demasiado generoso o una respuesta de API sin filtro de permisos.
Ejecuta el prompt de revisión defensiva (consejo 10) en este archivo
El mismo texto del tema 4, aplicado solo al archivo sospechoso
El resultado combina ambos lados: «la pantalla X expone el campo Y (hallazgo visual) porque la ruta Z devuelve el objeto completo sin filtrar por permiso (hallazgo de código); corrígelo proyectando el DTO de respuesta».
Fíjate en que en ningún momento pediste «cómo explotaría un atacante este panel»: pediste claridad en la interfaz y una revisión defensiva del código. Precisamente esa combinación evita el rechazo y cubre el riesgo de punta a punta: desde la pantalla hasta la línea de código que la alimenta.
En una frase: la auditoría visual detecta lo que se filtra en pantalla; la revisión defensiva descubre por qué el código permitió que se filtrara — juntos, los dos consejos cubren todo el panel.
✅ Errores comunes y lista de verificación rápida
🧠 Imagínalo así: los dos consejos de esta lección casi siempre fallan por el mismo motivo: la solicitud quedó vaga o fue demasiado ofensiva. Este checklist es el antídoto rápido para ambos casos.
Antes de pegar cualquiera de los dos prompts, revisa estos puntos: son los errores que más hacen que el consejo 9 devuelva una opinión vaga o que el consejo 10 provoque un rechazo.
✗ Evita
- ✗"Haz que se vea más bonito" sin decir cuál es el objetivo de la pieza
- ✗Pedir la captura de pantalla sin adjuntar la imagen de verdad
- ✗"Enséñame a explotar/invadir X"
- ✗Pedir «paso a paso» de cualquier cosa relacionada con un ataque
- ✗Revisar solo la pantalla o solo el código, nunca ambos juntos
✓ Haz
- ✓Di cuál es el objetivo de la pieza + adjunta la imagen real
- ✓Usa las 6 preguntas fijas del consejo 9, siempre en ese orden
- ✓Enmarca la seguridad como «revisión defensiva», nunca como ataque
- ✓Cierra el prompt con las dos negaciones: sin exploit, sin paso a paso
- ✓En pantallas con datos, combina la revisión visual (consejo 9) con el código (consejo 10)
En una frase: un objetivo claro + una imagen real (consejo 9) y un encuadre defensivo + dos negaciones (consejo 10) resuelven casi todos los errores comunes de esta lección.
🧾 Resumen del Módulo
refusal categoría cyber; pedir una revisión defensiva del mismo tema ofrece un diagnóstico completo.Próximo módulo:
2.6 — Bucles con verificación + memoria externa: cómo convertir una revisión puntual en un ciclo continuo, con criterios, pruebas y lecciones registradas.