全部英雄

英雄列表最适合回答具体问题：谁能启动一条 Tag 连携，谁能响应某种状态，哪些英雄使用远程攻击，或当前三人队伍缺少什么定位。已经知道名字时直接搜索；还不知道答案时，组合使用定位、攻击类型、施加状态、激活条件与 Signal 筛选。只比较能够解决同一问题的英雄。输出、连携中继与防御角色都可能很强，但三者并不是可互换的候选。当前目录收录十九名英雄，先设置一个真正影响决策的条件，观察剩余数量，再添加第二个硬性条件，通常就能得到可逐个核对的名单，也不会因为盲目叠加筛选而错过重要选择。

英雄卡片只是入口，不是强度结论。进入详情页后，应逐级查看技能文本、施加状态、激活条件、目标描述与首次解锁等级。规划 Tag 连携时，“施加浮空或击倒”与“目标处于浮空或击倒时激活”是两类不同事实；数据库把效果与条件分开，避免把要求误读成英雄能够主动施加的状态。还要确认中继英雄是否能用同一技能承接并产生下一状态，还是必须连续使用两项技能。即使文本链成立，也不能证明动画时序、能量、冷却、敌人免疫或实际伤害合适，这些随战斗变化的内容仍需在游戏中验证。

英雄投入应按相同的觉醒目标比较，而不是依据立绘边框或某个孤立的最高数值。每个详情页都会展示已发布的养成阶段、金币、材料数量以及对应材料记录。先决定下一项真正有用的里程碑，再累计从当前起点到该阶段的全部成本，避免把便宜的早期提升与完整的后期培养混在一起。如果多名英雄争用相同材料，把全部目标加入英雄升级材料工具，查看合并后的总需求与缺口。玩家填写的库存只保存在当前浏览器，可以用来扣减仍需收集的数量，但不会改变游戏数据中已经核验的原始需求。

确定英雄后，需要检查整套配置，而不是默认所有高品质记录都能装备。构筑规划器会核对五个装备部位、能力限制、套装门槛、Karma 绑定、Rune、强化目标以及使魔槽位。以英雄为起点，先加入满足公开限制的装备，再比较主属性候选与套装进度；选择 Karma 前确认它是普通记录，还是只适用于特定英雄。使魔属于独立的队伍配置，本身不会创造技能 Tag 关系。网站按英雄在浏览器中分别保存构筑，因此可以保留多名英雄的方案，并在替换装备、Karma 或使魔时比较结果，而不会无意覆盖另一名英雄的配置。

页面能够确认的是当前记录中的名字、定位、技能文本、等级、状态关系、装备数据、Karma 关系和养成成本。它不会声称某名英雄在所有场景都是最强，也不会计算每场战斗的最终伤害、预测未来平衡改动或知道玩家账号拥有什么。技能连携成立，仍可能因为操作困难、首领免疫或生存要求而不适合当前关卡。队伍目标改变时应重新筛选，在相同养成状态下比较，并在投入稀缺资源前进入游戏核对实时表现。这样的证据流程能在版本更新后直接复查发生变化的字段，而不是继续沿用已经失效的旧榜单结论。