Cómo escribir prompts para generadores de apps con IA (con ejemplos de antes y después)
Un buen prompt para un generador de apps con IA describe el producto, no el código: quién lo usa, qué hace paso a paso, qué datos guarda y quién puede ver cada cosa. Una vez que existe la primera versión, pide un cambio concreto por mensaje, indica qué debe seguir igual y describe los problemas como «hice X, esperaba Y, obtuve Z». Estos tres hábitos resuelven la mayoría de los resultados decepcionantes.
El resto de esta guía muestra los patrones en detalle, con ejemplos de antes y después que puedes adaptar.
Por qué pedir cosas a un generador de apps es distinto de chatear con una IA
Cuando haces una pregunta a un asistente de chat, un prompt vago da una respuesta vaga y tú pasas a otra cosa. Cuando pides algo a un generador de apps con IA, la respuesta es un programa en funcionamiento. Cada hueco en tu descripción se rellena con una suposición, y esas suposiciones se convierten en código, tablas de base de datos y pantallas con las que luego tienes que convivir o que tienes que deshacer.
Así que el objetivo de un prompt no es sonar inteligente. Es dejar menos decisiones importantes al azar. Para eso no necesitas vocabulario técnico. Necesitas ser concreto sobre lo que solo tú sabes: tus usuarios, tu flujo de trabajo y tus reglas.
Qué incluir en el primer prompt
Antes de escribir nada, responde a estas preguntas. Cada una cierra un hueco que la IA adivinaría de otro modo.
| Incluye | Por qué importa | Ejemplo |
|---|---|---|
| El producto en una frase | Marca el marco de todas las decisiones posteriores | «Una web de reservas para una barbería de dos sillones» |
| Quién lo usa | Decide las pantallas y el tono | «Clientes sin cita en el móvil, y el dueño en un portátil» |
| El flujo principal, paso a paso | Lo que debe funcionar primero | «Elegir un servicio, elegir una hora, introducir nombre y teléfono y recibir una confirmación» |
| Los datos que guarda | Se convierte en el diseño de la base de datos | «Servicios, reservas, clientes» |
| Quién puede ver o cambiar qué | Decide el inicio de sesión y los permisos | «Solo el dueño ve todas las reservas» |
| Aspecto y estilo, brevemente | Evita un estilo genérico por defecto | «Oscuro, sencillo, botones grandes» |
| Qué dejar fuera por ahora | Mantiene pequeña la primera versión | «Todavía sin pagos ni reseñas» |
La última fila se subestima. Decir lo que no quieres evita que la IA añada un blog, una página de precios y un formulario de newsletter que nunca pediste.
Antes y después: el primer prompt
Antes:
Hazme una app para mi gimnasio.
El generador tiene que adivinarlo todo: ¿socios o personal? ¿Clases o entrenamiento personal? ¿Pagos? Obtendrás algo que parece una web de gimnasio y no hace lo que necesitas.
Después:
Construye una app de reservas de clases para un pequeño estudio de yoga. Los socios ven las clases de esta semana (nombre, profesor, hora y plazas libres), reservan una plaza y pueden cancelar hasta dos horas antes. Los socios se registran con correo y contraseña. El dueño del estudio inicia sesión para añadir clases, ver quién tiene reserva y marcar la asistencia. Guarda clases, socios y reservas en una base de datos. Diseño tranquilo y claro que funcione bien en el móvil. Todavía sin pagos.
La segunda versión sigue siendo breve. Simplemente responde a las preguntas de la tabla de arriba.
Describe el comportamiento, no la implementación
A menudo obtendrás mejores resultados describiendo lo que debe ocurrir en lugar de cómo construirlo.
Antes:
Añade un useEffect que obtenga las reservas y un componente modal para editarlas.
Después:
Cuando el dueño pulse una reserva, abre un panel donde pueda cambiar la hora o cancelarla. Los cambios deben verse al instante en la lista.
El primer prompt obliga a la IA a usar una técnica concreta que quizá no encaje con la forma en que está construida la app. El segundo le indica el resultado y deja que elija el enfoque adecuado para el código que ya escribió. Si eres desarrollador y sí tienes una preferencia fuerte, dilo, pero acompáñala del resultado.
Sé concreto con las reglas
Las reglas de negocio son donde más suelen fallar las apps creadas con IA, porque para ti son obvias y para la IA son invisibles. Explícitalas.
- Límites: «Un socio puede tener como máximo tres reservas futuras».
- Plazos: «Las cancelaciones se cierran dos horas antes de que empiece la clase».
- Casos límite: «Si una clase está completa, muestra un botón de lista de espera en lugar de Reservar».
- Permisos: «Los profesores pueden ver la asistencia de sus propias clases, pero no la de otros profesores».
Cada una de estas reglas cabe en una frase. Si omites alguna, la app no la aplicará o inventará su propia versión.
Después de la primera versión: un cambio por mensaje
Cuando algo ya funciona en la vista previa, deja de describir el producto entero y pide cambios pequeños que puedas comprobar.
Antes:
El diseño no está bien, la reserva no funciona como debe y quiero una vista de calendario y correos.
Después (como cuatro mensajes separados):
- Cuando reservo la última plaza de una clase, la clase sigue mostrando «1 plaza libre». Debería mostrar «Completa» y ocultar el botón de Reservar.
- Añade en la página de horarios un calendario de vista semanal, con una columna por día. Mantén la vista de lista actual como opción.
- Haz las tarjetas de clase más compactas en el móvil: menos relleno y el nombre del profesor en la misma línea que la hora.
- Envía al socio un correo de confirmación cuando reserve.
Por qué funciona:
- Cada cambio es lo bastante pequeño para que la IA lo haga bien en una sola pasada.
- Puedes probar cada uno antes de pasar al siguiente.
- Si uno sale mal, puedes revertir solo ese paso sin perder los demás.
Indica qué mantener
Cuando pidas un cambio en algo que ya funciona, dile a la IA qué no debe cambiar. Es la forma más sencilla de evitar regresiones (cosas que funcionaban y se rompen tras una edición).
Rediseña la cabecera de la página de inicio con un titular más grande y una foto a la derecha. Mantén exactamente igual la navegación, los colores y todo lo que hay debajo de la cabecera.
Lo mismo vale para los datos: «Añade un campo de teléfono a los socios. No elimines ni renombres ningún campo existente».
Usa capturas y texto exacto
Frases como «la cosa de arriba» son ambiguas. La mayoría de los generadores de apps con IA aceptan imágenes, y una captura con una nota breve es más rápida que un párrafo de descripción.
- Adjunta una captura y di «el botón marcado en rojo se superpone al menú en los móviles».
- Pega el texto exacto de cualquier mensaje de error en lugar de parafrasearlo.
- Cita las etiquetas de pantalla tal cual: «el botón Guardar cambios de la página de Ajustes».
Para los errores, usa esta estructura:
En la página de reservas, pulsé Cancelar en una reserva de mañana. Esperaba que desapareciera de mi lista. En cambio, no pasó nada y la reserva sigue ahí tras recargar. Arréglalo y comprueba que cancelar funciona.
Nuestra guía sobre cómo depurar una app creada con IA profundiza en esto.
Planifica primero los cambios grandes
Para cualquier cosa que afecte a muchas partes de la app (añadir cuentas de usuario a una app que no tenía, añadir pagos o cambiar la forma en que se estructuran los datos), pide un plan antes de que se modifique ningún código.
Antes de cambiar nada, explica cómo añadirías cuentas de equipo: qué tablas nuevas, qué páginas cambian y qué pasa con los usuarios existentes. Todavía no edites código.
Lee el plan. Si ha malinterpretado algo, corregir un párrafo cuesta mucho menos que corregir una funcionalidad terminada. Muchos generadores tienen un modo específico para esto; en Mythex es el modo Plan, junto a Build y Ask.
Qué evitar
| Evita | Por qué | En su lugar |
|---|---|---|
| «Hazlo mejor» / «Haz que llame la atención» | No hay objetivo, así que la IA cambia cosas al azar | Nombra el cambio: «más espacio entre secciones, títulos más grandes» |
| Un prompt gigante con diez funcionalidades | Los errores se acumulan y es difícil de probar | Una funcionalidad por mensaje |
| Pegar claves de API en el chat | Las claves acaban en el historial del chat | Usa los secretos o los ajustes de entorno del generador |
| Discutir con un resultado roto | Cada arreglo se apila sobre el error | Revierte y luego reformula |
| Especificar código que no entiendes | Fija una solución que puede no encajar | Describe el comportamiento que quieres |
| Pedir una «seguridad de nivel empresarial» | No significa nada concreto | Enumera las reglas reales: quién puede ver qué |
Sobre las claves de API: si necesitas un servicio de pagos o de correo, guarda sus claves en los secretos del proyecto y no en el prompt. Consulta qué son las variables de entorno y los secretos si es un concepto nuevo para ti.
Plantillas de prompts reutilizables
Adáptalas sustituyendo las partes entre corchetes.
App nueva:
Construye un [tipo de app] para [quién]. Hacen [flujo principal, paso a paso]. [Segundo tipo de usuario] inicia sesión para [lo que hace]. Guarda [datos] en una base de datos. [Aspecto y estilo]. Deja fuera [cosas para más adelante].
Nueva funcionalidad:
Añade [funcionalidad] a [página]. Cuando [usuario] haga [acción], debe pasar [qué debe ocurrir]. Solo [quién] puede [hacerlo]. Mantén [cosas existentes] como están.
Cambio de diseño:
En [página], cambia [elemento concreto] a [cambio concreto]. Mantén [lo que hay que conservar]. Comprueba que se ve bien en una pantalla del ancho de un móvil.
Error:
En [página], hago [pasos]. Esperaba [lo esperado]. En cambio [lo que ocurre, más el texto exacto del error]. Arréglalo y verifica que el flujo funciona.
Pregunta sin cambios:
No cambies ningún código. Explica cómo funciona [parte de la app] y dónde se guardan [datos].
Escribir una especificación más larga
Para proyectos más grandes, puede ayudar escribir primero un resumen de una página y pegarlo como prompt inicial: los usuarios, los flujos principales, los datos, las reglas y lo que queda fuera. Incluso puedes pedir a una IA que te ayude a redactarlo; nuestra guía sobre cómo escribir un documento de requisitos de producto con IA explica cómo. Limita la primera petición de construcción al flujo principal y añade el resto paso a paso.
Pedir prompts en Mythex
Todo lo anterior funciona en Mythex. Algunos detalles que ayudan:
- Modos Build, Plan y Ask. Usa Plan para cambios grandes o arriesgados, y Ask cuando quieras una explicación sin ediciones.
- Puntos de control. Tras cada cambio correcto, Mythex guarda un punto de control, y Revert to this point en una respuesta devuelve el proyecto a ese estado. También puedes editar un mensaje anterior y reenviarlo para probar otro prompt desde ese punto.
- Tarjeta de secretos. Cuando el agente necesita una clave de API, la pide mediante una tarjeta en el chat, de modo que el valor se guarda como secreto del proyecto y no se escribe en tu mensaje.
- Imágenes. Adjunta capturas o maquetas y el agente las mirará.
La documentación tiene una breve página sobre prompts eficaces y otra sobre iterar sin reconstruir. Si empiezas desde cero, cómo crear una app con IA recorre un proyecto completo, y cómo diseñar una app con buen aspecto con IA trata los prompts para pulir el diseño visual.
Preguntas
¿Cuánto debe ocupar un prompt para un generador de apps con IA?
Para la primera versión, un párrafo corto de cuatro a ocho frases suele bastar: quién usa la app, el flujo principal, los datos que guarda y quién puede ver qué. Después, los prompts más cortos que piden un solo cambio cada vez funcionan mejor que los largos.
¿Debo indicar a la IA qué framework o lenguaje usar?
Solo si tienes un motivo, como un desarrollador que vaya a encargarse del código o un servicio que solo funcione con una determinada pila tecnológica. En caso contrario, describe el producto y deja que el generador elija valores por defecto razonables.
¿Por qué la IA sigue cambiando cosas que no le pedí cambiar?
Normalmente porque el prompt era demasiado genérico («hazlo mejor») o no indicaba qué mantener. Nombra exactamente lo que hay que cambiar, di qué debe seguir igual y pide un solo cambio por mensaje.
¿Es mejor arreglar un mal resultado con más prompts o empezar de cero?
Si el último cambio empeoró las cosas, vuelve a la versión anterior y reformula, en lugar de acumular arreglos encima. Empieza un proyecto nuevo solo cuando la idea en sí ha cambiado.