2026.5.13-日报-王雨默

用户2965

5月14日修改

一.工作内容概述

•
完成抽奖系统剩余部分逻辑，修复bug​

•
测试生图Skill进阶模式执行链路，并对其进行优化​

二.生图Skill进阶模式测试优化

1.测试情况

最开始几次测试时，发现流程并没有完全按照预期运行，主要问题包括：​

1.
 一些已经约定好的流程步骤没有被严格执行； ​

2.
 provider 的相关配置没有被持久化保存，导致多次调用之间配置不稳定； ​

3.
 某些本应向用户确认的步骤被跳过； ​

4.
 部分阶段虽然状态显示已完成，但实际中间产物并不稳定； ​

5.
 生成、拆分、后处理、交付之间的衔接还不够清晰。 ​

经过多轮修复后，进阶模式已经能够按照预期流程运行，并最终完成图片资产交付。但在当前默认链路下，交付质量、资产风格一致性以及对参考图的还原度仍然不够稳定。​

也就是说，进阶模式现在已经具备基本交付能力，但还需要继续优化生成链路的可控性和稳定性。​

common.docs_name - LarkCCM_Docs_Menu_Image

前期资产清单确认

50%

生成报告，尺寸有bug，后面修复了

50%

效果图

交付图，整体风格符合概念图，但是样式没有按照效果图进行还原

2.质量问题与初步判断修正

问题不一定出在底层模型能力本身，而可能出在调用链路、提示词编译、任务拆分方式、参考图传递方式，以及 skill 工作流对生图任务的组织方式上。​

也就是说，即使底层模型同样是 image2，最终效果也可能因为前置 agent、provider 封装层、参数暴露方式、prompt 编写方式不同而出现明显差异。调用同一个生图模型，不代表最终效果一定等价。​

原生 ChatGPT 网页端的生图效果较好，可能不仅是因为底层模型强，也因为它在用户输入和生图模型之间，存在更强的任务理解、prompt 优化和调用编排能力。第三方 agent 如果只是把用户原话简单拼接后交给模型，即使模型相同，结果也可能不稳定。​

所以当前要解决的核心不只是 provider 能不能调用 image2，而是：第三方 agent 能不能像原生 GPT 一样，把用户的模糊需求转译成适合生图模型执行的高质量 prompt。​

3.拆分生成测试与发现

为了进一步定位资产质量问题，今天使用一张完整的游戏抽奖界面进行了拆分生成测试。​

最开始版本生成出的资产并不是完全跑偏，整体风格与参考图是接近的，例如水彩质感、柔和配色、手绘感、棕色描边等方向基本能够保持。但是问题在于，生成结果对参考图中具体元素的还原度不够稳定，部分资产在形状、比例、细节和布局关系上与原图存在偏差，更像是“同风格重画”，而不是“基于参考图进行单资产重建”。​

后续排查后发现，一个关键问题是：参考图没有实际随 prompt 一起发送给 image2。这导致 image2 主要依赖文字描述生成资产，只能做到风格接近，但难以稳定还原参考图中的具体样式。​

修复参考图传递问题后，又进一步测试了“完整原图作为统一参考 + 每个资产独立详细 prompt”的方式。每个资产的 prompt 都明确说明：​

•
 当前只需要生成哪一个资产； ​

•
 需要包含哪些内容； ​

•
 需要排除哪些内容； ​

•
 需要保持原图中的水彩手绘风格； ​

•
 需要保持棕色描边、柔和配色、纸张纹理； ​

•
 输出为独立资产； ​

•
 不要带出其他界面元素。 ​

实际测试结果明显更接近预期。生成出来的标题、按钮、转盘底板、金币、闪电、拼图、宝箱等资产，不仅整体风格与原图接近，在具体样式还原上也比最初版本更加稳定。​

基于这次测试，可以初步认为：影响生成效果的关键不只是模型能力，而是参考图是否真实参与生成，以及 agent 能否为每个资产生成清晰、独立、细节充分的 prompt。​

这次效果较好的原因主要有几点：

1.
参考图传递问题已被验证并修复。​
修复后，完整原图能够实际作为统一参考传入 image2，为模型提供整体风格、色彩、笔触、描边、材质和界面气质，使生成结果不再只依赖文字描述。 ​

2.
整体识别和拆分规划前置完成。​
在 skill 流程初期，agent 已经对完整界面进行了内容识别，拆出了标题、按钮、宝箱、转盘底板、图标等最小可用资产单元。到了 image2 调用阶段，不再把整体识别和拆分规划的责任交给 image2，而是基于前置拆分结果，每次只让 image2 执行一个明确的单资产重建任务。 ​

2026.5.13-日报-王雨默​

2026.5.13-日报-王雨默