Los comentarios de los probadores solo sirven cuando cambian la app. Si creas sobre todo con prompts, el camino más corto desde la nota de un probador hasta una corrección pasa por un buen prompt. Un prompt vago da un cambio vago, y un cambio que no verificas puede romper otra cosa. Esta página te ofrece un ciclo que puedes repetir en cada ronda de comentarios.
El ciclo
- Recoger
- Priorizar
- Escribir el prompt
- Aplicar y leer el cambio
- Verificar en un dispositivo real
- Informar al probador
1. Recoge comentarios estructurados
Un "está roto" suelto es difícil de aplicar. Pide a los probadores siempre los mismos campos: qué hicieron, qué esperaban, qué pasó, dispositivo y versión del sistema. Un informe con esa forma se puede pegar en un prompt casi sin cambios. Consulta cómo escribir comentarios que un desarrollador pueda aplicar y la plantilla de informe de error.
2. Prioriza antes de escribir el prompt
No mandes diez informes al asistente de golpe. Ordénalos por impacto y esfuerzo (guía): primero los fallos y los flujos principales bloqueados, y los detalles al final. Trabaja con un problema por prompt. Los cambios pequeños son más fáciles de comprobar y de deshacer.
3. Escribe un prompt preciso
Un buen prompt lleva cuatro cosas:
- Contexto: qué pantalla o función, en una o dos frases.
- El informe: pasos, resultado esperado, resultado real, dispositivo y versión del sistema.
- El límite: "cambia solo lo necesario; no refactorices código no relacionado".
- Una comprobación: cómo sabrás que funciona, incluido un comportamiento cercano que debe seguir igual.
Versión para copiar y pegar: prompt de plantilla para corregir un error a partir de un informe.
Si no puedes reproducir el problema tú mismo, dilo en el prompt y pide al asistente que explique su suposición antes de cambiar código. No le pidas que "arregle todo lo que hay en este informe".
4. Lee el cambio
No hace falta entender cada línea, pero mira qué ha cambiado: qué archivos y cuántas líneas. Un error de una línea que produce un cambio en diez archivos merece una segunda mirada. Guarda cada corrección en su propio commit o punto de guardado para poder volver atrás.
5. Verifica en un dispositivo real
Repite los pasos exactos del informe en un teléfono real, idealmente del tipo que usó el probador. Después prueba el comportamiento cercano que marcaste como "debe seguir igual". El emulador es una primera pasada; el teléfono real es la prueba. Consulta por qué no basta un emulador.
6. Cierra el ciclo
Dile al probador qué cambiaste y pídele que lo vuelva a comprobar. Quienes ven usados sus comentarios suelen enviar mejores comentarios la siguiente vez. No afirmamos una tasa para eso; así los comentarios se convierten en un hábito y no en algo puntual.
Cuando la corrección no funciona
- El asistente "lo arregló", pero los pasos siguen fallando: envía el mismo informe otra vez con lo que observaste después del cambio.
- La corrección rompió otra cosa: revierte y añade el comportamiento roto a la línea de "debe seguir igual".
- Dos intentos sin avance: describe el problema con tus propias palabras, más corto y con menos contexto.
Lleva un registro corto
Una línea por informe: fecha, problema, dispositivo, prompt usado, resultado. Después de unas cuantas rondas verás qué tipos de informes producen correcciones limpias.
Dónde encaja AppReviewX
AppReviewX te da comentarios privados y estructurados de otros desarrolladores, en un formato que encaja con este ciclo. Un comentario que escribes te da un crédito, los créditos sirven para obtener comentarios sobre tu propia app, y las cuentas nuevas empiezan con 0 créditos.
Relacionado: centro de vibe coding, cómo conseguir tus primeras reseñas honestas en la tienda, motivos habituales de rechazo en la tienda, pruebas en dispositivo real.
Empieza gratis y pon el ciclo en marcha.