games-development-ai/docs/agent-specs/2026-06-17-生成主线-对话生成修改素材-review.md
zizi 771619c7da docs: 新角色分工(Mac开发/6c6g大脑)+ 收编他session loose-end + _index修漂移
- 多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>
2026-06-18 04:56:15 +00:00

7.7 KiB

生成主线:对话式生成/修改 + 六类素材驱动(M0 核心纵切契约) — review 版

类型:review 版(结论先行,供决策;待 2 轮评审后出 execution 版再实施)。 日期:2026-06-17 · owner:6c6g(后端线领 spec)· 评审:codex + opus 两轮。 定位:Phase 1 最大前向特性 + M0 核心纵切(生成/修改/玩 端到端,三契约对齐 = 两开发线独立开工的前提)。 关联:多session分工总账 · 完成度优先级总账 · 架构充分性核验(本会话)。


1. 结论(先行)

把"一句话生成"升级为创始人口径的真创作能力:对话式生成/修改 + 六类素材驱动,系统分析→(智能)确认目标→生成/修改。落到契约 = 6 处 delta,跨两开发线:

# 契约 delta 触及线 性质
D1 assetContext(六类素材透传生成) #1 API(aigc+studio) 后端 + 前端 + 引擎 additive 字段
D2 /studio/analyze(意图分析+智能确认) #1 API(studio) 后端 + 前端 新端点
D3 /studio/modify(差量局部修改) #1 API(studio) 后端 + 前端 新端点
D4 玩法模板注册(template/list 空→真品类模板) #1 API + DB 后端 + 前端 新实体
D5 GamePackage 可寻址结构(六槽+config+关卡可单独 target) #4 manifest 引擎 + runtime + 后端 关键·跨两线
D6 dispatcher 增 modify job 模式 + 失败枚举补 nine_gate_failed #6 dispatcher 后端 + worker additive

最硬的一条是 D5:创始人选"差量局部修改"→ 产物不能是不透明 blob,manifest 必须把资产/配置/关卡暴露成可寻址部件,引擎从"可解构包"渲染。这把生成主线从填桩升级为真架构设计。正向对齐:已有 StudioAssetDO 六槽 + Runner v2 engineBundle 内嵌包,D5 是把"已有槽位"提升为"可寻址 manifest 部件",非从零。


2. 背景 / 目标 / 非目标

背景:现状(已核码)——生成是单步一句话;attachments 字段在但编译期保证不透传(R7);regenerate=同 prompt 重试(非语义修改);template/list 返空占位;dispatcher/manifest 结构现成但 manifest 不可寻址。

目标(Phase 1):

  • 用户可对话式生成简单游戏(LittleJS),上传六类素材(图元/角色/特效/场景/界面/音乐)驱动生成。
  • 用户可差量修改已生成游戏(换美术 / 调参数 / 改某关卡,保留其余)。
  • 系统分析输入→智能确认目标(清晰直通、模糊才确认)→ 生成/修改。
  • M0 验收 = 1 个最简模板端到端真玩 + 三契约(API/dispatcher/manifest)对上。

非目标(下沉):复杂 2D/3D(Cocos→P2);骨骼 rig / 可视化批量编排(P1+);素材市场/授权交易(mock-pending);真实计费(admin 赋予)。


3. 推荐方案

3.1 纵切流(智能确认)

sequenceDiagram
  participant U as 用户(studio前端)
  participant S as studio后端
  participant A as aigc编排(SAA)
  participant W as W-G1 worker(引擎线)
  U->>S: analyze(prompt + 六类素材refs)
  S->>A: 意图分析(多模态读素材)
  A-->>S: 解析目标 + needsConfirm
  alt 模糊/信息不足
    S-->>U: 展确认卡(目标摘要)
    U->>S: 确认/微调
  else 清晰一句话
    Note over S: 直通不打断
  end
  U->>S: generate / modify(确认后)
  S->>A: 提交(generate含assetContext / modify含target+baseVersion)
  A->>W: 派发(generate | modify job)
  W-->>A: 回调(产物=可寻址GamePackage + trace)
  A-->>S: 终态 + versionId
  U->>S: 轮询→可玩(play真引擎)

3.2 六处 delta 要点

  • D1 assetContext:{type∈[sprite图元/character角色/effect特效/scene场景/ui界面/music音乐], ref/url, role}[];aigc reqDTO 增同名字段(打破 R7 编译期阻断);图/视觉类走多模态、音乐/脚本作结构化上下文。additive,空数组=现行行为
  • D2 /studio/analyze:入 prompt+assetContext → 出 {parsedGoal, needsConfirm, clarifyQuestions[]};needsConfirm 由 aigc 判模糊度(智能确认)。
  • D3 /studio/modify:入 {gameId, baseVersionId, instruction, target?};target 指向可寻址部件(资产槽/config键/关卡);出新 version(差量应用)。区别于 retry(retry=同 prompt 整局重跑保留作血缘备选)。
  • D4 玩法模板注册:模板实体/表(品类框架:经营模拟/剧情互动/解谜闯关/TRPG/非遗科普…)+ 注册表;template/list 真返;模板=引导生成的品类框架(非旧"整局填参游戏模板",见 memory 术语纠正)。
  • D5 GamePackage 可寻址:manifest 暴露 {assets{六槽}, config{可寻址键}, levels[]},每部件带稳定 id;引擎从可解构包渲染;差量修改只重生成 target 部件、其余字节保留(sha256 复用)。
  • D6 dispatcher:job 增 mode∈[generate,modify],modify 携 baseVersion 产物 + instruction;FailureReasonEnumnine_gate_failed(修现 worker 回调被拒→watchdog 误判 timeout 的 bug)。

4. 关键权衡

抉择 选定(创始人) 代价 理由
修改方式 差量局部 强制 D5 可寻址 manifest + 引擎可解构渲染,复杂度↑ 体验顺、改一处不毁全局;Phase 1 简单游戏部件少、可寻址粒度可粗(资产/关卡/参数三档)
素材深度 全六类进上下文 assetContext 六型 + 多模态成本↑ 对齐"素材驱动创作"卖点;音乐/脚本作结构化上下文非生成图,成本可控
意图确认 智能确认 需 aigc 判模糊度(可能误判) 兼顾"一句话快"与"确认目标准";误判可由用户跳过兜底

5. blast radius / 兼容 / 风险

  • blast radius:后端 aigc/studio API + 编排 + worker dispatcher;#4 manifest(引擎+runtime+feed 全链消费);前端创作页(对话/上传/确认 UI);引擎 runtime 可解构渲染。两条线都触及,交汇全在本 spec 的 6 契约。
  • 兼容:全 delta 走 additive(assetContext 空=现行;modify 是新端点不动 generate/retry;manifest 加部件层旧 blob 仍可读);feature-flag 控新路;现有 B1 发布链/feed 真玩零回归。
  • 最大风险:差量修改在简单游戏上的可行性未证——便宜模型能否"只改 target 部件不毁全局"待 W-G1 真机验;D5 可寻址粒度定太细则 manifest 复杂、太粗则改不动。缓解:M0 先验最粗粒度(整资产槽/整关卡替换),细粒度(config 参数级)留 M1 迭代。
  • 次风险:智能确认误判(清晰判成模糊→多一步);多模态读六类素材的 token 成本(配额门 D12 已在,纳入计量)。

6. 验收标准(M0 + Phase 1 纵切)

  • M0(契约对齐):1 个最简模板,assetContext 六类透传 → generate 出可寻址 GamePackage → play 真引擎 → 端到端真玩;三契约 schema 校验过 + 真机对上。
  • 生成:上传六类素材 → 产物体现(图进画面/音乐进音轨);智能确认在模糊输入弹卡、清晰输入直通。
  • 修改:对已生成游戏发"换美术"/"改第2关"→ 新 version 仅 target 变、其余字节保留(sha256 比对);retry 血缘仍可用。
  • 非阻断:assetContext 空 / modify 未用时,现行一句话生成零回归。

7. 待确认项

  • 已定(本会话):意图确认=智能确认 · 素材=全六类进 · 修改=差量局部。
  • 待评审/创始人:① 六类素材枚举是否就是 图元/角色/特效/场景/界面/音乐(对齐 demo workshop)② D5 可寻址粒度 M0 取"资产槽/关卡"粗档、参数级 config 留 M1——可否?③ 玩法模板首批品类清单(经营/剧情/解谜/TRPG/非遗… 取哪几个先建)④ modify 失败是否回滚到 baseVersion(建议:是,差量失败不毁原作)。