771619c7da
- 多session分工总账 §2/§5/§7 重定:域切→角色切(Mac全开发按计划执行 / 6c6g设计·计划·评审·文档·优化);Mac工作清单(plan001 SAA产线化Tier0 + plan002 Tier-1剩4域 + 前端8页)+ 6c6g大脑角色 + 协调约束(git中介·够不到Mac) - 收编他session未提交:orchestrator *_walk脚本×6 + v1对话生成修改素材/ v2生命周期项目管理 review + prefix-cache preflight(保全) - _index修漂移:v2=ACTIVE范式基座(改源不改包)、v1=留痕(前提被supersede); 生成域canonical现归本session(6c6g)维护 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
134 lines
9.1 KiB
Markdown
134 lines
9.1 KiB
Markdown
# 生成主线 v2:游戏全生命周期项目管理(LLM as 工作室) — review 版
|
|
|
|
> 类型:review 版(基座重构,结论先行,供决策)。日期:2026-06-17 · owner:6c6g 领 spec · 评审:codex + opus(v1 已两轮,本 v2 基座变更需再一轮)。
|
|
> **supersede**:本 v2 取代 v1 [`2026-06-17-生成主线-对话生成修改素材-review.md`](2026-06-17-生成主线-对话生成修改素材-review.md);v1 的 D5「改打包产物/可寻址 manifest」被**创始人生命周期重构**整条废除。
|
|
> **触发**:创始人裁定——「系统不生成一次性内容;要长期/可维护/可扩展/灵活/稳定/简单/高效——这是游戏全生命周期管理。LLM 只是替代游戏工作室原本做的事。」
|
|
|
|
---
|
|
|
|
## 1. 结论:范式转变
|
|
|
|
| 旧范式(v1 及之前) | 新范式(本 v2 基座) |
|
|
|---|---|
|
|
| 生成 = 产出一坨可玩 bundle,存下来 | 生成 = LLM(工作室)**创建并长期维护一个游戏源项目** |
|
|
| 修改 = 想办法 diff 打包产物(不可行) | 修改 = 工作室在**源项目**上做一次开发迭代,再构建 |
|
|
| 产物 = 一次性、不可维护的硬编码 blob | 规范物 = **结构化、可维护、数据驱动的源项目**(像工作室的 git 仓) |
|
|
| 打包/发布是终点 | 打包=CI 构建步、发布=一次 release;项目**持续演进** |
|
|
|
|
**一句话**:把游戏建模成**长生命周期的软件项目**,LLM 是它的**工作室**;create/modify/extend/build/release/maintain 都是项目生命周期操作。这从根上化解了"怎么改打包产物"的死结——**不碰产物,在源项目上演进,再构建**。
|
|
|
|
---
|
|
|
|
## 2. 现状缺口(当前是"一次性"反模式 · 已核码)
|
|
|
|
- worker 在临时目录生成源 → 打包成单 iife `bundle.iife.js` → 回调**只带打包后的 bundle**(`service.py:199` 注释"游戏逻辑全在 engineBundle 内");`gameConfig` 占位、`assets[]` 空。
|
|
- **源生成完即弃**:后端手里只有不可维护的整包 blob,无源项目、无数据驱动、无可寻址结构 → 无法维护、无法局部改、无法长期演进。
|
|
- 这正是创始人要废的"一次性内容"。
|
|
|
|
---
|
|
|
|
## 3. 规范模型
|
|
|
|
### 3.1 游戏源项目结构(LLM 工作室维护的"仓")
|
|
|
|
```
|
|
game-project/
|
|
├── game.json # 项目元数据(引擎版本/入口/品类templateId/标题/版本)
|
|
├── design.md # GDD:玩法意图/机制/胜负条件(工作室的"需求与设计")
|
|
├── config/
|
|
│ ├── params.json # 平衡参数(数值/难度/速度)——数据驱动,改这里=调平衡
|
|
│ └── levels/ # 关卡数据——加文件=加关卡
|
|
├── src/ # 模块化游戏逻辑(按系统拆:input/spawn/score/physics…)
|
|
├── assets/ # 六类:sprite/character/effect/scene/ui/music(引用,非内联)
|
|
└── build.json # 构建配置
|
|
```
|
|
> 设计驱动力:**因为工作室(LLM)将来要回来改它**,所以必须模块化 + 数据驱动 + 资产分离 + 有 GDD——可定位、可局部改、可扩展。硬编码 blob 不可维护 = 不合格产出。
|
|
|
|
### 3.2 LLM 工作室的生命周期操作 + 构建/发布管线
|
|
|
|
```mermaid
|
|
graph LR
|
|
Brief[一句话/对话+六类素材] --> Scaffold[create:脚手架建项目]
|
|
Scaffold --> Proj[(游戏源项目<br/>版本化·可寻址)]
|
|
Proj --> Build[build:确定性构建<br/>项目→bundle+manifest]
|
|
Build --> Release[release:发布版本→feed过审]
|
|
Release --> Play[玩家试玩]
|
|
Play --> Data[遥测/反馈]
|
|
Data --> Iterate[modify/extend/fix/balance<br/>工作室迭代]
|
|
Iterate --> Proj
|
|
```
|
|
- **create**:brief+模板品类+素材 → 脚手架出结构化项目。
|
|
- **modify**:改某部件——换美术/调参/改关卡 = **确定性编辑源文件(免 LLM、秒级)**;改玩法逻辑 = LLM **只重生成那个模块**。
|
|
- **extend**:加关卡/机制/内容 = 加文件,additive。
|
|
- **build**:源项目 → 可玩 bundle(确定性、可复现;RuntimeBuild 桩转真)。
|
|
- **release**:构建产物发布为版本,过审入 feed(复用现 B1 发布链)。
|
|
- **maintain/iterate**:据遥测/反馈,工作室回项目继续演进(闭环护城河)。
|
|
|
|
---
|
|
|
|
## 4. 七质量 → 生成产出硬契约
|
|
|
|
| 质量 | 落到生成产出的硬约束 |
|
|
|---|---|
|
|
| 长期/可维护 | 模块化代码 + GDD;工作室能回来定位并改 |
|
|
| 可扩展 | additive 内容模型(加关卡/资产/模块不重写) |
|
|
| 灵活 | **数据驱动**(行为走 config/data,不硬编码) |
|
|
| 稳定 | 确定性构建 + 版本化 release + 回滚 + 构建门(九门/质量门) |
|
|
| 简单 | 轻游戏轻结构,不过度工程(够维护即可) |
|
|
| 高效 | 增量改+增量构建;确定性操作免 LLM;复用模块/资产 |
|
|
|
|
> 这是 v1 与两评审都没抓住的根:**生成质量的真标尺不是"这次能不能玩",是"工作室将来能不能维护它"**。配置驱动的结构化项目 = 既好维护又更好玩。
|
|
|
|
---
|
|
|
|
## 5. 与现有模块映射(非推倒,是各归其位)
|
|
|
|
- `project` 模块 = 项目/版本台账;**game_version 的内容从"打包产物"升级为"源项目工件 + 构建产物双存"**,version=一次 release。
|
|
- `studio` 模块 = **工作室编排层**(create/modify/extend 生命周期操作的入口与编排)。
|
|
- `runtime` 模块 = **CI 构建**(RuntimeBuild 桩 → 真:源项目→bundle);宿主/feed 消费构建产物**不变**(blast radius 收窄)。
|
|
- `telemetry`/`feed` = 反馈源 → 驱动工作室迭代(P-OPS-03/04「AI 内容诊断/一键迭代」自然落地)。
|
|
- W-G1 worker = 工作室的"程序员",受生成产出结构契约约束。
|
|
|
|
---
|
|
|
|
## 6. 契约 delta(基座重写)
|
|
|
|
| # | delta | 说明 | 取代 v1 |
|
|
|---|---|---|---|
|
|
| C1 | **游戏源项目工件契约** | 项目结构 schema(game.json/design/config/src/assets)+ 版本化存储(源+构建产物双存) | 新 |
|
|
| C2 | **生成产出结构契约** | worker 必须产**结构化源项目**(真 gameConfig/真 assets/模块化 src),非硬编码 bundle;补现 gameConfig 占位/assets 空缺口 | 新(吸收 D5 的真需求) |
|
|
| C3 | **生命周期操作契约** | `/studio/{create,modify,extend}` + aigc RPC(mode/baseVersion/target/idempotency);modify 产物=新预览版,**不动 currentVersion、不自动入 feed**,仍过审发布 | 替 v1 D3,补评审 P0 |
|
|
| C4 | **build 构建步契约** | 源项目→bundle+manifest+checksum,确定性可复现;打包产物 schema **不变**(现 GamePackage) | 替 v1 D5(改包)——**删 manifest 可寻址** |
|
|
| C5 | assetContext(六类) | 取代 attachments(废 R7),六类枚举一次定死四处同引;以平台 assetId/ref 为主、url 只读镜像;含安全/大小/token 预算 | 收紧 v1 D1 |
|
|
| C6 | analyze 智能确认 | 结果用显式 `confirmedGoal` 携带(无隐藏共享态);含跳过路径+失败枚举 | 收紧 v1 D2 |
|
|
| C7 | 回调面 | 改述为 worker job 模型(非冻结契约)+ `DifyCallbackReqVO`(#1)additive(带 baseVersionId/源项目引用);失败枚举处置评审 P2-1 | 改 v1 D6 |
|
|
| — | 玩法模板 | = **品类引导预设(影响生成 prompt/脚手架),不进 templateId 白名单/执行器**(执行器仍 generic);从 M0 关键路径摘出 | 收紧 v1 D4 |
|
|
|
|
---
|
|
|
|
## 7. blast radius / 兼容 / 风险
|
|
|
|
- **blast radius**:后端 studio/aigc/project(version 双存)+ worker 生成产出结构 + runtime 构建步;**宿主/feed/manifest 打包产物侧不变**(比 v1 D5 小)。
|
|
- **兼容**:打包产物 schema 不变 → B1 发布链/feed 真玩/宿主零回归;新增源项目工件为 additive 存储;generic 兜底保留;现有一句话生成空 assetContext = 现行行为。
|
|
- **最大风险(单点)**:**便宜模型能否稳定产"可维护的结构化源项目"**(数据驱动+模块化+资产分离),而非硬编码 blob。当前游戏未做到 → 这是生成侧的真升级,必须 W-G1 实测(结构化产出的成功率/成本是否仍过 ¥0.15+P75 门)。**缓解**:M0 先定最小项目结构(game.json+params+单 src+assets 引用),复杂结构随品类迭代;结构合规作为生成门的一道断言。
|
|
- 次风险:双存(源+产物)存储成本;确定性构建步要可复现(锁引擎版本/依赖)。
|
|
|
|
---
|
|
|
|
## 8. 验收 + M0 切片
|
|
|
|
- **M0(基座第一切片)**:一句话 → 工作室**脚手架出结构化源项目**(game.json+config+src+assets 引用)→ **确定性构建**出 bundle → play 真玩;源项目与构建产物双落库、可寻址。验"非一次性"=能从源项目重新构建出字节等价产物。
|
|
- **修改(生命周期)**:对源项目"换美术/改第2关"= 确定性编辑源文件→重构建→新预览版,旧版可回滚,未改部分行为不变。
|
|
- **生成质量门**:产出过"结构化合规"断言(数据驱动/资产分离/模块化)+ 九门真玩。
|
|
- **非阻断**:空 assetContext / 不 modify 时,现行生成零回归。
|
|
|
|
---
|
|
|
|
## 9. 待确认项
|
|
|
|
1. **M0 项目结构最小集**:game.json + config/params + 单 src 模块 + assets 引用,够不够?复杂结构(多 src 模块/levels 目录)随品类迭代——可否?
|
|
2. **生成产出结构契约是否设为 Phase 1 生成侧硬约束**(创始人本轮倾向:是)——结构不合规即判生成失败(进九门断言)?
|
|
3. 双存策略:源项目工件存 DB(JSON/文本)还是对象存储?M0 建议 DB(简单),大资产走 ref。
|
|
4. 六类素材枚举定稿(图元/角色/特效/场景/界面/音乐)。
|
|
5. modify 失败回滚 = 不建新版、base 不动(评审 P1-2 建议),确认。
|