¿Qué debe incluir realmente un prompt de construcción?
Cuatro cosas, y lo digo después de ver algo así como doscientas de estas convertirse en sitios terminados: qué es, para quién es, los imprescindibles y, opcionalmente, un ambiente. Todo lo demás es ruido que el constructor rellenará con valores predeterminados de todas formas, así que la verdadera habilidad no es escribir más, sino identificar sobre cuál de estas cuatro cosas realmente tienes una opinión y decir solo eso.
Empieza por qué es, y mantenlo en una categoría, no en una especificación. "Un sitio de reservas para un estudio de yoga" es mejor que "un sitio donde la gente ve horarios y pulsa un botón para reservar un turno y recibe una confirmación", aunque la segunda opción contenga más información. La categoría activa valores predeterminados que el constructor ya tiene —los horarios se parecen a horarios, los flujos de reserva se parecen a flujos de reserva—, mientras que la descripción lo obliga a reconstruir la categoría desde cero.
¿Necesito indicar para quién es?
No es obligatorio, pero es la línea que la gente se salta y no debería. "Para los estudiantes actuales del estudio" y "para personas que descubren el estudio por primera vez" producen sitios distintos en casi todo lo que importa: el tono del texto, si hay un gran héroe de marketing o un diseño directo al horario, si los precios van al frente (los visitantes nuevos los necesitan) o quedan más discretos (los habituales ya los conocen). Una sola frase aquí puede resolver cien pequeñas ambigüedades que una página de solicitudes de funciones nunca resolvería. Si la audiencia realmente es genérica, déjala fuera; no inventes una solo para llenar el espacio.
¿Cuántos imprescindibles debo enumerar?
Dos o tres. La prueba que uso: ¿rechazarías la primera construcción si le faltara esto? "Horario de clases, pagos en línea, biografías de profesores" pasa esa prueba para un estudio de yoga; sin horario no es una versión más pequeña del sitio, es un sitio distinto. "Un formulario de suscripción al boletín en el pie de página" casi nunca la pasa; eso es un extra deseable, y los extras deseables van en la conversación de seguimiento una vez que hayas visto un plan, no metidos a presión en el prompt inicial, donde compiten con lo que sí importa.
Este es, honestamente, el ingrediente que la gente estropea peor, en ambas direcciones. Cero imprescindibles y el constructor adivina, a veces mal. Ocho imprescindibles y el constructor los trata a todos como igual de esenciales, y el resultado se lee como una lista de funciones disfrazada de sitio web, sin jerarquía, sin espacio para respirar. Si tuviera que insistir en no saltarse un ingrediente, sería este. Incluso una sola frase con "las dos cosas que hacen que esto sea tuyo" ahorra casi siempre una ronda extra, porque es la única información que el constructor no tiene forma de deducir solo de la categoría.
¿Debo especificar un ambiente?
Solo si tienes uno. Muchos prompts buenos lo omiten por completo, y está bien — el director de diseño se compromete con una dirección artística la especifiques o no. Un estado de ánimo de dos palabras ("cálido y dibujado a mano", "clínico y rápido", "como un arcade de los 90") simplemente orienta ese compromiso hacia algún lugar en vez de dejarlo en manos de lo que sea que la categoría haga por defecto. Si tienes una reacción fuerte —sabes que quieres fondos color crema y tipografía serif cálida, o sabes que odias las esquinas redondeadas—, invierte la frase. Por cierto, "limpio y moderno" no cuenta. Eso no es un estado de ánimo, es la ausencia de uno, y no orienta nada mientras igual te cuesta un espacio.
¿Por qué no describir todo lo que estoy pensando?
Porque el constructor obedece. Ese es el verdadero modo de fallo, y no es lo que la gente espera: no es que demasiada información confunda al constructor, es que cada frase que escribes se lee como una instrucción, incluidas las medio formadas que descartarías con gusto en una segunda mirada. He visto a alguien escribir "tal vez una sección de testimonios, no estoy seguro" y recibir de vuelta una sección de testimonios con tres citas de relleno, porque "tal vez, no estoy seguro" es una duda para un lector humano y una solicitud de función para un sistema que te toma la palabra.
Esto no importaría si especificar de menos fuera costoso, como lo es con un equipo humano de desarrollo, donde la ambigüedad te cuesta dos semanas antes de que alguien note que se construyó lo equivocado. Aquí no es costoso. El constructor planifica antes de construir —ves una propuesta concreta antes de que nada quede fijado en código—, así que especificar de menos te cuesta una corrección de cinco minutos en el chat, mientras que especificar de más carga por adelantado todas tus ideas más débiles y a medio formar justo en el momento en que menos información tienes para saber cuáles vale la pena conservar. Diez palabras de requisitos reales superan a doscientas palabras de flujo de conciencia, no porque más información sea mala en abstracto, sino porque en esta interfaz en concreto, cada palabra de más es un compromiso.
Hay también un costo más silencioso: aplana la jerarquía. Enumera doce funciones con el mismo énfasis y el constructor no tiene ninguna señal de cuáles tres te importan realmente, así que o bien les da a las doce el mismo peso visual (desordenado) o adivina la prioridad (a veces mal, y ahora estás depurando una suposición en lugar de expresar una preferencia). Tres imprescindibles dichos con claridad protegen esa jerarquía. Doce en un párrafo la borran.
¿Cómo se ve realmente un buen prompt?
| Prompt | Por qué funciona |
|---|---|
| "Un registro de entrenamiento para escaladores: sesiones, grados, gráficos de progreso." | Qué más tres imprescindibles, diez palabras de requisitos en total. Sin nota de audiencia, porque "escaladores registrando su propio entrenamiento" es obvio a partir de la categoría; correctamente omite el único ingrediente que aquí no aporta nada. |
| "Una página de aterrizaje para mi podcast sobre agricultura urbana, cálida y editorial, con una lista de episodios y un formulario de suscripción." | Qué, audiencia implícita en "mi podcast", estado de ánimo, dos funciones. No dice qué reproductor incrusta los episodios ni cuántos se muestran por página; esas son preguntas de la segunda ronda, no del prompt inicial. |
| "Un juego de hockey de aire para dos jugadores, con física real, un solo teclado." | Los juegos hacen este patrón obvio: género más la única restricción que define cómo se juega realmente. "Física real" y "un solo teclado" no son tanto funciones como las dos decisiones que determinan si se siente como el juego que tenías en mente. Color de la mesa, estelas del disco, interfaz de puntuación: el constructor propone, tú reaccionas. |
Lo que une a los tres no es la brevedad por sí misma, es que cada palabra cumple una función. Quita "cálida y editorial" del prompt del podcast y obtienes una página de podcast genérica; quita "agricultura urbana" y el estado de ánimo no tiene hacia dónde apuntar. Esa es la verdadera prueba de si un prompt está bien formado: no el número de palabras. Preferiría un prompt de 40 palabras donde cada frase se gana su lugar, antes que uno de 15 palabras que es conciso por serlo y omite en silencio un imprescindible.
¿Qué pasa si ya tengo colores de marca o fotos reales?
Adjúntalos. No los describas. He visto a gente escribir un párrafo cuidadoso fijando una paleta de marca en un lenguaje casi de código hexadecimal —"un verde bosque profundo, algo apagado"— cuando la guía de marca real estaba todo el tiempo en un PDF en su escritorio. Un color descrito es una suposición que el constructor tiene que reconstruir; uno adjunto simplemente es correcto. Menús reales, fotos reales, recursos de marca: las funciones de conocimiento y referencia los incorporan directamente al build, y los hechos superan a las descripciones de los hechos siempre.
