桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载导读本文讲解 ZenlessZoneZero-OneDragon绝区零 一条龙项目中画面建档screen onboarding的完整方法论从拿到一张待建档的游戏截图开始如何按「客观识别 → 主观理解 → 建档 → 缺口分析 → 主动建模 → 归档」推进把画面事实沉淀为稳定的文档docs/game/screens/与可被识别器使用的模型screen_info area / 模板。读完本文你将掌握 MCP 工具直调的正确姿势、三层信息源并用的核对方法、手动分解操作抓取中间态画面的技巧以及把图形按钮从「OCR 盲区」建为 CV 模板的完整链路。本文主体来自 skills/zzz-od-dev-screen-onboarding/SKILL.md配套设计说明见同目录 design.md并辅以仓库源码逐条佐证。前置工具用法避免绕路建档的第一个坑是绕路。本 skill 明确要求MCP 工具直调mcp__zzz_od__analyze_screen/upsert_screen_area/delete_screen_area不要写 HTTP 客户端脚本绕路连接 stale 时让用户/mcp重连。设计文档记录了这条教训早期曾写过streamablehttp客户端脚本调 server其实mcp__zzz_od__*工具一开始就在工具列表里直调即可。screen_info 的 area 改动一律走 CRUD 工具upsert_screen_area/delete_screen_area—— 它们经save_screen同步独立 yml _od_merged.yml合并缓存 reload。禁止手编 screen_info yml 或手改模板目录手编不重算合并缓存daemon 按旧缓存加载 → 找不到模板/area。从源码看这一约束的底层原因是真实的。在 src/one_dragon/base/screen/screen_loader.py 中save()每次不仅把目标 screen 写回独立 yml还会把全部内置 screen 一并写入合并文件_od_merged.ymlmerge_yml_file_path见 screen_loader.py随后reload(from_memoryTrue)重新加载。只有走 CRUD 工具才能触发这条写独立 yml → 重算合并缓存 → reload的完整链路手编单个 yml 后合并缓存不会重算运行期加载到的仍是旧缓存。设计文档中记录的实例是改名模板时手编了enter_game.yml 重命名目录漏了_od_merged.ymldaemon 报「未找到模板」。MCP 工具本身定义在 src/zzz_od/backend/mcp/app.py其中与建档直接相关的有工具作用源码位置analyze_screen截图 OCR 画面匹配返回结构化结果app.pyupsert_screen_area插入/更新一个 area写 yml reloadapp.pydelete_screen_area删除一个 area写 yml reload不可逆app.pyclick_game/key_tap/drag点击坐标 / 键盘按键 / 拖拽手动复现操作app.py注意analyze_screen是只读工具不改游戏状态upsert/delete_screen_area是操作类工具后者在返回结构中带有action(inserted/updated/deleted)与area_count可用于确认改动生效。另一个边界本 skill 只记建档方法论具体游戏知识归对应文档 —— 传送流程/键位见 地图 / 3D地图玩法机制见 gameplay/本 skill 不记具体键位/流程/机制。建档规模先判「单画面 vs 重 app」拿到任务的第一步不是急着 analyze而是先判建档规模重 app 多子玩法1 app 调度多子 op、每子玩法独立画面 入口→子玩法→返回入口循环如随便观 7 子玩法→ 按app 维度建档而不是逐画面零散建档入口画面 各子玩法画面各自建档每画面独立 doc或同 doc 多子态app 编排节点链 / 分支 / 入口循环单独成develop docdocs/develop/zzz/application/app.md不进 screen doc玩法机制目标 / 资源 / 循环进gameplay doc此时触发zzz-od-dev-gameplay-onboardingskill 对玩法建档不在本 skill 内直接写玩法避免写成代码说明书跨画面 op 联动子 op 委托另一个 op如饮茶仙缺料 → 制造坊补料screen doc 记「跨画面流转入口」develop doc 记编排。判据app 有≥3 子玩法、各独立画面→ 重 app 维度单画面 / 独立 app 走常规五步流程。从仓库实际产物看这一维度判断已经被反复实践docs/game/screens/随便观.md即为典型的重 app 建档成果 —— 它把入口interact 狮耶 游历/制造坊/售卖铺/饮茶仙/邦巢/德丰大押/自动托管/经营总览 等 9 个子画面组织在同一文档体系内入口 状态流转、子画面全集表格、逐画面小节并与 7 个 screen_info yml入口游历/制造坊/售卖铺/饮茶仙/邦巢/德丰大押一一对应另有 3 个画面好物铺/自动托管/经营总览无 screen_info 待补。信息源理解画面三层并用截图只覆盖「当前帧看得到」的内容画面背后的结构信息要另外拉。建档前并读三层截图→analyze_screen客观 area/OCR第 1 步 vision主观布局/状态图标第 2 步。screen_infoassets/game_data/screen_info/screen_id.yml的area_list→ 该画面全部已建模元素含当前帧未显示的子态 area如弹窗按钮。每个 area 的text/template_id/pc_rect/goto_list/pc_alt/gamepad_key直接说明它是啥、点后跳哪、PC 端怎么点。analyze 只返回当前帧命中的 areascreen_info 才是全集。application/operation 代码src/zzz_od/application/app_id/→operation_node链 画面跳转与状态流转round_by_find_and_click_area/round_by_goto_screen调用 在哪画面点哪 area。对齐判据doc 的「可交互元素」「状态流转」要与 screen_infoarea_list 代码逐条对齐—— screen_info 有、doc 无 建档漏补上。截图没显示的子态 area先按 screen_info 代码记入流转、标「待现场快照」。这一层的方法论来自实战教训记录于 design.mdonboard「大世界」时 doc 漏写左上角「按钮-菜单」汉堡 ≡——normal_world_basic.yml的area_list本有此 area但它是纯坐标无 text/template不参与 analyze 匹配只看截图就漏了同期 onboard「邮件」靠读email.yml的 area_list email app 的operation_node链快速理清跳转。所以只看截图是不够的screen_info 与代码才是画面元素的全集来源。版本迁移核对老 app / 大版本更新后必查信息源三层之一是代码但代码可能落后于游戏版本故需核对 —— 游戏版本更新会改画面 / UI / 流程如随便观德丰大押 2.5 移除「百通宝 / 云纹徽」tab → op 点 tab 的代码失效成死代码。判据建档前核对 op 代码假设的画面元素tab / 按钮 / 流程在当前游戏版本还在吗—— 不假设「代码 当前游戏」。发现不符① doc 记版本差异 标「代码与当前版本不符」② 搜官方更新说明确认改动版本③ app 层若有占位短路如handle_xxx直返「未开启」说明已知情标「待重写」。教训德丰大押 op 基于 2.4、2.5 tab 移除靠用户观察 搜官方说明才发现 —— 代码默认有效是建档盲区。截图获取手动分解动作不靠跑 app 中途跑 apprun_standalone_app/ 跑单个 oprun_operation中途capture抓不到中间态—— op 执行快、且会自动消费中间画面如确认弹窗被 op 自己点掉sleep 完再 capture 只能看到 op 跑完的结果如落地入口抓不到中间弹窗如传送后的「自动进入交互」确认。判据app/op 内部连续动作transport→move→interact→drag→…→各弹窗产生的画面按 op 的operation_node节点逻辑手动分解成单步—— 读 op 代码每步一个click_game/key_tap/dragcapture逐步截图在 op 会自动点的弹窗处停下、手动不点、先 capture。跑 app /run_operation只用于「验证流程通」或「到位」不用于抓中间态画面。transport 复现transport 后角色朝向传送后角色朝向继承传送前若传送前已在同一地图。app 常假设 transport 后固定朝向来move_winteract手动复现时先传送去别的地图、再传送回目标地图朝向即重置到默认。补档先读 app/operation 代码 move 距离一致手动复现前先读src/zzz_od/application/app/的operation_node链弄清 transport→move→interact 的具体动作move_wpress_timeturn_to_angleinteract 哪个 NPC按 app 的距离 / 对象复现 —— 别只靠 vision 推朝向 / 距离。判据手动key_tap w的press_time要和 app 的move_w一致如coffee/random_playPOINT_1 是turn_to_anglemove_w 1ssuibian_temple无 move 就不走传送点已在交互范围走多了反而错过交互点角色过头提示消失。Transport 失败排查run_operation Transport失败尤其「执行传送」节点卡 OCR 地图、重试到超时常见根因是目标传送点未解锁 该地图未探索新版本玩法 / 新城区需先跑图解锁传送点其他地图同理。判据Transport 打开了地图但选不中目标点 → 先确认目标地图已探索、传送点已解锁否则换已解锁的 app 建档。仓库里「吼吼饼铺」即为此例骨架已建信息源三层但 ⚠️ Transport 卡 3.0 布亚斯特城区未探索截图待补见 docs/game/screens/README.md。操作时序操作后等动画再 capture否则截过渡帧底层click_game/key_tap/drag无内置等待等待在框架 operation round 层success_waitMCP 不经 round。MCP 工具文档也明确写了这一条 —— 例如 app.py 中click_game的说明「操作后建议 sleep底层 click 无内置等待点 UI 常触发画面切换连续操作或capture_game_screen前建议 sleep ~1s 等动画否则截过渡帧」key_tap 同样提醒「移动 wasd ~1s 等角色到位不等就 interact 可能失效、交互 f ~1-2s 进场景/对话、esc ~0.5s 开关菜单」。操作后画面/角色变化需 sleep 再capture。关键 sleep 点move 后等角色到位不等就紧接 interact 会失效interactF长按press_time0非短按 tap。sleep 建议值click ~1s / move ~1s / interact 1-2s / esc ~0.5s / drag ~0.5s。边缘状态态依赖游戏条件 → 人机协作很多状态态会话内创造不了—— 需游戏特定条件游历到期 / 材料不足 / 持有上限 / 刷新出稀有。判据状态态依赖「资源消耗 / 时间 / 随机」而非「导航可达」→ 标「待条件」别硬刷随机态如稀有掉落刷了空跑消耗态如材料不足在资源充足时不出现。处理① doc 标「待条件」 已拍的核心态先归档②请用户帮切用户能调游戏状态造条件比智能体盲操作高效③ 后续会话条件出现时补。教训随便观 B 类游历收获 / 饮茶缺料 / 邦巢持有上限全靠用户帮切 4 画面才补全。1. 客观识别跑analyze_screenanalyze_screen(screenshot绝对路径 或 .debug/images 图名)取三样对应 app.py 的返回结构AnalyzeScreenResult匹配画面screens[].screen_nameis_precise精准 / 模糊 / 无匹配。匹配 areascreens[].areasarea_name / 类型text|template/ 文本或template_id/ conf / 位置。全量 OCRocr_texts全部文字含噪声/动态值。area 维护的文字可能不全 → 全量 OCR 是权威文本源与匹配 area 的文字重叠属正常勿去重。工具支持三种输入不传screenshot 实时截当前画面需游戏在线传绝对路径 读指定图无需游戏在线传纯名字 读.debug/images/名字.png。离线模式不回写识别状态适合做「离线校验 / 反哺 screen_info」—— 这正是建档场景的常态拿一张截图分析不打扰游戏运行。2. 主观理解多模态 vision 看图必需不只靠 MCP必须用多模态大模型 / 工具看图analyze_image/ vision不能只靠 MCPanalyze_screen的 OCR / area—— OCR 看不见图形 / 图标按钮、布局结构、状态图标选中态 / 已读 / 可领、模态性遮罩、角色朝向 / 场景类型。每张建档截图都要 vision 看一遍漏看会导致元素、画面边界或状态判断不完整。vision 调用失败如 400必须重试换图重传 / 重新 capture不能跳过。设计文档的实测反面scratch_card 刮态 vision 400 没重试就跳过 → doc 漏刮层布局细节。若用户给了画面相关提示向 vision 提偏向该类画面典型元素的问题判据是提示指向某类画面 → 问该类的典型可交互元素 状态文本而非泛泛「描述画面」无提示 → 通用问布局 / 可交互元素 / 文字 / 图标 / 当前状态 / 模态性。明确区分可交互元素按钮 / 输入 / 图标与展示信息。vision 状态推理不可信只信客观描述踩坑固化vision 不懂游戏 —— 它「描述画面有什么」元素 / 文字 / 标记 / 颜色 / 位置 / 布局可信但「判断状态 / 作用」已派遣 / 未派遣、按钮作用、是否可点不可信会基于看到的文字瞎猜。prompt 要客观描述「有哪些文字 / 按钮 / 图标各自位置(x,y)哪个元素有三角形 / 高亮 / 颜色标记」别问状态推理状态判断结合代码自己做如choose_period检测「提前收获」已派遣 / 检测 duration选时间预览而非靠 vision 看「剩余时间」猜已派遣 —— 那个时间可能只是选时预览不是进行中倒计时。可交互对象判据名字绝区零 NPC / 交互对象进入可交互范围时名字左右出现三角形标记如 狮耶 出现即在交互范围interact F即可不需再走。⚠️ OCR 常只识出名字漏了符号vision 也不懂这约定 → 双双误判「没到还要走」。判据画面出现 NPC 名字 app 假设该位置可交互 → 直接试key_tap fF 实际选中的对象看结果画面F 提示文本未必是 F 实际交互对象如 F 提示小贩但实际 interact 了狮耶vision 提示词要明确「可交互对象名字左右有三角形出现即已可交互不要再走」。角色朝向/视角判据vision 盲区vision 对朝向 / 视角推断不可信 —— 本游戏是第 3 人称追尾视角看到角色背部 角色正对前方vision 会误判「背对」差点误导走「跨地图朝向重置」弯路design.md 记录suibian_temple 入口建档时 vision 判「角色背对随便观入口」实际摄像机在主角身后。判据朝向以 OCR 交互提示如「前往 XX」 实际 interact 结果为最终判据别轻信 vision 的朝向推断。3. 建档先判独立画面还是已建档画面的子态模态/弹窗/状态如对话框、loading/ready 子态独立画面→ 新建docs/game/screens/name.md中文screen_name文件名英文 snake_case、不带冒号等特殊字符登记进 docs/game/screens/README.md 索引一行。子态→ 并进父画面 doc「何时出现/状态流转」补该子态的入口从哪来 出口动作→下一态、「可交互元素」补该态元素、「识别快照」加该态子表不另开文件、不登索引。建档文档 稳定的画面参考事实不是建档过程的日志。描述类章节何时出现/状态流转/识别特征/可交互元素/识别快照只写画面本身的事实长啥样/元素/识别/流转建档/排查过程的产物不混入不进 doc① 测试结果通过/失败 —— 测试归zzz-od-testdoc 不跟踪测试状态② bug/修复历史「原 bug...现已修」归 commit/PRdoc 只写现状。进「备注」并与事实分开开放问题如某元素触发条件未知、screen_info 现状缺口、易变点。判据每句问「这是画面本身的事实还是建档/排查过程的产物」后者不进描述章节。design.md 记录的实例onboard 迷失之地战斗失败时把「✅ 两种布局均识别 GREEN」测试结果、「原 bug...现已修」修复历史混进了画面描述稳定事实被淹没doc 变得像排查日志后续已清理。新画面 doc 结构frontmatterscreen_name/appears_in: [gameplay_name...]/last_updated核对日期/source_image归档后用测试仓相对路径screens/screen/state.webp—— 自描述可找含 screen 目录无跨 screen 歧义归档前可暂记.debug基线图名归档后更新为完整路径别留临时截图名 / 只写 state 名。仓库实例见 随便观.md 的 frontmatterscreen_name: 随便观、appears_in: [随便观经营]、source_image: screens/随便观/入口-手动态.webp。何时出现 状态流转出现条件 前后邻居多子态画面必须记状态流转每子态入口 从哪来[动作/条件]、出口 动作→下一态用表格或链式表达。识别特征稳定锚点稳定文字 / 模板图标 / 固定图标标注易变值版本号 / 进度 / 公告勿当特征。可交互元素按钮 / 输入 / 图标图形按钮注明「需模板/CV」。识别快照 ① 匹配画面screen_name is_precise② 匹配 area 表area_name / 类型 / 文本或 template_id / conf / 位置③ 全量 OCR 文本。多子态画面的每子态快照用### N. 子态名(source_image)编号子标题## 识别快照下一级符合 markdownlint MD001加粗在多子态里不够显眼。仓库实例见 随便观.md## 随便观-游历(实拍)下以###分级组织子态并标注source_image: screens/随便观/游历.webp( screens/随便观/游历-已派遣态.webp 已派遣态)。备注 / 待查与事实分开标注screen_info 现状缺口 / 误匹配隐患、开放问题待查、变更检测方法、易变点。不写bug/修复历史、不写测试状态。4. 缺口分析对照「匹配 area」与「可交互元素 / 识别特征」命中且 conf 高 → 已建模。模糊误匹配is_preciseFalse且命中无关 area→ 记隐患screen_info 该收紧 / 加精准特征。无匹配screens[]→ 先想兜底画面loading / 对话 等通用画面无固定文字特征但结构固定截图符合兜底结构loading 黑屏 lore tip / 对话下方对话框 好感度标题area→ 按兜底画面识别 建档不必精准 screen 匹配否则 screen_info 缺口画面未收录。仓库中已有docs/game/screens/对话.md、docs/game/screens/加载画面.md两个兜底画面建档成果见 docs/game/screens/README.md。可交互元素无对应 area → 进第 5 步建模。5. 主动建模图形 / 图标按钮文字按钮 OCR 多已覆盖无需此步。图形 / 图标按钮OCR 看不见按下面流程。状态指示图标radio 选中/未选中、下拉 ▽/△、勾选框同属此类 —— OCR 读不准状态用每态一个模板如 ▽ 收起 / △ 展开 适高阈值如 0.9区分状态design.md 实测各配自家 1.0、互不串。定位圆形 →cv2.HoughCircles扫 param2 / 半径取稳定命中数其它形状 → 轮廓 圆度4πA/P² 0.7或颜色阈值。两法互相印证。裁模板用项目TemplateInfo生成结构对齐既有模板raw.pngmask.pngconfig.ymltemplate_shape: circle/auto_mask: true/point_list: [圆心, 边缘点]。⚠️screen_image必须用原始截图PNG / 未压缩不要用 webp 归档版lossy → 小区域裁剪放大 artifacts → 模板 conf 降。入 screen_infoupsert_screen_area(screen_name, area_name, pc_rect[x1,y1,x2,y2], template_sub_dir, template_id, ...)对应 app.py 的工具签名pc_rect为 1080p 游戏坐标另有text/lcs_percent/template_match_threshold/color_range/goto_list/id_mark/gamepad_key等可选参数。area_name 用功能名中文template_id 用英文 snake_casepc_rect 模板 bbox每边 10px再夹到画面边界max(0,·)/min(1920,·)/min(1080,·)贴边时余量自动收窄项目编辑器约定「稍微比模板大一点」见devtools_screen_manage_interface相关实现防匹配大小/位移偏差且不重叠邻接按钮。回验再跑analyze_screen确认新 area 命中、conf 高。该步骤的动机来自实测design.md「打开游戏」画面右下角 4 个圆圈按钮OCR 只零碎识出一个C—— 文字按钮 OCR 覆盖图形按钮必须走「HoughCircles / 轮廓圆度定位 → TemplateInfo 裁模板 → upsert_screen_area 入 screen_info → analyze 回验」链路把「OCR 盲区」也建上模型。6. 归档代表截图onboarding 的画面都要归档一张代表截图多子态画面每子态一张到测试仓screens/screen_name/state.webp供后续测试 fixture 文档溯源。测试可用性归档 webp mock 测试 fixture归档截图要让 mock 测试能稳定用测试体系见 docs/develop/testing/README.md稳定态非过渡/动画帧操作后 sleep 等动画完再截底层 click/key_tap/drag 无内置等待截过渡帧 → mock 不稳定。覆盖该 screen 关键 area测试断言依赖的 id_mark / 文字 area 要在帧内 命中截完用analyze_screen回验目标 area 命中再归档。多子态每态一张测不同分支如游历的收获 / 派遣、入口的自动托管中 / 关闭。文件名 可读 statefixture 引用如游历-派遣中.webp非截图时间戳。写 mock 断言前先读 node 返回类型踩坑固化round_success/round_by_find_area命中判is_successround_wait/round_retry判status匹配词—— 先读 node 代码确认返回类型再写断言别照搬别的 apptrigrams_collection 照搬 scratch_card 的is_success失败因其主态返round_wait。通用断言判据已沉淀到 docs/develop/testing/README.md 第 3 节「断言:看 node 返回类型」。格式 路径webp q90有损压缩但整屏 OCR / 模板匹配实测识别无损效省空间/1080p 原生不缩放同 screen_info 坐标/文件名用可读 state 名如ready.webp/ screen_name 含冒号用下划线如警告_游戏前详阅。⚠️ webp 归档版不能当模板裁剪源小区域裁剪放大 artifacts → conf 降模板裁剪用原 PNG见第 5 步。⚠️路径是zzz-od-test/screens/screen_name/state.webp测试仓根screens/非test/screens/——conftest.load_screen读Path(__file__).parent.parent / screenszzz-od-test/screens/conftest.py在test/parent.parent zzz-od-test/。归档到test/screens/→ mock 测试找不到 fixture。doc 不写具体 webp 数如「22 张」—— 建档频繁加截图数字易过时不一致README / doc / screen 数处打架。写「实拍归档测试仓screens/name/」即可。归档后更新 docsource_image归档完把 frontmatter 各子态标题的source_image改成测试仓相对路径screens/screen/state.webp自描述可找含 screen 目录—— 不用临时截图名.debug/screenshot_xxx.png会被清、也不只写 state 名无 screen 目录、跨 screen 同名歧义。转换工具convert_to_webp.py用本 skill 目录的 convert_to_webp.pypython skills/zzz-od-dev-screen-onboarding/convert_to_webp.py 图片.png | 目录单张或目录批量不要手写转换逻辑易重复造轮子 漏 Windows 中文路径坑。该脚本支持python convert_to_webp.py 图片.png原地转 q90保留原 PNGpython convert_to_webp.py 目录批量原地转 q90python convert_to_webp.py 图片.png -o 目录转出到目录python convert_to_webp.py 图片.png -q 101指定质量默认 q90q101 无损精度 / OCR 敏感图可试底层用cv2.imencodendarray.tofile非cv2.imwrite—— Windows 中文路径会挂读取同理用np.fromfilecv2.imdecode见 convert_to_webp.py。脚本在输出已存在时会打印 ⚠️ 覆盖提醒提示归档覆盖前确认未被测试 fixture 引用。该脚本被内联进 SKILL.md 的原因design.md#2300 review 时 AI 见「见 design.md」没去读、手写了重复转换脚本把命令内联进 SKILL.md 可防漏读造轮子。覆盖检查防断测试归档时若目标screens/screen/state.webp会被覆盖已存在/ 要删旧图覆盖前先查该图是否被测试 fixture 引用—— 测试靠归档图做 mock 输入覆盖/删了会让 fixture 内容变断言失配或文件没测试找不到。判据覆盖/删/重命名 webp 前查测试仓里加载该 screen 归档图的位置测试代码读 fixture 的调用无引用 → 可覆盖/删有引用 → 用不同 state 名区分多态同 screen 各一张旧图确需替换则先改测试引用。实战记录design.mdonboard 式舆防卫战归档时删测试仓 3 个旧 webp新版同图重复 重命名 1 个Grep 确认这批无引用后才操作。收尾判据建档收尾时用以下判据自检每条都是踩坑固化的经验改动经工具MCP 直调 脚本CRUD 手编 yml稳定特征 易变值图形按钮 CV/模板 OCR。模板改名 / 加 area 涉及多文件目录、config、yml、合并缓存→ 一律经工具或同步合并缓存别只改一处 —— 这正是第 1 节「CRUD 手编」的底层原因save_screen会同步独立 yml _od_merged.yml合并缓存 reload见 screen_loader.py 与 screen_loader.py。落地与边界来自 design.md本 skill 落点在skills/zzz-od-dev-screen-onboarding/SKILL.mddesign.mdjunction 到.claude/skills/每人本地建不提交开发类前缀zzz-od-dev-项目开发流程与zzz-od-dev-deciding-a-fix等同列。其职责边界为管拿到截图后的离线分析 建档docs/game/screens/ 建模可交互元素模板 screen_info area。不管运行时识别框架 screen matching 自己跑gameplay 跨画面流程文档另成docs/game/gameplay/*.md本 skill 只管单画面整 screen 级 CRUD增删整个画面本 skill 只 area 级。整套方法论脱胎于「打开游戏」画面右下角 4 个图标按钮的实战后续经退出登录弹窗子态并入父 doc、账号确认态状态流转记录、大世界信息源三层、报刊亭/随便观手动分解截图、迷失之地建档文档只写事实等多次实战逐步补全 —— 每一步的「判据」都来自真实踩坑可直接复用于后续任何新画面的建档工作。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐绝区零 OneDragon 玩法建档指南基于 zzz-od-dev-gameplay-onboarding 的跨画面玩法文档方法论绝区零 OneDragon 玩法建档指南基于 zzz od dev gameplay onboarding 的跨画面玩法文档方法论 本指南围绕「绝区零 一条龙桌面应用RPA计算机视觉ZenlessZoneZero-OneDragon 端到端开发流程实战从画面建档、双仓测试到跨仓 PR 协同ZenlessZoneZero OneDragon 端到端开发流程实战从画面建档、双仓测试到跨仓 PR 协同 导读 本文档面向在 ZenlessZoneZer桌面应用RPA计算机视觉ZenlessZoneZero-OneDragon 快速开始指南从零搭建绝区零一条龙开发环境ZenlessZoneZero OneDragon 快速开始指南从零搭建绝区零一条龙开发环境 本文是「绝区零 一条龙」ZenlessZoneZero One桌面应用RPA计算机视觉上一篇CANN/hcomm组调用开始接口下一篇catlass ASWT策略说明创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
绝区零画面建档实战指南：ZenlessZoneZero-OneDragon 的 analyze → 建档 → 建模五步流程
桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载导读本文讲解 ZenlessZoneZero-OneDragon绝区零 一条龙项目中画面建档screen onboarding的完整方法论从拿到一张待建档的游戏截图开始如何按「客观识别 → 主观理解 → 建档 → 缺口分析 → 主动建模 → 归档」推进把画面事实沉淀为稳定的文档docs/game/screens/与可被识别器使用的模型screen_info area / 模板。读完本文你将掌握 MCP 工具直调的正确姿势、三层信息源并用的核对方法、手动分解操作抓取中间态画面的技巧以及把图形按钮从「OCR 盲区」建为 CV 模板的完整链路。本文主体来自 skills/zzz-od-dev-screen-onboarding/SKILL.md配套设计说明见同目录 design.md并辅以仓库源码逐条佐证。前置工具用法避免绕路建档的第一个坑是绕路。本 skill 明确要求MCP 工具直调mcp__zzz_od__analyze_screen/upsert_screen_area/delete_screen_area不要写 HTTP 客户端脚本绕路连接 stale 时让用户/mcp重连。设计文档记录了这条教训早期曾写过streamablehttp客户端脚本调 server其实mcp__zzz_od__*工具一开始就在工具列表里直调即可。screen_info 的 area 改动一律走 CRUD 工具upsert_screen_area/delete_screen_area—— 它们经save_screen同步独立 yml _od_merged.yml合并缓存 reload。禁止手编 screen_info yml 或手改模板目录手编不重算合并缓存daemon 按旧缓存加载 → 找不到模板/area。从源码看这一约束的底层原因是真实的。在 src/one_dragon/base/screen/screen_loader.py 中save()每次不仅把目标 screen 写回独立 yml还会把全部内置 screen 一并写入合并文件_od_merged.ymlmerge_yml_file_path见 screen_loader.py随后reload(from_memoryTrue)重新加载。只有走 CRUD 工具才能触发这条写独立 yml → 重算合并缓存 → reload的完整链路手编单个 yml 后合并缓存不会重算运行期加载到的仍是旧缓存。设计文档中记录的实例是改名模板时手编了enter_game.yml 重命名目录漏了_od_merged.ymldaemon 报「未找到模板」。MCP 工具本身定义在 src/zzz_od/backend/mcp/app.py其中与建档直接相关的有工具作用源码位置analyze_screen截图 OCR 画面匹配返回结构化结果app.pyupsert_screen_area插入/更新一个 area写 yml reloadapp.pydelete_screen_area删除一个 area写 yml reload不可逆app.pyclick_game/key_tap/drag点击坐标 / 键盘按键 / 拖拽手动复现操作app.py注意analyze_screen是只读工具不改游戏状态upsert/delete_screen_area是操作类工具后者在返回结构中带有action(inserted/updated/deleted)与area_count可用于确认改动生效。另一个边界本 skill 只记建档方法论具体游戏知识归对应文档 —— 传送流程/键位见 地图 / 3D地图玩法机制见 gameplay/本 skill 不记具体键位/流程/机制。建档规模先判「单画面 vs 重 app」拿到任务的第一步不是急着 analyze而是先判建档规模重 app 多子玩法1 app 调度多子 op、每子玩法独立画面 入口→子玩法→返回入口循环如随便观 7 子玩法→ 按app 维度建档而不是逐画面零散建档入口画面 各子玩法画面各自建档每画面独立 doc或同 doc 多子态app 编排节点链 / 分支 / 入口循环单独成develop docdocs/develop/zzz/application/app.md不进 screen doc玩法机制目标 / 资源 / 循环进gameplay doc此时触发zzz-od-dev-gameplay-onboardingskill 对玩法建档不在本 skill 内直接写玩法避免写成代码说明书跨画面 op 联动子 op 委托另一个 op如饮茶仙缺料 → 制造坊补料screen doc 记「跨画面流转入口」develop doc 记编排。判据app 有≥3 子玩法、各独立画面→ 重 app 维度单画面 / 独立 app 走常规五步流程。从仓库实际产物看这一维度判断已经被反复实践docs/game/screens/随便观.md即为典型的重 app 建档成果 —— 它把入口interact 狮耶 游历/制造坊/售卖铺/饮茶仙/邦巢/德丰大押/自动托管/经营总览 等 9 个子画面组织在同一文档体系内入口 状态流转、子画面全集表格、逐画面小节并与 7 个 screen_info yml入口游历/制造坊/售卖铺/饮茶仙/邦巢/德丰大押一一对应另有 3 个画面好物铺/自动托管/经营总览无 screen_info 待补。信息源理解画面三层并用截图只覆盖「当前帧看得到」的内容画面背后的结构信息要另外拉。建档前并读三层截图→analyze_screen客观 area/OCR第 1 步 vision主观布局/状态图标第 2 步。screen_infoassets/game_data/screen_info/screen_id.yml的area_list→ 该画面全部已建模元素含当前帧未显示的子态 area如弹窗按钮。每个 area 的text/template_id/pc_rect/goto_list/pc_alt/gamepad_key直接说明它是啥、点后跳哪、PC 端怎么点。analyze 只返回当前帧命中的 areascreen_info 才是全集。application/operation 代码src/zzz_od/application/app_id/→operation_node链 画面跳转与状态流转round_by_find_and_click_area/round_by_goto_screen调用 在哪画面点哪 area。对齐判据doc 的「可交互元素」「状态流转」要与 screen_infoarea_list 代码逐条对齐—— screen_info 有、doc 无 建档漏补上。截图没显示的子态 area先按 screen_info 代码记入流转、标「待现场快照」。这一层的方法论来自实战教训记录于 design.mdonboard「大世界」时 doc 漏写左上角「按钮-菜单」汉堡 ≡——normal_world_basic.yml的area_list本有此 area但它是纯坐标无 text/template不参与 analyze 匹配只看截图就漏了同期 onboard「邮件」靠读email.yml的 area_list email app 的operation_node链快速理清跳转。所以只看截图是不够的screen_info 与代码才是画面元素的全集来源。版本迁移核对老 app / 大版本更新后必查信息源三层之一是代码但代码可能落后于游戏版本故需核对 —— 游戏版本更新会改画面 / UI / 流程如随便观德丰大押 2.5 移除「百通宝 / 云纹徽」tab → op 点 tab 的代码失效成死代码。判据建档前核对 op 代码假设的画面元素tab / 按钮 / 流程在当前游戏版本还在吗—— 不假设「代码 当前游戏」。发现不符① doc 记版本差异 标「代码与当前版本不符」② 搜官方更新说明确认改动版本③ app 层若有占位短路如handle_xxx直返「未开启」说明已知情标「待重写」。教训德丰大押 op 基于 2.4、2.5 tab 移除靠用户观察 搜官方说明才发现 —— 代码默认有效是建档盲区。截图获取手动分解动作不靠跑 app 中途跑 apprun_standalone_app/ 跑单个 oprun_operation中途capture抓不到中间态—— op 执行快、且会自动消费中间画面如确认弹窗被 op 自己点掉sleep 完再 capture 只能看到 op 跑完的结果如落地入口抓不到中间弹窗如传送后的「自动进入交互」确认。判据app/op 内部连续动作transport→move→interact→drag→…→各弹窗产生的画面按 op 的operation_node节点逻辑手动分解成单步—— 读 op 代码每步一个click_game/key_tap/dragcapture逐步截图在 op 会自动点的弹窗处停下、手动不点、先 capture。跑 app /run_operation只用于「验证流程通」或「到位」不用于抓中间态画面。transport 复现transport 后角色朝向传送后角色朝向继承传送前若传送前已在同一地图。app 常假设 transport 后固定朝向来move_winteract手动复现时先传送去别的地图、再传送回目标地图朝向即重置到默认。补档先读 app/operation 代码 move 距离一致手动复现前先读src/zzz_od/application/app/的operation_node链弄清 transport→move→interact 的具体动作move_wpress_timeturn_to_angleinteract 哪个 NPC按 app 的距离 / 对象复现 —— 别只靠 vision 推朝向 / 距离。判据手动key_tap w的press_time要和 app 的move_w一致如coffee/random_playPOINT_1 是turn_to_anglemove_w 1ssuibian_temple无 move 就不走传送点已在交互范围走多了反而错过交互点角色过头提示消失。Transport 失败排查run_operation Transport失败尤其「执行传送」节点卡 OCR 地图、重试到超时常见根因是目标传送点未解锁 该地图未探索新版本玩法 / 新城区需先跑图解锁传送点其他地图同理。判据Transport 打开了地图但选不中目标点 → 先确认目标地图已探索、传送点已解锁否则换已解锁的 app 建档。仓库里「吼吼饼铺」即为此例骨架已建信息源三层但 ⚠️ Transport 卡 3.0 布亚斯特城区未探索截图待补见 docs/game/screens/README.md。操作时序操作后等动画再 capture否则截过渡帧底层click_game/key_tap/drag无内置等待等待在框架 operation round 层success_waitMCP 不经 round。MCP 工具文档也明确写了这一条 —— 例如 app.py 中click_game的说明「操作后建议 sleep底层 click 无内置等待点 UI 常触发画面切换连续操作或capture_game_screen前建议 sleep ~1s 等动画否则截过渡帧」key_tap 同样提醒「移动 wasd ~1s 等角色到位不等就 interact 可能失效、交互 f ~1-2s 进场景/对话、esc ~0.5s 开关菜单」。操作后画面/角色变化需 sleep 再capture。关键 sleep 点move 后等角色到位不等就紧接 interact 会失效interactF长按press_time0非短按 tap。sleep 建议值click ~1s / move ~1s / interact 1-2s / esc ~0.5s / drag ~0.5s。边缘状态态依赖游戏条件 → 人机协作很多状态态会话内创造不了—— 需游戏特定条件游历到期 / 材料不足 / 持有上限 / 刷新出稀有。判据状态态依赖「资源消耗 / 时间 / 随机」而非「导航可达」→ 标「待条件」别硬刷随机态如稀有掉落刷了空跑消耗态如材料不足在资源充足时不出现。处理① doc 标「待条件」 已拍的核心态先归档②请用户帮切用户能调游戏状态造条件比智能体盲操作高效③ 后续会话条件出现时补。教训随便观 B 类游历收获 / 饮茶缺料 / 邦巢持有上限全靠用户帮切 4 画面才补全。1. 客观识别跑analyze_screenanalyze_screen(screenshot绝对路径 或 .debug/images 图名)取三样对应 app.py 的返回结构AnalyzeScreenResult匹配画面screens[].screen_nameis_precise精准 / 模糊 / 无匹配。匹配 areascreens[].areasarea_name / 类型text|template/ 文本或template_id/ conf / 位置。全量 OCRocr_texts全部文字含噪声/动态值。area 维护的文字可能不全 → 全量 OCR 是权威文本源与匹配 area 的文字重叠属正常勿去重。工具支持三种输入不传screenshot 实时截当前画面需游戏在线传绝对路径 读指定图无需游戏在线传纯名字 读.debug/images/名字.png。离线模式不回写识别状态适合做「离线校验 / 反哺 screen_info」—— 这正是建档场景的常态拿一张截图分析不打扰游戏运行。2. 主观理解多模态 vision 看图必需不只靠 MCP必须用多模态大模型 / 工具看图analyze_image/ vision不能只靠 MCPanalyze_screen的 OCR / area—— OCR 看不见图形 / 图标按钮、布局结构、状态图标选中态 / 已读 / 可领、模态性遮罩、角色朝向 / 场景类型。每张建档截图都要 vision 看一遍漏看会导致元素、画面边界或状态判断不完整。vision 调用失败如 400必须重试换图重传 / 重新 capture不能跳过。设计文档的实测反面scratch_card 刮态 vision 400 没重试就跳过 → doc 漏刮层布局细节。若用户给了画面相关提示向 vision 提偏向该类画面典型元素的问题判据是提示指向某类画面 → 问该类的典型可交互元素 状态文本而非泛泛「描述画面」无提示 → 通用问布局 / 可交互元素 / 文字 / 图标 / 当前状态 / 模态性。明确区分可交互元素按钮 / 输入 / 图标与展示信息。vision 状态推理不可信只信客观描述踩坑固化vision 不懂游戏 —— 它「描述画面有什么」元素 / 文字 / 标记 / 颜色 / 位置 / 布局可信但「判断状态 / 作用」已派遣 / 未派遣、按钮作用、是否可点不可信会基于看到的文字瞎猜。prompt 要客观描述「有哪些文字 / 按钮 / 图标各自位置(x,y)哪个元素有三角形 / 高亮 / 颜色标记」别问状态推理状态判断结合代码自己做如choose_period检测「提前收获」已派遣 / 检测 duration选时间预览而非靠 vision 看「剩余时间」猜已派遣 —— 那个时间可能只是选时预览不是进行中倒计时。可交互对象判据名字绝区零 NPC / 交互对象进入可交互范围时名字左右出现三角形标记如 狮耶 出现即在交互范围interact F即可不需再走。⚠️ OCR 常只识出名字漏了符号vision 也不懂这约定 → 双双误判「没到还要走」。判据画面出现 NPC 名字 app 假设该位置可交互 → 直接试key_tap fF 实际选中的对象看结果画面F 提示文本未必是 F 实际交互对象如 F 提示小贩但实际 interact 了狮耶vision 提示词要明确「可交互对象名字左右有三角形出现即已可交互不要再走」。角色朝向/视角判据vision 盲区vision 对朝向 / 视角推断不可信 —— 本游戏是第 3 人称追尾视角看到角色背部 角色正对前方vision 会误判「背对」差点误导走「跨地图朝向重置」弯路design.md 记录suibian_temple 入口建档时 vision 判「角色背对随便观入口」实际摄像机在主角身后。判据朝向以 OCR 交互提示如「前往 XX」 实际 interact 结果为最终判据别轻信 vision 的朝向推断。3. 建档先判独立画面还是已建档画面的子态模态/弹窗/状态如对话框、loading/ready 子态独立画面→ 新建docs/game/screens/name.md中文screen_name文件名英文 snake_case、不带冒号等特殊字符登记进 docs/game/screens/README.md 索引一行。子态→ 并进父画面 doc「何时出现/状态流转」补该子态的入口从哪来 出口动作→下一态、「可交互元素」补该态元素、「识别快照」加该态子表不另开文件、不登索引。建档文档 稳定的画面参考事实不是建档过程的日志。描述类章节何时出现/状态流转/识别特征/可交互元素/识别快照只写画面本身的事实长啥样/元素/识别/流转建档/排查过程的产物不混入不进 doc① 测试结果通过/失败 —— 测试归zzz-od-testdoc 不跟踪测试状态② bug/修复历史「原 bug...现已修」归 commit/PRdoc 只写现状。进「备注」并与事实分开开放问题如某元素触发条件未知、screen_info 现状缺口、易变点。判据每句问「这是画面本身的事实还是建档/排查过程的产物」后者不进描述章节。design.md 记录的实例onboard 迷失之地战斗失败时把「✅ 两种布局均识别 GREEN」测试结果、「原 bug...现已修」修复历史混进了画面描述稳定事实被淹没doc 变得像排查日志后续已清理。新画面 doc 结构frontmatterscreen_name/appears_in: [gameplay_name...]/last_updated核对日期/source_image归档后用测试仓相对路径screens/screen/state.webp—— 自描述可找含 screen 目录无跨 screen 歧义归档前可暂记.debug基线图名归档后更新为完整路径别留临时截图名 / 只写 state 名。仓库实例见 随便观.md 的 frontmatterscreen_name: 随便观、appears_in: [随便观经营]、source_image: screens/随便观/入口-手动态.webp。何时出现 状态流转出现条件 前后邻居多子态画面必须记状态流转每子态入口 从哪来[动作/条件]、出口 动作→下一态用表格或链式表达。识别特征稳定锚点稳定文字 / 模板图标 / 固定图标标注易变值版本号 / 进度 / 公告勿当特征。可交互元素按钮 / 输入 / 图标图形按钮注明「需模板/CV」。识别快照 ① 匹配画面screen_name is_precise② 匹配 area 表area_name / 类型 / 文本或 template_id / conf / 位置③ 全量 OCR 文本。多子态画面的每子态快照用### N. 子态名(source_image)编号子标题## 识别快照下一级符合 markdownlint MD001加粗在多子态里不够显眼。仓库实例见 随便观.md## 随便观-游历(实拍)下以###分级组织子态并标注source_image: screens/随便观/游历.webp( screens/随便观/游历-已派遣态.webp 已派遣态)。备注 / 待查与事实分开标注screen_info 现状缺口 / 误匹配隐患、开放问题待查、变更检测方法、易变点。不写bug/修复历史、不写测试状态。4. 缺口分析对照「匹配 area」与「可交互元素 / 识别特征」命中且 conf 高 → 已建模。模糊误匹配is_preciseFalse且命中无关 area→ 记隐患screen_info 该收紧 / 加精准特征。无匹配screens[]→ 先想兜底画面loading / 对话 等通用画面无固定文字特征但结构固定截图符合兜底结构loading 黑屏 lore tip / 对话下方对话框 好感度标题area→ 按兜底画面识别 建档不必精准 screen 匹配否则 screen_info 缺口画面未收录。仓库中已有docs/game/screens/对话.md、docs/game/screens/加载画面.md两个兜底画面建档成果见 docs/game/screens/README.md。可交互元素无对应 area → 进第 5 步建模。5. 主动建模图形 / 图标按钮文字按钮 OCR 多已覆盖无需此步。图形 / 图标按钮OCR 看不见按下面流程。状态指示图标radio 选中/未选中、下拉 ▽/△、勾选框同属此类 —— OCR 读不准状态用每态一个模板如 ▽ 收起 / △ 展开 适高阈值如 0.9区分状态design.md 实测各配自家 1.0、互不串。定位圆形 →cv2.HoughCircles扫 param2 / 半径取稳定命中数其它形状 → 轮廓 圆度4πA/P² 0.7或颜色阈值。两法互相印证。裁模板用项目TemplateInfo生成结构对齐既有模板raw.pngmask.pngconfig.ymltemplate_shape: circle/auto_mask: true/point_list: [圆心, 边缘点]。⚠️screen_image必须用原始截图PNG / 未压缩不要用 webp 归档版lossy → 小区域裁剪放大 artifacts → 模板 conf 降。入 screen_infoupsert_screen_area(screen_name, area_name, pc_rect[x1,y1,x2,y2], template_sub_dir, template_id, ...)对应 app.py 的工具签名pc_rect为 1080p 游戏坐标另有text/lcs_percent/template_match_threshold/color_range/goto_list/id_mark/gamepad_key等可选参数。area_name 用功能名中文template_id 用英文 snake_casepc_rect 模板 bbox每边 10px再夹到画面边界max(0,·)/min(1920,·)/min(1080,·)贴边时余量自动收窄项目编辑器约定「稍微比模板大一点」见devtools_screen_manage_interface相关实现防匹配大小/位移偏差且不重叠邻接按钮。回验再跑analyze_screen确认新 area 命中、conf 高。该步骤的动机来自实测design.md「打开游戏」画面右下角 4 个圆圈按钮OCR 只零碎识出一个C—— 文字按钮 OCR 覆盖图形按钮必须走「HoughCircles / 轮廓圆度定位 → TemplateInfo 裁模板 → upsert_screen_area 入 screen_info → analyze 回验」链路把「OCR 盲区」也建上模型。6. 归档代表截图onboarding 的画面都要归档一张代表截图多子态画面每子态一张到测试仓screens/screen_name/state.webp供后续测试 fixture 文档溯源。测试可用性归档 webp mock 测试 fixture归档截图要让 mock 测试能稳定用测试体系见 docs/develop/testing/README.md稳定态非过渡/动画帧操作后 sleep 等动画完再截底层 click/key_tap/drag 无内置等待截过渡帧 → mock 不稳定。覆盖该 screen 关键 area测试断言依赖的 id_mark / 文字 area 要在帧内 命中截完用analyze_screen回验目标 area 命中再归档。多子态每态一张测不同分支如游历的收获 / 派遣、入口的自动托管中 / 关闭。文件名 可读 statefixture 引用如游历-派遣中.webp非截图时间戳。写 mock 断言前先读 node 返回类型踩坑固化round_success/round_by_find_area命中判is_successround_wait/round_retry判status匹配词—— 先读 node 代码确认返回类型再写断言别照搬别的 apptrigrams_collection 照搬 scratch_card 的is_success失败因其主态返round_wait。通用断言判据已沉淀到 docs/develop/testing/README.md 第 3 节「断言:看 node 返回类型」。格式 路径webp q90有损压缩但整屏 OCR / 模板匹配实测识别无损效省空间/1080p 原生不缩放同 screen_info 坐标/文件名用可读 state 名如ready.webp/ screen_name 含冒号用下划线如警告_游戏前详阅。⚠️ webp 归档版不能当模板裁剪源小区域裁剪放大 artifacts → conf 降模板裁剪用原 PNG见第 5 步。⚠️路径是zzz-od-test/screens/screen_name/state.webp测试仓根screens/非test/screens/——conftest.load_screen读Path(__file__).parent.parent / screenszzz-od-test/screens/conftest.py在test/parent.parent zzz-od-test/。归档到test/screens/→ mock 测试找不到 fixture。doc 不写具体 webp 数如「22 张」—— 建档频繁加截图数字易过时不一致README / doc / screen 数处打架。写「实拍归档测试仓screens/name/」即可。归档后更新 docsource_image归档完把 frontmatter 各子态标题的source_image改成测试仓相对路径screens/screen/state.webp自描述可找含 screen 目录—— 不用临时截图名.debug/screenshot_xxx.png会被清、也不只写 state 名无 screen 目录、跨 screen 同名歧义。转换工具convert_to_webp.py用本 skill 目录的 convert_to_webp.pypython skills/zzz-od-dev-screen-onboarding/convert_to_webp.py 图片.png | 目录单张或目录批量不要手写转换逻辑易重复造轮子 漏 Windows 中文路径坑。该脚本支持python convert_to_webp.py 图片.png原地转 q90保留原 PNGpython convert_to_webp.py 目录批量原地转 q90python convert_to_webp.py 图片.png -o 目录转出到目录python convert_to_webp.py 图片.png -q 101指定质量默认 q90q101 无损精度 / OCR 敏感图可试底层用cv2.imencodendarray.tofile非cv2.imwrite—— Windows 中文路径会挂读取同理用np.fromfilecv2.imdecode见 convert_to_webp.py。脚本在输出已存在时会打印 ⚠️ 覆盖提醒提示归档覆盖前确认未被测试 fixture 引用。该脚本被内联进 SKILL.md 的原因design.md#2300 review 时 AI 见「见 design.md」没去读、手写了重复转换脚本把命令内联进 SKILL.md 可防漏读造轮子。覆盖检查防断测试归档时若目标screens/screen/state.webp会被覆盖已存在/ 要删旧图覆盖前先查该图是否被测试 fixture 引用—— 测试靠归档图做 mock 输入覆盖/删了会让 fixture 内容变断言失配或文件没测试找不到。判据覆盖/删/重命名 webp 前查测试仓里加载该 screen 归档图的位置测试代码读 fixture 的调用无引用 → 可覆盖/删有引用 → 用不同 state 名区分多态同 screen 各一张旧图确需替换则先改测试引用。实战记录design.mdonboard 式舆防卫战归档时删测试仓 3 个旧 webp新版同图重复 重命名 1 个Grep 确认这批无引用后才操作。收尾判据建档收尾时用以下判据自检每条都是踩坑固化的经验改动经工具MCP 直调 脚本CRUD 手编 yml稳定特征 易变值图形按钮 CV/模板 OCR。模板改名 / 加 area 涉及多文件目录、config、yml、合并缓存→ 一律经工具或同步合并缓存别只改一处 —— 这正是第 1 节「CRUD 手编」的底层原因save_screen会同步独立 yml _od_merged.yml合并缓存 reload见 screen_loader.py 与 screen_loader.py。落地与边界来自 design.md本 skill 落点在skills/zzz-od-dev-screen-onboarding/SKILL.mddesign.mdjunction 到.claude/skills/每人本地建不提交开发类前缀zzz-od-dev-项目开发流程与zzz-od-dev-deciding-a-fix等同列。其职责边界为管拿到截图后的离线分析 建档docs/game/screens/ 建模可交互元素模板 screen_info area。不管运行时识别框架 screen matching 自己跑gameplay 跨画面流程文档另成docs/game/gameplay/*.md本 skill 只管单画面整 screen 级 CRUD增删整个画面本 skill 只 area 级。整套方法论脱胎于「打开游戏」画面右下角 4 个图标按钮的实战后续经退出登录弹窗子态并入父 doc、账号确认态状态流转记录、大世界信息源三层、报刊亭/随便观手动分解截图、迷失之地建档文档只写事实等多次实战逐步补全 —— 每一步的「判据」都来自真实踩坑可直接复用于后续任何新画面的建档工作。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐绝区零 OneDragon 玩法建档指南基于 zzz-od-dev-gameplay-onboarding 的跨画面玩法文档方法论绝区零 OneDragon 玩法建档指南基于 zzz od dev gameplay onboarding 的跨画面玩法文档方法论 本指南围绕「绝区零 一条龙桌面应用RPA计算机视觉ZenlessZoneZero-OneDragon 端到端开发流程实战从画面建档、双仓测试到跨仓 PR 协同ZenlessZoneZero OneDragon 端到端开发流程实战从画面建档、双仓测试到跨仓 PR 协同 导读 本文档面向在 ZenlessZoneZer桌面应用RPA计算机视觉ZenlessZoneZero-OneDragon 快速开始指南从零搭建绝区零一条龙开发环境ZenlessZoneZero OneDragon 快速开始指南从零搭建绝区零一条龙开发环境 本文是「绝区零 一条龙」ZenlessZoneZero One桌面应用RPA计算机视觉上一篇CANN/hcomm组调用开始接口下一篇catlass ASWT策略说明创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
