Vai al contenuto principale

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

La cosa più importante da ricordare quando istruisci Devin è essere il più specifico possibile. Così come forniresti una specifica dettagliata quando chiedi a un collega di scrivere del codice, dovresti fare lo stesso con Devin. Questa guida ti aiuterà a strutturare le tue istruzioni e i tuoi prompt per utilizzare Devin in modo efficace. Per strategie più generali su come lavorare in modo efficace con agenti di programmazione, consulta anche la nostra guida Coding Agents 101.

​
Come scrivere prompt efficaci

Ecco un esempio di prompt che dimostra istruzioni efficaci:
Nel repo di Devin, voglio che tu crei uno strumento che monitori l’utilizzo di RAM e CPU delle macchine remote su cui viene eseguito Devin. Per farlo, svolgi le seguenti attività:
  • Crea un’attività in background che si avvii automaticamente all’avvio di devin.rs.
  • L’attività deve aprire una connessione a tutte le macchine remote derivate (forked) utilizzate in questa sessione di Devin e monitorarne l’utilizzo di RAM e CPU.
  • Se l’utilizzo supera l’80% della risorsa disponibile, emetti un nuovo tipo di evento Devin per segnalarlo (controlla come utilizziamo Kafka).
  • Progetta l’architettura in modo intelligente, in modo che non blocchi le altre operazioni. Dovresti capire come tutti i container dei sotto-agent di Devin interagiscono tra loro.

​
Perché questo funziona bene

Fornisce un contesto utile

  • Dettaglio: Specifica il repository di Devin e l’obiettivo più ampio (monitoraggio dell’utilizzo delle risorse).
  • Beneficio: Devin conosce chiaramente l’ambito e il dominio.

Fornisce istruzioni passo-passo

  • Dettaglio: Attività come “crea un’attività in background” e “emetti un evento all’80% di utilizzo”.
  • Beneficio: Scompone il lavoro in parti logiche.

Definisce criteri di successo chiari

  • Dettaglio: Definisce il “successo” come l’emissione di uno specifico evento al raggiungimento dell’80% di utilizzo.
  • Beneficio: Devin sa esattamente cosa deve ottenere.

Fa riferimento a pattern e codice esistenti

  • Dettaglio: Menziona Kafka e le interazioni con i container.
  • Beneficio: Incoraggia il riutilizzo di codice o approcci di design consolidati.

​
Best Practices: cosa fare e cosa non fare

Da fare: fornire direttive chiare
  • Perché: Devin può bloccarsi senza un percorso chiaro o quando si trova di fronte a troppe possibili interpretazioni.
  • Come:
    • Prendere decisioni importanti e assumere i giudizi critici al posto di Devin.
    • Fornire scelte di design specifiche e strategie di implementazione.
    • Definire in modo chiaro ambito, confini e criteri di successo.
  • Esempio: “Ottimizza la query getOrderDetails in orderService.js aggiungendo un indice composito sulle colonne order_id e product_id nella tabella order_items. Refattorizza la query per sostituire la subquery correlata esistente con una JOIN alla tabella products per recuperare i dettagli dei prodotti.”
Da non fare: lasciare le decisioni aperte
  • Perché: Istruzioni vaghe possono portare Devin a implementare soluzioni che non sono allineate alle tue reali esigenze.
  • Come:
    • Evitare indicazioni che richiedono a Devin di prendere decisioni significative di design o implementazione senza un chiaro orientamento. Questo può portare a risultati inaspettati.
  • Esempio: Non fare: “Migliora le prestazioni del nostro database.”
Da fare: scegli task in cui Devin è bravo
  • Perché:
    • Massimizza i risultati: Assegnando task che si allineano alle capacità di Devin, puoi ottenere i risultati migliori con il minimo sforzo e il minor numero di ACU.
  • Come:
    • Leggi questa guida: Quando usare Devin
    • Fornisci esempi, moduli, risorse e template che Devin possa seguire.
      • Condividi link diretti ai siti di documentazione, così che Devin possa leggere dettagli come i body delle richieste API e funzionalità che potrebbe non conoscere.
      • Condividi nomi di file specifici che vuoi che Devin analizzi e da cui impari.
    • Collega le integrazioni MCP per dare a Devin accesso a design Figma, database, strumenti di monitoraggio e altro ancora.
    • Esempio: Da fare: “Refattorizza la gestione dello state nel componente Header per usare l’hook useReducer di React e migliorarne scalabilità e manutenibilità. Assicurati che tutta la funzionalità esistente venga preservata e aggiungi unit test per coprire la nuova logica di state.”
    • Esempio: Da fare: “Usa authTemplate.rs come riferimento per mantenere la coerenza nella gestione degli errori.”
    • Esempio: Da fare: “Consulta la documentazione ufficiale di Sequelize su https://sequelize.org/docs/v6/getting-started/ per i passaggi di migrazione.”
Da non fare: omettere il contesto per task complessi
  • Perché: Anche se Devin può gestire attività complesse, dà il meglio quando gli fornisci contesto e una direzione chiara.
  • Come:
    • Per task che richiedono conoscenze di dominio, fornisci documentazione, esempi o riferimenti pertinenti.
    • Per task visivi, fornisci file Figma tramite il Figma MCP, design di riferimento o specifiche dettagliate — Devin può costruire a partire da questi ma non inventerà l’estetica da solo.
    • Per app mobile, tieni presente che Devin non ha accesso a un emulatore di telefono, quindi fornisci criteri di test chiari.
  • Esempio: Da non fare: “Migliora l’aspetto dell’app” — invece, fornisci specifiche di design precise o un file Figma.
  • Esempio: Da non fare: “Migliora le prestazioni del nostro database” — invece, specifica quali query ottimizzare e quali metriche prendere di mira.
Da fare: stabilire verifiche chiare e frequenti
  • Perché: feedback frequenti (sia da parte tua che da test/verifiche/linters) garantiscono che Devin corregga gli errori in modo efficace.
  • Come:
    • Usa test (unitari/di integrazione) per confermare la correttezza.
    • Mantieni verifiche di build, controlli di linting e analisi statica per la qualità del codice.
    • Abilita Devin Review con Auto-Fix in modo che Devin risponda automaticamente ai commenti di review e agli errori della CI — creando un ciclo chiuso in cui le PR iterano fino a raggiungere una qualità pronta per il merge senza che tu debba intervenire.
  • Esempio: Da fare: “Esegui npm test dopo ogni iterazione.”
  • Esempio: Da fare: “Assicurati che la pipeline su CircleCI non fallisca.”
  • Esempio: Da fare: “Supera i controlli ESLint/Prettier prima di effettuare qualsiasi commit.”
Da non fare: trascurare di fornire feedback
  • Perché: senza feedback, Devin non saprà se le sue soluzioni soddisfano i tuoi standard.
  • Come:
    • Evita di assegnare task senza definire come li valuterai.
Da fare: definire checkpoint e sotto-attività chiari
  • Perché: Suddividere attività complesse in checkpoint più piccoli aiuta Devin a rimanere concentrato e riduce gli errori.
  • Come:
    • Suddividi le attività in sotto-attività verificabili e avvia una sessione Devin per ciascuna sotto-attività.
    • Definisci cosa significa successo per ciascuna sotto-attività e, facoltativamente, imposta dei checkpoint all’interno di ogni sotto-attività.
    • Chiedi a Devin di fornire un resoconto al termine di ogni checkpoint o sotto-attività.
Esempi:
  • Esempio: Da fare: “Quando lavori con il dataset, verifica che contenga almeno 500 righe e includa le colonne X, Y, Z.”
  • Esempio: Da fare: “Quando modifichi l’API, conferma che l’endpoint restituisca lo status 200 e includa tutti i campi richiesti.”
  • Esempio: Da fare: “Quando aggiorni la UI, controlla che il componente venga renderizzato senza errori in console e che corrisponda alle specifiche di design.”
Da non fare: saltare requisiti di validazione specifici
  • Perché: Senza passaggi di validazione definiti, Devin non può completare le attività in modo affidabile.
  • Come:
    • Evita criteri di successo vaghi.
    • Non lasciare che i passaggi di verifica siano impliciti o non definiti.
  • Esempio: Da non fare: “Assicurati che funzioni.”
Devin dispone di un ambiente desktop completo — shell, IDE e browser. Chiedi a Devin di testare il proprio lavoro prima di aprire una PR:
  • Avvia l’app: “Esegui npm run dev e verifica che la nuova pagina venga visualizzata su /settings.”
  • Test nel browser: “Apri il browser, vai alla pagina di login e conferma che il flusso OAuth si completi correttamente.”
  • Verifica visiva: “Acquisisci screenshot alle larghezze desktop (1440px) e mobile (375px) e conferma che il layout corrisponda al design.”
  • Registrazione schermo: “Effettua una registrazione dello schermo mentre testi l’intero flusso di checkout end‑to‑end.”
Questo permette a Devin di eseguire il QA sulle proprie modifiche nello stesso modo in cui lo faresti tu — prima che tu debba guardare la PR.
Per attività ripetitive o complesse, consigliamo di usare e perfezionare i Playbooks. Scopri di più su come usare i playbook in modo efficace. I playbook sono prompt riutilizzabili e condivisibili che semplificano l’assegnazione dei task. Ad esempio, se vuoi che Devin gestisca i continui errori nei build CI, crea un playbook che includa i passaggi generali che Devin dovrebbe seguire ogni volta.Per il contesto persistente che Devin deve ricordare in tutte le sessioni — come standard di coding, bug comuni e relative correzioni, workflow di deployment o il modo in cui usare gli strumenti interni — usa Knowledge. Gli elementi di Knowledge vengono richiamati automaticamente quando sono pertinenti, così non devi ripetere le stesse istruzioni in ogni prompt. Puoi associare elementi di Knowledge a repo specifici oppure applicarli a livello globale.
Playbooks vs. Knowledge: Usa i Playbooks per procedure passo-passo legate a task specifici. Usa Knowledge per suggerimenti generali, convenzioni e contesto che si applicano in modo trasversale alle varie sessioni.