Ви хочете один контракт, який випускає мечі, зілля та ключі, кожен із власним token id, і хочете знати, хто має право створювати нові токени. Агент пише код Solidity, запускає команди компіляції та тестування на локальному ланцюжку або тестовій мережі та показує кожен крок як картку з реальним результатом. Цей посібник розглядає функцію створення, оскільки той, хто може її викликати, вирішує, скільки токенів існує. Розгорнутий контракт не можна змінити, тому все це залишається на локальному ланцюжку або тестовій мережі, де монети не мають вартості. Новачки можуть крок за кроком виконувати чотири кроки, а досвідчені читачі можуть пропустити їх і перейти до детальних описів нижче. Ті самі чотири кроки працюють для набору квитків, де кожен тип квитка отримує свій id, а функція створення вирішує, скільки кожного типу існує.
Запустіть WaveClamp, виберіть папку, що містить файли .sol та тести, як робочу папку чату, і оберіть Ask first, щоб кожна зміна надходила як diff, який ви приймаєте або відхиляєте. Інструменти для роботи з файлами працюють у межах цієї папки, тому тримайте проєкт в одному місці. Створіть тимчасову папку для першого запуску, якщо ви хочете лише потренуватися.
Запитайте про контракт ігрових предметів із трьома типами предметів, функцією створення, яку може викликати лише один обліковий запис власника, та пакетними переказами, і дозвольте агенту створити файл за допомогою write_file. Назвіть файл відповідно до контракту, щоб наступні кроки могли посилатися на нього. Зробіть перший запит невеликим, оскільки другий запит може додати пакетні перекази після прийняття першого diff.
Попросіть агента запустити вашу команду компіляції та команду тестування через Shell, а потім прочитайте код виходу та назви будь-яких невдалих тестів на розгорнутій картці. Успіх оцінюється за реальним кодом виходу, а не за зведеним звітом. Якщо команда компіляції завершиться з помилкою, картка покаже текст помилки, і агент зможе прочитати його та запропонувати виправлення у вигляді нового diff.
Відкрийте розгорнуті картки, прочитайте diff та вивід команди, прийміть правильне, відхиліть решту та запитайте виправлення там, де тест все ще не проходить. Повторюйте, доки тести не пройдуть успішно, а потім ще раз прочитайте функцію створення. Зберігайте кожен прийнятий diff невеликим, щоб пізніша помилка вказувала на одну зміну, а не на десять.
MultiTokenMinimal.solзбереженоMultiTokenMinimal.sol14 рядківbalanceOf1 збігyour 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);
}Цей інтерфейс лише для читання оголошує захід TransferSingle та функції balanceOf і uri стандарту мульти-токенів. Він не містить стану, логіки створення токенів чи ключів, що робить його невеликим файлом для читання перед додаванням реальної логіки. Спочатку запустіть команду компіляції для нього. Спочатку скомпілюйте його, а потім дозвольте агенту розширити його по одному переглянутому diff за раз, починаючи з функції створення. Ім'я файлу відповідає мітці прикладу, тому ви можете попросити агента відкрити його пізніше.
Відкрийте контракт і попросіть агента обгорнути допоміжну функцію ERC1155 _mint у публічну функцію, яку може викликати лише обліковий запис власника. Агент використовує read_file, щоб побачити поточний код, та edit_file, щоб вставити функцію, і показує зміну як diff. Загальнодоступні реалізації з відкритим кодом надають внутрішні допоміжні функції з іменами _mint та _mintBatch, і внутрішня допоміжна функція не має власної перевірки доступу, тому обгортка має значення. Ви можете крок за кроком створити токен ERC20 за допомогою того ж методу, але для набору ігрових предметів потрібні id, тому почніть із макету мульти-токенів. Shell потім запускає вашу команду компіляції та команду тестування, і кожна картка показує реальний код виходу. Прийміть diff лише після того, як ви прочитали тести.
Відкрийте приклад контракту ERC721 зі свого власного проєкту або попросіть агента написати його за допомогою write_file і розмістіть його поруч із вашим набором предметів. Агент використовує grep для переліку функцій у обох файлах та read_file для порівняння того, як зберігається власність: один власник на токен у файлі унікального токена, баланс на обліковий запис і id у файлі мульти-токена. Стандарт для децентралізованих профілів із використанням soulbound NFT вимагав би токенів, які не можна передати, що є іншим дизайном від предметів, які гравці передають один одному. Попросіть агента звести різницю в коротку таблицю. Ви читаєте порівняння в чаті, вирішуєте, який стандарт підходить для вашого дизайну, і лише потім запитуєте зміни в коді.
Гравці часто переміщують кілька типів предметів одночасно, тому попросіть агента додати до контракту safeBatchTransferFrom та balanceOfBatch. Агент використовує edit_file для зміни, glob для пошуку файлів тестів та Shell для запуску вашої команди тестування після кожної зміни. Функції пакетного переміщення переміщують кілька token id в одній транзакції, що означає, що один тест може перевірити кілька балансів. Розуміння безкоштовної реєстрації через ERC4337 — це окрема тема, тому залиште її за межами першого контракту та протестуйте її окремо. Прочитайте diff у режимі Ask first, знову запустіть тести та шукайте захід TransferBatch у виводі перед прийняттям зміни.
Контракт, який отримує токени, повинен реалізувати onERC1155Received та onERC1155BatchReceived і приймати токени, інакше безпечний переказ буде відхилено. Попросіть агента виконати grep для обох імен та відкрити контракт одержувача за допомогою read_file, а потім перелічити, якого саме не вистачає. Далі попросіть його використати edit_file для значення uri(id), щоб воно містило {id}, який клієнти замінюють на token id у нижньому регістрі шістнадцяткового формату, доповнений нулями до 64 символів. Використовуйте write_file для одного JSON-файлу на кожен id. Запустіть команду компіляції та команду тестування, прочитайте обидва коди виходу та перегляньте фінальний diff перед його прийняттям.
