TL;DR

Il prompt Auditor capovolge l'IA da autrice ad avversaria: dopo che consegna, le comandi di attaccare il proprio output — cercando difetti logici, affermazioni non supportate e angoli mancati — prima di produrre una versione finale indurita. Costa un messaggio di follow-up e regolarmente cattura il fallimento che avresti scoperto a tue spese.

L'analogia

Ogni giornale serio funziona su due persone che non si siedono mai alla stessa scrivania: lo Scrittore e l'Editor.

Il lavoro dello Scrittore è la produzione — trascinare il lettore, far cantare la tesi. Il lavoro dell'Editor è la demolizione. L'Editor cerchia l'affermazione senza fonte, scrive "chi lo dice?" a margine, trova il paragrafo in cui l'argomento si contraddice silenziosamente, e fa la domanda che lo Scrittore sperava nessuno notasse. Crucialmente, l'Editor viene valutato sui difetti trovati, non sulla gentilezza — un editor gentile è un editor rotto. Il giornale è degno di fiducia precisamente perché chi lo controlla non è chi l'ha scritto.

Ecco il problema con l'IA: finora hai parlato con uno Scrittore senza Editor. Il modello che ha prodotto la tua bozza è ottimizzato per produrre testo che fluisce — e quando chiedi allo stesso modello "è buono?", stai chiedendo all'autore di rivedere il proprio manoscritto. Cosa diresti se un romanziere ti dicesse che il suo libro è impeccabile? Lo sgraveresti all'istante. Eppure la gente accetta "sembra fantastico!" da un'IA ogni giorno — e poi scopre, davanti al capo, che l'introduzione contraddiceva la conclusione.

Il prompt Auditor sei tu che assumi l'Editor di proposito. Stesso modello, nuovo contratto: il lavoro non è più "scrivi questo" — il lavoro è "rompi questo". È la mossa del red team del mondo della cybersecurity, dove un team costruisce il sistema e un team rivale viene pagato per attaccarlo prima che lo facciano gli avversari reali. Fuoco amico, di proposito, prima che arrivi quello ostile.

E a differenza di un editor umano, questo lavora in secondi, non si stanca mai della tua terza bozza, e non può essere offeso fino ad ammorbidirsi — perché hai scritto la durezza nelle istruzioni.

Come funziona e lo strumento (modelli di reasoning)

La tecnica è un ritmo in due passi: Bozza, poi Audit. Mai insieme.

Passo 1 — Bozza. Produci il lavoro normalmente, con qualsiasi tecnica si adatti: un prompt one-shot, un'intervista, un formato vincolato. Il cervello che redige e il cervello che audita devono fare turni separati — chiesto di "scrivere e controllare" in un solo messaggio, un modello scriverà con sicurezza e poi si timbrerà da solo.

Passo 2 — Audit. Segui con un comando che ha tre parti portanti:

ParteCosa faEsempio
Assegnazione di ruoloUccide la cortesia dell'autore"Agisci come un Avvocato del Diavolo spietato"
Riscontri contatiForza difetti reali, non vibrazioni"Trova esattamente 3 difetti fatali"
Verdetto trattenutoVieta la conclusione rassicurante"Non riscrivere ancora — solo riscontri, classificati per gravità"

Agisci come un Avvocato del Diavolo spietato e critica la tua risposta precedente. Trova esattamente 3 difetti fatali: errori logici, affermazioni non supportate o angoli mancati che un esperto scettico attaccherebbe. Classificali per gravità. Non riscrivere nulla per ora — solo riscontri.

Perché "esattamente 3"? Perché un "qualche problema?" senza limite invita il modello a recitare sicurezza — "nel complesso è ben strutturato!" — e un audit che si apre con un elogio è un audit già fallito. Un conteggio forza lo scavo: qualcosa deve riempire gli slot numerati, anche in un buon lavoro, e ciò che emerge è di solito l'assunzione che nessuno aveva esaminato. Poi, solo dopo aver letto i riscontri, rilasci il passo tre: "Ora riscrivi l'originale, correggendo tutti e tre i difetti."

È anche dove vive il tocco ibrido sottile: qualsiasi modello può auditare, ma auditare è lavoro di pensiero — e è questo per cui sono costruiti i modelli di reasoning. I modelli di reasoning (come quelli premium disponibili in Uzu) sono addestrati a rallentare e lavorare a un problema passo per passo prima di rispondere, il che li rende sproporzionatamente bravi a catturare il difetto che i modelli veloci scavalcano. Da qui la pipeline professionale: modello veloce per la bozza, modello di reasoning per l'audit. Il modello economico e rapido genera il materiale grezzo; il modello costoso e deliberato spende la sua potenza di fuoco solo sul passaggio che conta — quello che decide se il lavoro sopravvive al contatto con la realtà.

Prima e dopo (i prompt)

Esempio 1 — il business case

È buono questo business plan? Qualche feedback?

L'autore rivede il manoscritto. Torna: prima i punti di forza, un gentile "considera di aggiungere", e un verdetto complessivo di solido. Il plan parte con la sua assunzione fatale intatta.

Agisci come un investitore scettico che ha visto 1.000 pitch. Identifica esattamente 3 difetti fatali in questo business plan — le ragioni per cui uno studio passerebbe oltre. Classifica per gravità, cita la sezione specifica, solo riscontri, nessuna riscrittura.

Ora lo stesso plan affronta l'Editor. I riscontri tornano numerati e scomodi: il modello di ricavi assume un tasso di conversione del 40% senza alcuna evidenza; l'"analisi della concorrenza" omette il maggiore attore; la proiezione di cassa nasconde un vuoto al mese sette. Nessuna di queste è una nota di stile. Tutte sono la differenza tra finanziamento e silenzio.

Esempio 2 — l'argomento

Controlla il mio saggio per errori.

"Errori" è una caccia ai refusi, quindi è ciò che ottieni — grammatica lucidata, logica intatta.

Sei il mio critico più severo. Leggi il mio argomento e trova esattamente 3 punti dove il ragionamento è più debole — salti, premesse non supportate o obiezioni che non ho affrontato. Per ciascuno, esponi il contro-argomento più forte contro di me. Non ammorbidire. Solo riscontri.

L'audit restituisce le due frasi che un avversario citerebbe contro di te — e l'unica obiezione a cui non hai mai risposto perché non l'avevi mai vista. Correggi quelle tre, e l'argomento è pronto per un pubblico che vuole che fallisca.

Esempio 3 — l'email prima dell'invio

Assicurati che questa email suoni giusta.

Controllo del tono. Bene. Ma il pericolo dell'email non era mai il tono — era la frase che ti impegnava accidentalmente a una scadenza che non puoi rispettare.

Prima che la invii: auditala come avvocato contrattualista. Trova esattamente 3 affermazioni che potrebbero essere lette come impegni o responsabilità non intese. Citale una per una, spiega la lettura rischiosa, solo riscontri.

Tre riscontri dopo, una frase è segnalata: "Risolveremo a breve" — che, sotto pressione, diventa una promessa. Viene riformulata. L'email non era mai meglio scritta. Era più sicura da inviare.

Errori comuni

  1. Accettare la prima risposta "sembra fantastico!". Se chiedi con cortesia, il modello valuterà generosamente il proprio compito — la cortesia è stata addestrata più a fondo del rigore. Un audit che restituisce zero riscontri non era un audit; era un complimento. Riesegui con un conteggio: "Trova esattamente 3."
  2. Auditare nello stesso respiro della redazione. "Scrivilo e assicurati che sia buono" collassa l'Editor nello Scrittore. Il modello redige con sicurezza, poi eredita la propria sicurezza come revisore. Due turni, sempre: bozza, poi attacco.
  3. Richieste di audit vaghe. "Critica questo" invita una pappetta lunga un saggio su tono e struttura. Vincola l'audit come vincoleresti qualsiasi output: un ruolo, un conteggio, una classifica di gravità, una regola di non-riscrittura. Anche l'audit è un deliverable.
  4. Saltare l'audit su lavori che "sembrano finiti". La fluenza è esattamente il segnale di completamento sbagliato — ricorda l'illusione della sicurezza: la bozza dal suono impeccabile e la bozza difettosa arrivano nella stessa voce serena. Più si legge bene, più ti serve un passaggio ostile, non meno.
  5. Correggere sintomi, non riscontri. L'audit nomina tre difetti; tu rattoppi una frase per ciascuno e lo chiami finito. Il riscontro di solito punta a un'assunzione — riesaminala, non solo la frase che la trasportava. Poi ri-audita la revisione: "Audita la v2 allo stesso modo."

FAQ

Come faccio a far criticare all'IA il proprio lavoro?

Comandaglielo esplicitamente: assegna un ruolo ostile ("agisci come un Avvocato del Diavolo spietato / investitore scettico / red team"), pretendi una lista contata di difetti ("esattamente 3 difetti fatali"), richiedi la classifica di gravità, e vieta la riscrittura finché non hai letto i riscontri. La struttura in tre parti — ruolo, conteggio, verdetto trattenuto — è ciò che separa un audit vero da un complimento.

Perché l'IA dice che il mio lavoro è buono quando non lo è?

Perché hai fatto una domanda con una sola risposta educata. I modelli sono addestrati su conversazioni accondiscendenti, quindi "è buono?" tira verso "sì, con piccoli suggerimenti". La soluzione non è una domanda migliore — è un contratto diverso: il modello non sta più valutando il lavoro di un amico, viene valutato sui difetti trovati. Cambia gli incentivi e appare l'onestà.

Dovrei usare un modello di reasoning per controllare l'output dell'IA?

Per qualsiasi cosa con conseguenze, sì. I modelli di reasoning — come quelli premium in Uzu — deliberano passo per passo prima di rispondere, che è esattamente l'abilità che la caccia ai difetti richiede. Il pattern efficiente è la divisione del lavoro: un modello veloce redige a buon mercato, poi il modello di reasoning spende il suo calcolo solo sul passaggio di audit. Riserva il modello pesante al pensiero pesante.

Prossima lezione

L'Auditor esegue un passaggio potente: bozza, attacco, correzione. Ma alcuni lavori sono troppo grandi anche per una singola risposta perfetta — ricerca poi trasformazione poi rifinitura, ogni passo che alimenta il successivo. Cosa succede quando smetti di scrivere prompt e inizi a costruire catene di montaggio?

Continua alla prossima lezione: Prompt Chaining

Esercizio pratico prima di andare: prendi l'ultimo output dell'IA che hai davvero usato e esegui sopra l'esatto prompt di audit — ruolo spietato, esattamente 3 difetti, solo riscontri. Qualsiasi cosa emerga, rifletti sul fatto che era lì seduto tutto il tempo, in attesa che qualcuno fosse pagato per trovarlo.