装备状态升级可视化

适用目标

让观众看出“仍是同一件装备，哪些功能发生了变化，何时能用、用完怎样恢复”。用于装备基础形态、升级态、激活态和受击反馈设计；不以堆光效或扩大尺寸代替功能说明，也不替游戏新增攻击方式、资源机制或升级条件。

输入

读取装备基础参考、名称和版本、轮廓识别点、持握/佩戴方式、尺度与材质、已确认升级规则、各状态触发和结束条件、可重复使用次数、镜头/资产用途。只有影响身份、规则或交付规格的缺项需要澄清；其余保留待核实。图片能证明看见的外观，不能独自证明能力、持续时间或判定范围。

先建状态字典，把容易混淆的三种变化分开：

• 永久升级：条件达成后保留的结构或能力变化；是否可回退依据设定。
• 临时激活：在条件满足期间出现的状态，需写结束或消耗后状态。
• 瞬时反馈：一次接触/触发的短暂表现，不自动意味着装备已升级或持续激活。
  耐久受损、皮肤外观和升级也应分别命名，不能把裂纹默认解释为升级。

执行流程

1. 锁身份与空间关系：确定主体轮廓、关键结构、标志图案、握点/系带、大小相对人体的位置。镜位变化时仍应能辨认同一装备。对照表写清哪些绝对保留、哪些允许变化；不得让升级后握柄换侧、手穿盾面或佩戴点消失。
2. 每项能力变化仅匹配必要的视觉变化。能反弹一次可考虑一个可读的准备标记和消耗反馈，但标记数量不等于真实次数，须与已知规则一致；不能自动增设光弹发射口或多层攻击结构。
3. 定义状态进入、持续、退出：触发是什么，可见事件是什么，结束后保留什么、消失什么。永久结构不应在镜头后自行恢复；临时发光不应无缘由延续到未激活镜头。
4. 用相同可比条件展示差异。基础态与升级态尽量保持朝向、尺度、光照和握持，先确认识别与功能差异，再增加戏剧镜头。若用户指定不同姿势，就额外说明哪些变化来自角度，哪些来自装备。
5. 每个需要独立生成、复用或分镜引用的形态用“## 对象名｜具体形态”单独写完整描述。包含轮廓、结构、材质、颜色、尺度、握持、已激活部位、禁止误读项，不用“同上但更华丽”代替可执行正文。
6. 设计过渡时固定前后状态。列出变化从何处开始、沿何路径扩展、何时完成、接触点是否保持；不让镜头遮挡掩盖结构凭空换位。特效退场后检查是否回到正确状态。
7. 检查可读性与复用：缩到实际使用尺寸、去掉背景噪声后能否认出；不同等级是否只剩亮度差；关键功能是否被装饰遮挡。只有实际打开图像、播放视频或运行工具的结果可标记已检验。

输出

示例：一次反弹盾

已知：普通盾升级后可反弹一次来袭攻击，其他规则未给出。基础盾保留外轮廓、握带与持握姿态；升级后只增加与该功能相符的视觉识别。激活态说明“待触发”，接触时表现入射攻击与触发点的关系；一次反馈结束后回到规则规定的消耗后状态。反弹方向和重新充能条件未给出时，列为待核实，不自行选择自动追踪或自然恢复。

正确核查：是否让观众看见来袭、触发、次数耗尽；手与盾的空间是否连续；升级结构是否仍在。反例：没有来袭攻击就主动发射光弹；用全屏爆炸打倒周围敌人；一次反弹后继续反弹多次；仅把盾放大三倍却不表达功能变化。镜头震动可以是观看反馈，不能当成新增击退能力。

验收与最小修复

验收至少覆盖基础态、升级未激活、激活、触发瞬间、触发后五类中的实际适用状态；不存在的状态不用强行补造。每条状态需有可识别差异、合法进入/退出条件及对应来源。没有实机测试时结论限于外观或方案检查，不称引擎状态机已通过。
若失败，先修最小问题：认不出原装备就还原轮廓；无法看出次数消耗就强化规则允许的标记变化；状态串错就修首末帧与版本引用。保留已正确的角色脸、场景、风格，不整组盲目重做。用例属于计划验收，非已发生效果验证。

提示词入口

读取本包提示词 装备状态升级可视化｜任务输入 并填入当前资料与限制。风格示例服务表达目标，不覆盖用户指定文字、主体数、比例和时长；不能见到发光效果就补写规则。