实体预设
最大生命值属性预设
最大生命值属性预设如今是一整套完整的 Attribute 工作流程，而不再是一段模板化的命令注释。当 Boss、守卫或耐打的自定义生物需要比召唤默认值更高的生命值时，请使用这个预设。把生命值作为独立的 attribute 命令处理，可以让平衡更新更轻松，因为创作者无需重写装备或乘客 NBT 也能调整耐打程度。本文把设置字段、输出审查、Project 归位以及结果截图整合在一起，让命令在成为地图设置、事件触发器或可复用 Command Pack 的一部分之前，容易被审计。Attribute 工作台会让目标选择器、属性 ID、操作和数值与输出并排展示。配套的数据合并很重要，因为只把最大生命值调高、却不同步当前生命值，可能会让实体仍然存活，却没有真正补满到新的上限。
预设结果
被打了标签的 Boss 会同时获得更高的最大生命值和匹配的当前生命值。
输出
最大生命值属性命令
/attribute @e[tag=arena_boss,limit=1] minecraft:max_health base set 80
/data merge entity @e[tag=arena_boss,limit=1] {Health:80f}预设截图
构建预设
- 打开 Attribute 工作台。
- 把目标设为打了标签的 Boss 实体。
- 把属性设为 `minecraft:max_health`。
- 使用 base set 操作，把数值设为 `80` 等具体数字。
- 当 Boss 应当满血开战时，追加一次将当前生命值同步上去的数据合并。
- 把属性命令和生命值同步行一起保存到 Project。
- 在调整平衡的伤害之前，先在打了标签的测试实体上把这两条命令都跑一遍。
为什么这个属性预设应进入 Project
当 Boss、守卫或耐打的自定义生物需要比召唤默认值更高的生命值时，请使用这个预设。把生命值作为独立的 attribute 命令处理，可以让平衡更新更轻松，因为创作者无需重写装备或乘客 NBT 也能调整耐打程度。
Attribute 工作台会让目标选择器、属性 ID、操作和数值与输出并排展示。配套的数据合并很重要，因为只把最大生命值调高、却不同步当前生命值，可能会让实体仍然存活，却没有真正补满到新的上限。复制出来的命令只有在周围假设可见时才有用：选择器范围、世界状态、包内顺序，以及将要粘贴进 Minecraft 的确切输出。把这个预设当作检查点，让这些细节在命令离开 NBTForge 之前接受审查。
整组截图就是围绕这种审查思路而设计的。第一张展示工作台状态，第二张点出改变面向玩家行为的字段或配套模块，输出截图保留最终命令或命令对。当预设有可见结果时，游戏内截图会在恢复的测试世界中确认同一个结论，而不是靠通用素材敷衍了事。
测试与范围审查
当实体应该满血开战时，请务必在调高 max_health 之后再设置当前生命值。否则上限确实变了，但 Boss 可能仍以旧的当前血量进入战斗。
用窄选择器和干净的世界状态做第一次冒烟测试。环境、实用、路由和反馈类命令看起来无害，但它们往往会影响每一位玩家或整张世界。先确认命令只改变预期的状态，再把确切的输出和设置行或解释行一起保存。
如果命令将进入函数文件或命令方块链，请测试复制出来的成品，而不仅是当前工作台状态。这样才能抓出过期的选择器、错误的命令顺序、漏掉的设置行，以及那些只因前一次测试残留状态而显得有效的效果。
- 在完整审过整个包之前，始终把选择器范围收窄。
- 把世界级设置放在战斗专用覆盖之前。
- 把反馈命令紧挨着触发它们的状态变化保存。
接下来用在哪里
把它保存在 Boss 召唤之后、阶段效果、bossbar 设置或伤害测试之前。
如需相邻的数值调参方案，可对比移动速度属性预设与自定义怪物缩放属性预设。
FAQ
我可以直接把这条 attribute 命令粘进聊天框吗？
如果选择器安全、命令行不长，做一次性冒烟测试通常没问题。但若要复用为地图行为，请把它保存到 Project，并复制有序的包或函数式输出。
为什么实用类预设也要附上结果截图？
结果截图能证明命令真的在 Minecraft 中改变了可见世界、HUD、路由或反馈状态，而不仅仅是在输出面板里看起来对。
在分享这个预设之前，我应该核对哪些内容？
核对选择器范围、命令顺序、目标版本，以及这条命令到底属于设置、战斗逻辑、反馈还是清理。这些分类决定了它在 Project 包中的位置。
打开这个工作流
从相关 Attributes 工作台开始，然后按你的世界调整预设字段。