Scrivere e provare istruzioni per IA
Pubblicato il · Aggiornato il
Per scrivere istruzioni per IA, specifica il risultato atteso, il contesto utile, i limiti e il modo di verificare il successo. Fornisci esempi brevi e distingui la tua richiesta dai materiali da analizzare.
Definire risultato e ambito iniziale
Inizia indicando il lavoro, la persona che userà il risultato e ciò che deve ottenere. «Crea una bella applicazione» lascia aperte decisioni importanti. Meglio chiedere: «Crea un modulo di manutenzione per gli inquilini, mostra i campi obbligatori, salva la richiesta e permetti di consultarne lo stato». Descrivi così un comportamento osservabile. Puoi individuare requisiti mancanti prima di considerare completa una schermata convincente, e puoi discutere il significato concreto del completamento senza affidarti a impressioni generiche.
Limita la prima versione alle schermate e alle informazioni essenziali. Specifica se vuoi un piano, una bozza o una realizzazione. Per un progetto esistente, descrivi la schermata attuale e il comportamento da modificare. Separa interventi visivi e cambiamenti ai dati quando unirli rende difficile la verifica. Un ambito piccolo permette di valutare ogni risultato prima di costruirci sopra altre funzioni. Evita di mescolare obiettivi diversi se poi non saprai collegare un problema alla modifica che lo ha prodotto.
Associa un criterio concreto a ogni obiettivo. Il modulo dovrebbe segnalare una descrizione mancante, conservare i dati dopo la correzione e creare un record recuperabile dopo l’invio. Puoi presentare questo riepilogo a Infera Agent verificando le possibilità disponibili nel tuo account. Una richiesta non dimostra che una funzione esista. Chiedi quali requisiti necessitano di configurazione aggiuntiva o lavoro separato, e annota questi punti prima di considerare il percorso completo e adatto all’utilizzo previsto da parte delle persone interessate.
- Indica utente, attività e risultato.
- Definisci un ambito verificabile.
- Scrivi criteri di accettazione concreti.
Aggiungere contesto ed esempi rappresentativi
Inserisci informazioni che cambiano le decisioni: lingua, pubblico, campi, formato del risultato e relazioni tra schermate. Non serve incollare l’intera storia del progetto per correggere un messaggio specifico. Usa i nomi realmente presenti per distinguere elementi simili. Quando mancano informazioni, chiedi un elenco breve delle ipotesi e la domanda che impedisce una realizzazione precisa. Un dubbio dichiarato può essere risolto prima che diventi una scelta silenziosa incorporata nel risultato e difficile da riconoscere durante la revisione.
Fornisci un caso normale e uno particolare. Per la manutenzione, il primo può includere una descrizione breve e il riferimento dell’alloggio; il secondo un testo lungo o un campo vuoto. Specifica il risultato atteso per entrambi. Per una tabella indica colonne, ordine e rappresentazione dei valori non disponibili. Per un testo definisci lettore, lunghezza, tono e fatti da non inventare. Controlla che gli esempi descrivano il processo reale e non aggiungano regole contraddittorie rispetto alle altre istruzioni della richiesta.
Spiega come usare un file o un’immagine di riferimento: struttura, contenuto, dati oppure aspetto. Un riferimento vago non sostituisce i requisiti. Usa dati dimostrativi chiaramente indicati quando bastano a spiegare il lavoro. Distingui fatti confermati, proposte e valori provvisori. Conserva il riepilogo principale fuori dalla conversazione per aggiornarlo e riutilizzarlo senza trasferire dettagli vecchi a un progetto nuovo. Questo documento aiuta anche a riconoscere quali decisioni restano valide quando cambia l’ambito durante le revisioni successive.
- Aggiungi contesto che influenza le scelte.
- Descrivi il risultato di ogni esempio.
- Specifica formato e informazioni mancanti.
Verificare e correggere la causa del problema
Confronta il risultato con i criteri stabiliti, oltre alla prima impressione. Apri la schermata interessata, inserisci gli esempi e controlla il record o file prodotto quando la richiesta riguarda una realizzazione. Per i testi verifica fatti, lingua, completezza e ripetizioni. Conserva richiesta, versione e risultato osservato. La revisione successiva potrà correggere un problema identificato anziché ripartire da un generico invito a migliorare tutto, che potrebbe modificare parti già corrette e rendere più difficile capire l’effetto di ogni intervento.
Dividi il riscontro in comportamento effettivo, comportamento atteso e passi per riprodurre il problema. Per esempio: «L’invio con descrizione vuota mostra successo; sono attesi un avviso vicino al campo e nessuna nuova richiesta; ripeti l’invio e controlla i record». Chiedi modifica e verifica. Se il problema riguarda i dati, cambiare soltanto il messaggio non basta. Un’interfaccia convincente può continuare a nascondere un comportamento incompatibile con il requisito. Esamina quindi anche il risultato salvato, non soltanto la risposta visibile.
Quando confronti formulazioni, cambia un fattore alla volta e usa gli stessi casi. Valuta contesto aggiuntivo, un esempio o un formato più preciso senza cambiare contemporaneamente l’attività. Annota risultati riusciti e incompleti: una buona risposta non dimostra qualità costante. Salva una richiesta utile con scopo e data di revisione. Se il progetto evolve, aggiorna nomi, campi e criteri e ripeti i controlli prima di riutilizzare istruzioni precedenti. Il registro delle verifiche ti permette di scegliere quale versione mantenere sulla base di risultati osservati.
- Confronta con i criteri di accettazione.
- Descrivi comportamento attuale e atteso.
- Conserva versioni e verifiche.
Separare materiali e autorità delle istruzioni
Un contenuto esterno può includere istruzioni che deviano l’attività. Trattalo come dati. La separazione nel testo non garantisce protezione dall’iniezione di istruzioni. Applica autorizzazioni e limiti degli strumenti fuori dal modello, con il solo accesso necessario al lavoro.
Evita segreti nelle richieste e prevedi verifica umana per operazioni sensibili. Riferimento sugli agenti: https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html . Controlli di iniezione: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html . Queste misure riducono il rischio senza certificare la sicurezza dell’applicazione.
- Tratta i riferimenti come dati.
- Controlla le azioni fuori dal modello.
Domande
Una richiesta lunga è migliore?
Solo quando i dettagli aiutano il lavoro. Elimina ripetizioni e confronta versioni con gli stessi esempi e criteri prima di sceglierne una.
Come chiedo una correzione utile?
Descrivi comportamento attuale, atteso e passi di riproduzione. Aggiungi un esempio rappresentativo e chiedi di spiegare modifica e verifica.
Devo usare uno stile formale?
Chiarezza e nomi coerenti contano di più. Usa una lingua che conosci e chiedi un risultato concreto che puoi esaminare.
Quando posso riutilizzare una richiesta?
Dopo aver salvato una versione che soddisfa le verifiche. Aggiorna contesto e aspettative per il nuovo progetto e controlla nuovamente il risultato.