d97e194383
- 注册表:docs/architecture/README.md §2,37 份 canonical(frontmatter topic+canonical:true)与表双向机器对账
- 门:.agents/tools/docs-gate.py 六检(品牌根/canonical唯一/死链/入口卫生/留痕隔离/设计档申报),挂 .githooks/pre-commit(本仓已激活)+ .gitea/workflows/docs-gate.yml(待runner)+ wave-close 第8步;旧 check-deadlinks.sh 退役并入 G3
- 清缩:删 54 项历史档(plans 16/agent-specs 设计与spike 20/brainstorms 5/memorys 3/goals+作战清单完成史归档/王蓝莓design/SAA现状html/add-game-template);channel-spike 564K 代码资产迁仓级 spikes/;六件删前蒸馏已迁(代码评审16条open项→进度总账§5、prefix-cache字段表→cheap-model skill、意图基线29条→需求清单附录、九门降级rationale→验收门、A11 TODO→tech-decisions、3layer边界→littlejs-game-dev 指针)
- 修口径约90处:六处SAA『现行主线』旧标、Nacos/RocketMQ『未部署』旧述(07-01反转)、gameDefinition残留、全部死链改 git show 定位;AGENTS.md 249→136行(决策史归tech-decisions);_index 改纯在飞板;对外演示版 md→html
- 依据:docs/agent-specs/2026-07-02-文档治理-{全量普查与裁决-report,SoT注册表与治理门-设计}.md(四路普查191份md+Codex/Opus双评审必修项已折入);恢复基线 8ea97234(单档 git checkout 8ea97234 -- <路径>)
139 lines
11 KiB
Markdown
139 lines
11 KiB
Markdown
# MVP 范围与里程碑事实蒸馏
|
||
|
||
> 蒸馏来源：`docs/superpowers/specs/mvp-execution-spec-design.md`（HJ-MVP-SPEC-001，执行权威）、`docs/architecture/产品/需求清单.md`（Doc A 产品功能）、`docs/architecture/产品/需求模块映射.md`（Doc C 需求↔模块 RTM）、`docs/architecture/架构/README.md`（§1.2 指标、§9 路线）。
|
||
> 目的：让后续 Agent 一篇掌握 MVP 端到端闭环、量化验收线、范围口径、5 工位分工、M0-M5 里程碑、契约先行要点。
|
||
> 相关：架构模块见 [`product-and-architecture.md`](./product-and-architecture.md)；选型与"范围张力"见 [`tech-decisions.md`](./tech-decisions.md)。契约先行 playbook 见 [`../skills/contract-first-development.md`](../skills/contract-first-development.md)。
|
||
|
||
---
|
||
|
||
## 1. 端到端闭环链路（一句话）
|
||
|
||
**创作者登录 → 资产管理 → Prompt 生成 / 资产组装 → 预览试玩 → 发布 → 审核 → 游戏流推荐 → 玩家试玩 → 互动 → 分享 → 广告展示 → 收益归集 → 创作者钱包可见 → 遥测采集 → 质量评分 → 推荐优化。**
|
||
|
||
数据回路闭环：遥测事件 → quality_score → feed 推荐排序 → 更多曝光/试玩 → 更多事件（feed 与 telemetry 互为反哺）。
|
||
|
||
---
|
||
|
||
## 2. 量化验收标准
|
||
|
||
| 指标 | 标准 | 出处与备注 |
|
||
|---|---|---|
|
||
| **P0 产品功能覆盖** | **55 / 55** 项 Doc A 的 P0 产品功能全部可用且可验证 | Doc A 产品口径（详见 §3）|
|
||
| 端到端链路 | 创作→生成→预览→发布→审核→游戏流→试玩→互动→广告→收益 全走通 | 执行 spec |
|
||
| **生成成功率** | **≥ 80%**（基于 3-5 个模板，MVP 验收线） / **≥ 85%**（技术决策版蓝图远期目标） | 两个数字并存：执行 spec §1.2 与 AI 链路验收均为 **80%**；技术决策版 §1.2/§4.1 为 **85%**。**MVP 验收按 80% 判定** |
|
||
| 游戏流首屏 | **P75 < 3s**（技术决策版另列 P95 < 6s） | 执行 spec + 技术决策版 §7.1 |
|
||
| 冒烟测试 | 核心 **5 条**链路自动化通过（`deploy/smoke-test.sh`） | 执行 spec |
|
||
| Bug 门槛 | **P0 Bug = 0**；P1 遗留 ≤ 10 个 | 执行 spec §1.2 |
|
||
|
||
---
|
||
|
||
## 3. MVP 范围口径（「产品功能」口径）
|
||
|
||
> MVP 以 **Doc A 产品功能**作为验收单位（用户可感知）。三文档体系下三个独立计数互不混用：
|
||
|
||
| 文档 | 计数单位 | 总量 | 其中 MVP |
|
||
|---|---|---|---|
|
||
| **Doc A 产品需求清单** | 产品功能 `P-id` | 155 | **55 项 P0**（= MVP 验收线）|
|
||
| **Doc B 技术架构与模块** | 技术功能 `T-id` | 204 | 由 Doc C 反查（= MVP 实现范围）|
|
||
| **Doc C 需求↔模块映射** | RTM 行 | 155 | — |
|
||
|
||
**MVP 验收 = Doc A 的 55 项 P0 产品功能全部走通**；其技术实现范围 = 这 55 项经 Doc C 反查到的 `T-id` 集合（不在此重复罗列，**Doc C 即唯一桥接**，改任一侧只动 Doc C）。
|
||
|
||
**55 项 P0 产品功能按首要 owner（Doc C）分布：**
|
||
|
||
| owner 模块 | P0 数 | owner 模块 | P0 数 |
|
||
|---|---|---|---|
|
||
| feed | 13 | community | 5 |
|
||
| studio | 7 | aigc | 3 |
|
||
| compliance | 6 | runtime | 3 |
|
||
| biz | 6 | trade | 3 |
|
||
| project | 5 | ad | 2 |
|
||
| telemetry | 1 | pay | 1 |
|
||
| ip | 0 | **合计** | **55** |
|
||
|
||
> **demo 闭环骨架(G1–G7)纳入 MVP P0**：双轨专区(P-PLZ-01·P-LIC-06)、锁风门二态(P-LIC-05·P-PUB-03)、统一发布编排+渠道状态机(P-PUB-01)、按 Zone 分区(P-PLZ-01) 均为 P0 产品功能；其后端 `T-PRJ-07/08·T-CMP-12·T-RT-32·T-FED-15` 经 Doc C 纳入实现范围。**编辑器精修**(骨骼/动画/对白 P-CRT-06/07·P-LIC-04)、素材双轨(P-MAT-*)、TapTap 提审、智能体多轮会话(P-CRT-05) 为 P1 → MVP 后增量。
|
||
> **工作量参照**：技术实现工作量 ≈ **137 技术项**，仅用于 §4 人天估算；**验收口径以 55 P0 产品功能为准**。关键口径见 [`tech-decisions.md`](./tech-decisions.md) §4。
|
||
|
||
---
|
||
|
||
## 4. 5 工位编制（WS1-WS5）与职责边界
|
||
|
||
10 人、3 周（15 工作日 = 150 人天）。**验收按 55 P0 产品功能**；**人天按技术功能(T-id)工作量**估算（≈137 技术项，留约 13 人天缓冲）。下表"P0 数"为各工位 owner 模块的 **P0 产品功能数**（合计 55）。
|
||
|
||
| 工位 | 代号 | 人数 | 角色 | 职责边界（owner 模块）| MVP P0 产品功能数 |
|
||
|---|---|---|---|---|---|
|
||
| 平台基座 | **WS1** | 2 | 后端 Senior×2 | Huijing fork / Gateway / DB / CI-CD / **project + compliance** | 11（project 5 + compliance 6）|
|
||
| AI 生成 | **WS2** | 2 | AI 工程师 + 后端 | ~~Dify / OpenGame~~（降级远期未部署，现行=new-api 网关+SAA(Spring AI Alibaba v1.1.2.2)裸图编排 (HJ-AGI-002)，见 tech-decisions §1） / ~~ComfyUI~~（退备选，素材现行=mmx-cli） / **aigc + studio**（创作编排域）/ 质量门禁 | 10（aigc 3 + studio 7）|
|
||
| 运行时与分发 | **WS3** | 2 | 后端 + 前端(SDK) | **runtime + feed** / SDK / 多渠道导出 / 互动 / 分享 | 16（runtime 3 + feed 13）|
|
||
| 产品前端 | **WS4** | 2 | 前端×2 | game-studio 全页面 / game-admin 审核+模板+看板（**承载 55 项 P0 的 UI**）| 不单算 |
|
||
| 数据与变现 | **WS5** | 2 | 后端 + 产品运营 | **telemetry + ad + trade + pay + community + biz** / seed / 验收 | 18（tel1+ad2+trade3+pay1+cmu5+biz6）|
|
||
|
||
> 注：WS1 11 + WS2 10 + WS3 16 + WS5 18 = **55**；WS4 不重复计数（承载 UI）。**studio 后端模块归 WS2**（与 aigc 同工位、调用链最紧密）；其编辑器重交互在 game-studio 前端(WS4)，后端 `game-module-studio` 只持久化会话/资产图/对白树/任务链状态并编排（UX≠后端模块）。**人天**按 T-id 工作量核算（产品功能数 ≠ 人天，一项功能常展开多个 T-id），3 周窗口可吸收。
|
||
|
||
---
|
||
|
||
## 4b. PRD 功能到三仓三端的覆盖（覆盖度版核对结论）
|
||
|
||
模块架构与 MVP 覆盖度文档逐条核对 MVP PRD，结论：**三仓库 + 内部子模块拆分完整覆盖 PRD，无需第四个模块。** 关键映射示例：
|
||
|
||
| PRD 需求块 | game-cloud 模块 | game-studio 页面 | game-admin 页面 |
|
||
|---|---|---|---|
|
||
| 自然语言/模板创作 | aigc(prompt/template/generation) | creator/CreateProject·GenerationStatus | game/template |
|
||
| 预览与轻量编辑 | runtime(compiler/package) | creator/DraftEditor·PreviewPlay | — |
|
||
| 发布/版本/状态 | project(publish+bpm·version) | creator/PublishFlow·profile/MyGames | game/review·version·project |
|
||
| 游戏流/即点即玩/互动 | feed(recommend/interaction/share)·runtime | feed/FeedPage·play/PlayPage | game/feed |
|
||
| 审核/内容安全/推荐管理 | project+bpm·compliance·feed | — | game/review·content-safety·feed |
|
||
| 账号/权限 | system(OAuth2/SMS/RBAC) | auth/ | system/（原生） |
|
||
|
||
六处"看似遗漏"实则已覆盖：匿名玩家（framework 扩展匿名 token）、内容安全（aigc 加 `service/safety/`）、游戏运行容器（studio `components/game-runtime/` 纯前端）、CDN（deploy 配置）、数据导出（telemetry-admin 接口）、防沉迷（system 用户表加 `birthDate` 字段预留）——均无需新模块。
|
||
|
||
---
|
||
|
||
## 5. 里程碑表（M0-M5）
|
||
|
||
| 里程碑 | 日期 | 验证标准 | 验证人 |
|
||
|---|---|---|---|
|
||
| **M0 契约锁定** | 6/9 上午 | `contracts/` 目录 **7 个**契约文件提交 git | 全员签字 |
|
||
| **M1 全栈可启动** | 6/11（Day 3） | `docker compose up` → 全服务绿灯 + Swagger 可调 project CRUD | WS1 lead |
|
||
| **M2 创作链路跑通** | 6/18（Day 8） | Prompt → AI 生成 → 预览试玩 端到端（**真 LLM，非 mock**） | WS2 lead |
|
||
| **M3 分发链路跑通** | 6/20（Day 10） | 发布 → 审核 → 游戏流 → 试玩 → 互动 → 分享 | WS3 lead |
|
||
| **M4 变现链路跑通** | 6/23（Day 11） | 广告展示 → 收益 → 钱包可见 | WS5 lead |
|
||
| **M5 MVP 交付** | 6/27（Day 15） | 种子用户走通全链路 + 冒烟全绿 + P0 Bug = 0 | 产品负责人 |
|
||
|
||
三周节奏：**Week 1（6/9-6/13）** 基座 + 各工位基于契约 mock 独立开发；**Week 2（6/16-6/20）** 链路串通 + 功能完善（Day 10 全链路端到端走通，允许有 bug）；**Week 3（6/23-6/27）** Day 11-12 专职联调（不加新功能）→ Day 13 修 P0 Bug + 性能/安全加固 → Day 14 冒烟脚本 + demo 内容（≥10 款）→ Day 15 灰度 staging + 10 人种子内测 + 交付确认。
|
||
|
||
---
|
||
|
||
## 6. 契约先行（Day 0）与 Mock/并行解耦
|
||
|
||
**Day 0（6/9 上午）全员半天锁定下列 7 个 Day-0 契约文件，写入 `contracts/` 提交 git。锁定后各工位 mock 对方接口独立开发，联调统一在 Day 11 起。** 加上 Prompt Registry（`contracts/prompts/`）共构成 **8 类契约**（Prompt 即第 8 类，见 [`../skills/prompt-governance.md`](../skills/prompt-governance.md)）。
|
||
|
||
| 契约文件 | 内容 | 负责人 |
|
||
|---|---|---|
|
||
| `api-schemas/*.yaml` | 各模块 API 的 OpenAPI 3.0 定义（Request/Response） | WS1 lead 主笔，全员 review |
|
||
| `db-schemas/V1__*.sql` | 核心表结构（Flyway 迁移脚本） | WS1 |
|
||
| `sdk-interface.d.ts` | WanxiangGameSDK 全部 public API 类型 + postMessage 协议 | WS3 SDK 负责人 |
|
||
| `game-package.schema.json` | GamePackage manifest 格式 + 目录结构 | WS3 + WS2 |
|
||
| `events.schema.json` | telemetry 事件名 + 字段（v1） | WS5 |
|
||
| `dify-workflow-io.json`（降级远期未部署，见 `contracts/DEPRECATED-dify-workflow-io.md`） | Dify workflow 输入/输出契约 | WS2 |
|
||
| `ad-slot.schema.json` | 广告位配置格式 | WS5 |
|
||
|
||
Mock 与真实对接节奏（并行解耦核心）：
|
||
|
||
| 工位 | 依赖谁 | Mock 方式 | 真实对接 |
|
||
|---|---|---|---|
|
||
| WS4（前端） | WS1/2/3/5 的 API | `vite-plugin-mock` 基于契约 yaml 自动生成 | Day 6 起逐步替换（改 `.env` 的 `VITE_API_BASE_URL`） |
|
||
| WS3（SDK） | WS4（宿主） | 独立测试页模拟 postMessage | Day 6 集成 |
|
||
| WS2（aigc） | WS1（project） | 内存态写入 + MQ mock | Day 5 真实对接 |
|
||
| WS5（telemetry） | WS3（SDK 上报） | curl 模拟 `/events/batch` | Day 6 真实对接 |
|
||
|
||
解耦纪律：每日 10:00 站会（每人 2 分钟）；阻塞超 30 分钟立即升级；后端新增/变更 API 必须同步更新 `contracts/api-schemas/` 并通知前端。详细 playbook 见 [`../skills/contract-first-development.md`](../skills/contract-first-development.md)。
|
||
|
||
---
|
||
|
||
## 7. MVP 交付物清单（执行 spec §10）
|
||
|
||
`game-cloud/`（后端全模块可编译运行）、`game-admin/`（可登录可操作）、`game-studio/`（全链路可用）、`contracts/`（API/DB/SDK/事件契约）、`deploy/`（docker-compose 全栈/中间件/AI + `sql/seed-*.sql` + `smoke-test.sh`）、`docs/mvp/`（本 spec + 每日进展 changelog）。
|
||
|
||
**主要执行风险与应对**（⚠️ 本段为原执行 spec 风险预案，其中「Dify/OpenGame 攻坚 / 切纯 Dify+模板填充」已随 C2/HJ-GEN-001 失效——现行生成主线=new-api 网关+agent 写码于插件库，Dify/OpenGame 从未部署）：~~Dify/OpenGame 集成超预期 → WS2 前 3 天攻坚，失败则 Day 3 切纯 Dify+模板填充~~；联调期 bug 过多 → Week 3 前 2 天只联调不加功能、P0 优先；广告联盟审核未过 → 先 mock 广告，真实对接可延到 MVP 后 1 周；某工位落后 → Day 5/Day 10 两次检查点，落后则他工位支援。
|