Portar Prompts entre Modelos

Intermedio

Tienes un prompt que funciona de maravilla en un modelo. Ahora lo necesitas en otro — un cliente vive en GPT, un objetivo de coste te empuja hacia un modelo abierto, o estás haciendo un test A/B de Claude contra Gemini. La buena noticia, repetida en la documentación de cada proveedor: los cimientos de un buen prompt son universales. Lo que cambia es una fina capa de convenciones de superficie. Esta página separa ambas cosas para que puedas mover un prompt sin reescribirlo, y te da un flujo de migración repetible más una plantilla portable.

What you'll learn

• Saber qué partes de un prompt se transfieren sin problemas entre Claude, GPT, Gemini y modelos abiertos
• Saber qué partes necesitan ajuste por modelo — y por qué
• Ejecutar un flujo de migración repetible en lugar de reescribir por ensayo y error
• Mantener una plantilla de prompt portable y neutral respecto al modelo que puedas especializar por destino

Última verificación: 2026-06-28.

Los nombres exactos de los modelos, la verbosidad por defecto, el ajuste de rechazos, el peso del prompt de sistema, los parámetros admitidos (prefill, secuencias de parada, límites de max-token) y las formas del JSON de las llamadas a herramientas cambian entre versiones en cada proveedor. Esta página enseña el encuadre duradero — qué se transfiere frente a qué ajustar. Para cualquier comportamiento, nombre de parámetro o límite concreto, confírmalo en la documentación vigente del proveedor enlazada en Fuentes en lugar de confiar en un valor memorizado aquí.

Confirma con la fuente oficial.

El modelo mental: la estructura se transfiere, las convenciones no

Piensa en cualquier prompt como dos capas:

• La capa de razonamiento — qué estás pidiendo, el contexto que aportas, los ejemplos, la salida que quieres. Esto tiene que ver con la comunicación, y se transfiere casi sin cambios entre modelos.
• La capa de convenciones — cómo quiere este modelo concreto que se empaquete esa comunicación: dónde va el prompt de sistema y con cuánta fuerza se sigue, si prefiere XML o Markdown, el esquema exacto de las llamadas a herramientas, su locuacidad por defecto y su postura ante los rechazos, qué parámetros de generación existen.

Portar un prompt casi nunca es reescribir la capa de razonamiento. Es reajustar la capa de convenciones. Acierta con esa distinción y la migración se vuelve mecánica en lugar de misteriosa. (Para la forma neutral respecto al proveedor de elegir un destino en primer lugar, consulta Elegir un Modelo.)

Qué se transfiere sin problemas

Esto se mantiene por igual en Claude, GPT, Gemini y los principales modelos abiertos — la documentación de buenas prácticas de cada proveedor lo recomienda de forma independiente:

• Un rol + tarea + instrucciones explícitas claros. "Eres X. Tu trabajo es Y. Sigue estas reglas." Cada proveedor documenta una construcción de persona/rol y premia las instrucciones específicas e inequívocas frente a las vagas.
  Última verificación: 2026-06-28. La guía de diseño de prompts de Gemini de Google recomienda colocar la persona, las reglas y los requisitos de formato de salida como instrucciones de sistema explícitas; OpenAI y Anthropic dan el mismo consejo en sus propias guías — verifica la redacción vigente en cada fuente. Confirma con la fuente oficial.
• Ejemplos concretos (few-shot). Mostrar de 2 a 5 pares entrada→salida enseña un patrón de forma más fiable que describirlo. Los tres proveedores principales recomiendan explícitamente los ejemplos few-shot; la documentación de Gemini llega a recomendar que casi siempre los incluyas.
• Un formato de salida especificado. "Devuelve una tabla Markdown con columnas X, Y, Z" o "solo JSON, sin prosa" funciona en todas partes. La instrucción se transfiere aunque el mecanismo de modo estricto difiera (se cubre más abajo).
• Cadena de pensamiento / "razona antes de responder". Pedir razonamiento paso a paso en tareas difíciles mejora los resultados entre modelos. Una salvedad que sí es por modelo: los modelos de razonamiento/pensamiento dedicados a menudo lo hacen internamente, así que un "piensa paso a paso" explícito puede ser redundante o incluso contraproducente — consulta la lista de ajustes.
• Grounding / RAG. "Usa ÚNICAMENTE el contexto siguiente; si la respuesta no está ahí, di que no lo sabes." La disciplina de aportar contexto recuperado y restringir el modelo a él es universal — cada proveedor documenta el grounding estilo RAG como la forma de reducir las alucinaciones.
• Poner el contexto largo primero y la pregunta al final. Empieza con los documentos/datos, termina con la instrucción. Este orden ayuda en todos los modelos y se menciona explícitamente en la guía de Gemini.

Si has interiorizado Fundamentos de Prompting, ya posees el 80 % portable.

Qué necesita ajuste por modelo

Esta es la capa de convenciones — la parte que realmente difiere. Reajusta esto cuando muevas:

Aspecto	Qué cambia entre modelos	Qué hacer
Manejo y peso del prompt de sistema	Todos los modelos tienen un mensaje de sistema/developer, pero con cuánta fuerza sobrescribe el turno del usuario varía. Algunos dan a un rol dedicado de developer/sistema más peso que las instrucciones del usuario; otros difuminan la línea.	No asumas que tu prompt de sistema se sigue con la misma fuerza. Vuelve a probar que las restricciones realmente se mantienen; sube las reglas críticas de nivel si se escapan.
XML vs Markdown vs delimitadores	Claude interpreta especialmente bien las etiquetas XML para separar instrucciones/contexto/ejemplos; GPT y Gemini aceptan XML pero también se apoyan en encabezados y delimitadores Markdown.	Mantén algo de estructura explícita; cambia el sabor a la preferencia del destino. Igualar el formato de tu prompt al de la salida deseada también orienta el estilo de salida.
Forma del JSON de llamada a herramientas/funciones	El bucle (declarar herramientas → el modelo pide una llamada → tú la ejecutas → devuelves el resultado) es idéntico en todas partes; el formato de transmisión no lo es — los nombres de campo, cómo se ubican las llamadas/resultados en la lista de mensajes y las opciones de modo estricto difieren.	Nunca copies JSON de herramientas en bruto entre proveedores. Vuelve a mapearlo al esquema del destino. Consulta Uso de Herramientas.
Verbosidad por defecto	Los modelos más nuevos tienden a ser escuetos por defecto y esperan que pidas detalle; los más antiguos eran más locuaces.	Si portaste un prompt y las respuestas se hicieron más cortas/largas, fija la verbosidad explícitamente en lugar de culpar al prompt.
Postura de rechazo / seguridad	Cada modelo tiene su propio umbral para rechazar o evadir peticiones límite, y estos se reajustan en cada versión.	Vuelve a probar los casos límite tras portar. Un prompt que nunca activó rechazos en un modelo puede necesitar un reencuadre en otro.
Prefill de la respuesta	Poner palabras en boca del asistente para forzar un formato es una palanca clásica de la era Claude — pero los modelos Claude más nuevos (4.6+) rechazan un turno final de asistente con prefill, y el soporte varía por completo en otros.	Reemplaza el prefill con una instrucción directa ("responde sin preámbulo"), un esquema de salida o llamadas a herramientas.
Secuencias de parada y max tokens	Todos exponen un límite de longitud y la mayoría exponen secuencias de parada, pero los nombres de parámetro, los valores por defecto y los límites difieren — y algunos controles de presupuesto de pensamiento se están retirando en favor de effort/max_tokens.	Vuelve a comprobar los nombres de parámetro y los topes en el destino; no asumas que tus valores antiguos se portan.

Última verificación: 2026-06-28.

Dos de las filas anteriores son ejemplos concretos de deriva: la documentación de buenas prácticas vigente de Anthropic indica que los turnos finales de asistente con prefill devuelven un error en Claude 4.6 y modelos posteriores (usa una instrucción directa o salida estructurada en su lugar), y que las etiquetas XML son la forma recomendada de separar instrucciones, contexto, ejemplos y entradas para Claude. Ambos comportamientos son específicos de versión — confírmalos en la fuente antes de fiarte de ellos.

Confirma con la fuente oficial.

Un flujo de migración

Trata el porte como un bucle corto y disciplinado, no como una reescritura de adivina y prueba.

Guided walkthrough1 of 6

1. Lee tu prompt existente y divídelo mentalmente: capa de razonamiento (rol, tarea, contexto, ejemplos, especificación de salida) vs capa de convenciones (elecciones de XML/Markdown, prefill, JSON de herramientas, parámetros). Conservarás la primera y reajustarás la segunda.

:::tip No reescribas desde cero Si te encuentras reconstruyendo el rol, la tarea o los ejemplos, detente — esa es la capa portable. Un porte limpio cambia el empaquetado, no el significado. :::

Una plantilla de prompt portable

Escribe tu prompt en una forma neutral respecto al modelo, y luego especializa solo la capa de convenciones por destino. Este núcleo usa una estructura ligera y universalmente entendida (se lee limpiamente como Markdown, y las etiquetas se convierten fácilmente a XML para Claude):

Núcleo de prompt neutral respecto al modelo — especializa la capa de convenciones por destino

# ROLE
You are {role}.

# TASK
{One clear sentence describing the single goal.}

# RULES
- Use ONLY the information in CONTEXT below. If the answer is not there, say "I don't know" — do not guess.
- Be concise. Respond directly, with no preamble like "Here is..." or "Based on...".
- {Any other hard constraints.}

# OUTPUT FORMAT
{Exact format — e.g. "A Markdown table with columns Name, Value, Source." or "JSON only matching this schema: {...}".}

# EXAMPLES
Input: {example input 1}
Output: {ideal output 1}

Input: {example input 2}
Output: {ideal output 2}

# CONTEXT
{Retrieved documents / data go here — long content first.}

# REQUEST
{The actual user question, last.}

Ajustes por destino que superponer encima:

• Claude — mueve los marcadores de sección a etiquetas XML (<role>, <rules>, <context>, <request>); las interpreta especialmente limpio. No uses un turno de asistente con prefill en los modelos actuales; apóyate en la regla de "sin preámbulo" o en una herramienta/esquema en su lugar.
• GPT — pon las RULES en el mensaje de sistema/developer para que pesen más; los encabezados Markdown están bien; usa el modo de salida estructurada/JSON estricto en lugar de solo describir el esquema en prosa.
• Gemini — pasa ROLE + RULES + OUTPUT FORMAT mediante el campo de instrucción de sistema, mantén el prompt directo (los Gemini más nuevos pueden sobreinterpretar prompts verbosos), y mantén el CONTEXT primero con el REQUEST al final.
• Modelos abiertos (Llama/Mistral/Qwen, etc.) — sigue exactamente la plantilla de chat publicada del modelo, y apóyate más en ejemplos few-shot explícitos y restricciones de formato, ya que el seguimiento de instrucciones suele ser menos robusto que en los modelos cerrados de frontera.

Comprobación rápida

Comprueba lo aprendido

0/3

1. 1Estás moviendo un prompt de Claude que funciona a GPT. ¿Qué parte deberías esperar mantener esencialmente sin cambios?
2. 2Tu prompt portado produce de repente respuestas mucho más cortas en el nuevo modelo. ¿Causa más probable?
3. 3¿Qué es cierto sobre las llamadas a herramientas/funciones al portar entre proveedores?

Chuleta de porte

Pulsa Intro o Espacio para girar la tarjeta. Usa las flechas izquierda y derecha para moverte entre las tarjetas.Término mostrado.

1 / 6

Key takeaways

• Un prompt es una capa de razonamiento (se transfiere) más una capa de convenciones (se reajusta por modelo) — porta la segunda, conserva la primera.
• Rol/tarea/instrucciones claros, ejemplos few-shot, especificaciones de formato de salida, cadena de pensamiento y grounding RAG se transfieren entre Claude, GPT, Gemini y modelos abiertos.
• Ajusta por destino el peso del prompt de sistema, la estructura XML vs Markdown, el JSON de llamada a herramientas, la verbosidad por defecto, la postura de rechazo, el prefill y los parámetros de longitud.
• Ejecuta un pequeño conjunto de eval con entradas reales antes/después; arregla las convenciones antes de tocar el razonamiento.
• Mantén una plantilla neutral respecto al modelo más ajustes por destino en control de versiones para que cambiar sea barato.
• Los comportamientos concretos cambian en cada versión — verifica los parámetros y límites en la documentación vigente de cada proveedor, nunca de memoria.

Fuentes y lecturas adicionales

• Visión general de ingeniería de prompts — documentación de Anthropic (Claude) — técnicas de prompting de Claude: claridad, ejemplos, estructuración XML, pensamiento, roles.
• Buenas prácticas de prompting de Claude — documentación de Anthropic — ajuste específico del modelo, etiquetas XML, control de salida/verbosidad y la guía de migración de prefill.
• Buenas prácticas de ingeniería de prompts — documentación de la API de OpenAI (GPT) — roles de mensajes/cadena de mando, delimitadores, few-shot y guía de modelos de razonamiento vs GPT.
• Llamadas a funciones — documentación de la API de OpenAI — el esquema de llamada a herramientas y el bucle de petición/respuesta que mapear.
• Estrategias de diseño de prompts — documentación de la API de Gemini de Google — instrucciones de sistema, few-shot, estructuración, orden de contexto primero y parámetros de salida/longitud.
• Guía para desarrolladores de Gemini 3 — documentación de la API de Gemini de Google — guía de modelos más nuevos sobre prompts directos, verbosidad por defecto y colocación de instrucciones.

Siguiente

• Igualar la profundidad de pensamiento entre proveedores → Modelos de Razonamiento Comparados
• Elegir el destino de forma neutral respecto al proveedor → Elegir un Modelo
• Los fundamentos portables → Fundamentos de Prompting
• La palanca de estructura de Claude → Etiquetas XML
• Volver a mapear el esquema de herramientas → Uso de Herramientas