绝区零一条龙从翻车现场到全自动挂机事件驱动状态机如何撑起这套游戏自动化框架【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址: https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon深夜两点你盯着屏幕自动战斗脚本又在 BOSS 战里卡死了角色原地发呆技能循环毫无反应一场本该 3 分钟的战斗拖成了 10 分钟最后以团灭收场。这不是个别现象而是游戏自动化领域的通病——脚本能动却不会看、不会想、不会应变。绝区零一条龙ZenlessZoneZero-OneDragon正是冲着这个问题来的。这个基于 Python 的开源游戏自动化框架用一套事件驱动状态机引擎重新定义了挂机它不只是机械地按键盘而是先看懂画面再决定下一步做什么最后才执行操作。本文将带你从它的核心设计出发看看这套框架凭什么敢说自己能全自动刷空洞、自动闪避、自动做每日——以及它为什么值得你在动手写下一个自动化脚本前先认真研究一遍。一个深夜翻车现场暴露了脚本的三个致命伤先从一个具体的翻车场景说起。假设你想写一个自动刷副本的脚本第一版通常长这样等 5 秒 → 按攻击键 → 循环。它确实能跑但只能跑 30 秒——因为游戏不会按你的剧本走画面是动态的。加载画面、结算弹窗、升级动画每个环节的节奏都不一样固定延时迟早对不上。状态是分叉的。同样点一下挑战按钮可能进入战斗、可能弹出体力不足、可能网络重连分支多得写不完。失败是不可预测的。一次闪避失误、一次技能放空都可能让流程走向完全不同的结局。传统脚本的应对方式是用if/else堆逻辑但游戏的流程复杂度远超人的枚举能力。绝区零一条龙的答案是把流程彻底数据结构化不再是一行行顺序执行的代码而是一张可以运行、可以调试、可以复用的有向节点图。这套设计正是它的核心资产我们一步步拆开看。拆开快递一条龙框架的三层世界动手看代码前先建立全局认知。项目的目录结构非常规整可以理解为三个相互独立的世界第一层通用自动化底座src/one_dragon/。这里没有一行绝区零专属代码只有与游戏无关的通用能力操作节点引擎、模板匹配器、OCR 服务、事件总线、截图与输入控制器。换个游戏这一层几乎可以原样复用。第二层业务逻辑src/zzz_od/。这里才是懂绝区零的部分。自动空洞、世界巡逻、防卫战、每日签到、咖啡店、邦布店……二十多个功能应用全部以插件形式挂载在底座上每个应用就是一个独立的包。第三层数据与配置assets/game_data/与config/。游戏的所有知识被抽离成 YAML每个界面的按钮位置、每个区域的文本、每张地图的道路掩码、每个角色的战斗策略全部外部化配置改配置就能适配新版本不用动代码。这种底座—插件—数据的分层让新功能开发变成了填配置 写节点的组装游戏而不是从零造轮子。接下来我们进入最精彩的部分节点引擎。让流程成为图状态机设计的三个关键决策一个自动化流程本质是当前处于什么状态 → 根据感知结果 → 迁移到下一个状态。绝区零一条龙把这句话翻译成了极简的代码模型全部浓缩在两个装饰器里# src/one_dragon/base/operation/operation_node.py def operation_node( name: str, timeout_seconds: float None, is_start_node: bool False, node_max_retry_times: int 3, screenshot_before_round: bool True, ): # 把节点元数据附加到函数上运行前统一收集# src/one_dragon/base/operation/operation_edge.py def node_from(from_name: str, success: bool True, status: str None, ignore_status: bool True): # 声明从哪个节点来边会在构图阶段自动补全去向用真实代码看效果。这是自动空洞迷失之地入口流程的一段src/zzz_od/application/hollow_zero/lost_void/lost_void_app.pyoperation_node(name初始化加载, is_start_nodeTrue) def init_for_lost_void(self) - OperationRoundResult: if self.run_record.is_finished_by_day: return self.round_success(LostVoidApp.STATUS_ENOUGH_TIMES) self.ctx.lost_void.init_before_run() return self.round_success(LostVoidApp.STATUS_AGAIN) node_from(from_name初始化加载, statusSTATUS_AGAIN) operation_node(name识别初始画面) def check_initial_screen(self) - OperationRoundResult: # 通过 find_and_click / OCR 判断当前在哪一屏 return self.round_success(可前往快捷手册) # 或其它状态 node_from(from_name识别初始画面, status可前往快捷手册) node_from(from_name识别初始画面, statusOperation.STATUS_SCREEN_UNKNOWN) node_from(from_name识别初始画面, status未识别初始画面) operation_node(name前往零号空洞-入口) def tp_to_lost_void(self) - OperationRoundResult: ...这个设计里有三个值得玩味的决策决策一节点即函数边即装饰器。每个节点就是类里的一个方法operation_node把节点元数据名称、超时、重试次数挂在函数上node_from则声明我这个节点从哪个节点来。运行时引擎用inspect扫描类方法自动收集节点和边组装成图——代码写出来就是流程图本身可读性拉满。决策二节点不调用下一个节点只返回状态。节点之间没有直接调用关系每个节点只管返回round_success(某个状态)或round_retry(...)至于下一步去哪由引擎根据边的匹配规则决定。这让节点高度内聚改一个节点不需要动它的所有邻居。决策三边支持状态过滤与兜底。从上面的代码能看到同一个节点可以发出多条边分别匹配不同的返回状态ignore_statusTrue的边则作为兜底在所有精确匹配都落空时兜住流程避免死锁。这是应对游戏画面千变万化的关键保险。引擎的呼吸主循环、轮次结果与边匹配图建好了谁来跑Operation.execute()是一个极其清醒的主循环src/one_dragon/base/operation/operation.pywhile True: if self.timeout_seconds ! -1 and self.operation_usage_time self.timeout_seconds: op_result self.op_fail(Operation.STATUS_TIMEOUT) # 整体超时保护 break if self.ctx.run_context.is_context_stop: op_result self.op_fail(人工结束) # 用户随时可叫停 break round_result self._execute_one_round() # 执行当前节点一轮 if round_result.result OperationRoundResultEnum.RETRY: self.node_retry_times 1 # 单节点重试计数 if self.node_retry_times self.node_max_retry_times: continue if round_result.result OperationRoundResultEnum.WAIT: continue # 等待 原地再拍一张 next_node self._get_next_node(round_result) # 按状态找下一条边 if next_node is None: # 没有后继 流程结束 break self._current_node next_node每一轮执行节点方法返回四种结果之一SUCCESS进入下一条边、FAIL走失败边或结束、RETRY本节点重试 N 次、WAIT等一帧再判断。_get_next_node则遍历当前节点的出边按success匹配 status精确匹配 ignore_status兜底的优先级选出下一个节点。这个循环还内置了三层防护值得单独强调逐节点超时与重试一个节点可以设置自己的超时秒数和最大重试次数比如示例里前往迷失之地-入口设了 20 次重试不怕偶发卡顿。整体超时与人工干预整个操作有总时长上限用户暂停、停止随时生效绝不无限挂机。游戏窗口守护构图时会自动在起始节点前插入检测游戏窗口 → 打开并进入游戏两个前置节点_add_check_game_node游戏没开先把你送进游戏再说。很多无人值守场景的翻车其实都栽在这一步——这个框架替你兜住了。一双看得见的手三级识别与配置驱动的眼睛状态机的每一步决策都依赖感知而感知靠的是三条并行的识别通道模板匹配对按钮、图标、血条这类固定 UI 元素用模板图像做匹配毫秒级出结果是高频路径的主力。OCR 识别对挑战、确认、体力不足这类动态文本用内置的 ONNX 运行时 OCR 引擎读取并带区域缓存避免重复计算。YOLO 目标检测对敌人姿态、连携条、BOSS 血线这类复杂视觉场景用目标检测模型定位。三条通道的分工耐人寻味凡是稳定的东西用模板凡是变化的东西用 OCR凡是模糊的东西用 YOLO。但真正的设计精华是把眼睛看哪里也配置化了——assets/game_data/screen_info/下每个界面一个 YAML声明各个按钮的区域坐标assets/game_data/world_patrol/lemnian_hollow/下每张地图配有道路掩码图导航时先识别小地图再对照掩码判断可走路径。这意味着游戏 UI 改版通常只需更新 YAML 与图片模板框架代码毫发无损。版本适配成本被压缩到一个不可思议的量级。让组件彼此说话事件总线与上下文状态机解决的是一个流程怎么走但一个框架里同时跑着战斗、巡逻、推送、GUI 多个子系统它们之间怎么协作绝区零一条龙的答案是**上下文Context 事件总线EventBus**的松耦合组合。上下文OneDragonContext是全局单例的服务容器截图控制器、匹配器、OCR、配置、运行记录全都挂在这里任何节点都能通过self.ctx取到。而事件总线src/one_dragon/base/operation/context_event_bus.py实现标准的发布—订阅class ContextEventBus: def dispatch_event(self, event_id: str, event_obj: Any None): if event_id not in self.callbacks: return for callback in self.callbacks[event_id]: future _od_event_bus_executor.submit(callback, ContextEventItem(event_id, event_obj)) future.add_done_callback(thread_utils.handle_future_result)注意ThreadPoolExecutor.submit——事件回调被丢进线程池异步执行发事件的人不阻塞。操作引擎靠它监听暂停/恢复GUI 靠它刷新状态异常检测靠它广播告警。组件之间不知道彼此存在只认事件 ID这正是加一个功能不动旧代码的底气所在。实战走读一次自动空洞整条链路如何协同把上面的设计串起来看一次真实的自动空洞迷失之地运行你会理解每一层在干什么入口判断识别初始画面节点截屏先用区域查找判断挑战-确认按钮再用 OCR 判断当前在哪个界面大世界/快捷手册/副本画面返回不同状态。路线分流返回可前往快捷手册就走手册传送链返回可前往副本画面就直接进副本链不同状态走不同边——这就是状态机对分叉的优雅处理。循环推进进入副本后节点在识别悬赏委托完成进度处检查每日次数够了直接STATUS_ENOUGH_TIMES收工否则继续挑战流程战斗阶段由自动战斗应用接管配合闪避检测与技能循环。异常兜底任何一个环节找不到目标节点返回RETRY重试 N 次仍失败则走失败边或由全局超时兜底退出绝不死循环。值得一提的是整套引擎自带运行轨迹可视化每个节点从哪来、返回什么状态、耗时多少毫秒都通过 overlay 调试总线实时推送。用户能在界面上看到初始化加载 → 识别初始画面 → 前往零号空洞-入口的完整流转轨迹。自动化流程不再是黑盒而是可以观察、可以回放、可以定位的透明管道——这一点对排障体验的提升怎么强调都不过分。冷静的审视它做到了什么还差什么回到开头的翻车现场。绝区零一条龙给出的解法本质上是把自动化从指令序列升级为感知—决策—执行的闭环状态机并配套了三件利器配置驱动的数据层低成本适配版本、事件总线的松耦合低成本扩展功能、轨迹可视化的调试层低成本定位问题。对于想研究游戏自动化架构、或想给自家工具套上会看图、会决策能力的开发者它是一份极好的活教材。当然它也有清醒的边界强绑定 Windows 生态控制器基于窗口句柄与模拟输入跨平台Linux/macOS需要重写控制器层。配置工作量大新界面、新玩法需要采集模板、标注区域、写道路掩码数据生产本身有成本。对画面稳定性敏感高分辨率缩放、滤镜、非默认画质都可能影响识别率需要用户保持环境一致。如果让我给改进方向提三条建议一是将模板与区域配置做可视化采集工具把写 YAML变成框选即生成二是引入强化学习做技能循环自适应让战斗策略从配置驱动升级为数据驱动三是沉淀一套通用界面状态识别抽象层让底座真正脱离绝区零成为通用的游戏自动化内核。毕竟这套框架最迷人的地方不是它自动化了哪款游戏而是它证明了把流程画成图、把感知做成数据、把协作交给事件——复杂系统的自动化可以优雅得像个艺术品。【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址: https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 绝区零一条龙：从“翻车现场“到全自动挂机，事件驱动状态机如何撑起这套游戏自动化框架？
绝区零一条龙从翻车现场到全自动挂机事件驱动状态机如何撑起这套游戏自动化框架【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址: https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon深夜两点你盯着屏幕自动战斗脚本又在 BOSS 战里卡死了角色原地发呆技能循环毫无反应一场本该 3 分钟的战斗拖成了 10 分钟最后以团灭收场。这不是个别现象而是游戏自动化领域的通病——脚本能动却不会看、不会想、不会应变。绝区零一条龙ZenlessZoneZero-OneDragon正是冲着这个问题来的。这个基于 Python 的开源游戏自动化框架用一套事件驱动状态机引擎重新定义了挂机它不只是机械地按键盘而是先看懂画面再决定下一步做什么最后才执行操作。本文将带你从它的核心设计出发看看这套框架凭什么敢说自己能全自动刷空洞、自动闪避、自动做每日——以及它为什么值得你在动手写下一个自动化脚本前先认真研究一遍。一个深夜翻车现场暴露了脚本的三个致命伤先从一个具体的翻车场景说起。假设你想写一个自动刷副本的脚本第一版通常长这样等 5 秒 → 按攻击键 → 循环。它确实能跑但只能跑 30 秒——因为游戏不会按你的剧本走画面是动态的。加载画面、结算弹窗、升级动画每个环节的节奏都不一样固定延时迟早对不上。状态是分叉的。同样点一下挑战按钮可能进入战斗、可能弹出体力不足、可能网络重连分支多得写不完。失败是不可预测的。一次闪避失误、一次技能放空都可能让流程走向完全不同的结局。传统脚本的应对方式是用if/else堆逻辑但游戏的流程复杂度远超人的枚举能力。绝区零一条龙的答案是把流程彻底数据结构化不再是一行行顺序执行的代码而是一张可以运行、可以调试、可以复用的有向节点图。这套设计正是它的核心资产我们一步步拆开看。拆开快递一条龙框架的三层世界动手看代码前先建立全局认知。项目的目录结构非常规整可以理解为三个相互独立的世界第一层通用自动化底座src/one_dragon/。这里没有一行绝区零专属代码只有与游戏无关的通用能力操作节点引擎、模板匹配器、OCR 服务、事件总线、截图与输入控制器。换个游戏这一层几乎可以原样复用。第二层业务逻辑src/zzz_od/。这里才是懂绝区零的部分。自动空洞、世界巡逻、防卫战、每日签到、咖啡店、邦布店……二十多个功能应用全部以插件形式挂载在底座上每个应用就是一个独立的包。第三层数据与配置assets/game_data/与config/。游戏的所有知识被抽离成 YAML每个界面的按钮位置、每个区域的文本、每张地图的道路掩码、每个角色的战斗策略全部外部化配置改配置就能适配新版本不用动代码。这种底座—插件—数据的分层让新功能开发变成了填配置 写节点的组装游戏而不是从零造轮子。接下来我们进入最精彩的部分节点引擎。让流程成为图状态机设计的三个关键决策一个自动化流程本质是当前处于什么状态 → 根据感知结果 → 迁移到下一个状态。绝区零一条龙把这句话翻译成了极简的代码模型全部浓缩在两个装饰器里# src/one_dragon/base/operation/operation_node.py def operation_node( name: str, timeout_seconds: float None, is_start_node: bool False, node_max_retry_times: int 3, screenshot_before_round: bool True, ): # 把节点元数据附加到函数上运行前统一收集# src/one_dragon/base/operation/operation_edge.py def node_from(from_name: str, success: bool True, status: str None, ignore_status: bool True): # 声明从哪个节点来边会在构图阶段自动补全去向用真实代码看效果。这是自动空洞迷失之地入口流程的一段src/zzz_od/application/hollow_zero/lost_void/lost_void_app.pyoperation_node(name初始化加载, is_start_nodeTrue) def init_for_lost_void(self) - OperationRoundResult: if self.run_record.is_finished_by_day: return self.round_success(LostVoidApp.STATUS_ENOUGH_TIMES) self.ctx.lost_void.init_before_run() return self.round_success(LostVoidApp.STATUS_AGAIN) node_from(from_name初始化加载, statusSTATUS_AGAIN) operation_node(name识别初始画面) def check_initial_screen(self) - OperationRoundResult: # 通过 find_and_click / OCR 判断当前在哪一屏 return self.round_success(可前往快捷手册) # 或其它状态 node_from(from_name识别初始画面, status可前往快捷手册) node_from(from_name识别初始画面, statusOperation.STATUS_SCREEN_UNKNOWN) node_from(from_name识别初始画面, status未识别初始画面) operation_node(name前往零号空洞-入口) def tp_to_lost_void(self) - OperationRoundResult: ...这个设计里有三个值得玩味的决策决策一节点即函数边即装饰器。每个节点就是类里的一个方法operation_node把节点元数据名称、超时、重试次数挂在函数上node_from则声明我这个节点从哪个节点来。运行时引擎用inspect扫描类方法自动收集节点和边组装成图——代码写出来就是流程图本身可读性拉满。决策二节点不调用下一个节点只返回状态。节点之间没有直接调用关系每个节点只管返回round_success(某个状态)或round_retry(...)至于下一步去哪由引擎根据边的匹配规则决定。这让节点高度内聚改一个节点不需要动它的所有邻居。决策三边支持状态过滤与兜底。从上面的代码能看到同一个节点可以发出多条边分别匹配不同的返回状态ignore_statusTrue的边则作为兜底在所有精确匹配都落空时兜住流程避免死锁。这是应对游戏画面千变万化的关键保险。引擎的呼吸主循环、轮次结果与边匹配图建好了谁来跑Operation.execute()是一个极其清醒的主循环src/one_dragon/base/operation/operation.pywhile True: if self.timeout_seconds ! -1 and self.operation_usage_time self.timeout_seconds: op_result self.op_fail(Operation.STATUS_TIMEOUT) # 整体超时保护 break if self.ctx.run_context.is_context_stop: op_result self.op_fail(人工结束) # 用户随时可叫停 break round_result self._execute_one_round() # 执行当前节点一轮 if round_result.result OperationRoundResultEnum.RETRY: self.node_retry_times 1 # 单节点重试计数 if self.node_retry_times self.node_max_retry_times: continue if round_result.result OperationRoundResultEnum.WAIT: continue # 等待 原地再拍一张 next_node self._get_next_node(round_result) # 按状态找下一条边 if next_node is None: # 没有后继 流程结束 break self._current_node next_node每一轮执行节点方法返回四种结果之一SUCCESS进入下一条边、FAIL走失败边或结束、RETRY本节点重试 N 次、WAIT等一帧再判断。_get_next_node则遍历当前节点的出边按success匹配 status精确匹配 ignore_status兜底的优先级选出下一个节点。这个循环还内置了三层防护值得单独强调逐节点超时与重试一个节点可以设置自己的超时秒数和最大重试次数比如示例里前往迷失之地-入口设了 20 次重试不怕偶发卡顿。整体超时与人工干预整个操作有总时长上限用户暂停、停止随时生效绝不无限挂机。游戏窗口守护构图时会自动在起始节点前插入检测游戏窗口 → 打开并进入游戏两个前置节点_add_check_game_node游戏没开先把你送进游戏再说。很多无人值守场景的翻车其实都栽在这一步——这个框架替你兜住了。一双看得见的手三级识别与配置驱动的眼睛状态机的每一步决策都依赖感知而感知靠的是三条并行的识别通道模板匹配对按钮、图标、血条这类固定 UI 元素用模板图像做匹配毫秒级出结果是高频路径的主力。OCR 识别对挑战、确认、体力不足这类动态文本用内置的 ONNX 运行时 OCR 引擎读取并带区域缓存避免重复计算。YOLO 目标检测对敌人姿态、连携条、BOSS 血线这类复杂视觉场景用目标检测模型定位。三条通道的分工耐人寻味凡是稳定的东西用模板凡是变化的东西用 OCR凡是模糊的东西用 YOLO。但真正的设计精华是把眼睛看哪里也配置化了——assets/game_data/screen_info/下每个界面一个 YAML声明各个按钮的区域坐标assets/game_data/world_patrol/lemnian_hollow/下每张地图配有道路掩码图导航时先识别小地图再对照掩码判断可走路径。这意味着游戏 UI 改版通常只需更新 YAML 与图片模板框架代码毫发无损。版本适配成本被压缩到一个不可思议的量级。让组件彼此说话事件总线与上下文状态机解决的是一个流程怎么走但一个框架里同时跑着战斗、巡逻、推送、GUI 多个子系统它们之间怎么协作绝区零一条龙的答案是**上下文Context 事件总线EventBus**的松耦合组合。上下文OneDragonContext是全局单例的服务容器截图控制器、匹配器、OCR、配置、运行记录全都挂在这里任何节点都能通过self.ctx取到。而事件总线src/one_dragon/base/operation/context_event_bus.py实现标准的发布—订阅class ContextEventBus: def dispatch_event(self, event_id: str, event_obj: Any None): if event_id not in self.callbacks: return for callback in self.callbacks[event_id]: future _od_event_bus_executor.submit(callback, ContextEventItem(event_id, event_obj)) future.add_done_callback(thread_utils.handle_future_result)注意ThreadPoolExecutor.submit——事件回调被丢进线程池异步执行发事件的人不阻塞。操作引擎靠它监听暂停/恢复GUI 靠它刷新状态异常检测靠它广播告警。组件之间不知道彼此存在只认事件 ID这正是加一个功能不动旧代码的底气所在。实战走读一次自动空洞整条链路如何协同把上面的设计串起来看一次真实的自动空洞迷失之地运行你会理解每一层在干什么入口判断识别初始画面节点截屏先用区域查找判断挑战-确认按钮再用 OCR 判断当前在哪个界面大世界/快捷手册/副本画面返回不同状态。路线分流返回可前往快捷手册就走手册传送链返回可前往副本画面就直接进副本链不同状态走不同边——这就是状态机对分叉的优雅处理。循环推进进入副本后节点在识别悬赏委托完成进度处检查每日次数够了直接STATUS_ENOUGH_TIMES收工否则继续挑战流程战斗阶段由自动战斗应用接管配合闪避检测与技能循环。异常兜底任何一个环节找不到目标节点返回RETRY重试 N 次仍失败则走失败边或由全局超时兜底退出绝不死循环。值得一提的是整套引擎自带运行轨迹可视化每个节点从哪来、返回什么状态、耗时多少毫秒都通过 overlay 调试总线实时推送。用户能在界面上看到初始化加载 → 识别初始画面 → 前往零号空洞-入口的完整流转轨迹。自动化流程不再是黑盒而是可以观察、可以回放、可以定位的透明管道——这一点对排障体验的提升怎么强调都不过分。冷静的审视它做到了什么还差什么回到开头的翻车现场。绝区零一条龙给出的解法本质上是把自动化从指令序列升级为感知—决策—执行的闭环状态机并配套了三件利器配置驱动的数据层低成本适配版本、事件总线的松耦合低成本扩展功能、轨迹可视化的调试层低成本定位问题。对于想研究游戏自动化架构、或想给自家工具套上会看图、会决策能力的开发者它是一份极好的活教材。当然它也有清醒的边界强绑定 Windows 生态控制器基于窗口句柄与模拟输入跨平台Linux/macOS需要重写控制器层。配置工作量大新界面、新玩法需要采集模板、标注区域、写道路掩码数据生产本身有成本。对画面稳定性敏感高分辨率缩放、滤镜、非默认画质都可能影响识别率需要用户保持环境一致。如果让我给改进方向提三条建议一是将模板与区域配置做可视化采集工具把写 YAML变成框选即生成二是引入强化学习做技能循环自适应让战斗策略从配置驱动升级为数据驱动三是沉淀一套通用界面状态识别抽象层让底座真正脱离绝区零成为通用的游戏自动化内核。毕竟这套框架最迷人的地方不是它自动化了哪款游戏而是它证明了把流程画成图、把感知做成数据、把协作交给事件——复杂系统的自动化可以优雅得像个艺术品。【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址: https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考