Escribir instrucciones para IA: objetivos claros y resultados comprobables
Publicado el · Actualizado el
Para escribir instrucciones para IA, especifica el resultado, el contexto necesario, los límites y cómo comprobar el éxito. Aporta ejemplos pequeños y distingue tu petición de los materiales que deben analizarse.
Define el resultado y el alcance inicial
Empieza por nombrar la tarea, la persona que utilizará el resultado y lo que necesita conseguir. «Crea una aplicación excelente» deja decisiones importantes sin resolver. Es más concreto pedir: «Crea un formulario de mantenimiento para inquilinos, muestra los campos obligatorios, guarda la solicitud y permite consultar su estado». Así describes un comportamiento observable y puedes detectar requisitos ausentes antes de aceptar una pantalla atractiva como solución completa. También facilitas una conversación sobre qué significa terminar correctamente el trabajo.
Limita la primera versión a pantallas e información esenciales. Indica si buscas un plan, un borrador o una implementación. En un proyecto existente, describe la pantalla actual y el comportamiento que quieres cambiar. Separa cambios visuales de cambios en datos guardados cuando combinarlos dificulte la revisión. Un alcance pequeño permite evaluar cada resultado antes de construir otra función sobre él. Evita mezclar objetivos distintos si después no podrás reconocer qué modificación produjo el problema ni cómo comprobarla.
Escribe un criterio observable para cada objetivo. El formulario debería advertir de una descripción ausente, conservar los datos tras corregirlos y generar un registro que pueda encontrarse después del envío. Puedes presentar este resumen a Infera Agent mientras verificas las opciones disponibles en tu cuenta. Una petición no demuestra que exista una función concreta. Pregunta qué requisitos necesitan configuración adicional o trabajo separado y documenta esos puntos antes de considerar que todo el recorrido está listo para usarse.
- Nombra usuario, tarea y resultado.
- Define un alcance revisable.
- Establece criterios de aceptación.
Aporta contexto útil y ejemplos representativos
Incluye información que influye en las decisiones: idioma, público, campos, formato de salida y relaciones entre pantallas. No necesitas pegar todo el historial del proyecto para corregir un mensaje específico. Usa los nombres que aparecen realmente para distinguir elementos parecidos. Si falta información, solicita una lista breve de supuestos y la pregunta que impide completar correctamente la tarea. Una incertidumbre explícita puede resolverse antes de que se convierta en una decisión silenciosa dentro del resultado generado.
Presenta un caso habitual y una excepción. Una solicitud de mantenimiento puede incluir una descripción corta y una referencia de vivienda; la excepción podría contener un texto largo o un campo vacío. Explica el resultado esperado en ambos casos. Para una tabla, define columnas, orden y representación de valores no disponibles. Para un texto, indica lector, extensión, tono y hechos que no deben inventarse. Revisa los ejemplos para comprobar que describen tu proceso real y no introducen reglas contradictorias o ambiguas.
Explica cómo debe utilizarse un archivo o una imagen de referencia: estructura, contenido, datos o apariencia. Una referencia vaga no sustituye los requisitos. Usa datos de ejemplo claramente identificados cuando basten para demostrar el trabajo. Separa hechos confirmados de sugerencias y valores provisionales. Conserva el resumen principal fuera de la conversación para poder actualizarlo y reutilizarlo sin trasladar detalles antiguos a otro proyecto. Esto también facilita reconocer qué información sigue siendo válida cuando el alcance cambia durante las revisiones.
- Incluye contexto que cambie decisiones.
- Explica el resultado de cada ejemplo.
- Define formato y datos pendientes.
Comprueba y corrige la causa del problema
Compara el resultado con los criterios acordados, no solo con su primera impresión. Abre la pantalla correspondiente, introduce los ejemplos y examina el registro o archivo producido cuando la tarea sea de implementación. En textos, revisa hechos, idioma, cobertura y repetición. Guarda la petición, su versión y el resultado observado. La siguiente ronda podrá corregir un problema identificado en lugar de empezar con otra petición general para mejorar todo, que podría alterar partes ya adecuadas y complicar la evaluación.
Divide la corrección en comportamiento real, comportamiento esperado y pasos para reproducirlo. Por ejemplo: «Enviar una descripción vacía muestra éxito; debería aparecer un aviso junto al campo y no crearse una solicitud; repite el envío y revisa los registros». Pide el cambio y su comprobación. Si el problema afecta a los datos, cambiar únicamente el mensaje no basta. Una interfaz convincente puede ocultar que el comportamiento sigue incumpliendo el requisito. Revisa el resultado persistente además de la respuesta visible.
Al comparar formulaciones, cambia un factor cada vez y utiliza los mismos casos. Evalúa contexto adicional, un ejemplo o un formato más preciso sin reemplazar simultáneamente la tarea. Anota casos satisfactorios e incompletos; una respuesta acertada no demuestra rendimiento constante. Guarda una petición útil con su finalidad y fecha de revisión. Cuando evolucione el proyecto, actualiza nombres, campos y criterios, y repite las comprobaciones antes de reutilizar instrucciones anteriores. El registro de resultados permite decidir qué versión conservar con evidencia concreta.
- Compara con los criterios definidos.
- Describe realidad, expectativa y reproducción.
- Guarda versiones y comprobaciones.
Separa referencias y autoridad de las instrucciones
El contenido externo puede intentar redirigir la tarea mediante instrucciones incrustadas. Trátalo como datos. Separarlo en el texto no garantiza protección frente a la inyección de instrucciones. Aplica autorización y límites de herramientas fuera del modelo, con acceso mínimo para la tarea.
Evita secretos en las peticiones y exige revisión humana de operaciones sensibles. Referencia sobre agentes: https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html . Controles de inyección: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html . Estas medidas reducen el riesgo; no certifican la seguridad de la aplicación.
- Trata las referencias como datos.
- Controla las acciones fuera del modelo.
Preguntas
¿Una petición más larga es mejor?
Solo si los detalles ayudan a la tarea. Elimina repeticiones y compara versiones con los mismos ejemplos y criterios antes de elegir.
¿Cómo solicito una corrección útil?
Describe comportamiento real, esperado y pasos de reproducción. Incluye un ejemplo representativo y pide explicar el cambio y cómo se comprobó.
¿Necesito un estilo formal?
La claridad y los nombres constantes son más útiles. Emplea un idioma que domines y pide un resultado concreto que puedas revisar.
¿Cuándo puedo reutilizar una petición?
Después de guardar una versión que cumpla tus comprobaciones. Actualiza contexto y expectativas para el nuevo proyecto y verifica nuevamente el resultado.