企业官网建设流程全解析

• 桌面应用
• RPA
• 计算机视觉

本篇技术指南聚焦 ZenlessZoneZero-OneDragon（绝区零一条龙）自动化框架中的游戏启动序列画面之一——「绝区零标题页」（游戏 Logo 展示页）。文章基于 画面描述文档，完整还原该画面的出现时机、识别特征与 OCR 识别快照，并结合仓库源码说明它在启动流程中的位置、screen_info建模缺口以及analyze_screen变更检测工作流。读完本文，你将掌握如何为这类"纯展示、无按钮、OCR 不可靠"的过渡画面设计稳定的识别锚点，并能直接复用本文方法补全画面描述与 screen_info 模型。

画面定位：启动序列中的第三站

在绝区零一条龙的自动化启动流程中，游戏从进程拉起到大世界登录，依次经过以下画面（参见 画面描述索引 中的"打开游戏首个画面 / 登录前"条目）：

1. 米哈游启动页：打开游戏后的第一个画面，品牌 + 合规展示，无操作自动跳过（见 米哈游启动页.md）；
2. 警告:游戏前详阅：光敏性癫痫警告页，纯文字展示，无按钮（见 警告_游戏前详阅.md）；
3. 绝区零标题页（本文主题）：游戏 logo 展示页，展示数秒或点击后进入登录；
4. 打开游戏（登录页）：真正的登录画面，含 loading / ready / 手动登录 / 选区服等多个子态，已在enter_game建模（见 打开游戏.md 与 enter_game.yml）。

标题页的出现时机是：打开游戏后，「警告:游戏前详阅」之后、登录「打开游戏」之前的游戏标题 / logo 展示页。它与前两页一样是纯展示过渡页，展示数秒（或点击）后自动进入登录。该画面在文档中标注appears_in: [游戏启动]、last_updated: 2026-07-05、source_image: screens/绝区零标题页/默认.webp。

识别特征：稳定锚点与不可靠的英文艺术字

画面描述文档给出了两条候选特征，并明确区分了可靠性：

• 中文标题绝·区·零：位于@(827,691,268×76)，画面下方居中（艺术字）。这是推荐使用的稳定锚点；
• 英文游戏名ZENLESS ZONE ZERO：位于下方（艺术字），OCR 会误识成ZRNLESS ZONE ZRrO，不可靠。

文档结论：用中文标题绝·区·零或 logo 图像（模板匹配）做特征；英文艺术字 OCR 不稳，别依赖。

这一点与相邻画面文档的识别经验完全一致：在 米哈游启动页.md 中，miHoYo logo 与标语TECH OTAKUS SAVE THE WORLD是稳定锚点，而底部合规文字"易变、且会误匹配「菜单」"；在 警告_游戏前详阅.md 中，标题警告:游戏前详阅是精准特征，正文长句则因命中登录页 area 而不可用。"图形化大字 + 长文本段落不可靠"是本仓库画面识别实践中反复验证的规律：OCR 对艺术字、图形字的误识率远高于规整 UI 文字，因此这类画面的识别锚点应优先选择中文字面特征或图像模板。

可交互元素：无按钮的过渡页

文档明确记录：无明显按钮（OCR 未识别到）——推测自动推进或点击继续，待确认。

这意味着自动化处理该画面时，不能依赖"找到按钮并点击"的操作模式，而应走等待 / 轮询超时跳过的策略——这与 米哈游启动页.md（"自动化靠等待 / 轮询超时跳过，不点击"）和 警告_游戏前详阅.md（"纯展示过渡页，自动化靠等待 / 轮询超时跳过"）的处理方式一致。从源码结构看，EnterGame操作（见 enter_game.py）通过check_screen/check_login_related等轮询式 round 逻辑逐画面推进，过渡页不会触发任何点击分支，仅作为流程中的状态观测点。

识别快照：2026-07-05 核对的 OCR 全量结果

文档记录了使用analyze_screen核对后的完整快照（analyze_screen是 MCP 提供的画面识别工具，返回匹配画面 / 匹配 area / 全量 OCR 的结构化结果，见 mcp.md）：

匹配画面：无（screens=[]，未被任何 screen_info 收录）匹配 area：无

OCR 文本（全量）：

快照的两个关键事实：其一，整个画面 OCR 仅产出两行文本，属于"低文本密度"画面，识别信息量有限；其二，全量 OCR 中没有任何按钮文案，佐证了"无明显按钮"的结论。同时screens=[]表明连模糊匹配都没有命中任何已收录画面，说明该页面与现有 screen_info 模型（如打开游戏、菜单等）之间不存在共享 area 导致的跨画面误匹配，这是与本序列中另外两个过渡页（米哈游启动页误匹配「菜单」、警告页误匹配「打开游戏」）的不同之处。

screen_info 缺口与建模建议

文档明确指出当前状态：screen_info 缺口——screens:[]（连模糊匹配都没有），assets/game_data/screen_info/下没有对应的「绝区零标题页」条目（对比已建模的 enter_game.yml 与 loading.yml）。

补 screen_info 的推荐方案（文档原话）：

• 用中文标题绝·区·零做 text area 特征；
• 或用logo 模板图做 template area 特征（与enter_game中switch_account/settings/announcement等图标按钮采用template_sub_dir: enter_game+template_id的做法同构，参见 enter_game.yml 中"右边沿 4 个图标按钮"用传统 CV（HoughCircles）定位 + 裁模板建 template area 的先例）。

按 docs/game/README.md 的记录规范，画面文档与assets/game_data/screen_info/<name>.yml一一对应、双向引用，因此补建模时应同步在画面文档中登记新 screen_name，并维持 frontmatter 的appears_in/last_updated/source_image字段。

变更检测与文档维护工作流

文档给出明确的维护方法（与 development_workflow.md 中"截图 →analyze_screen客观识别（匹配画面 / area / 全量 OCR）"的流程一致）：

1. 重新截一张本画面；
2. 跑analyze_screen与上方快照 diff；
3. 由于 logo 极少变，画面特征基本稳定；若界面变化，则更新快照 +last_updated/source_image字段。

截图文件名为一次性捕获 ID、易失，正文绝不写死具体 ID（见 docs/game/README.md 规范第 4 条）；基线截图统一使用可读命名的 webp 归档。变更复核的边界在于：标题页 logo 极少变化，真正需要关注的变量是版本号随 build 变化（如登录页CNPRODWin3.0.0_R17093596_S170935）以及可能随合规调整的正文措辞——但标题页几乎无正文文字，所以维护重心就是确认绝·区·零中文标题仍在原位、未被游戏更新改动。

小结：一类过渡页的通用识别方法论

「绝区零标题页」是启动序列中三类"纯展示过渡页"的典型代表，从它的画面文档可以提炼出通用方法论：

• 识别锚点选型：优先中文大字 / logo 模板，规避艺术字英文 OCR 误识；
• 交互策略：无按钮画面不做点击，走等待 / 轮询超时；
• 建模优先级：screens=[]缺口画面在补建模时，用文字 area 或 template area 建立专属特征，避免与其他画面共享长文本导致的模糊误匹配；
• 维护节奏：通过analyze_screen快照 diff 做变更检测，仅更新last_updated/source_image，正文不写死一次性截图 ID。

如需继续深入，可对照阅读 打开游戏.md（同一启动序列中已建模、多子态的登录页）、画面描述索引（全部画面文档总览）以及 enter_game.yml（已建模画面的 area 结构参考）。

• 桌面应用
• RPA
• 计算机视觉