dc-docs/output/feishu-docs/EIWNwKjnIipmStkzIr1cd1kTnPf.md

EIWNwKjnIipmStkzIr1cd1kTnPf

Source: https://dianchukeji.feishu.cn/wiki/EIWNwKjnIipmStkzIr1cd1kTnPf

一.工作内容概述

• 尝试优化AI自动化关卡生成逻辑
• 尝试优化自动化关卡截图分析流程
• 体验《佛系消消消》，补充收集部分关卡样本，作为后续分析参考。

二.关卡生成逻辑优化

目前关卡生成痛点

目前关卡生成的主要问题集中在高维度关卡，尤其是 10x10、12x12 这类关卡。 之前的生成方式更偏向先随机生成区域，再通过反复尝试来筛选合适结果。这种方式在低维度关卡上还可以接受，但在高维度关卡上会暴露出几个问题：

• 很多关卡虽然能生成出来，但并不是唯一解；
• 有些关卡看起来结构正常，但玩家实际推理时可能无法稳定解出；
• 通过随机微调区域边界来修复多解问题，成功率很低；
• 部分备用生成路径虽然能产出关卡，但质量不可控，不适合作为正式发布内容；
• 原本的难度评估比较粗，只能大致判断关卡是否可解，不能很好反映推理过程到底有多复杂。 也就是说，当前关卡生成的核心问题不是“能不能生成出来”，而是生成出来的关卡是否满足正式发布要求：
• 答案是否唯一；
• 是否能通过逻辑推理解出；
• 难度是否符合预期；
• 生成过程是否足够稳定。

优化逻辑

本次优化的方向，是把关卡生成从“随机尝试”调整为“围绕发布标准进行生成”。 也就是不再单纯追求生成数量，而是先明确一套正式关卡必须满足的标准：

• 必须只有一个正确答案；
• 必须能通过逻辑推理完成；
• 普通关不能依赖猜测；
• 高维度关卡允许使用更复杂的推理方式；
• 备用生成结果不能直接进入正式发布流程；
• 关卡难度不仅看尺寸和区域数量，也要看实际推理过程。 同时，对求解器的评分逻辑进行了优化。之前更多是判断“这关能不能解出来”，现在进一步补充**“这关是怎么解出来的”、“用了多复杂的推理步骤”。** 这样后续就可以更准确地区分：
• 简单关：通过基础排除就能解出；
• 中等关：需要结合行、列、区域关系进行判断；
• 高难关：需要多步推理或组合判断才能解出。

优化步骤

3.1 调整正式生成入口

将正式生成流程切换到更适合保证唯一解的生成方式。 之前的生成方式偏随机，适合快速产出候选关卡，但高维度关卡容易出现多解。 新的生成方式会在生成过程中不断检查并排除错误候选，目标是更稳定地生成只有一个答案的关卡。 这样做的目的，是优先保证关卡的正确性，再考虑生成效率。

3.2 固化发布标准

整理并固化了一套正式发布标准：

• 关卡必须只有一个答案；
• 关卡必须能被逻辑推理解出；
• 普通关不允许依赖猜测；
• 高维度关卡允许使用更高级的逻辑推理，符合关卡定位的同时也能提高生成成功率；
• 备用生成路径产出的关卡，不直接进入正式发布流程。 这样可以避免“生成成功”被误认为“可以发布”。

3.3 增加发布审计工具

新增了关卡发布审计工具，用来自动检查关卡是否符合发布要求。 它可以检查：

• 当前关卡是不是唯一解；
• 是否能被逻辑推理解出；
• 是否超过允许的推理复杂度；
• 是否来自不可靠的备用生成路径；
• 不通过时具体失败原因是什么。 这样后续批量生成后，可以直接筛选出真正适合发布的关卡。

3.4 优化求解器的策略评分逻辑

除了判断关卡是否能解出，还进一步记录解题过程中使用了哪些类型的推理方法，以及推理链路有多深。 可以理解为：

• 以前只知道： “这关能解。”
• 现在可以知道：“这关是靠什么样的策略解出来的。” 这部分优化的价值是：
• 更准确评估关卡真实难度；
• 避免只用尺寸或区域数量判断难度；
• 为后续难度曲线设计和关卡筛选提供依据。

3.5 补充高级推理规则

针对高维度关卡，补充了一批更复杂的推理规则。 这些规则主要用于处理一些基础规则无法解决的情况，例如：

• 某一行、某一列或某个区域中的组合关系；
• 多个区域之间的容量限制；
• 某些候选位置会导致矛盾，因此可以被排除。 这部分优化后，部分原本求解器无法完整解出的 12x12 关卡，现在可以通过逻辑推理完成。

3.6 增加失败原因分析与自动调整

生成失败时，不再只记录“失败”，而是进一步区分失败原因。 例如：

• 是因为答案不唯一；
• 是因为逻辑推理无法解出；
• 是因为生成时间超时；
• 是因为求解过程太复杂。 根据不同失败原因，再调整对应参数。 这样生成过程不再是盲目增加次数，而是可以有针对性地优化。

结果测试

4.1 旧生成方案诊断结果

通过测试确认，旧方案在高维度关卡上生成失败的主要原因是多解。 在 8x8 / 10x10 / 12x12 测试中，大量失败情况都是因为生成出的关卡不止一个答案。 同时，随机调整区域边界的修复方式效果也不好，在多组测试中几乎无法稳定修复唯一性问题。 结论是：旧方案不适合作为正式发布链路的默认生成方式。

4.2 新生成链路测试结果

切换新的生成链路后，测试结果有明显改善：

• 8x8：已经比较稳定，可以在较短时间内生成并通过发布检查；
• 10x10：已经可以生成可发布关卡，但仍需要一定的重试和参数调整；
• 12x12：已经能生成可发布样本，但成功率还不够稳定。 目前可以认为：
• 低维度关卡已经基本稳定；
• 中等尺寸关卡具备交付能力；
• 高维度关卡已经跑通流程，但还需要继续优化生成成功率。

4.3 求解器评分测试结果

优化策略评分后，关卡难度不再只依赖尺寸或区域数量，而是可以结合实际解题过程判断。 例如，同样是 12x12 关卡：

• 有些关卡只需要基础规则就能解出；
• 有些关卡需要行列锁定、区域锁定；
• 有些关卡需要多步组合推理。 这让后续难度评估更准确，也方便将关卡分配到普通关、卡点关或每日挑战等不同类型中。

4.4 高级推理规则测试结果

补充高级推理规则后，对已有样本进行对比测试：

• 总体逻辑可解覆盖率从 66/68 提升到 68/68；
• 12x12 关卡覆盖率从 3/5 提升到 5/5；
• 新规则主要提升的是高维度关卡；
• 低维度关卡没有明显额外负担。 这说明新增规则确实解决了一部分高维关卡的求解问题。

4.5 当前剩余问题

目前关卡生成链路已经从“能不能生成”推进到“能不能稳定批量生成可发布关卡”。 剩余主要问题是：

• 12x12 的唯一解生成成功率仍然不稳定；
• 部分高难关卡需要更复杂的推理策略，难度边界还需要继续评估；
• 后续需要继续优化高维度关卡的生成效率和稳定性。

三.关卡截图分析流程优化

之前方案

之前在验证截图关卡时，主要依赖 Agent 的识图能力来识别棋盘中的单元格和颜色区域。 这种方式的优点是上手快，不需要自己写复杂的图像处理逻辑，只要把截图交给 Agent，就可以让它尝试判断：

• 棋盘是几乘几；
• 每个格子是什么颜色；
• 哪些格子属于同一个区域； 但实际使用中也暴露出一些问题：
• 识别结果高度依赖接入的模型能力，不同agent对同一个截图可能会给出不同的结果。
• 对相近颜色的判断容易出错；
• 棋盘边缘、阴影、高光、UI 遮挡等因素会影响识别；
• Agent 的识别过程不够可控，出错后很难精确定位是哪一步出错；
• 不适合后续接入自动化批量验证流程。 因此，之前方案更适合临时辅助判断，不适合作为稳定的工具链。

优化思路

本次优化的方向，是尝试用 OpenCV 替代 Agent 识图，把识别过程拆成更明确、可调试的图像处理步骤。 新的思路是：

• 使用 OpenCV 找到棋盘区域，并识别每个单元格的位置；
• 对每个格子中心区域进行颜色采样
• 判断哪些格子颜色相同
• 还原出关卡区域数据
• 交给求解器验证 这样做的核心价值是：识别逻辑从“让 Agent 看图判断”变成“用固定算法提取颜色和网格”。 相比之前方案，OpenCV 方案有几个优势：
• 识别过程更可控；
• 每一步都可以输出中间结果进行排查；
• 颜色采样、阈值、网格识别规则都可以手动调整；
• 更容易做成批量自动化工具；
• 出错时可以明确判断是网格识别问题，还是颜色分类问题。 目前已经尝试实现了一版基于 OpenCV 的识别流程：
• 通过颜色筛选棋盘色块；
• 使用轮廓检测定位格子；
• 根据格子中心点推断完整网格；
• 采样格子中心区域，减少边框和阴影影响；
• 根据采样结果对颜色进行分类，将同一颜色的格子归并为同一区域；
• 最后导出关卡数据，并调用求解器验证唯一性。

目前遇到的问题

目前 OpenCV 方案已经能在部分截图上跑通，低维度关卡识别效果较好，但在 高维度关卡上还存在颜色误判问题。 主要问题是： 游戏内有些区域颜色非常接近，在截图采样后，这些颜色经过量化处理时，可能会被误认为是同一种颜色。 这样会导致：

• 原本不同的区域被合并；
• 还原出的关卡数据和真实截图不一致； 也就是说，目前 OpenCV 方案的主要瓶颈不是网格定位，而是相近颜色的稳定区分。 后续可以继续从几个方向优化：
• 提高颜色分类精度，避免不同颜色被合并；
• 改用更适合区分色相的颜色空间；
• 对每个格子采样更多像素点，减少阴影和高光影响；
• 在识别后增加颜色数量校验，发现异常时自动提示。 目前的阶段性结论是：OpenCV 方案比 Agent 识图更适合作为长期工具链，但还需要继续优化颜色分类逻辑，尤其是高维度关卡中相近颜色的区分问题。

四.后续计划

界面适配与美术完善

• 补充遗漏的美术资源，并对已有资源的细节表现进行优化；
• 持续完善 UI 动效、特效和交互反馈，提升整体界面表现力；
• 基于后续测试结果，修复可能遗漏的多分辨率适配问题。 关卡与玩法体验
• 继续优化自动化关卡截图识别流程，结合体验反馈和样本分析结果，辅助重新规划项目关卡难度曲线，并批量生成、配置对应关卡数据；
• 继续优化大尺寸关卡的唯一解生成成功率，并结合求解器评分结果，进一步校准不同尺寸、不同难度关卡的生成策略。
• 继续探索更稳定的自动化或半自动化关卡数据收集方案； 平台与真机测试
• 持续进行真机测试，排查不同设备、分辨率和平台环境下的显示与交互问题；
• 结合抖音小游戏环境继续验证构建、运行、存档、广告等平台相关能力；
• 对测试中发现的问题进行记录、分类和阶段性修复。