Bạn muốn một hợp đồng duy nhất phát hành kiếm, thuốc và chìa khóa, mỗi loại có token id riêng, và bạn muốn biết ai được phép tạo token mới. Agent sẽ viết mã Solidity, chạy lệnh biên dịch và kiểm tra trên chuỗi cục bộ hoặc mạng thử nghiệm, đồng thời hiển thị từng bước dưới dạng thẻ với kết quả thực tế. Hướng dẫn này tập trung vào hàm đúc token, vì người có thể gọi hàm này quyết định số lượng token tồn tại. Một hợp đồng đã triển khai không thể thay đổi, vì vậy mọi thứ ở đây đều diễn ra trên chuỗi cục bộ hoặc mạng thử nghiệm, nơi các đồng tiền không có giá trị. Người mới có thể làm theo bốn bước theo thứ tự, còn người đọc có kinh nghiệm có thể nhảy đến các hướng dẫn chi tiết ở phía dưới. Bốn bước tương tự cũng áp dụng cho bộ vé, nơi mỗi loại vé có id riêng và hàm đúc token quyết định số lượng của mỗi loại.
Khởi động WaveClamp, chọn thư mục chứa các tệp .sol và bài kiểm tra làm thư mục làm việc của cuộc trò chuyện, và chọn Ask first để mọi thay đổi đều xuất hiện dưới dạng diff mà bạn có thể chấp nhận hoặc từ chối. Các công cụ tệp hoạt động trong thư mục đó, vì vậy hãy giữ dự án ở một nơi. Tạo một thư mục tạm thời cho lần chạy đầu tiên nếu bạn chỉ muốn thực hành.
Yêu cầu tạo một hợp đồng vật phẩm game với ba loại vật phẩm, một hàm đúc token chỉ một tài khoản chủ sở hữu mới có thể gọi, và chức năng chuyển hàng loạt, sau đó để agent tạo tệp bằng write_file. Đặt tên tệp theo tên hợp đồng để các bước sau có thể tham chiếu đến nó. Hãy giữ yêu cầu đầu tiên ngắn gọn, vì yêu cầu thứ hai có thể thêm chức năng chuyển hàng loạt sau khi diff đầu tiên được chấp nhận.
Bảo agent chạy lệnh biên dịch và lệnh kiểm tra của bạn thông qua Shell, sau đó đọc mã thoát và tên của bất kỳ bài kiểm tra nào thất bại trên thẻ mở rộng. Thành công được đánh giá dựa trên mã thoát thực tế, không phải qua tóm tắt. Nếu lệnh biên dịch thất bại, thẻ sẽ hiển thị văn bản lỗi, và agent có thể đọc nó và đề xuất bản sửa lỗi dưới dạng diff mới.
Mở các thẻ mở rộng, đọc diff và kết quả lệnh, chấp nhận những gì đúng, từ chối những phần khác, và yêu cầu sửa lỗi ở bất kỳ đâu bài kiểm tra vẫn thất bại. Lặp lại cho đến khi các bài kiểm tra thành công, sau đó đọc lại hàm đúc token một lần nữa. Hãy giữ mỗi diff được chấp nhận nhỏ gọn, để một lỗi sau này chỉ trỏ vào một thay đổi chứ không phải mười thay đổi.
MultiTokenMinimal.solđã lưuMultiTokenMinimal.sol14 dòngbalanceOf1 khớpyour 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);
}Giao diện chỉ đọc này khai báo sự kiện TransferSingle và các hàm balanceOf và uri của tiêu chuẩn multi-token. Nó không chứa trạng thái, logic đúc token hay khóa nào, khiến nó trở thành một tệp nhỏ để đọc trước khi bạn thêm logic thực sự. Hãy chạy lệnh biên dịch trên nó trước. Biên dịch nó trước, sau đó để agent mở rộng nó từng diff đã được xem xét một lần, bắt đầu với hàm đúc token. Tên tệp khớp với nhãn ví dụ, để bạn có thể yêu cầu agent mở nó sau này.
Mở hợp đồng và yêu cầu agent bao bọc hàm trợ giúp ERC1155 _mint trong một hàm public chỉ tài khoản chủ sở hữu mới có thể gọi. Agent sử dụng read_file để xem mã hiện tại và edit_file để chèn hàm, đồng thời hiển thị thay đổi dưới dạng diff. Các triển khai mã nguồn mở phổ biến thường expose các hàm trợ giúp nội bộ có tên là _mint và _mintBatch, và một hàm trợ giúp nội bộ không có kiểm soát truy cập riêng, đó là lý do tại sao lớp bao bọc lại quan trọng. Bạn có thể tạo token ERC20 từng bước bằng phương pháp tương tự, nhưng một bộ vật phẩm game cần id, vì vậy hãy bắt đầu từ bố cục multi-token. Sau đó, Shell sẽ chạy lệnh biên dịch và lệnh kiểm tra của bạn, và mỗi thẻ sẽ hiển thị mã thoát thực tế. Chỉ chấp nhận diff khi bạn đã đọc qua các bài kiểm tra.
Mở ví dụ hợp đồng ERC721 từ dự án của riêng bạn, hoặc yêu cầu agent viết một ví dụ với write_file và đặt nó bên cạnh bộ vật phẩm của bạn. Agent sử dụng grep để liệt kê các hàm trong cả hai tệp và read_file để so sánh cách lưu trữ quyền sở hữu: một chủ sở hữu cho mỗi token trong tệp token đơn lẻ, và số dư cho mỗi tài khoản và id trong tệp multi-token. Một tiêu chuẩn cho hồ sơ phi tập trung sử dụng NFT không thể chuyển nhượng (soulbound) sẽ cần các token không thể chuyển đi, đây là một thiết kế khác với các vật phẩm mà người chơi có thể trao đổi. Hãy yêu cầu agent liệt kê các khác biệt vào một bảng ngắn. Bạn đọc phần so sánh trong cuộc trò chuyện, quyết định tiêu chuẩn nào phù hợp với thiết kế của mình, và chỉ sau đó mới yêu cầu thay đổi mã.
Người chơi thường di chuyển nhiều loại vật phẩm cùng lúc, vì vậy hãy yêu cầu agent thêm safeBatchTransferFrom và balanceOfBatch vào hợp đồng. Agent sử dụng edit_file cho thay đổi, glob để tìm các tệp kiểm tra, và Shell để chạy lệnh kiểm tra của bạn sau mỗi lần chỉnh sửa. Các hàm hàng loạt di chuyển nhiều token id trong một giao dịch, nghĩa là một bài kiểm tra có thể kiểm tra nhiều số dư. Việc hiểu cách đăng nhập không cần gas bằng ERC4337 là một chủ đề riêng biệt, vì vậy hãy giữ nó ra khỏi hợp đồng đầu tiên và kiểm tra nó riêng lẻ. Đọc diff trong chế độ Ask first, chạy lại các bài kiểm tra và tìm sự kiện TransferBatch trong kết quả trước khi chấp nhận thay đổi.
Một hợp đồng nhận token phải triển khai onERC1155Received và onERC1155BatchReceived và chấp nhận các token, nếu không việc chuyển an toàn sẽ bị từ chối. Hãy yêu cầu agent grep tìm cả hai tên và mở hợp đồng nhận bằng read_file, sau đó liệt kê xem tên nào bị thiếu. Tiếp theo, yêu cầu nó sử dụng edit_file trên giá trị uri(id) để nó chứa {id}, điều này các khách hàng sẽ thay thế bằng token id ở chữ thường dạng thập lục phân, được đệm đủ 64 ký tự. Sử dụng write_file cho một tệp JSON cho mỗi id. Chạy lệnh biên dịch và lệnh kiểm tra của bạn, đọc cả hai mã thoát và xem xét diff cuối cùng trước khi chấp nhận nó.
