Cómo se escribe un prompt que sí funciona
Antes de los proyectos, esto. Todo lo demás en este sitio aplica lo que hay en esta página.
Un prompt “perfecto” no es el más largo ni el que intenta construir todo de una vez. Es una instrucción que reduce ambigüedades, produce un cambio comprobable y permite corregir el rumbo antes de continuar.
1. Antes de escribir prompts: requisitos
Si una de estas respuestas falta, el problema todavía no se resuelve agregando más adjetivos al prompt. Antes de abrir Horizons deberías poder responder:
- ¿Para quién es la página?
- ¿Qué acción principal debe completar esa persona?
- ¿Qué información necesita ver antes de actuar?
- ¿Qué datos se recopilan y cuáles son obligatorios?
- ¿Qué debe ocurrir después del envío?
- ¿Cómo sabremos que el resultado funciona?
- ¿Qué queda explícitamente fuera del proyecto?
Si no puedes responderlas todavía, empieza por el pre-brief y el Arquitecto de Proyectos IA: ese es exactamente su trabajo.
2. El método C.L.A.R.O.
Cada prompt lleva solo los bloques que necesita, pero el conjunto de prompts de un proyecto debe cubrir este marco:
| Letra | Bloque | Qué responde |
|---|---|---|
| C | Contexto | Quién usa el producto y qué problema intenta resolver. |
| L | Logro | Qué resultado observable debe producir esta iteración. |
| A | Alcance | Contenido, campos, comportamiento y límites del cambio. |
| R | Reglas | Diseño, accesibilidad, datos y aquello que no debe modificarse. |
| O | Observación | Criterios concretos para probar si la iteración quedó bien. |
CONTEXTO [Usuario, producto y problema.] LOGRO DE ESTA ITERACIÓN [Un solo resultado principal.] ALCANCE [Elementos o comportamientos que debe crear o modificar.] REGLAS [Restricciones, estados, datos que deben preservarse y fuera de alcance.] COMPROBACIÓN [Pruebas visibles y criterios de aceptación.]
3. Un prompt, un objetivo
Cada iteración responde una pregunta diferente:
- Estructura: ¿la página comunica bien?
- Interfaz: ¿el formulario pide lo correcto?
- Lógica: ¿previene errores y comunica sus estados?
- Backend: ¿guarda y notifica de verdad?
- Calidad: ¿funciona en distintos escenarios y tamaños?
Después de cada prompt se prueba el resultado. Si una prueba falla, se corrige esa iteración antes de agregar la siguiente capa.
La regla de las 3 funciones
Un prompt lleva un solo objetivo y como máximo 3 funciones o cambios. Si algo pide más, se parte en dos prompts en vez de alargar uno. Doce prompts cortos funcionan mejor que seis cargados: cada uno se puede probar por separado y corregir sin tocar lo que ya estaba bien.
Y nunca se mezclan capas dentro del mismo prompt: ni lo visual con la lógica, ni una pantalla nueva con su conexión a datos, ni dos pantallas a la vez.
El orden que sigue el curso
- 1. Base visual y navegación — paleta, tipografía, layout y menú. Sin contenido de pantallas.
- 2. Pantallas — una por prompt. Si tiene más de tres bloques: primero estructura y contenido, después los estados (vacío, carga, éxito, error).
- 3. Interacciones — máximo tres por prompt, y relacionadas entre sí.
- 4. Datos, usuarios e integraciones — separados: modelo de datos, guardado, lectura y permisos. Una integración externa va sola en su prompt.
- 5. Responsive, accesibilidad y SEO — un frente por prompt.
- 6. Pruebas y pulido — un prompt por defecto encontrado.
4. Cuando algo sale mal
No se vuelve a pedir el proyecto completo. Se describe el defecto con evidencia y se corrige solo esa causa:
En la versión actual ocurre este problema: [QUÉ OCURRE]. Lo reproduzco así: 1. [PASO 1] 2. [PASO 2] 3. [PASO 3] Resultado esperado: [RESULTADO]. Resultado actual: [RESULTADO]. Corrige únicamente esta causa. Conserva sin cambios: [FUNCIONES QUE YA ESTÁN APROBADAS]. Después de corregir, verifica: [PRUEBA CONCRETA].
5. Errores que esta metodología evita
- Pedir diseño, validación, datos, correo y pulido en un solo mensaje.
- Usar palabras subjetivas como “bonito” o “profesional” sin criterios.
- Cambiar toda la página para corregir un solo defecto.
- Conectar el backend antes de comprobar el formulario.
- Declarar “ya funciona” sin mirar la colección de datos y el correo.
- Publicar sin distinguir entre Test data y Live data.
6. Créditos de IA: la gasolina
Cada vez que Horizons crea, edita o corrige algo consume créditos de IA. El consumo es dinámico: una petición pequeña —cambiar un texto, ajustar un color— consume poco; crear una app completa, añadir muchas funciones o corregir varias cosas a la vez consume bastante más.
Mientras más clara y específica sea la solicitud, mejor se administran los créditos. Por eso el curso construye una versión simple, la prueba, corrige lo necesario y solo después mejora la apariencia.
Reintentar el mismo prompt amplio porque “no salió bien” es la forma más rápida de quemar créditos. Si un prompt falla dos veces, no lo repitas: divídelo en dos pasos más pequeños.