✔️✔️ Doppie Spunte Blu Cap. 11 · Prompt engineering decente

Puntata 120

Puntata 120 — TEST: ottimizza 5 prompt scarsi insieme

Livello: ✔️✔️ Doppie Spunte Blu · Capitolo 11 · Prompt engineering decente · 🎯 Laboratorio pratico di fine capitolo

Cinque casi reali. Prima il prompt scarso, poi quello ottimizzato. Tu provi entrambi, confronti, capisci dove sta la differenza.

una clinica di prompt. Cinque “pazienti” in fila (prompt brutti), un robottino in camice li opera uno per volta — taglia, sutura, aggiunge struttura. Escono in salute, ben formati

Come funziona il laboratorio

5 prompt presi da casi d’uso reali. Per ognuno:

  1. La versione scarsa (quella che chiunque scriverebbe in 10 secondi).
  2. L’analisi: cosa manca? Quali delle 6 leggi (puntata 111) non sono rispettate?
  3. La versione ottimizzata che applica tutto quello che abbiamo visto nelle puntate 111-119.
  4. Cosa è cambiato e perché funziona meglio.

Ti consiglio di provare entrambe le versioni su un modello (ChatGPT, Claude, Gemini) e confrontare. Misura la rilavorazione manuale che dovresti fare sull’output.

Caso 1 — Email di vendita

Versione scarsa

“Scrivimi un’email per vendere il nostro nuovo software ai potenziali clienti.”

Analisi

  • ❌ Chiarezza: cosa fa il software? Chi sono i clienti?
  • ❌ Contesto: nessun dato sull’azienda o prodotto.
  • ❌ Ruolo: il modello andrà in default “venditore di plastica”.
  • ❌ Formato: lunghezza? Oggetto? CTA?
  • ❌ Vincoli: niente.

Output prevedibile: email piena di “rivoluzionario, all’avanguardia, soluzione definitiva”, lunga il doppio del necessario, generica.

Versione ottimizzata

[Ruolo]
Sei un Account Executive B2B con 10 anni di esperienza nella vendita
di software a PMI italiane. Tono diretto, cordiale, mai pressante.

[Contesto]
Vendo: TaskFlow, software di gestione progetti per team di 10-100
persone. Differenziatore: si integra nativamente con Microsoft 365 +
WhatsApp Business. Pricing: 8€/utente/mese.

Target email: Operations Manager di aziende italiane manifatturiere
con 50-200 dipendenti, ancora gestiscono progetti via Excel ed email.
Pain point principale: perdita di tempo per coordinamento e visibilità
su stato avanzamento.

[Compito]
Scrivi un'email di primo contatto cold. Obiettivo: ottenere una demo
di 15 minuti.

[Vincoli negativi]
- Niente "rivoluzionario", "all'avanguardia", "leader di mercato".
- Niente promesse generiche ("aumenta produttività").
- Niente claim non verificabili.
- Niente "Spero questa mail ti trovi bene".
- Niente domande retoriche tipo "Quante ore perdi al mese in...?".

[Formato]
- Oggetto: max 60 caratteri, specifico.
- Corpo: 4 paragrafi brevi, max 120 parole totali.
- CTA: 1 sola, concreta (link demo o data proposta).
- Tono: professionale-conversazionale, da Account Exec esperto.

Cosa è cambiato e perché

  • Ruolo specifico + contesto di prodotto = email customizzata.
  • Vincoli negativi = niente marketing-speak.
  • Formato strutturato = email subito utilizzabile.
  • Lunghezza vincolata = costringe a essere essenziali.

Caso 2 — Estrazione dati da scontrini

Versione scarsa

“Estrai i dati da questo scontrino.”

Analisi

  • ❌ Quali dati?
  • ❌ In che formato?
  • ❌ Cosa fare se manca un dato?

Versione ottimizzata

Estrai dati dallo scontrino fornito.

Output ESCLUSIVAMENTE in JSON con questo schema:
{
  "ragione_sociale": string,           // negozio/esercente
  "partita_iva": string,                // 11 cifre, formato puro
  "data": string,                       // formato YYYY-MM-DD
  "ora": string,                        // HH:MM o null
  "totale": number,                     // float in euro
  "iva_totale": number,                 // float in euro
  "metodo_pagamento": string,           // "contanti" | "carta" | "altro" | null
  "items": [
    {"descrizione": string, "quantità": number, "prezzo": number}
  ]
}

Esempio 1:
[Input scontrino]: "FARMACIA CENTRALE / P.IVA 12345678901 / 14/05/2026
ore 10:32 / 1 ASPIRINA 500MG 4.50€ / Totale 4.50€ / IVA 0.99 / CARTA"

[Output]:
{
  "ragione_sociale": "FARMACIA CENTRALE",
  "partita_iva": "12345678901",
  "data": "2026-05-14",
  "ora": "10:32",
  "totale": 4.50,
  "iva_totale": 0.99,
  "metodo_pagamento": "carta",
  "items": [{"descrizione": "ASPIRINA 500MG", "quantità": 1, "prezzo": 4.50}]
}

Vincoli:
- Output ESCLUSIVAMENTE JSON. Niente testo prima o dopo.
- Se un campo non è leggibile/presente, valore = null.
- Date sempre normalizzate a YYYY-MM-DD.
- Niente commenti dentro il JSON.
- Non inventare dati: se illeggibile, null.

[Input scontrino da elaborare]:
...

Cosa è cambiato e perché

  • JSON schema esplicito = output utilizzabile da codice.
  • Few-shot = il modello impara normalizzazione date e gestione null.
  • Vincoli su “non inventare” = riduce hallucination su dati illeggibili.

Caso 3 — Riassunto di una riunione

Versione scarsa

“Riassumi questa riunione.”

Analisi

  • ❌ Per chi? Tono?
  • ❌ Cosa estrarre: decisioni? Action item? Punti aperti?
  • ❌ Lunghezza?

Versione ottimizzata

[Ruolo]
Sei un Chief of Staff esperto in sintesi esecutiva di riunioni.

[Compito]
Riassumi la trascrizione fornita per **executive che non c'erano**.

[Formato output — markdown]

## TL;DR (3 righe)
[Tre frasi massimo: cosa è stato deciso, qual è il blocco, qual è il
prossimo step]

## Decisioni prese
- [decisione 1] (chi: nome, entro: data)
- [decisione 2]

## Action item
| Persona | Task | Scadenza |
|---|---|---|
| ... | ... | ... |

## Punti aperti / da chiarire
- [punto 1]
- [punto 2]

## Cita di rilievo (massimo 2)
> "frase importante detta da X"

[Vincoli]
- Massimo 350 parole totali.
- Niente meta-commento ("ecco il riassunto…").
- Per ogni action item, indicare la persona responsabile (se non
  identificata, scrivere "TBD").
- Niente date inventate. Se la riunione non specifica una scadenza,
  scrivere "non specificata".

Cosa è cambiato

  • Struttura fissa = riassunti coerenti tra riunioni diverse.
  • Tabella per action item = visivamente parseable.
  • “Vincoli su date” = riduce invenzioni.

Caso 4 — Brainstorm di idee creative

Versione scarsa

“Dammi idee per il prossimo lancio.”

Analisi

  • ❌ Prodotto? Audience? Budget? Vincoli temporali?
  • ❌ Quante idee? Che tipo?
  • ❌ Niente criteri per evitare il banale.

Versione ottimizzata

[Ruolo]
Sei un Senior Brand Strategist con esperienza in lanci di prodotti
food&beverage in Italia.

[Contesto]
- Prodotto: nuovo gelato vegan al pistacchio siciliano.
- Brand: piccola gelateria artigianale di Catania, 2 punti vendita.
- Target: 25-45 anni, attenti al cibo etico, vegetariani/vegani.
- Budget: massimo 8.000€ totali.
- Tempistica: lancio fra 6 settimane (giugno 2026).
- Vincoli operativi: nessun e-commerce, solo punto vendita fisico +
  social.

[Compito]
Dammi 8 idee di lancio organizzate in 3 categorie:
1. Locale/in-store (massimo 250€ ciascuna).
2. Digitale/social (massimo 1500€ ciascuna).
3. PR/eventi (massimo 4000€ ciascuna).

Per ogni idea:
- Nome breve dell'iniziativa.
- 2 righe di descrizione.
- Costo stimato.
- Effort di esecuzione (basso/medio/alto).
- Rischio o cosa potrebbe andare storto.

[Vincoli]
- Niente idee generiche tipo "fai una promozione sui social".
- Almeno 2 delle 8 devono essere "non convenzionali" — qualcosa che
  un piccolo brand non ovvio farebbe.
- Niente sponsorizzazioni di influencer con milioni di follower
  (fuori budget).
- Tieni conto della stagionalità (gelato + giugno = picco).

Cosa è cambiato

  • Vincoli operativi specifici = idee fattibili.
  • Categorie con budget cap = decisione facilitata.
  • “Almeno 2 non convenzionali” = forza la creatività oltre il banale.

Caso 5 — Code review

Versione scarsa

“Cosa pensi di questo codice?”

Analisi

  • ❌ Cosa cerchi: bug? Performance? Style? Security?
  • ❌ Quale livello di rigorosità?
  • ❌ Output: lista? Codice corretto?

Versione ottimizzata

[Ruolo]
Sei un Senior Software Engineer (Python, 15 anni) che fa code review
in una team che pubblica librerie open-source con uso enterprise.

[Compito]
Code review della funzione fornita.

[Cosa cercare, in ordine di priorità]
1. **Bug** — logica errata, edge case non gestiti, race condition.
2. **Sicurezza** — input non sanitizzato, secret esposti, SQL injection.
3. **Performance** — complessità inutile, allocazioni evitabili, I/O
   sincroni dove async sarebbe meglio.
4. **Maintainability** — naming, docstring, type hints, structure.
5. **Style** — solo se viola PEP-8 in modo non banale.

[Formato output]

## Critical issues (bug / security)
- [issue 1]: descrizione + linea + fix proposto in 2 righe.

## Improvements suggested
- ...

## Stylistic notes (opzionale, solo se rilevanti)
- ...

## Verdict
APPROVE / REQUEST_CHANGES / BLOCK

## Codice corretto (solo se REQUEST_CHANGES o BLOCK)
```python
[codice fixato]

[Vincoli]

  • Sii diretto, anche scomodo. Niente “ottimo lavoro generalmente”.
  • Per ogni issue, indica linea esatta.
  • Se non ci sono critical issue, scrivi “Nessuno” — non inventare.
  • Niente commenti su scelte stilistiche soggettive (es. virgolette singole vs doppie) salvo che non sia regola di team.

### Cosa è cambiato
- **Priorità esplicita** = focus sui veri problemi.
- **Vincolo "anti-sycophancy"** = critica vera, non gentile.
- **Verdict strutturato** = decisione operativa.

---

## Le 6 leggi applicate, sintetizzate

| Caso | Aggiunte principali |
|---|---|
| 1. Email vendita | Ruolo + contesto prodotto + vincoli negativi + formato |
| 2. Estrazione scontrini | JSON schema + few-shot + vincoli su null |
| 3. Riassunto riunione | Struttura markdown fissa + ruolo + vincoli anti-invenzione |
| 4. Brainstorm | Contesto operativo + categorie + criterio "non convenzionale" |
| 5. Code review | Priorità + vincolo anti-sycophancy + verdict strutturato |

Tutti e 5 i casi: **stesso modello, prompt diverso, qualità +50% almeno**.

---

## Auto-valutazione

Hai applicato le 6 leggi in pratica?

| Hai capito | Verdetto |
|---|---|
| **5/5 casi** con netta differenza qualità | 🏆 Prompt engineering decente, sei pronto per il Cap. 12 |
| **3-4/5** | 🥈 Ripassa le puntate dove sei stato meno sicuro |
| **0-2/5** | 📚 Ri-leggi le puntate 111-119 con calma; il prompt engineering richiede pratica iterativa |

---

## 🎓 Hai finito il Capitolo 11

Adesso sai:
- Le **6 leggi** del prompt (111).
- **Role prompting** (112).
- **Few-shot learning** (113).
- **Chain-of-thought** (114).
- **Formato output** (115).
- **Vincoli negativi** (116).
- **System vs user prompt** (117).
- **Iterare il prompt** (118).
- **Template riusabili** (119).
- Come **ottimizzare prompt scarsi** in casi reali (120).

Sei pronto per il **Capitolo 12: il bestiario dei modelli** (121-130). Da qui in poi non chiederai *"qual è il prompt migliore?"* ma *"qual è il prompt migliore **per questo modello su questo task**?"*

---

### Take-away in una riga
*Prompt engineering decente = applicare strutture conosciute, non cercare formule segrete. La differenza tra dilettante e professionista è la disciplina nell'iterare.*

➡️ **Prossimo capitolo:** Il bestiario dei modelli — GPT-5 e famiglia OpenAI.