绝区零文本驱动配队
先读取 references/analysis-rules.md。把数据库和当前游戏文本视为证据，不凭印象补机制。
工作流
-
确认角色池与硬约束。
- 默认忽略等级，除非用户明确要求考虑。
- 区分“同一次出战的两队不复用”和“所有属性预设永久不复用”。不要擅自采用更严格解释。
- 未拥有、计划抽取和已经拥有的角色分开处理。计划抽取角色只能进入假设方案。
- 用户定义优先：强攻、异常、命破属于C位；支援、防护、击破属于辅助。辅C仍必须从C位角色中选择。 -
取得权威文本。
- 优先访问https://zzz.nanoka.cc/的当前数据库；先确认站点版本/更新时间，再读取角色的属性、阵营、定位、核心被动、额外能力、额外能力触发条件和关键技能文本。站点可访问时，不要默认使用旧本地数据库替代它。
- 用户提供的当前游戏截图或逐字文本优先用于覆盖数值冲突；将其标记为“用户当前版本文本”。
- 使用本地客户端和项目中的 Nanoka 快照做交叉核验，尤其检查角色文本版本、数值和新增角色。记录来源与版本，不把本地3.1快照冒充当前版本。
- 数据版本不一致时明确指出差异：当前游戏文本 > Nanoka当前数据库 > 版本匹配本地快照 > 旧本地数据 > 第三方攻略。
- 对每名候选角色提取：属性、阵营、定位、核心被动、额外能力、额外能力触发条件、关键普通技能。 -
先验证，再配队。
- 核心被动是角色自身机制，通常不需要队友“激活”；判断队友能否提供其需要的条件或窗口。
- 逐人验证额外能力由哪名队友触发。三人必须全部成立才可进入正式方案。
- 写清谁提供条件、谁承接增益、何时入场兑现，不能只罗列乘区。
- 同属性或被动亮起只代表门槛成立，不自动等于协同闭环。 -
构造队伍。
- 单核：1主C+2辅助。
- 双核：1主C+1辅C+1辅助，或2辅C+1辅助。
- 异常队优先使用两种不同属性异常C加一名异常/失衡辅助；说明异常施加顺序、异放/紊乱时点及换人时机。
- 三异常C只有在站场不冲突且用户允许无辅助时才列为正式队。 -
做冲突和完整性审计。
- 检查队伍内三人额外能力全开。
- 检查同时出战的队伍无角色重复。
- 检查每个属性对策确有对应输出或机制，而不只是辅助角色的属性相符。
- 单独审计编队槽位顺序：把技能文本中的“下一位/上一位角色”映射到实际队伍循环，写明首发位、快速支援承接位和连携技选择位；不能把成员组合顺序直接当作出场顺序。
- 检查未入选角色：至少说明是被谁覆盖、在哪种敌人/机制下可替换，不能把“主推名单”冒充“完整角色池分析”。 -
比较强度。
- 没有敌人参数、装备和操作时间轴时，只比较“对应弱点下的机制上限”，不要声称精确DPS。
- 列出增益的承接者和适用招式。例如“100%暴击伤害”要说明是艾莲本人指定招式承接，不得写成全队增益。
- 区分短失衡爆发、长线持续输出、异常双弱点和多目标环境。
输出格式
先给结论表，再给逐队证据：
| 队伍 | 主C/辅C/辅助 | 三人额外能力触发 | 条件提供者 | 增益承接者 | 循环 |
|---|---|---|---|---|---|
每队随后按以下顺序说明：
- 三人核心被动与额外能力关键原文。
- 每项额外能力由谁触发。
- 条件供给链和承接者。
- 实战时间轴：谁先站场、何时切人、失衡/异常后谁入场。
- 槽位顺序：列出1→2→3的实际编队，并注明方向性快速支援的触发者与承接者；没有方向性技能的队伍也要说明该顺序只是首发/操作便利，不是强制机制。
- 适用BOSS弱点和不适用场景。
最后追加：
- 角色重复检查。
- 未入选角色及可替换条件。
- 数据版本和结论置信度。
禁止事项
- 不根据等级淘汰角色，除非用户授权。
- 不把计划抽取角色当成已拥有。
- 不把击破角色列为辅C，除非其实际定位是命破或用户另行定义。
- 不把“感电条可以继续积累”误写成同属性会触发紊乱；紊乱需要不同属性异常覆盖。
- 不把异常伤害默认视为能暴击；只有技能原文明确的特殊伤害例外。
- 不凭角色标签假装形成飞轮。必须展示原文推导痕迹。
