Recuperar cuando un cambio rompe una compilación que funcionaba
Restaurar el último comportamiento funcional, conservar el buen trabajo reciente y los datos del cliente, y luego volver a aplicar solo el cambio que deseaba.
Cuándo usarlo
Cuando la aplicación funcionaba, solicitó un cambio y ahora una página o flujo importante está roto, aunque desea conservar las partes útiles del trabajo reciente.
Antes de empezar
- Deje de enviar más solicitudes de reparación hasta que identifique la última versión que definitivamente funcionaba.
- El cambio reciente que provocó el problema, copiado con la mayor precisión posible.
- La fecha, hora o descripción de la versión que se sabía que funcionaba por última vez.
- Una lista corta de lo que aún funciona, lo que se rompió y qué nuevo trabajo útil desea conservar.
- Cuentas de prueba seguras y registros de prueba para el flujo afectado.
- Una exportación o registro escrito de cualquier información real del cliente añadida desde la última versión funcional. Nunca experimente con la única copia.
El prompt
Estos prompts funcionan mejor en inglés — pégalos tal como están, incluso en páginas traducidas.
Recover this app after [RECENT CHANGE OR PROMPT] broke [EXACT BROKEN BEHAVIOR]. Restore the working behavior without discarding [GOOD NEW WORK TO KEEP] or losing customer information added since [LAST KNOWN WORKING VERSION OR TIME]. Do not make another broad change yet. Compare the current version with the last known working version available in this platform's history. List what changed in the affected page, shared elements, login, stored information and external connections. Separate evidence you can see from guesses. Create a recovery plan with three outcomes. Restore [PREVIOUSLY WORKING FLOW]. Preserve [GOOD NEW CONTENT OR FEATURE]. Reapply only [THE INTENDED PART OF THE RECENT CHANGE] after the app is stable. Tell me which outcome can be completed safely and which needs my decision. Treat the app's pages and behavior separately from live customer information. Restoring an earlier visual or app version must not silently erase, replace or expose accounts, bookings, orders, messages, uploads or payments created afterwards. If the platform's restore action may affect stored information, connection settings or permissions, stop and explain the risk before using it. Use the platform's actual version-history, revert or deployment-rollback control when a restore is needed. Do not pretend that writing the word revert in chat has undone the change. Preview the last working version first where the platform allows it. Restore a safe working version or repair the smallest confirmed cause. Then test [BROKEN FLOW] with safe data, plus sign-in, the main navigation, [IMPORTANT FORM OR PAYMENT], the phone layout and one nearby feature that was not broken. Confirm that information added after the last working version is still present. Only after those checks pass, reapply [INTENDED CHANGE] as a narrow change that does not touch [AREAS TO PROTECT]. Test the old working flow and the new change together. If they conflict, keep the stable version and show me the decision instead of forcing both. Do not delete stored information, reset the app, replace the login system, change payment keys or remove access rules. Keep the repair surgical and the explanation calm. Finish with what was restored, what was preserved, what was reapplied and what I should test on the published site.
¿Ya estás creando? Pega esto en tu proyecto. ¿Empiezas de cero? Abre una cuenta gratuita en un creador compatible a continuación.
Créalo en
Qué crea esto
- Una comparación entre la versión rota y la última versión funcional
- Un plan de recuperación que separa la restauración, la preservación y la reaplicación
- Un retroceso seguro o una reparación estrechamente dirigida
- Verificaciones para el flujo reparado, las funciones cercanas y la información reciente del cliente
- Una reaplicación controlada solo del cambio previsto
- Un registro de recuperación en lenguaje sencillo para problemas futuros
Comprueba que funcionó
Pega el prompt, espera a que termine la construcción y luego confirma esto — en lenguaje sencillo, sin comprobaciones técnicas:
- La acción que funcionaba antes del cambio vuelve a funcionar con datos de prueba seguros
- El nuevo texto o función útil que nombró sigue presente, o está claramente guardado para su reaplicación
- Las cuentas de clientes, reservas, pedidos, mensajes y archivos cargados después de la versión funcional siguen ahí
- El inicio de sesión, la navegación y la función cercana que probó siguen funcionando
- El nuevo cambio limitado funciona sin romper el flujo restaurado
- El sitio publicado muestra la versión funcional aprobada, no solo la vista previa del editor
- Recibe un informe claro de lo que se restauró y de todo lo que se dejó sin cambios deliberadamente
¿Falta algo? Es normal — pídelo en un mensaje corto de seguimiento en vez de volver a ejecutar todo el prompt.
Siguientes pasos
Reaplicar el cambio útil de forma segura
Después de que el comportamiento funcional anterior se haya restaurado y verificado
Reapply only this part of the change: [EXACT DESIRED RESULT]. Protect [WORKING FLOW, DATA AND PAGES] from modification. Show me the smallest planned change first, then implement it and retest both the restored behavior and the new result.
Sabrás que funcionó cuando: La mejora deseada está presente mientras el flujo recuperado sigue superando la misma prueba.
Añadir una comprobación para el comportamiento defectuoso
Una vez que la recuperación es estable
Add a repeatable safe test for this rule: [WHAT MUST NEVER BREAK AGAIN]. Use test data only. Run it after the current version and explain in plain language how I can ask for the same check after future changes.
Sabrás que funcionó cuando: La prueba pasa ahora y proporciona un fallo claro si el mismo error vuelve a ocurrir.
Registrar la recuperación para la próxima vez
Después de confirmar que el sitio en vivo funciona
Create a short recovery note containing [CHANGE THAT CAUSED THE BREAK], [VISIBLE SYMPTOM], [CONFIRMED CAUSE], [VERSION RESTORED OR FIX APPLIED], [DATA CHECKED] and [FINAL TESTS]. Keep it private to the owner and do not include passwords, payment details or connection keys.
Sabrás que funcionó cuando: El propietario tiene un registro privado y legible que hace que un problema recurrente sea más rápido de diagnosticar.
Ojo con
- Más solicitudes de reparación pueden enterrar el último buen estado. Deténgase después de la primera regresión clara e inspeccione el historial antes de solicitar otra corrección amplia.
- Una solicitud de chat para revertir puede no realizar una reversión real. Utilice el control de revertir, el historial de versiones o el control de implementación visibles de la plataforma y confirme qué versión está activa.
- La restauración de páginas puede no restaurar la información almacenada de la misma manera. El código, el diseño, los datos y la configuración externa pueden tener historiales separados. Nunca asuma que una reversión visual revierte de forma segura un cambio de datos.
- Una reversión en vivo puede restaurar a los visitantes rápidamente sin arreglar el borrador. Confirme tanto lo que ve el público como qué versión seguirá editando.
- El buen trabajo reciente necesita un inventario. Anote el texto, las funciones y los registros que vale la pena preservar antes de volver a una versión anterior.
- El cambio original puede entrar genuinamente en conflicto con el comportamiento anterior. Si ambos no pueden coexistir de forma segura, mantenga la versión estable y haga que el compromiso sea explícito.
Notas por plataforma
<ul><li><strong>Base44:</strong> Utilice el control de revertir (Revert) o el historial de versiones (Version History). Base44 puede previsualizar una versión anterior, restaurarla en el editor o publicar una versión anterior mientras mantiene el borrador actual, lo cual es útil para restaurar la aplicación en vivo antes de reparar el borrador.</li><li><strong>Lovable:</strong> Lovable permite previsualizar y revertir a versiones anteriores del proyecto. Es posible que una reversión de versión no revierta todos los cambios en los datos almacenados, por lo que debe inspeccionar los datos y los permisos por separado antes de asumir que toda la aplicación ha vuelto al estado anterior.</li><li><strong>v0:</strong> Un proyecto v0 implementado en Vercel puede devolver la producción a una implementación anterior. Eso restaura lo que ven los visitantes, pero el código fuente del proyecto y cualquier dato conectado aún necesitan una revisión por separado a través del historial del proyecto o la copia de seguridad de GitHub conectada.</li></ul>
Gasta menos créditos
Toda plataforma te cobra por el trabajo que hace su IA — así que el hábito más barato es pensar antes de construir. Estas seis reglas eliminan la mayor parte del desperdicio, elijas la plataforma que elijas.
- Planifica primero en un chat gratuito. Esboza todo en ChatGPT, Claude o Gemini — páginas, funciones, qué recoge cada formulario, cómo debe verse. Pensar allí es gratis; pensar dentro de un builder se factura.
- Empieza con un prompt escrito, no con una frase. "Hazme una web" es la frase más cara al construir con IA. Un primer prompt completo — como los de este sitio — ahorra decenas de rondas de corrección.
- No seas perezoso con los detalles. Cada detalle que omites vuelve como una corrección que pagas. Nombre del negocio, colores, cada página, cada campo del formulario, qué pasa tras el envío — ponlo todo en el primer prompt.
- Después, un cambio por mensaje. "Arregla la cabecera, y el formulario, y los colores" produce un enredo que cuesta más deshacer de lo que ahorró.
- ¿Atascado? Deja de parchear. Si la misma corrección falla unas tres veces, no envíes una cuarta — describe el estado final deseado de toda la sección en un mensaje nuevo.
- Empieza gratis. Mejora el plan cuando necesites más. Usa la cuota gratuita para crear y explorar tu primera versión. Mejora el plan cuando necesites más uso o funciones de pago, y revisa el coste de los servicios conectados antes del lanzamiento.
Los prompts de esta página están escritos para hacer casi todo este trabajo por ti — de eso se trata.
Lee la guía completaPlaybooks relacionados
Revisado el: 2026-07-27