桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载导读本文围绕开源仓库 ZenlessZoneZero-OneDragon 的 docs/game/screens/README.md画面描述索引展开。该索引按screen_name组织「1 篇文档 ↔ 1 个screen_info画面」的知识库是自动化的眼睛从登录页到大世界、从战斗画面到各种非战斗 App每个可识别画面都有对应的描述文档与assets/game_data/screen_info/name.yml配置文件。读完本文你将掌握画面索引的组织方式与双向引用规范、36 个已登记画面的分类与建档状态、非战斗 App 的三种建档路线以及如何用 MCP 工具增改/删除画面区域、OCR 快照复核为缺口画面补档的完整实操流程。一、画面描述索引是什么自动化的视觉地图在绝区零一条龙ZenlessZoneZero-OneDragon这类全自动脚本项目中AI 或脚本要能看懂游戏画面才能决定下一步操作。这一能力建立在screen_info 画面模型之上每个可识别画面对应一份 YAML 配置assets/game_data/screen_info/ 目录下如 menu.yml、大世界、战斗画面而 docs/game/screens/README.md 就是这个模型的人类可读索引。索引的定位规则只有一句话按screen_name组织每篇文档 ↔ 一个assets/game_data/screen_info/name.yml。这里的关键是screen_name中文名如「菜单」「大世界-普通」「打开游戏」而不是底层的screen_id英文标识如menu、common_screen。这个约定在 docs/game/README.md 的「记录规范」中被再次强调——关联键一律使用screen_info.screen_name中文非screen_id。之所以这样约定是因为文档面向本地 AI 与开发者阅读中文画面名更直观且能与gameplay_name形成跨文档的双向引用。1.1 双向引用规范screens ↔ gameplaydocs/game/目录下有两类领域知识文档docs/game/README.mdscreens/— 画面描述1 篇 md ↔ 1 个画面对齐assets/game_data/screen_info/name.ymlgameplay/— 玩法描述跨画面的机制与系统。两者通过 frontmatter 建立双向引用screens/*.md的 frontmatter 带appears_in本画面出现在哪些玩法用gameplay_namegameplay/*.md的 frontmatter 带involves_screens本玩法经过哪些画面用screen_name。以 大世界.md 为例其 frontmatter 为screen_name: 大世界 appears_in: [登录游戏] last_updated: 2026-07-06 source_image: screens/大世界/普通.webp除了appears_infrontmatter 还会记录last_updated核对日期和source_image当前基线截图。规范明确要求正文绝不写死截图 ID因为.debug/images/下的截图文件名是一次性捕获 ID、易失变更复核走方法重新截图 →analyze_screen→ 与 OCR 快照 diff → 更新last_updated/source_image归档测试则使用可读名的 webp 版本方法论见 docs/develop/zzz/screenshot_archive.md。1.2 识别快照每篇画面文档的体检报告每篇画面文档都要求保存一份analyze_screen快照包含三部分匹配画面screen_nameis_precise是否精准命中匹配 area 表取自screens[].areas包含 area_name、类型text|template、文本或template_id、conf置信度、位置x,y,w×h基于 1080p 游戏空间坐标pc_rect全量 OCR 文本ocr_texts。大世界.md 的识别快照展示了这一格式- 匹配画面: 大世界-普通 (is_preciseTrue ✓) - 匹配 area: | area | 类型 | conf | 位置 (x,y,w×h) | |---|---|---|---| | 按钮-信息 | template | 0.991 | 1738,928,78×78 | | 预备编队 | template | 0.990 | 1321,51,90×44 | | 快捷手册 | template | 0.968 | 1531,60,48×43 |一个值得注意的细节MCP 的ocr_texts保持全量area 维护的文字可能不全所以文字 area 在「匹配 area 表」和「全量 OCR 文本」两边都出现属正常现象并非重复维护。二、36 个画面条目全景screen_name / 文件 / 简介总表索引正文是一张按screen_name排列的登记表。下表完整继承了原索引的全部 36 个条目含末尾补充的「预备编队」并补注了各自的建档状态已建模 / 已建档 / screen_info 缺口 / 待补便于读者快速定位哪些画面能用、哪些待补。screen_name文件简介状态菜单menu.md游戏主菜单已建模menu.yml米哈游启动页米哈游启动页.md打开游戏首个画面品牌/合规screen_info 缺口警告:游戏前详阅警告_游戏前详阅.md登录前的光敏性癫痫警告页screen_info 缺口绝区零标题页绝区零标题页.md游戏 logo 展示页screen_info 缺口打开游戏打开游戏.md登录页自动/手动登录多子态验证码/账号密码/扫码/选区服已建模加载画面加载画面.md通用加载画面lore 轮换screen_info 缺口大世界大世界.mdOverworld 主画面活动入口/任务/快捷键已建模is_precise战斗画面战斗画面.md战斗实动作界面战斗态稳定锚点攻击按钮模板id_mark 无框架走is_normal_attack_btn_available子态默认/精英BOSS血条/限时倒计时/战斗结果已建模实战模拟室实战模拟室.md养成材料副本快捷手册-训练入口副本选择/出战/战斗结束-获得奖励获得弹窗子态战斗结束按玩法分战斗中归战斗画面防卫战挑战结果/实战模拟室获得弹窗各玩法各 screen已建模式舆防卫战式舆防卫战.md周期战斗玩法快捷手册-作战入口选关主界面前哨档案节点01-05剧变节点进度弱点/编队/战斗/领奖多子态剧变节点进度 OCR 连写3/5→315issue #2510已建模迷失之地迷失之地.mdlost_void 零号空洞战斗肉鸽层间移动重 app已实拍 5 选择/结算画面通用选择/武备选择/挑战结果/路径迭换/抽奖机其余 9 画面大世界/入口系列/战线肃清/矩阵行动/特遣调查/邦布商店/战斗失败待补✅通用选择按钮-确定宽 rect940px曾致 ppocrv6 漏检 ppocrv5 误判「以太稳定」卡死已收紧 rect提 lcs 修复ppocrv6 恢复部分实拍快捷手册快捷手册.md玩法总入口大世界右上5 TAB目标/日常/训练/作战/战术各玩法卡片「前往」传送TransportByCompendium经此已建模邮件邮件.md每日领取邮件附件菜单→邮件列表态 确认弹窗子态已建档已建档菜单-更多功能菜单-更多功能.md菜单点「更多」功能入口枢纽预备编队/兑换码/登出已建模兑换码输入兑换码输入.md兑换码输入框菜单-更多功能→兑换码screen_info 缺口结果弹窗待补仓库-驱动仓库仓库-驱动仓库.md仓库音擎 TAB-驱动盘驱动盘管理已建模识别模糊仓库-驱动仓库-驱动盘拆解驱动盘拆解.md驱动盘拆解快速选择/拆解默认态误匹配快捷手册拆解确认待补已建模快捷手册-日常快捷手册-日常.md手册日常 tab今日活跃度奖励领取弹窗待补活跃度已满已建模丽都城募丽都城募.md大月卡菜单→丽都城募5 tab成长任务/等级回馈领奖已建模报刊亭报刊亭.mdscratch_card 场景F 交互进报刊亭场景刮态嗷呜对话/确认待补已建档刮刮卡地图地图.md网格/列表传送视图MapTransport用底部传送点列表确认弹窗选传送点/传送确认弹窗子态已建已建模3D地图3D地图.md立体城市俯视world_patrol/锄大地用区域/子区域/筛选/图标/前往无确认弹窗子态待补截图已建模卦象集录卦象集录.mdtrigrams_collection澄辉坪阿朔交互主界面今日已领取已建档滑动获取卦象/领奖确认待补已建档对话对话.md通用兜底画面大世界 NPC/剧情对话无固定文字特征有 NPC 名已建档旁白对话待补已建档兜底随便观随便观.mdsuibian_temple 经营玩法入口interact 狮耶 9 子画面实拍归档游历/制造坊/售卖铺/饮茶仙/邦巢/德丰大押/好物铺/自动托管/经营总览共 7 screen_info入口游历/制造坊/售卖铺/饮茶仙/邦巢/德丰大押、3 画面无好物铺/自动托管/经营总览待补部分实拍影像店营业影像店营业.mdrandom_play 录像店经营无战斗经营状况/宣传员选择/录像带上架已建档营业确认弹窗待补已建档丽都周纪丽都周纪.mdridu_weekly 周常 BINGO 积分领奖无战斗BINGO 主画面已建档已建档咖啡店咖啡店.mdcoffee 每日咖啡增益⚠️边界核心点咖啡非战斗 可选挑战副本含战斗对话点单-已喝过态已建档已建档边界 app吼吼饼铺吼吼饼铺.mdhou_hou_bakery 每日签到盲盒无战斗骨架已建信息源三层⚠️Transport 卡 3.0 布亚斯特城区未探索截图待补骨架已建委托助手委托助手.mdcommission_assistant 对话/剧情/钓鱼辅助循环器非固定画面多态识别已建 doc⚠️含可选 auto_battle 边界已建档辅助循环器道具处理道具处理.md仓库道具处理子界面合成/分解/摧毁合成电池玩法经此合成以太电池60电量储值电卡丁尼合成页合成确认获得弹窗三子态已建模仓库-材料道具仓库-材料道具.md仓库材料道具页道具处理的另一入口TAB 音擎/驱动盘⚠️未 live 实证代码零引用纯画面连通图未实证恢复电量恢复电量.md副本内电量不足弹窗储蓄/电池/菲林 兑换电量主弹窗快捷使用获得三子态RestoreChargeop⚠️菲林来源 config 未支持已建模预备编队预备编队.md通用画面多玩法共用预备编队列表两子态选择准备出战有 SELECT/预备出战/ 编辑管理PredefinedTeamChecker只能编辑当前命中实战模拟室无独立 screen_info已建模2.1 实战模拟室 vs 防卫战战斗结束画面按玩法分流索引中「实战模拟室」条目隐含了一个重要设计原则——战斗结束画面的归属按玩法分流战斗中画面统一归「战斗画面」防卫战结束后 → 「挑战结果」画面实战模拟室结束后 → 「获得奖励」弹窗。因此每个玩法都有各自的screen不能共用一个战斗结束通用画面。这与 式舆防卫战.md 中「选关主界面 弱点/编队/战斗/领奖多子态」的建模方式一致一个玩法 一个 screen_name 多个子态 area。2.2 迷失之地的 OCR 修复案例ppocrv5/v6索引中「迷失之地」条目记录了真实的排障案例值得自动化开发者留意✅ 通用选择按钮-确定宽 rect940px曾致 ppocrv6 漏检 ppocrv5 误判「以太稳定」卡死已收紧 rect提 lcs 修复ppocrv6 恢复。这说明OCR 引擎ppocrv5 与 ppocrv6对同一区域的行为可能截然不同——过宽的矩形区域会让新版引擎漏检、旧版引擎误检。修复手段是同时收紧pc_rect并提高 LCS最长公共子序列用于文本相似度匹配的lcs_percent阈值。这也是在 menu.yml 中每个 area 都带有pc_rectlcs_percenttemplate_match_threshold的原因。三、screen_info 配置结构一个 area 的完整字段要理解索引文档必须先能读懂它背后的 YAML。以 menu.ymlscreen_id: menuscreen_name: 菜单为例一个典型的 area 字段如下- area_name: 返回 id_mark: false pc_rect: [82, 13, 150, 90] # 1080p 游戏空间坐标 (x, y, w, h) text: lcs_percent: 0.1 # 文本 LCS 相似度阈值 template_sub_dir: menu # 模板子目录assets/template/ 下 template_id: back # 模板名 template_match_threshold: 0.7 # 模板匹配阈值 color_range: null goto_list: [] # 点击该 area 后的跳转目标 screen_namearea 的类型通过字段组合区分文字 areatext靠 OCR 识别text字段如「邮件」「仓库」「确认」模板 areatemplate靠模板匹配template_sub_dirtemplate_id如「返回」menu/back、「关闭」menu/btn_close跳转 areagotogoto_list非空表示点击后进入的目标画面如 menu.yml 中- area_name: 底部-更多 text: 更多 goto_list: - 菜单-更多功能 # 点击「更多」→ 进入「菜单-更多功能」画面 - area_name: 按钮-返回 id_mark: true # id_marktrue 的画面锚点 template_id: back template_match_threshold: 0.9 goto_list: - 大世界-普通 # 返回 → 大世界-普通另外screen_id: common_screen、screen_name: 画面-通用common_screen.yml是通用兜底画面包含「左上角-区域」「返回」「关闭」等公共 area。这与 对话.md、加载画面.md 这类无固定文字特征的兜底画面fallback screen相呼应。四、非战斗 App 的三种建档路线与跳过原则索引后半部分「非战斗 app 建档进度」对无战斗玩法的 App 做了分类是按「操作复杂度」划分的三条建档路线4.1 路线一纯 UIMCP 可复现已建档email邮件/redemption_code兑换码/drive_disc_dismantle驱动盘拆解/engagement_reward快捷手册-日常/city_fund丽都城募/ridu_weekly丽都周纪BINGO 积分领奖。这类 App 纯点按 UI 即可走通对应的 screen_info 已可在 assets/game_data/screen_info/ 中直接查到如 email.yml、city_fund.yml、ridu_weekly.yml。4.2 路线二move / interact / drag 类已建档scratch_card报刊亭刮刮卡嗷呜对话 / 确认弹窗待补trigrams_collection卦象集录滑动获取卦象 / 领奖确认待补random_play影像店营业Transport POINT_2 interact 进经营营业确认弹窗待补suibian_temple随便观入口 interact 狮耶 9 子画面实拍归档3 画面无 screen_info 待补。这类 App 需要鼠标拖拽、交互进入等操作建档时用key_tapdragrun_operation Transport分解具体见 onboarding skill 的「截图获取」章节。4.3 路线三通用兜底画面无固定文字特征已建档对话NPC 对话有 NPC 名已建档旁白待补、加载画面通用 lore 轮换。这类画面没有稳定的文字特征只能靠兜底逻辑识别详见 onboarding skill 的「兜底画面」章节。4.4 ⚠️ 跳过与不建档跳过边界 app不在建档范围hou_hou_bakery吼吼饼铺.md骨架已建信息源三层⚠️Transport 卡 3.0 布亚斯特城区未探索截图待补life_on_line危局含战斗EnterHddMissionKeySimRunner非「不含战斗」appcommission_assistant委托助手.md辅助循环器多态识别已建 doc⚠️含可选 auto_battle边界coffee咖啡店.md已建档非战斗画面⚠️边界 app可选挑战副本含战斗。不建档无游戏画面notify只发推送通知汇总 run_record不截图/不点 UI。4.5 缺口画面的补档路径索引明确给出结论跳过的 app 待 MCP 补足transport/move/drag/键盘注入能力后或用框架run_standalone_app跑通后沿途截图补。即缺口画面的补档依赖两条通道——MCP 的交互能力扩展或run_standalone_app独立跑通后沿途截图。五、源码级验证screen_info 的读写与 MCP 工具画面索引不只是文档约定它在后端源码中有完整的落点。以下路径均在 src/zzz_od/backend/ 下可验证。5.1 screen_loaderget_screen / save_screen画面模型的读取与回写由上下文对象screen_loader承担。从源码结构看其核心接口包括screen_loader.get_screen(screen_name)按中文screen_name取画面未找到时 raisescreen_loader.save_screen(screen_info)把修改后的画面写回对应 YAML 并重载。调用点示例backend_context.py 的 area 增删逻辑约 L587-L650screen_info self._ctx.screen_loader.get_screen(screen_name) # 未找到 raise action screen_info.upsert_area(area) self._ctx.screen_loader.save_screen(screen_info)以及删除路径if not screen_info.remove_area_by_name(area_name): ... # 未找到 area 报错 self._ctx.screen_loader.save_screen(screen_info)区域更新语义为area_name 已存在 → 整体更新不存在 → 追加随后写回 YAML 并重载保证运行时热生效。5.2 坐标体系pc_rect 与 1080p 游戏空间索引文档中的坐标如大世界的1531,60、1738,928都基于1080p 游戏空间坐标与 screen_info 的pc_rect同源。这一点在 backend_context.py 的点击/拖拽工具注释中被反复强调点击点击游戏窗口内指定坐标(1080p 游戏空间,同源 screen_info pc_rect)拖拽鼠标按住拖拽((x1,y1)→(x2,y2),1080p 游戏坐标,同源 screen_info pc_rect)。这也解释了 大世界.md 中「PC 端点击需pc_alttrueAlt 解锁光标 非零press_time框架默认 0.1」的原因绝区零 PC 端锁光标不按 Alt 直接点击会落空。5.3 匹配结果语义is_precise 与候选列表screens匹配结果在 schemas.py 中的语义为画面匹配结果精准命中 [1 个 is_preciseTrue]否则 top_n 个 is_preciseFalse 候选。决策优先看 screens需看散落文本再看 ocr_texts。而 backend_context.py 在识别回写逻辑中有条件判断if write_back and screens and screens[0].is_precise:即只有精准命中时才考虑回写状态避免把模糊候选当结论写入。索引文档中「大世界-普通is_preciseTrue ✓」这类标注正对应此语义。5.4 MCP 工具建档/维护画面区域的实操入口画面索引的建档工作通过 MCPModel Context Protocol服务完成入口在 mcp/app.py。与本文主题直接相关的工具包括识别画面决策入口analyze_screen相关工具返回screens精准命中 1 个is_preciseTrue否则 top_n 候选ocr_texts离线校验时从.debug/images/名字.png读图、不回写识别状态用于校验/反哺 screen_info增改画面区域按area_name在指定 screen 插入或更新一个 area写 yml reload操作类删除画面区域按area_name删除写 yml reload操作类 不可逆需谨慎。配合索引正文与每篇画面文档的「识别快照」即可完成截图 → analyze_screen → 对照快照 diff → 增改 area → 更新文档 last_updated的闭环维护流程。六、实战如何阅读与使用这份索引6.1 快速定位一个画面是否可用在 README.md 索引表中按screen_name中文找到对应条目查看「简介」列的建档状态词已建模screen_info 完整可用如 menu.yml、已建档画面文档已建但 screen_info 可能不全、screen_info 缺口只有文档、无 YAML 配置、待补已知缺口若需在代码/配置中核实到 assets/game_data/screen_info/ 找name.ymlname 为英文 screen_id确认screen_name与area_list是否齐全。6.2 从索引走向画面细节每个条目链接的画面文档如 大世界.md、战斗画面.md、式舆防卫战.md会进一步给出何时出现进入路径识别特征稳定锚点模板/文字/位置可交互元素每个 area 的坐标与 goto 目标条件弹窗模态覆盖非独立画面识别快照匹配画面 area 表 OCR 文本。6.3 为缺口画面补档工作流针对标记为「screen_info 缺口 / 待补」的画面按索引第 4.5 节给出的路径操作优先选择 MCP 具备transport/move/drag/键盘注入能力后补档或用框架run_standalone_app跑通对应 App沿途截图用 MCPanalyze_screen识别截图对照 docs/game/README.md 的「识别快照」规范匹配画面 area 表 全量 OCR记录快照用「增改画面区域」工具写入 areaarea_name已存在则整体更新、不存在则追加写 yml reload更新画面文档 frontmatter 的last_updated/source_image保持双向引用appears_in↔involves_screens一致。6.4 边界与陷阱不要混淆 screen_name 与 screen_id文档/索引用中文screen_nameYAML 文件名与代码中常用英文screen_id兜底画面对话/加载画面无固定文字特征别期待其像大世界那样有精准模板锚点战斗结束画面按玩法分流切勿用一个通用「结算」画面覆盖所有玩法OCR 引擎差异ppocrv5 vs ppocrv6会导致同一 rect 表现不同参考迷失之地案例必要时收紧pc_rect并调整lcs_percent识别回写仅在 is_precise 时发生见 5.3 节模糊匹配不写入状态。七、结语从索引到模型的反哺闭环这份画面索引属于 docs/game/README.md 定义的离线领域知识库——Part A 的analyze运行时并不读取它运行时解耦它服务于「自由积累 → 统一分析 → 反哺/重构 screen_info 模型」的演化路径对应 CLAUDE.local.md 的「增量 → 合并回主 spec」。因此索引与其说是运行文档不如说是画面模型的增量待办清单 验收台账36 个条目中哪些已建模、哪些已建档、哪些待补一目了然每补一个画面assets/game_data/screen_info/ 就多一份可被 src/zzz_od/backend/ 读取的 YAML自动化的眼睛就更完整一分。对希望为该项目贡献画面建模能力的开发者而言这份索引就是最佳起点。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐绝区零一条龙ZenlessZoneZero-OneDragon仓库-材料道具画面解析screen_info 建模、goto 连通与代码零引用现状绝区零一条龙ZenlessZoneZero OneDragon仓库 材料道具画面解析screen_info 建模、goto 连通与代码零引用现状 导读 本桌面应用RPA计算机视觉QMK 固件中的 Atreus62 键盘支持从键盘配置到构建烧录全指南QMK 固件中的 Atreus62 键盘支持从键盘配置到构建烧录全指南 本篇技术指南以 QMK 固件仓库中的 keyboards/atreus62/readm桌面应用RPA计算机视觉绝区零一条龙画中画PiP模式架构与实现深度解析绝区零一条龙画中画PiP模式架构与实现深度解析 导读 画中画Picture in PicturePiP模式是「绝区零 一条龙」ZenlessZon桌面应用RPA计算机视觉创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考