Dezvoltarea aplicațiilor Web3 în dosarul propriului proiect

Ce poate face agentul pentru dApp-ul tău

• Fișiereread_file, write_file, edit_file, grep, glob și list_dir funcționează în dosarul de lucru al chat-ului, astfel încât componentele, stilurile și fișierul JSON ABI pot fi citite și modificate acolo.
• Shellrulează propria comandă de build și comanda de test pe Windows, WSL sau un server SSH pe care îl deții, și raportează codul de ieșire real al fiecăreia.
• Webweb_search și http_get citesc paginile de documentație publice, astfel încât o întrebare despre o bibliotecă sau o interfață poate fi verificată împotriva paginii care o descrie.
• Capturi de ecran și imaginiocr citește textul unei capturi de ecran salvate, cum ar fi un mock-up de design, iar gen_image salvează fișiere imagine, cum ar fi ilustrații placeholder.
• Orchestraretask lansează sub-agente pentru părți separate ale muncii în paralel, run_on_model trimite un pas dificil unui model mai mare, iar skill reutilizează un playbook.
• Moduri de aprobareAuto-run acționează imediat, Ask first se oprește înainte de acțiunile care modifică ceva și afișează un diff, iar Plan only scrie un plan și nu rulează nimic.
• Cronrulează un prompt la intervale, de exemplu comanda de test o dată pe zi, iar planurile supraviețuiesc restartării aplicației, astfel încât un task lung poate continua mai târziu.
• Modelefolosește un furnizor AI cloud printr-un endpoint API standard, un model pe propriul PC sau modelul integrat și apasă Test pentru a verifica un endpoint.

Patru ghiduri pentru un proiect dApp

Mapează un proiect preluat

Îl rogi pe agent să mapneze un dosar dApp început de altcineva. list_dir arată structura, glob găsește fișierele componentă și ABI, iar grep listează fiecare loc unde se apelează o funcție de contract. Fiecare rezultat este un card în chat. Nimic nu se modifică. Mapa arată unde sunt gestionate stările tranzacțiilor și unde lipsesc, iar ceea ce împiedică adoptarea dapp-urilor este adesea un front-end care eșuează fără a spune de ce: fără portofel, rețeaua greșită sau o semnătură respinsă. Modul Plan only se potrivește bine acestei sarcini, deoarece scrie planul și nu rulează nimic, iar planul poate numi fișierele care necesită atenție prima dată. Cere un rezumat scris scurt, apoi citește-l împotriva dosarului înainte de a începe orice editare și corectează agentul dacă a interpretat greșit un fișier.

Conectează un ABI într-o componentă

Cere o componentă care afișează soldul unui cont de test. read_file deschide JSON-ul ABI, astfel încât agentul știe că balanceOf primește un address și returnează un uint256, iar edit_file adaugă apelul la componenta ta. În modul Ask first, modificarea așteaptă sub forma unui diff. Citești liniile adăugate și eliminate, le accepți sau le respingi și ceri o revizuire dacă un nume sau un tip pare greșit. Shell rulează apoi comanda ta de build și raportează codul de ieșire real pe card, iar poți extinde cardul pentru a citi output-ul complet. Un build verde arată că codul se compilează; nu arată că se apelează funcția corectă, așa că verifică apelul împotriva ABI-ului tău și menține fișierul ABI sincronizat cu contractul.

Testează fiecare stare de tranzacție

Interfețele eșuează în spațiile dintre stări: ne trimisă, așteptând portofelul, în așteptare, confirmată și eșuată. Pentru a opri construirea de dApp-uri fantomă care par finalizate și se strică la prima semnătură respinsă, roagă agentul să scrie un test front-end pentru fiecare stare. write_file creează fișierul de test, edit_file ajustează componenta unde lipsește o stare, iar Shell rulează comanda ta de test. Cardul arată codul de ieșire și, când îl extinzi, output-ul complet. Rulează testele împotriva unui lanț local cu conturi de împrumut, citește fiecare eșec și decide dacă testul sau componenta este greșit. Nu accepta o modificare doar pentru că testele devin verzi: citește diff-ul și verifică dacă testul afirmă cu adevărat starea după care este numit.

Planifică o funcționalitate, apoi implementeaz-o

Un dezvoltator care vrea să avanseze după 1 an în web3 poate cere agentului un plan care adaugă stări de încărcare, remedieri de accesibilitate și teste la un dApp existent. În modul Plan only, agentul scrie pașii și nu rulează nicio comandă și nu modifică niciun fișier. Citești planul, tai ceea ce nu vrei și treci la Ask first pentru a-l implementa. De atunci, agentul se oprește înainte de fiecare acțiune care modifică ceva, iar tu citești fiecare diff înainte de a-l accepta. Planurile supraviețuiesc unui restart, astfel încât te poți opri la orice pas și poți continua a doua zi. Termină prin a-ți rula comanda de test și citind output-ul ei în persoană și notează în README care comenzi ai folosit.