整理资源类型 #368

New Issue

2026-09-15T11:00:53+08:00

k88936 commented

2026-09-15 11:00:53 +08:00

@suzmii 我在改相关的地方注意到这里有:

packages/shared/src/contracts/gameCreationApp.ts:513 线上出现的非 canonical kind → canonical kind 的别名表。

const GAME_CREATION_APP_LEGACY_ASSET_KINDS: Record<
  string,
  GameCreationAppCanonicalAssetKind
> = {
  'game-background': 'scene',
  'character-art': 'character',
  'ui-prototype': 'ui-design',
  ui: 'ui-design',
  'art-spritesheet': 'icon-spritesheet',
  'art-spritesheet-slice': 'icon',
  illustration: 'image',
  'game-art': 'image',
  'game-entry': 'code',
  'game-script': 'code',
  'game-style': 'code',
  animation: 'character-animation',
  asset: 'image',
  font: 'document',
};

我觉得我们需要尽早把资源类型整理到枚举值, 而不是还在开发的时候就做fallback

我看了一下你记录的文档:

来源有: 1. 现有 manifest 2. 当前确实还会写入别名的代码

或者未来从主站迁移过来的生各种资源

其实: 开发阶段没必要做兼容, 别的地方哪里写别名改哪里, 加入类似主站生资源的话我们尽早把客户端这里的和主站的对齐.(可能有别的细节我没考虑到,请反驳我)
你考虑下呗.

@suzmii 我在改相关的地方注意到这里有: > packages/shared/src/contracts/gameCreationApp.ts:513 线上出现的非 canonical kind → canonical kind 的别名表。 ```rust const GAME_CREATION_APP_LEGACY_ASSET_KINDS: Record< string, GameCreationAppCanonicalAssetKind > = { 'game-background': 'scene', 'character-art': 'character', 'ui-prototype': 'ui-design', ui: 'ui-design', 'art-spritesheet': 'icon-spritesheet', 'art-spritesheet-slice': 'icon', illustration: 'image', 'game-art': 'image', 'game-entry': 'code', 'game-script': 'code', 'game-style': 'code', animation: 'character-animation', asset: 'image', font: 'document', }; ``` 我觉得我们需要尽早把资源类型整理到枚举值, 而不是还在开发的时候就做fallback 我看了一下你记录的文档: > 来源有: 1. 现有 manifest 2. 当前确实还会写入别名的代码或者未来从主站迁移过来的生各种资源其实: 开发阶段没必要做兼容, 别的地方哪里写别名改哪里, 加入类似主站生资源的话我们尽早把客户端这里的和主站的对齐.(可能有别的细节我没考虑到,请反驳我) 你考虑下呗.

k88936 added a new dependency 2026-09-15 11:16:33 +08:00

#236 DirectProject 客户端 Skill 自然语言触发能力缺口

k88936 removed a dependency 2026-09-15 11:16:48 +08:00

#236 DirectProject 客户端 Skill 自然语言触发能力缺口

suzmii commented

2026-09-16 11:48:51 +08:00

这个不做兼容的话会导致之前的项目没法用（产品那边做的相对完善的项目都花了不少时间，觉得不能让他们的浪费了），如果没必要向前兼容的我重构下这块吧

突然想到如果需要向前兼容的话可以写个项目迁移的逻辑，确实没必要代码层面fallback

这个不做兼容的话会导致之前的项目没法用（产品那边做的相对完善的项目都花了不少时间，觉得不能让他们的浪费了），如果没必要向前兼容的我重构下这块吧突然想到如果需要向前兼容的话可以写个项目迁移的逻辑，确实没必要代码层面fallback

k88936 commented

2026-09-16 18:38:07 +08:00

这个不做兼容的话会导致之前的项目没法用（产品那边做的相对完善的项目都花了不少时间，觉得不能让他们的浪费了），如果没必要向前兼容的我重构下这块吧

突然想到如果需要向前兼容的话可以写个项目迁移的逻辑，确实没必要代码层面fallback

我试着做了一些了, 可以写个一次性的python脚本给策划把已有的项目迁过来(好像只改那个清单就行),

以后到处都用枚举值, 需要的话在解析的时候做迁移就好了

> 这个不做兼容的话会导致之前的项目没法用（产品那边做的相对完善的项目都花了不少时间，觉得不能让他们的浪费了），如果没必要向前兼容的我重构下这块吧 > > 突然想到如果需要向前兼容的话可以写个项目迁移的逻辑，确实没必要代码层面fallback 我试着做了一些了, 可以写个一次性的python脚本给策划把已有的项目迁过来(好像只改那个清单就行), 以后到处都用枚举值, 需要的话在解析的时候做迁移就好了

❤️ 1

k88936 referenced a pull request that will close this issue

2026-09-16 18:40:17 +08:00

refactor/整理现有的string-typed资源类型 #388

k88936 closed this issue

2026-09-19 03:51:33 +08:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GenarrativeAI/Genarrative#368