- \n
- Sei regole di prompting<\/strong> fanno la differenza fra un costoso procedere per tentativi e un lavoro efficiente con Fable 5.<\/li>\n
- Il contesto batte i comandi:<\/strong> dica al modello il perch\u00e9<\/em>, non solo il cosa<\/em>.<\/li>\n
- Scelga consapevolmente il livello di effort<\/strong> \u2013 non ogni compito richiede il modello pi\u00f9 costoso al livello massimo.<\/li>\n
- Faccia verificare:<\/strong> si faccia dimostrare i risultati invece di fidarsi ciecamente.<\/li>\n
- Meno \u00e8 meglio:<\/strong> con un modello cos\u00ec intelligente, istruzioni brevi e chiare guidano spesso meglio di regolamenti lunghi pagine.<\/li>\n<\/ul>\n\n\n\n
Perch\u00e9 con Fable 5 il prompting funziona diversamente<\/h2>\n\n\n\n
Fable 5 segue istruzioni brevi e chiare meglio dei modelli precedenti \u2013 semplicemente perch\u00e9 ragiona meglio. Spesso \u201ecapisce\u201c la Sua intenzione prima ancora che Lei abbia esplicitato ogni dettaglio. Da qui nascono le sei regole: non sono fine a se stesse, ma sfruttano in modo mirato questo punto di forza.<\/p>\n\n\n\n
Un’avvertenza onesta prima di iniziare: Fable 5 non \u00e8 un modello economico. Costa circa 10 dollari USA per milione di token di input e 50 dollari USA per milione di token di output \u2013 esattamente il doppio di Opus 4.8 (rispettivamente 5 e 25 dollari USA). Per la maggior parte dei compiti di routine non Le serve affatto. La vera arte sta nell’usarlo solo quando ne vale davvero la pena.<\/p>\n\n\n\n
![\"Infografica](\"https:\/\/pletzenauer.com\/wp-content\/uploads\/2026\/07\/infographic.png\")
Le sei regole di prompting per Claude Fable 5 in un colpo d’occhio.<\/figcaption><\/figure>\n\n\n\n Regola 1: dia al modello il \u201eperch\u00e9\u201c<\/h2>\n\n\n\n
Anthropic \u00e8 chiaro: Fable 5 d\u00e0 risultati migliori quando conosce la Sua intenzione. Il contesto collega il compito alle informazioni giuste \u2013 invece di costringere il modello a indovinare l’intenzione. La documentazione propone a senso perfino una formula fissa: \u201eSto lavorando a [il compito pi\u00f9 ampio] per [chi]. Serve [ci\u00f2 che il risultato rende possibile]. Su questa base: [la richiesta].\u201c<\/p>\n\n\n\n
- \n
- Invece di:<\/strong> \u201eScrivimi un’e-mail a un cliente per il ritardo.\u201c<\/li>\n
- Meglio:<\/strong> \u201eSto lavorando a questo progetto pi\u00f9 ampio, ecco il cliente ed ecco la sua richiesta. Con questo contesto, puoi scrivermi un’e-mail sul ritardo?\u201c<\/li>\n<\/ul>\n\n\n\n
Vale per: ogni modello<\/strong>. Chi lavora gi\u00e0 con file di contesto o con un sistema di conoscenza ben strutturato d\u00e0 cos\u00ec al modello anche la possibilit\u00e0 di cercare in modo mirato le informazioni giuste.<\/p>\n\n\n\n
Regola 2: dica esplicitamente cosa NON deve fare<\/h2>\n\n\n\n
In sostanza i modelli di IA prevedono la parola plausibile successiva \u2013 e a volte diventano \u201ecreativi\u201c e fanno cose che Lei non voleva. Il prompting negativo delimita questo spazio. Anthropic procede allo stesso modo nella propria documentazione. Un esempio mira a evitare che Fable 5, con un effort elevato, \u201emetta ordine\u201c senza che glielo si sia chiesto (tradotto a senso):<\/p>\n\n\n\n
\u201eNon aggiungere funzionalit\u00e0, non refattorizzare e non introdurre astrazioni che vadano oltre quanto il compito richiede. Una correzione di bug non ha bisogno di riordino attorno. Fai la cosa pi\u00f9 semplice che funzioni bene.\u201c<\/p><\/blockquote>\n\n\n\n
Il paragone migliore: lo spieghi come a uno stagista. A un principiante si dice come cosa ovvia ci\u00f2 che non<\/em> deve fare, perch\u00e9 non conosce ancora il processo. Il secondo esempio della documentazione traccia esattamente questo confine (tradotto a senso):<\/p>\n\n\n\n
\u201eQuando l’utente descrive un problema, pone una domanda o ragiona ad alta voce \u2013 invece di chiedere una modifica \u2013, il risultato atteso \u00e8 la tua valutazione. Riferisci ci\u00f2 che trovi e fermati. Non applicare alcuna correzione finch\u00e9 non ti viene chiesto esplicitamente.\u201c<\/p><\/blockquote>\n\n\n\n
Vale per: ogni modello<\/strong>.<\/p>\n\n\n\n
Regola 3: lo lasci agire non appena ne sa abbastanza<\/h2>\n\n\n\n
Metta fine alla pianificazione eccessiva. Anthropic formula a questo scopo uno snippet dedicato nella documentazione di Fable 5 \u2013 proprio perch\u00e9 ai livelli di effort alti una singola richiesta pu\u00f2 durare molti minuti, mentre il modello raccoglie contesto, costruisce e si verifica da solo (tradotto a senso):<\/p>\n\n\n\n
\u201eSe hai informazioni sufficienti per agire, agisci. Non ricavare di nuovo fatti gi\u00e0 stabiliti nella conversazione, non rimettere in discussione una decisione che l’utente ha gi\u00e0 preso e non elencare opzioni che comunque non seguirai.\u201c<\/p><\/blockquote>\n\n\n\n
E poi: scelga il livello di effort adatto.<\/strong> Fable 5 offre pi\u00f9 livelli \u2013 low, medium, high, extra high<\/em>. La raccomandazione di Anthropic alla lettera:<\/p>\n\n\n\n
- \n
- high<\/strong> come impostazione standard per la maggior parte dei compiti<\/li>\n
- extra high (xhigh)<\/strong> per i carichi di lavoro pi\u00f9 sensibili alla capacit\u00e0<\/li>\n
- medium oppure low<\/strong> per il lavoro di routine<\/li>\n<\/ul>\n\n\n\n
Interessante: secondo la documentazione, perfino i livelli di effort bassi di Fable 5 superano spesso il livello pi\u00f9 alto dei modelli precedenti \u2013 a costi inferiori. Chi invece fa girare Fable 5 al massimo per tutto<\/em> paga quasi sempre di pi\u00f9. Realisticamente, il modello di punta Le serve solo per una piccola parte dei Suoi compiti.<\/p>\n\n\n\n
Regola 4: si faccia dimostrare che ha finito<\/h2>\n\n\n\n
\u00c8 forse la regola pi\u00f9 importante. A volte i modelli affermano di aver finito \u2013 ma non \u00e8 vero, oppure non hanno verificato nulla. Anthropic riferisce che confrontare i progressi con risultati reali degli strumenti ha quasi eliminato, nei test, le comunicazioni di stato inventate. Inserisca quindi cicli di verifica (tradotto a senso):<\/p>\n\n\n\n
\u201ePrima di comunicare progressi, confronta ogni affermazione con un risultato di uno strumento ottenuto in questa sessione. Riferisci solo il lavoro di cui puoi mostrare le prove. Se qualcosa non \u00e8 ancora verificato, dillo esplicitamente invece di tirare a indovinare. Se un test fallisce, dillo riportando l’output; se un passo \u00e8 stato saltato, dillo.\u201c<\/p><\/blockquote>\n\n\n\n
Il consiglio vale per ogni modello<\/strong> \u2013 e andrebbe idealmente fissato nei Suoi Skills, agent e file di configurazione, invece di essere accodato a ogni singolo prompt.<\/p>\n\n\n\n
Regola 5: non chieda a Fable 5 di rivelare i suoi pensieri<\/h2>\n\n\n\n
Questa regola \u00e8 specifica di Fable<\/strong> \u2013 ed \u00e8 indicata esplicitamente nella documentazione ufficiale. Prompt, Skills o istruzioni di harness che chiedono al modello di riprodurre, trascrivere o spiegare il proprio ragionamento interno come testo di risposta possono attivare la categoria di rifiuto reasoning_extraction<\/em>. La conseguenza: pi\u00f9 fallback su Claude Opus 4.8. Al momento del passaggio controlli quindi i Suoi Skills e system prompt esistenti alla ricerca di formulazioni del tipo \u201espiega il tuo ragionamento\u201c. Se ha davvero bisogno di vedere il reasoning, legga invece i blocchi strutturati thinking<\/em> \u2013 anzich\u00e9 chiederlo al modello.<\/p>\n\n\n\n
Regola 6: dica di meno, non di pi\u00f9<\/h2>\n\n\n\n
All’inizio suona contraddittorio \u2013 per molto tempo si \u00e8 detto che pi\u00f9 contesto \u00e8 meglio. Ma la capacit\u00e0 di Fable 5 di seguire le istruzioni \u00e8 cos\u00ec buona che un’istruzione breve guida la maggior parte dei comportamenti in modo altrettanto affidabile di un regolamento dettagliato \u2013 a condizione che il modello lavori in un buon ambiente, con contesto, strumenti e Skills.<\/p>\n\n\n\n
Questo non<\/strong> \u00e8 in contraddizione con la regola 1: dare il \u201eperch\u00e9\u201c non significa gonfiare tutto. Invece di \u201eregola uno: sii conciso, regola due: \u2026, regola tre: \u2026\u201c spesso basta una breve indicazione come: \u201eApri con il risultato. La tua prima frase dopo aver concluso deve dire cosa \u00e8 successo o cosa hai trovato.\u201c<\/strong> E per le domande di chiarimento: \u201eFermati solo quando il lavoro lo richiede davvero \u2013 in caso di azione distruttiva, di un reale cambiamento di scope o quando solo l’utente pu\u00f2 fornire un contributo.\u201c<\/strong> Vale per: specifico di Fable<\/strong>, nel senso della forte capacit\u00e0 di seguire le istruzioni.<\/p>\n\n\n\n
Bonus: quando Fable passa silenziosamente il compito a Opus 4.8<\/h2>\n\n\n\n
Fable 5 esegue classificatori di sicurezza mirati a tre ambiti: tecniche offensive di cybersecurity (per esempio la costruzione di exploit, malware o strumenti di attacco), contenuti di biologia e life sciences (per esempio metodi di laboratorio o meccanismi molecolari) e l’estrazione del ragionamento riassunto del modello. Se uno di questi classificatori interviene, la richiesta pu\u00f2 terminare con il motivo di arresto refusal<\/em> \u2013 e pu\u00f2 essere inoltrata automaticamente via fallback a Claude Opus 4.8<\/strong>. Importante da sapere: anche ricerca legittima sulla sicurezza o compiti utili di life sciences possono attivare questi meccanismi di protezione. La conseguenza pratica: formuli in modo chiaro e legittimo \u2013 e, se sviluppa tramite API, configuri correttamente il fallback su Opus 4.8.<\/p>\n\n\n\n
Da portare con s\u00e9: download gratuiti<\/h2>\n\n\n\n
\n\ud83d\udcc4 Bigliettino:<\/strong> Scarica la checklist delle 6 regole in PDF<\/a> \u2014 una pagina, da stampare o da tenere accanto allo schermo. In tedesco.<\/p>\n\n\n\n
- extra high (xhigh)<\/strong> per i carichi di lavoro pi\u00f9 sensibili alla capacit\u00e0<\/li>\n
- Meglio:<\/strong> \u201eSto lavorando a questo progetto pi\u00f9 ampio, ecco il cliente ed ecco la sua richiesta. Con questo contesto, puoi scrivermi un’e-mail sul ritardo?\u201c<\/li>\n<\/ul>\n\n\n\n
- Il contesto batte i comandi:<\/strong> dica al modello il perch\u00e9<\/em>, non solo il cosa<\/em>.<\/li>\n