chore:文档补全

output/feishu-docs/EIWNwKjnIipmStkzIr1cd1kTnPf.md

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