任意物品的自定义名称与描述文本预设

当可见提示框本身就是物品的核心时，就该用上它：钥匙、遗物、奖杯、商店货品以及 NPC 奖励都适用。

文本组件控件免去了手动转义 JSON 的麻烦，同时仍能精确生成 custom_name 与 lore 组件。这恰恰是一段普通命令片段最容易隐藏的部分：面向玩家的文本、随版本变化的组件以及可直接复制的输出，必须在命令离开 Workbench 之前彼此一致。

在物品被接入更大的命令链之前，请把这个预设当成一块校验面板。确认提示框已向玩家说清楚物品的用途，确认 custom_data 或其他隐藏组件承载着真正的命令逻辑，并确认复制出来的输出仍然贴合所选的 Minecraft 版本。游戏内结果之所以特意保持简单，是因为它能直接回答第一个 QA 问题：这条命令是不是真的发放了文章所描述的那一份物品堆叠？

现代 Java 版的物品命令把许多旧教程里以 NBT 形式存在的细节都改用物品组件来表达。编辑时务必让所选版本一直可见，尤其是当物品涉及名称、描述文本 (lore)、附魔、稀有度、自定义模型数据、药水内容或不可破坏状态时。

过长的描述文本 (lore) 在物品栏里换行效果很差。请让每一行 lore 都保持简短，并把机器可读的状态改存到 custom_data 中。

命令通过校验后，请在地图或数据包将来真正运行的同一版本系列里再跑一遍。即便命令看上去复制得干干净净，只要组件不受支持、选择器命中过多玩家，或者物品文本承诺了数据并未真正强制执行的行为，它就依然存在设计漏洞。在添加计分板、战利品、商店、NPC 或重置命令之前，先把这条稳定版本保存到 Project 中。

• 在动手编辑原始命令文本之前，优先使用 Workbench 字段。
• 让显示文本足够简短，能够完整放进物品栏提示框里。
• 用 custom_data 来承载命令逻辑，而不要依赖可见名称。

在为同一件物品继续添加附魔、属性或谓词之前，先保存一份 Project 副本。

如果这件物品需要反复使用，请先把它存为 Project 条目，再围绕它去添加计分板、战利品表、NPC 或重置命令。这样在地图规模不断扩大的过程中，物品定义本身依然可以审核。

如果需要相近的提示框示例，可对比带稀有度的任务奖励物品预设、冒险地图关键物品预设和Minecraft 自定义剑制作预设。