Вам нужен один контракт, который выпускает мечи, зелья и ключи, каждый со своим идентификатором токена, и вы хотите знать, кто имеет право создавать новые токены. Агент пишет код на Solidity, запускает команды компиляции и тестов на локальной сети или тестовой сети, и показывает каждый шаг в виде карточки с реальным результатом. Это руководство описывает функцию минта, потому что тот, кто может её вызвать, определяет количество существующих токенов. Развёрнутый контракт нельзя изменить, поэтому всё, что описано здесь, остаётся в локальной сети или тестовой сети, где монеты не имеют стоимости. Новички могут пройти четыре шага последовательно, а опытные пользователи могут сразу перейти к подробным описаниям ниже. Те же четыре шага подходят для набора билетов, где каждый тип билета получает свой идентификатор, а функция минта определяет количество каждого типа.
Запустите WaveClamp, выберите папку, содержащую файлы .sol и тесты, в качестве рабочей папки чата, и выберите режим Ask first (Сначала спросить), чтобы каждое изменение приходило в виде diff, который вы можете принять или отклонить. Инструменты работы с файлами работают внутри этой папки, поэтому держите проект в одном месте. Создайте временную папку для первого запуска, если хотите просто потренироваться.
Попросите создать контракт игровых предметов с тремя типами предметов, функцией минта, которую может вызвать только один аккаунт владельца, и функцией пакетной передачи, и позвольте агенту создать файл с помощью write_file. Назовите файл в соответствии с именем контракта, чтобы последующие шаги могли ссылаться на него. Держите первый запрос небольшим, так как второй запрос может добавить пакетные передачи после принятия первого diff.
Попросите агента запустить команду компиляции и команду тестов через Shell, затем прочитайте код выхода и имена любых неудачных тестов на раскрытой карточке. Успех оценивается по реальному коду выхода, а не по сводке. Если команда компиляции завершается ошибкой, карточка показывает текст ошибки, и агент может прочитать его и предложить исправление в виде нового diff.
Откройте раскрытые карточки, прочитайте diff и вывод команд, примите то, что правильно, отклоните остальное и запросите исправление там, где тесты всё ещё не проходят. Повторяйте, пока тесты не пройдут, затем ещё раз прочитайте функцию минта. Держите каждый принятый diff небольшим, чтобы последующая ошибка указывала на одно изменение, а не на десять.
MultiTokenMinimal.solsavedMultiTokenMinimal.sol14 linesbalanceOf1 matchyour 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 тем же методом, но для набора игровых предметов нужны идентификаторы, поэтому начните с макета мульти-токена. Затем Shell запускает команду компиляции и команду тестов, и каждая карточка показывает реальный код выхода. Принимайте diff только после того, как прочитаете тесты.
Откройте пример контракта ERC721 из вашего собственного проекта или попросите агента написать его с помощью write_file и поместите его рядом с вашим набором предметов. Агент использует grep, чтобы перечислить функции в обоих файлах, и read_file, чтобы сравнить, как хранится владение: один владелец на токен в файле уникального токена, баланс на аккаунт и идентификатор в файле мульти-токена. Стандарт для децентрализованных профилей с использованием привязанных NFT потребовал бы токены, которые нельзя передать, что является другим дизайном от предметов, которые игроки передают друг другу. Попросите агента оформить различия в виде краткой таблицы. Вы читаете сравнение в чате, решаете, какой стандарт подходит вашему дизайну, и только затем запрашиваете изменения в коде.
Игроки часто перемещают несколько типов предметов одновременно, поэтому попросите агента добавить safeBatchTransferFrom и balanceOfBatch в контракт. Агент использует edit_file для изменения, glob для поиска файлов тестов и Shell для запуска команды тестов после каждого редактирования. Пакетные функции перемещают несколько идентификаторов токенов в одной транзакции, что означает, что один тест может проверить несколько балансов. Понимание безгазового онбординга ERC4337 — это отдельная тема, поэтому держите её вне первого контракта и тестируйте её отдельно. Читайте diff в режиме Ask first, снова запустите тесты и ищите событие TransferBatch в выводе, прежде чем принять изменение.
Контракт, который получает токены, должен реализовать onERC1155Received и onERC1155BatchReceived и принять токены, иначе безопасная передача будет отклонена. Попросите агента выполнить grep по обоим именам и открыть контракт получателя с помощью read_file, затем перечислить, какой из них отсутствует. Далее попросите его использовать edit_file для значения uri(id), чтобы оно содержало {id}, который клиенты заменяют на идентификатор токена в нижнем регистре шестнадцатеричного формата, дополненный до 64 символов. Используйте write_file для одного файла JSON на каждый идентификатор. Запустите команду компиляции и команду тестов, прочитайте оба кода выхода и просмотрите финальный diff, прежде чем принять его.
