Inizia la tua prima sessione e scopri cosa può fare Devin
Prima di iniziare la tua prima sessione, assicurati di aver indicizzato e configurato i tuoi repository. Questi passaggi fondamentali aiutano Devin a comprendere e a lavorare sulla tua codebase.
Ora che hai completato la configurazione, avvia la tua prima sessione con Devin! Questa guida ti guiderà nella nuova interfaccia della sessione e ti aiuterà a capire come interagire al meglio con Devin.
Quando avvii una nuova sessione, ti vengono presentate due modalità principali: Ask e Agent.
A meno che tu non abbia già un piano ben definito, consigliamo di iniziare con Ask per collaborare con Devin alla definizione di un piano, quindi passare alla modalità Agent per eseguirlo.
Ask Devin è una modalità leggera per esplorare la tua codebase e pianificare attività con Devin, senza modificare effettivamente il codice. Usa la modalità Ask per:
Fare domande su come funziona il tuo codice
Esplorare l’architettura e le dipendenze
Pianificare e definire l’ambito delle attività prima dell’implementazione
Generare prompt ricchi di contesto per le sessioni di Agent
Puoi attivare Ask mode dalla pagina principale o da una pagina DeepWiki.Per usare Ask mode dalla pagina principale, passa ad Ask mode e seleziona il/i repository su cui vuoi porre domande.
Per usare Ask mode da una pagina DeepWiki, digita una query nel campo di input della chat in fondo alla pagina e fai clic su Ask. Questo contestualizzerà automaticamente le conoscenze di Devin a quello specifico repository.
Scopri di più nella nostra guida Ask Devin.Dopo aver lavorato con Devin per capire il problema e creare un piano, sei pronto per passare ad Agent mode.
La modalità Agent è la modalità completamente autonoma di Devin, in cui può scrivere codice, eseguire comandi, navigare sul web e completare attività complesse end-to-end. Usa la modalità Agent quando sei pronto a:
Implementare funzionalità o correggere bug
Aprire pull request
Eseguire test e fare debug dei problemi
Svolgere attività in più passaggi che richiedono modifiche al codice
Puoi attivare la modalità Agent dalla pagina principale o da una sessione Ask Devin.Per attività che non sono completamente definite, ti consigliamo di:
Iniziare con la modalità Ask per pianificare l’attività
Creare un Devin Prompt, che utilizzerà la tua sessione Ask per creare un piano con ambito ben definito
Fare clic su Send to Devin per passare alla modalità Agent ed eseguire l’attività
Questo flusso è illustrato di seguito:
Per avviare la modalità Agent dalla pagina principale, passa alla modalità Agent e seleziona uno o più repository con cui vuoi lavorare.
Quando avvii una sessione Agent, dovrai configurare alcune opzioni: la selezione di un Repository e la selezione di un Agent.
Seleziona il repository con cui vuoi che Devin lavori. Fai clic sul selettore del repository per vedere tutti i repository che sono stati aggiunti alla macchina di Devin.
Selezionare un repository garantisce che Devin:
abbia accesso alla tua codebase e possa apportare modifiche
utilizzi il branch corretto come punto di partenza
Puoi scegliere quale configurazione di agent Devin utilizzare per la tua sessione. Gli agent possono avere funzionalità diverse o essere ottimizzati per tipi specifici di attività.Attualmente abbiamo un agent predefinito che funziona bene per la maggior parte delle attività e un agent data analyst chiamato Dana, ottimizzato per attività di analisi dei dati.
Se non sai quale agent utilizzare, quello predefinito è adatto alla maggior parte delle attività.
Usa le menzioni @ per fornire a Devin un contesto specifico su file, repository o altre risorse. Quando digiti @ nel campo di input della chat, vedrai un menu a discesa con le menzioni disponibili:
@Repos - Fai riferimento a un repository specifico
@Files - Fai riferimento a un file specifico nella tua codebase
@Macros - Fai riferimento a una macro per una voce di Knowledge
@Playbooks - Fai riferimento a un playbook del team o della community, ovvero template di prompt dettagliati che possono essere utilizzati per guidare il comportamento di Devin.
@Secrets - Fai riferimento a uno specifico secret (ad es. API key, credenziali, ecc.) dal gestore di sessioni di Devin
Le menzioni @ aiutano Devin a capire esattamente su cosa stai lavorando e a ridurre l’ambiguità nei tuoi prompt.
I comandi slash sono scorciatoie che si espandono in modelli di prompt predefiniti. Digita / nel campo di input della chat per vedere i comandi disponibili:
/plan - Chiedi a Devin di aiutarti a definire l’ambito e pianificare un’attività
/review - Configura un flusso di lavoro per la revisione del codice
/test - Crea test o analizza la copertura dei test
/think-hard - Chiedi a Devin di riflettere più a fondo su problemi complessi
/implement - Implementa una specifica funzionalità o modifica
Le organizzazioni Enterprise possono anche creare comandi slash personalizzati per flussi di lavoro specifici del team. Scopri di più nella nostra guida ai comandi slash.
Inizia con attività di portata più limitata e ricorda di istruire Devin con il livello di dettaglio che forniresti a un ingegnere junior umano. Abbiamo visto utenti collaborare con Devin su tutto, dalla correzione di piccoli bug ai refactor mirati fino alle migrazioni su larga scala.
Crea un nuovo endpoint /users/stats che restituisca un oggetto JSON con il numero di utenti e l'età media al momento dell'iscrizione. Usa la nostra tabella users già esistente in PostgreSQL. Puoi fare riferimento all'endpoint /orders/stats in statsController.js per vedere come strutturiamo le risposte. Assicurati che il nuovo endpoint sia coperto dai test nella suite StatsController.test.js.
Piccole funzionalità del frontend
frontend features
Copia
Chiedi all'IA
In UserProfileComponent, aggiungi un menu a discesa che mostri l'elenco dei ruoli utente (admin, editor, viewer). Usa lo stile di DropdownBase. Quando viene selezionato un ruolo, chiama l'API esistente per impostare il ruolo utente. Verifica che la selezione aggiorni il ruolo utente nel DB. Fai riferimento alla tua Knowledge per eseguire i test correttamente.
Scrivere test unitari
unit tests
Copia
Chiedi all'IA
Aggiungi test Jest per i metodi di AuthService: login e logout. Assicurati che la copertura dei test per queste due funzioni sia almeno dell'80%. Usa UserService.test.js come esempio.Dopo l'implementazione, esegui `npm test -- --coverage` e verifica che il report di copertura mostri >80% per entrambe le funzioni. Conferma inoltre che i test vengano superati sia con credenziali valide che non valide e che il logout svuoti correttamente i dati di sessione.
Migrazione o refactoring del codice esistente
or refactoring existing code
Copia
Chiedi all'IA
Esegui la migrazione di logger.js da JavaScript a TypeScript. Disponiamo già di un tsconfig.json e di una suite di test LoggerTest.test.js per la validazione. Assicurati che compili senza errori e non modificare la configurazione esistente!Dopo la migrazione, verifica quanto segue: 1) esegui `tsc` per confermare che non ci siano errori di tipo2) esegui la suite di test con `npm test LoggerTest.test.js` per assicurarti che tutti i test vengano superati3) verifica che tutte le chiamate esistenti ai metodi del logger in tutto il codebase continuino a funzionare senza errori di tipo.
Aggiornamento delle API o delle query al database
unit tests
Copia
Chiedi all'IA
Stiamo effettuando la migrazione da pg a Sequelize (vedi https://sequelize.org/api/v6/identifiers). Aggiorna le query di UserModel per usare i metodi di Sequelize. Fai riferimento a OrderModel per vedere come lo gestiamo in questo codebase.Dopo l'implementazione, verifica:1) eseguendo `npm run test:integration UserModel.test.js` per verificare che tutti i test di integrazione vengano superati2) confermando che le prestazioni delle query non siano peggiorate, controllando il tempo di esecuzione su un dataset di test di 1000 utenti3) verificando che tutte le operazioni CRUD mantengano ancora l'integrità dei dati, eseguendo `npm run test:e2e user-flows.test.js`
Crea una PR rapida (consigliamo di utilizzare questo prompt in un Playbook)
Quick PR
Copia
Chiedi all'IA
## PanoramicaIl compito è creare una pull request rapida in un repository.Poiché questa è una PR "rapida", non avrai bisogno di eseguire alcun codice o testare nulla; limitati a creare una PR e l'utente si occuperà dei test. La tua unica responsabilità è leggere e scrivere codice.## Cosa è necessario dall'utente- Il repository su cui creare la pull request## Procedura### Prepara il tuo ambiente di lavoro1. Vai al repository rilevante sulla tua macchina (chiarisci con l'utente se non riesci a capirlo). - Fai il checkout del branch principale e annota il nome del branch principale. - Fai il checkout di un nuovo branch dato che creerai una pull request. Il nome del branch deve avere il formato `devin/<your-branch-name>/X` dove X è un numero casuale. Ad esempio `devin/fix-popup/3234`. Esegui `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` e sostituisci `{branch-name}` con il nome del branch che vuoi creare.2. Studia la richiesta, il codebase e pianifica le modifiche - Esamina i file e le sezioni di codice più rilevanti, identificando gli snippet pertinenti. - Informa l'utente del tuo piano### Lavora sulla PR3. Apporta le modifiche al codice - Non cambiare nulla che non sia stato specificamente richiesto dall'utente4. Crea la PR - Effettua il commit e il push delle modifiche e avvisa l'utente. - Consulta la sezione dei consigli per il comando esatto con cui creare la PR - Crea una pull request e rivedi la PR per assicurarti che sia tutto a posto. - Assicurati che tutte le GitHub Actions vadano a buon fine e apporta le modifiche necessarie finché non succede - Invia all'utente il link della PR e riassumi ciò che hai cambiato.5. Gestisci qualsiasi feedback dalla review; invia di nuovo il link della PR ogni volta che apporti modifiche - Se hai bisogno di fare aggiornamenti, esegui semplicemente il push di altri commit sullo stesso branch; non crearne uno nuovo## Specifiche del task- Il link della PR è incluso nei tuoi messaggi all'utente- La PR è stata rivista dopo la creazione- La PR non include modifiche spurie- La PR non cambia nulla che non sia stato specificamente richiesto dall'utente- La descrizione della PR deve includere un riepilogo delle modifiche, formattato come checklist- La descrizione della PR deve menzionare che il codice è stato scritto senza essere testato e includere - [ ] Test the changes come elemento- La descrizione della PR deve includere il seguente footer: "Questa PR è stata scritta da [Devin](https://devin.ai/) :angel:"- La descrizione della PR deve includere tutti i metadati forniti dall'utente (ad es. tag dei ticket Linear nella sintassi appropriata)- La descrizione della PR non deve essere malformattata (usa --body-file invece di --body se le nuove righe risultano illeggibili!)## Azioni vietate- NON provare ad accedere a github.com tramite il browser, non sarai autenticato.- NON fare mai force push sui branch! Preferisci il merge al rebase così da non perdere alcun lavoro.- NON eseguire push direttamente sul branch principale.## Consigli e suggerimenti- Controlla due volte il nome del branch principale (che potrebbe essere `main` o `master`) usando `git branch`.- Per i repository con CI/CD su GitHub Actions, puoi controllare i log di build usando la gh cli. Se ti viene chiesto di sistemare una build o di correggere errori di linting, dovresti iniziare guardando i log delle build recenti.- Controlla `git status` prima di effettuare commit o aggiungere file.- Usa `git diff` per vedere quali modifiche hai fatto prima di effettuare il commit.- Se stai aggiornando un repository esistente, usa `gh cli` per creare pull request.- Invia all'utente il link della PR ogni volta che effettui un aggiornamento e chiedi di rivederla di nuovo, in modo che sia comodo per loro.- Dovresti essere già autorizzato ad accedere a qualsiasi repository che l'utente ti segnala. In caso contrario, chiedi all'utente l'accesso.
Se vuoi approfondire alcuni esempi più dettagliati di ciò che Devin può fare (e come), consulta i nostri tutorial introduttivi qui sotto.
