Prompt Engineering avanzado en la práctica: de los trucos a la metodología

El resultado número 17 de la prueba ya está.

El mismo Prompt — «analiza los cuellos de botella de rendimiento de este código y sugiere optimizaciones» — el lunes por la mañana Claude respondió con detalle y profesionalidad; el viernes por la tarde devolvió un montón de generalidades vacías. Probé con otro modelo: ChatGPT modificó el código directamente, sin preguntar si quería cambios ni explicar por qué.

La calidad del Prompt oscilaba entre «aceptable» y «inútil». Al programar con IA o construir aplicaciones Agent, esa inestabilidad duele. El problema real: estaba ensamblando trucos sueltos, no construyendo una metodología.

Este artículo va de eso: pasar de «conocer algunos trucos» a «dominar una metodología sistemática». Hablamos del marco de tres capas, Chain-of-Thought y ReAct, DSPy como herramienta de optimización automática, y cómo escribir Prompts distintos para Claude y ChatGPT. Cerramos con un método de evaluación que puedes ejecutar de verdad — sin medición, «optimizar» es adivinar.

Por qué pasar de «trucos» a «metodología»

Seguro que has oído estos «trucos»: pedir a la IA que «piense paso a paso», añadir ejemplos para que los imite, asignarle un rol de «eres un experto»… Funcionan, pero el problema es que los resultados son demasiado inestables.

Las limitaciones del enfoque basado en la experiencia

Entre 2023 y 2024, la mayoría de técnicas de Prompt se basaban en la experiencia. ¿Qué significa? Básicamente «probar y ver»: cambias palabras, ejecutas, si funciona lo usas, si no, cambias otra vez. Ese enfoque tiene varios problemas claros:

Resultados impredecibles. El mismo Prompt puede fallar al cambiar de modelo. Incluso con el mismo modelo, la calidad puede variar mucho según el momento de la llamada. He visto a mucha gente (yo incluido) pasar horas afinando Prompts para descubrir al día siguiente que la versión buena ya no sirve.

Difícil de reproducir y transmitir. Ajustas un Prompt excelente, pero un compañero obtiene resultados distintos. ¿Por qué? Porque tu Prompt puede incluir contexto implícito que no percibes: conversaciones previas con el modelo, tu estilo de escritura, etc. Eso no cabe en documentación y otros no pueden reproducirlo.

Falta de estándares de evaluación. ¿Un Prompt es bueno o malo? Muchas veces solo por sensación. «Esta salida se ve bien» es demasiado subjetivo. Sin métricas cuantificables no hay optimización sistemática.

Un dato interesante: antes de usar métodos sistemáticos de Prompt (llaman «fórmula 3C» — Context, Constraint, Content), una empresa fintech tenía solo un 61% de comprensión correcta en el primer intento. Tras el marco sistemático, subió al 89%. No es un ajuste menor: es un salto cualitativo.

La transición 2025-2026

Desde 2025, Prompt Engineering está pasando de «ajuste manual de parámetros» a «ingeniería sistemática». Esa transición tiene tres avances clave:

Diseño modular. Dividir Prompts en componentes reutilizables, como ensamblar código. No escribes un Prompt largo desde cero cada vez, sino que combinas módulos estándar. Ventaja: cada componente se prueba y optimiza por separado; la estabilidad global mejora mucho.

Optimización automática. Los frameworks empiezan a optimizar Prompts por ti. DSPy es el más representativo: defines tarea y criterios de evaluación, y el framework itera hasta la configuración óptima. Su filosofía: «Programming, not prompting».

Evaluación estandarizada. Con métricas y frameworks de prueba, el efecto del Prompt se mide objetivamente. DeepEval, Promptfoo y otras herramientas cubren precisión, consistencia, seguridad y eficiencia de costes. La evaluación deja de ser intuición y pasa a ser datos.

En serio, esas tres cosas cambiaron mi forma de trabajar. Antes afinar Prompts era «suerte»; ahora es más ingeniería: diseño, pruebas, iteración y datos. Ese es el núcleo del paso de «trucos» a «metodología».

Marco de tres capas de técnicas de Prompt

Entender las técnicas en tres capas aclara mucho: capa base, capa de razonamiento y capa de sistema. Cada una resuelve problemas distintos.

Capa base: que el modelo te entienda

Esta capa resuelve lo más básico: cómo hacer que el modelo produzca lo que quieres.

Zero-shot, prompt sin ejemplos: no das ningún ejemplo y pides completar la tarea directamente. Por ejemplo:

Explica qué es la arquitectura de microservicios.

Es simple y directo, adecuado para tareas sencillas o conocimiento general. En tareas complejas o formatos específicos, Zero-shot suele ser inestable.

Few-shot, prompt con pocos ejemplos: das 2-5 ejemplos para que el modelo aprenda. Si quieres descripciones de producto con estilo vivo:

Escribe una descripción del nuevo producto siguiendo el estilo de estos ejemplos:

Ejemplo 1:
Producto: Auriculares Bluetooth inalámbricos
Descripción: Un mini universo en tus oídos, sonido tan nítido como en un concierto en vivo, batería para un vuelo intercontinental.

Ejemplo 2:
Producto: Cafetera portátil
Descripción: Mete una cafetería en la mochila, café de filtro premium en cualquier lugar, hasta el poso bajo control.

Ahora escribe una descripción para «Termo inteligente».

El modelo imitará el estilo. Claves de Few-shot: ejemplos alineados con el estilo deseado, pocos (2-5 bastan) pero de alta calidad.

Role Prompting, prompt de rol: asignas una identidad al modelo. Restringe estilo y nivel profesional:

Eres un arquitecto backend con 10 años de experiencia, especializado en optimización de rendimiento y diseño de sistemas.
Analiza los problemas de rendimiento del siguiente código, señala cuellos de botella concretos y da recomendaciones de optimización.
Código: [pega el código]

Con un rol definido, el modelo piensa más en clave profesional y la salida es más estructurada. El rol debe ser concreto: «eres un experto» es vago; mejor indicar dominio y experiencia.

Salida estructurada: exiges un formato concreto (JSON, Markdown, tablas, etc.). Muy útil para extracción de datos o integración con sistemas posteriores:

Extrae la información del producto del siguiente texto y devuélvela en formato JSON:
{
  "product_name": "nombre del producto",
  "price": "precio",
  "features": ["lista de características"]
}

Texto: [pega el texto]

Las restricciones estructuradas mejoran mucho la usabilidad y reducen el postprocesado.

Capa de razonamiento: que el modelo «piense»

Esta capa permite no solo entender, sino razonar de forma compleja.

Chain-of-Thought (CoT), cadena de pensamiento: el modelo muestra su razonamiento. La idea: no dar la respuesta directa; primero explicar cómo piensa.

El artículo de Wei et al. (2022) demostró que CoT mejora mucho la precisión en razonamiento complejo. La lógica es simple: problemas complejos requieren varios pasos; escribirlos da un «buffer de pensamiento» y reduce errores.

El uso más simple es añadir al final del Prompt:

Piensa en este problema paso a paso y luego da la respuesta.

O Few-shot CoT, con ejemplos que muestran el razonamiento:

Pregunta: Ming tiene 5 manzanas, le da 2 a Hong y recoge 3 del árbol. ¿Cuántas manzanas tiene Ming ahora?
Proceso de razonamiento: Ming empezó con 5. Tras dar 2 a Hong, quedan 5-2=3. Tras recoger 3, tiene 3+3=6.
Respuesta: 6 manzanas.

Ahora resuelve de la misma forma: Una cesta tiene 12 fresas, Ming come 4 y Hong añade 6. ¿Cuántas fresas hay en la cesta?

ReAct, bucle de razonamiento + acción: el modelo piensa mientras ejecuta. Flujo: Thought (pensar el siguiente paso) → Action (ejecutar) → Observation (observar resultado) → repetir. Ideal cuando hace falta herramientas externas o recuperación de información.

Eres un asistente capaz de buscar información. Responde en este formato:

Thought: [qué hay que hacer ahora]
Action: search("[contenido de búsqueda]")
Observation: [resultado de búsqueda]
... (repetir hasta tener respuesta)
Final Answer: [respuesta final]

Pregunta: ¿Qué película ganó el Oscar a Mejor Película en 2024?

ReAct es central en desarrollo de Agents: el núcleo es el ciclo «pensar-actuar-feedback», y ReAct ofrece una plantilla estándar.

Self-Consistency, autocoherencia: el modelo razona varias veces sobre el mismo problema y vota la respuesta más fiable. Útil cuando exiges alta precisión, pero el coste sube (varias llamadas).

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Tree of Thoughts (ToT), árbol de pensamientos: explora varias rutas de razonamiento y elige la mejor. Adecuado para decisiones complejas, generación creativa o planificación estratégica.

Capa de sistema: gestión de Prompts como ingeniería

No es una técnica aislada, sino convertir la gestión de Prompts en un sistema de ingeniería.

Prompt modular. Dividir un Prompt complejo en módulos reutilizables: rol, definición de tarea, restricciones de salida, invocación de herramientas. Cada módulo se gestiona por separado y se combina con flexibilidad.

Optimización automática. Con frameworks como DSPy no ajustas parámetros a mano: defines firmas de tarea y métricas, y el framework itera. Lo veremos en detalle más adelante.

Evaluación estandarizada. Conjunto de prueba, métricas, pruebas por lotes y registro de puntuaciones por iteración. La optimización queda respaldada por datos, no por sensación.

El marco de tres capas ayuda a decidir en qué nivel está el problema y qué técnica usar: base para tareas simples, razonamiento para lógica compleja, sistema para construir plataformas.

Chain-of-Thought en profundidad

CoT merece un apartado propio. Es la técnica de razonamiento más madura y de barrera baja: no hace falta código de framework complejo, bastan unas frases en el Prompt.

Zero-shot CoT vs Few-shot CoT

Dos modos, escenarios distintos.

Zero-shot CoT: sin ejemplos, solo una frase guía. La más clásica:

Let's think step by step.

O en español:

Piensa en este problema paso a paso.

Es simple, barato y sirve en la mayoría de casos. Incluso esa sola línea puede subir la precisión en razonamiento complejo un 20-40%.

Few-shot CoT: ejemplos con proceso de razonamiento completo en formato «pregunta → razonamiento → respuesta»:

Pregunta: Una tienda compra 100 artículos a 20 yuanes cada uno. Día 1 vende 30 a 35 yuanes. Día 2 vende 50 a 30 yuanes. Día 3 liquida el resto a 15 yuanes. ¿Cuál es el beneficio total?

Proceso de razonamiento:
1. Coste total: 100 × 20 = 2000 yuanes
2. Ingresos día 1: 30 × 35 = 1050 yuanes
3. Ingresos día 2: 50 × 30 = 1500 yuanes
4. Resto día 3: 100-30-50=20 artículos, ingresos: 20 × 15 = 300 yuanes
5. Ingresos totales: 1050+1500+300 = 2850 yuanes
6. Beneficio total: 2850-2000 = 850 yuanes

Respuesta: 850 yuanes

Ahora resuelve de la misma forma:
Pregunta: Una empresa tiene 200 empleados con salario medio mensual de 8000 yuanes. A inicio de año despide 30 con indemnización de 2 meses cada uno. Luego contrata 50 nuevos con 6000 yuanes/mes durante 3 meses de prueba. ¿Cuánto cambia el gasto salarial anual?

Few-shot CoT guía formato y estilo de razonamiento, pero exige ejemplos de calidad; malos ejemplos confunden al modelo.

¿Cuándo usar cada uno?

• Tarea simple, ruta clara: Zero-shot CoT, una frase guía basta
• Tarea compleja, formato específico: Few-shot CoT con buenos ejemplos
• Modelo fuerte (p. ej. Claude 4): Zero-shot CoT suele bastar
• Modelo medio y alta precisión: Few-shot CoT es más estable

Escenarios adecuados para CoT

No todas las tareas lo necesitan. Encaja mejor en:

Razonamiento matemático y análisis lógico. Cálculos o deducciones en varios pasos; CoT evita saltos y omisiones.

# Sin CoT la salida podría ser:
«La respuesta es 850 yuanes.» (salto al resultado, error intermedio posible)

# Con CoT:
«Voy a calcular paso a paso...»
y luego cada paso en detalle.

Planificación en varios pasos. Plan de proyecto o arquitectura de sistema: primero descomponer, luego desarrollar.

Análisis previo en generación de código. Analizar requisitos, diseñar solución y luego codificar, en lugar de volcar código directo.

Implementa un sistema de autenticación de usuarios en estos pasos:

Paso 1: Analiza requisitos y lista funciones clave
Paso 2: Diseña modelo de datos e interfaces
Paso 3: Proporciona código de implementación
Paso 4: Explica plan de pruebas

Requisitos: [tu descripción]

Variantes de CoT

Auto-CoT: el modelo genera solo las cadenas de razonamiento de los ejemplos y se usan como Few-shot. Ahorra trabajo manual, pero la calidad depende de la primera generación; si falla, el resto también.

CoD (Chain of Debate), cadena de debate: dos roles debaten, se cuestionan y sintetizan respuesta. Funciona en problemas complejos u abiertos, pero cuesta más y tarda más.

Precauciones al usar CoT

Algunos errores que cometí:

No forzar razonamiento de más. Preguntas simples no lo necesitan. «¿Cuál es la población de Pekín?» con CoT alarga la salida o introduce errores. Criterio: ¿hace falta razonamiento en varios pasos?

Ejemplos alineados con la tarea. Ejemplos matemáticos para una tarea lógica hace que el modelo razone mal. El tipo de ejemplo debe coincidir.

Pasos no demasiado largos. Muchos pasos (p. ej. una docena) aumentan errores intermedios. En problemas muy complejos, dividir: descomponer primero, resolver subproblemas después.

En conjunto, CoT es la técnica de razonamiento más práctica. Dominar Zero-shot y Few-shot, y saber cuándo aplicarla, mejora mucho tus Prompts.

Framework ReAct: razonamiento y acción combinados

ReAct significa Reasoning + Acting. Une pensamiento y acción para invocar herramientas, obtener información y decidir dinámicamente. Si CoT es «pensar bien», ReAct es «pensar mientras actúas».

Bucle Thought → Action → Observation

El núcleo es un ciclo:

Thought (pensamiento) → Action (acción) → Observation (observación) → Thought → ...

Cada vuelta avanza la solución. Ejemplo de Q&A con búsqueda:

Tarea: Consultar el campo de investigación de los ganadores del Nobel de Física 2024.

Proceso del modelo:

Thought: Primero debo saber quién ganó el Nobel de Física 2024.
Action: search("2024 Nobel Prize in Physics winners")
Observation: [resultado] El Nobel de Física 2024 fue para John Hopfield y Geoffrey Hinton, por sus contribuciones a redes neuronales artificiales.

Thought: Ya sé quiénes son; debo profundizar en sus campos.
Action: search("John Hopfield research field")
Observation: [resultado] John Hopfield es físico, propuso el modelo de red Hopfield...

Thought: Tengo información suficiente para responder.
Final Answer: El campo de investigación de John Hopfield y Geoffrey Hinton, ganadores del Nobel de Física 2024, es las redes neuronales artificiales...

El modelo «rellena información» durante el razonamiento: ante lo desconocido no inventa, busca. Diferencia clara con CoT: CoT solo usa conocimiento interno; ReAct puede usar herramientas externas.

ReAct vs CoT: diferencias clave

CoT encaja cuando el modelo ya sabe bastante: matemáticas, lógica. ReAct cuando hace falta información en tiempo real: eventos actuales, bases de datos, APIs.

Estructura del Prompt ReAct

Un Prompt ReAct estándar incluye:

Eres un asistente inteligente que puede usar herramientas. Completa la tarea en este formato:

Herramientas disponibles:
- search(query): buscar información en internet
- database_query(sql): consultar base de datos
- calculate(expression): ejecutar cálculo matemático

Formato:
Thought: [tu razonamiento, qué hacer ahora]
Action: [nombre y parámetros, p. ej. search("consulta")]
Observation: [resultado de la herramienta, se rellena automáticamente]
... (puede haber varias rondas Thought-Action-Observation)
Final Answer: [respuesta final]

¡Empieza!

Tarea: [tu tarea concreta]

Puntos clave:

Definir herramientas disponibles. Nombre, formato de parámetros y tipo de retorno.

Formato de salida explícito. Thought, Action y Observation deben ser parseables para ejecutar herramientas y devolver resultados al modelo.

Condición de terminación. Final Answer cuando hay información suficiente, sin bucles infinitos.

ReAct en desarrollo de Agents

ReAct es uno de los patrones base de Agents modernos. Bot de soporte, asistente de datos u operaciones automatizadas suelen usar esta idea.

En producción, ReAct es más complejo que el Prompt de ejemplo. Necesitas:

1. Sistema de registro de herramientas: interfaces, validación de parámetros, permisos
2. Motor de ejecución: parsear Action, invocar herramienta, formatear y devolver Observation
3. Control del bucle: máximo de iteraciones, timeout, anti-bucle infinito
4. Manejo de errores: informar al modelo del fallo para que ajuste estrategia

Precauciones al usar ReAct

Modelo suficientemente capaz. ReAct exige mantener contexto en varias rondas y decidir acciones razonables. Modelos débiles llaman herramientas al azar. Claude y GPT-4 suelen ir bien.

Definiciones de herramientas claras. Sin descripción detallada, el modelo no invoca o lo hace mal. Cada herramienta como documentación de API.

Evitar dependencia excesiva de herramientas. A veces basta el conocimiento interno. En el Prompt: «Si el conocimiento interno basta, responde con Final Answer sin invocar herramientas.»

Control de costes. Varias invocaciones suben el gasto de API. ReAct para tareas complejas; Prompt normal para las simples.

ReAct convierte el Prompt de «script estático» en «programa dinámico» y acerca la IA de «conversacional» a «orientada a la acción».

DSPy: optimización automática de Prompts

CoT y ReAct requieren escribir Prompts a mano. DSPy es distinto: «Programming, not prompting» — defines la tarea con código y el framework genera y optimiza Prompts.

Qué es DSPy

DSPy es un framework del grupo NLP de Stanford. Convierte Prompt Engineering en paradigma de programación: defines la estructura entrada/salida (Signature), eliges módulos (Module), configuras optimizador (Optimizer), y el framework itera hasta la configuración óptima.

Ventajas:

Más fiable. Los Prompts manuales omiten restricciones o fallan en formato; la definición declarativa es más rigurosa.

Más mantenible. Los Prompts son código: versiones, tests, iteración.

Más portable. Al cambiar de modelo no reajustas a mano; el framework se adapta.

Componentes centrales de DSPy

Signature (firma de tarea): estructura entrada/salida.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

import dspy

class QuestionAnswer(dspy.Signature):
    """Responder preguntas con explicación detallada"""
    question = dspy.InputField(desc="pregunta del usuario")
    answer = dspy.OutputField(desc="respuesta detallada con proceso de razonamiento")

Como la interfaz de una función: qué entra, qué sale y requisitos por campo. No escribes el texto del Prompt, solo la estructura.

Module (módulo): componentes reutilizables que encapsulan técnicas.

# Módulo básico: predicción directa
qa_basic = dspy.Predict(QuestionAnswer)

# Módulo con cadena de pensamiento
qa_cot = dspy.ChainOfThought(QuestionAnswer)

# Módulo ReAct (requiere configurar herramientas)
qa_react = dspy.ReAct(QuestionAnswer, tools=[search_tool, calculator_tool])

Quieres CoT: eliges ChainOfThought; el framework genera el Prompt correspondiente.

Optimizer (optimizador): optimiza la configuración automáticamente.

from dspy.teleprompt import BootstrapFewShot

# Preparar datos de entrenamiento
trainset = [
    dspy.Example(question="¿Qué es la recursión?", answer="La recursión es una función que se llama a sí misma..."),
    dspy.Example(question="Explica el ordenamiento burbuja", answer="El ordenamiento burbuja compara elementos adyacentes..."),
]

# Configurar optimizador
optimizer = BootstrapFewShot(max_bootstrapped_demos=3)

# Optimizar módulo
qa_optimized = optimizer.compile(qa_cot, trainset=trainset)

Genera ejemplos Few-shot, ajusta estructura e itera. Similar a entrenar, pero sobre Prompts, no pesos del modelo.

Ejemplo completo con DSPy

Sistema de Q&A para programación:

import dspy

# 1. Definir Signature
class CodeQA(dspy.Signature):
    """Responder preguntas de programación con explicación clara y ejemplos"""
    question = dspy.InputField(desc="pregunta relacionada con programación")
    answer = dspy.OutputField(desc="respuesta detallada con conceptos y ejemplos de código")

# 2. Configurar modelo de lenguaje
lm = dspy.LM("claude-3-5-sonnet-20241022", api_key="your_key")
dspy.settings.configure(lm=lm)

# 3. Crear módulo (ChainOfThought para razonamiento)
qa = dspy.ChainOfThought(CodeQA)

# 4. Llamada directa
result = qa(question="¿Cómo implementar decoradores en Python?")
print(result.answer)

No escribimos texto de Prompt. ChainOfThought genera uno con guía de cadena de pensamiento; la respuesta incluye razonamiento y explicación.

Para optimizar, añade datos y optimizador:

# 5. Datos de entrenamiento
train_examples = [
    dspy.Example(
        question="¿Qué es una API REST?",
        answer="Una API REST es un estilo de diseño de interfaces de aplicaciones en red..."
    ),
    dspy.Example(
        question="Explica el concepto de ramas en Git",
        answer="Las ramas de Git permiten separar líneas de trabajo independientes del desarrollo principal..."
    ),
]

# 6. Función de evaluación
def evaluate_answer(example, pred):
    """Comprueba palabras clave y longitud razonable"""
    keywords = example.question.lower().split()
    has_keywords = sum(1 for k in keywords if k in pred.answer.lower()) >= 2
    length_ok = len(pred.answer) > 100
    return has_keywords and length_ok

# 7. Optimizar
optimizer = BootstrapFewShot(metric=evaluate_answer, max_bootstrapped_demos=4)
qa_optimized = optimizer.compile(qa, trainset=train_examples)

# 8. Usar módulo optimizado
result = qa_optimized(question="¿Cómo implementar decoradores en Python?")

El optimizador genera Few-shot y ajusta formato sin tuning manual.

Cuándo usar DSPy y cuándo Prompt manual

DSPy no lo resuelve todo.

Escenarios para DSPy:

• Aplicaciones de IA reutilizables
• Estructura de tarea clara y estandarizable
• Datos de entrenamiento disponibles
• Migración entre modelos
• Muchos Prompts difíciles de gestionar a mano

Escenarios para Prompt manual:

• Uso único
• Estructura de tarea difusa
• Sin datos de entrenamiento
• Prototipo rápido
• Tareas simples con Zero-shot

Mi experiencia: en proyectos y sistemas de largo plazo, DSPy compensa el tiempo inicial. Para consultas puntuales, el Prompt manual es más directo.

Precauciones con DSPy

Métricas de evaluación. El optimizador depende de tu función; métricas malas desvían la optimización.

Calidad de los datos. BootstrapFewShot genera ejemplos a partir del trainset; datos malos, ejemplos malos.

No sobreoptimizar. Muchas iteraciones pueden sobreajustar al trainset y empeorar en casos nuevos. Fija un tope razonable.

DSPy apunta a la optimización automática frente al ajuste manual. Para quien construye IA de forma sistemática, vale la pena dominarlo.

Claude vs ChatGPT: mejores prácticas diferenciadas

Claude y ChatGPT son los dos modelos más usados. La misma pregunta: ¿por qué salidas distintas y cómo optimizar cada uno?

Comparación de características

No son reglas absolutas; varían versión y tarea. En general, Claude favorece rigor y estructura; ChatGPT, flexibilidad y velocidad.

Mejores prácticas para Claude

1. Etiquetas XML para restricciones estructuradas

Claude entiende muy bien XML. Envolver contenido mejora la calidad:

Analiza los problemas de rendimiento del siguiente código:

<code>
function processData(data) {
  let result = [];
  for (let i = 0; i &lt; data.length; i++) {
    result.push(transform(data[i]));
  }
  return result;
}
</code>

Devuelve el análisis en este formato:

<analysis>
[análisis de problemas de rendimiento]
</analysis>

<suggestions>
[recomendaciones de optimización]
</suggestions>

Las etiquetas separan entrada y formato de salida. Claude respeta la estructura y no mezcla análisis con sugerencias.

2. Patrón rol + restricciones + ejemplo

Claude toma en serio rol y restricciones. Estructura completa:

Definición de rol:
Eres un ingeniero senior de optimización de rendimiento con 8 años en backend Java. Identificas cuellos de botella y propones planes aplicables.

Restricciones de la tarea:
- Señala cuellos de botella concretos (no digas solo «se puede optimizar»)
- Las sugerencias deben incluir ejemplos de código
- Si una optimización tiene riesgo, indícalo claramente

Ejemplo de salida:
<analysis>
Problema: creación frecuente de objetos en el bucle, posible presión de memoria.
Ubicación: bucle for en líneas 3-5.
</analysis>
<suggestions>
Sugerencia 1: preasignar tamaño del array.
Código: let result = new Array(data.length);
Riesgo: sin riesgo evidente.
</suggestions>

Ahora analiza este código:
[pega tu código]

Claude sabe quién es, qué hacer y cómo debe verse la salida.

3. Aprovechar el contexto largo

200K tokens permiten archivos completos sin truncar:

Analiza este archivo de código completo y encuentra todos los posibles problemas de rendimiento:

Código completo:
<code>
[pega el archivo entero, cientos de líneas]
</code>

Analiza módulo por módulo con problemas y recomendaciones.

128K de ChatGPT basta en muchos casos; en documentos muy largos Claude tiene ventaja.

Mejores prácticas para ChatGPT

1. Restricciones explícitas de formato

ChatGPT es flexible y a veces cambia el formato. Hay que acotarlo:

Analiza el rendimiento del código. El formato de salida debe ser:

## Análisis de problemas de rendimiento
- Problema 1: [descripción concreta]
- Problema 2: [descripción concreta]

## Recomendaciones de optimización
| Problema | Sugerencia | Ejemplo de código |
|-----|-----|---------|
| [Problema 1] | [Sugerencia] | [Código] |

Código:
[pega el código]

Markdown (## encabezados, tablas) hace que ChatGPT siga el formato.

2. Ajustar el parámetro temperature

temperature = 0: más determinista y consistente; 0.7-1: más creativo y variado.

# Salida determinista (código, análisis de datos)
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0
)

# Salida creativa (copywriting, diseño)
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0.8
)

Claude API tiene controles similares, pero temperature en ChatGPT se nota más.

3. Guía paso a paso

En tareas complejas ChatGPT puede saltar pasos. Divídelas:

Completa esta tarea paso a paso:

Paso 1: Lista los módulos funcionales principales del código
Paso 2: Analiza el rendimiento de cada módulo
Paso 3: Identifica cuellos de botella
Paso 4: Propón plan de optimización

Empieza por el Paso 1.

Salida por pasos reduce errores por saltos.

Mismo objetivo, Prompts distintos

Extraer información de producto de un texto.

Versión Claude:

Extrae la información del producto del siguiente texto:

<text>
[texto de presentación del producto]
</text>

Formato de salida:
<product_info>
<name>[nombre del producto]</name>
<price>[precio]</price>
<features>
<feature>[característica 1]</feature>
<feature>[característica 2]</feature>
</features>
</product_info>

Versión ChatGPT:

Extrae información del producto del texto en formato JSON.

Texto:
[texto de presentación del producto]

Ejemplo de formato:
{
  "name": "nombre del producto",
  "price": "precio",
  "features": ["característica 1", "característica 2"]
}

Sigue estrictamente esta estructura JSON; no añadas otros campos.

Diferencia: XML para Claude; JSON + restricciones explícitas para ChatGPT.

Recomendaciones de elección

• Razonamiento riguroso y salida estructurada: prioriza Claude
• Creatividad y prototipo rápido: prioriza ChatGPT
• Documentos largos o archivos de código completos: prioriza Claude (200K)
• Generación de código y Q&A técnica: ambos excelentes, estilos distintos
• Copywriting y diseño creativo: prioriza ChatGPT (temperature más alta)

En proyecto real puedes elegir por tarea o comparar ambos modelos. Los Prompts deben adaptarse a cada uno; usar el estilo equivocado empeora mucho el resultado.

Evaluación e iteración de Prompts

Hemos visto muchas técnicas, pero falta responder: ¿cómo saber si tu Prompt funciona? Sin evaluación, optimizar es a ciegas.

Dimensiones de evaluación: cuatro métricas centrales

Un buen Prompt debe cumplir en cuatro dimensiones:

Precisión. ¿La salida es correcta? Es la más importante y la más difícil de medir. En tareas objetivas (cálculo, hechos) basta comparar con la respuesta correcta. En tareas subjetivas (creatividad, diseño) se evalúa si cumple expectativas.

Ejemplos de evaluación:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

• Matemáticas: comparar resultado con la respuesta correcta
• Código: ejecutar y pasar tests
• Q&A: comprobar puntos de información correctos
• Copy: puntuación manual o métricas (longitud, cobertura de palabras clave)

Consistencia. ¿La calidad es estable en varias llamadas? Baja consistencia = hoy bien, mañana mal; no sirve en producción.

Método: misma tarea 10 veces y medir variación. Mucha fluctuación = problema de consistencia.

Seguridad. ¿Contenido dañino, fugas de privacidad o sesgos? Crítico en soporte, moderación, etc.

Método: reglas de detección o herramientas de evaluación de seguridad.

Eficiencia de costes. ¿El consumo de Tokens es razonable? Prompt largo = caro; corto = peor calidad. Hay que equilibrar.

Método: registrar Tokens por llamada y comparar versiones.

Herramientas de evaluación

DeepEval. Framework open source con métricas de precisión, consistencia, relevancia, etc. Ideal para pruebas por lotes.

from deepeval import evaluate
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

metrics = [
    AnswerRelevancyMetric(threshold=0.7),
    FaithfulnessMetric(threshold=0.8)
]

evaluate(test_cases, metrics)

Promptfoo. CLI para probar Prompts en lote, comparar modelos y generar informes. Validación rápida.

promptfoo eval --prompts my_prompt.txt --providers openai:gpt-4 --tests test_cases.yaml

OpenAI Evals. Framework oficial, orientado a capacidad del modelo, también útil para Prompts.

Patrón común: conjunto de prueba → ejecución por lotes → puntuación automática → informe. Mucho más eficiente que pruebas manuales.

Flujo de pruebas A/B

Al mejorar Prompts, A/B es el método riguroso:

Paso 1: conjunto de prueba. 20-50 tareas típicas, escenarios variados.

Paso 2: métricas. Según la tarea: Q&A → precisión + cobertura; código → tasa de paso + calidad.

Paso 3: línea base. Prompt actual sobre el conjunto; puntuaciones de referencia.

Paso 4: versión mejorada. Según fallos: baja precisión → CoT; mala consistencia → formato más estricto.

Paso 5: comparación. Mismo conjunto con la nueva versión; adoptar si mejora métricas.

Paso 6: iteración. Si el avance es poco, analizar y repetir hasta el objetivo.

Tabla simplificada de registro:

Cada cambio debe quedar registrado para trazabilidad.

Gestión de versiones de Prompt

Los Prompts son código y necesitan versionado:

Numeración. v1, v2, v3… con fecha y cambio principal.

Registro de cambios. Qué cambió, por qué y resultado de pruebas.

## Registro de versiones del Prompt

### v3 (2026-04-15)
Cambio: 3 ejemplos Few-shot y restricciones de formato
Motivo: v2 con mucha variación en consistencia
Prueba: precisión 78%→82%, variación ±10%→±5%

### v2 (2026-04-10)
Cambio: guía CoT «piensa paso a paso»
Motivo: v1 con baja precisión en razonamiento complejo
Prueba: precisión 65%→78%

### v1 (2026-04-05)
Versión original sin optimización especial
Prueba: precisión 65%, variación ±20%

Almacenamiento. Prompts y datos de prueba juntos; Git o herramientas dedicadas.

Claves de la iteración

No cambiar demasiadas cosas a la vez. Una variable por iteración: primero CoT, luego Few-shot, no ambos juntos.

Vigilar costes. Más precisión con el doble de Tokens puede no compensar.

Registrar intentos fallidos. Evita repetir errores.

Objetivo con tope. P. ej. 80% de precisión y parar. La optimización infinita tiene rendimientos decrecientes.

Evaluación e iteración cierran el ciclo. Sin evaluación no sabes si va bien; sin iteración no mejoras. Con ambas, Prompt Engineering es ingeniería de verdad.

Conclusión

La idea central: Prompt Engineering pasa de «mística» a «ingeniería».

El marco de tres capas indica qué técnica usar: base para que el modelo entienda, razonamiento para que piense, sistema para que sea gestionable. CoT y ReAct son las técnicas de razonamiento más prácticas hoy; DSPy apunta a optimización automática. Claude y ChatGPT requieren Prompts distintos: XML y restricciones para Claude; formato explícito y temperature para ChatGPT. La evaluación es la pieza final; sin ella no hay optimización científica.

Puedes hacer tres cosas ahora:

Revisar tus Prompts actuales. ¿En qué capa están? ¿Problemas de estabilidad, coste o formato?

Probar DSPy una vez. Si tu proyecto encaja, configura un módulo simple y siente la optimización automática.

Definir tu estándar de evaluación. Conjunto de prueba, métricas clave, prueba base. Con datos, la optimización tiene dirección.

Prompt Engineering requiere práctica, pero con metodología dejas de «afinar a ciegas». Espero que este marco te ayude. Comentarios bienvenidos.

Referencias

• PromptingGuide.ai — Guía oficial de Prompt Engineering
• DSPy Official — Sitio del framework DSPy de Stanford
• Claude Prompt Engineering Best Practices — Documentación oficial de Anthropic
• Chain-of-Thought Prompting Elicits Reasoning — Artículo de Wei et al. 2022
• A Systematic Survey of Prompt Engineering — Revisión sistemática 2025