Cómo hacer un prompt para ChatGPT paso a paso, con un caso concreto

Hacer un prompt para ChatGPT no consiste en acertar con la frase exacta a la primera, sino en construir la instrucción por capas: escribes una versión corta, miras qué ha tenido que inventarse el modelo para responder y le añades eso que le faltaba —contexto, límites, formato y criterios de aceptación— hasta que el resultado se pueda usar sin rehacerlo. Aquí tienes ese proceso completo sobre una tarea de oficina de las que se repiten en cualquier empresa: cinco versiones del mismo prompt, qué suele fallar en cada una y qué cambia al arreglarlo.

Qué hay en este post y qué está en los otros dos

Sobre prompts hay aquí tres artículos:

• Qué es un prompt y por qué importa cómo lo escribes responde al qué: la definición, los seis elementos que cubre un buen prompt y los errores más frecuentes. Es el artículo de fondo.
• Los mejores prompts para ChatGPT en el trabajo de oficina responde al cuáles: diez instrucciones ya escritas —resumir un hilo, sacar acuerdos de un acta, comparar dos versiones— listas para copiar.
• Este responde al cómo: fabricar uno desde cero cuando no hay ninguno hecho que te sirva.

Si buscas algo que copiar ya, ve al segundo. Sigue aquí si quieres aprender a construirlos tú, que es lo que se practica sobre documentos reales en el curso de prompt engineering.

El ejemplo trabajado: comunicar un cambio de proceso al equipo

Voy a trabajar sobre una tarea que le toca a cualquiera antes o después: escribir el correo que anuncia un cambio en un procedimiento interno. En este caso, que desde el 1 de septiembre las facturas de proveedor dejan de enviarse por correo a administración y se registran en una herramienta nueva. Lo leerán treinta personas con prisa que no han pedido el cambio. Vamos a ver qué pasa según cuánta de esa información acaba dentro del prompt.

Versión 1: la frase corta que escribiríamos casi todos

«Escríbeme un comunicado para el equipo sobre el cambio en el proceso de facturas.»

Este es el punto de partida de casi todo el mundo, y no por falta de nivel técnico: es la costumbre de doce años escribiendo en un buscador. Tratamos a ChatGPT como si fuera Google —una frase corta, sin contexto, sin decir para quién es la respuesta, qué restricciones hay ni cómo sabremos si el resultado es bueno— y esperamos que el otro lado ponga el resto.

Lo previsible con una instrucción así es un correo de aspecto impecable: una apertura sobre la mejora continua, un cuerpo que habla del nuevo proceso en abstracto y un cierre agradeciendo la colaboración. Y con la fecha, el nombre de la herramienta y la persona a la que dirigir las dudas inventados, porque para escribir el correo hacen falta esos datos y nadie se los ha dado.

Qué le falta: todo lo que solo sabes tú. Quién lo lee, qué cambia, desde cuándo y qué tiene que hacer cada persona. Sin eso, el modelo genera lo más plausible, y lo más plausible es un comunicado que valdría para cualquier empresa.

Versión 2: añadir el contexto que el modelo no tiene

Primera capa: la situación real y el objetivo. No «somos una empresa de servicios», sino lo que ha pasado y para qué sirve el correo.

«Tengo que escribir un correo interno para anunciar un cambio de procedimiento.

Contexto: hasta ahora las facturas de proveedor se enviaban por correo a administración; desde el 1 de septiembre se registran en una herramienta nueva. Afecta a treinta personas de tres departamentos que no han pedido el cambio. Hay una guía de dos páginas y una persona de administración resolviendo dudas la primera semana.

Objetivo: que desde el día 1 nadie siga enviando facturas por correo, sin que el cambio genere una avalancha de preguntas.»

Qué mejora: el texto ya va de tu cambio y no de la mejora continua. Aparecen la fecha correcta, los tres departamentos y la guía.

Qué sigue fallando: los defectos típicos de esta capa son alargarse hasta las cuarenta líneas, adoptar un tono de circular que no es el de la casa y seguir rellenando huecos por su cuenta: un enlace inventado a la guía, una formación que nadie ha anunciado, el supuesto de que el cambio afecta también a los tickets de gasto. Nada en la instrucción le impide pasarse.

Versión 3: poner límites y decir de dónde salen los datos

Segunda capa: restricciones y fuentes. Qué extensión, qué tono, qué no puede afirmar y con qué material trabaja.

«[…contexto y objetivo de la versión anterior…]

Restricciones: máximo dieciocho líneas, se lee en el móvil. Tono directo y cercano, sin lenguaje de circular. No justifiques el cambio con generalidades sobre eficiencia; una frase de motivo basta.

Fuentes: usa solo lo que te he dado arriba. No inventes enlaces, nombres de herramienta, plazos ni sesiones de formación. Si hace falta un dato que no tienes, escríbelo como [FALTA: qué necesitas] en lugar de rellenarlo.»

Qué mejora: el correo cabe en una pantalla, suena a persona y —esto es lo importante— deja de inventar. Donde antes habría un enlace falso, debe aparecer [FALTA: enlace a la guía], que es justo lo que quieres ver.

Qué sigue fallando: el texto es bueno, pero no encaja donde tiene que ir. Falta el asunto, y qué hacer desde el día 1 se queda diluido en un párrafo. No se puede pegar y enviar.

Versión 4: fijar el entregable exacto y el formato

Tercera capa: qué te devuelve, con qué partes y en qué forma. Es la que convierte un texto correcto en algo usable.

«[…contexto, objetivo, restricciones y fuentes…]

Entregable: (1) dos opciones de asunto, una neutra y otra más directa, de menos de nueve palabras; (2) el cuerpo del correo con esta estructura: qué cambia en dos líneas, desde cuándo, tres puntos con lo que tiene que hacer cada persona desde esa fecha, dónde está la guía y a quién preguntar; (3) el mismo aviso en tres líneas para Teams.»

Qué mejora: el resultado ya tiene la forma del sitio donde va. Los tres puntos de acción se leen en diez segundos, que era el objetivo desde el principio.

Qué sigue fallando: poca cosa a la vista, y ese es el problema. El correo parece bien y no tienes forma sistemática de comprobarlo: cada vez que repitas la tarea tendrás que releerlo entero.

Versión 5: los criterios de aceptación y las comprobaciones

Última capa, la que casi nadie escribe: cómo sabrás que está bien, y qué debe revisar el modelo antes de responder.

«[…todo lo anterior…]

Criterios de aceptación: está bien si quien lo lee diez segundos en el móvil sabe qué hacer distinto el 1 de septiembre sin contestar preguntando; si no promete nada que yo no haya escrito arriba; y si podría haberlo escrito un compañero, no una circular.

Antes de responder, comprueba: que cada fecha, nombre y dato aparece en el contexto que te he dado; que no supera las dieciocho líneas; que los tres puntos son acciones y no descripciones. Si algo falla, corrígelo antes de enseñármelo y dime qué has ajustado.»

Qué mejora: escribir los criterios te obliga a decidir de antemano qué esperas —la mitad del trabajo, y suele destapar que ni tú lo tenías claro—. Y el modelo se autocorrige antes de responder, así que tu revisión final te lleva un minuto en lugar de cinco.

El prompt final, entero

Ensamblado, queda así. Se escribe en tres minutos y sirve igual la próxima vez que cambie otro procedimiento:

«Tengo que escribir un correo interno para anunciar un cambio de procedimiento.

Contexto: hasta ahora las facturas de proveedor se enviaban por correo a administración; desde el 1 de septiembre se registran en una herramienta nueva. Afecta a treinta personas de tres departamentos que no han pedido el cambio. Hay una guía de dos páginas y una persona de administración resolviendo dudas la primera semana.

Objetivo: que desde el día 1 nadie siga enviando facturas por correo, sin que el cambio genere una avalancha de preguntas.

Restricciones: máximo dieciocho líneas, se lee en el móvil. Tono directo y cercano, sin lenguaje de circular. Una sola frase de motivo.

Fuentes: usa solo lo que te he dado. No inventes enlaces, nombres, plazos ni formaciones. Lo que falte, márcalo como [FALTA: qué necesitas].

Entregable: dos asuntos de menos de nueve palabras; el cuerpo con qué cambia, desde cuándo, tres puntos de acción, dónde está la guía y a quién preguntar; y una versión de tres líneas para Teams.

Criterios de aceptación: que quien lo lea diez segundos sepa qué hacer el día 1 sin responder preguntando; que no prometa nada que no esté arriba; que suene a compañero, no a circular.

Comprobaciones: que cada dato salga del contexto, que no pase de dieciocho líneas, que los tres puntos sean acciones. Corrige lo que falle y dime qué has ajustado.»

Qué ha cambiado de la versión 1 a la versión 5

Cada capa quita un defecto concreto:

• Contexto y objetivo quitan lo genérico. Sin ellos, el correo serviría para cualquier empresa.
• Restricciones quitan la longitud y el tono equivocados.
• Fuentes quitan lo inventado, que es el defecto más caro: un enlace falso o un plazo que nadie prometió llegan a treinta personas.
• Entregable quita el trabajo de reformatear a mano.
• Criterios y comprobaciones quitan la revisión a ciegas.

Ese recorrido es el «clic» que veo en formación: el momento en que alguien deja de buscar la frase mágica y empieza a dar contexto, criterios de aceptación, ejemplos y un formato de salida. Misma herramienta, misma suscripción, y de repente el resultado se puede usar. No ha cambiado el modelo: han cambiado las decisiones que tomas tú en lugar de delegarlas sin querer.

El mismo método en una tarea que no es de redacción

Para que no parezca que esto solo vale para redactar, el mismo recorrido en una tarea de análisis: clasificar sesenta respuestas abiertas de una encuesta interna.

La versión 1 sería «clasifícame estas respuestas por temas», y lo esperable son seis categorías genéricas que se solapan. Las capas se aplican igual: el contexto es de qué iba la encuesta y quién leerá la clasificación; el objetivo, decidir en qué dos cosas trabajar el trimestre que viene; las restricciones, seis categorías como máximo y cada respuesta en una sola; las fuentes, que agrupe por lo que dicen estas respuestas y no por lo que suele salir en las encuestas; el entregable, una tabla con categoría, número de respuestas y dos citas literales; y el criterio, que ninguna categoría se llame «otros» con más de cinco dentro.

Mismo orden, contenido distinto. Lo que se traslada de una tarea a otra no es el texto del prompt: es la secuencia de preguntas que te haces antes de escribirlo.

Cuando el resultado no sirve: qué capa te falta

La ventaja de construir por capas es que el diagnóstico se vuelve mecánico: el defecto te dice qué añadir.

• Suena genérico, valdría para cualquiera → falta contexto real.
• Es correcto pero no me sirve → falta el destinatario y el objetivo.
• Se ha inventado un dato → faltan fuentes y la instrucción de marcar los huecos.
• Es demasiado largo, o el tono no es el nuestro → faltan restricciones.
• Está bien pero tengo que reformatearlo entero → falta el entregable exacto.
• No sé si está bien → faltan criterios de aceptación.
• Hace tres cosas y ninguna del todo → hay que separar la tarea en pasos.

Nada de esto elimina la revisión final: el modelo genera lo más plausible, no comprueba hechos. Cifras, fechas, nombres y compromisos siguen siendo tuyos mientras el documento lleve tu firma.

Cuánto de esto hay que escribir cada día

Ni de lejos todo. Para una consulta rápida que vas a leer y tirar, dos líneas bastan; las capas completas compensan cuando el resultado sale de tu ordenador o cuando la tarea se repite.

Para el día a día funciona bien una versión mínima de cuatro líneas: para qué es, quién lo va a leer, en qué formato lo quieres y qué no debe inventarse. Treinta segundos de escritura que te ahorran la mayoría de las segundas vueltas.

Guarda el prompt que funcione

Cuando una instrucción te dé un buen resultado, no la dejes morir en el historial del chat. Cópiala a un documento y sustituye los datos concretos por marcadores entre corchetes: [qué cambia], [desde cuándo], [a quién afecta]. Acabas de convertir tres minutos de trabajo en una plantilla reutilizable, y con cinco o seis así cubres casi todo lo que repites en un mes. Si prefieres un punto de partida, los diez prompts de tareas de oficina ya llevan esos marcadores puestos.

Dónde se practica esto con tus propios documentos

Leer el recorrido de las cinco versiones se entiende a la primera; hacerlo con un documento tuyo, delante de un resultado que no acaba de servir, es otra cosa. La parte difícil no es entender las capas: es acordarse de aplicarlas con prisa y saber cuál falta cuando el resultado sale raro.

Eso es lo que se trabaja en el curso de prompt engineering: construir instrucciones sobre tareas reales del equipo y afinarlas hasta que el resultado se pueda usar, sirva la herramienta que sirva. Si tu equipo aún está empezando, la puerta de entrada es el curso de ChatGPT para empresas; ambos forman parte del itinerario de formación en IA para empresas.

¿Quieres verlo con una tarea concreta de tu semana? Reserva media hora y construimos el prompt juntos con tu material, no con un ejemplo genérico.