预设

召唤预设

跨版本召唤预设清单

跨版本召唤预设清单如今已是完整的 Summon 工作流程，不再只是套模板的命令说明。在你把一条召唤命令对外宣称为跨版本可用之前，先用这个预设。Java 的召唤输出可能包含 NBT、属性、装备和乘客，而基岩版并不会以同样的形式解析它们，因此这份清单的作用就是把这些差异始终摆在台面上。本文把设置字段、输出审阅、Project 归位和结果截图整合到一起，让命令在成为地图设置、事件触发器或可复用 Command Pack 的一部分之前就能被检视清楚。Summon Workbench 作为 Java 侧的事实来源，而 Project 则记录哪些部分需要在基岩版重新搭建。这样能避免作者把一次成功的 Java 预览误当成基岩版兼容性的证据。

阅读语言ENRUDEESPT中文日本語VIFR한국어IDPLTR

预设结果

一份把 Java 的 NBT 能力与基岩版重建工作清晰区分的召唤审阅清单。

输出

跨版本召唤复核单

Summon cross-edition review
- Java NBT: custom names, attributes, equipment, passengers.
- Bedrock rebuild: supported entity id, supported events/components, separate ride or equipment workflow.
- Save variants separately and test both editions.

预设截图

从用于定义预设状态的 Summon 控件开始。
第二张截图突出展示了那些会改变面向玩家行为的设置或配套命令。
输出截图在最终命令或命令组进入 Project 之前让它们保持可见。

构建预设

  1. 打开代表目标生物的 Java Summon 预设。
  2. 逐项列出仅 Java 才有的功能：NBT、装备、属性、标签和乘客。
  3. 判断基岩版可以用受支持的命令重建哪些部分。
  4. 为该重建创建独立的基岩版 Project 条目。
  5. 把不被支持的功能记录下来，而不是默默地忽略掉。
  6. 对两个版本的变体分别独立测试。

为什么这个 Summon 预设属于 Project

在你把一条召唤命令对外宣称为跨版本可用之前，先用这个预设。Java 的召唤输出可能包含 NBT、属性、装备和乘客，而基岩版并不会以同样的形式解析它们，因此这份清单的作用就是把这些差异始终摆在台面上。

Summon Workbench 作为 Java 侧的事实来源，而 Project 则记录哪些部分需要在基岩版重新搭建。这样能避免作者把一次成功的 Java 预览误当成基岩版兼容性的证据。复制出去的命令只有在周围的假设都可见时才有用：选择器范围、世界状态、命令包内部的执行顺序，以及将要粘贴进 Minecraft 的精确输出。把这个预设视作一个检查点，让这些细节在命令离开 NBTForge 之前都能被审阅。

图集就是围绕这种复核思路构建的。第一张截图展示 Workbench 状态，第二张截图点出改变面向玩家行为的字段或配套模块，输出截图则让命令或命令组保持可见。当预设有可见的实际效果时，游戏内的截图会在还原好的测试世界里再次确认同一思路，而不是依赖通用的占位画面。

测试与范围把控

如果一条召唤命令仅依赖 Java 的 NBT，就不要把它标注为基岩版安全。请单独重建最接近的基岩版行为，并把任何缺失的功能记录下来。

用收窄的选择器和干净的世界状态跑第一轮冒烟测试。环境、工具、路由和反馈类命令看起来无害，但它们往往会影响每一名玩家或整个世界。先确认命令只会改变预期中的那部分状态，然后再把准确的输出连同设置行或解释其存在原因的说明行一起保存。

如果命令将成为函数文件或命令方块链条的一部分，请测试复制出来的成品，而不仅是 Workbench 的实时状态。这样才能发现陈旧的选择器、错误的命令顺序、缺失的设置行，以及那些只是因为前一次测试残留状态才显得有效的效果。

  • 在整包审阅完成之前，始终把选择器范围保持得很窄。
  • 把世界设置类命令放在战斗或事件专用的覆盖命令之前。
  • 把反馈命令保存在触发它们的状态变更旁边。

下一步去哪里

在把乘客、Boss 或自定义生物预设转写成跨版本文章之前，请用这份清单核对一遍。

相关的检查可以对照 基岩版安全预设工作流程 与 面向 Java 乘客的基岩版坐骑预设。

FAQ

可以直接把这条 Summon 命令粘贴到聊天里吗？

如果选择器足够安全、命令也不长，做单条命令的冒烟测试通常没问题。若是要可重复使用的成熟行为，请把它存进 Project 并复制有序的命令包或函数风格的输出。

为什么这个图集里只有界面截图？

这个预设产出的是 JSON、Project 组织方式或审阅工作流程，而不是世界里可见的实际物体。有用的证据是 Workbench 状态、输出和它在 Project 中的位置。

分享这个预设之前应该检查些什么？

检查选择器范围、命令顺序、目标版本，以及该命令到底属于设置、遭遇逻辑、反馈还是清理阶段。这些分类决定了它在 Project 命令包中的位置。

打开这个工作流

从相关 Summon 工作台开始，然后按你的世界调整预设字段。