← Volver al listado de tecnologías ← Índice de Mejorar Prompts

Protocolo para Mejorar un Prompt

8 de junio de 2026 Por: Artiko

promptsprompt-engineeringclaudeagentesiaprotocolo

Protocolo para Mejorar un Prompt

Aviso humano: este capitulo no esta optimizado para vos. Es un protocolo ejecutable para un agente IA. Vos solo necesitas invocarlo con: “Lee este tutorial y reescribe mi prompt siguiendo el protocolo” y pegar tu prompt crudo.

Aviso agente IA: lo que sigue es para vos. El usuario te va a pasar un prompt crudo. Tu trabajo es devolverlo reestructurado segun las 7 secciones, sin cambiar la intencion del usuario. Ejecuta en orden, fase por fase. No improvises secciones que no se piden ni inventes contexto: si falta informacion, pregunta.

Modelo mental antes de empezar

Internaliza estas ideas. Si dudas durante el protocolo, relee esta tabla:

Idea	Aplicacion en este protocolo
Un buen prompt separa lo fijo (rol, reglas, tono) de lo variable (datos del usuario)	Nunca mezcles instrucciones con los datos a procesar
El contexto va primero, la instruccion final va al final	Ordena las secciones, no las dejes como las escribio el usuario
Pide comportamiento en positivo (que hacer, no que evitar)	Reescribe “no hagas X” como “haz Y” siempre que se pueda
Definir que hacer si falta informacion evita alucinaciones	Toda tarea sensible necesita una regla de “si faltan datos, dilo”
Los ejemplos ensenan el criterio, no tienen que ser perfectos	Agrega 3 a 5 solo si la tarea es ambigua o tiene formato especifico
No dependas de prefill (relleno del turno del asistente)	Define el formato dentro del prompt o usa structured outputs
Solo info verificable	Si no podes confirmar la intencion del usuario, pregunta; no la inventes

Las 7 secciones de un buen prompt

Este es el marco objetivo. Todo prompt mejorado se evalua y reconstruye contra estas 7 secciones, en este orden:

flowchart TD
    A["1. Contexto<br/>rol + objetivo + para quien"] --> B["2. Datos / Entrada<br/>info variable, separada de las reglas"]
    B --> C["3. Instrucciones<br/>que hacer, pasos numerados si el orden importa"]
    C --> D["4. Criterios<br/>que hace correcta la respuesta + que hacer si faltan datos"]
    D --> E["5. Ejemplos<br/>3 a 5, solo si hay ambiguedad"]
    E --> F["6. Formato de salida<br/>texto / XML / JSON"]
    F --> G["7. Verificacion<br/>autoevaluacion en tareas sensibles"]

No todas las secciones son obligatorias en todos los prompts. Las secciones 1, 3 y 6 casi siempre aplican. Las 4, 5 y 7 dependen de la sensibilidad y ambiguedad de la tarea. La 2 aplica cuando hay datos variables que el modelo debe procesar.

Flujo del protocolo

flowchart LR
    F0["Fase 0<br/>Recibir prompt"] --> F1["Fase 1<br/>Diagnostico"]
    F1 --> F2["Fase 2<br/>Preguntas minimas"]
    F2 --> F3["Fase 3<br/>Reestructurar"]
    F3 --> F4["Fase 4<br/>Ajustes para Claude"]
    F4 --> F5["Fase 5<br/>Autoverificacion"]
    F5 --> F6["Fase 6<br/>Entregar + changelog"]

Fase 0 — Recibir el prompt y delimitar el alcance

Objetivo: tener claro que prompt vas a mejorar y para que modelo.

Identifica el prompt crudo que paso el usuario. Si te paso varias cosas, separa el prompt del resto del mensaje.
Confirma el destino. Por defecto asume Claude (este protocolo nace de las recomendaciones para Claude). Si el usuario indica otro modelo, mantene el marco de 7 secciones pero omite los ajustes especificos de Claude de la Fase 4.
No empieces a reescribir todavia. Primero diagnostica.

Si el usuario no pego ningun prompt, deteneté y pedi el prompt crudo. No inventes uno.

Fase 1 — Diagnostico de las 7 secciones

Objetivo: detectar que secciones ya estan, cuales faltan y cuales estan mal ubicadas.

Recorre el prompt crudo y marca cada seccion:

[ ] 1. Contexto    -> hay rol y objetivo claros?
[ ] 2. Datos       -> los datos variables estan separados de las reglas?
[ ] 3. Instrucciones -> dice exactamente que hacer? el orden esta claro?
[ ] 4. Criterios   -> define que es una buena respuesta y que hacer si faltan datos?
[ ] 5. Ejemplos    -> la tarea es ambigua y se beneficiaria de ejemplos?
[ ] 6. Formato     -> dice como entregar la respuesta?
[ ] 7. Verificacion -> es una tarea sensible que necesita autoevaluacion?

Para cada seccion anota uno de tres estados:

Presente y correcta: la conservas, quiza la reubicas.
Presente pero debil: existe pero hay que reforzarla (ej: instrucciones en negativo, datos mezclados).
Ausente: hay que crearla o decidir que no aplica.

Detecta tambien los problemas tipicos:

Instrucciones escritas en negativo (“no hagas…”) -> reescribir en positivo.
Rol y datos en el mismo parrafo -> separar.
La instruccion principal aparece al inicio en vez del final.
Falta la regla de “si falta informacion, dilo”.
Depende de prefill o de que el modelo “continue” un texto -> reemplazar por formato explicito.

Fase 2 — Preguntas minimas al usuario

Objetivo: completar solo los huecos que no podes inferir con seguridad.

Reglas:

Pregunta una sola vez, agrupando todo lo que necesites.
No preguntes lo que podes inferir razonablemente del prompt. Documenta tu inferencia en vez de preguntar.
Prioriza estas preguntas cuando falten y no sean inferibles:
- Rol/objetivo real (que problema resuelve, para quien).
- Formato de salida deseado (texto libre, XML, JSON con esquema).
- Que hacer si faltan datos (responder igual, pedir aclaracion, decir que no sabe).
- Ejemplos disponibles si la tarea es ambigua.

Si el usuario no responde o dice “usa tu criterio”, avanza con tu mejor inferencia y dejala anotada en el changelog de la Fase 6.

Fase 3 — Reestructurar segun las 7 secciones

Objetivo: reconstruir el prompt en orden, una seccion a la vez. Conserva la intencion original; mejora la forma.

1. Contexto

Define quien es el modelo, para quien trabaja y que problema resuelve. Incluye la motivacion (“para que” sirve la tarea): ayuda al modelo a ajustar la respuesta al objetivo real.

2. Datos / Entrada

Separa la informacion fija (rol, reglas, tono) de la variable (texto del usuario, documentos). Coloca los datos variables en su propio bloque, idealmente con etiquetas XML para delimitarlos.

3. Instrucciones

Describe exactamente que hacer. Si el orden importa, usa pasos numerados. Escribe en positivo. Ejemplo de cadena de analisis:

1. Identifica el objetivo
2. Extrae los datos relevantes
3. Senala contradicciones
4. Evalua si la evidencia es suficiente
5. Entrega una conclusion con su nivel de confianza

4. Criterios

Define que hace correcta una respuesta y, sobre todo, que hacer si faltan datos. Ejemplo: “No inventes detalles. Si falta informacion, dilo explicitamente en vez de suponerla.”

5. Ejemplos

Solo si la tarea es ambigua o tiene un formato especifico. Usa entre 3 y 5, con etiquetas:

<example>
<input>caso del usuario</input>
<output>respuesta esperada</output>
</example>

Los ejemplos no necesitan ser perfectos, pero deben ensenar el criterio aplicable.

6. Formato de salida

Elige segun el consumidor de la respuesta:

Texto con instrucciones de estilo, cuando lo lee una persona.
XML cuando hay secciones jerarquicas que separar.
JSON estructurado cuando otra maquina o API consume la salida.

Ejemplo con XML:

<resumen>explicacion breve</resumen>
<riesgos>lista principal</riesgos>
<recomendacion>siguiente paso</recomendacion>

7. Verificacion

Solo en tareas sensibles (codigo, analisis legal, datos). Pide al modelo que revise su propia respuesta antes de entregarla:

Antes de responder, verifica que:
1. Usaste solo la informacion incluida en el prompt
2. No inventaste datos
3. Incluiste tu nivel de confianza

Organizacion con etiquetas XML

Envuelve cada seccion en etiquetas XML para que el modelo distinga instrucciones, contexto y datos. Esto mejora la consistencia y permite anidar informacion jerarquica. Estructura recomendada del prompt final:

<contexto> ... </contexto>
<datos> ... </datos>
<instrucciones> ... </instrucciones>
<criterios> ... </criterios>
<ejemplos> ... </ejemplos>
<formato_salida> ... </formato_salida>
<verificacion> ... </verificacion>

Fase 4 — Ajustes especificos para Claude

Objetivo: aplicar las recomendaciones propias de Claude. Omite esta fase si el destino no es Claude.

No dependas de prefill. Desde versiones recientes, rellenar el turno del asistente con el inicio de la respuesta ya no es confiable en algunos casos. En su lugar, define el formato dentro del prompt o usa structured outputs.
Structured outputs para JSON. Si necesitas JSON que cumpla un esquema (extraccion de datos, APIs), pidelo via salida estructurada en vez de rogar por JSON en el texto.
Adaptive thinking. Para tareas complejas, permite que Claude decida cuanto razonar segun la complejidad, en vez de forzar un formato de razonamiento rigido.
Parametro effort. Ajusta el esfuerzo segun la tarea: bajo para tareas simples, alto para analisis complejos. Mencionalo como recomendacion de configuracion, no como parte del texto del prompt.

Fase 5 — Autoverificacion contra el checklist

Objetivo: validar el prompt reescrito antes de entregarlo. Recorre el checklist; si algo falla, vuelve a la Fase 3.

[ ] El modelo conoce su rol?
[ ] La tarea esta descrita con claridad?
[ ] El contexto aparece antes de la instruccion final?
[ ] Los datos estan separados de las instrucciones?
[ ] Esta definido que hacer si falta informacion?
[ ] El orden de analisis es claro (pasos numerados si aplica)?
[ ] Hay ejemplos si la tarea es ambigua?
[ ] El formato de salida esta definido?
[ ] Hay criterios de verificacion en tareas sensibles?
[ ] El prompt no depende de prefill?
[ ] Las instrucciones estan en positivo?

Fase 6 — Entregar el prompt mejorado + changelog

Objetivo: devolver al usuario un resultado accionable.

Entrega dos bloques:

Prompt mejorado: el prompt completo y reestructurado, listo para copiar y pegar al LLM, en un solo bloque de codigo.
Changelog: una lista breve de que cambiaste y por que. Ejemplo:
- “Movi el rol al inicio (contexto va primero).”
- “Separe el documento a analizar en un bloque <datos>.”
- “Agregue la regla ‘si faltan datos, dilo’ (evita alucinaciones).”
- “Convertí ‘no seas tecnico’ en ‘usa lenguaje claro para una audiencia no tecnica’ (instruccion en positivo).”
- “Defini el formato de salida como JSON porque lo consume tu API.”
- “Inferi que el publico objetivo es ; confirmalo si no es correcto.”

No agregues secciones que el usuario no necesita solo para llenar el marco. La meta es un prompt mas claro, no mas largo.

Ejemplo de aplicacion

Prompt crudo (entrada)

Resume este informe y no te inventes nada. <texto largo del informe>

Diagnostico

Contexto: ausente (no hay rol ni objetivo).
Datos: presente pero mezclado con la instruccion.
Instrucciones: debil (“resume” sin criterio de longitud ni foco).
Criterios: presente pero en negativo (“no te inventes”).
Formato: ausente.
Verificacion: ausente, y es una tarea sensible (informe).

Prompt mejorado (salida)

<contexto>
Eres un analista que ayuda a un equipo directivo a entender informes tecnicos
extensos en poco tiempo. Tu resumen se usa para tomar decisiones, asi que la
precision importa mas que la brevedad.
</contexto>

<datos>
<informe>
<texto largo del informe>
</informe>
</datos>

<instrucciones>
1. Identifica el objetivo principal del informe.
2. Extrae los 3 a 5 hallazgos mas relevantes para una decision.
3. Senala riesgos o contradicciones si los hay.
4. Entrega un resumen de maximo 200 palabras.
</instrucciones>

<criterios>
Usa unicamente la informacion del informe. Si un dato no esta presente, dilo
explicitamente en vez de suponerlo.
</criterios>

<formato_salida>
<resumen>el resumen en prosa</resumen>
<riesgos>lista de riesgos detectados, o "ninguno"</riesgos>
</formato_salida>

<verificacion>
Antes de responder, verifica que no agregaste informacion ausente en el informe.
</verificacion>

Changelog

Agregue contexto (rol + objetivo + por que importa).
Separe el informe en un bloque <datos> delimitado.
Convertí “resume” en pasos numerados con criterio de longitud.
Reescribí “no te inventes nada” como criterio en positivo: “usa unicamente la informacion del informe”.
Defini formato de salida con XML (resumen + riesgos).
Agregue verificacion por tratarse de una tarea sensible.

Cierre

Un prompt util no se escribe una vez: se construye probando, observando fallos y ajustando. Este protocolo cubre la primera iteracion, la que ordena el prompt segun una estructura solida. Si despues de usarlo el resultado sigue fallando, vuelve a la seccion que corresponda (criterios, ejemplos, formato) y refina.

Fuente

Como escribir buenos prompts para Claude — Platzi

Anterior -> Indice