1077 lines
21 KiB
Markdown
1077 lines
21 KiB
Markdown
# AI Native 游戏开发工作站方案 EpeeKit
|
||
|
||
## —— 以 Agent 编排为核心的专业游戏开发工厂
|
||
|
||
---
|
||
|
||
## 1. 项目定义
|
||
|
||
### 1.1 终极愿景
|
||
|
||
本项目的终极形态是：
|
||
|
||
**AI Native 游戏开发工作站**
|
||
|
||
它面向游戏研发全流程，目标是在统一的项目空间中，逐步支持：
|
||
|
||
* 2D 游戏资产生产
|
||
* 3D 资产与动画资产生产
|
||
* 音频与语音资产生产
|
||
* 配置与结构化内容生成
|
||
* 游戏设计与内容策划辅助
|
||
* 项目知识、工作流、技能模板的沉淀与复用
|
||
|
||
这个终极愿景成立的前提不是“一个模型做所有事”，而是：
|
||
|
||
**用统一的 Agent 语义层、项目层和资产层，去编排多种不同范式的底层能力。**
|
||
|
||
也就是说，统一的是“用户入口”和“系统组织方式”，不是底层模型范式本身。
|
||
|
||
---
|
||
|
||
### 1.2 当前阶段目标
|
||
|
||
当前阶段的第一个明确 milestone 是：
|
||
|
||
**解决 2D 游戏资产的工程化生产问题**
|
||
|
||
并且只聚焦于其中最有价值、最能形成能力闭环的一部分，而不是一开始覆盖全部游戏研发任务。
|
||
|
||
EpeeKit 方案下，第一阶段的核心定义为：
|
||
|
||
> 通过对话式 Agent + 受控工作流系统 + 资产管理系统，完成 2D 游戏资产的可控生成、编辑、一致性维护、训练沉淀与项目级复用。
|
||
|
||
---
|
||
|
||
### 1.3 核心产品定位
|
||
|
||
本系统不是：
|
||
|
||
* 单纯的聊天生图工具
|
||
* 单纯的节点工作流工具
|
||
* 单纯的模型管理平台
|
||
|
||
而是：
|
||
|
||
**以 Agent 编排为核心的游戏资产生产系统**
|
||
|
||
它的本质是把：
|
||
|
||
**自然语言需求 → 结构化任务 → 受控工作流 → 结果评估 → 资产沉淀**
|
||
|
||
串成一个稳定闭环。
|
||
|
||
---
|
||
|
||
## 2. 核心设计原则
|
||
|
||
---
|
||
|
||
### 2.1 统一语义层，不统一底层范式
|
||
|
||
系统要统一的是：
|
||
|
||
* 用户表达方式
|
||
* 任务理解方式
|
||
* 资产组织方式
|
||
* 项目上下文
|
||
* 约束与复用方式
|
||
|
||
系统不追求统一的是：
|
||
|
||
* 图像模型内部结构
|
||
* 3D 生成范式
|
||
* 音频生成范式
|
||
* 配置生成范式
|
||
|
||
这意味着未来扩展到 3D、动画、音频时，依然可以沿用同一个 Agent 和项目系统，但底层执行链路会不同。
|
||
|
||
---
|
||
|
||
### 2.2 Agent 负责理解与编排，不直接“自由设计工作流”
|
||
|
||
Agent 的职责是：
|
||
|
||
* 理解意图
|
||
* 追问必要信息
|
||
* 选择模板
|
||
* 填充参数
|
||
* 解释结果
|
||
* 引导修改
|
||
|
||
Agent 不应直接拥有无限自由的工作流设计权。
|
||
否则系统会迅速陷入组合爆炸和不可维护状态。
|
||
|
||
所以，系统必须建立：
|
||
|
||
* **任务中间层（Task IR）**
|
||
* **工作流注册表（Pipeline Registry）**
|
||
* **资产约束系统（Style / Character / Project Constraints）**
|
||
|
||
Agent 的行为边界是：
|
||
|
||
> 在受控模板和约束系统内进行选择、补全和编排，而不是任意发明执行逻辑。
|
||
|
||
---
|
||
|
||
### 2.3 默认简单，逐层开放
|
||
|
||
系统应当对普通用户隐藏复杂度，但不能永久隐藏控制权。
|
||
|
||
因此产品必须支持三层使用模式：
|
||
|
||
#### 模式 A：自然语言驱动
|
||
|
||
适合普通用户，用户只描述想要什么。
|
||
|
||
#### 模式 B：引导式修订
|
||
|
||
系统给出结果后，用户通过自然语言做精修，例如：
|
||
|
||
* 头发颜色更冷一点
|
||
* 构图别那么满
|
||
* 表情更阴郁
|
||
* 武器做得更夸张
|
||
|
||
#### 模式 C：高级控制
|
||
|
||
在用户需要时，开放：
|
||
|
||
* 参数面板
|
||
* 中间节点可见
|
||
* 控制图输入
|
||
* 模板选择/切换
|
||
* 高级实验模式
|
||
|
||
默认路径必须简单，但不是彻底黑盒。
|
||
|
||
---
|
||
|
||
### 2.4 风格一致性不是单模型问题，而是资产系统问题
|
||
|
||
系统不应把风格一致性寄托于某一个模型“自动学会”。
|
||
EpeeKit 明确认为，风格一致性和角色一致性都必须由系统层共同实现：
|
||
|
||
* 风格集
|
||
* 角色参考组
|
||
* 可选 LoRA
|
||
* 结构控制
|
||
* 多候选评估
|
||
* 项目级约束
|
||
|
||
也就是说，一致性是“生成 + 约束 + 资产沉淀”的联合能力。
|
||
|
||
---
|
||
|
||
### 2.5 第一阶段收敛，未来阶段扩张
|
||
|
||
EpeeKit 不再追求“第一版做万能平台”，而是明确采用：
|
||
|
||
**阶段收敛、体系扩张**
|
||
|
||
第一阶段只验证 2D 资产的可控生产系统。
|
||
一旦核心中间层、模板系统、资产系统跑通，后续才向 3D、动画、音频扩展。
|
||
|
||
---
|
||
|
||
## 3. 产品范围与阶段路线
|
||
|
||
---
|
||
|
||
### 3.1 阶段划分
|
||
|
||
#### Phase 0：验证期
|
||
|
||
目标：用最少能力验证 Agent + 工作流 + 资产沉淀是否能形成闭环。
|
||
|
||
#### Phase 1：2D 资产生产系统
|
||
|
||
目标：形成可用的 2D 游戏资产生产系统。
|
||
|
||
#### Phase 2：角色一致性和项目风格系统强化
|
||
|
||
目标：将角色一致性、风格一致性、训练中心做成系统能力。
|
||
|
||
#### Phase 3：扩展到 3D / 动画 / 音频 / 配置
|
||
|
||
目标：沿用统一的 Agent 与项目层，扩展底层能力域。
|
||
|
||
---
|
||
|
||
### 3.2 第一阶段建议聚焦范围
|
||
|
||
第一阶段不做所有 2D 资产，而是优先做这些：
|
||
|
||
* 角色立绘（全身 / 半身 / 头像）
|
||
* 道具 / 武器 / 图标
|
||
* 场景概念图
|
||
* 同角色多变体生成
|
||
* 风格 LoRA / 角色 LoRA 基础训练
|
||
|
||
这几类任务共同覆盖了：
|
||
|
||
* 风格控制
|
||
* 结构控制
|
||
* 一致性需求
|
||
* 批量候选
|
||
* 训练复用
|
||
* 项目资产归档
|
||
|
||
是最适合形成闭环的一组任务。
|
||
|
||
---
|
||
|
||
### 3.3 第一阶段暂不重点做的内容
|
||
|
||
* 复杂团队协作系统
|
||
* 多模型自由混编的高级实验系统
|
||
* 全类型 ControlNet 能力全集
|
||
* 文档/Skill 系统的完整产品化
|
||
* 3D / 动画 / 音频
|
||
* 自动一键完成整套游戏生产
|
||
|
||
这些都属于未来扩展方向，不应干扰第一阶段的产品收敛。
|
||
|
||
---
|
||
|
||
## 4. 系统总架构
|
||
|
||
---
|
||
|
||
### 4.1 总体架构
|
||
|
||
系统可以抽象为以下 7 层：
|
||
|
||
1. 用户交互层
|
||
2. Agent 语义层
|
||
3. 任务中间层（Task IR）
|
||
4. 工作流编排层
|
||
5. 模型执行层
|
||
6. 评估与质检层
|
||
7. 资产与项目层
|
||
|
||
---
|
||
|
||
### 4.2 高层数据流
|
||
|
||
```text
|
||
用户输入
|
||
→ Agent理解与追问
|
||
→ 生成 Task IR
|
||
→ 映射到 Pipeline Template
|
||
→ 填充参数与约束
|
||
→ 执行生成 / 编辑 / 训练
|
||
→ 评估与筛选
|
||
→ 返回结果
|
||
→ 沉淀到项目资产库
|
||
```
|
||
|
||
---
|
||
|
||
## 5. 关键中间层设计
|
||
|
||
这是 EpeeKit 最重要的部分。
|
||
|
||
---
|
||
|
||
### 5.1 Task IR：任务中间层
|
||
|
||
Task IR 是系统的核心抽象层。
|
||
它的作用是把不稳定的自然语言请求，转成稳定、受控、可验证的任务描述。
|
||
|
||
Task IR 至少应包含以下字段：
|
||
|
||
* task_type：任务大类
|
||
* asset_type：资源类型
|
||
* project_id：所属项目
|
||
* style_id：目标风格
|
||
* character_id：目标角色（可选）
|
||
* consistency_level：一致性要求
|
||
* input_references：参考图集合
|
||
* structure_control_type：结构控制类型
|
||
* output_specs：尺寸、比例、透明背景等
|
||
* workflow_template_id：匹配到的模板
|
||
* generation_policy：批次、候选数、评估策略
|
||
* editable_flags：是否允许后续高级编辑
|
||
|
||
示例：
|
||
|
||
```json
|
||
{
|
||
"task_type": "asset_generation",
|
||
"asset_type": "character_full_body",
|
||
"project_id": "proj_x",
|
||
"style_id": "anime_dark_fantasy_v1",
|
||
"character_id": "char_001",
|
||
"consistency_level": "high",
|
||
"input_references": ["ref_a", "ref_b"],
|
||
"structure_control_type": "pose",
|
||
"output_specs": {
|
||
"resolution": "1024x1536",
|
||
"background": "transparent_optional"
|
||
},
|
||
"workflow_template_id": "character_consistent_v1",
|
||
"generation_policy": {
|
||
"candidate_count": 4,
|
||
"rerank": true
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
### 5.2 Pipeline Registry：工作流注册表
|
||
|
||
系统不能允许无限自由组合工作流。
|
||
因此必须有一个注册表，所有可执行工作流都以模板方式注册。
|
||
|
||
每个模板应包含：
|
||
|
||
* 模板 ID
|
||
* 支持的任务类型
|
||
* 支持的输入字段
|
||
* 所需模型组件
|
||
* 默认参数范围
|
||
* 支持的约束
|
||
* 适用场景说明
|
||
* 成本级别
|
||
* 输出格式定义
|
||
|
||
例如：
|
||
|
||
* character_base_v1
|
||
* character_consistent_v1
|
||
* item_icon_v1
|
||
* scene_concept_v1
|
||
* style_transfer_v1
|
||
* lora_training_style_v1
|
||
|
||
默认情况下，Agent 只能从注册表中选模板，而不能自己发明模板。
|
||
|
||
---
|
||
|
||
### 5.3 Constraint Layer：约束层
|
||
|
||
约束层用于防止系统漂移。
|
||
它把“风格”“角色”“项目规范”变成系统级条件，而不是散落在 prompt 里的脆弱文本。
|
||
|
||
约束来源包括：
|
||
|
||
* 项目约束
|
||
* 风格约束
|
||
* 角色约束
|
||
* 输出规范约束
|
||
* 成本与策略约束
|
||
|
||
例如：
|
||
|
||
* 某项目只能使用指定风格集
|
||
* 某角色必须绑定参考组
|
||
* 某任务必须输出透明背景
|
||
* 某类任务默认限制候选数
|
||
* 某阶段不允许自由实验模式
|
||
|
||
这层会显著提升可控性。
|
||
|
||
---
|
||
|
||
## 6. Agent 系统设计
|
||
|
||
---
|
||
|
||
### 6.1 Agent 的职责
|
||
|
||
Agent 在 EpeeKit 中承担以下角色：
|
||
|
||
* 对话理解器
|
||
* 任务拆解器
|
||
* 缺失信息追问器
|
||
* 模板选择器
|
||
* 参数填充器
|
||
* 修改解释器
|
||
* 项目上下文读取器
|
||
|
||
---
|
||
|
||
### 6.2 Agent 不应直接承担的职责
|
||
|
||
Agent 不应：
|
||
|
||
* 自由生成任意工作流图
|
||
* 直接产生不受控参数全集
|
||
* 代替所有图像评估逻辑
|
||
* 代替项目约束系统
|
||
* 代替用户的最终审美判断
|
||
|
||
Agent 是“编排核心”，不是“唯一智能体”。
|
||
|
||
---
|
||
|
||
### 6.3 Agent 的三段式执行逻辑
|
||
|
||
#### 第一步：意图分类
|
||
|
||
判断任务属于哪一类：
|
||
|
||
* 新建角色
|
||
* 生成变体
|
||
* 修图
|
||
* 风格迁移
|
||
* 训练 LoRA
|
||
* 批量导出
|
||
|
||
#### 第二步：结构化填充
|
||
|
||
将用户输入填入 Task IR。
|
||
|
||
#### 第三步：模板匹配与执行策略选择
|
||
|
||
根据任务类型、项目约束、成本策略，选择合适模板。
|
||
|
||
---
|
||
|
||
### 6.4 修改闭环设计
|
||
|
||
用户通常不会说参数，只会说感受。
|
||
所以系统要支持“自然语言修改闭环”。
|
||
|
||
例如用户说：
|
||
|
||
* 脸还是不够像之前那个角色
|
||
* 武器太普通
|
||
* 颜色更偏冷色
|
||
* 构图留白多一点
|
||
|
||
系统需要将这些转为：
|
||
|
||
* 角色参考权重增强
|
||
* 风格强度提高
|
||
* 光照与色温调节
|
||
* 构图相关约束调整
|
||
|
||
这层是 EpeeKit 必须具备的，不然用户会在第一轮结果后流失。
|
||
|
||
---
|
||
|
||
## 7. 模型执行层设计
|
||
|
||
---
|
||
|
||
### 7.1 总体策略：双栈路线
|
||
|
||
EpeeKit 建议采用双栈路线，而不是单押一种底模。
|
||
|
||
#### 主力工程栈
|
||
|
||
适合可控、成熟、工程化能力强的任务。
|
||
|
||
#### 高质量增强栈
|
||
|
||
适合质量更高、复杂度更高的任务。
|
||
|
||
这样做的目的不是炫技，而是兼顾：
|
||
|
||
* 稳定性
|
||
* 可控性
|
||
* 生态成熟度
|
||
* 质量上限
|
||
|
||
---
|
||
|
||
### 7.2 第一阶段建议执行栈
|
||
|
||
#### 主执行栈
|
||
|
||
* SDXL 系列为主
|
||
* 参考图风格注入
|
||
* ControlNet
|
||
* img2img / inpaint
|
||
* LoRA 加载
|
||
* 批量候选生成
|
||
|
||
#### 增强栈
|
||
|
||
* 更高质量的图像模型作为后续增强路线
|
||
* 用于高质量角色图、复杂编辑或特定高价值任务
|
||
|
||
---
|
||
|
||
### 7.3 工作流执行引擎
|
||
|
||
建议将工作流执行层与业务后端解耦。
|
||
|
||
可以采用：
|
||
|
||
* 一个适合复杂节点编排和快速试验的执行引擎作为主工作流引擎
|
||
* 同时为未来服务化保留标准化 Python / API 管线
|
||
|
||
这样可以兼顾：
|
||
|
||
* 快速实验
|
||
* 模板沉淀
|
||
* 后续服务化
|
||
|
||
---
|
||
|
||
## 8. 风格一致性与角色一致性系统
|
||
|
||
这是 EpeeKit 的核心壁垒之一。
|
||
|
||
---
|
||
|
||
### 8.1 真实能力边界
|
||
|
||
必须非常客观地说：
|
||
|
||
#### 当前 AI 可以较稳定做到的
|
||
|
||
* 风格层面的一致
|
||
* 颜色体系和材质倾向一致
|
||
* 同一项目下相似视觉语言
|
||
|
||
#### 当前 AI 可以中等程度做到的
|
||
|
||
* 同一角色的相似脸部
|
||
* 同一角色的服装和关键符号保留
|
||
* 同一角色的有限变体
|
||
|
||
#### 当前 AI 很难天然做到的
|
||
|
||
* 任意角度下完全统一的角色身份
|
||
* 任意姿态和复杂场景下完全稳定的角色
|
||
* 像 3D rig 那样严格的一致性
|
||
|
||
所以系统必须承认现实边界，采用工程组合策略，而不是幻想靠单一模型解决。
|
||
|
||
---
|
||
|
||
### 8.2 一致性系统的三层结构
|
||
|
||
#### A. Style Layer：风格层
|
||
|
||
定义项目风格，不建议仅靠 prompt 文字描述。
|
||
|
||
组成包括：
|
||
|
||
* 风格 ID
|
||
* 风格参考集
|
||
* 可选风格 LoRA
|
||
* 风格 embedding
|
||
* 风格描述元数据
|
||
|
||
#### B. Character Layer：角色层
|
||
|
||
定义项目中的角色身份。
|
||
|
||
组成包括：
|
||
|
||
* 角色 ID
|
||
* 角色参考组
|
||
* 角色描述元数据
|
||
* 可选角色 LoRA
|
||
* 角色关键视觉要素
|
||
|
||
#### C. Constraint Layer：约束层
|
||
|
||
规定生成任务必须使用哪些风格和角色资源，以及允许偏移的范围。
|
||
|
||
---
|
||
|
||
### 8.3 风格集和角色参考组怎么做
|
||
|
||
#### 风格集
|
||
|
||
不要用单张图定义风格。
|
||
应使用一个风格参考集，至少包含若干能代表该风格核心特征的图。
|
||
|
||
作用：
|
||
|
||
* 让风格定义更稳
|
||
* 避免单图偏差
|
||
* 为评估层提供参考
|
||
|
||
#### 角色参考组
|
||
|
||
角色不能只绑定一张正面图。
|
||
建议包含：
|
||
|
||
* 正面
|
||
* 半侧面
|
||
* 半身
|
||
* 表情变化
|
||
* 关键服饰细节
|
||
|
||
作用：
|
||
|
||
* 提供更稳定的角色身份锚点
|
||
* 为一致性生成提供多参考依据
|
||
|
||
---
|
||
|
||
### 8.4 一致性生成策略
|
||
|
||
角色或风格一致性任务应优先使用组合策略：
|
||
|
||
* 角色参考组
|
||
* 风格参考组
|
||
* 可选 LoRA
|
||
* 结构控制
|
||
* 多候选生成
|
||
* 自动筛选
|
||
* 必要时局部修补
|
||
|
||
不要把一致性问题只交给 prompt。
|
||
|
||
---
|
||
|
||
## 9. ControlNet、参考图和编辑系统
|
||
|
||
---
|
||
|
||
### 9.1 ControlNet 的定位
|
||
|
||
EpeeKit 中，ControlNet 更偏内部控制能力，而不是用户直接面对的核心产品对象。
|
||
|
||
用户不需要理解所有 ControlNet 类型。
|
||
系统应根据任务自动选择适当的结构控制方式。
|
||
|
||
例如：
|
||
|
||
* 人物姿态类任务：优先 pose
|
||
* 轮廓与结构锁定：优先 canny / line
|
||
* 局部构图控制：通过图生图或局部编辑完成
|
||
|
||
第一阶段不应追求支持所有控制类型，而应只保留最有价值的少数几类。
|
||
|
||
---
|
||
|
||
### 9.2 图生图与局部编辑
|
||
|
||
图生图和局部编辑在系统中非常关键，因为它们决定了：
|
||
|
||
* 第一轮生成结果不满意时是否能延续修改
|
||
* 是否能在不重来的前提下保住已有价值
|
||
* 是否能形成真正的“生产”而不是“重抽奖”
|
||
|
||
因此 EpeeKit 必须支持：
|
||
|
||
* 基础 img2img
|
||
* 局部 inpaint
|
||
* 遮罩上传或自动生成
|
||
* 结果版本回溯
|
||
|
||
---
|
||
|
||
## 10. 训练中心设计
|
||
|
||
---
|
||
|
||
### 10.1 训练中心不是“附属功能”，而是沉淀系统能力的核心
|
||
|
||
训练中心的意义在于让系统逐渐具备：
|
||
|
||
* 项目专属风格
|
||
* 角色专属视觉身份
|
||
* 更高的一致性和复用能力
|
||
|
||
所以训练中心必须是产品化模块，不是裸露的训练入口。
|
||
|
||
---
|
||
|
||
### 10.2 第一阶段建议支持的训练类型
|
||
|
||
* 风格 LoRA
|
||
* 角色 LoRA
|
||
|
||
第一阶段不建议铺开太多训练类型。
|
||
|
||
---
|
||
|
||
### 10.3 训练中心应包含的功能
|
||
|
||
* 批量上传参考图
|
||
* 项目归属绑定
|
||
* 自动去重
|
||
* 自动质量检查
|
||
* 基础数据清洗建议
|
||
* 训练模板选择
|
||
* 训练任务排队
|
||
* 训练状态监控
|
||
* 训练结果对比预览
|
||
* 模型版本管理
|
||
* 回滚与弃用机制
|
||
|
||
---
|
||
|
||
### 10.4 自动化边界
|
||
|
||
用户应尽量以“选图”为主，而不是理解训练细节。
|
||
但系统不宜在第一版完全黑盒自动训练。
|
||
|
||
更合理的是：
|
||
|
||
#### 第一阶段
|
||
|
||
半自动：
|
||
|
||
* 系统自动检查
|
||
* 用户最终确认训练集和目标
|
||
|
||
#### 第二阶段
|
||
|
||
增强自动化：
|
||
|
||
* 自动风格聚类
|
||
* 自动样本筛选
|
||
* 自动参数推荐
|
||
* 自动评估报告
|
||
|
||
---
|
||
|
||
## 11. 评估与质检层
|
||
|
||
---
|
||
|
||
### 11.1 为什么必须有评估层
|
||
|
||
如果没有评估层，系统就只是自动点生成按钮。
|
||
评估层的作用是：
|
||
|
||
* 从多张候选图中筛出更优结果
|
||
* 检测风格偏移
|
||
* 检测角色偏移
|
||
* 减少人工挑图成本
|
||
* 为训练和模板优化积累反馈数据
|
||
|
||
---
|
||
|
||
### 11.2 评估层组成
|
||
|
||
评估层建议包括：
|
||
|
||
#### A. 语义匹配评分
|
||
|
||
评估结果是否符合任务目标。
|
||
|
||
#### B. 风格相似度评分
|
||
|
||
与风格参考集进行相似度计算。
|
||
|
||
#### C. 角色一致性评分
|
||
|
||
与角色参考组进行一致性评估。
|
||
|
||
#### D. 规则检查
|
||
|
||
例如：
|
||
|
||
* 人脸异常
|
||
* 手部异常
|
||
* 边缘问题
|
||
* 构图越界
|
||
* 背景不符合规范
|
||
* 透明背景是否正确
|
||
|
||
#### E. 人工确认
|
||
|
||
最终审美结论仍需要人参与，尤其在高价值资产场景。
|
||
|
||
---
|
||
|
||
### 11.3 评估层的产品作用
|
||
|
||
评估层不是只给用户看分数，而是用来支持：
|
||
|
||
* 自动 rerank
|
||
* 自动重试策略
|
||
* 模板优化
|
||
* 训练效果比较
|
||
* 项目质量控制
|
||
|
||
---
|
||
|
||
## 12. 项目与资产系统
|
||
|
||
---
|
||
|
||
### 12.1 项目是系统最重要的组织单位
|
||
|
||
用户的核心工作对象不应是“单次会话”，而应是“项目”。
|
||
|
||
每个项目中应包含：
|
||
|
||
* 风格系统
|
||
* 角色系统
|
||
* 资源历史
|
||
* 模板集合
|
||
* 训练模型
|
||
* 参考库
|
||
* 输出规范
|
||
* 任务记录
|
||
|
||
---
|
||
|
||
### 12.2 资产类型
|
||
|
||
项目资产至少包括：
|
||
|
||
* 原始参考图
|
||
* 风格集
|
||
* 角色参考组
|
||
* 生成结果图
|
||
* 编辑结果图
|
||
* 控制图
|
||
* 遮罩图
|
||
* LoRA 模型
|
||
* 任务记录
|
||
* 模板副本
|
||
|
||
---
|
||
|
||
### 12.3 项目模板机制
|
||
|
||
系统内模板应分成两类：
|
||
|
||
#### 平台官方模板
|
||
|
||
经过验证、默认推荐、参数范围受控。
|
||
|
||
#### 项目自定义模板
|
||
|
||
从官方模板 fork 后形成，允许项目内部沉淀自己的生产路线。
|
||
|
||
这解决了“既要收敛，又要可扩展”的矛盾。
|
||
|
||
---
|
||
|
||
## 13. 用户体验设计
|
||
|
||
---
|
||
|
||
### 13.1 用户主路径
|
||
|
||
第一阶段的理想体验应是：
|
||
|
||
1. 用户创建项目
|
||
2. 选择或建立风格
|
||
3. 创建角色或导入参考
|
||
4. 通过对话描述需求
|
||
5. 系统自动匹配模板并生成候选
|
||
6. 用户选图或自然语言修改
|
||
7. 结果沉淀为项目资产
|
||
8. 后续继续派生使用
|
||
|
||
---
|
||
|
||
### 13.2 三层交互界面
|
||
|
||
#### 层 1：对话界面
|
||
|
||
面向大多数用户。
|
||
|
||
#### 层 2：任务说明卡
|
||
|
||
向用户展示系统理解到的内容，例如：
|
||
|
||
* 当前任务类型
|
||
* 风格
|
||
* 角色
|
||
* 输出规格
|
||
* 使用的模板
|
||
|
||
#### 层 3：高级面板
|
||
|
||
用于：
|
||
|
||
* 选择控制图
|
||
* 查看候选参数
|
||
* 编辑模板
|
||
* 进入实验模式
|
||
|
||
这样可以避免纯黑盒的不信任感。
|
||
|
||
---
|
||
|
||
## 14. 技术实现建议
|
||
|
||
---
|
||
|
||
### 14.1 后端
|
||
|
||
建议使用 Python 为主的服务栈，负责：
|
||
|
||
* Agent 调度
|
||
* 任务中间层处理
|
||
* 模板匹配
|
||
* 任务排队
|
||
* 训练任务管理
|
||
* 资产元数据管理
|
||
|
||
需要具备：
|
||
|
||
* 标准 API 层
|
||
* 异步任务队列
|
||
* 数据库
|
||
* 对象存储
|
||
* 缓存系统
|
||
|
||
---
|
||
|
||
### 14.2 工作流执行层
|
||
|
||
建议将复杂工作流引擎独立成执行层服务。
|
||
业务层只通过模板和参数调用，不直接耦合节点细节。
|
||
|
||
这样做的好处是：
|
||
|
||
* 易于替换模型
|
||
* 易于扩展新 pipeline
|
||
* 易于控制权限和版本
|
||
|
||
---
|
||
|
||
### 14.3 前端
|
||
|
||
建议采用项目工作台形态，而不是纯聊天形态。
|
||
|
||
基本结构可以是：
|
||
|
||
* 左侧：项目与资产
|
||
* 中间：对话与任务区
|
||
* 右侧：结果、候选、编辑和高级面板
|
||
|
||
---
|
||
|
||
## 15. 风险与应对
|
||
|
||
---
|
||
|
||
### 15.1 风险一：产品野心过大导致失焦
|
||
|
||
#### 风险
|
||
|
||
想同时做 2D、3D、动画、音频、策划，导致第一阶段无法落地。
|
||
|
||
#### 对策
|
||
|
||
坚持阶段化路线，第一阶段只验证 2D 资产生产闭环。
|
||
|
||
---
|
||
|
||
### 15.2 风险二：Agent 失控
|
||
|
||
#### 风险
|
||
|
||
LLM 直接输出不稳定工作流与参数。
|
||
|
||
#### 对策
|
||
|
||
使用：
|
||
|
||
* Task IR
|
||
* 模板注册表
|
||
* 强 schema
|
||
* 校验器
|
||
* 项目约束
|
||
|
||
---
|
||
|
||
### 15.3 风险三：一致性效果被高估
|
||
|
||
#### 风险
|
||
|
||
误以为单模型可以稳定解决风格和角色一致性。
|
||
|
||
#### 对策
|
||
|
||
明确采用系统级组合策略：
|
||
|
||
* 风格集
|
||
* 角色参考组
|
||
* 结构控制
|
||
* 可选 LoRA
|
||
* 自动筛选
|
||
* 局部修补
|
||
|
||
---
|
||
|
||
### 15.4 风险四：训练质量不稳定
|
||
|
||
#### 风险
|
||
|
||
用户上传垃圾数据导致 LoRA 训练无效。
|
||
|
||
#### 对策
|
||
|
||
训练中心产品化，加入数据检查、模板、预览、版本管理。
|
||
|
||
---
|
||
|
||
### 15.5 风险五：工作流数量爆炸
|
||
|
||
#### 风险
|
||
|
||
自由组合导致不可维护。
|
||
|
||
#### 对策
|
||
|
||
默认只允许模板化使用。
|
||
实验模式单独隔离。
|
||
|
||
---
|
||
|
||
### 15.6 风险六：成本失控
|
||
|
||
#### 风险
|
||
|
||
多轮生成、自动重试、训练任务导致资源占用过高。
|
||
|
||
#### 对策
|
||
|
||
即使短期不以盈利为目标，也要以可持续为前提。
|
||
应建立：
|
||
|
||
* 候选数上限
|
||
* 成本等级
|
||
* 模板成本标签
|
||
* 项目资源策略
|
||
* 任务缓存与复用策略
|
||
|
||
---
|
||
|
||
## 16. 第一阶段的最小成功闭环
|
||
|
||
EpeeKit 认为第一阶段最值得追求的不是“功能多”，而是一个强闭环。
|
||
|
||
建议定义为：
|
||
|
||
> 用户在项目内，通过自然语言创建一个 2D 角色；系统生成若干候选；用户通过自然语言继续修改；系统保持风格和角色一致性；最终导出角色相关资源并沉淀到项目资产库。
|
||
|
||
这个闭环至少要包含：
|
||
|
||
* 项目空间
|
||
* 风格选择
|
||
* 角色定义
|
||
* 对话生成
|
||
* 候选筛选
|
||
* 自然语言修改
|
||
* 结果沉淀
|
||
* 可复用派生
|
||
|
||
如果这个闭环做得足够好，系统就具备生命力。
|
||
|
||
---
|
||
|
||
## 17. EpeeKit 最终结论
|
||
|
||
这套方案的本质，不是做一个“更会聊天的生图工具”，而是建立一种新的研发范式：
|
||
|
||
**用 Agent 作为统一语义入口，用模板化工作流作为执行骨架，用项目与资产系统作为长期记忆和约束，从而把 AI 资产生产从“临时创作”推进到“工程化生产”。**
|
||
|
||
它的关键不在于某一个模型，而在于三件事是否成立：
|
||
|
||
* **Task IR**
|
||
* **Pipeline Registry**
|
||
* **Project / Style / Character Asset System**
|
||
|
||
只要这三者成立，系统就不会只是一个 demo，而会逐步变成真正可扩展的游戏资产生产平台。 |