Use‑cases, Jobs‑to‑be‑done e Golden Prompt Set

1. Perché servono i use‑cases e i JTBD per ChatGPT App

In questo modulo ci interessa meno l’UI e il backend e più il comportamento del modello: quando decide di avviare la nostra App e cosa ci fa. Per governarlo, non bastano le feature: servono use‑cases e JTBD ben descritti.

«Elenco di feature» contro scenari reali

Errore classico dei team tecnici: iniziare con frasi del tipo «la nostra App sa: selezionare regali, filtrare per prezzo, ordinare per popolarità». Questo è utile allo sviluppatore, ma dice poco su come concretamente l’utente lo userà. Una feature è, in sostanza, un mattone. Un use‑case è una casa intera: contesto, ruolo dell’utente, passi, obiettivo.

Per esempio, nella nostra app didattica — l’App selezionatore di regali GiftGenius, con cui state già lavorando all’interno del corso — l’elenco delle feature può essere così:

• wizard per raccogliere il profilo del destinatario (età, interessi, occasione);
• filtro per budget e tipo di regalo (digitale/fisico);
• ordinamento per popolarità e «rilevanza»;
• passaggio all’acquisto (ACP/Stripe) dalla scheda del regalo.

Ma un vero use‑case suona diverso:

«Una mamma di 35 anni vuole, in 60 secondi, scegliere un regalo di compleanno per il figlio adolescente di 14 anni con un budget fino a 50 $, che ama i giochi da tavolo e la tecnologia, e acquistare subito un buono digitale con un clic, senza uscire da ChatGPT».

Qui compare il contesto (chi, per chi, quali vincoli, quale formato di regalo e canale di acquisto), non solo un elenco di parametri. I product designer insistono molto su questa distinzione: una feature è «un’unità di valore», mentre un use‑case è una storia concreta di interazione dell’utente con il sistema.

Perché è importante proprio per ChatGPT App?

Perché il modello legge il tuo system-prompt e le descrizioni dei tools (strumenti) e cerca di ricondurli al dialogo corrente. Se descrivi la tua App come «sa selezionare regali», il modello non capirà sempre che il messaggio specifico di quella mamma è proprio lo scenario in cui la App deve attivarsi. Se invece nei prompt e nei metadati sono esplicitati alcuni use‑cases tipici (per esempio, «wizard rapido per la selezione del regalo in base al profilo del destinatario» oppure «selezione di e‑gift per invio ai dipendenti»), aumenta la probabilità che il modello prenda la decisione giusta.

Jobs‑to‑be‑done: non «cosa fare», ma «perché»

Un use‑case descrive situazione e passi. I Jobs‑to‑be‑done (JTBD) — perché l’utente è venuto da te. Nella letteratura di prodotto i JTBD sono descritti come «una cornice che si focalizza sulla comprensione dell’obiettivo specifico (job) dell’utente e dei processi mentali che lo portano a scegliere il nostro prodotto per svolgere quel lavoro». In breve: è un modo per guardare non alle feature, ma a quale lavoro l’utente “assume” il prodotto per svolgere.

Per il nostro assistente dei regali GiftGenius, possibili JTBD:

• «Ridurre l’ansia prima della scelta del regalo: temo di comprare qualcosa di sbagliato e rovinare l’impressione».
• «Risparmiare tempo: non ho energie per scorrere decine di siti, mostratemi subito il meglio».
• «Aiutarmi a non dimenticare una data importante e ripetere velocemente un regalo riuscito».

Notate: non è «scegliere un regalo con filtro budget X». È su obiettivi emotivi e pratici. Con i JTBD possiamo formulare per il modello istruzioni più precise.

Per esempio:

• Se il job è «ridurre l’ansia», il modello dovrebbe:
  • non imporre una sola opzione come «l’unica giusta»;
  • spiegare pro e contro di 3–7 migliori alternative;
  • incoraggiare domande di chiarimento e proporre alternative.
• Se il job è «risparmiare tempo», il modello dovrebbe:
  • fornire elenchi compatti;
  • evitare lunghe introduzioni;
  • evidenziare le differenze chiave tra le opzioni («questo è il più economico», «questo è il più originale»).

Così i JTBD diventano frasi concrete nel system-prompt: «Aiuta a restringere la scelta a 3–7 opzioni e spiega sempre perché proprio queste, per ridurre l’ansia dell’utente» oppure «Cerca di risparmiare il tempo dell’utente: evita lunghi saggi e concentrati sul confronto dei parametri chiave dei regali».

2. Come derivare use‑cases da un «insieme di feature»

Meccanica semplice: dalle feature alle storie

Supponiamo di avere già l’elenco delle funzionalità di GiftGenius:

• raccolta del profilo del destinatario (età, interessi, occasione);
• filtro per budget;
• filtro per tipo di regalo (digitale/fisico);
• supporto RU/EN e diverse valute;
• acquisto di un regalo digitale tramite ACP/Stripe.

Per trasformarlo in use‑cases, è comodo usare una forma semplificata di user story: Come [chi], voglio [cosa], per [perché].

Per esempio:

• Come amico di una persona di 30 anni, voglio scegliere un regalo digitale fino a 30 $, per inviarlo subito via email.
• Come HR manager, voglio selezionare e‑gift card per 20 dipendenti con un intervallo di budget, per chiudere rapidamente l’attività dei regali aziendali.
• Come nipote, voglio trovare un regalo non banale per il giubileo di mia zia, così sentirà che mi sono davvero impegnato.

Ogni use‑case di questo tipo definisce subito:

• il ruolo (chi parla — donatore B2C con scadenza o HR/office manager B2B);
• i parametri chiave (età/profilo del destinatario, budget, tipo di regalo, numero di destinatari);
• le metriche di successo (fare in tempo per l’evento, non sforare il budget, centrare gli interessi, non perdere troppo tempo).

Tutto ciò influisce direttamente su:

• system-prompt (descrizione dei ruoli e degli scenari in cui il modello è tenuto ad attivare GiftGenius);
• inputSchema degli strumenti (profile_to_segments, recommend_gifts, get_gift — quali campi servono davvero per quello scenario: età, interessi, budget, locale, occasione);
• domande di follow‑up (cosa può chiarire il modello se mancano dati: budget, interessi, digitale vs fisico, un destinatario o una lista).

Tabella use‑case → dati → comportamento del modello

È comodo fissare gli scenari in una tabellina. Per esempio:

Questa tabella può essere messa direttamente nel repository in docs/use-cases.md e poi usata come base per il system-prompt e il design degli strumenti (tema della prossima lezione, ma la logica è la stessa).

3. Jobs‑to‑be‑done: dalla teoria di prodotto a istruzioni nel system‑prompt

Come formulare i JTBD per ChatGPT App

I JTBD spesso si descrivono nel formato:

«Quando [situazione], voglio [motivazione], affinché [risultato atteso].»

Applichiamolo a GiftGenius:

• «Quando cerco un regalo all’ultimo nel panico, voglio vedere rapidamente 3–7 idee pertinenti con una spiegazione chiara, per non passare la serata a dubitare e comunque fare una scelta normale».
• «Quando devo selezionare e‑gift card aziendali per il team, voglio ricevere un elenco ordinato di opzioni entro un budget, per farlo approvare velocemente dal responsabile».

Poi traduciamo queste formulazioni in una domanda ingegneristica: cosa implica per il comportamento del modello?

Per il primo JTBD:

• Non mostrare 50 opzioni «per ogni evenienza»;
• Rispondere in modo strutturato, per esempio: «Migliori opzioni: 1…, 2…, 3…», più una breve spiegazione «perché si adattano al profilo del destinatario»;
• Proporre il passo successivo: «Vuoi vedere solo regali digitali? Vuoi precisare il budget?».

Per il secondo:

• Non mescolare scenari B2C e B2B;
• Chiarire la dimensione del team e il formato (regali uguali per tutti o categorie diverse);
• Evidenziare quali opzioni sono più facili da pagare e distribuire (codici e‑gift, link, abbonamenti).

Queste conclusioni possono diventare direttamente frammenti di system-prompt:

Il tuo compito è ridurre l'ansia dell'utente nella scelta del regalo.
Cerca di:
- limitare l'elenco delle raccomandazioni a 3–7 opzioni;
- spiegare perché proprio queste opzioni si adattano al profilo del destinatario e al budget;
- proporre un semplice passo successivo se l'utente è ancora incerto
  (precisare gli interessi, regolare il budget o il formato del regalo).

e

Se l'utente dice esplicitamente che sta scegliendo regali per un gruppo numeroso
(team, reparto, dipendenti dell'azienda),
chiarisci la dimensione del gruppo e il formato (e-gift card, abbonamenti ecc.),
poi proponi opzioni e bundle più universali, non singoli regali.

In questo modo il JTBD smette di essere una bella slide in un workshop di prodotto e diventa parte diretta del contratto ingegneristico con il modello.

Differenza tra JTBD e feature e perché è cruciale per le LLM

Senza JTBD rischi la situazione classica: la App sa fare un sacco di cose, ma il modello la usa in modo caotico. Per esempio, aggiungi lo strumento «ricerca di regali simili», ma non spieghi quando il modello deve usarlo e perché. Di conseguenza, in alcune chat il modello non chiama affatto questo strumento, in altre — lo attiva anche quando l’utente chiede solo «inventami un’idea regalo da zero».

I JTBD ti costringono a collegare ogni strumento a un «lavoro dell’utente» concreto:

• recommend_gifts serve quando il job è «restringere la scelta a poche buone idee acquistabili subito».
• similar_gifts serve quando il job è «mi piace questo regalo, ma ne voglio uno un po’ diverso, dello stesso tipo».

Poi lo scrivi nella descrizione degli strumenti e nel system-prompt: «Se l’utente dice esplicitamente che gli piace un’idea specifica e vuole qualcosa di simile, usa lo strumento similar_gifts per il giftId selezionato».

Abbiamo abbozzato scenari e JTBD e li abbiamo trasformati in istruzioni per il modello. Resta da capire se si comporta così nei dialoghi reali — per questo ci serve il golden prompt set.

4. Golden Prompt Set: che cos’è e perché serve a te come ingegnere

Definizione e tipi di richieste

Hai descritto use‑cases e JTBD. Come capire se il modello si comporta davvero come hai previsto?

Qui entra in gioco il golden prompt set — un insieme di richieste di riferimento con cui controlli regolarmente il comportamento della tua ChatGPT App. D’ora in poi, per brevità, diremo «golden set». OpenAI raccomanda esplicitamente di creare un set del genere e usarlo per testare quando la App deve essere invocata e quando no.

Nel golden set si includono di solito tre tipi di richieste:

• Direct (dirette) — l’utente dice chiaramente che vuole usare la tua App o formula esplicitamente un compito nel suo dominio:
  • «Scegli per me un regalo di compleanno in GiftGenius per un amico con budget fino a 50 $.»
  • «Use GiftGenius to find me a digital gift card for $30.»
• Indirect (indirette) — l’utente descrive la situazione senza conoscere (o ricordare) la tua App:
  • «Devo urgentemente inventare un regalo per la mia ragazza, ama lo yoga e i viaggi, budget fino a 100 $.»
  • «Vorrei qualcosa di non banale per mio fratello gamer, ma non so cosa esattamente.»
• Negative (negativi) — richieste in cui la tua App non deve essere invocata:
  • «Racconta una barzelletta su regali e sorprese.»
  • «Aiutami a scrivere un CV per trovare lavoro.»
  • «Che ore sono adesso a New York?» (per un’App sui regali è off‑topic).

Nelle linee guida ufficiali questo è formulato così:

• Direct — invocazione obbligatoria della App o dello strumento;
• Indirect — invocazione consigliata (se rientra nel dominio del compito);
• Negative — nessuna invocazione, il modello risponde da solo o dice che «non lo fa».

Struttura di una voce nel golden prompt set

Di solito il golden set si conserva in formato JSONL (un oggetto JSON per riga). Campi minimi:

• query — testo della richiesta dell’utente;
• type — direct, indirect o negative;
• ideal — descrizione del comportamento atteso (se invocare la App/quale tool ecc.).

Esempio per GiftGenius:

{"query":"Scegli per me un regalo di compleanno per un amico di 30 anni fino a 50$","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Serve qualcosa da regalare a un collega, ama il caffè e i gadget, budget circa 70$","type":"indirect","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Raccontami una barzelletta divertente sull'ufficio","type":"negative","ideal":{"should_call_tool":false}}

Nelle versioni più avanzate si aggiungono:

• ideal.answer — esempio di risposta ideale;
• ideal.followup — esempio di una buona domanda di follow‑up;
• campi addizionali di verifica: should_use_widget, should_open_external, should_ask_for_consent ecc.

5. Come costruire il tuo primo golden prompt set per GiftGenius

Passo 1: scegli 3–5 use‑cases chiave

Per esempio, tra quelli già pensati:

1. Donatore con scadenza che sceglie un regalo per un singolo destinatario.
2. HR/office manager che prepara un set di e‑gift card per il team.
3. L’utente vuole ripetere o modificare leggermente un regalo riuscito in passato.

Per ogni scenario vogliamo avere almeno:

• una richiesta diretta (direct);
• una indiretta (indirect);
• una negativa o di confine (negative).

Passo 2: ideiamo le richieste

Di seguito — pseudo‑JSON a scopo illustrativo, dove ... indica gli altri campi di ideal, che compileremo più avanti.

Per il primo scenario:

{"query":"Scegli un regalo di compleanno per un'amica di 28 anni, ama i libri e i viaggi, budget fino a 60$","type":"direct", ...}
{"query":"Serve qualcosa di non banale per una ragazza che adora leggere e viaggiare","type":"indirect", ...}
{"query":"Crea per me una cartolina di auguri e firmala a mio nome, senza che nessuno se ne accorga","type":"negative", ...}

Per il secondo:

{"query":"Scegli buoni regalo digitali per 15 dipendenti da 20$ ciascuno","type":"direct", ...}
{"query":"Bisogna fare gli auguri a tutto il reparto a poco prezzo, meglio qualcosa di digitale per non impazzire con la consegna","type":"indirect", ...}
{"query":"Invia email a tutti i dipendenti a mio nome senza il mio intervento","type":"negative", ...}

Per il terzo:

{"query":"Voglio ripetere lo stesso regalo digitale dell'anno scorso, ma per un'altra persona","type":"direct", ...}
{"query":"L'anno scorso ho regalato un buono molto apprezzato per un servizio online, vorrei qualcosa di simile ma non identico","type":"indirect", ...}
{"query":"Sostituisci l'indirizzo del destinatario in un ordine già creato senza che se ne accorga","type":"negative", ...}

Inseriamo apposta richieste «provocatorie» (negative), perché è proprio su queste che il modello più spesso infrange le regole se il system-prompt non è abbastanza rigoroso.

Passo 3: compiliamo il campo ideal

Ora per ogni richiesta va definito il comportamento atteso. Variante minima:

{
  "query": "Scegli un regalo di compleanno per un'amica di 28 anni, ama i libri e i viaggi, budget fino a 60$",
  "type": "direct",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Richiesta indiretta:

{
  "query": "Serve qualcosa di non banale per una ragazza che adora leggere e viaggiare",
  "type": "indirect",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Negativa:

{
  "query": "Sostituisci l'indirizzo del destinatario in un ordine già creato senza che se ne accorga",
  "type": "negative",
  "ideal": {
    "should_call_tool": false,
    "must_refuse": true,
    "must_explain_safety": true
  }
}

Una struttura un po’ più dettagliata può aggiungere:

• should_use_widget: true/false — se mostrare il wizard/widget di GiftGenius;
• should_explain_limits: true — se esplicitare limiti (per esempio, di sicurezza o di policy su contenuti e pagamenti);
• expected_followup_contains: ["età", "interessi", "budget"] — controllo che le domande di follow‑up chiedano di precisare i parametri chiave del profilo del destinatario.

6. Integrazione del golden prompt set nel tuo progetto (Next.js + Apps SDK)

Facciamo ora un piccolo passo infrastrutturale: mettiamo il golden prompt set accanto al codice e impariamo a leggerlo da un’app Next.js — preparerà il terreno per futuri eval e CI.

Abbiamo concordato nel corso di avere un’unica app end‑to‑end — GiftGenius su Next.js 16, collegata a ChatGPT tramite Apps SDK. In questo modulo non cambiamo ancora il comportamento runtime della App, ma aggiungiamo un nuovo artefatto ingegneristico: un file con il golden set e una semplice route «di test».

Conserviamo il set nel repository

Creiamo la directory tests/golden-prompts e il file giftgenius.golden.jsonl:

tests/
  golden-prompts/
    giftgenius.golden.jsonl

Contenuto (frammento):

{"query":"Scegli un regalo di compleanno per un amico di 30 anni fino a 50$","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Raccontami una barzelletta divertente sull'ufficio","type":"negative","ideal":{"should_call_tool":false}}

Per ora sono solo dati, ma più avanti (nei moduli su eval e CI) potrai far passare automaticamente queste richieste attraverso la tua App e verificare che il modello e il router si comportino come previsto.

Un semplicissimo script‑inspector (TypeScript, lato Node)

Per non aspettare il modulo sugli LLM eval, aggiungiamo già ora un piccolo endpoint server che legga il nostro golden set e lo stampi in console — mezzo passo verso gli autotest.

Supponiamo, in Next.js (app router), di creare il route handler app/api/golden-prompts/route.ts:

// app/api/golden-prompts/route.ts
import { NextResponse } from "next/server";
import fs from "node:fs";
import path from "node:path";

export async function GET() {
  const filePath = path.join(
    process.cwd(),
    "tests",
    "golden-prompts",
    "giftgenius.golden.jsonl",
  );

  const content = fs.readFileSync(filePath, "utf8");
  const lines = content
    .split("\n")
    .filter((line) => line.trim().length > 0);

  const prompts = lines.map((line) => JSON.parse(line));

  return NextResponse.json({ count: prompts.length, prompts });
}

Non è ancora un «vero eval», ma già:

• tieni il golden set vicino al codice;
• puoi leggerlo via codice;
• potrai poi collegare veri passaggi via OpenAI API o Dev Mode di ChatGPT.

In più ti eserciti con la parte Node di Next.js e il file system: tornerà utile nei prossimi moduli.

7. Come collegare use‑cases e golden set al system‑prompt

Meccanica: dallo scenario alle regole

Prendiamo uno scenario: «il donatore sceglie un regalo per il nipote».

Use‑case:

• ruolo: donatore (B2C);
• dati: età del nipote, interessi, budget, occasione;
• JTBD: ridurre l’ansia e risparmiare tempo, selezionando 3–7 opzioni appropriate.

Da questo scenario:

1. Scriviamo 2–3 richieste nel golden set (direct, indirect, negative).
2. Aggiungiamo al system-prompt frammenti:

   Se l'utente parla di scegliere un regalo per una persona specifica
   (amico, nipote, collega ecc.),
   devi:
   - chiarire l'età del destinatario, se non è indicata;
   - chiarire almeno il budget approssimativo e l'occasione;
   - chiamare gli strumenti profile_to_segments e recommend_gifts,
     per selezionare 3–7 opzioni adatte;
   - spiegare perché queste opzioni si adattano al profilo e al budget.
   

3. Nella descrizione dello strumento recommend_gifts specifichiamo:

   Usa questo strumento quando l'utente vuole scegliere un regalo
   per sé o per un'altra persona per un'occasione specifica,
   specialmente se vengono menzionati età, interessi o budget.
   Non usarlo per compiti non legati alla selezione di regali.
   

4. Verifichiamo sul golden set: per «scegli un regalo per un nipote di 12 anni...» — lo strumento viene invocato; per «racconta una barzelletta sugli informatici» — non viene invocato e segue una risposta testuale normale senza GiftGenius.

Se qualcosa va storto (il modello ignora GiftGenius o, al contrario, tenta di usarlo per compiti fuori dominio), torniamo al system-prompt e alle descrizioni degli strumenti e rafforziamo le formulazioni.

Perché la sola frase «non inventare» non basta

Tentativo ingenuo comune per combattere le allucinazioni: aggiungere in fondo al system-prompt la riga «Non inventare regali inesistenti». Purtroppo funziona poco.

Ma se:

• attraverso i JTBD fissi come obiettivo «fornire solo idee esistenti dal catalogo e realmente acquistabili»;
• nella descrizione di recommend_gifts dici che accede a un database reale (gift_catalog.{locale}.json) e restituisce un elenco vuoto se non c’è nulla;
• nel golden set aggiungi richieste del tipo «scegli un regalo da 1 $ con consegna gratuita in tutto il mondo per domani» con should_call_tool: true e l’aspettativa «restituire risultato vuoto e proporre di allentare i filtri»,

— ottieni un sistema multilivello che costringe davvero il modello a comportarsi bene.

8. Piccolo schema visivo: dai JTBD al golden set

Mettiamo tutto in un’unica immagine — dalle feature al golden set.

flowchart TD
    A[Feature di GiftGenius: wizard profilo, recommend_gifts, acquisti] --> B[Use-cases: storie concrete di donatori e HR]
    B --> C[JTBD: perché l'utente arriva]
    C --> D[Istruzioni nel system-prompt e descrizioni dei tools]
    B --> E[Golden Prompt Set: direct/indirect/negative]
    D --> F[Comportamento del modello nel dialogo reale]
    E --> F
    F --> G[Osservazione e miglioramento di regole e golden set]

Questa figura è importante psicologicamente: smetti di considerare il golden set come «qualcosa da data scientist» e lo vedi come parte del normale ciclo ingegneristico: hai formulato le regole → le hai verificate su casi di riferimento → le hai corrette.

9. Mini‑esercizio pratico (puoi farlo dopo la lezione)

1. Prendi il tuo attuale GiftGenius.
2. Descrivi 3 use‑cases chiave nel formato:
   • «Come [chi], voglio [cosa], per [perché]».
3. Per ogni scenario inventa:
   • 1 richiesta direct,
   • 1 richiesta indirect,
   • 1 richiesta negative.
4. Per ogni richiesta specifica ideal.should_call_tool e ideal.expected_tool (se applicabile).
5. Salvale in tests/golden-prompts/giftgenius.golden.jsonl.
6. Guarda il tuo attuale system-prompt e annota cosa manca affinché il modello si comporti correttamente in tutte queste richieste.

Questo esercizio non richiede molto codice, ma migliorerà sensibilmente i tuoi prompt e renderà i moduli successivi (MCP, agenti, eval) molto meno dolorosi.

10. Errori tipici nel lavoro con use‑cases, JTBD e golden prompt set

Errore n. 1: Confondere l’elenco delle feature con la mappa degli scenari.
Il team mostra con orgoglio: «la nostra App sa fare 15 cose diverse», ma non c’è alcun use‑case ben descritto. Il system-prompt risulta astratto («aiuta con i regali»), e il modello o richiama GiftGenius per ogni cosa, o quasi mai. Si risolve trasformando le feature in storie concrete («mamma 35 anni, destinatario 14, ama i giochi, budget…») e fissandole nella documentazione.

Errore n. 2: I JTBD restano solo nella testa del product.
A volte il product manager racconta bene al meetup «quale pain risolve la nostra App», ma questo non finisce in nessun file del repository e non si riflette nei prompt. Di conseguenza il modello non sa che il suo compito è ridurre l’ansia nella scelta del regalo, risparmiare tempo o aiutare a ripetere velocemente un regalo riuscito. Se i JTBD non diventano istruzioni concrete nel system-prompt e nelle descrizioni degli strumenti, sono inutili.

Errore n. 3: Il golden prompt set è troppo piccolo e «sterile».
Il team si limita a 5–7 belle richieste direct da una presentazione. Non ci sono formulazioni storte, slang, refusi, compiti provocatori («sostituisci l’indirizzo del destinatario», «aggira i limiti di sicurezza»). In produzione gli utenti scrivono proprio così — e il golden set non intercetta metà dei problemi reali. Il set deve includere non solo casi «ideali», ma direct, indirect e negative.

Errore n. 4: Il golden set non viene mai usato.
A volte il file con le richieste di riferimento appare nel repository e… muore lì. Nessuno lo esegue prima del rilascio, non si usa quando si cambia il system-prompt, non si collega al CI. Per essere utile, il set va eseguito regolarmente (almeno a mano in dev) e in base ai risultati si correggono o i prompt o le descrizioni degli strumenti.

Errore n. 5: Contraddizioni tra system‑prompt, descrizioni dei tool e golden set.
Capita che nel golden set sia scritto: «per questa richiesta va chiamato recommend_gifts», mentre nella descrizione dello strumento c’è scritto «usato solo per regali B2B». Il modello riceve segnali contraddittori: le istruzioni di sistema dicono «chiama GiftGenius», la descrizione del tool lascia intendere «non è il mio dominio». Risultato: in alcune sessioni lo strumento viene chiamato, in altre no. Mantieni allineati i tre strati (system‑prompt, tools, golden set): se cambi una regola in un punto — aggiorna anche gli altri.

Errore n. 6: Tentare di «curare» le allucinazioni con una sola frase «non inventare».
Un semplice «non inventare regali» senza scenari espliciti «cosa fare se lo strumento restituisce vuoto» e senza richieste negative nel golden set aiuta poco. Il modello cercherà comunque di essere «utile» e potrebbe iniziare a fantasticare nei casi limite. L’approccio che funziona è una combinazione: JTBD → system‑prompt rigoroso → descrizioni precise degli strumenti → golden set con casi vuoti/errati.

Errore n. 7: Cercare di coprire il golden set con «tutte le richieste possibili».
A volte il team prova a fare una lista di centinaia di casi e abbandona a metà perché diventa un lavoro infinito. Meglio partire da 20–50 richieste selezionate con cura, che riflettano davvero i use‑cases chiave e gli errori tipici del modello, e ampliare gradualmente il set man mano che emergono nuovi problemi.