Evilom
116 lines
8.4 KiB
Markdown
116 lines
8.4 KiB
Markdown
# QAdawW4l4iaWSIkf0jDcqVxqngb
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/QAdawW4l4iaWSIkf0jDcqVxqngb
|
||
|
||
|
||
# 一.工作内容概述
|
||
- 基于昨日进度，继续探索生图工作流优化方向，重点尝试解决从整体 UI 效果图拆分单个素材时，单个素材无法完全还原效果图样式的问题。
|
||
- 了解抖音开发者平台相关流程，将 Cocos 项目构建后导入抖音开发者工具，并针对抖音环境下暴露出的各种问题进行排查与修复。
|
||
# 二.生图工作流探索
|
||
之前的测试发现，ClaudeCode在后续拆分阶段使用 image2 对单个元素进行重新生成，只能保证风格统一，却无法保证样式还原，初步怀疑是提示词和拆分策略的原因。
|
||
因此今天分别使用 **Codex** 和 **ClaudeCode**，**基于相同提示词、相同参考图**，连续执行了三次拆分任务，用于观察两者在稳定性与还原度上的差异。
|
||
## 1.测试结果
|
||
**对比项**
|
||
**Codex原生环境**
|
||
**ClaudeCode 调用 Image2**
|
||
多次输出稳定性
|
||
稳定
|
||
较稳定
|
||
风格一致性
|
||
稳定
|
||
较稳定
|
||
与效果图还原度
|
||
几乎完全还原效果图
|
||
只能做到风格相近
|
||
资产细节
|
||
保留度更高
|
||
容易发生重构
|
||
中文文字 / 图标细节
|
||
清晰还原
|
||
容易变形或重写
|
||
同样是使用Image-2，但Codex的输出更符合“从效果图中拆出元素”的目标。
|
||
|
||
|
||
|
||
|
||
|
||
## 2.问题分析
|
||
### 关键差异不是“生图与抠图”
|
||
初期曾认为：
|
||
- Codex = 程序化抠图 + 后处理
|
||
- ClaudeCode = image2 重绘
|
||
但经过进一步分析，这个判断并不完全准确。
|
||
更准确的结论是：**Codex 也是使用了生图能力，但它更像是通过对话式 agent + 图像工具链来完成任务；ClaudeCode 则更像是直接裸调用 image2 的 generation 接口。**
|
||
OpenAI 官方图像文档中明确区分了两类能力入口：**Image API** 和 **Responses API 图像工具：**
|
||
- Image API 包含 generations 与 edits 两类端点，前者用于从文本 prompt 生成图像，后者用于基于已有图像进行修改；
|
||
- 而 Responses API 更适合“对话式、多步骤”的图像体验，并且可以把图像输入和输出保留在上下文中。
|
||
这与今天观察到的现象一致：如果 ClaudeCode 只是裸调用 images.generate，任务更容易退化为“参考图重新生成”；**而 Codex / ChatGPT 式链路更可能通过上下文、工具路由和多步编辑能力，把需求解释成“从图中分离 / 编辑 / 保持同源”。**
|
||
|
||
### “同样的提示词”不等于“同样的真实调用”
|
||
OpenAI 文档说明，Responses API 的 image generation tool 支持在上下文中决定是生成新图还是编辑已有图，可以通过 action: "auto" 让模型自动选择，也可以用 action: "generate" 或 action: "edit" 强制指定行为。
|
||
|
||
这说明同样一句用户需求，在不同链路里可能被执行成两种不同任务：
|
||
- generate：参考原图重新生成一个相似资产
|
||
- edit / isolate：基于已有图像做编辑、分离或局部修改
|
||
此外，官方文档还说明，使用 Responses API 的图像生成工具时，主模型会自动改写 prompt，并可在 revised_prompt 字段中查看改写后的提示词。
|
||
因此，今天的测试结论不能简单归因于“提示词写得好不好”。更合理的理解是：**Codex / 网页 GPT 的执行链路可能包含更高层的需求转译、prompt revision 和 edit / generate 路由；而 ClaudeCode 当前流程更接近将 prompt 和参考图直接交给 generation 接口，因此更容易退化成“参考图重绘”。**
|
||
### ClaudeCode 更容易把“拆分”理解成“参考重绘”
|
||
在 ClaudeCode 方案中，即使提示词中明确写了：
|
||
- 只提取指定元素
|
||
- 保持原图风格
|
||
- 匹配颜色、线条、质感、比例
|
||
- 透明背景
|
||
- 不要包含其他元素
|
||
image2 仍然容易把任务执行成：参考原图，重新生成一个风格相近的元素，而不是：从原图中分离出这个元素。
|
||
所以最终结果虽然稳定，但细节会漂移，例如：
|
||
- 图标轮廓变化；
|
||
- 水彩纹理重构；
|
||
- 中文文字被重新书写；
|
||
- 装饰细节缺失或变形；
|
||
- 转盘颜色、边缘、比例与原图不完全一致等。
|
||
OpenAI 官方文档也提到，图像模型虽然具备较强能力，但仍存在限制，例如文字渲染、跨多次生成保持一致性等场景仍可能出现问题。
|
||
这也能解释为什么逐个重新生成资产时，中文标题、按钮文字、图标细节更容易发生漂移。
|
||
## 3.后续 Skill 改造方向
|
||
### 将 Skill 迁回 Codex
|
||
结合今日测试结果，后续方向应调整为：重新把 UI-Asset-Forge Skill 迁回 Codex。相比 ClaudeCode 中直接裸调用 image2，Codex 更适合作为完整资产生成与交付流程的执行环境，可以更好地串联图像生成、文件处理、后处理切分、结果检查和失败重试等步骤。
|
||
### 减少 Skill 中过重的提示词规划
|
||
经测试，效果图 + 简单的“拆分图片中各个元素并交付”类 prompt，在 Codex / 网页 GPT 环境中已经能够得到较理想的输出效果。
|
||
|
||
因为在codex流程中，agent会理解需求并自行改写优化prompt，所以后续**不应继续扩大 prompt 的复杂度，而是要减少无效中间流程以提高执行效率**。
|
||
需要减少的部分包括：
|
||
- 过长的风格复述；
|
||
- 逐元素重复 prompt 拼装；
|
||
- 多层 asset brief；
|
||
- 复杂但不直接参与执行的 planning 文件；
|
||
- 依赖模型自己理解“拆分”的提示词工程。
|
||
但仍然需要保留轻量决策层：
|
||
- 任务类型判断：生成 / 拆分 / 混合
|
||
- 输出模式判断：单图 / asset sheet / mockup + sheet
|
||
- 批次规划：哪些合批，哪些单独生成
|
||
- 后处理规则：透明底、纯色底、扣底、切分、padding
|
||
- 失败策略：重试、单独补生成、标记人工检查
|
||
核心变化是：**从“prompt 工程中心”转向“执行流程中心”。**
|
||
### 引入合理的 asset sheet 合批策略
|
||
后续按这个思路来构建策略以提高生成效率：
|
||
- 主结构件：单独生成
|
||
- 小图标组：asset sheet 合批生成
|
||
- 文字类资源：单独生成或尽量程序化处理
|
||
- 装饰件：按风格和尺寸合批
|
||
- 失败项：单独补生成
|
||
# 三.抖音开发者平台相关
|
||
项目构建并导入抖音开发者工具后，实际运行过程中发现，抖音小游戏环境和 Cocos 本地环境仍然存在一些差异。目前发现的问题集中在 **运行环境差异、代码依赖关系、关卡生成性能** 三个方面。
|
||
## 运行环境差异
|
||
部分功能在 Cocos 本地预览时可以正常运行，但导入抖音开发者工具后会出现异常。
|
||
主要原因是抖音小游戏的运行环境和本地 Cocos 环境并不完全一致，对一些代码写法更敏感。比如：
|
||
- 原来部分逻辑使用了反复递归重试，在抖音环境中容易导致程序崩溃；
|
||
- 有些只是普通工具类的代码，被当成 Cocos 组件注册后，在抖音环境中会触发异常。
|
||
## 代码依赖关系问题
|
||
项目导入抖音环境后，也暴露出了一些代码文件之间依赖关系不清晰的问题。
|
||
简单来说，就是部分代码在本地环境下可以正常被识别，但在抖音构建和运行环境中，会因为文件互相引用、类型没有正确导出等问题导致报错。
|
||
## 关卡生成性能问题
|
||
当前生存模式关卡仍然是在客户端本地实时生成。导入抖音环境后发现，这部分逻辑对性能和稳定性要求较高，容易影响体验。
|
||
主要表现为：
|
||
- 小尺寸关卡有时生成不稳定；
|
||
- 某些参数组合下生成容易失败；
|
||
- 后台生成关卡时，可能会影响页面切换流畅度。
|
||
后续会改为从云端拉取生成好的关卡或者是请求云端生成关卡 |