Prima che il modello giri
L'utente fornisce un prompt e un alias come cheap, fast o smart. Il server di produzione verifica autenticazione, possesso del workspace e permesso prima di accettare l'attività. Gli ID dei modelli e i segreti dei provider restano dietro quella frontiera — l'alias amichevole è l'unico vocabolario di modelli che il client deve conoscere, perché la mappatura verso un modello reale del provider è configurazione, non contratto.
Un record di attività durevole dà alla richiesta un'identità prima che inizi l'esecuzione in background. Quell'identità collega submission, worker, record di utilizzo e risultato. Dà anche all'utente un modo per recuperare il lavoro dopo aver navigato altrove.
L'ordine conta: il lavoro costoso parte solo dopo che i controlli economici sono passati. Verificare autenticazione, possesso e permesso prima che qualsiasi cosa venga accodata impedisce a richieste non autenticate o non pagate di raggiungere mai un provider — e rende il fallimento spiegabile all'utente. La guida al modulo AI documenta dove vivono quei controlli; il post sui confini dei workspace spiega perché il possesso viene derivato sul server invece che affidato al client.
Decidi di chi sono le chiavi e di chi i limiti
Una funzionalità AI è una decisione di spesa. supastack permette ai workspace di portare le proprie chiavi dei provider — conservate cifrate, mai esposte ai client — o di girare sulle chiavi della piattaforma, e fa rispettare budget per workspace contro un catalogo di prezzi dei modelli. Qualunque sia la tua implementazione, le domande sono le stesse: chi paga, e dove viene fatto valere il limite?
L'applicazione appartiene al workflow del server, non a una stima lato browser. Un budget controllato dopo la generazione registra solo il superamento; controllato prima del dispatch, lo previene. La guida alla configurazione delle chiavi dei provider copre il lato della configurazione.
Rendi esplicita l'esecuzione
Trigger.dev esegue il workflow ai.generate. Il router consapevole delle capacità sceglie un modello in base alla policy configurata e ai requisiti della richiesta. Tratta quella policy come un input operativo: un alias non disponibile non deve apparire come una scelta funzionante nell'interfaccia.
Un errore di rete durante la submission può lasciare il client incerto se il lavoro sia stato accodato. Il percorso di produzione usa una chiave di idempotenza delimitata all'attività e una submission salvata così il ripristino riutilizza la richiesta originale. Inviare una nuova attività dopo ogni timeout rischia lavoro e costo duplicati.
La durabilità è anche ciò che mantiene semplice l'interfaccia: la schermata legge lo stato dell'attività e lo renderizza invece di orchestrare retry. Quando la generazione attraversa chiamate al modello, passi di strumenti o pianificazioni, il contratto esplicito del workflow — enqueue, status, cancel — è ciò che mantiene onesto lo «in corso».
Dai un nome ai modi di fallimento
Tra richiesta e risultato c'è un insieme specifico e finito di cose che vanno storte. Progetta per ciascuna per nome invece che per «errori» in astratto — ogni attività dovrebbe finire in uno stato spiegabile: in coda, in esecuzione, fallita con un motivo, o completa con un risultato. Il ripristino delle attività è il riferimento del kit per il lato del recupero.
Il requisito dell'interfaccia sottostante è che nessuno stato può mentire. Uno spinner che sopravvive al lavoro, o un messaggio di successo per un'attività mai eseguita, è un ticket di supporto e una contestazione di fatturazione in attesa di accadere.
- Timeout della submission — recupera tramite la submission salvata e la chiave di idempotenza delimitata all'attività invece di riaccodare.
- Il provider è fallito a metà attività — marca l'attività come fallita con un motivo che l'interfaccia può mostrare.
- Budget esaurito — rifiuta prima del dispatch, non dopo la spesa.
- L'utente ha navigato altrove — il record durevole e l'URL di ripresa ripristinano stato e risultato.
Traccia cosa è successo
La generazione produce più che testo. L'applicazione registra utilizzo e un risultato dell'attività, e l'interfaccia legge lo stato tramite l'API autenticata. Il record di utilizzo è ciò che rende il budget applicabile — viene scritto prima che il risultato sia restituito, non stimato dopo.
L'email di completamento è un passo separato con record di consegna separati. Una risposta del modello riuscita non stabilisce che un'email sia stata consegnata. Tenere distinti questi esiti rende i fallimenti più facili da spiegare e riprovare senza rieseguire il modello inutilmente.
Il risultato ha anche bisogno di una casa a cui l'utente possa tornare: una pagina dell'attività, una lista dello storico, un URL di ripresa consegnato in quell'email di completamento. Una generazione che esiste solo in una notifica transitoria è lavoro che ti verrà chiesto di produrre due volte.
Verifica ogni frontiera
Usa adattatori fake deterministici per testare prima le decisioni dell'applicazione: accesso negato, alias disabilitati, submission duplicate, ripristino dei risultati ed errori generici. Questi test devono girare senza credenziali dei provider.
Poi usa il processo di smoke dei provider esplicitamente opt-in per le integrazioni reali. Richiede la configurazione sandbox documentata e un'approvazione per fare chiamate esterne. La distinzione mantiene veloce lo sviluppo ordinario rendendo le prove di produzione specifiche e tracciabili.
Mantieni stabile quella divisione man mano che il prodotto cambia: copertura deterministica vicino a ogni decisione di frontiera, così un cambio di provider, una modifica alla policy del router o un nuovo alias fa fallire un test invece che un cliente.
Domande frequenti sulle funzionalità AI nei SaaS
Alcune domande emergono in ogni conversazione sul mettere l'AI dietro un paywall.
- Dove dovrebbe avvenire l'autorizzazione per le funzionalità AI? — Prima che qualsiasi cosa venga accodata: autentica, risolvi il workspace, verifica il permesso, poi crea l'attività. I controlli eseguiti dopo la generazione documentano solo l'abuso.
- Mi serve il supporto bring-your-own-key? — Se i tuoi clienti hanno relazioni proprie con i provider, sì: decide chi paga e chi possiede i rate limit. Conserva le chiavi cifrate e tienile lontane dai client — la guida alla configurazione dell'AI copre il modello.
- Come evito che i retry addebitino due volte? — Delimita la chiave di idempotenza all'attività e riusa la submission salvata durante il ripristino, così un timeout non può creare una seconda esecuzione fatturabile.
- Quali dati di utilizzo dovrei registrare? — Per attività: modello, unità consumate, costo contro il catalogo dei prezzi e il workspace — abbastanza per far rispettare i budget e rispondere alle domande di spesa senza rieseguire i job.
- Quando la generazione appartiene a un job in background? — Ogni volta che può sopravvivere a una richiesta. Latenza del modello, retry e lavoro in più passi spingono per l'esecuzione durevole; solo le chiamate istantanee ed economiche stanno inline.