games-development-ai/docs/agent-specs/_archive/2026-06-09-agent化生成QA闭环-review.md

agent 化生成 QA 闭环 · 评审版设计（创始人拍板版）

• 文档编号: HJ-AGENT-LOOP-REVIEW-001
• 日期: 2026-06-09
• 状态: ✅ 已拍板（2026-06-09 创始人对 §7 四项全部采纳推荐答案；execution 版起草中）
• 终审修订: 2026-06-09 按总架构师终审 5 条意见修订（修订账见 §2.4：落包三表写入链 / runtime-api 扩面如实计量 / M2 两段式口径 / 漂移表述降格 / 裁决决策表要求）
• 评审方式: 三镜头提案（mvp-first / quality-first / compound-first）× 三评委独立裁决（工程正确性 / 范围 YAGNI / 产品护城河），评委均做了超出事实清单的代码核验
• 裁决结果: 三位评委 ranking 首位一致 = mvp-first → 以其为骨架，嫁接另两案 steal 亮点，fatal 逐条化解（见 §2）

---

0. 结论（先行）

推荐架构一句话：以「2 个 LLM 角色（独立策划 + 对抗策划）+ 2 个确定性组件（CDP 玩家取证 + 纯代码裁决）+ 1 个脚本编排器」组成全自动生成 QA 闭环；后端新增 = aigc 回调实做（内联 PackageFactory）+ runtime-api 扩落包方法（一次闭合 aigc 链 2→5 唯一断点，未来真 Dify 接入零改动，通道与三表写入清单见 §4 接线②）；发布前可运行证据 = CDP 捕获宿主 lifecycle emits（规避预览页不发遥测的真实断点）；v1 仅 clicker 走全闭环，staging 单批 20 创意全自动流完、accept 率 ≥80% = M2 成功率指标口径达标（M2 整体收口另以 M-b 生成半下沉为准，两段式定义见 §7 待确认 4），任一 accept 在 feed 真可玩为终验。

为什么是它：

1. 集成切面全场最准（三评委一致）：全仓既有 HTTP 写入面只有 /admin-api/aigc/dify/callback 桩，实做它 = 零新对外端点（runtime-api 扩落包方法为内部 RPC 契约，见 §4 接线②）、状态机首获写入方、与未来真 Dify 共用同一契约（contracts/dify-workflow-io.json）、无弃件。
2. 裁决确定性最高（诚实口径）：accept/fix/kill 全部为纯代码规则（非 LLM），规则变更走 PR 可审计——裁决规则确定，但闭环并非全确定：accept 硬条件中「无 P0/P1 残留」的判定仍来自对抗评审（LLM 输出面），同一 prompt 下模型批间漂移（非 prompt 变更，四道闸管不到）仍可影响 80% 达标。靠 Golden 创意集回归、批报告对抗评审稳定性披露（§3.4）、换模型 20% 抽检冻结阀三件共同缓解与监控，而非封死。
3. 零创始人参与达成：staging 自动 APPROVE（裁决即审核员，走 admin 审计日志）、批报告自动生成仅留档——对齐「初版完全由 agent 完成、无需创始人参与或读 CSV」的指令；生产保留人审开关（对齐 D-PUB α 设计）。
4. 复利内建：闭环批报告直接充当 Prompt 治理四道闸的「成功率 ≥80%」闸数据源（门禁与生产同源）；每条裁决按 prompt id 回流 contracts/prompts/eval/ Golden 集自动生长（C1 的 52 条为种子）。

---

1. 背景与依据

1.1 两条已验证的事实底座

底座	结论	出处
C1 生成 spike：结构层 100%	4 模板 × 13 创意 = 52/52 全过（HTTP 通 + JSON 合法 + 逐字段 schema），含 2 条故意模糊创意；通道 = new-api 直调 MiniMax-M2.7 + json_object。战略含义：「模板驱动生成（LLM 填参 + 固定模板 runtime）」高度可行，可绕开高风险 LLM 代码生成	docs/agent-specs/2026-06-09-generation-spike/spike-summary.md、docs/agent-specs/2026-06-09-generation-spike/gen_spike.py
B2′ 真人浏览器试玩闭环已通	staging + 真无头 Chrome：feed 真标题 → 点卡进试玩 → clicker 真玩通关 → 遥测 game_play_end{completed:true} 落库 → quality 0→60 → feed 翻转登顶；CDP 真实输入可穿 sandbox iframe 点 canvas；通关程序可确定（点 target 次）	docs/mvp/MVP作战清单.md（B2′ 行）

1.2 三个待解问题（本设计的靶子）

1. C1 的诚实边界：可运行层仅 clicker 有 runtime 真验；可接受层完全未评，原计划靠创始人 A4 盲评（人读 CSV）——创始人已改向：用 agent 化 QA 闭环替代盲评，零人参与。
2. aigc 链唯一断点：入口（submitGenerate）真、出口（completeWithVersion）真但全仓无调用方；中段「生成执行器 + PackageFactory（链路 2→5）」缺失，任务永远停 queued（出处：game-cloud/game-module-aigc/game-module-aigc-server/src/main/java/cn/wanxiang/game/module/aigc/service/task/AigcTaskServiceImpl.java 及调研清单）。
3. 质量真值缺位：发布链（B1）与数据回路（telemetry→quality_score→feed，B2）均已真 e2e，但「什么样的生成结果配进 feed」没有机器口径。

1.3 一个评委查实的关键断点（影响所有方案）

发布前预览页 /create/preview/:versionId（game-studio/src/views/create/Preview.vue，路由见 game-studio/src/router/index.ts）不发任何遥测——game_play_start/end 遥测映射只存在于发布后的 game-studio/src/views/play/Play.vue。因此「发布前试玩以遥测落库为证据」按文不可执行，必须换证据通道（见 §3.3 runnableOk 定义）。

---

2. 评审过程与 fatal 化解账

2.1 三案三评委裁决摘要

提案	评委1（工程正确性）	评委2（范围 YAGNI）	评委3（产品护城河）	总评
mvp-first	1st (8)	1st (7.5)	1st (8)	骨架。接缝最准、裁决最便宜、口径纪律最好；两处 fatal 均「小修可愈」
quality-first	2nd (7)	3rd (5.5)	2nd (7.5)	纵深与诚实度最高，但 durationMs<3s 口径错误会让首批数据报废 + 工程量最大
compound-first	3rd (6)	2nd (6.5)	3rd (6.5)	单点亮点密度最高（eval 生长/克隆配方），但外部脚本→JVM 接口通道缺失 = 按文不可执行

2.2 骨架（mvp-first）fatal 逐条化解

#	fatal（评委原话要义）	化解方式
F1	发布前试玩证据链断：accept 硬依赖遥测落库，但 Preview.vue 不发遥测（B2′ 证据是发布后路径，引用越界）	嫁接 compound-first 的证据通道：PlayReport 主证据 = CDP 注入监听捕获宿主 lifecycle emits（postMessage 层，零前端改动、既有预览路由现成可用）；发布后抽样 1 条走 Play.vue 真玩，以「遥测落库 + quality_score + feed 重排」做双锚复核（B2′ 配方原样）
F2	playerScore（fun/clarity 1-5）作 accept 硬条件，对全通关的 clicker 无区分度，退化为二次文本评审且噪声可左右 80% 达标	v1 砍掉 LLM 玩家评分门：玩家 agent 退为纯确定性取证（不评分）；「可接受层」由对抗评审 findings（无 P0/P1 残留）+ 文案非占位贴题 + 批内查重承担；主观趣味真值交给发布后真实玩家完玩率回路（已真 e2e）
F3	「顺手补上全链唯一断点」过度声明：只补了落包半（3→5），生成半留在编排器脚本，studio 真实用户任务仍永久 queued	如实降格表述 + 给归处：v1 = 补落包通道（回调实做），生成半由编排器承担（伪装 Dify 出参）；v1.1 把编排器的生成调用下沉为 aigc 内薄轮询执行器（复用同一回调语义），接通真实用户链路——列入里程碑与风险 R6，不假称已通
F4	回调实做工作量略报：DifyCallbackReqVO 现无 gameConfig/assets 字段、端点带 @PreAuthorize('aigc:dify:callback') 权限位	两件显式列入 v1 交付清单：VO 扩字段对齐 contracts/dify-workflow-io.json + 回调权限配置（见 §4 接线②）
F5	状态机 1(running) 仍无写入方（回调直接 0→2/3）	回调实做受理即置 1，同事务推进至 2/3——状态机全口径获得写入方

2.3 嫁接清单（另两案 steal 亮点 → 本设计落点）

来源	嫁接件	落点
compound-first	CDP 捕宿主 emits 为主证据；durationMs>0 断言（防 startMs 缺省 =0 假象）；eval 集自动生长（kill 负例/fix 对照/accept 正例按 prompt id 落 contracts/prompts/eval/）；4 模板 schema 一次落盘；批内同质化查重；连续 5 条同因 kill 停批；新模板「四件套」克隆配方；Verdict 预留 completed:false 语义	§3.2 / §3.3 / §3.4 / §5
quality-first	「声明不作证据」铁律（证据核对由编排器代码强制，非 prompt 约束）；预算闸数字化（LLM≤8 次/创意、实玩≤3 次、整批 30min 收口、浏览器池≤2）；金丝雀限额（每批入 feed ≤10）+ 换模型抽检复核 20%（分歧 >10% 冻结发布并告警）；「现无下架接口」诚实披露列 M3；禁止 evaluate_script 篡改游戏状态的取证纪律；漏斗归因 +「不得以降低裁决口径换达标」红线	§3.3 / §3.4 / §6
（新增防御）	demo 兜底假阳性防御：取包失败会静默兜底 demo 包（target:5 恒可通关），PlayReport 必须校验所玩包 checksum / config 与落包一致，兜底包（64 位 '0' checksum）判 infra_fail 而非通过	§3.3 runnableOk ⑤

被有意不采纳的项（防过度设计）：LLM 裁决 agent 与 rubric 三维评分、任何「试玩时长 < 阈值」类质量门（bot 点击节奏 ≠ 人类体验时长，评委证实该规则会系统性打穿首批 accept 率）、三个无 runtime 模板的批量静态空跑（spike 已 52/52 实证，重复证明零信息增量）、Java 侧依赖未实现的 PromptRegistryLoader（编排器直接读 contracts/prompts/ 文件渲染，git 即事实源）、新增预览路由（已存在）。

2.4 终审补查与修订账（5 条，全部采纳并已回写正文）

#	终审发现（severity，均经代码实查复核）	修订落点
Z1	接线②按文不可执行（high）：原步骤序列缺「创建 game_runtime_package 行」——实查 createForPackage 只建 game_version 行；DbPackageStore.putManifest 未命中行时静默 log.warn 跳过、不抛错（回调事务不回滚，任务带病 succeeded）；全仓无任何生产代码插入 game_runtime_package（B1 闭环的行来自 staging 手工灌数）。缺行连锁：预览取包抛 1-102-001-001 → demo 兜底 → 被 §3.3 ⑤ 判 infra_fail → 整批熔断；发布翻包同样必失败。execution 版照抄原文则闭环 100% 跑不通	§4 接线②：补建行步骤（putManifest 之前）+ putManifest 未命中改显式失败 + 「三表一次事务写入清单」为 execution 验收断言
Z2	落包写入通道跨模块边界缺失（medium）：PackageStore 位于 runtime-server 内部包，跨模块唯一面 RuntimePackageApi 仅 publish/getStatus 两方法且 javadoc 明文「禁止上游依赖 runtime 的 -server」；aigc 回调实做要么违纪，要么必须扩 runtime-api =第二个后端改动点；且 aigc-server pom 现无 project-api/runtime-api 依赖。原「唯一新增后端代码=回调实做；其余零改动」的拍板前提不成立（不影响 mvp-first 骨架结论，但工作量口径必须如实）	§0/§4/§5.1/§6 回滚行：统一修正为「回调实做 + runtime-api 扩落包方法 + pom 依赖」
Z3	M2 过线口径与进度总账叙事冲突（medium）：原文「accept 率 ≥80% 即过 M2 验收线」，而进度总账明言「80% 验收线依赖 aigc/Dify 真实接通、接通前无法测量、是 M2 命门」；本设计 v1 生成半仍留编排器（F3/R6 自承），创始人可能批了口径却误以为 v1 收口=M2 完成	M2 过线拆两段式定义（§0/§3.3/§5.2 口径注），单列 §7 待确认 4 显式拍板，拍板后同步回写进度总账
Z4	「从根上封死 LLM 评分漂移」表述过度（medium）：accept 硬条件含「无 P0/P1 残留」，P0/P1 判定本身是 LLM 输出面；F2 砍掉的是玩家评分，对抗 findings 这个噪声入口还在，批间漂移仍可左右 80% 达标——影响创始人对「零人在环可信度」的判断	§0 第 2 点改述为「缓解与监控，而非封死」；§3.4 批报告增加对抗评审稳定性披露
Z5	裁决规则存在未覆盖分支（medium）：schema 不合法 @round=0 既不满足 kill 条款（要求 round=1 仍不合法）也不满足 fix 条款（要求结构/运行 OK），重出算不算 fix 轮、round 如何计数、按序短路完整执行序均无口径——引擎无法按文落成纯代码	§3.3 补回炉计数总则 + schema-fail@round=0 重出规则；execution 版强制显式决策表（全分支可单测）

---

3. 推荐架构

3.1 agent 角色与边界

flowchart LR
    I[创意批次 N≥20] --> O

    subgraph ORCH[编排器 · 确定性脚本]
        O[批次驱动 / 预算闸 / 熔断<br/>JSONL 账本 / eval 回流]
    end

    subgraph LLMZ[LLM 层 · prompt 全入 Registry]
        D[独立策划 agent<br/>创意→GameDesign]
        A[对抗策划 agent<br/>只批不改→findings]
    end

    subgraph DETZ[确定性层 · 非 LLM]
        P[玩家 agent<br/>CDP 真玩取证→PlayReport]
        J[裁决引擎 · 纯代码规则<br/>accept / fix / kill]
    end

    subgraph BE[后端真实链路]
        CB[(Dify 回调实做<br/>内联 PackageFactory)]
        PUB[发布六步编排→feed]
        TQ[telemetry→quality_score 回路]
    end

    O --> D --> A
    A -- "P1 findings 回灌(≤1轮)" --> D
    A --> J
    D --> J
    O -- "伪装 Dify 出参 POST 回调" --> CB
    CB -- versionId 真包 --> P
    P --> J
    J -- accept --> PUB --> TQ
    J -- "kill / fix / 全量 Verdict" --> O

角色	输入	输出	禁区
独立策划 agent（LLM）	创意一句话 + 模板 schema + 批内禁重列表（fix 轮追加 findings）	GameDesign（含完整 GameConfig 候选）	不得超出模板 schema 自由发挥；不自评；fix 轮只改指出项
对抗策划 agent（LLM）	GameDesign 全文	findings[]（P0/P1/P2 + 整改建议）	只批不改；不下最终结论；评审时不可见试玩数据（保独立性）
玩家 agent（确定性 CDP 驱动，非 LLM）	versionId（落包后真包）	PlayReport（纯客观取证）	只产证据不评分；游玩必须真实 pointer 事件，禁止 evaluate_script 篡改游戏状态；不调任何后端写接口
裁决引擎（纯代码规则，非 agent）	GameDesign + findings + PlayReport	Verdict{accept|fix|kill}	无 LLM 参与；缺 PlayReport 硬证据不得 accept（代码强制）；规则变更 = 改代码走 PR
编排器（Workflow 脚本）	创意批次	账本 + 真实链路调用 + 资产回流	prompt 不内嵌（走 Registry 文件渲染）；不做内容判断；不得绕过裁决发布

Prompt 归置（沿 Registry 既有 8 阶段目录，不新增 stage）：策划 → 04-config、对抗 → 06-quality、fix 变体 → 07-fix；frontmatter 按 docs/agent-specs/prompt治理体系-execution.md §5.1；改 prompt 必升 version、走四道闸。LLM 通道沿用 spike 已证配方（new-api + MiniMax-M2.7 + json_object）。

3.2 工件契约（字段级）

GameDesign（新增 contracts/agent-loop/game-design.schema.json）

{ designId: sha256(idea+templateId+round), idea: str, templateId: enum,
  designIntent: str(≤100字玩法意图), expectedPlaySeconds: int,
  config: GameConfig, round: 0|1 }

GameConfig（C1 spike 口径固化为 contracts/templates/*.schema.json，补齐「模板级 schema 今天不存在」缺口，兼作门禁④静态校验对象；4 份一次落盘，v1 仅 clicker 走闭环）

clicker: { templateId:"clicker", title:str非空, theme:str非空, target:int(5-30), scoreLabel:str非空 }
dodge / runner / match: 按 gen_spike.py 已验 schema 同步落盘（仅契约，不跑批）

诚实边界：runtime 今天只消费 target；title 经 meta 上 feed 卡片；theme/scoreLabel v1 仅为文本评审面（不渲染，v1.1 扩渲染面）。

Verdict（新增 contracts/agent-loop/verdict.schema.json，全量落 JSONL 账本并按 prompt id 回流 eval 集）

{ designId, taskId, versionId?, decision: accept|fix|kill,
  structureOk: bool, runnableOk: bool,
  playReport: { loaded: bool, clicks: int,
                gameEnd: { completed: bool, durationMs: int } | null,
                consoleErrors: [str], assetLoadErrors: int,
                packageChecksumVerified: bool,        // 防 demo 兜底假阳性
                emitsCaptured: [str] },               // CDP 捕获的宿主 lifecycle 事件序列
  findings: [{ severity: P0|P1|P2, issue: str, suggestion: str }],
  reasons: [str], round: int,
  evidence: { traceId, promptVersions: {} } }

playReport.gameEnd.completed 预留 false 语义——dodge 引入判负时契约零改动。

3.3 裁决口径（可执行规则，按序短路）

runnableOk 定义（五条 AND，编排器代码强制核对，agent 自述一律不作证据）： ① CDP 捕获 game_loaded；② 捕获 game_end{completed:true}；③ durationMs>0（证明 game_start 真触发，防 startMs 缺省 =0 假象）；④ 零 game_error 且 console 无致命错误；⑤ 所玩包 checksum/config 与落包一致（demo 兜底包判 infra_fail，不算通过也不算 kill）。

回炉计数总则（Z5）：round = 该 designId 的回炉计数（0=首轮，1=回炉轮；GameDesign/Verdict 的 round 字段即此口径），全流程回炉额度合计 1 轮，schema 重出与 P1-fix 共享同一额度。schema 不合法 @round=0 → 携 schema 校验错误回灌策划 agent 本地重出 1 次（消耗唯一回炉额度；不经对抗评审、不落包，免费门先行）；round=1 后任何不满足 accept 的分支一律不再回炉。

1. kill（即时，不给 fix）
   • schema 不合法且 round=1 仍不合法 → 回调 failed + config_invalid；
   • findings 含 P0（违规/敏感/年龄不适）→ 回调 failed + unsafe_prompt（均取 FailureReasonEnum 既有 7 值，不扩枚举）；
   • 批内同质化撞重（theme/文案查重）→ kill 留档负例；
   • 落包后真玩重试 1 次仍非 runnableOk → 不发布、留档告警，任务保持 succeeded（区分「运行环境劣」与「设计劣」，不污染任务状态机语义）。
2. fix（与 schema 重出共享回炉额度，合计至多 1 轮）：结构/运行 OK，但 ∃P1（题文不符、target 与意图矛盾、文案不通/占位）且 round=0 → findings 回灌策划 agent 重出 → 全流程重走（target 可能变，必须重玩）；round=1 仍 ∃P1 → kill 留档（不再回炉）。
3. accept（全部满足）：structureOk ∧ runnableOk ∧ 无 P0/P1 残留 ∧ 批内查重通过。

execution 版硬要求（Z5）：裁决必须落成显式决策表——输入 (schemaOk, findings, playReport, round) → 唯一输出分支，覆盖全部输入组合（含 schema-fail@round=0/1、P1@round=0/1、runnable-fail 重试、infra_fail 旁路），「按序短路」的完整执行序以该表为准；引擎照表落码，单测覆盖全分支。

「可接受」v1 机器口径 = accept 四条 AND，替代创始人 A4 盲评；长期第二裁判 = 发布后真实玩家 telemetry→quality_score→feed 重排（已真 e2e）。明确不设任何「试玩时长阈值」质量门——bot 点击节奏与人类体验无关。

成功率统一口径（三案口径分歧已收敛；M2 两段式过线定义见 §7 待确认 4，Z3）： accept 率 = accept 数 ÷ (提交创意数 − infra 类)，≥80% = M2 成功率指标口径达标（v1 编排器代产批跑即可测量——这是 80% 这条 MVP 核心指标首次可测量）；但 M2 整体收口另需生成链路贯通（以 M-b 薄轮询执行器落地为准），编排器代产批次过线不得单独宣称 M2 完成。infra 类（new-api 超时 / 浏览器环境挂 / demo 兜底触发）不计分母、designId 幂等可重放；批报告分层披露结构层 / 可运行层 / 可接受层三层通过率（对齐 C1 三层口径）。

3.4 并行编排形态

• 流水（贵的资源最后用）：N 创意 → 策划（并发 ≤3、间隔 0.3s，沿 spike 通道纪律）→ 本地 schema 门（免费）→ 对抗评审 → fix 回炉（≤1 轮）→ 过文本面者落包（§4 回调）→ 玩家 agent 真玩（无头 Chrome 串行池 ≤2，防互扰）→ 裁决 → accept 走发布 / kill 留档。并行边界 = 创意边界，零共享状态（复用三相 Workflow 编排方法，见 .agents/workflows/mvp-execution-orchestration.md）。
• 预算闸：每创意 LLM ≤8 次、实玩 ≤3 次；整批 30 分钟强制收口。
• 熔断：批内 infra_fail >30% 自动停批告警（防带病出数）；连续 5 条同因 kill → 停批告警（prompt/环境系统性问题，防预算空烧）；试玩环境不可用 → 整批暂停（runnable 证据不可豁免，禁降级为「跳过试玩」）。
• 账本与资产回流（每批强制，非可选）：JSONL ledger（Verdict 全量 + taskId/traceId，幂等断点重放）；批末自动摘要（accept 率/三层漏斗/kill 原因分布/成本/对抗评审稳定性披露）——同时就是 prompt-eval.yml 闸②④的数据源（门禁与生产同源）；每条 Verdict 按 prompt id 落 contracts/prompts/eval/<id>/（kill 负例 / fix 前后对照 / accept 正例），C1 的 52 条 spike 数据为种子。全程无任何人读 CSV。
• 对抗评审稳定性披露（Z4，监控 LLM 批间漂移）：批末对同批随机抽样 ≥3 条 GameDesign 做对抗评审同 prompt 重测，披露 P0/P1 判定一致率（判定翻转即不一致）；与既有换模型 20% 抽检冻结阀共同构成 findings 这一 LLM 噪声入口的监控面——一致率持续走低 = 漂移预警，触发 Golden 集回归排查（修 prompt 走四道闸），不得以放宽 P1 口径回应。
• 发布纵深：每批入 feed 金丝雀限额 ≤10；accept 随机 20% 由换模型独立复核重裁，分歧率 >10% 自动冻结本批发布开关 + 告警落库（人可事后审但不在环）。

---

4. 与 aigc / runtime / feed / telemetry 的最小集成

后端改动 = aigc 回调实做（内联 PackageFactory）+ runtime-api 扩落包方法（Z2 修正，工作量如实计）；发布链 / telemetry / feed / 前端全部走已验真实链路，零改动。

sequenceDiagram
    participant O as 编排器
    participant S as studio/aigc(真)
    participant CB as Dify回调实做(后端件,含runtime-api扩面)
    participant P as 玩家agent(CDP)
    participant F as 发布链+feed(真)

    O->>S: ① createDraft→submitGenerate(B1配方鉴权)
    S-->>O: taskId(queued)+traceId
    Note over O: LLM出GameConfig+对抗评审(文本面)
    O->>CB: ② 按dify-workflow-io.json出参伪装Dify POST回调
    Note over CB: 受理置1→组GamePackage(sha256)<br/>→createForPackage(建game_version行)<br/>→建game_runtime_package行(status=0)<br/>→putManifest→completeWithVersion→置2<br/>(三表同事务,幂等;经runtime-api扩面)
    CB-->>O: studio轮询getTask拿versionId
    P->>P: ③ 既有预览路由真玩,CDP捕宿主emits
    O->>F: ④ accept→publish→admin APPROVE(staging自动批)
    F-->>O: 六步编排落feed(PUBLISH_BASELINE)
    Note over F: ⑤ 发布后抽样1条走Play.vue真玩<br/>遥测落库+quality_score+feed重排双锚复核

1. 入口（真）：编排器以测试创作者身份（B1 配方：token=test1 + tenant-id）走 studio 真链 createDraft → submitGenerate，得 taskId(queued) + traceId。
2. 落包（后端件，Z1/Z2 终审修正后口径）：实做 /admin-api/aigc/dify/callback 桩为事务服务 = 内联 PackageFactory，一次事务完整写入序列：校验 → 组 GamePackage（契约#4 contracts/game-package.schema.json，sha256 manifest/checksum，assets=[]）→ ProjectVersionApi.createForPackage（按 genTaskId 幂等，建 game_version 行）→ 建 game_runtime_package 行（status=0 预览就绪） → 写 manifest → AigcTaskService.completeWithVersion（幂等）→ 状态机受理置 1、终态 2/3（failed 按 FailureReasonEnum）。
   • 为何必须补建行步骤（Z1）：终审实查 createForPackage 只建 game_version 行，全仓无任何生产代码插入 game_runtime_package（B1 闭环的行来自 staging 手工灌数）；缺此步则预览取包抛 1-102-001-001 → demo 兜底 → 被 §3.3 ⑤ 判 infra_fail → 整批熔断，发布翻包亦必失败——闭环 100% 跑不通。
   • 落包写入通道（Z2）：PackageStore 是 runtime-server 内部件，aigc 不得直依赖（守门纪律：跨模块只依赖 runtime 的 -api）——扩 RuntimePackageApi 新增「建包行 + 写 manifest」落包方法，沿既有 @FeignClient + 本地 @Primary ApiImpl 同事务模式（与 ProjectVersionApi.createForPackage 同款），事务内禁 Feign/HTTP/@Async/REQUIRES_NEW（对齐该接口既有纪律）；aigc-server pom 新增 project-api / runtime-api 依赖，列入交付清单。方法签名与事务约束细节由 execution 版给出。
   • 失败路径（Z1）：「putManifest 未命中运行包行」必须由现状静默跳过（DbPackageStore log.warn 即返回，事务不回滚）改为显式失败——回调同事务回滚、任务置 failed，禁止带病 succeeded。
   • 配套两小件（评委查实，计入工作量）：DifyCallbackReqVO 扩 gameConfig/assets 字段对齐 contracts/dify-workflow-io.json；aigc:dify:callback 权限配置。未来真 Dify 接入零改动。
   • execution 版验收断言（Z1）：以「回调一次事务的完整写入清单 = game_aigc_task / game_version / game_runtime_package 三表」为准——回调成功后三表行齐备、预览取包不走 demo 兜底；任一表写入失败则三表全回滚且任务置 failed。
3. 试玩（真，零前端改动）：玩家 agent 经既有预览路由 /create/preview/:versionId（game-studio/src/views/create/Preview.vue）取包真玩；主证据 = CDP 注入 postMessage 监听捕获宿主 lifecycle emits（loaded/start/end/error）；游玩操作为真实 pointer 事件点 canvas target 次；B2′ 三坑（画布 0 高/兜底误判/completed 漏发，已修 d279898）固化为 PLAY 前置回归断言。
4. 发布（真）：accept → POST /app-api/project/{id}/publish（适龄 + 合规门禁，MVP 桩 pass）→ admin reviewProject APPROVE（staging 自动批；生产保留人审开关，对齐 D-PUB α）→ 既有六步编排落 feed（game-cloud/game-module-project/.../PublishOrchestrationServiceImpl.java，B1 已验）。
5. 回路（真）：发布后抽样真玩走 game-studio/src/views/play/Play.vue → 遥测落库 + quality_score + feed 重排双锚复核（B2′ 配方）；长期裁判 = 真实玩家完玩率回路。telemetry/feed 零改造。

诚实边界（对应 F3）：本 v1 只补「落包半」；studio 真实用户 submitGenerate 的任务仍停 queued，v1.1 将编排器的生成调用下沉为 aigc 内薄轮询执行器（复用同一回调语义）后才真正接通——在此之前不得宣称「生成链路已通」。

---

5. v1 范围与里程碑（clicker 先行 → 克隆扩展）

5.1 v1 交付物（5 件）

1. Registry 3 条 prompt（策划 04-config / 对抗 06-quality / fix 变体 07-fix）+ frontmatter + 各自 eval 目录骨架；
2. contracts/agent-loop/ 两个 schema + contracts/templates/ 4 模板 schema（仅 clicker 走闭环）;
3. 编排器脚本（批量 / JSONL 账本 / 幂等重放 / 预算闸 / 熔断 / eval 回流 / 批报告）；
4. DifyCallback 真实做（内联 PackageFactory：game_aigc_task/game_version/game_runtime_package 三表同事务写入 + putManifest 显式失败语义）+ runtime-api 扩落包方法（含本地 @Primary ApiImpl）+ VO 扩字段 + 权限配置 + aigc-server pom 依赖（project-api/runtime-api），含单测；
5. 玩家 agent clicker 取证策略（CDP emits 捕获 + demo 兜底检测 + B2′ 三坑回归断言）。

5.2 v1 验收

staging 上一批 20 创意全自动流完（零人工介入、零人读中间产物），统一口径 accept 率 ≥80%，批报告 + eval 集自动落盘，抽任一 accept 在 feed 真可玩（浏览器实证 + 遥测/quality/feed 重排双锚）。

口径注（Z3）：本验收过线 = M2 成功率指标口径达标（80% 这条核心指标首次可测量），不等于 M2 整体收口——后者另需真实用户生成链贯通（M-b 薄轮询执行器，真实 submitGenerate 不再停 queued），见 §7 待确认 4。

5.3 里程碑

阶段	内容	出口判据
M-a（本案 v1）	clicker 全闭环 + 回调实做 + 4 schema 落盘	§5.2 验收过线
M-b（v1.1）	① 生成半下沉：aigc 内薄轮询执行器（复用同一回调语义），studio 真实用户链路活；② 最小 runtime 改动放大渲染面（theme/scoreLabel 入画布，守 toString 注入 + <15KB 红线）	真实用户 submitGenerate 不再停 queued
M-c（衔接 B3）	按「四件套」克隆 dodge → runner → match：模板 schema（已落盘）+ 模板 runtime（补 update(dt)/碰撞/判负）+ 玩家策略表条目（随机性模板加 debug 自动通关钩子）+ registry prompt 变体；dodge 首次引入 completed:false 判负（契约已预留）；编排器/裁决口径/资产管道零改动	每模板独立过一批 ≥80%

clicker 同质化产能拐点（批内查重 kill 率持续走高）= dodge runtime 的立项触发信号——用数据驱动模板扩张节奏。

5.4 明确不做（v1）

dodge/runner/match runtime 及其批量静态空跑；OpenGame 代码生成 / ComfyUI 素材；Dify 编排迁移（回调契约兼容，后接零改）；MQ 异步化；LLM 裁决 agent / 玩家主观评分 / 多 persona；promptHash MD5→sha256 顺手修；runtime destroy() 补发 game_end（与闭环 happy path 无关，列 B3）；下架接口（M3）；模板列表接 studio 正式入口。

---

6. 风险与降级

#	风险	应对 / 降级
R1	clicker 可评审面窄（玩法差异仅 target + 文本，对抗评审实质在文本层）	诚实接受为 v1 边界；M-b 以最小 runtime 改动放大渲染面；真趣味判定交发布后完玩率回路
R2	同质化刷屏（clicker 参数空间小）	策划注入批内禁重列表 + 裁决批内查重 + 金丝雀限额（每批 ≤10）；拐点即 dodge 立项信号
R3	自产自评偏置 / Goodhart（调松评审刷指标）	裁决纯代码 + 规则变更走 PR；prompt/阈值升版必过四道闸 + 固定 Golden 创意集回归；换模型抽检 20%、分歧 >10% 冻结发布；红线：任何情况不得以降低裁决口径换达标；80% 不达线按漏斗归因分段处方（损耗在策划/填参 → 收紧 prompt 至模板近似填空；损耗在实玩 → 修 runtime/驱动，不放宽门槛）
R4	试玩遥测污染 quality	v1 发布前试玩走 Preview（不发遥测，天然无污染）；发布后抽样真玩量小且限 staging；生产化硬前置 = bot 账号排除规则（三案共性盲点，显式立项）
R5	new-api / 无头浏览器单点	退避重试 ×2 → infra_fail 不计分母；infra_fail>30% 停批；试玩环境不可用整批暂停（禁跳过试玩）；最终兜底链：agent 闭环挂 → 回退 C2 已裁决「模板驱动 + schema 门禁」（人工抽检）→ 再降 = demo 预设包，发布链不断
R6	真实用户生成链 v1 仍断（F3 化解后的残余，如实列险）	种子用户内容池 v1 依赖编排器批跑代产；M-b 薄轮询执行器为第一优先后端件
R7	现无下架接口（评委查实：AdminProjectController 仅两端点、QUALITY_REFRESH 不动 status）	发布后异常（如首 24h completeRate<20%）仅告警不自动下架；下架接口列 M3 缺口，不虚构；金丝雀限额收敛血量
R8	换模型复核的第二模型可用性未验（new-api 多通道未实测）	复核模型不可用时降级为「同模型异版本 prompt 重裁 + 告警」，冻结阀照常生效
回滚	整体回滚	编排器 + agent 层为纯叠加：关停即回现状；后端件（回调实做 + runtime-api 扩落包方法）独立可灰度——扩面为纯新增方法、不动既有 publish/getStatus，关闭调用方即失活，aigc 入口/出口、发布链、telemetry 回路均无侵入改动

---

7. 待创始人确认项（4 项 · ✅ 2026-06-09 已全部拍板）

拍板记录（2026-06-09，主 agent 当面征询创始人）：1=认可机器口径（A4 盲评降级为事后抽看校准）；2=接受「staging 零人在环、生产人审」分界；3=v1 后先投 M-b 生成下沉；4=认可 M2 两段式定义（进度总账口径已同步回写）。

1. 「可接受」机器口径替代 A4 盲评：v1 accept = 结构合法 ∧ 真玩通关（CDP 证据）∧ 对抗评审无 P0/P1 ∧ 批内查重通过，不含人类趣味盲评；A4 盲评降级为「事后抽看 accept 样本」的校准动作（非门禁）。是否认可以此机器口径作为「生成成功率」的测量定义？（本项只拍测量口径；M2 过线问题单列第 4 项，两件事分开拍。）
2. 发布门分界：staging 全自动 APPROVE（裁决即审核员，走 admin 审计日志 + 金丝雀限额 + 抽检冻结阀），生产保留人审开关。是否接受「staging 零人在环、生产人审」这条分界线？
3. M-b 资源排序：v1 收口后，「生成半下沉（真实用户链路活）」与「dodge runtime（内容池扩品类，B3）」二者先投哪个？（建议前者——M2 命门是真实生成链贯通，且 clicker 同质化拐点数据可让 dodge 立项更有据。）
4. M2 过线两段式定义（Z3，防过度承诺）：① 成功率指标口径达标 = 本案 accept 率 ≥80%（v1 编排器代产批跑即可测量，使「接通前无法测量」成为历史）；② 生成链路贯通 = 真实用户 submitGenerate 不再停 queued（以 M-b 薄轮询执行器落地为准）。v1 收口仅完成 ①，不得据此宣称 M2 完成；M2 整体收口 = ① ∧ ②。 是否认可此两段式定义？拍板后由执行者同步回写 docs/mvp/MVP进度总账.md（其现行表述「80% 验收线依赖 aigc/Dify 真实接通、接通前无法测量」需更新为「v1 起可测量；贯通另以 M-b 计」）。

---

附：引用文件清单（仓库相对路径）

• 事实底座：docs/agent-specs/2026-06-09-generation-spike/spike-summary.md、docs/agent-specs/2026-06-09-generation-spike/gen_spike.py、docs/mvp/MVP作战清单.md
• 契约：contracts/game-package.schema.json、contracts/dify-workflow-io.json、contracts/prompts/README.md、contracts/prompts/registry.yaml、docs/agent-specs/prompt治理体系-execution.md
• 后端：game-cloud/game-module-aigc/game-module-aigc-server/src/main/java/cn/wanxiang/game/module/aigc/service/task/AigcTaskServiceImpl.java、game-cloud/game-module-aigc/game-module-aigc-server/src/main/java/cn/wanxiang/game/module/aigc/controller/admin/task/vo/DifyCallbackReqVO.java、game-cloud/game-module-project/game-module-project-server/src/main/java/cn/wanxiang/game/module/project/service/publish/PublishOrchestrationServiceImpl.java、game-cloud/game-module-studio/game-module-studio-server/src/main/java/cn/wanxiang/game/module/studio/service/studio/StudioServiceImpl.java
• 后端（终审 Z1/Z2 实查面）：game-cloud/game-module-runtime/game-module-runtime-api/src/main/java/cn/wanxiang/game/module/runtime/api/RuntimePackageApi.java（仅 publish/getStatus + 守门纪律）、game-cloud/game-module-runtime/game-module-runtime-server/src/main/java/cn/wanxiang/game/module/runtime/service/pkg/store/DbPackageStore.java（putManifest 未命中行静默跳过）、game-cloud/game-module-project/game-module-project-server/src/main/java/cn/wanxiang/game/module/project/service/version/GameVersionServiceImpl.java（createForPackage 只建 game_version 行）、game-cloud/game-module-aigc/game-module-aigc-server/pom.xml（现无 project-api/runtime-api 依赖）
• 前端：game-studio/src/host/runtime/index.ts、game-studio/src/host/inject.ts、game-studio/src/host/GamePlayer.vue、game-studio/src/views/create/Preview.vue、game-studio/src/views/play/Play.vue、game-studio/src/router/index.ts
• 方法论：.agents/workflows/mvp-execution-orchestration.md、.agents/skills/contract-first-development.md