¿Qué es el Framework RTF?
📍 In One Sentence
RTF es un esqueleto de prompt de tres partes — Rol, Tarea, Formato — que le da al modelo justo la estructura suficiente para tareas rutinarias sin la sobrecarga de frameworks más grandes.
💬 In Plain Terms
Dile a la IA quién ser (Rol), qué hacer (Tarea) y cómo formatear la respuesta (Formato). Eso es todo. Tres cosas. Funciona para el 80% de las tareas cotidianas. Cuando deje de ser suficiente, pasas a CO-STAR o SPECS.
El Framework RTF es un patrón de prompt de tres partes que le dice al modelo quién es, qué hacer y exactamente cómo debe verse la respuesta. En lugar de enviar una pregunta suelta, especificas Rol, Tarea y Formato explícitamente. Esto funciona en GPT-4o, Claude Opus 4.7, Gemini 3.1 Pro y modelos locales que ejecutas via Ollama o LM Studio.
RTF es intencionalmente mínimo. Con solo tres campos, es fácil de recordar, rápido de completar y lo suficientemente flexible para muchas tareas cotidianas. Puedes tratarlo como un "esqueleto de prompt predeterminado" siempre que no estés seguro de qué framework especializado usar.
Los Tres Componentes RTF
Un prompt RTF sólido define claramente cada uno de los tres componentes para que el modelo no tenga ambigüedad sobre su trabajo. Puedes escribirlos como líneas etiquetadas o como una oración que aún contenga las tres partes.
Definiciones típicas:
- Rol: La perspectiva o experiencia que el modelo debe adoptar (por ejemplo "Eres un analista de datos sénior").
- Tarea: La acción concreta que quieres, descrita en una o dos oraciones.
- Formato: La estructura, longitud y estilo del output (por ejemplo "3 puntos de bala más un resumen de 2 oraciones").
🔍 El Formato Es el Movimiento Clave
Rol y Tarea son obvios — la mayoría ya dicen lo que quieren. Formato es donde RTF añade valor real. "3 puntos de bala, máx 50 palabras cada uno, markdown" produce output dramáticamente más consistente que "dame un resumen". El campo Formato es el arma secreta de RTF.
Por qué RTF es útil
El Framework RTF es útil porque te da la mayoría de los beneficios de frameworks más complejos con casi ninguna sobrecarga. Te obliga a tomar tres decisiones — quién, qué y cómo — antes de enviar un prompt.
Las ventajas prácticas incluyen:
- Escritura de prompts más rápida que los frameworks de múltiples secciones para trabajo rutinario.
- Mejor consistencia entre modelos y ejecuciones, ya que el formato siempre es explícito.
- Fácil incorporación para compañeros de equipo que pueden aprender RTF en pocos minutos y reutilizarlo en todas partes.
Ejemplo: Prompt RTF malo vs bueno
La versión RTF le dice al modelo exactamente cómo pensar sobre el contenido y cómo empaquetar el resultado para que otros puedan usarlo inmediatamente.
❌ Solicitud sin estructura
Resume esta reunión.
✅ Prompt RTF
Rol: Eres un gerente de operaciones resumiendo una reunión de estado del proyecto para el liderazgo senior. Tarea: Lee la transcripción e identifica las decisiones clave, los riesgos abiertos y los próximos pasos discutidos en la reunión. Formato: Produce un resumen en Markdown con tres secciones (`Decisiones`, `Riesgos`, `Próximos pasos`). En cada sección, usa 3-5 puntos de bala. Mantén el resumen total bajo 250 palabras.
Cuándo usar RTF
Debes usar el Framework RTF cuando quieres un patrón simple y reutilizable que aún imponga claridad y estructura. Es un buen predeterminado siempre que no necesites especificaciones largas o trazas de razonamiento multi-paso.
Los casos de uso típicos incluyen:
- Informes cortos, recapitulaciones y resúmenes para emails o chat.
- Redactar respuestas a clientes o partes internas con estructura clara.
- Generar pequeños fragmentos de código o refactorizaciones con un formato de output especificado.
- Piezas de contenido rápidas como descripciones de productos, entradas de FAQ o listas de verificación simples.
Cuándo RTF no es la elección correcta
| Escenario | Limitación de RTF | Usa en su lugar |
|---|---|---|
| Contenido de cara al cliente donde el tono y la audiencia son críticos | Sin campo explícito de Audiencia o Tono | CO-STAR (incluye Estilo, Audiencia, Tono) o CRAFT (Restricciones, Rol, Audiencia, Formato, Tono) |
| Imposición estricta de estructura o esquema de datos necesaria | El campo Formato puede solicitar JSON pero no ofrece sintaxis de restricciones | SPECS (incluye campo de Restricciones explícito) |
| Razonamiento multi-paso o lógica de decisión necesaria | Sin campo de razonamiento paso a paso explícito | TRACE (incluye Disparador, Respuesta, Acción, Consecuencia, Evaluación) |
| Flujos de trabajo complejos con lógica condicional | Único Rol/Tarea/Formato por prompt | APE (Acción, Proceso, Ejemplos) o flujos de trabajo multi-turno personalizados |
Tablas de comparación
Cómo RTF se compara con otros frameworks principales:
Comparación por dimensión
| Dimensión | RTF | CO-STAR | SPECS | TRACE |
|---|---|---|---|---|
| Número de campos | 3 (Rol, Tarea, Formato) | 6 (Contexto, Objetivo, Estilo, Audiencia, Respuesta, Tono) | 5 (Configuración, Persona, Ejemplos, Patrón, Restricciones) | 5 (Disparador, Respuesta, Acción, Consecuencia, Evaluación) |
| Tiempo de configuración | 30 segundos | 2-3 minutos | 3-5 minutos | 2-3 minutos |
| Mejor para | Tareas rutinarias y repetibles | Control de tono y audiencia | Esquemas y restricciones estrictas | Pasos de razonamiento explícitos |
| Consistencia del output | Buena | Excelente | Excelente | Buena |
| ¿Requiere ejemplos? | No | Opcional | Sí (patrones sólidos) | No |
Comparación por pares (RTF vs Otros)
| Comparación | Ganador | Por qué |
|---|---|---|
| RTF vs CO-STAR | CO-STAR (si la audiencia importa) | CO-STAR incluye campos explícitos de Audiencia y Tono. RTF fuerza el tono en Rol o Formato, lo que se vuelve complicado. Si no te importa la voz, RTF es más rápido. |
| RTF vs SPECS | SPECS (si se necesitan restricciones estrictas) | SPECS incluye un campo de Restricciones dedicado y espera ejemplos. RTF puede solicitar restricciones en Formato pero carece de sintaxis estructurada. SPECS gana para JSON, CSV o datos estructurados. |
| RTF vs TRACE | TRACE (si el razonamiento importa) | TRACE modela explícitamente causa y efecto (Disparador → Respuesta → Acción → Consecuencia). RTF no tiene campo de paso de razonamiento. Usa TRACE para lógica compleja, RTF para output simple. |
| RTF vs Chain-of-Thought | Complementarios | RTF define el rol y el formato del output. CoT mejora el razonamiento. Combínalos: usa RTF para estructurar el prompt, añade "piensa paso a paso" para matemáticas o lógica complejas. |
Cómo escribir un prompt RTF
- 1Rol: Define quién está interpretando la IA. Los roles específicos superan a los genéricos. Malo: "Eres útil." Bueno: "Eres un ingeniero backend sénior revisando código por regresiones de rendimiento." Cuanto más específico, más consistente el output.
- 2Tarea: Indica qué debe hacer la IA. Sé concreto. Malo: "Resume esto." Bueno: "Identifica las tres decisiones clave, los riesgos abiertos y los próximos pasos discutidos."
- 3Formato: Especifica estructura, longitud y estilo. Aquí es donde RTF añade valor. Malo: (Formato faltante). Bueno: "3 puntos de bala, máx 50 palabras cada uno, markdown, bajo 200 palabras en total."
- 4Separa Tarea y Formato. Mézclalos en un bloque y ninguno obtiene suficiente especificidad. Mantenlos distintos.
- 5Siempre incluye Formato, incluso cuando parezca obvio. Sin él, los modelos usan prosa por defecto.
Cinco ejemplos reales de RTF
Aquí hay cinco prompts RTF listos para producción para flujos de trabajo comunes:
Ejemplo 1: Resumen de estado semanal
Rol: Eres un gerente de operaciones escribiendo un resumen de estado semanal para el liderazgo ejecutivo.
Tarea: Resume el progreso del proyecto de esta semana, las decisiones clave tomadas, los riesgos identificados y las prioridades de la próxima semana.
Formato: Markdown, cuatro secciones (Resumen, Decisiones, Riesgos, Próxima semana), 3-5 puntos por sección, máx 300 palabras.
Ejemplo 2: Feedback de revisión de código
Rol: Eres un ingeniero backend sénior revisando código por mantenibilidad, rendimiento y seguridad.
Tarea: Revisa este bloque de código e identifica cualquier problema, sugiere mejoras y califica la calidad general.
Formato: Markdown, tres secciones (Problemas encontrados, Mejoras, Calificación de calidad 1-5), bloques de código para ejemplos.
Ejemplo 3: Borrador de email al cliente
Rol: Eres un gerente de éxito del cliente redactando una respuesta profesional y empática a una queja del cliente.
Tarea: Aborda su preocupación, discúlpate donde corresponda, explica la resolución y restaura la confianza.
Formato: Formato de email (saludo, 2-3 párrafos, cierre), tono profesional, 150-250 palabras.
Ejemplo 4: Notas de reunión a elementos de acción
Rol: Eres un coordinador de proyectos extrayendo elementos de acción de notas de reunión en bruto.
Tarea: Identifica las decisiones tomadas, los riesgos discutidos y los próximos pasos con responsables y plazos.
Formato: Markdown con tres secciones (Decisiones, Riesgos, Elementos de acción), elementos de acción como listas de verificación con asignado y fecha límite.
Ejemplo 5: Documentación de producto para usuarios no técnicos
Rol: Eres un escritor técnico explicando una función a usuarios no técnicos en lenguaje simple.
Tarea: Explica qué hace esta función, por qué podrían usarla y cómo usarla en tres pasos simples.
Formato: 1 oración de introducción, 3 pasos numerados con ejemplos, 1 oración de conclusión. Evita el jerga.
Combinar RTF con otros frameworks
Debes combinar el Framework RTF con otros frameworks tratando RTF como tu predeterminado liviano y cambiando a frameworks más pesados cuando aumenten las restricciones. Un patrón práctico es:
- Empieza con RTF para la mayoría de las nuevas tareas donde solo necesitas una estructura clara rápidamente.
- Pasa a SPECS cuando necesites esquemas estrictos, ejemplos y restricciones.
- Usa TRACE o APE cuando quieras pasos de razonamiento explícitos antes de la respuesta final.
- Usa frameworks creativos como CRAFT cuando la audiencia y el tono sean centrales.
Errores comunes de RTF
❌ Rol vago — "Eres un asistente útil"
Why it hurts: "Asistente útil" es el predeterminado. No añade nada. Un rol vago significa que el modelo elige su propia perspectiva, que varía entre ejecuciones.
Fix: Sé específico: "Eres un ingeniero backend sénior" o "Eres un gerente de marketing B2B dirigiéndose a CFOs." Cuanto más específico el rol, más consistente el output.
❌ Tarea vaga — "ayúdame con esto"
Why it hurts: "Ayúdame con esto" no es una tarea. El modelo adivina qué acción tomar, qué detalle incluir y qué ignorar. La ambigüedad en la Tarea produce variabilidad en el output.
Fix: Escribe la Tarea como una acción específica: "Identifica los tres principales riesgos técnicos en este plan de proyecto" o "Escribe una respuesta de seguimiento de 5 frases para esta queja del cliente."
❌ Formato faltante
Why it hurts: Sin Formato, el modelo elige la longitud, estructura y estilo. Esto produce variabilidad entre ejecuciones e inconsistencia cuando el mismo prompt se usa en múltiples modelos.
Fix: Siempre incluye Formato. Incluso algo simple como "Markdown, 3 puntos de bala, bajo 150 palabras" mejora dramáticamente la consistencia.
❌ Combinar Tarea y Formato en una oración
Why it hurts: "Resume esto en 3 puntos" combina qué hacer con cómo formatearlo. Si cambia la tarea, se pierde el formato. Si cambia el formato, la tarea se vuelve confusa.
Fix: Mantenlos separados: "Tarea: Identifica los riesgos. Formato: 3 puntos de bala, máx 30 palabras cada uno."
Lecturas relacionadas
- Schulhoff, L., et al. (2024). Prompt Engineering Guide. https://www.promptingguide.ai
- Brown, T. B., et al. (2020). "Language Models are Few-Shot Learners." OpenAI. arXiv:2005.14165
- OpenAI. (2026). Prompt Engineering Best Practices. https://platform.openai.com/docs/guides/prompt-engineering
- Anthropic. (2026). Prompt Engineering — Claude API Documentation. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering