Evilom
106 lines
6.8 KiB
Markdown
106 lines
6.8 KiB
Markdown
# QR6uwinsWikNQnkiQrzcvtUnnDe
|
||
|
||
Source: https://my.feishu.cn/wiki/QR6uwinsWikNQnkiQrzcvtUnnDe
|
||
|
||
|
||
# 2026.5.23 工作日报
|
||
## 今日内容概述
|
||
### 1. cc game studio 决策文档推进
|
||
- 继续推进 architecture-review 相关工作，围绕补齐审查文档，并持续修正读取参数问题。
|
||
### 2. AI 游戏项目基础设施思考与 Spine 工具链调研
|
||
- 对原生 AI 游戏项目需要提前沉淀的决策记录、任务拆解、验证、遥测、实验、内容生产、回归保护、运营学习等基座做了整理。
|
||
- 同时对 Spine 动画相关的 AI 自动化/半自动化方案做了调研，初步筛选出可继续验证的方向，也排除了几条依赖抽卡、难以微调或局部优化的路线。
|
||
## 一、审查推进
|
||
**核心问题**
|
||
**调研重点**
|
||
- 持续补齐 requirements-traceability.md 之外的审查报告与登记表。
|
||
- 通过正确的读取方式继续推进剩余文件验证，避免流程被参数错误反复打断。
|
||
- 同步整理日报提取素材，让会话记录能够稳定沉淀为可复用的日报输入。
|
||
**结果**
|
||
- requirements-traceability.md 已更新到位。
|
||
- 当前审查流程已经从“资料不完整”推进到“还需继续补完与验证”的阶段。
|
||
**结论**
|
||
- 这条线当前最重要的不是扩写内容，而是先把流程跑稳，把剩余文件补齐并核对结果。
|
||
- 读取参数问题属于流程性阻塞，后续需要通过固定正确操作方式来避免重复发生。
|
||
## 二、AI 游戏项目基础设施与 Spine 调研
|
||
### 1. AI 游戏项目基础设施梳理
|
||
**定位**
|
||
- 不是先追求大而全的平台，而是先把能支撑 AI 持续产出、持续验证、持续迭代的基础设施沉淀出来。
|
||
**调研重点**
|
||
#### （1）决策记录基座
|
||
- ADR、设计决策、数值决策、范围裁剪原因都需要沉淀。
|
||
- 目的：让后续 AI 不只是看到结果，还能理解“为什么这样定”。
|
||
#### （2）任务拆解基座
|
||
- 将工作拆为 大目标 → 场景需求 → 任务 → 验证证据。
|
||
- 每个任务要有输入文档、产出文件、验收标准、推荐 agent。
|
||
- 目的：让 Claude Code 接任务时尽量不靠临场猜。
|
||
#### （3）验证基座
|
||
- 自动测试、烟测清单、手动验证记录、截图证据、playtest 反馈都需要积累。
|
||
- 目的：AI 生成越多，越需要机器可验证的质量闸门。
|
||
#### （4）遥测 / 数据基座
|
||
- 埋点事件、玩家行为漏斗、失败点、留存、广告触发、战斗节奏数据等需要提前设计。
|
||
- 目的：上线后能基于真实数据调优，而不是凭感觉。
|
||
#### （5）实验基座
|
||
- A/B 测试、配置灰度、远程数值表、实验记录都要保留。
|
||
- 目的：AI 不直接“改线上体验”，而是先提出实验，再根据结果固化。
|
||
#### （6）内容生产基座
|
||
- 美术资产规格、命名规则、导入规则、Prompt 模板、可复用素材库需要统一。
|
||
- 目的：让美术、音频、文案、关卡内容可以批量产出且风格一致。
|
||
#### （7）回归保护基座
|
||
- 每次 AI 修改后，要知道会影响哪些系统、该跑哪些测试、该看哪些截图。
|
||
- 目的：后期不能靠“全项目重读”，而要靠影响范围索引。
|
||
#### （8）运营学习基座
|
||
- 玩家反馈、版本复盘、热修记录、社区问题、差评原因都要持续记录。
|
||
- 目的：每一轮运营都能变成下一轮 AI 决策的上下文。
|
||
**结论**
|
||
|
||
> :beach_with_umbrella:
|
||
- 知识库更像 AI 的基础设施，作用类似互联网时代公司的数据库。
|
||
- 文档驱动本身也有风险，尤其是负责全流程管理的状态文档容易出现“流程已完成但状态未更新”的问题，这一点后续要特别注意。
|
||
### 2. Spine 动画工具链调研
|
||
**核心问题**
|
||
**调研结果**
|
||
#### （1）龙骨动画（LoongBones）
|
||
- 通过自然语言描述生成动画关键帧，定位为 Spine 的搭档。
|
||
- 结论：可以考虑作为 spine 动作开发的副手，但还需要用实际动作验证效率提升，有订阅成本。
|
||
#### （2）Godmode AI
|
||
- 允许上传角色图片并自动绑定骨骼、应用预置动画。
|
||
- 结论：不可用，主要以 3D 为主，且不可微调。
|
||
#### （3）视频 → 序列帧 → Spine 序列帧链路
|
||
- 这一路线依赖抽卡式序列帧生成，难以做定向修改和局部优化。
|
||
- 结论：不可用。
|
||
#### （4）Spine 动画转序列帧动画
|
||
- 本质仍是序列帧方案，不适合作为 Spine 动作制作主路线。
|
||
- 结论：不可用。
|
||
#### （5）Spine 网页付费在线生成
|
||
- 测试后发现其宣称的 Spine 换皮能力不符合预期。
|
||
- 结论：不可用。
|
||
#### （6）Spine Animation AI 开源工具链
|
||
- 通过对话驱动实现动画生成自动化，但目前效果受提示词和多轮沟通影响较大，且只支持人形态。
|
||
- 结论：极少数情况下可以产出接近要求的待机动作，但稳定性和泛化能力都不足。
|
||
**结果**
|
||
- 已经把可行路线和不可行路线做了初步区分。
|
||
- 当前更值得继续观察的是“能对 Spine 动作开发起辅助作用”的方向，而不是依赖抽卡或序列帧替代 Spine 本身。
|
||
**结论**
|
||
- 这次调研的重点不是找一个“万能生成器”，而是判断哪些方案能真正进入动作开发流程。
|
||
|
||
> :monkey_face:
|
||
- 现阶段较明确的判断是：暂未发现合适AI工具能直接高效进行spine动作制作. 能微调、能局部优化、能配合 Spine 工作流的工具才值得继续验证。
|
||
## 三、阶段性结论
|
||
### 1. 审查推进这条线
|
||
**结论**
|
||
- 流程已经进入补齐和验证阶段，当前的关键是收尾而不是扩张。
|
||
- 读取参数问题必须被当成流程规范问题处理，避免重复消耗推进效率。
|
||
### 2. AI 游戏项目基础设施这条线
|
||
**结论**
|
||
- 真正值得优先沉淀的，不是单个工具，而是能支撑后续反复迭代的底层机制。
|
||
- 决策、任务、验证、数据、实验、内容、回归、运营这 8 类基座，基本构成了 AI 游戏项目的长期工作骨架。
|
||
### 3. Spine 调研这条线
|
||
**判断**
|
||
- 绝大多数“自动生成 Spine 动画”的现成方案仍然停留在包装层或序列帧层，离实际可控生产还有距离。
|
||
- 现阶段更适合继续看可辅助、可微调、可嵌入现有动作开发流程的方案。
|
||
## 四、下一步工作思考
|
||
**后续推进方向**
|
||
- 对 nvmojian 的 stand 动作继续做预览确认，重点看披风、毛发和整体循环是否自然。
|
||
- 如果后续继续调研 Spine 工具链，优先验证能否真正进入工作流，而不是停留在演示效果。
|
||
- 尝试了解像素风的steam游戏/像素风相关的技术栈/工具 |