Web3-App-Entwicklung direkt in Ihrem Projektordner

Was der Agent für Ihre dApp leisten kann

• Dateienread_file, write_file, edit_file, grep, glob und list_dir arbeiten im Arbeitsordner des Chats. So können Komponenten, Stylesheets und die ABI-JSON-Datei gelesen und geändert werden.
• ShellFührt Ihren eigenen Build- und Testbefehl unter Windows, WSL oder auf einem SSH-Server aus, den Sie besitzen, und meldet den echten Exit-Code jedes Befehls.
• Webweb_search und http_get lesen öffentliche Dokumentationsseiten. So lässt sich eine Frage zu einer Bibliothek oder Schnittstelle gegen die beschreibende Seite prüfen.
• Screenshots und Bilderocr liest den Text eines gespeicherten Screenshots, z. B. eines Design-Entwurfs, und gen_image speichert Bilddateien, z. B. Platzhaltergrafiken.
• Orchestrierungtask startet Sub-Agenten für separate Arbeitsschritte parallel, run_on_model sendet einen komplexen Schritt an ein größeres Modell, und skill wiederverwendet ein Skript.
• GenehmigungsmodiAuto-run handelt sofort, Ask first pausiert vor Änderungen und zeigt einen Diff, und Plan only erstellt einen Plan, führt aber nichts aus.
• CronFührt einen Prompt nach Zeitplan aus, z. B. Ihren Testbefehl einmal täglich. Pläne überleben einen App-Neustart, sodass eine lange Aufgabe später fortgesetzt werden kann.
• ModelleNutzen Sie einen Cloud-KI-Anbieter über einen Standard-API-Endpunkt, ein Modell auf Ihrem eigenen PC oder das integrierte Modell. Drücken Sie Test, um einen Endpunkt zu prüfen.

Vier Anleitungen für ein dApp-Projekt

Ein geerbtes Projekt kartieren

Sie bitten den Agenten, einen dApp-Ordner zu kartieren, den jemand anderes begonnen hat. list_dir zeigt die Struktur, glob findet die Komponenten- und ABI-Dateien, und grep listet jeden Ort auf, an dem eine Vertragsfunktion aufgerufen wird. Jedes Ergebnis ist eine Karte im Chat. Es ändert sich nichts. Die Karte zeigt, wo Transaktionszustände verarbeitet werden und wo sie fehlen. Oft verhindert ein Frontend, das ohne Erklärung versagt, die Adoption: kein Wallet, das falsche Netzwerk oder eine abgelehnte Signatur. Der Modus Plan only passt gut zu dieser Aufgabe, da er den Plan erstellt und nichts ausführt. Der Plan kann die Dateien nennen, die zuerst Aufmerksamkeit benötigen. Bitten Sie um eine kurze Zusammenfassung, prüfen Sie sie gegen den Ordner, bevor Sie mit einer Bearbeitung beginnen, und korrigieren Sie den Agenten, wenn er eine Datei falsch gelesen hat.

Eine ABI in eine Komponente einbinden

Sie bitten um eine Komponente, die den Saldo eines Testkontos anzeigt. read_file öffnet die ABI-JSON, sodass der Agent weiß, dass balanceOf eine Adresse entgegennimmt und einen uint256 zurückgibt, und edit_file fügt den Aufruf zu Ihrer Komponente hinzu. Im Ask first-Modus wartet die Änderung als Diff. Sie lesen die hinzugefügten und entfernten Zeilen, nehmen sie an oder lehnen sie ab, und bitten um eine Überarbeitung, wenn ein Name oder Typ falsch erscheint. Shell führt dann Ihren Build-Befehl aus und meldet den echten Exit-Code auf der Karte. Sie können die Karte erweitern, um die vollständige Ausgabe zu lesen. Ein grüner Build zeigt, dass der Code kompiliert; er zeigt nicht, dass die richtige Funktion aufgerufen wird. Prüfen Sie den Aufruf selbst gegen die ABI und halten Sie die ABI-Datei mit dem Vertrag synchron.

Jeden Transaktionszustand testen

Interfaces scheitern oft in den Lücken zwischen den Zuständen: nicht gesendet, wartend auf das Wallet, ausstehend, bestätigt und fehlgeschlagen. Um zu verhindern, dass Ghost-dApps gebaut werden, die fertig aussehen, aber bei der ersten abgelehnten Signatur zusammenbrechen, bitten Sie den Agenten, einen Frontend-Test für jeden Zustand zu schreiben. write_file erstellt die Testdatei, edit_file passt die Komponente an, wo ein Zustand fehlt, und Shell führt Ihren Testbefehl aus. Die Karte zeigt den Exit-Code und, wenn Sie sie erweitern, die vollständige Ausgabe. Führen Sie die Tests gegen eine lokale Chain mit Wegwerfkonten aus, lesen Sie jeden Fehler und entscheiden Sie, ob der Test oder die Komponente falsch ist. Akzeptieren Sie eine Änderung nicht nur, weil die Tests grün werden: Lesen Sie den Diff, und prüfen Sie, ob der Test wirklich den Zustand assertet, nach dem er benannt ist.

Eine Funktion planen, dann durchführen

Ein Entwickler, der nach 1 Jahr in der Web3-Entwicklung aufsteigen möchte, kann den Agenten um einen Plan bitten, der Ladezustände, Barrierefreiheitskorrekturen und Tests zu einer bestehenden dApp hinzufügt. Im Modus Plan only erstellt der Agent die Schritte, führt aber keinen Befehl aus und ändert keine Datei. Sie lesen den Plan, streichen, was Sie nicht wollen, und wechseln zu Ask first, um ihn durchzuführen. Ab jetzt pausiert der Agent vor jeder Aktion, die etwas ändert, und Sie lesen jeden Diff, bevor Sie ihn annehmen. Pläne überleben einen Neustart, sodass Sie an jedem Schritt stoppen und am nächsten Tag fortfahren können. Beenden Sie, indem Sie Ihren Testbefehl ausführen und dessen Ausgabe selbst lesen. Notieren Sie in der README, welche Befehle Sie verwendet haben.