Dominar ChatGPT: consejos avanzados para obtener mejores respuestas de IA

Las indicaciones son una especificación de tareas, no una redacción mágica

Un mensaje fuerte ChatGPT es una especificación compacta para un trabajo. Identifica el resultado, proporciona la evidencia o el contexto que importa, establece límites, define la forma del entregable y le dice al modelo cómo se verificará el resultado. El modelo mental útil no es "¿Qué frase inteligente desbloquea el modelo?" Es "¿Qué necesitaría un colaborador competente para completar esta tarea correctamente?"

La propia guía de OpenAI enfatiza solicitudes claras y específicas, contexto suficiente y refinamiento iterativo. Esos principios siguen siendo duraderos incluso cuando los modelos se vuelven más capaces porque el modelo todavía no puede inferir hechos privados, preferencias ocultas, limitaciones no declaradas o el estándar por el cual se juzgará el trabajo. Los mejores modelos pueden recuperarse de un informe vago con mayor frecuencia; no pueden definir bien un objetivo indefinido en su nombre.

Comience con el artefacto y la definición de hecho.

Muchas indicaciones fallan antes de que comience el modelo porque el artefacto solicitado no está claro. “Analizar esto” podría significar resumirlo, compararlo con un punto de referencia, identificar riesgos, extraer números, cuestionar el argumento o recomendar una acción. Empiece por nombrar lo que necesita recibir.

Una definición de hecho no tiene por qué ser larga. Puede ser una breve lista de aceptación: "un H1, sin enlaces rotos, con capacidad de respuesta móvil, sin nuevas dependencias y aprobado el conjunto de pruebas existente". La clave es que la respuesta puede evaluarse con respecto a algo más que la intuición.

Contexto del paquete para que el modelo pueda usarlo.

El contexto debe responder a las preguntas que cambian materialmente el resultado: quién es la audiencia, qué ya se ha decidido, qué fuente tiene autoridad, qué debe permanecer sin cambios, dónde se utilizará el resultado y qué limitaciones provienen del sistema circundante. Volcar todos los documentos disponibles en un mensaje no es lo mismo que brindar un contexto útil.

Separar instrucciones de evidencia

Etiqueta las partes del mensaje. Una estructura confiable es: objetivo, antecedentes, aportes autorizados, restricciones, entregables y controles. Esto reduce la ambigüedad sobre si un párrafo pegado es una instrucción, una fuente para citar, un ejemplo para imitar o un texto para reescribir.

GOAL
Create a two-page support guide for first-time users.

AUTHORITATIVE INPUTS
- Product requirements below
- Existing support policy below

CONSTRAINTS
- Do not invent features or response times
- Preserve the stated refund policy exactly
- Use plain English

DELIVERABLE
Return the guide, a missing-information list, and a final factual check.

Dar el contexto suficiente más pequeño.

Incluye lo que afecta la decisión y omite el ruido. Para un cambio de código, los archivos relevantes, la pila, el error, el comportamiento esperado y las restricciones son más útiles que todo el repositorio pegado sin explicación. Para un resumen de políticas, el documento de política exacto y las preguntas a responder son más útiles que una colección de artículos no relacionados.

Cuando la entrada sea demasiado grande, divídala deliberadamente en lugar de hacerlo en límites de caracteres arbitrarios. Numere los fragmentos, indique el total, conserve los encabezados y dígale al modelo que no analice hasta que llegue la parte final. El divisor de mensajes y texto largo está diseñado para este tipo de transferencia controlada.

Utilice restricciones para evitar una deriva predecible

Las limitaciones no son decoración. Impiden que el modelo se optimice para el objetivo equivocado. Las restricciones útiles cubren alcance, evidencia, riesgo, estilo, compatibilidad, extensión y cambios prohibidos.

• Scope: "Cambie solo el formulario de pago; no rediseñe la navegación global".
• Evidence: "Utilice sólo el informe adjunto para afirmaciones objetivas. Marque todo lo que el informe no respalde".
• Risk: "No envíe, publique, elimine, compre ni modifique datos de producción".
• Compatibilidad: "Mantener el soporte público API y el Nodo 22 sin cambios".
• Style: "Utilice un tono operativo, párrafos cortos y sin superlativos de marketing".
• Length: "Mantenga el resumen ejecutivo en menos de 180 palabras; incluya los detalles en el apéndice".

Evite restricciones contradictorias. "Sea exhaustivo" y "manténgalo en menos de 300 palabras" pueden ser incompatibles. Clasifique las prioridades cuando existan compensaciones: primero la precisión, luego la integridad y luego la brevedad.

Definir un contrato de salida

Un contrato de salida le dice al modelo cómo organizar el resultado para que pueda usarse inmediatamente. Esto es más específico que pedir "una mesa". Defina las secciones, los campos obligatorios, el orden, los tipos de datos y lo que debe suceder cuando la información no está disponible.

Para un trabajo legible por humanos, un contrato puede requerir: resumen ejecutivo, suposiciones, tabla de evidencia, recomendaciones, riesgos y próximos pasos. Para la salida consumida por la máquina, especifique JSON válido, nombres de campo exactos, valores permitidos y ningún comentario circundante. Para el código, especifique nombres de archivos, complete reemplazos versus diferencias, pruebe comandos y si se requieren comentarios.

Utilice ejemplos cuando la forma importe más que la explicación.

Los ejemplos son poderosos cuando el patrón deseado es difícil de describir: etiquetas de clasificación, voz de marca, reglas de transformación o una estructura de datos particular. Un buen ejemplo puede aclarar más que un párrafo de adjetivos de estilo vagos.

Los ejemplos deben demostrar la regla sin convertirse en una fuente de copia accidental. Muestre un pequeño par entrada-salida y luego indique qué debe generalizarse. Para escribir, identifique las propiedades a preservar (densidad de la oración, franqueza, estilo de evidencia) y no simplemente “escribir así”. Para la extracción, incluya casos extremos como una fecha faltante o una categoría ambigua.

No sobrecargue el modelo con ejemplos que entren en conflicto. Si dos muestras utilizan estructuras diferentes, explique cuál controla.

Divida el trabajo complejo en etapas revisables

Las indicaciones de una sola vez son atractivas porque se sienten rápidas, pero ocultan los errores hasta el artefacto final. Utilice etapas cuando la tarea contenga riesgos de razonamiento o producción separados.

1. Ingest: confirma el objetivo, las entradas autorizadas y las restricciones.
2. Diagnose: identifica lagunas, conflictos y suposiciones.
3. Plan: propone estructura o pasos de implementación.
4. Produce: crea el artefacto.
5. Verificar: pruébelo según los criterios de aceptación.
6. Recuperar: revise solo las piezas fallidas.

Esto no significa que cada interacción necesite seis mensajes separados. Un solo mensaje puede solicitar estas etapas con límites explícitos. Lo importante es que la planificación y la verificación sean resultados visibles, no esperanzas ocultas.

Para proyectos grandes, mantenga un registro de decisiones. Registre el URL elegido, la convención de nomenclatura, la versión, la audiencia y las restricciones para que las indicaciones posteriores no vuelvan a abrir preguntas resueltas.

Preguntar de manera diferente cuando hay herramientas involucradas

Cuando el modelo pueda explorar, ejecutar código, inspeccionar archivos o realizar acciones, especifique tanto el objetivo como la política de la herramienta. Indique qué fuentes son autorizadas, cuándo se requiere verificación web, qué se puede cambiar y qué requiere confirmación.

Navegación e investigación

Solicite la jerarquía de fuentes: primero la documentación oficial, luego la investigación primaria, los archivos o los informes acreditados. Requerir fechas para reclamos urgentes. Dígale al modelo que distinga los hechos derivados de la fuente de la inferencia. Una bibliografía extensa no es útil si no respalda las afirmaciones que se hacen.

Herramientas de código y archivos

Requerir inspección antes de editar. Especifique la raíz del repositorio, la rama de destino, el comando de compilación, los archivos que no deben cambiar y la entrega esperada. Solicite un parche mínimo, pruebas y un resumen de diferencias final. Para los archivos generados, se requiere una reconstrucción determinista en lugar de ediciones manuales que la próxima compilación sobrescribirá.

Acciones con efectos secundarios.

Para correo electrónico, publicación, compras, eliminación o cambios de producción, distinga entre redacción y ejecución. "Redactar el correo electrónico" es diferente de "enviarlo". Un buen mensaje indica el destinatario previsto, la información que se puede transmitir y si se requiere confirmación final.

Incorporar la verificación en el mensaje

Los modelos pueden producir errores fluidos. Las instrucciones de verificación deben ser proporcionales a lo que está en juego. Solicite controles que realmente puedan revelar fracasos, no una autoaprobación ceremonial.

Solicite una justificación concisa, suposiciones o verifique los resultados, no una cadena de pensamiento privada y oculta. La evidencia que necesita es el camino observable desde las entradas hasta una salida comprobable.

Recuperarse de una falla sin reiniciar a ciegas

Cuando el resultado sea incorrecto, diagnostique el tipo de falla antes de reescribir todo el mensaje. Los modos de falla comunes incluyen contexto faltante, restricciones conflictivas, un contrato de producción vago, hechos no respaldados, limitaciones de herramientas o una prueba de aceptación que nunca se definió.

Utilice un mensaje de reparación específico

The draft failed these checks:
1. It changed the original refund terms.
2. It omitted the compatibility table.
3. Two claims have no source.

Revise only the affected sections. Preserve the approved structure and all verified text. Return a short change log and the corrected artifact.

Si las reparaciones repetidas crean más desviaciones, restablezca el último artefacto aprobado y vuelva a aplicar solo los cambios verificados. Las charlas largas pueden acumular suposiciones obsoletas; Replantear la fuente actual de verdad es a menudo más rápido que corregir cada giro histórico.

Separe la arquitectura de avisos duradera del ajuste específico del modelo

La parte duradera de un mensaje es el diseño del trabajo: objetivo, evidencia, limitaciones, resultados y controles. El ajuste específico del modelo se asienta sobre esa base. Un modelo puede responder mejor a instrucciones más breves; otro puede beneficiarse de un plan más explícito, delimitadores más estrictos o una solicitud para inspeccionar su trabajo antes de devolver el artefacto final. Esas diferencias son importantes, pero no se debe permitir que oscurezcan una definición débil de la tarea.

Mantenga la especificación estable en un bloque reutilizable y coloque el lenguaje experimental en un bloque de adaptación más pequeño. Esto hace posible comparar modelos sin cambiar el trabajo real. Cuando una respuesta mejora, puede saber si la mejora proviene de un mejor modelo, una mejor especificación o una instrucción especial que debe conservarse.

Utilice un libro de contexto para trabajos de larga duración

Los proyectos largos fracasan cuando las decisiones se encuentran dispersas en docenas de mensajes. Mantenga un libro de contabilidad compacto que contenga el objetivo actual, las decisiones aprobadas, las preguntas no resueltas, los archivos o fuentes dentro del alcance y el próximo entregable. Actualice ese libro mayor después de cada etapa aprobada y proporciónelo al reanudar el trabajo. Esto reduce la repetición de explicaciones y evita que una respuesta posterior revierta silenciosamente una restricción anterior.

Un libro de contabilidad útil distingue los hechos de las decisiones. "El cliente requiere Windows 11" es un hecho del informe. "Utilizar una construcción portátil" es una decisión de diseño. "Confirmar si se permite el acceso de administrador" es una pregunta abierta. Mantener esos estados separados hace que la recuperación sea mucho más fácil cuando la conversación se interrumpe o se traslada a otra herramienta.

Una plantilla de aviso avanzada reutilizable

ROLE
Act as [specific role relevant to the task].

OUTCOME
Create [named artifact] for [audience/use].

AUTHORITATIVE CONTEXT
- [source or facts that control]
- [decisions already made]

TASK
[precise work to perform]

CONSTRAINTS
- [scope boundary]
- [facts or claims that must not be invented]
- [compatibility, tone, length, risk]

OUTPUT CONTRACT
Return:
1. [required section or file]
2. [required table/list/schema]
3. [assumptions or missing-information list]

VERIFICATION
Before finalizing, check [tests or quality criteria].
Report anything you could not verify.

FAILURE HANDLING
If a blocking fact is missing, ask [number] concise question(s).
Otherwise proceed with clearly labeled assumptions.

La plantilla es intencionalmente sencilla. Reemplace los corchetes con información específica de la tarea y elimine las secciones que no importen. El objetivo no es alargar cada mensaje; es para evitar una costosa ambigüedad.

Lista de control de calidad inmediata

• ¿Se nombra el artefacto solicitado?
• ¿Está claro el público o el caso de uso?
• ¿Las entradas autorizadas están separadas de las instrucciones?
• ¿Son explícitos los límites del alcance y los cambios prohibidos?
• ¿Está definida la estructura de salida?
• ¿El mensaje dice qué hacer con la información faltante?
• ¿Es necesario verificar las reclamaciones urgentes?
• ¿Están claros los permisos de las herramientas y los efectos secundarios?
• ¿Existe una prueba práctica de aceptación?
• ¿Se puede reparar una sección fallida sin recrear todo?

Una buena motivación es una comunicación disciplinada. El mejor mensaje no es el más elaborado; es el resumen más breve el que hace que la tarea, los límites, la evidencia y la definición de lo realizado sean inequívocos.

Preguntas frecuentes

Lectura relacionada

Fuentes y referencias

• Mejores prácticas de ingeniería de Prompt para ChatGPTOpenAI · primario · Consultado el 2026-08-01
• ¿Cómo creo un buen mensaje para un modelo de IA?OpenAI · primario · Consultado 2026-08-01
• Guía de indicaciones GPT-5OpenAI · primario · Consultado 2026-08-01
• OpenAI Modelo SpecOpenAI · primario · Consultado 2026-08-01