Por qué está escrito así
Cuando le pides a una IA que diseñe una base de datos, suele arrojar una docena de tablas de golpe. Aunque a primera vista parece completo, no hay espacio para entender por qué cierta columna está en cierta tabla, y para detectar errores tienes que revisar veinte definiciones desde cero.
Por eso, dividimos la tarea en pasos claros: Entidades → Relaciones → Definición técnica. Si en el Paso 1 ves que "Reserva" e "Historial de atención" están mezclados en una sola entidad, puedes corregirlo de inmediato y los siguientes pasos se construirán sobre premisas válidas. Si no le indicas explícitamente que se detenga tras cada paso, la IA escribirá todo junto en una sola respuesta.
Incluir una fase de preguntas de clarificación es vital porque el diseño cambia según ciertas reglas de negocio. Por ejemplo, si al cancelar una reserva el registro se elimina o cambia de estado, o si un usuario puede gestionar múltiples locales. Una IA que no pregunta asumirá esto por su cuenta. Limitarlo a 3 preguntas evita debates interminables.
En cuanto al formato, exigir tipos de datos y restricciones por columna asegura que la tabla esté lista para implementar en código. Un diseño sin claves primarias o foráneas claras falla en cuanto intentas migrarlo. Además, la instrucción de no inventar tablas adicionales evita que la IA agregue tablas innecesarias de notificaciones, logs o etiquetas por costumbre.
¿Términos desconocidos? Consulta Aha AI: prompt, chain-of-thought
Comparado con un mal ejemplo
Quiero hacer una app de reservas para peluquería, diséñame las tablas de la base de datos.
La IA generará diez tablas y columnas técnicas de una sola vez sin contexto. El problema es la imposibilidad de validar: puede incluir tablas no solicitadas como niveles de membresía, puntos o cupones que parecen útiles pero ensucian el MVP, mientras olvida dónde guardar los no-shows. Si corriges un campo después, todas las relaciones se desajustan.
Variaciones
Para auditar un diseño existente
Revisa el diseño de tablas en {{base de datos}} que acabamos de crear y señala únicamente los posibles problemas o cuellos de botella. Organízalo en una tabla con las columnas: "Ubicación | Problema detectado | Cuándo fallará | Cómo solucionarlo", ordenado por severidad y con un máximo de 5 puntos. No hagas observaciones sobre convenciones de nombres o preferencias de estilo.
Úsalo dentro de la misma conversación tras obtener el diseño. Sin el límite de "máximo 5" o "sin cuestiones de estilo", la respuesta se llenará de detalles menores ocultando los fallos críticos de integridad.
Diseño guiado desde la interfaz de usuario
Estoy desarrollando el siguiente servicio: {{descripción del servicio}}. Lee la lista de funciones que aparece abajo y ayúdame a identificar qué datos deben verse en pantalla organizándolo en una tabla: "Función | Datos necesarios en pantalla | De dónde provienen esos datos". No diseñes tablas de base de datos todavía; una vez completada la tabla, pregúntame si falta algún dato en pantalla.
""" {{funcion principal clave}} """
Ideal cuando los requisitos aún son abstractos. Mapear primero lo que ve el usuario en cada pantalla facilita un modelado de datos posterior mucho más exacto.
Notas por modelo
Tras recibir la respuesta del Paso 1, responde únicamente "siguiente" para avanzar. Si abres un chat nuevo, deberás pegar el resultado del paso anterior.
Al ser un prompt estructurado en pasos interactivos, la conversación se alargará. Si en el Paso 3 el modelo desvía alguna relación previa, vuelve a pegarle la lista de entidades acordada en el Paso 1 para retomar el contexto. Si pides diagramas ERD gráficos, muchos modelos generarán texto desalineado; es más práctico y legible validar las relaciones mediante tablas y frases explicativas.
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos