feat: 飞书文档深度分析与知识库构建
- 分析 147 篇下载的飞书文档 - 生成全面分析报告（feishu_docs_comprehensive_analysis.md） - 生成主题深度分析（feishu_docs_topic_analysis.md） - 生成关键发现摘要（key_findings.json） - 创建 Obsidian 知识库条目（飞书文档知识库.md） - 更新 MOC 索引 分析结果： - 花园世界研究：22 篇文档 - AI与Agent应用：109 篇文档 - 工作流优化：62 篇文档 - 竞品分析：59 篇文档 - 商业化策略：48 篇文档 - 产品策略：56 篇文档 - 技术实现：103 篇文档 - 美术资产：100 篇文档
This commit is contained in:
Evilom
@@ -0,0 +1,470 @@
|
||||
# 飞书文档主题深度分析
|
||||
|
||||
> 基于 147 篇下载文档的深度内容分析
|
||||
|
||||
---
|
||||
|
||||
## 花园世界 (22 篇)
|
||||
|
||||
### AbLed72FgoPn5hxOYN3cRpffn0E
|
||||
|
||||
- 这种设计
|
||||
- 将玩家的“休闲时间”转变为“资源经营时间”
|
||||
[图表]
|
||||
|
||||
### 花卉品级与培育体系
|
||||
玩家生态：资源阶梯
|
||||
|
||||
|
||||
花卉品级（凡/普/珍/华/仙）
|
||||
本质上是玩家在游戏内资源投入的权重排序
|
||||
- 业务部门可据此通过活动礼包的方式精准投放缺口材料，以换取用户的留存与消费
|
||||
- 竞争增量（效能评价）
|
||||
-
|
||||
|
||||
- 《我的花园世界》之所以能领先同行，就在于它
|
||||
- 不盲目增加内容，而是通过
|
||||
- 订单消耗的规模化
|
||||
- 与
|
||||
- 货币功能的碎片化
|
||||
- ，在有限的业务资源内，实现了玩家活跃度与单位付费收益的最大化
|
||||
|
||||
### ExYndBzwSoEobXxqgiicDkionnh
|
||||
|
||||
- - 完成了从飞书搜索、读取、同步到本地的真实链路
|
||||
-
|
||||
|
||||
### FTO7d8y5BoBDj9xDQWHcWcmSn5W
|
||||
|
||||
- 也是“产品是否值得继续往这个方向做”的
|
||||
早期信号
|
||||
|
||||
1. 产品设计和获客表达越来越早绑定
|
||||
三消+SLG、解谜+SLG、副玩法入口等案例都说明，很多出海产品在产品结构未定阶段就考虑用户如何被吸引进来
|
||||
|
||||
1. 素材、商店页、包体一致（看测试目的，留存测试必须一致）
|
||||
素材能带来点击，商店页决定是否转化，包体决定用户是否留下
|
||||
- 三个环节如果不一致，数据就很难解释
|
||||
|
||||
1. 测试要分层，不同指标回答不同问题
|
||||
CTR(点击率) 更适合看吸引力，CVR(点击转化率) 更适合看商店页承接，留存更适合看包体体验
|
||||
|
||||
### FWfQd4Xl6ojWh5xu87rcOIq4nye
|
||||
|
||||
- 在每一阶段结束后，必须进行系统的“整合优化”，而不是盲目增加新功能
|
||||
运营解耦：让活动实现“自循环”
|
||||
- 启示
|
||||
-
|
||||
|
||||
- 建立一套标准化的活动组件库，通过常驻轮换取代单次定制
|
||||
-
|
||||
- 这不仅能大幅降低研发部的需求积压，还能通过不同周期的组合，为玩家提供长期的“新鲜感”，确保用户留存不依赖于某一个特定的活动
|
||||
商业进化：体验付费优于数值付费
|
||||
- 启示
|
||||
-
|
||||
|
||||
- 商业化迭代的终极目的是降低玩家的“挫败感”
|
||||
|
||||
### GNtTdHLGuoSXITxbRhrc8AH1nxd
|
||||
|
||||
- 每一层的资源获取率故意设定为50%-80%（打开缺口），强制玩家通过小额充值填补“战力缺口”
|
||||
- 沉没成本
|
||||
-
|
||||
|
||||
- 利用玩家前期积累的养成数据，锁定玩家的参与意愿
|
||||
- 阶段二：解决流失/口碑问题
|
||||
- 目标：
|
||||
- 在保持高ARPU的同时，降低用户因“被剥削感”而导致的流失风险
|
||||
- 检查逻辑：
|
||||
- 当系统设置“高额付费点”时，是否配置了相应的“心理补偿物”（稀有展示、社交特权等）
|
||||
|
||||
阶段三：解决活跃与粘性问题
|
||||
- 目标：
|
||||
- 通过社交系统强制提升单周活跃度，从而实现利润变现
|
||||
- 检查逻辑：
|
||||
- 社交系统的运营成本是否低于其带来的用户贡献价值
|
||||
|
||||
---
|
||||
|
||||
## AI与Agent (109 篇)
|
||||
|
||||
### ACLuwapXRiUYX8ktOaNceqftn4g
|
||||
|
||||
- 游戏设计注重强竞争和氪金，降低成本，追求脉冲峰值和长尾收益
|
||||
- 案例
|
||||
以英勇之地为例，其在 Steam 上的爆发为手游带来了渠道推荐的短期高峰，验证了该战略的可行性
|
||||
|
||||
### AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
- 以前每单奖励都是固定的数值
|
||||
现在每一单都能单独配金币奖励，前面简单一点，后面奖励和难度一起往上走
|
||||
- 以前生成器解锁是静态的
|
||||
现在改成了“攒够金币、推进到剧情节点后，逐步解锁新生成器”，比如先开面包，再慢慢开饮料、甜点
|
||||
|
||||
### AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
- # AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
# 工作内容概述
|
||||
1. 美术AI工具调研与尝试
|
||||
1. ：尝试了2D游戏素材生成，包括Holopix、Banana、SD等，生成了一批临时素材
|
||||
- 1. 产品设计文档深化与临时配表
|
||||
1. ：
|
||||
- 检查并完善了昨日设计文档的初始框架
|
||||
|
||||
### B9Ofw7pPVix7FFk2XzOcyGoRnlc
|
||||
|
||||
- ### 去绿幕：后期兜底与生成端脏数据
|
||||
- 实测痛点：
|
||||
- 边缘抠不干净，根本原因不在于后期去色算法不够好，而是大模型前置生成图的背景本身就不纯
|
||||
- - 调参困境：
|
||||
- 目前用的 精确颜色剔除 → 色相范围兜底 流水线，处理纯绿背景没问题
|
||||
|
||||
### BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
- # BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
Source: https://ocnmca6f1o0p.feishu.cn/wiki/BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
## 工作内容概述
|
||||
1、研究通过让AI来生成Spine跟特效
|
||||
[文件]
|
||||
## 一. 让生图模型一次出多张图
|
||||
问题背景
|
||||
： Spine 动画需要角色在不同姿态、不同表情下保持是"同一个人"
|
||||
- 但生图模型的常见痛点是——同一个角色描述跑两次，出来的脸、发型、配色都会有微妙的不一样
|
||||
|
||||
---
|
||||
|
||||
## 工作流 (62 篇)
|
||||
|
||||
### AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
- 以前每单奖励都是固定的数值
|
||||
现在每一单都能单独配金币奖励，前面简单一点，后面奖励和难度一起往上走
|
||||
- 以前生成器解锁是静态的
|
||||
现在改成了“攒够金币、推进到剧情节点后，逐步解锁新生成器”，比如先开面包，再慢慢开饮料、甜点
|
||||
|
||||
### B9Ofw7pPVix7FFk2XzOcyGoRnlc
|
||||
|
||||
- ### 去绿幕：后期兜底与生成端脏数据
|
||||
- 实测痛点：
|
||||
- 边缘抠不干净，根本原因不在于后期去色算法不够好，而是大模型前置生成图的背景本身就不纯
|
||||
- - 调参困境：
|
||||
- 目前用的 精确颜色剔除 → 色相范围兜底 流水线，处理纯绿背景没问题
|
||||
|
||||
### BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
- # BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
Source: https://ocnmca6f1o0p.feishu.cn/wiki/BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
## 工作内容概述
|
||||
1、研究通过让AI来生成Spine跟特效
|
||||
[文件]
|
||||
## 一. 让生图模型一次出多张图
|
||||
问题背景
|
||||
： Spine 动画需要角色在不同姿态、不同表情下保持是"同一个人"
|
||||
- 但生图模型的常见痛点是——同一个角色描述跑两次，出来的脸、发型、配色都会有微妙的不一样
|
||||
|
||||
### Bf4mwuFU9in51RksjDDc5Fdgnag
|
||||
|
||||
- 核心思路是：
|
||||
- 尽量去除强绑定内容，比如复杂纹路图案、不可复用装饰等；
|
||||
- 保留通用的边框、底色、材质等；
|
||||
- 可以通过九宫格拉伸适配不同尺寸；
|
||||
- 让同一张资源可以应用到按钮、面板、棋盘单元格或其他 UI 容器中
|
||||
- 这样做的好处比较明确：一方面可以提升资源复用率，减少不同尺寸、不同场景下重复生成相似资源的情况；另一方面也能降低包体大小压力，避免大量近似 UI 资源同时进入项目
|
||||
|
||||
### BrBUdkTEPoCjsCxtxDWcBFsungg
|
||||
|
||||
- 当前更重要的方向，不是追求“大而全”的技术平台，也不是挑战短期难以落地的高度自动化目标，而是
|
||||
识别
|
||||
现有项目生产过程中真实存在的效率瓶颈、流程卡点和资源消耗问题
|
||||
，并判断 AI 是否能够在这些环节中形成可验证、可复用、可持续的效率提升
|
||||
- 从经营角度看，AI 应用需要避免两个偏差
|
||||
：
|
||||
-
|
||||
- 一是目标过低
|
||||
- ，只停留在个人效率提升，难以形成组织层面的竞争优势
|
||||
|
||||
---
|
||||
|
||||
## 竞品分析 (59 篇)
|
||||
|
||||
### AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
- 以前每单奖励都是固定的数值
|
||||
现在每一单都能单独配金币奖励，前面简单一点，后面奖励和难度一起往上走
|
||||
- 以前生成器解锁是静态的
|
||||
现在改成了“攒够金币、推进到剧情节点后，逐步解锁新生成器”，比如先开面包，再慢慢开饮料、甜点
|
||||
|
||||
### B9Ofw7pPVix7FFk2XzOcyGoRnlc
|
||||
|
||||
- ### 去绿幕：后期兜底与生成端脏数据
|
||||
- 实测痛点：
|
||||
- 边缘抠不干净，根本原因不在于后期去色算法不够好，而是大模型前置生成图的背景本身就不纯
|
||||
- - 调参困境：
|
||||
- 目前用的 精确颜色剔除 → 色相范围兜底 流水线，处理纯绿背景没问题
|
||||
|
||||
### BOWJwOqOxiARunkCc9Ac3nKwnZS
|
||||
|
||||
- [图表]
|
||||
第二步：数据导入
|
||||
每月编制时，仅需将当月5张子表底稿文件拖入工具指定目录
|
||||
- [图表]
|
||||
第三步：一键生成
|
||||
|
||||
|
||||
脚本自动完成源表数据定位、条件筛选、聚合计算，一键输出总表及三张利润子表(利润表-分产品、利润表-分地区、利润表-按月)
|
||||
|
||||
### CRV1dW7OtoFhVixTuskcvXiGn6d
|
||||
|
||||
- 操作流程：
|
||||
数据源底稿 → 映射关系&计算逻辑 → 标准中间表 → 月度管理报表
|
||||
|
||||
#### （一）方案调研与当前阶段推进原则
|
||||
今天同步调研了几类数据自动化方案，包括直接上传 AI、Excel / Power Query、RPA、本地 Python 脚本以及 Dify / 私有化平台等
|
||||
- 初步判断，当前月报涉及多份底稿、多 Sheet、字段映射、特殊规则和跨表计算，直接上传 AI 虽然方便，但在数据安全、口径稳定和长期复用方面不够稳
|
||||
|
||||
### DcOkwuOj6iPvdWkaFD1clKuRnAB
|
||||
|
||||
- 但是只有微信流量主才能申请广告位ID，而达成流量主的条件比较麻烦，需要小游戏至少有1000人的用户量
|
||||
- 以下以合并成功事件为例子进行展示
|
||||
[图表]
|
||||
[图表]
|
||||
- 也可以在平台的仪表盘中查看数据
|
||||
[图表]
|
||||
## 2.5 基础功能线——按玩家成长进度解锁生成器，通过新增按钮添加生成器到棋盘中
|
||||
- 该功能主要是为了适配关卡进度的推进而设计，玩家金币越多，解锁的生成器越多
|
||||
## 2.6 在接入微信开发者工具时测试广告时，发现切换分辨率后，UI会乱
|
||||
|
||||
---
|
||||
|
||||
## 商业化 (48 篇)
|
||||
|
||||
### AbLed72FgoPn5hxOYN3cRpffn0E
|
||||
|
||||
- 这种设计
|
||||
- 将玩家的“休闲时间”转变为“资源经营时间”
|
||||
[图表]
|
||||
|
||||
### 花卉品级与培育体系
|
||||
玩家生态：资源阶梯
|
||||
|
||||
|
||||
花卉品级（凡/普/珍/华/仙）
|
||||
本质上是玩家在游戏内资源投入的权重排序
|
||||
- 业务部门可据此通过活动礼包的方式精准投放缺口材料，以换取用户的留存与消费
|
||||
- 竞争增量（效能评价）
|
||||
-
|
||||
|
||||
- 《我的花园世界》之所以能领先同行，就在于它
|
||||
- 不盲目增加内容，而是通过
|
||||
- 订单消耗的规模化
|
||||
- 与
|
||||
- 货币功能的碎片化
|
||||
- ，在有限的业务资源内，实现了玩家活跃度与单位付费收益的最大化
|
||||
|
||||
### AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
- 以前每单奖励都是固定的数值
|
||||
现在每一单都能单独配金币奖励，前面简单一点，后面奖励和难度一起往上走
|
||||
- 以前生成器解锁是静态的
|
||||
现在改成了“攒够金币、推进到剧情节点后，逐步解锁新生成器”，比如先开面包，再慢慢开饮料、甜点
|
||||
|
||||
### DcOkwuOj6iPvdWkaFD1clKuRnAB
|
||||
|
||||
- 但是只有微信流量主才能申请广告位ID，而达成流量主的条件比较麻烦，需要小游戏至少有1000人的用户量
|
||||
- 以下以合并成功事件为例子进行展示
|
||||
[图表]
|
||||
[图表]
|
||||
- 也可以在平台的仪表盘中查看数据
|
||||
[图表]
|
||||
## 2.5 基础功能线——按玩家成长进度解锁生成器，通过新增按钮添加生成器到棋盘中
|
||||
- 该功能主要是为了适配关卡进度的推进而设计，玩家金币越多，解锁的生成器越多
|
||||
## 2.6 在接入微信开发者工具时测试广告时，发现切换分辨率后，UI会乱
|
||||
|
||||
### DeOCwJ8GZibah7ktWnmcChjEnWf
|
||||
|
||||
- 此前开题阶段更偏向《烽火逐盟》，主要因为它更符合“多人社交竞争游戏”“联盟竞赛”“团体赛季制”“平台生态治理”等原有框架
|
||||
- 但进入正式论文阶段后，不能只看活动是否符合开题表述，还要进一步判断它是否能支撑后续实证分析
|
||||
|
||||
### Euhbwrg5Ti3BLnkk6VEctad8nze
|
||||
|
||||
- #### （二）目前财务报表数据情况
|
||||
- 目前财务报表的数据来源比较分散，涉及不同底稿、不同 Sheet、不同字段和不同取数条件
|
||||
- - 如果每个月都靠人工手动处理，重复性工作较多，也容易因为口径理解、字段位置变化、筛选条件遗漏等问题导致错误
|
||||
[表格]
|
||||
工程化设计的核心逻辑：
|
||||
这套设计参考了游戏策划配置表的工程思路——先定义字段、编码、类型和规则，程序按照配置驱动执行
|
||||
|
||||
---
|
||||
|
||||
## 产品策略 (56 篇)
|
||||
|
||||
### AbLed72FgoPn5hxOYN3cRpffn0E
|
||||
|
||||
- 这种设计
|
||||
- 将玩家的“休闲时间”转变为“资源经营时间”
|
||||
[图表]
|
||||
|
||||
### 花卉品级与培育体系
|
||||
玩家生态：资源阶梯
|
||||
|
||||
|
||||
花卉品级（凡/普/珍/华/仙）
|
||||
本质上是玩家在游戏内资源投入的权重排序
|
||||
- 业务部门可据此通过活动礼包的方式精准投放缺口材料，以换取用户的留存与消费
|
||||
- 竞争增量（效能评价）
|
||||
-
|
||||
|
||||
- 《我的花园世界》之所以能领先同行，就在于它
|
||||
- 不盲目增加内容，而是通过
|
||||
- 订单消耗的规模化
|
||||
- 与
|
||||
- 货币功能的碎片化
|
||||
- ，在有限的业务资源内，实现了玩家活跃度与单位付费收益的最大化
|
||||
|
||||
### ACLuwapXRiUYX8ktOaNceqftn4g
|
||||
|
||||
- 游戏设计注重强竞争和氪金，降低成本，追求脉冲峰值和长尾收益
|
||||
- 案例
|
||||
以英勇之地为例，其在 Steam 上的爆发为手游带来了渠道推荐的短期高峰，验证了该战略的可行性
|
||||
|
||||
### B9Ofw7pPVix7FFk2XzOcyGoRnlc
|
||||
|
||||
- ### 去绿幕：后期兜底与生成端脏数据
|
||||
- 实测痛点：
|
||||
- 边缘抠不干净，根本原因不在于后期去色算法不够好，而是大模型前置生成图的背景本身就不纯
|
||||
- - 调参困境：
|
||||
- 目前用的 精确颜色剔除 → 色相范围兜底 流水线，处理纯绿背景没问题
|
||||
|
||||
### DeOCwJ8GZibah7ktWnmcChjEnWf
|
||||
|
||||
- 此前开题阶段更偏向《烽火逐盟》，主要因为它更符合“多人社交竞争游戏”“联盟竞赛”“团体赛季制”“平台生态治理”等原有框架
|
||||
- 但进入正式论文阶段后，不能只看活动是否符合开题表述，还要进一步判断它是否能支撑后续实证分析
|
||||
|
||||
### EIWNwKjnIipmStkzIr1cd1kTnPf
|
||||
|
||||
- # EIWNwKjnIipmStkzIr1cd1kTnPf
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/EIWNwKjnIipmStkzIr1cd1kTnPf
|
||||
|
||||
# 一.工作内容概述
|
||||
- 尝试优化AI自动化关卡生成逻辑
|
||||
- 尝试优化自动化关卡截图分析流程
|
||||
- 体验《佛系消消消》，补充收集部分关卡样本，作为后续分析参考
|
||||
- [文件]
|
||||
# 二.关卡生成逻辑优化
|
||||
## 目前关卡生成痛点
|
||||
目前关卡生成的主要问题集中在高维度关卡，尤其是
|
||||
10x10
|
||||
、
|
||||
12x12
|
||||
这类关卡
|
||||
|
||||
---
|
||||
|
||||
## 技术实现 (103 篇)
|
||||
|
||||
### ACLuwapXRiUYX8ktOaNceqftn4g
|
||||
|
||||
- 游戏设计注重强竞争和氪金，降低成本，追求脉冲峰值和长尾收益
|
||||
- 案例
|
||||
以英勇之地为例，其在 Steam 上的爆发为手游带来了渠道推荐的短期高峰，验证了该战略的可行性
|
||||
|
||||
### AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
- 以前每单奖励都是固定的数值
|
||||
现在每一单都能单独配金币奖励，前面简单一点，后面奖励和难度一起往上走
|
||||
- 以前生成器解锁是静态的
|
||||
现在改成了“攒够金币、推进到剧情节点后，逐步解锁新生成器”，比如先开面包，再慢慢开饮料、甜点
|
||||
|
||||
### AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
- # AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
# 工作内容概述
|
||||
1. 美术AI工具调研与尝试
|
||||
1. ：尝试了2D游戏素材生成，包括Holopix、Banana、SD等，生成了一批临时素材
|
||||
- 1. 产品设计文档深化与临时配表
|
||||
1. ：
|
||||
- 检查并完善了昨日设计文档的初始框架
|
||||
|
||||
### B9Ofw7pPVix7FFk2XzOcyGoRnlc
|
||||
|
||||
- ### 去绿幕：后期兜底与生成端脏数据
|
||||
- 实测痛点：
|
||||
- 边缘抠不干净，根本原因不在于后期去色算法不够好，而是大模型前置生成图的背景本身就不纯
|
||||
- - 调参困境：
|
||||
- 目前用的 精确颜色剔除 → 色相范围兜底 流水线，处理纯绿背景没问题
|
||||
|
||||
### BOWJwOqOxiARunkCc9Ac3nKwnZS
|
||||
|
||||
- [图表]
|
||||
第二步：数据导入
|
||||
每月编制时，仅需将当月5张子表底稿文件拖入工具指定目录
|
||||
- [图表]
|
||||
第三步：一键生成
|
||||
|
||||
|
||||
脚本自动完成源表数据定位、条件筛选、聚合计算，一键输出总表及三张利润子表(利润表-分产品、利润表-分地区、利润表-按月)
|
||||
|
||||
---
|
||||
|
||||
## 美术资产 (100 篇)
|
||||
|
||||
### ACLuwapXRiUYX8ktOaNceqftn4g
|
||||
|
||||
- 游戏设计注重强竞争和氪金，降低成本，追求脉冲峰值和长尾收益
|
||||
- 案例
|
||||
以英勇之地为例，其在 Steam 上的爆发为手游带来了渠道推荐的短期高峰，验证了该战略的可行性
|
||||
|
||||
### AjK2wPpI7iOFo5kOImVcEe1WnNS
|
||||
|
||||
- 以前每单奖励都是固定的数值
|
||||
现在每一单都能单独配金币奖励，前面简单一点，后面奖励和难度一起往上走
|
||||
- 以前生成器解锁是静态的
|
||||
现在改成了“攒够金币、推进到剧情节点后，逐步解锁新生成器”，比如先开面包，再慢慢开饮料、甜点
|
||||
|
||||
### AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
- # AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
Source: https://dianchukeji.feishu.cn/wiki/AqzvwhCH9iKYfbkQ5iacMuKJnMe
|
||||
|
||||
# 工作内容概述
|
||||
1. 美术AI工具调研与尝试
|
||||
1. ：尝试了2D游戏素材生成，包括Holopix、Banana、SD等，生成了一批临时素材
|
||||
- 1. 产品设计文档深化与临时配表
|
||||
1. ：
|
||||
- 检查并完善了昨日设计文档的初始框架
|
||||
|
||||
### B9Ofw7pPVix7FFk2XzOcyGoRnlc
|
||||
|
||||
- ### 去绿幕：后期兜底与生成端脏数据
|
||||
- 实测痛点：
|
||||
- 边缘抠不干净，根本原因不在于后期去色算法不够好，而是大模型前置生成图的背景本身就不纯
|
||||
- - 调参困境：
|
||||
- 目前用的 精确颜色剔除 → 色相范围兜底 流水线，处理纯绿背景没问题
|
||||
|
||||
### BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
- # BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
Source: https://ocnmca6f1o0p.feishu.cn/wiki/BaZIwUkMli87D4k9raUcuWSBnXe
|
||||
|
||||
## 工作内容概述
|
||||
1、研究通过让AI来生成Spine跟特效
|
||||
[文件]
|
||||
## 一. 让生图模型一次出多张图
|
||||
问题背景
|
||||
： Spine 动画需要角色在不同姿态、不同表情下保持是"同一个人"
|
||||
- 但生图模型的常见痛点是——同一个角色描述跑两次，出来的脸、发型、配色都会有微妙的不一样
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user