zizi-al/games-development-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
games-development-ai/docs/agent-specs/_archive/2026-06-17-生成主线-游戏生命周期项目管理-review.md
zizi 133182d803 docs(governance): 立「一题一活档」规则 + 收敛生成主线设计档(删 v1/归档 v2) 
起因:本会话同一设计(生成主线)随 4 次 reframe 产 4 份 review/execution、过期 v1 被连推上 origin = 文档 sprawl + 过期档误导(反模式)。

预防(规则,根治):
- engineering-conventions §10.4「一题一活档」:同一设计主题就地修订一份活档、禁「一 pivot 一文件」;review/execution 拆分仅当两者同时为活;终稿自洽;supersede 同提交删/归档(强化 §10.2);commit 设计档前自检。
- wave-close 第8步补:同一任务设计档收敛成最小自洽集(典型 1 review+1 execution)、被取代者同提交删/归档。
- (doc-organizer 轴①已检测 SUPERSEDED/DUP = 事后兜底;§10.4 = 事前根治)

收敛(应用):
- 删 v1(对话生成修改素材-review,D5「改打包产物」前提已被评审证伪=纯误导)。
- v2(生命周期项目管理-review)生命周期原则折入固定架构 review §1 使其自洽 → 归档 _archive/ + SUPERSEDED 墓碑。
- 固定架构 review §4 从 §10.1 收敛(消 opus 点的两份 agent 表分叉)。
- _index 活地图登记(固定架构 review+execution=ACTIVE、supersede 链记 v1/v2 收敛)。
留最小自洽集 = 固定架构 review(自洽)+ execution。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-17 12:16:57 +00:00

9.4 KiB
Raw Blame History

状态: SUPERSEDED(→ ../2026-06-17-固定游戏架构与SAA-agentic-studio-review.md) · 归档: 2026-06-17 本档生命周期原则(游戏=长生命周期源项目、LLM=工作室、改源不改打包产物)已折入继任固定架构 review §1,继任档自洽。本档留作原则出处参考,勿照建。

生成主线 v2:游戏全生命周期项目管理(LLM as 工作室) — review 版

类型:review 版(基座重构,结论先行,供决策)。日期:2026-06-17 · owner:6c6g 领 spec · 评审:codex + opus(v1 已两轮,本 v2 基座变更需再一轮)。 supersede:本 v2 取代 v1 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 工作室的生命周期操作 + 构建/发布管线

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 建议),确认。