Grok 4.7 Prompt: 5 scenari da copiare direttamente

TL;DR: 5 scenari, tutti testati realmente in produzione su HiAPI con grok-4.7, con output originali incollati così come sono. Costo per chiamata: $0,007–0,021; eseguire tutti e 5 costa circa $0,06. Il link sotto ogni prompt precompila automaticamente lo stesso prompt nella pagina del modello: basta inviare per riprodurre. Grok 4.7 è già disponibile su HiAPI, apri la pagina del modello per provarlo subito; i nuovi utenti ricevono 200 crediti alla registrazione.

Scenario 1: diagnosticare un blocco da concorrenza

La causa principale è che l'oggetto response non viene rilasciato e la connessione continua a occupare uno slot nel pool del connector.

Il ClientResponse restituito da session.get() restituisce la connessione al TCPConnector solo quando viene chiamato release() / close() (oppure quando esce dal context manager asincrono). Il codice attuale non usa né async with né release() esplicito. Leggere il body non restituisce la connessione; inoltre tra response e connection esiste un riferimento circolare, quindi la connessione viene liberata solo quando il GC ciclico esegue __del__.

Di default il limite di connessioni per ogni ClientSession è 100. 20 worker hanno ciascuno una session e inviano richieste in serie, ogni worker elabora circa 250 URL. Se le connessioni non vengono restituite:

1. Le connessioni occupate vengono chiuse con RST per timeout di inattività o limite di connessioni lato server; aiohttp emette ConnectionResetError a livello di protocollo (non necessariamente viene sollevata dal tuo await, quindi il blocco except non la intercetta né riesce a fare pulizia).
2. Gli slot restano occupati. Dopo aver raggiunto 100, la successiva session.get() resta bloccata su connector.acquire(), e questa attesa spesso non è soggetta al timeout.
3. Tutti i worker si bloccano in acquire, non chiamano più queue.get() né task_done(). Sull'event loop non avvengono nuove allocazioni, il GC ciclico non viene più eseguito e __del__ non può recuperare le connessioni: si crea un deadlock. Anche queue.join() non termina mai.

except Exception: pass riesce solo a inghiottire le eccezioni nella coroutine utente, ma non libera la connessione, quindi «errore» e «blocco» si manifestano insieme.

Modifica minima:

async def fetch(url, session):
    async with session.get(url) as r:
        return await r.json()

async with esegue __aexit__ → release() sia sul percorso di ritorno normale sia su quello di eccezione:

• La connessione torna subito nel pool, gli slot non si accumulano fino a 100, session.get() non resta più bloccata permanentemente su acquire e i worker possono continuare a consumare la coda. Questo risolve il blocco.
• La connessione non resta più a lungo in attesa del RST del server, e di conseguenza scompare anche il ConnectionResetError a livello di protocollo; anche se durante la lettura del body avviene davvero una disconnessione, il context manager restituisce/chiude comunque quella connessione, quindi un singolo fallimento non blocca il pool. Questo risolve l'errore e garantisce che la coda possa continuare dopo l'errore.

Prompt completo:

Questo codice Python, con una concorrenza un po' più alta, genera casualmente ConnectionResetError e subito dopo l'intero worker si blocca senza più consumare la coda. Trova la causa principale, fornisci una correzione con la modifica minima e spiega perché la tua correzione risolve contemporaneamente i due problemi: «errore» e «blocco».

```python
import asyncio, aiohttp

async def fetch(url, session):
    r = await session.get(url)
    return await r.json()

async def worker(queue):
    session = aiohttp.ClientSession()
    while True:
        url = await queue.get()
        try:
            data = await fetch(url, session)
            print(data)
        except Exception:
            pass
        queue.task_done()

async def main():
    queue = asyncio.Queue()
    for i in range(5000):
        queue.put_nowait(f"https://api.example.com/item/{i}")
    workers = [asyncio.create_task(worker(queue)) for _ in range(20)]
    await queue.join()

asyncio.run(main())
```

Genera con questo prompt →

grok-4.7, livello di ragionamento high predefinito, max_tokens massimo 6000, esecuzione reale 107,7s, input 3.572 / output 7.301 token, circa $0,021.

Fornendo in una sola volta sintomi, codice e il vincolo «devi spiegare entrambi i problemi», il modello individua la causa a livello di connection pool invece di fermarsi a una modifica superficiale del try-catch.

Scenario 2: code review con output JSON

{"issues":[{"severity":"high","line":8,"problem":"Controllo del saldo e addebito separati, race condition TOCTOU: richieste concorrenti possono superare contemporaneamente il controllo del saldo e addebitare due volte, causando scoperto o double spending","fix":"Passare a un singolo aggiornamento condizionale (es. $inc solo se balance>=amount) oppure completare atomicamente controllo e addebito con lock di riga/lock ottimistico in transazione"},{"severity":"high","line":9,"problem":"Addebito e accredito sono due scritture indipendenti, senza transazione; se la prima riesce e la seconda fallisce, i fondi spariscono da from e non possono essere annullati","fix":"Mettere i due aggiornamenti nella stessa transazione DB, con rollback complessivo se uno dei due fallisce, e verificare l'esistenza del conto to prima del commit"}

,"summary":"Questa API di trasferimento manca di transazioni atomiche, autorizzazione e validazione degli input; in concorrenza può causare double spending o perdita di fondi, e sui percorsi di eccezione lascia richieste appese."}

(estratto: l'output originale era un JSON su una sola riga; mantenuti i primi due problemi high e il summary, il resto omesso)

Prompt completo:

Esamina il seguente codice di una route Node.js, individua tutti i problemi che possono causare incidenti in produzione (sicurezza, concorrenza, leak di risorse inclusi) e ordinali per gravità. Restituisci rigorosamente un output JSON nel formato: {"issues": [{"severity": "high|medium|low", "line": numero_riga, "problem": "problema", "fix": "correzione"}], "summary": "riassunto in una frase"}.

```js
const express = require('express');
const db = require('./db');
const router = express.Router();

router.post('/transfer', async (req, res) => {
  const { from, to, amount } = req.body;
  const fromAccount = await db.findOne({ id: from });
  if (fromAccount.balance >= amount) {
    await db.update({ id: from }, { $inc: { balance: -amount } });
    await db.update({ id: to }, { $inc: { balance: amount } });
    res.json({ ok: true });
  } else {
    res.status(400).json({ ok: false });
  }
});

module.exports = router;
```

Genera con questo prompt →

grok-4.7, livello di ragionamento high predefinito, max_tokens massimo 4000, esecuzione reale 40,1s, input 3.576 / output 2.734 token, circa $0,010.

Scrivendo direttamente nel prompt lo scheletro JSON desiderato (nomi dei campi, regole di ordinamento), grok-4.7 produce un output rigorosamente conforme al formato, pronto per entrare nella pipeline.

Scenario 3: confronto tra soluzioni tecniche

Consiglio «heartbeat di attività + TTL Redis + polling breve on demand», senza WebSocket/SSE per la presenza online completa. Il passaggio a grigio dopo 5 minuti non richiede push a livello di secondo; con 100k DAU il polling regge benissimo ed è anche più adatto a Next.js.

Confronto tra soluzioni

	Polling	SSE	WebSocket
Direzione	Il client effettua richieste	Push unidirezionale dal server	Bidirezionale
Compatibilità con «grigio dopo 5 minuti di inattività»	Alta. Un refresh ogni 30–60s basta per il pallino verde	Media. Il push è più rapido, ma il timeout verso grigio va comunque calcolato	Da bassa a media. Connessione attiva ≠ utente attivo
Adattabilità a Next.js	Ottima. Un normale Route Handler	Scarsa. Connessioni lunghe poco compatibili con Serverless/multi-istanza	Pessima. Richiede un processo WS separato, sessioni sticky o servizi di terze parti
Costo delle connessioni	Nessuna connessione persistente	1 per ogni utente online	1 per ogni utente online, più heartbeat per mantenerla viva
Scalabilità	Stateless, scalabilità orizzontale semplice	Bisogna gestire disconnessioni, riconnessioni e fan-out multi-istanza	Come sopra, ma più pesante
Modalità di errore	Una richiesta fallisce, si riprova alla successiva	Dopo la disconnessione lo stato smette di aggiornarsi, serve un recupero	Come a sinistra, gateway più complesso
Vale la pena con 100k DAU	Sì, come soluzione predefinita	Solo se esiste già un canale di push	Solo se esiste già un gateway chat/collaborazione

Stima grezza del picco: 100.000 utenti attivi al giorno, con una stima del 5%–15% online contemporaneamente, circa 5.000–15.000. Un heartbeat ogni 45 secondi produce circa 100–300 scritture/s; ogni utente recupera ogni 30 secondi un blocco di stati degli utenti visibili, quindi anche le letture restano nella zona confortevole di Redis. Il collo di bottiglia non sarà il «pallino verde».

Raccomandazione e motivazione

Usare Redis come fonte di verità per la presenza online, PostgreSQL solo per il last_seen freddo, e far interrogare al client solo gli utenti attualmente sullo schermo.

1. La semantica di prodotto è «5 minuti senza attività», non «il TCP è ancora connesso». Una pagina lasciata aperta senza interazione deve diventare grigia, quindi anche con WS serve un heartbeat di attività separato. La connessione da sola non risolve il requisito.
2. Il pallino verde tollera un errore di decine di secondi. Un intervallo di polling di 30–60 secondi è sufficiente rispetto a una finestra di 5 minuti.
3. Next.js (soprattutto Vercel / Serverless) non è adatto a gestire connessioni lunghe. WS/SSE ti trascinano in un servizio realtime separato, routing sticky e compensazione delle disconnessioni, con benefici minimi.
4. Chi deve vedere lo stato di chi è di solito locale (amici, lista delle conversazioni, avatar nella pagina corrente), non una trasmissione globale. Recuperare in batch da Redis per id è di un ordine di grandezza più semplice che mantenere relazioni di sottoscrizione.
5. La scadenza naturale delle key Redis esprime bene il concetto di «timeout e offline», senza bisogno di keyspace notification o scansioni complete della tabella.

Presenza a livello utente = online (soluzione principale consigliata):

```text
presence:u:{userId}   STRING  valore = unix millisecondi lato server
                      TTL = 300 secondi
                      all'heartbeat SET key value EX 300
                      online = la key esiste
```

Non usare l'ora del client. Non è necessario che il TTL sia 2–3 volte l'intervallo di heartbeat: qui l'heartbeat è di 45–60 secondi e il TTL di 300 secondi, quindi perdendo due o tre heartbeat si resta considerati online, in linea con «5 minuti senza attività».

(estratto: conclusione della raccomandazione e prime 5 motivazioni, soluzione principale a livello utente nella progettazione delle key Redis)

Prompt completo:

Devo aggiungere a un'applicazione Web con 100.000 utenti attivi al giorno la funzione «stato online in tempo reale» (pallino verde accanto all'avatar dell'utente, grigio dopo 5 minuti di inattività). Lo stack è Next.js + PostgreSQL + Redis. Prima confronta le soluzioni (WebSocket / SSE / polling), indica quale consigli e perché, poi elenca i passaggi di implementazione e il design delle key Redis. Non scrivere codice completo, puoi incollare frammenti chiave.

Genera con questo prompt →

grok-4.7, livello di ragionamento high predefinito, max_tokens massimo 6000, esecuzione reale 69,8s, input 3.429 / output 4.247 token, circa $0,014.

Limitando prima stack e volume di business, poi chiedendo «prima il confronto, poi la raccomandazione», l'output diventa una proposta presentabile in sede di revisione tecnica, non una spiegazione neutra.

Scenario 4: spiegazione di concetti

Partiamo dallo scenario. Supponi di gestire un ordine: devi scrivere l'ordine nel database e contemporaneamente inviare un messaggio a una coda, in modo che magazzino, punti e notifiche svolgano le attività a valle. Queste due azioni non stanno nella stessa «transazione», e il fallimento di uno dei passaggi intermedi crea una frattura in cui «una parte riesce e l'altra non avviene».

Perché scrivere prima nel database e poi inviare il messaggio può far perdere il messaggio

Il commit del database è riuscito, l'ordine è memorizzato. Subito dopo il processo deve inviare il messaggio, ma a quel punto può succedere che:

• la rete abbia un intoppo e l'invio non riesca;
• la coda di messaggi sia temporaneamente non disponibile;
• più comunemente, il processo vada in crash dopo il commit del database e prima dell'invio del messaggio (riavvio della macchina, OOM, deploy rolling).

L'ordine è nel database, ma il messaggio non viene mai inviato. I sistemi a valle non sanno nemmeno che esiste questo ordine: il magazzino non scarica, la notifica non parte. Un retry successivo non serve: il processo che è andato in crash non esiste più; a meno che tu non abbia predisposto una compensazione affidabile, quel messaggio è perso. Per chi ha sempre lavorato su monoliti è come: annoti sul registro «pagamento ricevuto», poi vai all'ufficio postale a spedire la lettera di notifica, la lettera si perde per strada, ma il registro è già stato modificato: le due parti non coincidono.

(estratto: meccanismo di perdita del messaggio con «scrivi prima nel DB, poi invia il messaggio» e la metafora centrale)

Prompt completo:

Spiega, con un linguaggio comprensibile a un ingegnere backend con 3 anni di esperienza che non ha mai avuto a che fare con sistemi distribuiti, perché «scrivere prima nel database e poi inviare alla coda di messaggi» può causare la perdita del messaggio, e perché anche «inviare prima alla coda e poi scrivere nel database» non va bene. Indica per ciascuna delle due soluzioni corrette più comuni nel settore (tabella dei messaggi locale / messaggi transazionali) a quali scenari si adatta meglio.

Genera con questo prompt →

grok-4.7, livello di ragionamento high predefinito, max_tokens massimo 4000, esecuzione reale 41,3s, input 3.410 / output 2.478 token, circa $0,009.

Sostituendo «spiega bene» con «spiega a una persona con un profilo specifico», il modello sceglie da solo il livello giusto: è così che nascono metafore come registro e ufficio postale.

Scenario 5: script di analisi dati

```python
import pandas as pd
import numpy as np

# Dati di esempio (sostituibili con il tuo df reale)
np.random.seed(42)
n = 500
df = pd.DataFrame({
    "order_id": range(1, n + 1),
    "user_id": np.random.randint(1, 80, n),
    "amount": np.round(np.random.uniform(20, 500, n), 2),
    "created_at": pd.date_range("2023-01-01", periods=n, freq="D").astype(str),  # date simulate come stringhe
    "status": np.random.choice(["paid", "paid", "paid", "cancelled"], n),
})

# ---------- 0. Gestione date: conversione stringa → datetime ----------
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df.dropna(subset=["created_at", "amount", "user_id"])

# Opzionale: contare solo gli ordini validi (adatta i valori di status al tuo business)
df_valid = df[df["status"] == "paid"].copy()

# ---------- 1. GMV e numero ordini per mese ----------
df_valid["month"] = df_valid["created_at"].dt.to_period("M")
monthly = (
    df_valid.groupby("month", as_index=False)
    .agg(GMV=("amount", "sum"), order_count=("order_id", "count"))
    .sort_values("month")
)
monthly["month"] = monthly["month"].astype(str)
print("=== GMV e numero ordini per mese ===")
print(monthly)
```

(estratto: prima metà del codice (gestione date + GMV mensile), omesse la seconda metà con classifica utenti e trend del primo ordine)

Prompt completo:

Uso pandas per analizzare dati di ordini e-commerce; il dataframe df ha le colonne: order_id, user_id, amount, created_at, status. Dammi codice Python completo ed eseguibile che calcoli: 1) GMV e numero di ordini per ogni mese; 2) la classifica della spesa cumulata per utente (solo i primi 20); 3) il trend mensile della spesa media del primo ordine dei nuovi utenti. Gestisci il caso in cui created_at sia una stringa e commenta i passaggi chiave.

Genera con questo prompt →

grok-4.7, livello di ragionamento high predefinito, max_tokens massimo 5000, esecuzione reale 18,5s, input 3.440 / output 1.427 token, circa $0,007.

Elencando uno per uno i nomi delle colonne, le metriche da calcolare e i casi limite (created_at è una stringa), il codice generato è eseguibile subito, senza rilavorazioni.

Come scrivere i prompt

1. Incolla codice reale e nomi di colonna reali; non dire «c'è un pezzo di codice», incollalo direttamente.
2. Scrivi il formato di output nel prompt: se vuoi JSON, fornisci lo scheletro JSON; se vuoi codice, dì «completo ed eseguibile».
3. Più i vincoli sono specifici, meglio è: regole di ordinamento, solo i primi 20, non codice completo ma solo frammenti chiave.

Domande frequenti

Questi prompt si possono usare direttamente? Sì. Tutti e 5 sono prompt originali che abbiamo eseguito realmente su HiAPI, e gli output sono i risultati reali ottenuti. Clicca su «Genera con questo prompt» sotto ciascuno: la pagina del modello si precompila automaticamente; basta sostituire il codice o i dati con i tuoi per usarli subito.

Quanto è bravo grok-4.7 a scrivere codice? xAI lo posiziona proprio su coding e knowledge work; secondo i dati ufficiali, Terminal-Bench 4.0 passa dal 20,3% di grok-4.6 al 38,0% (fonte ufficiale). L'individuazione della causa principale nello scenario 1 e la checklist di review nello scenario 2 sono risultati delle nostre esecuzioni reali: puoi giudicare tu stesso.

Quanto costa una chiamata? Con i prezzi della piattaforma HiAPI (input $0,84 / output $2,52 per 1M token), questi 5 prompt costano in totale circa $0,06. Lo scenario 5, il più economico, costa solo circa $0,007; lo scenario 1, il più costoso, circa $0,021.

A cosa serve una context window di 500K? Permette di incollare in una singola richiesta i file di un intero repository di medie dimensioni o centinaia di pagine di log per fare review, debug o refactoring, senza doverli dividere. I prompt brevi quotidiani non la sfruttano e non costano di più: la fatturazione è sui token effettivi.

Continua a leggere

• Quanto costa l'API di Grok 4.7? — tre livelli di ragionamento, prezzi per documenti lunghi e matrice di budget mensile
• Grok 4.7 vs Grok 4.6 — stesso prezzo, quando usare l'uno o l'altro
• Guida all'integrazione dell'API Grok 4.7 — esegui la prima richiesta in 5 minuti
• Pagina del modello Grok 4.6 — uso completo del flagship della generazione precedente
• Pagina del modello Grok 4.7 — prova online, parametri e prezzi in tempo reale