Sie möchten einen Vertrag, der Schwerter, Tränke und Schlüssel ausgibt, wobei jeder Token eine eigene ID hat, und Sie möchten wissen, wer berechtigt ist, neue Token zu erstellen. Der Agent schreibt den Solidity-Code, führt Ihre Kompilier- und Testbefehle auf einer lokalen Chain oder einem Testnetzwerk aus und zeigt jeden Schritt als Karte mit dem tatsächlichen Ergebnis an. Dieser Leitfaden konzentriert sich auf die Minting-Funktion, denn wer sie aufrufen kann, entscheidet, wie viele Token existieren. Ein bereitgestellter Vertrag kann nicht mehr geändert werden, daher bleibt alles hier auf einer lokalen Chain oder einem Testnetzwerk, dessen Coins keinen Wert haben. Anfänger können die vier Schritte nacheinander durchgehen, und erfahrene Leser können direkt zu den weiter unten stehenden Anleitungen springen. Dieselben vier Schritte funktionieren auch für einen Ticket-Satz, bei dem jede Ticketart ihre eigene ID erhält und die Minting-Funktion entscheidet, wie viele von jeder Art existieren.
Starten Sie WaveClamp, wählen Sie den Ordner mit Ihren .sol-Dateien und Tests als Arbeitsordner für den Chat und aktivieren Sie Ask first, damit jede Änderung als Diff ankommt, den Sie akzeptieren oder ablehnen können. Die Dateitools arbeiten in diesem Ordner, also halten Sie das Projekt an einem Ort zusammen. Erstellen Sie für den ersten Lauf einen temporären Ordner, wenn Sie nur üben möchten.
Fordern Sie einen Spielgegenstands-Vertrag mit drei Gegenstandstypen, einer Minting-Funktion, die nur ein Besitzerkonto aufrufen kann, und Batch-Übertragungen an, und lassen Sie den Agenten die Datei mit write_file erstellen. Benennen Sie die Datei nach dem Vertrag, damit spätere Schritte darauf verweisen können. Halten Sie die erste Anfrage überschaubar, da eine zweite Anfrage Batch-Übertragungen hinzufügen kann, nachdem der erste Diff akzeptiert wurde.
Weisen Sie den Agenten an, Ihren Kompilierbefehl und Ihren Testbefehl über Shell auszuführen. Lesen Sie dann den Exit-Code und die Namen aller fehlgeschlagenen Tests auf der erweiterten Karte. Erfolg wird am tatsächlichen Exit-Code gemessen, nicht an einer Zusammenfassung. Wenn der Kompilierbefehl fehlschlägt, zeigt die Karte den Fehlertext an, und der Agent kann ihn lesen und eine Korrektur als neuen Diff vorschlagen.
Öffnen Sie die erweiterten Karten, lesen Sie den Diff und die Befehlsausgabe, akzeptieren Sie die richtigen Änderungen, lehnen Sie den Rest ab und bitten Sie um eine Korrektur, wo immer ein Test noch fehlschlägt. Wiederholen Sie dies, bis die Tests bestanden sind, und lesen Sie die Minting-Funktion noch einmal durch. Halten Sie jeden akzeptierten Diff klein, damit ein späterer Fehler auf eine einzige Änderung und nicht auf zehn zurückzuführen ist.
MultiTokenMinimal.solgespeichertMultiTokenMinimal.sol14 ZeilenbalanceOf1 Trefferyour compile commandexit 0// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IMultiTokenMinimal {
event TransferSingle(address indexed operator,
address indexed from, address indexed to,
uint256 id, uint256 value);
function balanceOf(address account, uint256 id)
external view returns (uint256);
function uri(uint256 id)
external view returns (string memory);
}Diese schreibgeschützte Schnittstelle deklariert das TransferSingle-Event sowie die Funktionen balanceOf und uri des Multi-Token-Standards. Sie enthält keinen Status, keine Minting-Logik und keine Schlüssel, was sie zu einer kleinen Datei macht, die Sie lesen sollten, bevor Sie echte Logik hinzufügen. Führen Sie Ihren Kompilierbefehl zuerst damit aus. Kompilieren Sie zuerst, lassen Sie dann den Agenten ihn schrittweise um einen geprüften Diff erweitern, beginnend mit der Minting-Funktion. Der Dateiname entspricht dem Beispielkennzeichen, damit Sie den Agenten bitten können, sie später zu öffnen.
Öffnen Sie den Vertrag und bitten Sie den Agenten, den ERC1155 _mint-Helfer in eine öffentliche Funktion zu packen, die nur das Besitzerkonto aufrufen kann. Der Agent verwendet read_file, um den aktuellen Code zu sehen, und edit_file, um die Funktion einzufügen, und zeigt die Änderung als Diff an. Bei gängigen Open-Source-Implementierungen werden interne Helfer namens _mint und _mintBatch freigegeben, und ein interner Helfer hat keine eigene Zugriffsprüfung, weshalb der Wrapper wichtig ist. Sie können einen ERC20-Token schrittweise mit derselben Methode erstellen, aber ein Spielgegenstandssatz benötigt IDs, also beginnen Sie mit dem Multi-Token-Layout. Shell führt dann Ihren Kompilierbefehl und Ihren Testbefehl aus, und jede Karte zeigt einen tatsächlichen Exit-Code. Akzeptieren Sie den Diff erst, wenn Sie die Tests gelesen haben.
Öffnen Sie ein ERC721-Vertragsbeispiel aus Ihrem eigenen Projekt oder bitten Sie den Agenten, eines mit write_file zu schreiben, und platzieren Sie es neben Ihrem Gegenstandssatz. Der Agent verwendet grep, um die Funktionen in beiden Dateien aufzulisten, und read_file, um zu vergleichen, wie die Ownership gespeichert wird: ein Besitzer pro Token in der Unique-Token-Datei, ein Saldo pro Konto und ID in der Multi-Token-Datei. Ein Standard für dezentrale Profile mit Soulbound-NFTs würde Token benötigen, die nicht übertragbar sind, was ein anderes Design von Gegenständen ist, die Spieler weitergeben. Bitten Sie den Agenten, die Unterschiede in eine kurze Tabelle zu schreiben. Sie lesen den Vergleich im Chat, entscheiden, welcher Standard zu Ihrem Design passt, und bitten erst dann um Codeänderungen.
Spieler bewegen oft mehrere Gegenstandstypen gleichzeitig, also bitten Sie den Agenten, safeBatchTransferFrom und balanceOfBatch zum Vertrag hinzuzufügen. Der Agent verwendet edit_file für die Änderung, glob, um die Testdateien zu finden, und Shell, um Ihren Testbefehl nach jeder Bearbeitung auszuführen. Batch-Funktionen bewegen mehrere Token-IDs in einer Transaktion, was bedeutet, dass ein Test mehrere Salden überprüfen kann. Das Verständnis von ERC4337 Gasless Onboarding ist ein separates Thema, also halten Sie es aus dem ersten Vertrag heraus und testen Sie es separat. Lesen Sie den Diff in Ask first, führen Sie die Tests erneut aus und suchen Sie nach dem TransferBatch-Event in der Ausgabe, bevor Sie die Änderung akzeptieren.
Ein Vertrag, der Token empfängt, muss onERC1155Received und onERC1155BatchReceived implementieren und die Token akzeptieren, sonst wird die sichere Übertragung abgelehnt. Bitten Sie den Agenten, nach beiden Namen zu grepfen und den empfangenden Vertrag mit read_file zu öffnen, und listen Sie dann auf, welche fehlt. Bitten Sie ihn als Nächstes, edit_file für den uri(id)-Wert zu verwenden, damit er {id} enthält, das Clients durch die Token-ID in Kleinbuchstaben-Hexadezimalschreibweise ersetzen, aufgefüllt auf 64 Zeichen. Verwenden Sie write_file für eine JSON-Datei pro ID. Führen Sie Ihren Kompilierbefehl und Ihren Testbefehl aus, lesen Sie beide Exit-Codes und prüfen Sie den finalen Diff, bevor Sie ihn akzeptieren.
