Ordner öffnen
Wähle den Projektordner als Arbeitsordner für einen neuen Chat und wähle Ask first, damit jede Änderung, die eine Datei schreibt, auf deine Entscheidung wartet. Lege die ABI-Datei in diesen Ordner, bevor du startest.
Workflows
Erstelle eine dApp aus einem leeren Ordner bis zum getesteten Bildschirm
03
Starte mit einem leeren Projektordner
Um eine dApp zu erstellen, beginne mit einem Ordner, der nur die ABI-Datei deines eigenen Vertrags enthält. Öffne diesen Ordner als Arbeitsordner für einen neuen Chat, wähle Ask first und beschreibe die Seite, die du möchtest: einen Connect-Wallet-Button, einen Saldo und eine Zeile für den Transaktionsstatus. Der Agent kartiert den Ordner, schlägt Dateien als Diffs vor und erstellt die Seite erst, nachdem du jede Änderung akzeptiert hast. Entscheide vor dem Start, wo das Projekt laufen soll. Eine lokale Chain auf deinem eigenen PC eignet sich gut für einen ersten Versuch, da die Coins darauf keinen Wert haben, und ein öffentliches Testnetz ist der nächste Schritt, sobald die Seite funktioniert. Nutze Wegwerfkonten auf beiden, niemals ein Konto, das echte Gelder enthält, und halte jeden Private Key und jeden Seed-Phrase aus dem Ordner, dem Chat und dem Repository. Das Ergebnis ist eine kleine, getestete Seite und eine README, der eine andere Person folgen könnte.
Bildschirm beschreiben
Schreibe in einfachen Sätzen, welche Daten die Seite anzeigt und welche Transaktionszustände sie verarbeiten muss. Nenne die Vertragsfunktion, die sie aufruft, und das Netzwerk, mit dem sie kommuniziert, zum Beispiel deine lokale Chain.
Jeden Diff prüfen
Lies jede vorgeschlagene Dateiänderung im Chat, akzeptiere sie dann oder lehne sie mit einer kurzen Notiz ab. Erweitere eine Karte, wenn du den vollständigen Diff sehen möchtest, und lehne alles ab, was du nicht in einem Satz erklären kannst.
Ausführen und prüfen
Lass Shell deinen Build-Befehl und deinen Testbefehl ausführen und lies den Exit-Code auf jeder Karte. Öffne die Seite gegen die lokale Chain und vergleiche, was sie anzeigt, mit deinen Erwartungen. Behebe Fehler, bevor du das nächste Feature hinzufügst.
Eine kleine ABI-Datei zum Starten
Lese balanceOf aus der ABI und zeige das Ergebnis auf der Seite an.
- read_file
balance-abi.jsongeladen - write_file
app.jsgespeichert - edit_file
index.html+4 Zeilen - Shell
your build commandexit 0
wartet auf Ihre Freigabe, bevor der nächste Schritt ausgeführt wirdAblehnenAkzeptieren
balance-abi.json
[
{
"type": "function",
"name": "balanceOf",
"stateMutability": "view",
"inputs": [{ "type": "address", "name": "account" }],
"outputs": [{ "type": "uint256" }]
}
]Dieses JSON-Fragment beschreibt eine schreibgeschützte Funktion, balanceOf, die Saldo-Lesefunktion, die ERC-20-Token verwenden. Sie nimmt eine Adresse namens account entgegen und gibt einen uint256 zurück. Ein Frontend verwendet eine solche ABI, um den Vertrag aufzurufen, und die Datei enthält keinen Schlüssel und kein Geheimnis. Speichere sie als balance-abi.json im Projektordner und ersetze sie durch die vollständige ABI deines eigenen Vertrags, sobald die Seite funktioniert, da ein echter Vertrag normalerweise viele weitere Funktionen hat.
Anleitungen für eine erste dApp
Ordner kartieren und ABI lesen
Ein guter Weg, um Web3 zu lernen, ist, eine kleine ABI-Datei zu lesen, bevor du irgendetwas schreibst. Bitte den Agenten, balance-abi.json zu öffnen. read_file zeigt die Datei an, list_dir zeigt, was sonst noch im Ordner ist, und grep bestätigt den genauen Namen der Funktion. Der Agent erklärt dann im Chat, dass balanceOf eine View-Funktion ist: Sie liest Daten und sendet keine Transaktion, daher ändert das Aufrufen nichts an der Chain. Noch wird nichts geschrieben. Sie listet auch auf, was die Seite benötigt, nämlich eine Verbindung zu einem Node, die Adresse des bereitgestellten Vertrags und ein Konto, das abgerufen werden soll. Prüfe jede Aussage gegen das JSON auf der Karte, da ein Modell einen Typ falsch lesen oder eine Funktion benennen kann, die nicht in der Datei enthalten ist, und bitte um Korrektur, bevor du fortfährst.
Seite mit einer lokalen Chain verbinden
Bitte um eine Seite, die den Saldo eines Wegwerf-Testkontos liest. write_file erstellt app.js mit einem Aufruf an deine lokale Chain über JSON-RPC, und edit_file fügt eine Script-Zeile zu index.html hinzu. Du brauchst Cross-Chain-Tools für eine dApp nur, wenn sie mit mehreren Chains kommuniziert; ein erstes Projekt auf einer lokalen Chain benötigt keines, also lass sie weg. Im Ask first-Modus warten beide Änderungen als Diffs. Lies sie und akzeptiere sie. Shell führt dann deinen Build-Befehl aus, und die Karte zeigt den echten Exit-Code. Öffne die Seite, vergleiche die Zahl, die sie anzeigt, mit der Zahl, die deine lokale Chain für dasselbe Konto meldet, und bitte den Agenten, die Seite zu korrigieren, wenn die beiden abweichen. Halte die Chain-Adresse an einer Stelle, damit das Ändern des Netzwerks später nur das Bearbeiten einer einzelnen Zeile bedeutet.
Transaktionszustände verarbeiten
Der Übergang von Web2 zu Web3 als Entwickler bedeutet hauptsächlich, eine Wallet, ein Netzwerk und einen Transaktionszustand zu Bildschirmen hinzuzufügen, die du bereits zu bauen kennst. Bitte den Agenten, eine Statuszeile mit 5 Zuständen hinzuzufügen: nicht gesendet, Wallet wird abgefragt, ausstehend, bestätigt und fehlgeschlagen. edit_file ändert das Script und die Stylesheet, und grep findet jede Stelle, an der ein Zustand noch fehlt. Die Wallet signiert; dein Code berührt niemals einen Private Key oder einen Seed-Phrase. Bitte auch um Nachrichten für eine fehlende Wallet, das falsche Netzwerk und eine abgelehnte Signatur, denn ein echter Benutzer wird ihnen früher oder später begegnen. Führe die Seite in einem Testnetz mit einem Wegwerf-Konto aus, lehne absichtlich eine Signatur ab und prüfe, ob der fehlgeschlagene Zustand mit einer klaren Meldung erscheint.
Testen, dann das Projekt dokumentieren
Bitte den Agenten, einen Frontend-Test für jeden Zustand und eine kurze README zu schreiben, die erklärt, wie das Projekt ausgeführt wird. write_file erstellt beide Dateien, Shell führt deinen Testbefehl aus und die Karte meldet den echten Exit-Code. Ein dApp-Entwickler, der ein Monat später zum Projekt zurückkehrt, wird zuerst diese README lesen, also prüfe, ob sie nur Befehle nennt, die du tatsächlich verwendest, und ob sie angibt, welches Netzwerk die Seite erwartet. Nutze zuerst den Plan only-Modus, wenn du die Liste der Schritte sehen möchtest, bevor eine Datei erstellt wird, und wechsle dann zu Ask first, um sie durchzuführen. Lies jeden Diff, führe die Tests selbst einmal in einem Testnetz mit Wegwerf-Konten aus und halte die README neben der ABI-Datei, damit beide synchron bleiben.
