适用范围与设计起点
这里讨论的是以 NFT 表示独立身份的模型或游戏道具，重点在链上身份与权限设计，不涉及三维建模工艺。设计时应先说明道具代表什么、谁能持有，以及持有后在应用中能做什么，避免把代币存在直接等同于完整的道具功能。
以太坊开发者文档介绍的 ERC-721 提供独立代币的标识、持有人查询、转移和授权接口。它适合表达需要分别识别的道具；模型如何展示、技能如何生效，仍需应用定义。
唯一身份与外观如何关联
在同一条链上，识别道具需要结合合约地址和 tokenId。不同合约可以出现相同的 tokenId，因此道具目录仅保存编号容易混淆对象；涉及多条链时，还需明确所属网络。
唯一身份也不意味着外观必然不同。两个独立道具可以使用相同模型，应用也可以根据编号生成不同展示。设计说明应交代编号与展示内容的对应方式，以及外观变化是否影响道具身份，避免把视觉差异当成身份判断依据。
持有、授权与管理需要分开
道具持有人、获准转移道具的账户和合约管理员承担不同职责。界面与规则应分别说明这些权限，尤其要区分单件道具授权和面向操作方的全部道具授权，不能用含糊的“允许使用”概括转移权限。
OpenZeppelin 的访问控制文档区分单一所有者管理与按角色管理，并强调最小权限原则。创建道具、销毁道具等能力可以分配给不同角色；角色管理员还可能具有授予和撤销权限的能力。
因此，设计评审既要检查谁能直接执行操作，也要检查谁能给自己或他人增加权限。道具持有关系不能代替这张管理权限关系图。
规则变化与权限交接
若道具允许后续创建、属性调整或其他管理操作，应逐项说明执行者、适用条件和权限撤销后的行为。角色拆分是否有效，取决于实际权限配置；仅使用角色名称不能证明权限已经隔离。
管理权交接需要考虑接收账户能否正常接管。两步接管机制要求新管理者确认，有助于降低错误交接风险；放弃管理权则可能使受该权限保护的功能无法继续调用，需提前明确影响。
常见问题与验收重点
使用 ERC-721 是否就能让模型在不同应用中直接使用？标准接口有助于统一识别和转移，但模型展示与玩法适配仍需各应用实现。
如何确认权限设计符合预期？可围绕未授权操作是否被拒绝、权限撤销后是否失效、授权范围是否清楚、道具转移后持有人查询是否一致进行验证。验收应覆盖权限变化后的行为，而不只验证正常操作能够成功。