nft-standards

nft-standards skill 概览

nft-standards skill 能做什么

nft-standards skill 用于帮助智能体围绕 ERC-721 和 ERC-1155 设计并实现 NFT 合约及相关产品逻辑，重点覆盖 metadata、minting 模式、royalties、marketplace 行为、soulbound 变体以及 dynamic NFT。它最适合在你需要的是 NFT 功能的代码结构与方案决策指导，而不只是临时要一段 Solidity 示例时使用。

谁适合使用 nft-standards

这个 nft-standards skill 特别适合：

• 在 ERC-721 和 ERC-1155 之间做取舍的 Web3 开发者
• 准备发布 NFT 系列或游戏资产的团队
• 需要处理 metadata 和 transfers 的 marketplace 构建者
• 要加入 royalties、reveal 机制或 non-transferable token 的产品工程师

如果你的需求是“帮我按我的业务场景把 NFT 正确实现出来”，那么这个 skill 会比通用的 smart-contract 提示词更贴近实际任务。

真实要解决的工作问题

大多数用户真正关心的，通常不是标准名称本身，而是这些落地决策：

• 哪种 NFT 标准更适合我的产品？
• metadata 应该如何存储和暴露？
• 我需要哪些 mint 限制和定价校验？
• royalties 和 marketplace 预期会怎样影响合约设计？
• 什么情况下该使用 soulbound 或 dynamic NFT 模式？

nft-standards 页面真正有价值的地方，在于它会用实现层面的语言来框定这些选择。

这个 skill 和通用提示词有什么不同

这个 skill 的原始内容只聚焦 Web3 里的 NFT 标准，因此相比“给我写一个 NFT 合约”这种泛化请求，它能给模型更清晰的默认判断框架。它覆盖：

• 面向唯一资产的 ERC-721
• 面向多 token 或 semi-fungible 系统的 ERC-1155
• metadata 模式
• royalties 与更高级的 NFT 行为

这种聚焦能显著减少提示词跑偏，尤其是在你希望智能体先判断该选哪种标准、再开始写代码的时候。

安装前你需要知道的限制

这是一个纯内容型 skill：仓库路径里只有 SKILL.md，没有 helper scripts、tests、reference docs，也没有 decision tables。这意味着 nft-standards install 很轻量，但输出质量会非常依赖你给出的 prompt。更准确地说，它应当被视为“带方向的实现上下文”，而不是完整的 audited framework 或可直接上生产的合约套件。

如何使用 nft-standards skill

nft-standards 的安装方式

从上级仓库安装这个 skill：

npx skills add https://github.com/wshobson/agents --skill nft-standards

由于该 skill 位于 plugins/blockchain-web3/skills/nft-standards，所以 skill 自身内部不需要额外的 package setup。安装后，只要你的请求明确涉及 NFT standards，智能体就可以调用这部分领域上下文。

先看这个文件

优先阅读：

• SKILL.md

这个 skill 文件夹里没有额外的 README.md、rules/、resources/ 或 helper files，所以几乎所有有价值的指导都集中在这一个文件里。这也让评估成本很低：你可以很快通读完整个 skill，再判断它是否适合你的技术栈。

nft-standards 最适合的使用场景

当你希望智能体完成以下任务时，适合使用 nft-standards usage：

• 在 ERC-721 和 ERC-1155 之间做选择
• 搭建带 minting 约束的 NFT 合约骨架
• 定义 metadata 字段和 token URI 策略
• 加入 royalty 支持与更符合 marketplace 预期的行为
• 提出 dynamic NFT 或 soulbound 的改造方案

它尤其适合用于架构初期和第一版实现阶段，因为 NFT 标准一旦选错，后续回退成本通常很高。

这个 skill 需要哪些输入，效果才会更好

如果你能提供以下信息，这个 skill 的表现会明显更好：

• 如果已经确定标准，就直接给出目标标准；如果还没定，就说明业务模型
• 所在 chain 或 EVM 环境
• metadata 是 on-chain、IPFS 还是中心化托管
• mint 模式：public mint、allowlist、lazy mint、admin mint
• transfer 策略：可转让、受限转让，还是 soulbound
• 供应规则，以及 per-wallet / per-tx 限制
• royalty 预期
• marketplace 兼容性要求
• token 是唯一资产、edition，还是游戏 inventory item

如果缺少这些信息，模型通常会退回到常见示例，而不是按你的真实约束来设计。

把模糊目标改写成高质量 prompt

弱 prompt：

Build me an NFT contract.

更强的 nft-standards guide prompt：

Use the nft-standards skill to recommend ERC-721 or ERC-1155 for a game with unique character NFTs and stackable item NFTs. We need IPFS metadata, OpenSea-compatible metadata, creator royalties, admin minting for rewards, and a soulbound achievement badge. Explain the standard split, then generate Solidity contracts using OpenZeppelin and list security and marketplace tradeoffs.

为什么这个版本更好：

• 它给出了产品形态
• 它要求先做标准决策，而不只是直接写代码
• 它明确了 metadata 和 marketplace 约束
• 它暴露了混合资产类型，这往往意味着需要多个合约

用于合约生成的 prompt 结构

一个可靠的写法是：

1. 描述资产模型
2. 说明 transferability 规则
3. 定义 metadata 存放位置
4. 说明 mint 权限与限制
5. 指出外部兼容性需求
6. 要求输出代码，并附带理由说明

示例：

Use nft-standards for Web3 contract design. Build an ERC-1155 for in-game items with fungible and semi-fungible token IDs, URI substitution metadata, batch minting, operator approvals, and royalties. Include admin-only mint, pause controls, and a short explanation of why ERC-1155 is better than ERC-721 here.

如何在 ERC-721 和 ERC-1155 之间做选择

这通常是这个 skill 最有价值的使用点。

以下情况更适合 ERC-721：

• 每个 token 都具有明确的唯一性
• collection 身份感很重要
• 优先考虑 marketplace 和钱包对 1/1 资产的展示体验

以下情况更适合 ERC-1155：

• 你需要在一个合约里承载多种 token 类型
• batch transfer 或 batch mint 很重要
• 某些物品是 semi-fungible 或按 supply 管理
• 在多类资产场景下，gas efficiency 很重要

建议让 skill 从 inventory model、metadata 结构和 transfer 行为这几个角度，把选择理由讲清楚。

面向 Web3 的 nft-standards 实际工作流

一个比较好的流程是：

1. 先让 skill 判断你的 NFT 模型属于哪一类
2. 再让它给出推荐标准和合约形态
3. 检查 minting、metadata 和 transfer 的前提假设
4. 追问生产级加固还缺哪些环节
5. 最后再在你的 repo 里生成或重构代码

这比一上来就要最终代码更稳妥，因为 NFT 项目翻车，更多时候不是语法问题，而是需求和设计不匹配。

如何检查输出是否靠谱

当智能体使用 nft-standards 后，建议确认返回内容是否覆盖了：

• 选用的标准，以及为什么这么选
• metadata URI 设计
• mint 权限与 supply cap
• royalty 机制
• marketplace 兼容性假设
• transfer 限制是否会破坏标准预期
• reveal、metadata freezing、状态演进等边界情况

如果这些内容缺失，说明输出还是偏泛，不够贴合真实实现。

常见采用障碍

主要障碍通常不是安装本身，而是实现需求不够明确：

• 没有说清 ERC-721 和 ERC-1155 的区别
• 缺少 metadata 策略
• 误以为 royalties 在所有链上场景都能 on-chain 强制执行
• 要求 soulbound 行为，却没考虑生态兼容性
• 在一份模糊需求里混合唯一资产和可堆叠资产模型

只有当你提前把这些产品决策讲清楚时，这个 skill 才最能发挥作用。

nft-standards skill 常见问题

nft-standards 适合新手吗？

适合，但前提是你已经理解基本的 Solidity 和 token 概念。nft-standards skill 能提供很有用的实现方向，但它不是从零开始的 smart contract、deployment 或 security auditing 教程。

什么情况下不该用 nft-standards？

如果你的任务主要是以下内容，就不建议优先使用 nft-standards：

• fungible token 的 token economics
• 不涉及合约设计的钱包集成
• 只做 marketplace backend indexing
• 法务 / 合规建议
• 生产级安全审查或 audit signoff

它最擅长的是 NFT 合约和 metadata 设计，而不是覆盖整个发售生命周期。

nft-standards 能替代 OpenZeppelin 文档吗？

不能。它更适合作为补充。你可以先用这个 skill 梳理解法，生成贴合场景的实现方案，然后再去对照官方库文档确认 inheritance 选择、hooks 和 extension 行为。

nft-standards 能处理 soulbound NFTs 吗？

可以。原始 skill 明确包含 soulbound 用例。不过你仍然应该要求智能体说明：阻止 transfer 会怎样影响钱包支持、marketplace 假设和用户预期，因为“non-transferable NFT”的实现方式并不只有一种。

仅靠 nft-standards 就够做 marketplace 集成吗？

它能帮助你做更符合 marketplace 预期的设计，尤其是在 metadata 和 royalty 相关要求上，但它不能保证自动兼容所有 marketplace。你仍然需要在目标平台上测试 metadata 渲染、royalty 处理、approvals 和 indexing 行为。

如果我只需要一个简单的 collection contract 呢？

这个 skill 仍然有帮助，但 prompt 要收窄。如果你只需要一个标准的 fixed-supply collection，就明确写出来。否则智能体可能会加入你并不需要的可选特性，比如 royalties 或更复杂的 metadata 模式。

如何改进 nft-standards skill 的使用效果

给 nft-standards 更完整的产品上下文

想提升 nft-standards 输出质量，最快的方法不是只说合约类型，而是把资产系统讲清楚。比如：

• “10,000 个唯一头像 NFT，带 reveal metadata”
• “游戏道具，包含可堆叠消耗品和唯一皮肤”
• “不可转让的完成徽章”

这种粒度的上下文，能带来更准确的标准选择，也能减少无关功能被一并加进去。

尽早明确 metadata 规则

很多质量不高的输出，根源都在 metadata 指令太弱。你应该明确告诉这个 skill：

• metadata 是 immutable 还是可更新
• URI 是按每个 token 单独设置，还是模板化生成
• 图片和属性放在 IPFS 还是其他位置
• 是否需要 reveal 或 evolution

这些信息会直接改变存储设计和合约对外暴露的接口面。

不要只要代码，也要让它讲清 tradeoff

更强的 prompt 可以这样写：

Use nft-standards to propose two designs, compare ERC-721 and ERC-1155, then recommend one.

这样做能让模型在正式落到实现前，先把隐藏决策摊开讲清楚。对 mixed collections、gaming assets 和 dynamic NFTs 尤其有帮助。

留意 nft-standards 常见失败模式

典型的低质量输出包括：

• 明明更适合 batch-heavy ERC-1155，却用了 ERC-721
• 忽略 metadata 托管前提
• 把 royalties 当成在所有场景都能强制执行
• 加了 enumerable extensions，却不讨论 gas tradeoff
• 实现了 soulbound 限制，却不提醒生态兼容性问题

如果你看到这些情况，应该要求它基于明确约束和 tradeoff 讨论重新设计。

第一稿之后主动要求迭代

拿到第一版回答后，用一个有针对性的 follow-up 往往就能显著提升结果：

• “Optimize for gas over convenience.”
• “Keep marketplace compatibility high.”
• “Remove all optional features not needed for launch.”
• “Separate unique and semi-fungible assets into different contracts.”
• “Explain security risks around minting and metadata updates.”

这种方式通常比从头重写 prompt 更有效。

用 repo 内部约束提升 nft-standards 的可落地性

如果你希望输出的代码可以真正合并进项目，请一并提供：

• Solidity version
• OpenZeppelin version
• 偏好 upgradeable 还是 non-upgradeable
• 现有 access control model
• testing framework
• deployment environment

nft-standards skill 本身没有内置的 repo awareness，所以这些约束必须由你主动提供。

把 nft-standards 当作决策层来用

nft-standards 最好的用法，往往是在写代码之前：先让它验证 asset model、metadata 方案和 transfer logic 是否成立。等这些关键决策稳定之后，再用第二个 prompt 去生成可落地实现的代码。相比一开始就要求输出完整 NFT 合约，这种两步法在 Web3 场景里几乎总能得到更好的结果。