chore:文档补全

2026-06-23 14:43:31 +08:00
parent a57554bbfa
commit 9f190e0315
377 changed files with 38889 additions and 8 deletions
@@ -0,0 +1,52 @@
+# ZVOVw5BCriBcUfkT1cFcOw3nnBc
+
+Source: https://dianchukeji.feishu.cn/wiki/ZVOVw5BCriBcUfkT1cFcOw3nnBc
+
+
+# 一.工作内容概述
+  - 使用生图工作流来产出美术资产，解决过程中遇到的问题
+  - 完成主菜单美术资产产出，并在游戏内进行替换
+  - 小功能点优化：补充关卡模式前期自动揭示逻辑、增加金币显示UI
+  - 整理汇报内容
+# 二.生图工作流测试验证情况
+今日主界面资源出图过程中暴露出多个问题，主要集中在复杂需求理解、图片尺寸控制和后处理质量上。
+## Agent Team 全自动流程仍无法应对复杂需求
+原计划是通过 Agent Team 完成从需求分析、资源生成、拆分、后处理到入库的完整自动化流程。但实际执行中发现，当前流程在中间脚本调用、状态传递、工具接口使用等环节频繁出错。
+比较明显的问题是：流程还没有真正进入高质量出图阶段，前置的脚本调用和任务编排就已经产生较多异常。这说明当前 Agent Team 流程的稳定性不足，如果继续强行推进全自动化，反而会放大试错成本。
+因此今日将主流程调整为半自动逐模块流程，即：**按模块拆分需求 → 单模块生成 → 人工确认 → 修正问题 → 后处理 → 入库**
+这种方式虽然自动化程度较低，但可控性更高。尤其是在复杂 UI 资源还无法稳定一次生成到位的阶段，逐模块处理能更快定位问题，也能减少整套资源返工的成本。待这套流程经多次测试，沉淀出稳定可复用的规范时，再考虑往全自动化方向发展。
+## 复杂 UI 界面 prompt 问题
+对于元素数量较多、层级较复杂的主界面 UI，之前测试过程中使用的简单描述已经很难让 image2 准确理解需求。模型在处理复杂界面时，容易自行补充、重绘或改变元素结构，导致输出结果虽然风格接近，但具体布局、元素比例和资源样式与预期存在偏差。
+在今日实际测试中，已经尝试让 agent 先对主界面进行结构分析：一方面输出需要拆分的 asset sheet 清单，另一方面同步给出各个元素的位置、尺寸信息。随后再将这些结构化信息提供给 image2 作为生成约束。
+从测试结果来看，这种方式下，模型对整体界面结构的理解更稳定，生成出的资源在比例、布局关系和样式一致性上都有提升，能够更好地减少模型自由发挥带来的偏差。
+这次尝试说明，复杂 UI 出图的关键并不只是加强风格描述，而是要让模型获得更明确的空间结构约束。后续可以将该方式沉淀为固定流程：先由 agent 生成布局表和资源清单，再由 image2 按结构化 prompt 生成资源，从而提升复杂界面资源输出的一致性和可控性。
+## 图片缩放与边缘修复方案
+### 图片尺寸过大的问题
+今日生成的美术资源普遍存在输出尺寸偏大的问题。由于 API 生成尺寸存在最低限制，很多资源即使在游戏中实际占用面积较小，最终交付的文件仍然会达到较高分辨率。
+对于一些美术资源，比如小图标和小按钮等，没有必要保留过高分辨率，如果这些图片直接进入项目，会带来几个问题：
+  - 项目包体变大，超过开发者平台的包体大小限制（抖音是主包20MB，超过需要分包）
+  - 加载资源时占用更多内存；
+  - 后续管理和替换成本增加。
+因此今日引入了图片缩放流程，对资源尺寸进行统一控制。
+### Sharp 库缩放方案
+本次选择使用 Sharp 库处理图片缩放。
+Sharp 是一个用于处理图片的第三方工具库，主要作用是对图片进行批量缩放、裁剪、格式转换和压缩。它类似于一个可以通过脚本调用的“自动图片处理工具”，不需要手动一张张打开图片修改尺寸，而是可以把一批图片按照预设规则统一处理。
+缩放策略上，不再简单按照固定比例缩放，而是根据规划阶段的目标尺寸进行等比缩放。对于底板等 UI 元素，采用宽高较大的一方作为基准进行缩放，避免因为某一边过窄导致整体被压得过小。
+这样可以优先保证资源在目标区域中具有足够的视觉尺寸，后续有需要的话，也可以通过裁剪或控制透明边距的方式来控制实际显示范围。
+### Alpha 边缘异常问题
+在一开始，图片缩放后出现了比较明显的边缘问题，主要表现为：
+  - alpha 边缘毛刺；
+  - 半透明边缘不干净；
+  - 缩小后细节变脏。
+初步判断主要原因是缩放插值过程中 alpha 通道和颜色通道共同参与计算，导致边缘半透明像素混入背景色或残留色。尤其是带阴影、描边、柔光的 UI 元素，在缩小后更容易出现边缘不干净的问题。
+为了解决该问题，尝试加入 alpha 边缘修复流程，核心思路是：**在缩放前，先让图片边缘稍微“向外扩一圈”，让边缘颜色更完整；等图片缩小完成后，再把多扩出去的部分“收回来”，最后清理掉透明度很低的残留像素。**
+这样做的好处是，缩放过程中图片边缘不会直接和透明区域混在一起，可以减少缩小后出现的毛刺、灰边、半透明脏边等问题。
+不过该方案也不是完全无损的。因为它会对图片边缘做一次“扩张”和“收缩”，所以在改善边缘干净程度的同时，可能会略微影响非常细的阴影、描边或小图标细节。后续需要根据不同资源类型调整处理强度，避免为了清理边缘而损失过多画面细节。
+## 当前确立的 UI 资源处理流程
+当前较稳定的 UI 资源处理流程如下：
+这个流程相比原先的全自动 Agent Team 流程更加保守，但更符合当前阶段的实际情况。对于复杂 UI 资源而言，先保证单模块质量稳定，比过早追求全自动更重要。
+# 三.后续计划
+  - 继续产出 UI 资源，并逐步实装进游戏中
+  - 体验《佛系消消消》，总结其关卡设计与投放思路
+  - 基于游玩体验重新生成并配置关卡，并视情况扩充调整关卡编辑器功能
+  - 持续进行真机测试，排查平台适配问题