企业官网建设流程全解析

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

导读

本文以《绝区零一条龙（ZenlessZoneZero-OneDragon）》仓库的画面描述文档加载画面为主体，系统梳理登录流程中"lore 加载过渡"画面的出现时机、识别特征与 OCR 实测数据，并深入对应源码解释该画面故意不收录进 screen_info（screens=[]）的设计决策——即"无可固定匹配特征 → 有意的缺口，非遗漏"。读完本文，你将理解项目画面识别体系的工作方式：文本区域如何通过 LCS 匹配、模板区域如何匹配、id_mark精准命中与模糊候选如何分工，以及为什么动态轮换内容无法成为可靠的识别锚点。

画面是什么：登录成功后的 lore 加载过渡

原文档对该画面的定位非常明确：

登录成功后 →本画面→ 大世界/主菜单。游戏内的通用加载画面，每次加载时出现。

也就是说，它出现在"打开游戏 → 登录成功"与"大世界/主菜单"之间，是游戏每次加载场景时都会经过的通用过渡画面。画面构成是固定的两栏式布局：

• 左侧 lore 区域：标题（如【港口工厂旧址】）+ 一段世界观描述文字。这部分是动态轮换的世界观 tip（World Lore Tip，类似原神/星铁加载界面的小知识），每次加载都可能不同；
• 右侧场景插画：静态插画，与当前 lore 标题对应（如港口工厂旧址的场景图）。

识别特征：稳定锚点与不可靠特征

原文档的"识别特征（稳定锚点）"一节是建模思路的核心，它明确区分了哪些内容可以当特征、哪些不能：

可交互元素：无。该画面是纯过渡加载画面，没有任何按钮或可点击区域，自动推进到下一画面。这意味着它不存在"点击某区域 → 跳转"的路由边（goto_list），也无法通过交互行为被利用。

识别快照（2026-07-06 核对）

原文档记录了 2026-07-06 的实测识别快照（识别快照 ID_1783247956712），其中关键结论是：

• 匹配画面：无（screens=[]，未被 screen_info 收录）；
• 该次快照对应的 lore 文本为「港口工厂旧址」，OCR 实测数据如下：

这份 OCR 数据恰好印证了前面的分析：整屏能 OCR 出的文本要么是动态 lore 内容，要么是通用的 UID 标签，没有任何一段固定、唯一的文字可作为画面判定的稳定锚点。

与loading.yml（加载中/NOW LOADING）的区分

原文档备注中专门澄清了本项目另一份易混淆的配置——assets/game_data/screen_info/loading.yml：

screen_id: loading screen_name: 加载中 pc_alt: false area_list: - area_name: 加载中 id_mark: false pc_rect: - 1161 - 724 - 1929 - 1055 text: NOW LOADING lcs_percent: 0.5 template_sub_dir: '' template_id: '' template_match_threshold: 0.7 color_range: null goto_list: []

loading.yml建立的是显示NOW LOADING文字的那个加载态（识别区域位于屏幕右下，pc_rect为[1161, 724, 1929, 1055]，即 (x1,y1,x2,y2) 坐标系）；而本文所述的 lore 加载画面没有NOW LOADING文字，因此screens=[]匹配不上loading.yml。文档同时注明：loading.yml的实际用途待确认，暂忽略。这两者虽都叫"加载"，但在本项目画面体系中是两个不同的画面，不可混用。

源码视角：screen_info 体系如何加载与匹配

要理解"为何故意不建 screen_info"，需要先了解本项目画面识别的底层机制。

ScreenInfo 配置结构与解析

assets/game_data/screen_info/目录下的每个 YAML 对应一个画面（screen_id），由 screen_info.py 中的ScreenInfo类解析。每个画面由若干area_list区域组成，区域的关键字段包括：

• pc_rect：PC 端区域矩形（x1,y1,x2,y2）；
• text+lcs_percent：文本区域的期望文字与 LCS 相似度阈值（默认 0.5，见解析代码data_area.get('lcs_percent', ...) else 0.5）；
• template_sub_dir+template_id+template_match_threshold：模板匹配子目录、模板 ID 与匹配阈值（默认 0.7）；
• id_mark：是否为该画面的"精准标识"区域；
• goto_list：点击该区域后可跳转的目标画面（路由边）。

配置文件由 screen_loader.py 的ScreenContext.reload()加载进内存，支持三种来源：内存、分离文件（assets/game_data/screen_info/*.yml）与合并文件_od_merged.yml；加载完成后会基于各区域goto_list构建画面路由，并用类 Floyd 算法算出任意两画面间的最短路径（见 screen_loader.py）。

区域匹配的两种路径

screen_match.py 的find_area_with_detail描述了单区域匹配逻辑：

• 文本区域（is_text_area）：对区域矩形内做 OCR，再用str_utils.find_by_lcs以lcs_percent阈值做最长公共子序列（LCS）相似度匹配——这正是 lore 动态文字的问题所在：【港口工厂旧址】、【某某某】每次都在变，无法用固定text去命中；
• 模板区域（is_template_area）：调用ctx.tm.crop_and_match_template，把截取区域与template_sub_dir/template_id指定的模板图做匹配，阈值template_match_threshold。加载画面的右侧插画随 lore 轮换，同样没有固定模板图可用。

画面级匹配：精准早停 + 模糊候选

find_screen_matches（screen_match.py）在画面级别做分级匹配：

• 遍历顺序优先从current/last画面出发做 BFS 扩散（利用goto_list路由图），无起点时才全量遍历；
• 遇到id_mark全中的画面即精准命中早停，返回is_precise=True；
• 若无精准命中，则按命中区域数取 top_n（默认 5）模糊候选，is_precise=False。

而本项目对加载画面完全没有注册任何id_mark区域或固定text区域——因此它在任何一轮匹配中都只会是"模糊候选"甚至完全不命中，这正是原文档强调screens=[]是有意缺口的原因。

为什么故意不建 screen_info：动态内容的建模边界

原文档"备注"一节把决策理由讲得很透彻，这是全文的结论性内容：

故意不建 screen_info：本画面无可固定的匹配特征（lore 文字轮换 + 场景插画随 tip 变化 + 无固定按钮/文字锚点）→ 不适合做 screen_info 模板/文本 area。screens=[]是有意的缺口，非遗漏。

结合源码可以进一步解释这条决策的正确性：

1. 文本锚点不存在：OCR 结果只有轮换的 lore 标题/描述 + 通用 UID，若强行把【港口工厂旧址】写进 area，LCS 匹配（find_by_lcs）在下一张 lore（如【莱姆尼安空洞】）出现时必然失配；
2. 模板锚点不存在：右侧插画每张 lore 对应不同场景图，无法在assets/template里为"所有加载插画"维护一个统一模板；
3. 无交互、无路由价值：画面无按钮、无goto_list，即使在路由图中注册，也没有任何"点击该区域前往 X"的边可以形成；
4. 状态机不需要它：加载过渡是自动推进的，自动化流程只需要"等待其消失/等待目标画面出现"，而非"识别它并做操作"。

从仓库的整体画面索引 docs/game/screens/README.md 也可看到，加载画面被归类为"通用兜底画面"（无固定文字特征），与「对话」画面并列，这类画面的建档策略就是：文档建档说明其边界，但不为其建立 screen_info 匹配模板。

实际运行与后续维护建议

对于运行期而言，加载画面"不被匹配"是符合预期的正常状态：登录流程中，自动化逻辑依赖的稳定锚点是登录页（如 assets/game_data/screen_info/enter_game.yml 中"点击进入游戏"等固定文本区域）和登录成功后的大世界画面；lore 加载画面作为纯过渡，只需等待其自然结束。后续维护时若想在文档中补充更多 lore 快照，保持"不新增 screen_info"的决策即可，除非游戏后续为加载画面引入了固定 UI 元素（例如固定的进度条、固定文案或按钮），那时才具备建模前提。

小结

绝区零一条龙的加载画面建档，是一次典型的"识别边界"决策示范：不是所有游戏画面都值得/能够建立 screen_info。lore 文字轮换 + 场景插画变化 + 无交互锚点，使该画面天然无法被 OCR 文本匹配或模板匹配稳定命中，因此项目以文档形式记录其识别特征与 OCR 数据、明确screens=[]是有意缺口，同时保留loading.yml（NOW LOADING 加载态）作为另一条独立的加载识别路径。理解这一取舍，有助于读者在为本项目新增画面建档时正确判断：画面是否存在固定、唯一、可重复命中的文字或模板特征，以及该画面是否具备交互/路由价值。

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