Cursor no necesita un prompt bonito: necesita contexto
Cursor es un editor con IA sobre un repositorio real. La diferencia con un constructor tipo Lovable o Bolt es que aquí el valor no está en generar la app entera desde cero, sino en cambiar código existente sin romper lo que ya funciona. Y para eso el contexto pesa más que la redacción.
Al empezar la sesión conviene gastar un mensaje en contar el proyecto: qué es la aplicación, para quién, el stack, cómo están organizadas las carpetas, las convenciones (nombres, estilos, idioma de la interfaz) y qué no se debe tocar. Todo lo que sigue en la sesión hereda ese contexto.
Los tres niveles de prompt en Cursor
- Nivel proyecto. El mensaje de apertura. Define stack, estructura, convenciones y límites. No pide cambios: prepara la sesión.
- Nivel cambio. Una petición por cosa. «En src/pages/Invoice.tsx, cuando el IVA es 0 el total sale NaN; debe mostrar el subtotal».
- Nivel criterio. Qué significa estar bien y qué está prohibido. «No añadas librerías nuevas», «no cambies el esquema de la base de datos», «los textos van en español».
Plantilla para pedir un cambio en Cursor
Fíjate en que son tres frases: situación, cambio y límite. Es la estructura que menos diffs provoca y la que menos veces obliga a deshacer.
Errores que cuestan una tarde
- Pedir tres cosas en un mensaje. Cursor edita ficheros mientras trabaja: si el resultado no te gusta, no sabes qué parte rechazar.
- No nombrar el fichero. «Arregla el login» en un proyecto de 200 ficheros es una invitación a que toque el que no era.
- No decir qué no tocar. Sin límite, el modelo «limpia» cosas que ya funcionaban.
- Aceptar diffs sin leerlos. Diez segundos de lectura ahorran una tarde de depuración.
- Crear el proyecto con IA sin una spec. Cursor acelera a quien ya sabe qué quiere construir; no decide el producto por ti.
Cursor para quien no programa
Se puede, con expectativas realistas: instalar el editor, abrir una carpeta y describir cambios es asumible. Lo que no desaparece es entender qué estás cambiando: carpetas, terminal y leer código siguen ahí. Si el objetivo es publicar una idea esta semana sin tocar código, empieza por Lovable o Bolt.new y pasa a Cursor cuando el proyecto pida más control.
Sigue con el generador
Preguntas frecuentes
¿Cómo se escribe un buen prompt para Cursor?
En tres niveles: un mensaje de proyecto al abrir la sesión (stack, estructura, convenciones), una petición por cambio con el fichero y el comportamiento esperado, y un límite explícito de qué no se debe tocar.
¿Cuál es la mejor forma de promptar Cursor para cambios pequeños?
Un cambio por mensaje, nombrando el fichero y describiendo el antes y el después. Los cambios pequeños generan diffs pequeños, y un diff pequeño se revisa o se rechaza sin arrastrar media app.
¿Sirve Cursor si no sé programar?
Sirve, pero no elimina el hecho de que trabajas sobre código: hay carpetas, una terminal y ficheros que conviene leer. Como primer paso, un constructor en el navegador es más rápido; Cursor es mejor segunda herramienta.
¿Qué diferencia hay entre Cursor y Lovable para construir una app?
Lovable genera la app completa en el navegador con Supabase y hosting; Cursor es un editor con IA sobre código que ya existe. Lovable para llegar antes a algo que enseñar; Cursor para mantener y ampliar lo construido.
¿Cómo evito que Cursor cambie cosas que ya funcionan?
Diciéndolo en el mensaje: «no toques X». Y revisando el diff antes de aceptar. Añadir también las convenciones del proyecto al contexto de la sesión reduce toques innecesarios.
¿Es gratis este generador de prompts para Cursor?
Sí, gratis y sin registro, con un límite de 8 prompts por hora por IP. No hace falta cuenta ni tarjeta para usarlo.