games-development-ai/docs/agent-specs/_archive/2026-06-09-下一阶段路线-plan.md

造梦AI MVP 下一阶段执行计划（autoplan 定稿）

文档号：HJ-PLAN-005 ｜ 日期：2026-06-09 ｜ 分支：dev/2.0.0 ｜ 基线：dev/1.0.0 评审：/autoplan ——CEO 双声音(Claude 子代理 + Codex)、Eng(Claude 子代理实证代码)、用户前提门 D1(双轨→后扩三轨)+审批门 D2(用户授权综合定形状=窄而深+数据回路)。 进度底账：docs/mvp/MVP进度总账.md（单一事实源）。

---

0. 现状基线（事实，核对至 commit eb5dbcb）

• M0 契约 ✅、M1 全栈真启动 ✅（mini-desktop 隔离 staging：Flyway V1-V9 全绿、24 表、admin/app-api 200）。
• 9/13 模块脊柱已建（全接单体+单测+契约+Flyway）；community/biz 未建，ip 寄宿，pay 原生未接。
• 结构骨架 ≈70%，真实可验收 P0 仍个位数：除 project 外 8 模块核心逻辑（Dify/runtime/广告/pay/MQ）全是桩；前端 build 绿但跑 mock 未真接后端。

---

1. 决策定稿（双模型评审 + 用户授权）

两个独立模型一致结论：原案（无论串行联调还是双轨）太工程内视角——把"联调缺口/生成成功率"放中心，却没把外部闸门、数据飞轮、商业验证变成同级执行轨。真护城河 = 数据回路(遥测→quality_score→feed)，不是生成引擎(会被大模型 12-18 月追平)；生成只是入场券。

定稿 = 三轨并行 + 窄而深黄金闭环：

轨	执行者	本质
A 外部闸门轨	创始人本人	启动不可压缩日历闸门 + 种子创作者 + 题材 + 分发入口（创始人最不可替代的事）
B 黄金闭环轨	AI 主 agent	把 1 条完整垂直闭环做到真实可演示、可采数据（含最小数据回路 = 护城河种子）；其余链路烟测登记
C 生成 Spike 轨	AI/工程跑 Dify，创始人评可接受率	限时限预算验证"生成≥80%"地基假设；生成与黄金闭环解耦（闭环用模板/兜底生成，不等 Dify）

1.1 前提（CEO 前提门已确认 + 双模型校正）

• P1 约束 = 外部日历闸门 + Dify 接通，非模块数 → 闸门今天就由创始人并行启动（升级为独立轨 A，非附注）。
• P2 结构骨架 ≠ 可验收 → 本阶段必须产出一个真闭环，不是登记一堆桩。
• P3 深度优先于宽度 → 窄深 1 条黄金闭环；community/biz 后置（但 biz 不机械后置，见 §3）。
• P4（双模型新增）生成 = 入场券非护城河 → 生成轨设硬预算、达及格即止；省下注意力投数据回路与分发。

---

2. 三轨详案

2.A 外部闸门轨（创始人本人，今天启动 —— 机会成本最高的事只有你能做）

• 建闸门看板（owner + 材料 + 最晚提交日 + 阻塞状态）：ICP 备案 / 域名 / 主体 / 支付商户进件 / 广告联盟资质 / 隐私协议 / 内容合规材料 / LLM 实名充值。今天就"提交或明确缺什么材料"，不停留在"要启动"。
• 约 5 个种子创作者 + 定首批 10 个 demo 题材（喂给 §2.D 种子内容）。
• 谈 1 个分发或 IP 冷启动入口。
• 边界：Dify 部署/裸生成不占创始人时间（交 AI/工程，见 2.C）。

2.B 黄金闭环轨（AI 主 agent）：1 条真实垂直闭环 + 其余烟测

黄金闭环（不依赖真实 Dify，用模板/兜底生成 + 现有 Canvas Runtime 3.5KB）： 模板/兜底生成一个 demo 游戏 → runtime 加载试玩(现有 Canvas Runtime) → 发布(真实 publish+锁风门) → feed 可见 → 玩家试玩 → telemetry 真实采事件 → 蠢 quality_score → feed 排序真读它

• 最小数据回路必须真实产出（本阶段 AC，护城河种子）——同步最小写路径，不接 MQ（Codex Eng critical：现 telemetry 只 dispatchToMq() 是 debug TODO；走 MQ 会膨胀成半个 M5）：/app-api/telemetry/events/batch 校验后同步写 game_telemetry_event → 按 game_id+stat_date upsert game_telemetry_game_stat → 算极简 quality_score（完玩率加权）→ 窄接口 upsert game_feed_rank.quality_score/sort_score。事件用契约真名：game_play_start/game_play_end(props.duration_ms,completed)/game_load_failed/like/share（非 play_start/duration/skip）；前端 track() 须生成有效 traceId（现默认 '' 被后端拒）。明确不做：MQ producer/consumer/DLQ、project 回灌、全量重算、多日推荐模型（MQ 只留契约+TODO）。
• Runtime 责任边界（Codex Eng high）：本阶段 runtime = 前端 Canvas Runtime 执行模板/demo 包；后端 runtime 桩只做取包/session 烟测，或单独准备 1 条已发布 game_runtime_package 种子数据。否则前端 GamePlayer 取包失败退回 demo 兜底，"跑通"变 demo 掩盖后端桩。
• 发布→feed 可见的最小机制（Codex Eng high）：feed 只读 game_feed_rank、getZones() 返空、publish 有默认放行 seam——不写 rank 则发布了也不出现。发布成功后显式 upsert game_feed_rank（或后台精选接口写入）；验收须证 feed 顺序是真实数据驱动，非手工提前 seed 的静态排序。
• 5 个开工前置项（Eng 实证，不补则静默假成功）：
  1. 环境变量真名 VITE_API_BASE（非 VITE_API_BASE_URL；request.ts:35）。
  2. mock 中间件加环境门控（VITE_API_BASE 非空即关），启动打印 baseURL+mock 状态。
  3. studio token 改 test1 + 注入 tenant-id:1 头（现发 mock-studio-token→后端判未登录 401）。
  4. 前端运行环境 = 本机 vite dev 连 staging（build 会 OOM）；产物验收用 mini-desktop vite preview --host + /browse。
  5. 契约缺口裁决：一律以 contracts/*.yaml 为准；契约不破坏、不改已合入 Flyway 迁移，但允许新增最小后端实现（telemetry/feed 数据回路）——原"后端零改动"与数据回路目标冲突，已删（Codex Eng critical）。阻断黄金闭环的缺口必须 T+1 修复（标 owner/严重度/是否阻断/最晚日，不许成"缺口坟场"）。
  6. 前端 staging 硬前置补充（Codex Eng high）：sendBeacon 写死同源 /app-api/...，须改走 VITE_API_BASE（或 fetch keepalive / 允许匿名遥测）；axios 注入 tenant-id；所有 staging 种子行统一 tenant_id=1（否则 MyBatis 租户过滤让 feed/stat 查空）；启动日志打印 baseURL/mock/tenant/token 来源。

  admin 侧：专门 env（VITE_BASE_URL=http://100.64.0.7:48080、API_ENCRYPT_ENABLE=false、TENANT_ENABLE=false）。CORS 已确认全放行（非风险）。

• 其余 4 链路只烟测登记（广度，廉价）：HTTP 通 + code==0 + 结构符 yaml，标【真实/桩】，缺口分类登记总账。
• 数据隔离：studio/admin 同库同 userId，串行联调（一端一轮），联调前关键表快照。

2.C 生成 Spike 轨（AI/工程部署 Dify，创始人只评"可接受率"）

• 硬预算（Codex critical）：≤2 天、≤N 次调用、≤1 个 Dify workflow；超预算就停，产品化确定性模板兜底，注意力转回数据回路。
• 三层成功率（Codex critical，不只"不崩"）：① 结构成功率（game-package.schema.json 自动二值校验）② 可运行成功率（Canvas Runtime 加载+30s 无崩溃）③ 可接受成功率（目标创作者/玩家盲测"愿不愿发布/分享/继续编辑"二值，非创始人单评）。
• 阈值校正（Codex high，对齐 ≥80% 验收线）：<60% 立刻转纯模板填充；60-79% 只做模板约束增强（不接 Dify 真实链路）；≥80% 才允许接 Dify 真实生成。产出 spike-eval.csv（模板/序号/三层结果/失败归因），结论须附 csv，不接受裸百分比。
• 密钥：API key/充值凭据走 .env(git-ignored) 或 mini-infra 环境变量，禁明文进 contracts/代码。

2.D 种子内容（无内容则 feed 空、飞轮启动不了，Codex high）

• 建 10 款种子游戏清单（模板/目标用户/封面/试玩目标/埋点/审核状态），喂黄金闭环的 feed，让数据回路有真实行为数据可采。

---

3. 后续阶段（本计划详化首轮三轨，后续占位）

• M2 桩真实化：由 §2.C Spike 结论定走向（≥80% 加力真实化 / <60% 纯模板兜底）。生成达及格即止（入场券非护城河）。
• M3/M5：黄金闭环已起最小数据回路；后续扩到全链路真实 + 5 条链路全通。
• Wave4：community 后置；biz 不机械后置——若广告/支付进件卡住，立刻把 biz 改轻量 lead form + 人工交付看板，验 B 端需求/现金流（可能是最现实的早期收入/融资证据，Codex medium）。
• 真实鉴权/多租户（OAuth2/SMS/RBAC、匿名玩家 token）：本阶段 mock，但须排期到下一步前，至少一条负路径验证（账号/权限是 P0，建显式 backlog）。

---

4. 验证与回滚

• 数据回路 A/B 验收协议（Codex Eng critical，须可执行）：备同 zone、同 boost 的 A/B 两个已发布游戏 → 记初始 /app-api/feed/stream 顺序 → 向 B 上报有效 game_play_start + game_play_end(duration_ms,completed=true) + like + share → 断言 game_telemetry_event 有原始行、game_telemetry_game_stat.quality_score 变大、game_feed_rank.sort_score 同步变大 → 再请求 feed，B 排到 A 前 → 重复同 traceId 批次不重复计数 → 关 mock 后仍通过。
• 通用判定：不只看 HTTP 200，须断言响应来自 staging（code==0+结构符 yaml+非 mock 特征值）；每链路跑负路径（错 token→401、停后端→不白屏、空数据→空态）。主 agent 独立复跑（不采信子代理自报）。
• 回滚单元拆 4（各自独立 commit，Codex Eng）：① 前端联调开关 ② telemetry 同步最小实现 ③ feed rank 回灌接口 ④ 种子数据脚本。
• 数据污染清理：黄金闭环测试数据用固定 traceId 前缀 + 固定 gameId 清单 + 独立 tenant + cleanup SQL；验证前后输出关键表快照。

5. 里程碑 + CEO 周看指标

• 推进 M3 分发链路 + M5 数据回路最小闭环（护城河种子真实起步）。
• 每周只看 6 个 CEO 指标（Codex critical）：真实生成可接受率 / 单局加载成功率 / 玩家完玩+次日回访 / 每款游戏事件量 / 外部闸门状态 / 首个收入或付费意向证据。
• 6 个月不后悔的判据：不是"模块能启动"，是"有人要用 + 能合规上线 + 能采数据 + 能产生收入"。

---

Decision Audit Trail（autoplan）

#	阶段	决策	分类	原则	理由	否决项
1	CEO	运行 Claude 独立 CEO 子代理	Mechanical	P6	始终跑独立声音	跳过
2	CEO	Codex CEO 声音（补跑：codex 后就绪）	Mechanical	P6	用户告知 codex ready，补齐双声音	仅 subagent
3	CEO	下一阶段排序方向	USER-GATED(前提门 D1)	—	用户选「双轨并行」	纯联调/M2优先/仅闸门
4	CEO	计划形状（广浅 vs 窄深）	USER-GATED(审批门 D2)→授权综合	P1+P2	用户授权我综合；双模型一致"窄深+数据回路"，否广浅	广而浅(原案)
5	CEO	双轨→三轨（加外部闸门轨）	Mechanical	P1	两模型均指闸门=约束，Codex 升级为独立轨	闸门作附注
6	CEO	数据回路最小闭环=本阶段 AC	Taste→采纳	P1	护城河种子，两模型一致须产出非登记	仍后置 M5
7	CEO	创始人时间转闸门/种子/分发（Dify 交 AI）	Mechanical	P3	创始人机会成本，调工具非不可替代	创始人跑 Dify
8	CEO	生成轨硬预算 + 三层成功率 + ≥80%才接Dify	Mechanical	P1	生成=入场券非护城河，60%误导	≥60%即加力
9	CEO	10 款种子内容清单	Mechanical	P1	空 feed 无行为，飞轮启动不了	无种子供给
10	Eng	运行 Claude 独立 Eng 子代理	Mechanical	P6	独立工程评审	跳过
11	Eng	5 开工前置项（VITE_API_BASE/mock门控/token/vite dev/契约裁决）	Mechanical	P5+P1	实读代码挖出会静默假成功的硬错	按原配方开工
12	Eng	缺口 T+1 修复机制（阻断黄金闭环必修）	Mechanical	P5	防"缺口坟场"，Codex high	只登记不修
13	Eng	风险表校正（CORS 非风险，鉴权/加密/401 真风险）	Mechanical	P5	corsFilter 已全放行	保留原风险表
14	Eng	数据隔离=串行联调	Taste→采纳	P3+P5	同库同 userId，串行最简	拆 userId 并发
15	—	Design/DX 阶段跳过	Mechanical	P3/P6	无新 UI 设计面；非开发者工具	跑 Design/DX
16	Eng	Codex Eng 声音（补跑）	Mechanical	P6	codex 就绪，补齐 Eng 双声音	仅 subagent
17	Eng	数据回路=同步最小写路径，不接 MQ	Mechanical	P5	Codex 实证 telemetry 走 MQ 会膨胀成半个 M5	走 MQ
18	Eng	事件用契约真名 + traceId 生成	Mechanical	P1	Codex 实证 plan 事件名与契约不符、traceId='' 被拒	用 plan 旧事件名
19	Eng	删"后端零改动"→允许新增最小后端实现	Mechanical	P5	Codex 指出与"真碰 telemetry/feed"硬冲突	保留零改动
20	Eng	补 beacon 走 baseURL + 种子 tenant_id=1 + 发布后 upsert feed_rank	Mechanical	P5+P1	Codex 实证 sendBeacon 绕 baseURL、feed 不写 rank 不出现	遗漏
21	Eng	A/B 验收协议证 quality_score 驱动排序	Mechanical	P1	防"排序真变化"流于口号	主观判定