diff --git a/docs/architecture/_recall/README.md b/docs/architecture/_recall/README.md deleted file mode 100644 index 2791aadc..00000000 --- a/docs/architecture/_recall/README.md +++ /dev/null @@ -1,114 +0,0 @@ -# 历史设计点回收 · 总索引 - -> 这是一次穷尽式的历史回收。六个领域各派一个 agent,把绘境AI 在历史与留痕文档(`docs/agent-specs/` 及其 `_archive/`、`docs/brainstorms/`、`docs/plans/`、`docs/memorys/`、`docs/architecture/_archive/` 里的旧版长设计文档)里**讨论过、但现行 `docs/architecture/` 没有沉淀下来**的设计点、想法、顾虑、约束,逐条挖出来,按领域摆成六份清单。 -> -> 目的只有一个:文档在反复重写、收窄、迁家的过程中,历史上认真想过的好东西、提过的真顾虑,很容易被悄悄丢掉。这份回收把它们重新摆到台面上,让创始人逐条过目、亲自裁定捡回还是放弃,免得现行架构在演进里漏掉了当初本该考虑的约束。 - ---- - -## 这份回收回答的问题 - -不是"现行档写得好不好",而是"**历史上想到过、现在还该不该管的东西,有没有被漏掉**"。所以它只收"历史有、现行没有"的差集——凡是现行档已经讲清楚的,一律不列(那是噪音)。 - -每一条都按同一个口径分了三种状态: - -- **遗落**——历史讨论过、有价值,却没进现行档、也没被明确放弃。这是这次回收的重点,60 条。它们可能是个被认真想过的好想法,也可能是一条该考虑却没人记下来的约束或顾虑。 -- **过期 / 弃用**——讨论过,但已经被明确决定不做或被取代。列出来不是要捡回,而是留个痕:让你知道这条路当初想过、为什么走不通,避免日后重新讨论一遍。25 条。 -- **不确定**——拿不准现行档到底覆盖没有。最常见的情形是"后端已经沉淀、但前端或某个域的承载没沉淀",到底算不算覆盖,取决于你对"那个域的文档边界"的口径。114 条,其中前端一家占了 43 条,后面会单独讲为什么。 - -每份清单的最后一列"判定"都留空,等你逐条勾:捡回 / 不捡 / 再议。 - ---- - -## 六份清单一览 - -| 领域 | 清单文件 | 总条数 | 遗落 | 过期/弃用 | 不确定 | -|---|---|---:|---:|---:|---:| -| 产品战略 | [产品战略-历史设计点.md](产品战略-历史设计点.md) | 32 | 17 | 2 | 13 | -| 前端 | [前端-历史设计点.md](前端-历史设计点.md) | 54 | 6 | 5 | 43 | -| 后端数据契约 | [后端数据契约-历史设计点.md](后端数据契约-历史设计点.md) | 25 | 4 | 3 | 18 | -| 生成引擎 | [生成引擎-历史设计点.md](生成引擎-历史设计点.md) | 28 | 10 | 7 | 11 | -| 运维基建 | [运维基建-历史设计点.md](运维基建-历史设计点.md) | 30 | 9 | 6 | 15 | -| 运营变现合规 | [运营变现合规-历史设计点.md](运营变现合规-历史设计点.md) | 30 | 14 | 2 | 14 | -| **合计** | | **199** | **60** | **25** | **114** | - -> 运营变现合规另有 4 条只做指向、不展开的交接条目(战略层的遗落点归在产品战略清单里,那份清单第七节登记交接),所以那份文件本身提到 34,但带状态、要判定的是 30 条。 - ---- - -## 先看这几条:一个想法横跨好几个领域 - -逐条判定之前,有几条值得先拎出来。它们不是孤立的一条,而是同一个设计意图散落在好几份清单里——如果分开判,容易在不同领域各判一次、判出不一致的结果。建议先把这几条当作整体定调,再回到各清单逐条过。 - -**一、对话式创作 + 六类素材驱动生成(最大的一条口径分叉)。** 后端的对话式生成、差量修改、六类素材契约,已经是架构域生成引擎子树里的现行真相,studio 三路由也建好了。但前端域文档仍然把这整套创作能力标成"工作坊 IDE 化、MVP descope",产品域的六资产验收口径也还悬着。结果是:**后端已经走到对话式了,前端和产品的设计档还停在"一句话 + 选模板 → 整包生成"**。涉及条目——前端 C01–C04(对话框 / 素材上传 UI / 智能确认卡 / 差量修改入口与差异展示全无承载)、生成引擎 001–002、产品战略 P-CRT-02。这是本次回收里最该由你先定调的一件事:前端创作 UX 现在到底是什么形态。 - -**二、数据飞轮的生成侧工程落点。** 护城河讲的"资产沉淀 + 网络效应 + 数据"三层,在生成侧本来有具体工程动作:创作者资产库 → 资产市场、玩家 → 创作者的 remix(带溯源链)、生成全量 + 收益数据回流当训练语料。这些创始人当初在 HJ-GEN-001 亲拍"全采纳",收窄到 Tier0 当下产线时丢掉了。涉及生成引擎 003/004/005,呼应产品战略护城河那组。护城河的故事讲了,但落地的工程钩子没在现行档里。 - -**三、审核台与内容安全运营,整块空白。** 内容审核双层架构(自部署快检 + 阿里云兜底 + 人审队列)、锁风门三档强度、违规处置分级——这套平台日常内容安全运营的骨架,现行运营档完全没有。涉及运营变现合规 017/018/019,以及前端 admin 段。这是平台敢放量之前绕不开的一块。 - -**四、平台吞并风险,没有风险章。** 如果微信 / 抖音自己上"IP 授权 + 一句话生成",绘境的位置在哪?这是真实的上游平台风险,现行产品战略叙事里完全没有风险章——尽调时是减分项。产品战略-004。 - -**五、线上靠什么观测,运维主档留白。** 蓝图画了 Prometheus / Grafana / Jaeger,现实只有秒级冒烟门和一个可用性数字,配不上 ≥99.5% 的目标。运维域作为"可用性怎么达标"的家,却没回答这个问题。运维基建-001,以及与它同组的几条稳定性红线(OOM 保护、磁盘水位告警、数据可靠性前置清单)。 - ---- - -## 为什么前端有 43 条"不确定" - -值得单独说一句,免得你在前端清单里被这个数字劝退。前端的 43 条不确定,绝大多数是同一个模式:体验 SLO(点卡 ≤2s、首帧 <300ms、自适应画质)、feed 容器调度、宿主冷启动逼近超时这些设计点,其实活在架构域生成引擎子树里、或者已经落在代码里了,只是前端域 README 没有引用、没有承载。它们算不算"已覆盖",取决于你对"前端域文档该不该把这些承载进来"的口径。所以这 43 条本质上是一个边界问题,不是 43 个独立缺口——你定一次"前端域档要不要收这类体验约束",大部分就一次性清掉了。 - ---- - -## 怎么判定 - -每份清单是一张表,列是:**ID / 设计点 / 出处 / 状态 / 为什么 / 判定**。前五列是 agent 填好的,最后一列"判定"留空给你。 - -建议的顺序:先把上面那五条横跨多域的定调了,再按"遗落 → 不确定 → 过期"的优先级逐条过——遗落是真要捡回的,不确定多半是边界口径(定一次清一批),过期只需扫一眼确认"知道了、不捡"。判定结果你怎么标都行(捡回 / 不捡 / 再议),标完我按你的结论,把要捡回的逐条接进对应的现行架构文档。 - ---- - -## 创始人判定:5 条横跨多域优先项(2026-06-21) - -第一轮先判了上面那 5 条横跨多域的。结论与落点如下,其余约 194 条待后续逐条过。 - -| # | 优先项 | 创始人判定 | 已落地 / 下一步 | -|---|---|---|---| -| 1 | 对话式创作 + 六类素材 | "一句话 + 选玩法模板"只是启动生成的点位之一;完整产品形态 = 对话创作 + 差量修改游戏 + 修改游戏素材 | 已对齐进档:[前端 README §7.3](../前端/README.md) 产品形态定调(对话式创作不再算 descope、前端 UI 列为待补);未擅改 P1/P0 验收契约 | -| 2 | 数据飞轮生成侧落点 | 没有成型设计,需要补充 | 已立待补设计骨架 + 范围建议:[生成引擎 README §10](../架构/生成引擎/README.md);待创始人定 MVP 边界 | -| 3 | 审核台与内容安全运营 | 没有设计,需要补充 | 已立待补设计骨架 + 范围建议:[合规闸门 §9](../运营/合规闸门.md);待创始人定 MVP 边界 | -| 4 | 平台吞并风险 | 应对 = 深化游戏引擎使用 + 深化游戏创作能力 | 已对齐进档:[商业定位 §3](../产品/商业定位.md)「平台方下场风险与应对」,指向 tier2 自治富游戏引擎 + 对话式创作 | -| 5 | 线上观测体系 | admin 补观测跳转 / 观测大图;栈 = OpenTelemetry + Grafana + 夜莺 + 链路日志 / 指标 / 告警 + k8s;参考 yudao-cloud / vue-pro | 已立待补设计骨架 + 范围建议:[运维 README §4](../运维/README.md);待创始人定 MVP 边界(含是否本阶段上 k8s) | - -第 2 / 3 / 5 条的骨架里原本写了"范围建议(待创始人确认边界)"——这三条要补的设计都不小,边界(MVP 做到哪一档)定了我才出正式设计稿,免得范围未定就写、写完返工。 - -**更新(2026-06-21):创始人已定三条边界——② 三条飞轮全做 / ③ 审核台全做(含锁风三档)/ ⑤ 观测全做且本阶段上 k8s。** 范围已回填进三个骨架(生成引擎 §10 / 合规闸门 §9 / 运维 §4);其中 ⑤ 的 k8s 迁移是部署架构大变更,我已在骨架里标注 blast radius、建议与观测埋点解耦单独立项。**4 份正式设计稿(数据飞轮 / 审核台运营 / 观测体系 / k8s迁移)已出并经 Codex+Opus 双评审精修;创始人 2026-06-22 进一步拍板:k8s 收窄(单节点 k3s + 数据库不进集群)+ 缓做(排 W-G1 之后)、P-FED-12 升 P0、同款首期不分成、审核台信用 + 降权放第一期。** - ---- - -## 第二轮:查漏补缺 + review(2026-06-22) - -第一轮 199 条出清单后,这几天又落地了 9 份新设计档(数据飞轮 / 审核台运营 / 观测体系 / k8s迁移,以及更早的 5 份 P0)。第二轮做两件事:拿这 9 份新档回头复核第一轮的判定,再补第一轮漏挖的。六个领域各派一个 agent,结果分三类。 - -| 领域 | 第二轮清单 | 新挖 | 改判 | 已被新档覆盖 | -|---|---|---:|---:|---:| -| 产品战略 | [产品战略-第二轮.md](产品战略-第二轮.md) | 4 | 4 | 5 | -| 前端 | [前端-第二轮.md](前端-第二轮.md) | 14 | 6 | 6 | -| 后端数据契约 | [后端数据契约-第二轮.md](后端数据契约-第二轮.md) | 8 | 3 | 3 | -| 生成引擎 | [生成引擎-第二轮.md](生成引擎-第二轮.md) | 9 | 2 | 4 | -| 运维基建 | [运维基建-第二轮.md](运维基建-第二轮.md) | 4 | 11 | 9 | -| 运营变现合规 | [运营变现合规-第二轮.md](运营变现合规-第二轮.md) | 4 | 2 | 9 | -| **合计** | | **43** | **28** | **36** | - -**一个让人安心的结论:这几天的设计稿把第一轮 36 条遗落 / 不确定接住了。** 运营变现合规第一轮自判"最该补的重灾区"是审核台,这次《审核台运营》几乎整章接住(双层审核 / 锁风三档 / 违规处置 / 审核状态机 / SOP 水印 / 未成年联动 / 人审台阶,9 条);运维基建的可观测性栈、OOM 保护、内存硬限、磁盘告警等 9 条被《观测体系》《k8s迁移》接住;生成引擎的资产市场 / remix 飞轮 / 收益回流 4 条被《数据飞轮》接住。回收 → 设计这条闭环是有效的。 - -**复核揪出一个真判错(后端数据契约-008)。** 第一轮把"feed 推荐完整目标信号公式"判成遗落,实际它早写在 `架构/README.md §7`——第一轮圈比对范围时漏看了架构域这份总纲 canonical。出处本身不假,错在没看到它已进现行档。提醒:第一轮的比对基线要补全架构 README。其余 27 条改判都是分类微调或因新档落地的状态收紧。 - -**新挖 43 条仍待你逐条判(判定列留空),重点几条:** - -- **跨域双漏(前端 J / K 段)**:新设计稿落在运营 / 运维域、却要 game-admin 前端承载——审核台四页 + 观测三入口,前端 agent 与运营 / 运维 agent 互相以为对方会挖,结果都漏。这是第一轮最系统的盲区。 -- **三条确定性后端缺口(后端 026 / 029 / 032)**:`game_trade_income` 缺 `game_id` 列、`game_telemetry_game_stat` 缺留存字段(这两个正是收益回流的 join 键缺口)、封号级联零实现(封了创作者他照样能创作)。这是缺口不是取舍。 -- **生成硬门 pivot 未回填(生成引擎-029)**:2026-06-20 创始人把生成硬门从"九门聚合"收窄成"客观健康门 A–E",这是 gamedef 做到 91.7% 的关键,但只进了 `.agents/skills`,生成引擎架构 canon 还把九门当统一硬地板讲。 -- **冷启动供给(产品战略 033 / 034)**:飞轮"从零启动那一下"——开张摆什么内容(种子游戏 + 题材)、头几个创作者谁来招(种子创作者 BD = 创始人不可替代),第一轮和现行档都漏了。 -- **运行时体验底线(运营 035)**:广告在玩家端挂了必须跳过让游戏继续——对 IAA 平台是留存生命线,两份变现档零覆盖。 -- **生成命脉的运维盲区(运维 031)**:new-api 网关多通道健康巡检 + key 失效监控(2026-06 通道批量失效真实发生过),现行档只有一句飘在风险表的应对、零运维落点。 - -判定方式同第一轮:每条第二轮清单带空判定列,你勾捡回 / 不捡 / 再议。 diff --git a/docs/architecture/_recall/产品战略-历史设计点.md b/docs/architecture/_recall/产品战略-历史设计点.md deleted file mode 100644 index af6d81a7..00000000 --- a/docs/architecture/_recall/产品战略-历史设计点.md +++ /dev/null @@ -1,119 +0,0 @@ -# 产品战略 · 历史设计点回收清单 - -> **这份清单是什么**：一次穷尽式的"历史设计点回收"。它把绘境AI 在历史/留痕文档里**讨论过、但现行 `docs/architecture` 产品域与运营域里没有沉淀下来**的产品战略设计点、想法、顾虑、约束，逐条挖出来摆在一起，免得历史上认真想过的好东西、提过的真顾虑随着文档重写被悄悄丢掉。聚焦范围是产品战略这一块：产品定位与愿景、需求与 P0 范围、游戏品类与玩法设计、护城河四层、商业模式与三线收入、用户角色与端到端流程、增长与冷启动。 -> -> **判定口径**：对历史里的每一条，问"它在现行档里有没有被讲清楚"。**遗落** = 现行档没讲、也没被明确弃用（是个被讨论过的好想法，或一条该考虑的约束/顾虑，却没沉淀进来）；**过期/弃用** = 历史里讨论过、但已被明确决定弃用或被取代（也列出来，让创始人知道它被想过、为什么弃，避免重复讨论）；**不确定** = 拿不准现行档到底覆盖没有。现行档已经讲清楚的，不列。 -> -> **判定列留空**：每条最后一列"判定"是空的，留给创始人勾选（捡回 / 不捡 / 再议）。 -> -> **我扫了哪些历史文档**（按信息密度排序）： -> - `docs/agent-specs/_archive/2026-06-10-架构文档三向审计-review.md`（HJ-AUDIT-001，四颗雷 + 外部核查，信息最密） -> - `docs/agent-specs/_archive/2026-06-17-demo与三文档套件缺口冲突审计-review.md`（HJ-DEMO-AUDIT-001，5 项产品决策待拍板） -> - `docs/memorys/2026-06-08-技术护城河复盘.md`（护城河真伪判定 + IP 战略岔路四议题） -> - `docs/brainstorms/2026-06-12-游戏生成系统意图清单-草案.md`（意图基线 v1，29 条产品/工程意图，创始人已冻结） -> - `docs/agent-specs/_archive/战略与合规.md`（已折叠进现行运营域，§6 留有待拍板项） -> - `docs/agent-specs/_archive/2026-06-08-mvp业务决策.md`（D1-D4 四项业务决策） -> - `docs/agent-specs/_archive/2026-06-09-下一阶段路线-plan.md`（三轨执行计划 + 6 个 CEO 周看指标） -> - `docs/architecture/_archive/`（投资人版 / 技术决策版 / 开发团队版 / 产品需求清单旧版） -> - `docs/memorys/2026-06-07-三文档与MVP口径迁移.md` -> -> **对照的"现行已沉淀"基线**：`docs/architecture/产品/`（README / 商业定位 / 护城河话术 / 需求清单 / 需求模块映射）、`docs/architecture/运营/`（变现与单位经济 / 合规闸门 / 渠道发行 / 变现端到端 / README）、`docs/architecture/架构/`、`.agents/knowledge/`（product-and-architecture / mvp-scope-and-milestones / glossary）。 - ---- - -## 一、竞争格局与窗口期（顾虑型为主） - -现行《商业定位》的竞品四象限只画了极逸 SOON / TapTap 制造 / FunloomAI 三家，把战场定义为"生态完整度 vs 技术深度"。但历史审计里有几条更尖锐的竞争顾虑——尤其是"自有 feed 这块地早有人占着"和"竞品数字未经核实"——只零散落在运营域或干脆没进现行档，对外尽调时容易被打脸。 - -| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-001 | **自有 feed 形态早有现任者（摸摸鱼 / 233 乐园 / 4399 / 微信小游戏中心）** —— 休闲游戏信息流这块地不是空白，差异化不能押在"自有 feed 形态"本身 | 三向审计 §0/§2「现任者证伪」；现仅落在 `运营/README.md` L44 | 不确定 | 这是审计对抗评审吸收的核心结论之一，但它只进了运营域 README，**产品域《商业定位》的竞品四象限里完全没有这三家现任者**——读产品域的人（投资人、新同事）会以为 feed 是无人区。建议把这条搬进产品域竞品分析，否则对外叙事和内部判定两张皮 | | -| 产品战略-002 | **竞品融资数字需外部核查（"极逸近 1 亿"实为"超千万"）** —— BP 引用的极逸 SOON"融资近 1 亿"外部只核到"超千万"，"自研三引擎"无外部证据；FunloomAI"百度云合作"查无信源 | 三向审计 §6 外部核查表；护城河复盘 §5「未独立核实」 | 遗落 | 现行《商业定位》和《护城河话术》仍直接写"极逸 SOON（融资近 1 亿）"，**未带"单源/打脸"标注**。进融资材料、被尽调交叉核验时，一个未核实的竞品数字会让对方默认你其余陈述都注水。该把这些数字降级为"据竞品自述/单源，待核"或补可引用信源 | | -| 产品战略-003 | **TapTap 制造 = 最大现实威胁、窗口正在收窄** —— 已确证 2026-01-31 上线（自然语言生成 + TapTap 渠道、免费），是离绘境最近的现实威胁 | 三向审计 §6；护城河复盘 | 不确定 | 现行四象限把 TapTap 当"有流量但封闭"轻轻带过，**没点明它是同形态最大威胁、窗口因它收窄**。窗口期判断（6-12 月）的紧迫性来源之一就是它，值得在战略叙事里讲透 | | -| 产品战略-004 | **上游平台吞并风险（腾讯/字节自上"IP 授权 + 一键生成"）** —— 若微信/抖音自己上"IP 授权 + 一句话生成"，绘境的位置在哪？这是真实的上游平台风险 | 护城河复盘 §6 议题①质疑3；三向审计 §6（腾讯/字节未正面进入、网易 UGC 工具迫近、Roblox Cube 季度迭代） | 遗落 | 现行档**完全没有"上游平台风险/平台方下场"这一章**。护城河复盘的结论是"平台做通用、不会为腰尾 IP 做精细保真+分成，但这是真实风险，须在风险章正视"。一个没有风险章的战略叙事在尽调里是减分项 | | - ---- - -## 二、护城河四层与 IP 战略（多为已收口、但有降级细节遗落） - -护城河四层（数据/网络/资产/合规）现行档讲得很完整，IP"是点火燃料不是墙"也已沉淀。但护城河复盘里那条 IP 战略岔路走了**四次降级**，其中几个关键约束（腰尾部 IP 而非顶流、王蓝莓名称美术必须原创、品类独家被否）散落在历史里，现行档只留了结论、丢了"为什么"和几条硬约束。 - -| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-005 | **IP 护城河只能建在腰尾部 / 表情包型 IP 的规模化，不能讲"顶流独家"** —— 资本碾压下拿不到顶流独家，主攻层须诚实定为腰尾部 IP（已有锚点：王蓝莓） | 护城河复盘 §6 议题①质疑1 + 战略岔路 | 遗落 | 现行《护城河话术》讲了"IP 是燃料不是墙"，但**没沉淀"主攻腰尾部、别碰顶流独家"这条战略选择及其理由**。这是 IP 叙事的诚信边界——对外讲"我们要做正版 IP 规模化"时，必须自己先框死在腰尾部，否则被问"那你怎么拿顶流"就崩 | | -| 产品战略-006 | **王蓝莓系市面已有热门 IP，对外演示前名称/美术/主角必须原创** —— 玩法机制可借鉴（不受著作权保护），但《王蓝莓的小卖部》的名称/美术/角色须换成自有，恰合"平台吉祥物系"方向 | 意图清单 §5 风险旗 | 遗落 | 这是一条**法律风险约束**，现行产品域/运营域都没记。如果对外投资人演示直接用"王蓝莓"原名原形象，是侵权风险；该把"对外演示用自有吉祥物"作为一条红线沉淀进战略或合规档 | | -| 产品战略-007 | **王蓝莓授权 = 非独家 · 数年 · 分成 · 靠人脉获取** —— 据此 IP 在供给侧零防御力（竞品可拿同一个 IP）、获取路径不可规模化（人脉=一次性、有关键人风险） | 护城河复盘 §6 议题② | 不确定 | 现行《商业定位》只说"IP 非独家、是冷启动燃料"。**"靠人脉拿到、不可复制 BD"这条关键人风险没进现行档**——它直接决定 IP 是"样板"还是"引擎"。是否要把"建立可复制的 IP BD 打法"列为一个战略待办，值得议 | | -| 产品战略-008 | **谈"AI 生成小游戏品类独家"曾被提出作为 IP 升级为护城河的高杠杆动作** —— 整体非独家没关系，单独谈"这一细分品类独家"对 IP 方成本极低，却能让"这条赛道只有我们有王蓝莓"成立 | 护城河复盘 §6 议题③ | 过期/弃用 | **已被明确否决**（2026-06-08："品类独家：不能"）。列出来是让创始人记得这条路想过、走不通（拿不到品类独家），避免日后重新讨论。若未来 IP 议价能力变化，这仍是唯一能把 IP 从燃料升级为细分护城河的动作，可作为"条件触发再议"项 | | -| 产品战略-009 | **IP 保真护城河的真正资产是"已签约 IP 库 + IP 方信任 + 历史保真口碑"，锁风技术只是入场券** —— 技术（锁风+LoRA）竞品都能做，真壁垒是资产/关系累积 | 护城河复盘 §6 议题①关键 reframe | 不确定 | 现行《护城河话术》B 版讲了"锁风不是高深算法、价值在流程合规"，但**没把"IP 库+信任+口碑=真资产层"这个正向 reframe 讲出来**。这其实是 IP 故事里最该主打的那一面（资产壁垒+合规壁垒的具象），不该只留否定式口径 | | - ---- - -## 三、商业模式与三线收入（已收口为主，少数测量/承诺约束遗落） - -三线变现排序（B 端现金线 → 自有端数据线 → 渠道规模线）现行《商业定位》和运营域已沉淀得很扎实，分账公式、平台恒留 20%、IAA 万级 DAU 才回本、诚信红线都在。下面几条是审计当时提出、但偏"测量计划"和"用户侧诚信"的约束，现行档没完全接住。 - -| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-010 | **玩家侧获客通路与预算在全部文档里是零字** —— 投资人版只有 2 个变现数字、10 万创作者目标无推导、玩家侧获客通路与预算 0 字 | 三向审计 R3 | 遗落 | 现行档把供给侧（创作者激励、新人任务）讲得不错，但**玩家从哪来、获客成本多少、10 万创作者怎么推导出来——依旧没有**。飞轮要转，需求侧（玩家）的冷启动同样关键，这是个真实的战略空白 | | -| 产品战略-011 | **"满 5 元提现/能赚钱"对用户是下一笔潜在诚信债** —— 种子期创作者广告收益≈0，"满 5 元提现"长期不可达，对用户宣传"能赚钱"可能成为面向用户的诚信债 | 三向审计 R3；护城河复盘 | 不确定 | 现行《变现与单位经济》§4.2 已有"对创作者宣传必须用头部款口径、不做普遍性承诺"的诚信红线——**这条已部分沉淀**。但"满 5 元长尾不可达"作为一条产品体验/预期管理约束，是否要在创作者引导/激励文案层面落地（而不只是写在经济模型档里），值得议 | | -| 产品战略-012 | **每游戏粒度的单位经济测量计划（LLM 成本/审核成本/广告产值真实埋点）** —— 不是现编一页假设数，而是把数据回路扩成"每款游戏成本/收益真实埋点"的测量计划 | 三向审计 R3 修法②；护城河复盘 | 不确定 | 现行《变现与单位经济》§6 已把它登记为"W4 ③④待办（按游戏粒度成本/收益埋点）"——**已沉淀为待办**。这里标"不确定"是因为它躺在工程待办里、没上升为战略级"先把单位经济测准再谈规模"的优先级判断；是否要抬到战略层值得议 | | -| 产品战略-013 | **B 端"32 模板库 / 15min 自动出案 / 可交互 demo 自动生成"是产品承诺还是愿景示意（未拍板）** —— demo 高调呈现，但 biz 真实只有轻量 lead form + 人工报价，差距巨大 | demo 审计 §八待拍板#5；§四 C5 | 遗落 | 现行 Doc A 的 P-BIZ-02/03/04 仍是光秃秃的 P0，**没标注"32 模板/15min 自动"到底是承诺还是示意**。这直接决定 P-BIZ-02/03/04 的验收口径与 biz 模块建设范围，是一条悬而未决的产品边界，creator/B 端客户预期管理都依赖它 | | - ---- - -## 四、需求与 P0 范围（最该处理的一组——审计开出的口径调整大多没落地） - -这是整份清单里最实在的一组：三向审计和 demo 审计都对 55 P0 提出了具体的进/出/升调整，但翻看现行 Doc A，**绝大多数调整没有落地，Doc A 几乎还是 2026-06-07 的原貌**。这些不是泛泛而谈，是带行号证据的具体口径裁决，遗落它们等于让 MVP 验收集停在一个已被两次审计判过"需换血"的状态。 - -| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-014 | **存在"最小可验证集≈30 项"与"最小可上线集≈40 项"两个工作集** —— 邀请制内测口径只需约 30 项 P0，渠道线公开口径约 40 项，与"55 P0"是三个不同的工作边界 | 三向审计 §5 + R3；demo 审计现状 | 遗落 | 现行档只有"55 P0"一个口径。**审计提出的"30 项内测可验证集 / 40 项上线集"这个分层边界完全没沉淀**——它对应三线排序（自有端内测 vs 渠道线公开），是个很有用的、按合规阶段切分的范围管理工具，丢了可惜 | | -| 产品战略-015 | **P-FED-12「同款创作跳转工作坊」应升 P0（玩家→创作者转化的唯一杠杆）** —— 玩家流量导回创作供给是网络效应飞轮的核心，这是唯一杠杆 | 三向审计 §5「升」；意图基线 GP10「remix 飞轮」/ P9/XP6 | 遗落 | 现行 Doc A 里 P-FED-12 **仍是 P1**。审计明确建议升 P0，理由是它是玩与造互相转化的唯一入口、网络效应护城河的核心飞轮。把它压在 P1 等于把飞轮的关键一环排到 MVP 之外 | | -| 产品战略-016 | **P-OPS-01「创作者基础播放数据」应升 P0-lite（供给侧留存断点）** —— 创作者发布后"盲飞"看不到数据=供给侧留存断点，最基础的播放数应给 P0-lite | 三向审计 §5「升」 | 遗落 | 现行 Doc A 里 P-OPS-01 **仍是 P1**。创作者发了游戏却看不到任何数据，是留存杀手；审计建议至少把"基础播放数"提到 P0-lite。现行没采纳 | | -| 产品战略-017 | **法定 8 项产品功能须按三线排序分批进 P0（不是一次性全塞）** —— 渠道线起步即需 = AIGC 标识/注销/关个性化推荐；自有端公开前 = 实名/防沉迷/青少年模式/未成年充值限制；真钱开闸前 = 提现实名税务 | 三向审计 §5「进」 | 不确定 | 现行《合规闸门》已把 8 项法定要求作为整组讲清了，**但"按三线排序分批进 P0"这个分批节奏没明确落到 Doc A 的优先级里**（Doc A 的 8 项法定功能换血"待律所意见才定稿"，仍挂起）。分批口径有助于不被合规一次性压垮 MVP，值得议 | | -| 产品战略-018 | **P-PUB-01「外部多渠道发布」应从 P0 降 P1（自有单渠道保 P0）** —— 一键多渠道（抖音/微信/快手/TapTap）作为 P0 与渠道资质未启动的现实冲突 | 三向审计 §5「出」+ §3 Doc A 判定 | 不确定 | 现行 Doc A 里 P-PUB-01 **仍是 P0**（一键多渠道）。审计建议自有单渠道保 P0、外部多渠道降 P1，因为外部渠道受资质日历闸门阻塞、MVP 期不可能真做到。现行没采纳，可能导致 MVP 验收集里挂着一条注定做不完的 P0 | | -| 产品战略-019 | **P-TPL-01/03（玩法模板浏览/应用，P0）的产品形态未拍板** —— 玩法模板未废（是有效待建功能），但 P-TPL-01/03 当前形态是删除/降 P1/重定义为"示例 Prompt 库"/重定义为"灵感画廊"，须创始人定 | demo 审计 §八待拍板#1/#2/#3 | 遗落 | 现行《商业定位》§5 讲了"玩法模板未废、待建、非最高优先级"，但 **Doc A 里 P-TPL-01/03 仍是光秃秃的 P0、零状态注记**，且建草稿仍硬要 templateId（generic 桥接已暂解 limbo）。它直接污染 55 P0 验收契约——这两项当前到底以什么产品形态验收，是悬着的产品决策 | | -| 产品战略-020 | **P-CRT-02「六类资产模块化生成」的验收口径需澄清（一句话直出 vs 强制六模块逐一生成）** —— 现行主线是一句话直出+附件装配，不是用户在工作坊里逐类手工生成六资产 | demo 审计 §四 C4 + §七 | 遗落 | 现行 Doc A 里 P-CRT-02 **仍是光秃秃的 P0**，没标注"验收按 attachment 装配、非强制六模块逐一生成"。读 Doc A 的人会以为 MVP 要做一个能逐类生成六资产的工作坊，与现行"一句话直出"主线不符 | | -| 产品战略-021 | **六资产工作坊 + 角色骨骼 rig 编辑器范式：保留为远期产品方向还是放弃（未拍板）** —— demo 和 Doc A/B 仍承载该范式，与现行"agent 直出 + mmx 出静态素材"不在同一轨 | demo 审计 §八待拍板#4；§四 C4 | 遗落 | rig 三项（P-CRT-03/06/07）现行 Doc A 仍按 P1/P2 挂着、未标"远期/方向待定"。这是一整套产品范式（角色骨骼拆件、动作编辑、逐资产工作坊）的去留问题，现行决策从未显式裁过——是保留为 premium 远期方向还是彻底放弃，是个真实的产品方向决策 | | -| 产品战略-022 | **feed「最喜欢」星标是 demo 冗余第三态，建议确认删除** —— 语义独立于点赞(P-FED-03)/收藏(P-FED-04)，是 demo 多出来的第三种态 | demo 审计 §三 3.1 | 不确定 | 小但具体：现行 Doc A 没有"最喜欢"这一项（已隐含不收），但 demo 里还摆着。算是个已基本处理、留个尾巴的小项，确认一下即可 | | -| 产品战略-023 | **登录/注册作为产品功能在 Doc A 里没有 P-id** —— 账号体系是 P0 但 Doc A 里找不到对应的产品需求行 | 三向审计 §3 Doc A 判定 | 不确定 | 现行 Doc A 的 ACC 域有"账号信息/隐私政策/适龄提示/申诉"，但**登录/注册本身确实没有独立 P-id**（鉴权波已实现，可能视为基建不入产品清单）。是否要补一条产品需求行让清单自洽，值得确认 | | - ---- - -## 五、游戏品类与玩法设计（多为已收口，留一条架构裁决的演进线索） - -模板哲学（游戏模板填参式废除、玩法模板=品类框架未废待建）现行已沉淀。D2 模板集（idle/tycoon/merge/clicker）也已收口。这里主要留两条：一条是 D2 当时被否的动作类品类，一条是 tier2 富游戏轨与品类的关系。 - -| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-024 | **动作/技巧类品类（躲避/跑酷/射击/解谜）被定向降 P1** —— 创始人定调主打休闲/经营/放置（碎片化时间），动作类生成复杂度高、非碎片场景，明确降 P1 | MVP 业务决策 D2；三向审计 R4 | 过期/弃用 | 现行档讲了 MVP 模板集，但**没明确记"动作类品类被有意降 P1 及其理由（碎片化定位 + 留存经济学站在 idle/tycoon 一边）"**。这是一条品类战略选择，列出来避免日后有人提议"加个跑酷品类"时重新讨论一遍——它不是没想到，是被有意排在后面 | | -| 产品战略-025 | **"反同质化"是 feed 内容生态的生死指标，须可度量（相似度度量 + 上限告警）** —— 同一模板不同用户的成品在主题/美术/关卡/参数上要可见差异，建相似度度量并设上限告警 | 意图基线 GP4 / P3 | 遗落 | 这条在意图基线里被创始人冻结采纳，但**现行产品域/架构域没把"反同质化=feed 生死指标"作为一条产品约束沉淀**。如果生成出来千篇一律，再大的产能也喂不活 feed 内容生态——这是个该进战略/产品约束的判断，目前只躺在生成系统意图清单里 | | -| 产品战略-026 | **tier2 自治富游戏轨面向"价值更高、产量更低"的 premium 场景，与超休闲廉价线解耦并存** —— 对标《肥鹅美食街》类多系统富游戏，是第二条生成轨，不替换超休闲线 | `.agents/knowledge/glossary.md` tier2 词条；架构域生成引擎档 | 不确定 | tier2 在架构域和 glossary 里有，但**它对应的产品/商业定位（premium 品类、面向谁、怎么定价、和三线收入的关系）在产品域和运营域几乎没展开**。它现在是"待 0 号 spike 验证的假设"，但作为一条潜在的高价值产品线，其商业意图值得在产品战略里至少留个位置，而不只是当技术轨记着 | | - ---- - -## 六、用户角色与端到端流程（基本已收口，留增长侧的飞轮约束） - -用户角色权限模型（访客→玩家→创作者→专业创作者；运营→管理员；B 端）现行 `.agents/knowledge/product-and-architecture.md` 讲得清楚。端到端闭环也沉淀得好。这里留几条偏"增长飞轮机制"的产品想法，它们在意图基线里被冻结，但没进产品域。 - -| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-027 | **创作者梯度即订阅转化漏斗（免费体验 L1 → 订阅解锁 L2/L3）** —— 三级生成对应小白/进阶/专业三类人，复杂能力不打扰小白，梯度本身就是免费到付费的转化漏斗 | 意图基线 GP5 / P4；GP7「第一笔收益激活」 | 不确定 | 现行 Doc A 有会员订阅(P-PAY-02)、创作者等级(P-INC-02)，**但"生成分级=订阅转化漏斗"这个把产品分级和变现直接挂钩的商业机制设计没沉淀**。这是订阅收入线的核心产品逻辑（用生成级别做付费墙），值得在产品/变现战略里讲清 | | -| 产品战略-028 | **"创作者第一笔收益激活路径"应作为显式产品引导** —— 明确引导用户从"生成一个游戏"走到"发布并拿到第一笔广告收益"，把创作者留存从工具使用变成收益驱动 | 意图基线 GP7 / XP3 | 遗落 | 现行 Doc A 有新人任务(P-INC-01)，但**"第一笔收益激活"作为一条明确的创作者 onboarding/留存产品设计没沉淀**。这是把创作者从"试用一次就走"转成"为了收益留下"的关键产品钩子，是供给侧留存的核心 | | -| 产品战略-029 | **玩家→创作者 remix 飞轮（一键"改成我的版本"带溯源链）** —— feed 里每个爆款都允许"我也做一个类似的/换我的角色主题"，把玩家流量导回创作供给 | 意图基线 GP10 / P9 / XP6 | 遗落 | 与产品战略-015（P-FED-12 升 P0）同源但更完整：现行档没把"remix=网络效应核心飞轮"这个机制讲透（带溯源链、玩与造互转）。这是绘境区别于纯工具竞品的网络效应来源，值得作为一条产品战略机制沉淀，而不只是 Doc A 里一条 P1 功能 | | -| 产品战略-030 | **可运营的主题活动机制（节日主题/题材挑战/模板赛道榜单/收益榜）** —— 支持活动运营能力，放大内容生产与玩家参与、服务流量闭环与广告库存增长 | 意图基线 GP13 / XP7 | 遗落 | 现行 Doc A 的 GRW 域有"创作挑战赛"(P-GRW-02)、"创作大赛"(P-INC-05)，**但"可运营的主题活动机制作为放大内容供给和广告库存的增长引擎"这个战略意图没沉淀**。活动运营是冷启动后期放大飞轮的关键手段，目前散在意图清单里 | | -| 产品战略-031 | **6 个 CEO 周看指标（生成可接受率/单局加载成功率/玩家完玩+次留/每款事件量/外部闸门状态/首个收入或付费意向）** —— "6 个月不后悔"的判据不是"模块能启动"，是"有人要用+能合规上线+能采数据+能产生收入" | 下一阶段路线 plan §5 | 遗落 | 这套 CEO 级北极星指标在历史计划里定过，**现行档（含运营域看板）没有一个统一的"创始人每周只看这 6 个"的指标集**。它是把产品战略翻译成可周度跟踪的判据，对保持方向不跑偏很有用，值得沉淀为一份活的指标卡 | | - ---- - -## 七、对外叙事与诚信红线（已大量沉淀，留团队/融资口径的待收敛项） - -护城河话术双版本现行已沉淀得很好（诚实纪律、四条改口、自研边界）。这里留一条对外叙事层面、明确标着"待创始人定一个对外单值"的悬置项。 - -| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-032 | **唯一融资口径与团队口径待收敛（曾有三版互斥融资额 + 团队表述自相矛盾）** —— BP 改造版/生态引擎BP/路演稿三版融资额互斥（200-1000万 / 3000-5000万 / 3000万15%）；团队"全职5人"与三创始人"现任他司"矛盾 | 三向审计 R1；战略与合规 §6(B)「残留 3★」 | 不确定 | 这属于对外叙事，审计明确说"须创始人定一个对外单值"。现行《护城河话术》给了诚实口径模板，**但"对外融资额/团队表述到底锁哪个单值"这个待拍板项是否已闭合，从现行档看不出**。属对外材料一致性，建议确认是否已定 | | - ---- - -> **一句话给主代理**：这份清单 32 条里，最该优先看的是第四组"需求与 P0 范围"——两次审计开出的具体口径调整（P-FED-12/P-OPS-01 升 P0、P-PUB-01 降 P1、P-TPL-01/03 与 P-CRT-02 的形态/验收注记、30/40 分层工作集）大多没落进现行 Doc A，是积压最久、最可执行的一批；其次是第一组的竞争顾虑（feed 现任者没进产品域、竞品数字未核、上游平台风险无风险章）和第六组的增长飞轮机制（remix/第一笔收益激活/活动运营/CEO 周看指标）这些被冻结却没沉淀的好想法。 diff --git a/docs/architecture/_recall/产品战略-第二轮.md b/docs/architecture/_recall/产品战略-第二轮.md deleted file mode 100644 index 964e1c71..00000000 --- a/docs/architecture/_recall/产品战略-第二轮.md +++ /dev/null @@ -1,55 +0,0 @@ -# 产品战略 · 历史设计点回收 第二轮(复核 + 查漏) - -> **这份是什么**:对第一轮《产品战略-历史设计点.md》的复核加查漏。第一轮把产品战略这一摊的历史遗落点穷尽挖了一遍(32 条);这一轮做三件事——抽验它的出处准不准、判得对不对;把第一轮之后才落地的一批新设计稿拿来逐条比对,看哪些原标"遗落/不确定"的现在已经被新档接住了;再扫一遍历史源,补第一轮漏的、特别是卡在两个域交界处的设计点。 -> -> **第一轮之后新落地、这一轮拿来比对的新档**:架构域生成引擎子树的《数据飞轮》(溯源链 + 同款创作 + 资产市场 + 收益回流)、《自治富游戏引擎》与《tier2 实现详设》;运营域的《审核台运营》;运维域的《观测体系》《k8s 迁移》;以及《商业定位》《护城河话术》在 2026-06-21 的回填。 -> -> **结论先说**:第一轮整体扎实,出处抽验全部对得上,没有编造或张冠李戴。需要改判的只有 4 条——其中 3 条是被新档接住了(平台吞并风险、同款飞轮、remix 飞轮),1 条是分类口径要往"已部分覆盖"挪(tier2 商业定位)。被新档覆盖的第一轮条目共 5 条(含上面 3 条改判 + 2 条收益侧)。查漏补出 4 条新的,最值钱的一条是**种子内容/种子创作者的冷启动供给**——第一轮挖了"玩家从哪来",却漏了"开张那天 feed 里摆什么、谁来做头几款",这是创始人最不可替代的冷启动工作,现行档一字没有。 - ---- - -## 一、复核勘误表(改判的条目) - -先讲复核的总账:第一轮 32 条,出处抽验了竞争顾虑组(001/002/004)、需求范围组(014-023)、增长飞轮组(025/029/031)这几条最吃证据的,逐一 git grep 回原档核对,**出处全部属实**。融资数字"近 1 亿 vs 超千万"、feed 现任者"摸摸鱼/233乐园/4399"、上游平台风险"抖音/微信自上 IP 授权+一键生成"——原文都在三向审计和护城河复盘里一字不差地找得到。分类口径上,绝大多数判得准:凡是审计开给 Doc A 的口径调整(P-FED-12 升 P0、P-OPS-01 升 P0-lite、P-PUB-01 降 P1、P-TPL/P-CRT 形态注记),我核了现行 Doc A,**优先级一个都没改**(P-FED-12 仍 P1、P-OPS-01 仍 P1、P-PUB-01 仍 P0、P-TPL-01/03 仍 P0、P-CRT-02 仍光秃秃 P0),所以第一轮把它们判"遗落/不确定"是对的,不动。 - -真正要改判的是下面 4 条。前 3 条不是第一轮判错了,是**第一轮成稿之后(同在 2026-06-21)创始人拍了边界、设计稿才落地**,时间差导致的;第 4 条是分类口径的细调。 - -| ID | 原判 | 新判 | 为什么 | -|---|---|---|---| -| 产品战略-004 平台吞并风险 | 遗落 | **过期/已解(被新档覆盖)** | 第一轮说"现行档完全没有风险章"。但《商业定位》§3 现在有了一整段「平台方下场的风险与应对(创始人 2026-06-21 定调)」,把"微信/抖音自上 IP 授权+一句话生成"这个风险正面摆出来,应对指向 tier2 自治富游戏引擎 + 对话式创作。第一轮挖它的诉求(战略叙事要有风险章)已被满足,从遗落改为已解。 | -| 产品战略-015 P-FED-12 升 P0 | 遗落 | **不确定(设计接缝已补,升 P0 仍悬)** | 第一轮说"P-FED-12 仍 P1、审计建议升 P0 没落地"。《数据飞轮》§3.1 现在把同款创作的溯源链设计、血缘表、漏斗埋点全设计到位了,但它明确写"本稿只做设计接缝、不替代优先级裁定,升 P0 要走 RTM 同步改 Doc A、挂开放问题#6"。所以**设计层面已接住,优先级裁定仍未闭合**——不能算纯遗落了,改判不确定,等创始人在数据飞轮开放问题里拍升 P0。 | -| 产品战略-029 remix 飞轮 | 遗落 | **过期/已解(被新档覆盖)** | 第一轮说"现行档没把 remix=网络效应核心飞轮讲透(带溯源链、玩与造互转)"。《数据飞轮》整篇就是这条飞轮的正式设计:溯源链记血缘(parent/origin/depth)、试玩页展示"改编自 XX"、玩家流量导回创作侧的机制和防滥用全讲透了。第一轮的诉求已被一份完整设计稿满足,改为已解。(注:它和 015 同源——015 是"那一条 Doc A 功能行的优先级",029 是"那套飞轮机制",机制已落、优先级仍悬,所以 015 留不确定、029 转已解。) | -| 产品战略-026 tier2 富游戏轨商业定位 | 不确定 | **不确定(下调为"已部分覆盖")** | 第一轮说"tier2 的产品/商业定位在产品域几乎没展开"。这判断现在偏重了:《自治富游戏引擎》已写明 tier2"面向价值更高、产量更低的 premium 场景,与超休闲廉价线解耦并存";《tier2 实现详设》给了定价档(premium 取 L2 偏下、¥3/款假设);《商业定位》§3 也把 tier2 写进了平台吞并风险的应对。**"是什么、什么档位、怎么定价"已覆盖**,仍缺的只是"面向哪类客户、和三线收入哪条挂钩"这一层 go-to-market。仍判不确定,但缺口已从"几乎没展开"收窄到"商业化客群与收入归属待补",请创始人按这个更小的缺口议。 | - -第一轮其余 28 条复核后维持原判,不在此重列(那是噪音)。 - ---- - -## 二、已被新档覆盖的第一轮条目 - -这一节单独把"第一轮标遗落/不确定、现在被新落地的设计稿接住"的条目集中列出来,方便创始人一眼看清哪些账已经还上了。上一节改判的 004/029 也属于这一类(被覆盖),这里连同另两条收益侧的一起登记,给出被哪份新档覆盖。 - -| ID | 第一轮原判 | 被哪份新档覆盖 | 覆盖到什么程度 | -|---|---|---|---| -| 产品战略-004 上游平台吞并风险 | 遗落 | 《商业定位》§3「平台方下场的风险与应对」 | **全覆盖**。风险正面摆出 + 应对(tier2 引擎深度 + 创作深度)。 | -| 产品战略-029 remix 玩家→创作者飞轮 | 遗落 | 《数据飞轮》全篇(尤其 §3.1 溯源链 + 漏斗埋点) | **全覆盖**。血缘网络、防滥用、溯源展示、remix_click/submit 埋点都设计到位。 | -| 产品战略-015 P-FED-12 同款创作升 P0 | 遗落 | 《数据飞轮》§3.1 + 开放问题#6 | **设计覆盖、裁定未覆盖**。接缝全设计好,但升 P0 这个优先级动作明确挂回开放问题待创始人拍。 | -| 产品战略-012 每游戏粒度单位经济测量 | 不确定 | 《数据飞轮》§3.3 收益回流 + 《变现与单位经济》§6 W4 | **前置补齐已设计、战略优先级仍未抬**。收益回流把"收益→game_id 透传四步链"和"留存口径定义"作为前置写明了,和变现档 W4 是同一件事的两面;但第一轮真正想问的"要不要把'先测准单位经济再谈规模'抬成战略级优先级"仍没人拍,故仍留不确定。 | -| 产品战略-025 反同质化=feed 生死指标 | 遗落 | 《验收门-W-G1》《SAA 编排》的生成多样性门(部分) | **部分覆盖(在生成门一侧)**。反同质化作为一道**生成验收门**(多样性/相似度)在 W-G1 里有了着落;但第一轮挖的是它作为一条**feed 内容生态产品约束**(相似度度量 + 上限告警喂给 feed)的那一面,这一面仍没沉淀。所以它半边落了地——生成门拦得住单次同质,feed 侧的生态级度量仍缺。建议第一轮此条状态由"遗落"细化为"生成门已覆盖、feed 产品约束侧仍遗落"。 | - -> 一句话:**护城河四层里"网络效应"这一层(remix 飞轮 + 溯源链)的工程落点,被《数据飞轮》一份稿基本补齐了**,这是第一轮第二组(护城河)和第六组(增长飞轮)里最大的一块欠账被还上。剩下没还的主要是"数据"层的战略优先级(012)和 feed 生态度量(025 的另一半)。 - ---- - -## 三、查漏补充清单(第二轮新挖) - -第一轮的扫法偏"审计已开出的口径调整"和"意图基线里被冻结的飞轮机制",挖得很全。这一轮我顺着**冷启动执行**和**Doc A 自洽性**这两条第一轮带过的线,以及两份计划档(HJ-PLAN-005 下一阶段路线、HJ-DEC-001 业务决策)里偏"执行供给"的内容,补出下面 4 条。判据同第一轮:遗落=历史认真讨论过、有价值、现行没沉淀也没明确弃;不确定=拿不准现行覆盖没。现行已覆盖的(如打赏/积分体系——已在 P-PAY-08 和《变现端到端》§2.5 沉淀;社交关注/评论——已在 P-SOC-01..11 沉淀)一律不补。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 产品战略-033 | **冷启动内容供给:开张要有 10 款种子游戏 + 首批 10 个 demo 题材** —— feed 不能空着开张,飞轮转起来的前提是先有一批种子内容垫底,否则玩家进来看见空流、行为数据无从采起 | 下一阶段路线 plan §2.D「10 款种子游戏清单」+ §2.A「定首批 10 个 demo 题材」 | 遗落 | 这是第一轮 010(玩家获客通路)的供给侧镜像,也是它漏掉的另一半。第一轮问了"玩家从哪来",没问"玩家进来看见什么"。计划档把"建 10 款种子游戏清单(模板/封面/试玩目标/埋点/审核状态)"列为飞轮启动的硬前置(Codex 标 high:无种子供给则 feed 空、飞轮启动不了),现行产品域/运营域完全没有这条冷启动供给的产品约束。它不是工程量,是开张前必须备好的内容底盘。 | | -| 产品战略-034 | **种子创作者 BD 是创始人不可替代的冷启动轨,且需可复制的获取打法** —— 约 5 个种子创作者 + 1 个分发/IP 冷启动入口,是创始人本人(非 AI、非工程)要亲自做的冷启动第一步 | 下一阶段路线 plan §2.A 外部闸门轨;呼应护城河复盘 §6 议题②「IP 靠人脉=不可规模化」 | 遗落 | 第一轮 007 讲的是"王蓝莓 IP 靠人脉拿、关键人风险",是单点 IP 视角;这一条是更上位的——计划档把"种子创作者 + 种子分发入口"定为**创始人本人的独立执行轨 A**(机会成本最高、只有创始人能做)。供给侧冷启动(头几个创作者怎么招来、怎么留住第一批)作为一条产品/增长策略,现行档没有家。它和 010(玩家获客)、033(种子内容)合起来才是完整的冷启动三件套——需求侧、内容侧、创作者侧,现行都缺。 | | -| 产品战略-035 | **Doc A 几处入口/标签缺独立 P-id,清单不自洽** —— 智能体对话流的"代码目录"标签、创作模式"自定义/授权 IP"双标签切换入口,都是 demo 里真实存在的产品面,但 Doc A 里没有对应的产品需求行 | demo 审计 §三 3.1「智能体对话流三标签」「创作模式双标签切换」(均标 partial/表述缺口) | 不确定 | 这是第一轮 023(登录/注册无 P-id)同类的 Doc A 自洽性缺口,但 023 只挖了登录这一处,漏了这两处。demo 审计明确标它们是"表述缺口"——功能本体可能被别的 P-id 覆盖(对话流本体=P-CRT-05),但这两个**入口/切换面**本身没独立 P-id,读 Doc A 的人对不上 demo。判不确定是因为这取决于创始人对"Doc A 要不要把每个入口都列成行"的口径——和第一轮前端清单 43 条不确定是同一类边界问题,定一次口径可一并清掉(含 023)。 | | -| 产品战略-036 | **6 个月不后悔的判据 = "有人要用 + 能合规上线 + 能采数据 + 能产生收入",不是"模块能启动"** —— 这是把产品战略翻译成验收哲学的一句话总纲,统摄 031 那 6 个 CEO 周看指标 | 下一阶段路线 plan §5 + 同处 Decision Log | 遗落 | 第一轮 031 挖了"6 个 CEO 周看指标"(已确认现行运营档/看板里没有,只躺在归档的作战清单史里),但漏了它上面那句更根本的**验收哲学**:判断这半年没白干,看的不是结构骨架建了多少,是"有人要用+能合规+能采数据+能赚钱"四件事成立没。这句话其实是整个产品战略的北极星定义,比 6 个指标更上位,而且和创始人反复强调的"结构骨架≠真实可验收""产品视角非技术视角"一脉相承。它和 031 应作为一组(总纲 + 指标卡)一起沉淀进战略档或运营看板。 | | - -> **给创始人的一句话**:这一轮最该看的是 **033 + 034——冷启动供给那一对**。第一轮把"飞轮转起来之后怎么放大"(remix、活动运营、第一笔收益)挖得很全,这些现在也大多被《数据飞轮》接住了;但"飞轮怎么从零启动那一下"——开张摆什么内容、头几个创作者谁来招——第一轮和现行档都漏了,而这恰恰是创始人本人最不可替代、也最容易因为"它不是工程任务"而在文档里失踪的一块。其次是 036,它和已挖的 031 是一组,补上就让"这半年算不算没白干"有了一句能挂在墙上的判据。 diff --git a/docs/architecture/_recall/前端-历史设计点.md b/docs/architecture/_recall/前端-历史设计点.md deleted file mode 100644 index 633fc457..00000000 --- a/docs/architecture/_recall/前端-历史设计点.md +++ /dev/null @@ -1,150 +0,0 @@ -# 前端域 · 历史设计点回收清单 - -> **这份清单是什么。** 这是一次穷尽式的历史回收:把"前端"这个领域里,历史文档(留痕层、归档层、早期快照、旧版长设计文档)讨论过、但**现行设计文档没有沉淀下来**的设计点、想法、顾虑、约束,逐条挖出来摆在一起。目的只有一个——不让历史上认真讨论过的好想法、好顾虑被时间冲走,避免现行架构在演进中漏掉了当初本该考虑的约束。它不是新的设计决策,每一条的"判定"列都留空,等创始人过目后裁定:捡回、确认放弃、还是另作安排。 -> -> **"现行(已沉淀,不算遗落)"的判断基准。** 我把下面这些当作"读了就等于当前真相"的现行档,逐一读过:`docs/architecture/前端/README.md`(前端域设计主文档,设计体系的现行 SoT)、`.agents/skills/runtime-and-multichannel.md`(运行时/SDK/多渠道手册)、`.agents/skills/ui-walkthrough-cdp.md`(真 UI 走查配方)、`.agents/rules/security-and-reliability.md`(SDK 降级铁律与沙箱红线)、`.agents/rules/engineering-conventions.md`、以及 `.agents/rules/ui-uniform-rounded-rectangles.md`(注:这份圆角规则文件实测是空文件,真正的圆角铁律内容写在前端 README §5.5,这点本身是个小漂移,但不在本次回收范围)。凡是这些档已经讲清楚的,我不列(那是噪音)。 -> -> **我扫过哪些历史文档。** 留痕与归档层:`docs/agent-specs/_archive/` 下的 `2026-06-08-前端game-studio建设-review.md`(前端脊柱建设评审,HJ-FE-SPINE-001)、`2026-06-11-community-biz前端入口-review.md`(community/biz 前端入口评审,HJ-FE-CMBIZ-001,极厚)、`2026-06-11-Tier1运行时重设计-review.md`(Tier1 重设计,好玩基线)、`2026-06-13-P2-runner-v2泛化宿主-review.md`(通用宿主泛化)、`2026-06-16-studio视觉体系-i18n-组件库-execution.md`(设计体系执行版)、`2026-06-16-视觉增强repair-review.md`(已否决)、`2026-06-17-demo与三文档套件缺口冲突审计-review.md`(HJ-DEMO-AUDIT-001,demo 实然审计);`docs/agent-specs/` 下的 `2026-06-17-生成主线-对话生成修改素材-review.md`(对话式创作 UX)、`2026-06-11-前端接线创作链路UI走查/report.md`(UI 走查收口)、`docs/agent-specs/2026-06-12-channel-spike/`(渠道引擎对比)。早期快照:`docs/memorys/` 下的护城河复盘、三文档迁移、prefix-cache。旧版长设计文档:`docs/architecture/_archive/系统概要设计-技术决策版.md`(最厚的历史前端来源,SDK/插件/玩家流/创作工作台/三容器全在这里)、`系统概要设计-开发团队版.md`(历史意图中的 studio 目录结构)、`技术架构与模块.md`。 -> -> **怎么读这份清单。** 条目多,按子主题分了九张表(A 设计体系 / B 游戏流 feed 体验 / C 创作流程 UX / D 真实试玩宿主 / E SDK 与插件前端 / F 移动端适配与响应式 / G community·biz·social 前端入口 / H admin 前端 / I 性能与体验 SLO)。每条三种状态:**遗落**=历史讨论过、有价值、却没进现行档,也没被明确放弃(这是重点);**过期/弃用**=讨论过但已被明确取代或决定不做(列出来是为了让你知道它被考虑过、为什么弃,免得日后重复讨论);**不确定**=拿不准现行档到底覆盖没有(常见于"后端已沉淀、前端承载未沉淀"的情形)。 - ---- - -## A. 设计体系(token / i18n / 组件 / 主题 / 圆角 / 字体 / 图标) - -> 设计体系这一层现行 README 讲得相当透(token 两层、组件库四层、三主题、圆角铁律、i18n 契约、self-host 字体)。这里只捞它**没讲、但历史认真定过或顾虑过**的点。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-A01 | 跟随系统深浅色(`prefers-color-scheme`)做主题初值 | 设计体系 execution 版 §4.1「初值跟随 prefers-color-scheme」;归档 canonical 决议 2 也这么写 | 不确定 | 现行 README §5.2 把它降级为"远期增强,当前尚未接入,无持久化值时一律回落暗色",但 execution 版当初是把它写进决议 2 的实现口径的。这是"现行说远期、历史说要做"的口径分叉——值得明确:到底是确认远期,还是历史这条要捡回成首版默认。 | | -| 前端-A02 | 护眼主题 / 高对比主题作为后续增量档 | 前端 README §8 遗留段、execution 版 §0「out:护眼/高对比主题」 | 过期/弃用 | README 已把"护眼/高对比主题"明确列入"明确不做(留作后续增量)"。列出来只为留痕:三档(暗/浅/柔)之外曾计划过护眼与高对比,是无障碍/适老化的抓手,后续真要做时别当新需求从零想。 | | -| 前端-A03 | RTL(从右到左)书写支持,服务阿拉伯语等 | 前端 README §8 遗留段「明确不做:RTL」 | 过期/弃用 | 已明确不做。留痕:出海到中东语种时这是硬约束,token/组件层若提前留逻辑属性(margin-inline 等)成本低,真做时回看。 | | -| 前端-A04 | 组件库 component 层(组件级令牌)作为 token 第三层 | 前端 README §4.1「组件层是按需追加的第三层」、token 两层图里画了 CT 节点 | 不确定 | token 两层(primitive→semantic)是现行明确的,但组件级令牌这第三层只是"按需追加",没有任何一条说它何时追加、追加哪些。属于画了格子但没说怎么用——值得确认是有意留白还是该补一句使用边界。 | | -| 前端-A05 | admin(game-admin)只在品牌色一层与 studio 对齐,其余沿用 Element Plus 默认 | 前端 README §1 范围说明 | 不确定 | 现行只说了"admin 沿用 Element Plus 默认体系即可,只在品牌色对齐"。但"品牌色对齐"具体怎么落(admin 有没有引同一份 token?青绿渐变进不进 admin?)没有任何承载说明。admin 的设计体系归属是"钉了一句话、没有落点"——典型的孤儿,值得明确。 | | - ---- - -## B. 游戏流 feed 的体验与交互 - -> feed 是消费侧第一体验,但现行前端 README 对 feed 的**交互手势、容器策略、互动动作集**几乎没有正面描述(只说"竖屏滑动")。下面这些历史上定得很细的交互设计点,现行前端档没有沉淀。其中部分可能落在架构域生成引擎子树(运行时容器),故多标"不确定"。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-B01 | 上滑切换下一款 = 销毁当前容器 + 激活预加载容器(抖音式手势) | 技术决策版 §玩家流时序「上滑切换下一款 / 销毁当前容器 + 激活预加载容器」 | 不确定 | feed 的核心交互手势(上滑切下一款)和容器生命周期(滑走即销毁、激活预加载好的下一个)是产品第一观感的命门,但现行前端 README 对此只字未提,只说"竖屏滑动"。运行时的"三容器只预取不实例化"在 Tier1 约束里讲过,但**前端的滑动手势承载和切换动画**没有归宿。值得明确这块归前端域还是架构域,别让它悬空。 | | -| 前端-B02 | 三容器预加载策略:销毁中 / 当前播放 / 预加载完成三态脚手架 | 技术决策版 §游戏流首屏「三容器策略(参考抖音短视频预加载)」;Tier1 约束 R9「三容器 N±1 只预取字节不实例化」 | 不确定 | 后端/运行时侧的"N±1 只预取不实例化"已在 Tier1 约束沉淀,但**前端 feed 列表如何维护这三态容器、何时触发上/下预取、滚动方向预测**是前端实现问题,现行前端档无承载。建议确认前端域是否该补一节 feed 容器调度。 | | -| 前端-B03 | feed 卡片 + 预加载下一款 manifest(随 feed 清单下发,省一次 RTT) | 技术决策版 §玩家流「展示封面卡片 + 预加载下一款 manifest」;Tier1 约束 R10/E2「manifest 随 feed 下发」 | 不确定 | manifest 随 feed 清单先行下发(让首帧主题底色/标题在 <300ms 绘出)是体感关键。这条在 Tier1 约束(架构域)里有,但前端 feed 卡片的"先用 manifest 画首帧再加载游戏"这套首帧保障 UX,前端档没讲。 | | -| 前端-B04 | feed 互动动作完整集:点赞 / 收藏 / 分享 / 举报 / 评论 / 关注 | 技术决策版 §权限表「玩家:+点赞/收藏/分享/举报/评论」;开发团队版 互动(点赞/收藏/分享/举报) | 不确定 | 现行前端 README 的"反向超出"清单只点了分享落地页,**举报入口、评论 UI、关注**这三个互动动作在前端 feed 的承载从未在现行前端档出现。后端 community/social 有相应能力,但前端的举报入口、评论展开、关注按钮属于 feed 交互设计,值得确认是否遗落。 | | -| 前端-B05 | "最喜欢"星标 = demo 的冗余第三态,建议确认删除 | demo 审计 §3.1「feed『最喜欢』星标(★7689),语义独立于点赞/收藏,demo 冗余第三态,建议删」 | 不确定 | demo 里 feed 有"最喜欢"星标(独立于点赞和收藏的第三种态),审计判它是 demo 的冗余设计、建议删。现行前端档没记这个判定。留着是为了:若有人照 demo 复刻,会把这个冗余第三态也搬进来——需要一句明确的"不做"。 | | -| 前端-B06 | feed 同款创作入口(从 feed 卡片直接发起"做一个同款") | demo 审计 §二 feed 视图「同款创作」;feed-stream 设计 | 不确定 | demo 的 feed 卡片带"同款创作"动作(看到一款游戏直接发起做同类)。这是把消费侧流量导回创作侧的关键产品钩子,现行前端档无承载。值得确认是 descope 还是遗落。 | | -| 前端-B07 | 访客(未登录)可浏览试玩,登录后才解锁互动/收藏/举报 | 技术决策版 §角色「访客(可浏览试玩)→玩家(+互动/收藏/举报)」;鉴权波"互动即弹登录" | 不确定 | 访客先玩、互动时才弹登录(anonId 衔接)这套渐进式准入,鉴权波已实现"互动即弹登录"模式(community-biz 评审 §4.1 引 Feed.vue:151)。但前端 README 的"反向超出"只点了登录注册整屏,没把"访客可玩 / 互动门槛"这条渐进准入策略写进设计体系。属于实现里有、设计档没沉淀。 | | - ---- - -## C. 创作流程 UX - -> 这是本次回收**信息量最大、也最该看**的一块。现行前端 README §7 把"工作坊 IDE 化 / 智能体对话 / 六类资产台 / 编辑态调参"整体列为"有意 MVP descope",但与此同时,后端的对话式生成/差量修改/六类素材契约**已经在架构域生成引擎子树沉淀、studio 三路由已建**。也就是说:这套创作 UX 的后端已是现行真相,而前端承载在前端档里仍标着 descope——这是最大的口径分叉,逐条列清。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-C01 | 对话式生成/修改的前端创作页(对话框 + 多轮交互) | 对话生成修改素材 review §3.1「U:用户(studio前端)发 analyze/generate/modify」、§5「前端创作页(对话/上传/确认 UI)」 | 不确定 | 后端 `/studio/analyze`、`/studio/modify` 端点和 SAA modify 节点已是现行真相(固定游戏架构.md / SAA编排.md 都有),studio 三路由 `/studio/{create,modify,extend}` 也已建。但**前端的"对话式"创作交互(从一句话单步,升级为对话框多轮)**在前端 README 里仍归"工作坊 IDE 化 descope"。后端已经走到对话式了,前端设计档却还停在"一句话+选模板→整包生成"——这个分叉必须由创始人定:前端创作 UX 现在是什么形态。 | | -| 前端-C02 | 六类素材上传 UI(图元/角色/特效/场景/界面/音乐)驱动生成 | 对话生成修改素材 review D1 assetContext「六类素材透传生成,触及前端」;开发团队版 AssetWorkspace.vue | 不确定 | `assetContext` 六类素材契约是现行(additive 字段已定),但**前端的六类素材上传/选择/拖入作上下文的 UI**没有任何前端档承载。开发团队版历史里有 `AssetWorkspace.vue`(资产空间)的规划。后端已经能吃六类素材,前端怎么让用户传,空白。 | | -| 前端-C03 | 智能确认卡 UI(系统分析输入→模糊时弹目标确认卡,清晰则直通) | 对话生成修改素材 review §3.1「展确认卡(目标摘要),用户确认/微调」 | 不确定 | "系统分析→智能确认目标→生成"这套交互的后端(analyze 返 needsConfirm + clarifyQuestions)是现行,但**前端的确认卡组件(展示解析出的目标摘要、让用户确认或微调)**前端档无承载。这是对话式创作体验的关键一环,遗落。 | | -| 前端-C04 | 差量修改的前端入口与差异展示("换美术/改第2关",只改一处不毁全局) | 对话生成修改素材 review D3「差量局部修改」、§6「对已生成游戏发『换美术』/『改第2关』」 | 不确定 | 差量局部修改是创始人拍的核心创作能力(固定游戏架构.md 契约⑥ modifyPatch 已沉淀后端),但**前端如何让用户发起"改这一处"、如何展示"改了哪、其余没动"**,前端档无任何设计。后端可寻址了,前端的修改入口和差异可视化是空的。 | | -| 前端-C05 | 三种创作模式分层(一句话 / 资产驱动 / 全自定义编排)覆盖小白到专业 | 技术决策版 §创作工作台「三种创作模式」;开发团队版 GameDesigner.vue | 过期/弃用 | 历史定的三模式:一句话(小白)、资产驱动(进阶)、全自定义可视化编排(专业)。技术决策版已自行把"全自定义编排"标为"远期能力,MVP 暂不提供,现行专业路径=按需调 SAA 裸 StateGraph"。前端 README §7 也把"工作坊 IDE 化"descope。列出来是留痕:资产驱动这一档(C01/C02 正在以"对话+素材"形态回归)其实是三模式的中间档,别当全新概念。 | | -| 前端-C06 | 失败/取消/重试闭环:七种生成失败原因的可读中文映射 + 可取消可重试 + 进度色 | 前端 README §7.1 反向超出「失败/取消/重试闭环」(已沉淀);UI 走查 report 链路①实证 | 不确定(部分已沉淀) | "七枚举失败原因可读映射 + 取消重试 + 进度色"现行 README §7.1 作为"反向超出"已沉淀。但 D6 新增的失败枚举 `nine_gate_failed`(对话生成修改素材 review,修 worker 回调被拒被误判 timeout 的 bug)是否已进前端的失败原因映射表,不确定——值得核一遍前端的失败文案表是否跟上了后端枚举的新增。 | | -| 前端-C07 | 生成成功必须回写 project.currentVersionId(否则发布门禁恒失败) | UI 走查 report Bug A;已修(commit 29564c8) | 过期/弃用(已修) | 这是 UI 走查逮到的真实后端缺陷(生成成功只写版本表、没回写 project.currentVersionId,导致真人 UI 发布门禁⑤恒失败,而编排器旁路掩盖了它),已修。留痕是因为它揭示一条仍然成立的设计纪律:**编排器/批跑全绿 ≠ 真人 UI 能用,前端读的字段必须在生成链路真的被回写**。这条纪律已进 ui-walkthrough-cdp 技能,此处仅指针。 | | -| 前端-C08 | 创作者数据后台落地须反向定义回读 API + 把诊断接到生成侧,避免孤儿数据 | 前端 README §7.2 descope「创作者数据后台」;demo 审计 creator 中心 partial-stub | 不确定 | README 已把"创作者数据后台"标 descope,但同时点了一条约束"落地须反向定义出回读 API + 把诊断接到生成侧,避免没有入口的孤儿数据"。demo 审计也证实 creator 中心当前是 partial-stub(AI 内容诊断无后端、趋势诚实占位)。这条约束(诊断接生成侧)是个好顾虑,真做创作者后台时要遵守,值得确认它有没有被记牢。 | | - ---- - -## D. 真实试玩宿主 / 运行时前端 - -> 试玩宿主是护城河命门,现行前端 README §7.1 把它作为"反向超出"沉淀了(iframe 沙箱 + SDK/Runtime 注入 + postMessage 双校验 + manifest sha256)。但 P2 通用宿主评审里有一批**宿主前端的工程硬点和顾虑**,现行前端档没有讲到(多数是架构域 host 层,标不确定);另有 tier2 双产物承载现行档已点归属、未设计。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-D01 | 引擎冷启动逼近 5s game_loaded 超时,首屏 P75<3s 受压 | P2 宿主 review §5.2 风险「引擎冷启动 4.8~5.3×,异步 bundle 加载可能逼近 GamePlayer 5s 超时」 | 不确定 | 换真引擎后,iframe 内引擎 bundle 异步加载的冷启动时间逼近宿主侧 5s `game_loaded` 超时阈值,首屏 P75<3s 承诺受压。这是宿主前端(GamePlayer.vue)的真实工程顾虑,缓解靠 HTTP 强缓存跨游戏复用引擎 + 必要时放宽超时阈值。前端档无承载,值得确认归属(GamePlayer 在 game-studio 仓,偏前端域)。 | | -| 前端-D02 | GamePlayer boot 需从同步内联改为异步(外部 bundle 走 script onload) | P2 宿主 review §3.2「外部 bundle 走异步 script onload,boot() 重构为异步」 | 不确定 | 旧的 srcdoc + toString 内联是同步 boot,换 bundle 后 boot 必须异步化,且要和 5s 超时对齐。这是宿主前端的具体改造点,前端档无承载。 | | -| 前端-D03 | demo 兜底路径在取包失败时永久白屏"重构中",需决定是否给最小引擎样例 | P2 宿主 review O-P2-5「buildDemoPackage 取包失败注入,喂掏空壳=永久白屏重构中」 | 不确定 | 取包失败时前端注入 demo 兜底包,而 demo 兜底喂的是已停用的掏空壳→用户看到永久白屏"模板体系升级中"。这正是 ui-walkthrough-cdp 血泪坑(创始人经 IP 访问看到"加载失败")的根源之一。建议=保留 demo 走兜底但清晰降级,门禁断言"兜底触发即 fail"防假阳性。这条失败态 UX 顾虑前端档没沉淀。 | | -| 前端-D04 | 走查环境 localhost = 安全上下文,会系统性掩盖上下文依赖缺陷(crypto.subtle 等) | ui-walkthrough-cdp §1 红线(已沉淀于技能);UI 走查血泪 | 不确定(已沉淀于技能) | 这条已在 ui-walkthrough-cdp 技能里作为红线沉淀(localhost 安全上下文会掩盖 `crypto.subtle`/`isSecureContext` 门控特性缺陷,真实用户经 IP 明文 http 访问会撞上)。已补纯 JS SHA-256 兜底。此处仅指针,确认前端档是否需要也引一句"用户可见 UI 必须另跑一遍真实 origin"。 | | -| 前端-D05 | tier2 富游戏前端承载:feed 同时装载两种产物(LittleJS 单包 + Phaser 多文件工程) | 前端 README §8 tier2 段「feed 承载两种产物的装载分发 + studio 第二轨入口」(已点归属) | 不确定(已点归属未设计) | 现行 README §8 已经把这件事钉了归属(feed 运行时容器 + 创作端第二轨入口归前端域),但明说"等 tier2 临近过 0 号 spike 再展开,现在只钉归属、不预先设计"。列在这里是提醒:这是一个**已知待建、有意推迟**的前端设计点,不是遗落——但等 tier2 spike 一过,前端域要立刻补这两件的设计,别让它停在"只钉归属"。 | | -| 前端-D06 | QA 取证几何契约:Runner 按模板暴露只读"取证几何清单"供 player 驱动真实输入 | Tier1 重设计 review D5「隐性公式 parity → 显式只读布局契约」 | 不确定 | 历史定的:试玩宿主/Runner 要按模板暴露一份只读的确定性布局/坐标几何清单,让自动化走查(player_cdp)按清单驱动真实输入事件,而不是靠人肉逐字符对齐坐标公式。这是 e2e 走查能稳定的前端/宿主接口设计,现行档(含 game-e2e-cdp-harness 技能)是否完整承载这条"显式几何契约",不确定,值得核。 | | - ---- - -## E. SDK 与插件前端(WanxiangGameSDK) - -> SDK 的主体设计(Core/Plugin 分层、广告支付在宿主侧 iframe 外渲染、懒加载首屏<8KB、降级铁律、5s 加载超时、postMessage 协议)在 runtime-and-multichannel 技能 + security-and-reliability 规则里**沉淀得很完整**。下面只捞这两份没覆盖到的 SDK 细节。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-E01 | Debug 插件(调试面板):实时 FPS 曲线 / 事件流日志 / 状态变量查看器 / trace_id 展示 / 网络请求拦截 / 一键性能快照 | 技术决策版 §SDK「Plugin.Debug(调试面板)— 仅开发模式」;开发团队版 DebugPanel.vue | 遗落 | runtime-and-multichannel 技能列了 Ad/Pay/Social/Storage 四个插件,**唯独漏了 Debug 插件**。历史定的 Debug 面板(开发模式下:FPS 曲线、SDK 事件流实时日志、GameConfig 运行时状态查看、从生成到运行的全链路 trace_id 展示、网络请求拦截、一键性能快照)是创作者调试自己游戏、也是平台排查生成质量的利器,且开发团队版历史里有 `DebugPanel.vue` 组件位。这是一条实打实的遗落——一个被规划过、有明确价值、却没进任何现行档的 SDK 能力。 | | -| 前端-E02 | SDK 事件缓冲:每 10 条 or 5s flush 一次,减少 postMessage 频率不影响帧率 | 技术决策版 §SDK「事件缓冲 SDK 内 10 条/5s flush」 | 不确定 | 这条具体数值(10 条/5s)在 runtime-and-multichannel 技能里没看到明确写出(技能只说"减少 postMessage 频率")。是个小但实在的性能约束,值得确认是否需要在 SDK 契约里钉死。 | | -| 前端-E03 | 错误去重:相同 stack 10s 内只报 1 次,捕获后吞掉游戏继续 | 技术决策版 §SDK「Core.ErrorTrack:错误去重相同 stack 10s 内只报 1 次」 | 不确定 | "捕获不中断"已在降级铁律沉淀,但"相同 stack 10s 内只报 1 次"这条去重窗口的具体口径,security-and-reliability 没明确写。小约束,确认是否遗落。 | | -| 前端-E04 | SDK 内置自动上报事件集(game_load_start/success/failed、play_start/30s/complete、error、fps 每 10s 采样) | 技术决策版 §SDK「内置自动上报(无需游戏代码调用)」 | 不确定 | SDK 自动上报的这套生命周期+性能事件(尤其 game_play_30s、game_fps 每 10s 采样平均 FPS)是 feed 推荐信号和质量评估的数据源。这套事件清单在埋点契约/遥测侧应该有,但前端 SDK 这边"哪些是自动报、不用游戏调"的口径是否清晰沉淀,不确定。 | | - ---- - -## F. 移动端适配与响应式 - -> 现行前端 README §3/§5.1 把大方向定了(响应式优先消费级 Web,移动沉浸/桌面居中放大,一套组件适配两端,否决 demo 桌面侧栏)。但**移动端的具体适配约束**(安全区、键盘、手势、横竖屏、PWA/添加到主屏)在现行前端档里几乎是空白。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-F01 | 微信内置 WebView(XWeb/X5)为主要运行环境,适配其约束 | Tier1 约束 KD1「微信内置 WebView + 4G」;A2「XWeb/X5/低端 WebView 真实表现未验证」 | 不确定 | 参考运行环境是千元机 Android + 微信内置 WebView。这对前端是硬约束(微信 WebView 的 CSS/JS 特性、字体渲染、crypto 上下文都和标准 Chrome 有别)。Tier1 约束(架构域)点了这是 spike 钉子,但**前端域对"主要跑在微信 WebView 里"这件事的适配清单**(哪些特性不能用、哪些要兜底)没有沉淀。 | | -| 前端-F02 | 移动端安全区 / 刘海屏 / 底部手势条适配 | (历史未显式定,但 demo 是 390×660 框 + 竖屏 feed 的天然需求) | 遗落 | 竖屏沉浸式 feed 在真机上必然遇到刘海、底部手势条、安全区(safe-area-inset)。现行前端档完全没提移动端安全区适配。这是消费级移动 Web 的基本盘,属于"该考虑而没人记下来"的遗落——不是历史白纸黑字定过,而是历史定了"移动沉浸全屏"却没人把随之而来的安全区约束写进去。 | | -| 前端-F03 | 软键盘弹起对沉浸式布局/创作输入框的遮挡处理 | (历史未显式定,创作页 textarea + 沉浸 feed 的天然需求) | 遗落 | 创作页有一句话输入 textarea、评论有输入框,移动端软键盘弹起会顶布局。现行前端档无承载。同 F02,是"定了输入交互却没记键盘约束"的遗落。 | | -| 前端-F04 | 横屏游戏在竖屏 feed 里的呈现(旋转提示 / 强制竖屏 / 自适应) | (历史未显式定,游戏方向与 feed 竖屏的天然冲突) | 遗落 | 生成的游戏可能是横屏体验,但 feed 是竖屏沉浸流。横屏游戏怎么塞进竖屏卡片(旋转提示?letterbox?),现行档无承载。是一个真实会撞上的体验约束,遗落。 | | -| 前端-F05 | PWA / 添加到主屏 / 离线壳,作为"类原生"轻量入口 | 技术决策版 §按需加载等(零散提及离线),原生 App 列远期 | 不确定 | 现行前端 README 把"原生桌面 App / 移动 App"明确列为远期(仅 token 契约就绪)。但介于纯 Web 和原生 App 之间的 PWA(添加到主屏、离线壳、推送)历史上没有被正面讨论过,也没被明确否决。对一个"即点即玩"的消费产品,PWA 是低成本提留存的手段。值得确认是有意不做还是没想到。 | | -| 前端-F06 | 移动端触觉反馈 / 震动(游戏关键节点、互动反馈) | (历史未显式定;好玩基线 §D4 提到屏震但属引擎侧) | 遗落 | 好玩基线讲的"屏震"是引擎渲染层。移动设备的硬件震动(navigator.vibrate)作为互动/游戏反馈,前端宿主侧从未讨论。轻量但能提体感,遗落。 | | - ---- - -## G. community / biz / social 前端入口 - -> community 消息中心 + biz 客户看板归 studio 承接,这件事现行前端 README §8 已经钉了归属("B 端前端归属已定 = studio 承接,已建 BizLeads 等")。但 HJ-FE-CMBIZ-001 评审里有一大批**具体的信息架构(IA)和 UX 设计决策**,现行前端档只记了"归属已定"四个字,这些细节没沉淀。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-G01 | "我的"承载页 / 独立 `/me` 个人中心页作为 biz/消息/等级奖励/角标四个二级入口的聚合容器 | community-biz review D1「TabBar『我的』直指 /project 无聚合容器,需新建 /me 或 Project.vue 加聚合区」 | 不确定 | 这是一条真正的 IA 决策:现行 TabBar 第三入口直指项目列表页,没有一个聚合容器来挂"biz 入口 / 消息入口 / 等级奖励卡 / 未读角标"这四个二级入口。评审建议新建 `/me` 个人中心页或在 Project.vue 顶部加聚合区。这个"个人中心聚合页"的存在与否,现行前端档没记。属于"信息架构断层"的关键设计点。 | | -| 前端-G02 | 创作者等级 / 奖励展示(新人激励的可视化抓手) | community-biz review D2「含等级/奖励展示,/community/level + /rewards 后端已就绪」 | 不确定 | 后端 `/community/level`、`/community/rewards` 端点已就绪(P-INC-01 新人激励)。前端是否做"等级进度条 + 奖励卡"展示,评审建议做(否则后端能力成孤儿)。现行前端档无承载,属待确认。 | | -| 前端-G03 | biz demo 客户试玩的取包路径 = 跨前后端契约缺口(owner-agnostic 取包) | community-biz review D5⚠️「runtime 仅 preview(owner 校验)/play(status=1),运营代建 demo 的 owner≠客户→无可调端点」 | 遗落 | 这是一条被评审标为"高风险、卡 B 端现金线命脉"的真实契约缺口:运营为客户代建的 demo,owner 是运营不是客户,客户走 preview 会被 owner 校验拦,走 play 又要求已正式发布(status=1)。runtime 当前没有 owner-agnostic 的取包判定端点。这条缺口若没被后续闭合,B 端 demo 试玩闭环不可达。值得确认它最后是怎么解的(走正式发布流 vs runtime 补端点)。 | | -| 前端-G04 | biz demo 产出桥接:运营手工回填 versionId(契约无"为 lead 生成 demo"端点) | community-biz review §3.3「advance→3 弹窗 demoVersionId 由运营手工回填,跨页/跨系统运营动作」 | 不确定 | 契约里没有"为某 biz 询单一键生成 demo"的端点,运营要先去创作流另行生成游戏拿 versionId、再手工复制回 biz 推进弹窗。这个跨页跨系统的运营动作是 admin 侧 UX 的隐藏断点,现行档无承载。 | | -| 前端-G05 | 站内信 bizRef 跳转映射(各类型消息点击后跳到对应业务页) | community-biz review D4「站内信 bizRef 跳转映射契约未定」 | 不确定 | 站内信带 bizRef 跳转键(生成完成→项目详情、审核结果→...、收益变动→收益页)。但收益变动这类 MVP 还没有明细页,跳转映射当时未定,评审建议先做"点击标记已读不跳转"最小集。这条跳转映射的最终口径,现行档无承载。 | | -| 前端-G06 | 未读角标承载位:TabBar 当前无 badge 槽,角标挂二级入口 + 刷新时机 | community-biz review D6「TabBar 仅 path/match/label/icon 无 badge 槽」;前端 README §8 已点"4 tab 含 /message 带未读角标" | 不确定(部分已沉淀) | 现行前端 README §8 已经说了消息一级入口落地(TabBar 3→4 tab 含 /message 带 unreadTotal 角标)。但评审当时纠结的是"TabBar 无 badge 槽、角标该挂哪、何时重拉 unread-count(进页 onMounted + 已读乐观递减,本波不做实时推送)"。现行已经做成 4 tab 了,所以这条算部分落地——但"不做实时推送、靠进页拉取"这条降级口径是否记牢,值得核。 | | -| 前端-G07 | 进度时间线组件(biz 询单状态机的竖向时间线) | community-biz review D7「无现成 Timeline 组件,默认页内联,待第二消费者再抽公共件」 | 不确定 | biz 询单详情要渲染状态机进度时间线(提单→报价→制作→待验收→交付),当时仓里没有任何 Timeline 组件,评审决定先页内联(rule-of-three:单消费者不抽公共件)。这条"何时抽成公共 Timeline"的判定,现行组件库设计档没记。 | | -| 前端-G08 | "互动即弹登录"统一模式(写动作入口前置 isRealLogin 判定 → 弹去登录 + redirect) | community-biz review §4.1「写动作最前置 if(!isRealLogin) → showConfirmDialog 去登录」(引 Feed.vue:151) | 不确定 | 这是一个跨 feed/community/biz 复用的统一交互模式:任何写动作(提单/反馈/确认/标记已读/点赞)入口先判真实登录,未登录弹"去登录"确认框带 redirect。已在代码里实现(Feed.vue),但作为一条**跨页通用 UX 模式**,前端设计档没把它沉淀成约定。值得确认是否该写进组件/交互规范。 | | -| 前端-G09 | 报价非订单提示 / 金额一律分→元换算 + ¥ 展示约定 | community-biz review §5.3 D8「金额统一分→元(/100)两位+¥;报价处标注『仅供参考不支持在线支付』」 | 不确定 | biz 报价展示的金额口径(后端存分、前端统一 /100 转元带两位+¥,admin 报价输入用元前端换分避大额浮点)和"报价仅供参考、本波不支持在线支付"的提示文案,是 B 端 UX 约定。现行档无承载,小但实在。 | | - ---- - -## H. admin(game-admin)前端 - -> 现行前端 README 对 admin 几乎只说了"沿用 Element Plus 默认、品牌色对齐"。admin 侧历史上有几条具体约束散在评审里。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-H01 | admin 权限点门禁约定:现存 wanxiang 页零 v-hasPermi,靠后端 @PreAuthorize 兜底 | community-biz review §4.2「全部 wanxiang 页零 v-hasPermi,推荐沿用现状」 | 不确定 | admin 侧的权限控制纪律:前端不挂 v-hasPermi,全靠后端 @PreAuthorize 兜底(因为前端挂点需 system_menu seed 已到位,否则超管外角色按钮全隐)。这条 admin 前端权限约定,现行前端档没记。是个值得明确的纪律(前端是否永远不挂权限点)。 | | -| 前端-H02 | admin 构建腐化防护:钉 vite 5.1.4 清装、移杂散 pnpm-workspace.yaml | community-biz review §6.2 风险表「admin 构建腐化,照 admin-ui-walk-cdp-recipe 钉 vite 5.1.4」 | 不确定(已沉淀于技能/记忆) | admin 前端构建容易腐化(vite8 等),修法是钉死 vite 版本清装、移杂散 workspace 文件。这条已在记忆 admin-ui-walk-cdp-recipe 沉淀,此处仅指针,确认 staging-ops 技能是否完整承载。 | | -| 前端-H03 | admin 缺单询单详情端点,前端用列表行 + quotes 拼装(守零后端改动边界) | community-biz review §3.3「AdminBizLeadController 无单询单详情 GET,前端列表行+GET quotes 拼装」 | 不确定 | admin biz 队列缺一个"单询单详情" GET 端点(app 侧 detail 带客户归属校验、运营复用会被拦)。评审为守"零后端改动"边界,让前端用列表行+报价历史拼装详情。这条"前端拼装代替后端详情"的妥协,现行档无承载——是个技术债,值得记。 | | - ---- - -## I. 性能与体验 SLO - -> feed 首屏、点卡到可玩这套体验 SLO,Tier1 约束 brainstorm(架构域)定得很细。但这些**本质是前端可感体验承诺**,现行前端档没有引用它们。同时旧版长文档里有几条已被取代的旧 SLO 数字,列出来防止有人照旧文档复刻。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-I01 | 点卡→可玩 S2 体验门:常态≤2s、全新设备首次≤3.5s | Tier1 约束 R2(创始人拍板,锚千元机+4G P75) | 不确定 | 这是用户最直接感知的体验承诺(点一下游戏卡,多久能玩起来),Tier1 约束(架构域)明确定了常态≤2s/首次≤3.5s。但前端域 README 完全没引用这套体验 SLO。前端是这个 SLO 的执行点(预热、首帧、加载态),却在前端档里看不到它——建议前端域至少引用一句,别让体验承诺只活在架构域。 | | -| 前端-I02 | 首帧保障:<300ms 绘出主题底色/标题(GameConfig 随 feed 清单先行可得) | Tier1 约束 R12 E2「<300ms 绘主题首帧,加载等待感消失」 | 不确定 | "点开游戏先在 <300ms 用 manifest 画出主题底色和标题、消除加载等待感"是前端 feed/宿主的首帧 UX 设计。现行前端档无承载。属于体验设计点遗落在架构域。 | | -| 前端-I03 | 自适应质量分档:首次会话探测设备能力定档,P95 低端机自动降粒子/关后处理/限 dpr | Tier1 约束 R13 E3「自适应质量分档,P95 优雅降级机制化」 | 不确定 | "首次会话探测设备能力、低端机自动降级画质(降粒子/关后处理/限 dpr)"这套自适应质量,涉及前端/宿主的设备探测与降级开关。现行前端档无承载,且 E3 的探测信号集(WebGL 能力/deviceMemory/首帧采样)当时还是 outstanding question。 | | -| 前端-I04 | feed 首屏 P75<3s(既有红线保留,比 Facebook Instant Games <5s 更严) | Tier1 约束 R1;技术决策版 §运行性能;前端 README §8 提到"first-screen P75<3s"在 tier2 段 | 不确定(部分已沉淀) | feed 首屏 P75<3s 是 MVP 量化目标(AGENTS 也列了),Tier1 约束保留为 S1 红线。前端 README §8 tier2 段顺带提了一句。算部分沉淀,但前端域没把它当作前端的首要 SLO 正式列出。 | | -| 前端-I05 | 旧 SLO 数字:游戏流首屏 P95<6s / 远期 P75<1.5s | 技术决策版 §运行性能「P75<3s, P95<6s」;§性能优化「远期 P75<1.5s」 | 过期/弃用 | 旧版技术决策版写过 P95<6s 和远期目标 P75<1.5s。Tier1 约束 brainstorm(2026-06-11 创始人拍板)把 P95 改判为"优雅降级、不承诺帧率"(R3),P95<6s 这个硬数字实际已被"P95 走自动降级档"取代。列出来是防止有人照旧文档把 P95<6s 当现行硬门。远期 P75<1.5s 则仍是个可参考的拉伸目标。 | | -| 前端-I06 | 旧体积门:首屏≤2MB / 总包≤10MB(前端感知的资源约束) | 技术决策版 §性能门禁「包体积≤10MB/首屏≤2MB」;runtime-and-multichannel 已沉淀 | 不确定(已沉淀于技能) | 首屏≤2MB/总包≤10MB 在 runtime-and-multichannel 技能里已沉淀(作为编译门禁)。这里仅留痕:它同时也是前端首屏体验约束(首批可玩 payload 大小)。Tier1 约束 R7 把它细化为"每游戏首批可玩 payload ≤1MB(wire)"。确认前端是否需要感知 R7 的更严口径。 | | - ---- - -## 附:本次回收没列的(已被现行档清楚覆盖,记此免后人重查) - -为免后人重复挖,以下大块**已在现行档清楚覆盖,有意不列**:① 设计 token 两层 + 组件库四层 + 三档主题 + 圆角铁律 + i18n 三契约 + Inter self-host 字体(前端 README §4-6 全覆盖);② 真实试玩宿主的 iframe 沙箱 + postMessage 双校验 + manifest sha256(前端 README §7.1 + security-and-reliability §1.1);③ SDK 四插件(Ad/Pay/Social/Storage)+ 广告支付在宿主侧 iframe 外渲染 + 懒加载首屏<8KB + 降级铁律 + 5s 加载超时(runtime-and-multichannel + security-and-reliability §7);④ "学 demo 设计语言、不学其桌面侧栏布局"的核心取舍 + studio-vs-demo 勿误砍/勿误判两份清单(前端 README §3/§7);⑤ 分享落地页 + OG 元数据 + utm 归因、登录注册整屏 + 协议门 + anonId、发布门禁 7 项预检(前端 README §7.1);⑥ 编排器旁路掩盖 UI 缺陷、真 UI 走查是唯一手段、CDP 七坑(ui-walkthrough-cdp 技能);⑦ demo 审计里"素材中心/玩法模板中心/六资产工作坊/IP 货架"的 descope 判定(前端 README §7.2 已逐条沉淀)。⑧ 视觉增强 repair(已 NO-GO,且属生成评测环非前端域)、OpenGame 对照/SAA 编排(属架构域生成引擎)——均非前端域,不计。 diff --git a/docs/architecture/_recall/前端-第二轮.md b/docs/architecture/_recall/前端-第二轮.md deleted file mode 100644 index 3dc699fd..00000000 --- a/docs/architecture/_recall/前端-第二轮.md +++ /dev/null @@ -1,98 +0,0 @@ -# 前端域 · 历史设计点回收 · 第二轮(复核 + 查漏) - -> **这份是什么。** 第一轮已经把前端域的历史设计点穷尽式挖了一遍,落成 [前端-历史设计点.md](前端-历史设计点.md)(54 条)。这一轮不重抄第一轮——它只干三件事:**复核第一轮判得准不准、第一轮挖完之后新落地的一批设计稿把哪些"遗落/不确定"条目接住了、以及第一轮漏挖的设计点补上来**。所以你在这里只会看到三类内容:改判的、被新档覆盖的、新挖的。第一轮已经判对、也没被新档覆盖的条目,这里一个字都不提(那是噪音)。 -> -> **复核怎么做的。** 抽了第一轮十来条关键条目,逐条 `git grep` 回到它声称的出处核对——E01 Debug 插件、B01 上滑销毁容器、E02/E03/E04 三条 SDK 数值、B05 "最喜欢"星标、B06 同款创作、C07 currentVersionId 修复 commit、DebugPanel.vue 组件位,全部对得上,出处真实、没有张冠李戴。第一轮的出处可信,这一轮不再逐条复述核对结果,只把**确实要改判的**挑出来(见第一块)。 -> -> **新档指的是哪些。** 第一轮(2026-06-20)之后,创始人定了五条横跨多域的优先项,随之落地了一批正式设计稿:[数据飞轮](../架构/生成引擎/数据飞轮.md)、[审核台运营](../运营/审核台运营.md)、[观测体系](../运维/观测体系.md)、[k8s迁移](../运维/k8s迁移.md),以及前端 README 自己新增的 [§7.3 产品形态定调](../前端/README.md)。这些档把第一轮当时还悬着的好几条"不确定/遗落"接住了,逐条列在第二块。 -> -> **新挖的判据,同第一轮。** 遗落=历史讨论过、有价值、现行没沉淀也没明确弃;过期/弃用=已被取代或决定不做;不确定=拿不准现行覆盖没。现行已覆盖的不补。特别留意了**跨域交界处**——审核台/观测体系这两份新档落在运营域和运维域,它们带来的 admin 前端承载(审核台四页、观测大图),第一轮的前端 agent 默认归运营/运维侧挖、运营/运维侧又默认归前端挖,结果两边都漏了。这类"交界处双漏"是这一轮新挖的重点。 - ---- - -## 一、复核勘误表(改判的条目) - -第一轮整体判得相当准,出处无一编造。下面是复核后**确实要改判**的条目——多数是"第一轮判得偏保守、新事实出来后该收紧或松一档"的微调,没有出处造假级别的错误。 - -| ID | 原判 | 新判 | 为什么改 | -|---|---|---|---| -| 前端-C01~C04 | 不确定 | **不确定 → 已被新档覆盖(转入第二块)** | 第一轮把对话式创作 UX(对话页/素材上传 UI/确认卡/差量修改入口)整体标"不确定",理由是"后端走到对话式、前端档还停在 descope"。新落地的前端 README §7.3 已经把这条口径分叉正面解决了——明示对话式创作"不是 descope、是产品形态已定调、前端 UI 待补",并逐条点名 C01–C04。所以这四条的状态从"口径悬而未决的不确定"收敛成"已被现行档接住、定性为待补设计",移到第二块。注意:**覆盖的是"定性",不是"出了 UI 设计"**——README §7.3 只把它们从 descope 里捞出来、承认要补,具体的对话框/确认卡/差异展示设计仍未画。 | -| 前端-C05 | 过期/弃用 | **部分改判:资产驱动档→已被定调覆盖;全自定义编排→仍过期** | 第一轮把"三种创作模式(一句话/资产驱动/全自定义编排)"整条标过期,但其中**资产驱动档**正以"对话+素材"形态在 README §7.3 回归(C01/C02 就是它的承载)。所以这条要拆开:全自定义可视化编排 IDE 确实仍是 descope(README §7.2 明确远期),但资产驱动这一中间档不该再算"过期"——它已被 §7.3 定调为产品形态的一部分。第一轮自己在"为什么"里也察觉了("C01/C02 正以对话+素材形态回归"),但状态列仍标过期,这里把状态本身纠过来。 | -| 前端-B06 | 不确定 | **不确定 → 已被新档覆盖(转入第二块)** | 第一轮把 feed"同款创作入口"标不确定。新落地的数据飞轮 §3.1(溯源链)整节就是它——从 feed 卡片点"做同款"→ `/studio/create` 带 `remixFrom` → 血缘边 → 试玩页溯源条,产品主路、数据落点、防滥用全设计了。状态从不确定改为已覆盖,移到第二块。 | -| 前端-I04 | 不确定(部分已沉淀) | **维持,但覆盖面扩大** | 第一轮说 feed 首屏 P75<3s 只在前端 README §8 tier2 段顺带提一句、算部分沉淀。新落地的观测体系把它正式列为"前端层"观测目标(§2)、并接进前端可观测性埋点(§3.3 收首屏耗时对齐 P75<3s)。判定不变(仍是前端域 README 没把它当首要 SLO 正式列),但要记一笔:它现在在运维观测域有了度量承载,不再是纯口号。 | -| 前端-D04 / D06 | 不确定(已沉淀于技能) | **维持不确定,但 D06 倾向"已基本沉淀"** | 复核了 game-e2e-cdp-harness 技能:D06 说的"试玩宿主按模板暴露只读取证几何清单供 player 驱动真实输入",技能里其实已经有对应承载——rect 映射(canvas 坐标→getBoundingClientRect→页面坐标)、`_forensicsView().state()` 读实体位置自动出招的 driver 两态。所以 D06 的"显式几何契约"在 e2e 技能侧已基本落地,不是悬空的。判定可从"不确定"收紧到"已沉淀于技能、仅前端域档未引用"。D04(localhost 安全上下文掩盖缺陷)同理,技能已作红线沉淀,维持。 | - -> 一句话总结复核结论:**第一轮没有需要推翻的错判,出处全部真实**。上面五条都是"新事实出来后把状态收紧/拆细"的微调,不是纠错——尤其 C01–C05、B06 这几条,是因为第一轮之后新档落地把悬着的口径接住了,属于"清单被现实追上了",正是这一轮该干的活。 - ---- - -## 二、已被新档覆盖的第一轮条目 - -这是这一轮最实的产出:第一轮标"遗落/不确定"、当时确实没承载,**现在被新落地的设计稿接住了**。逐条列清被哪份新档的哪一节覆盖,这样创始人判定时可以直接把这些条目划掉(已闭合),不必再纠结。 - -| 第一轮 ID | 第一轮设计点 | 第一轮判定 | 被哪份新档覆盖 | 覆盖到什么程度 | -|---|---|---|---|---| -| 前端-B06 | feed 同款创作入口(从卡片发起做同款) | 不确定 | **[数据飞轮](../架构/生成引擎/数据飞轮.md) §3.1 溯源链** | **完全覆盖**:feed 卡片"做同款"→ `/studio/create {remixFrom}` 的产品主路有时序图;血缘记在源 schema 的 `lineage` 字段 + `game_lineage_edge` 表;防刷三道闸(深度截顶/D12 配额空窗兜底/去重独立创作者数);试玩页溯源条 + 创作者中心"被 N 人做了同款"入口。连漏斗埋点(remix_click/remix_submit)都设计了。注:同款的产品形态默认取"轻量跳转"(非真 remix),前端入口据此设计。 | -| 前端-C01 | 对话式生成/修改的前端创作页 | 不确定 | **[前端 README §7.3](../前端/README.md)** | **覆盖"定性"、未覆盖"设计"**:§7.3 把对话式创作明确为产品形态(不再算 descope),逐条点名"对话框"待补。承认了、定性了,但对话框/多轮交互的具体 UI 仍未画——属"已立案待补",不是"已设计"。 | -| 前端-C02 | 六类素材上传 UI 驱动生成 | 不确定 | **[前端 README §7.3](../前端/README.md)** + **[数据飞轮 §3.2](../架构/生成引擎/数据飞轮.md)** | **覆盖定性 + 划清了边界**:§7.3 点名"把六类素材传进去当生成上下文"待补;数据飞轮 §3.2 进一步划清生成侧只负责"把选用素材透传进生成上下文"(走 P-CRT-04 的 assetContext 通道),素材货架/授权属素材中心模块。上传 UI 本身仍待补设计。 | -| 前端-C03 | 智能确认卡 UI(目标摘要确认) | 不确定 | **[前端 README §7.3](../前端/README.md)** | 覆盖定性:§7.3 点名"系统解析意图后的目标确认卡"待补。具体确认卡组件仍未设计。 | -| 前端-C04 | 差量修改的前端入口与差异展示 | 不确定 | **[前端 README §7.3](../前端/README.md)** | 覆盖定性:§7.3 点名"差量修改的入口和'改了哪、其余没动'的差异展示"待补,且明确后端 `/studio/modify`、SAA modify 节点已是现行真相。差异可视化的具体设计仍待补。 | -| 前端-C05(资产驱动档) | 三模式中的"资产驱动"中间档 | 过期/弃用(误判) | **[前端 README §7.3](../前端/README.md)** | 资产驱动档以"对话+素材"形态被 §7.3 纳入产品形态,不该再算过期(见第一块改判)。全自定义编排 IDE 仍是 descope。 | - -> **一个要点提醒创始人**:C01–C04 被"覆盖"的含义是**口径被接住了**(从"前端档说 descope、后端说现行真相"的分叉,收敛成"产品形态已定调、前端 UI 待补"),**不等于这些 UI 已经有设计稿了**。前端 README §7.3 自己也写明这是"前端 UI 待补设计"。所以这四条从"清单上悬而未决的不确定"变成"现行档里明确挂账的待办",闭合的是"该不该做"这个问题,"具体怎么做"还在前面等着。真要落地仍要走一轮前端创作 UX 的设计。 - ---- - -## 三、查漏补充清单(新挖的) - -第一轮的九张表(A–I)覆盖得很广,但有几块是它结构性漏掉的——尤其是**两份新设计稿(审核台、观测体系)落在运营/运维域,它们要求的 admin 前端承载,第一轮的前端 agent 没扫到**(那两份档当时还没落地)。另有几条是跨域交界处、历史白纸黑字定过价值、前端却始终没承载的。编号接第一轮续(第一轮 A–I 表最大到 I06,这里从 J 段新起,ID 用 J01 起,避免与第一轮 A–I 撞号)。 - -### J. admin 审核台前端(审核台运营新档带来的全新承载) - -> [审核台运营](../运营/审核台运营.md) §3.7 明确审核台的运营出口是 game-admin 上的一组页面(Element Plus)。这是一整套**第一轮完全没有的 admin 前端**——第一轮 H 表只挖了 admin 的 biz 队列/构建/权限三条,没碰审核台,因为审核台设计稿是第一轮之后才落的。这块是典型的"跨域交界双漏":前端 agent 以为运营 agent 会挖审核台 UI,运营 agent 以为前端 agent 会挖 admin 承载。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-J01 | admin 审核队列页:待审工单 + 申诉工单两列表,按优先级/锁风档/触发原因/超时筛选,标红超 SLA | 审核台运营 §3.7「审核队列页」 | 遗落 | 审核台的主屏。展示机审转 review 的工单 + 锁风人工档工单 + 申诉工单,审核员从这里认领。数据来自审核工单台账分页(`compliance:review:query` 新增)+ 申诉台账分页。这是一个全新的 admin 前端主界面,现行前端档(含 H 表)零承载。属待建的核心运营工作台。 | | -| 前端-J02 | admin 审核详情页:一条工单的全部判定证据(可试玩/可预览 + 机审逐层结论 + 锁风档 + 命中 IP + 历史处置) | 审核台运营 §3.7「审核详情页」 | 遗落 | 审核员在这页看证据给 approve/reject。要把"游戏可试玩、素材可预览、快检判了啥、阿里云返回什么标签、各原子 reason、锁风档位、命中 IP"全摊开。这是审核质量的关键界面,且要在 admin 里嵌一个能真试玩待审游戏的宿主(和 C 端试玩宿主同源但在 admin 侧),前端工程量不小,现行档无承载。 | | -| 前端-J03 | admin 处置操作区:一键封禁/降权/下架/打分级标签,即时联动下游 | 审核台运营 §3.7「处置操作页」+ §3.5 | 遗落 | 三类处置动作的前端入口(封禁选分级+期限+原因、降权/下架调 feed 曝光、打分级标签)。这些是重权限动作,前端要按新增权限位(`compliance:exposure:handle`/`rating:set` 等)显隐按钮。现行档无承载。 | | -| 前端-J04 | admin 锁风档位配置页:给 IP 配 lockStrength、维护题材黑名单兜底规则、调各档机审阈值 | 审核台运营 §3.7「锁风档位配置页」+ §3.3 | 遗落 | 策略配置界面(非单条处置),只给合规管理员(`compliance:lock-policy:config`)。维护 `lock_strength_policy` 过渡表。这是审核台四页里最"运营策略"的一页,现行档无承载。 | | -| 前端-J05 | admin 审核台权限按钮显隐 vs 后端 @PreAuthorize:审核台尤其要守"前端藏按钮不算数" | 审核台运营 §3.7 权限段 + §5.1「权限不可绕」 | 不确定 | 审核台带"能封号、能改曝光"的端点,前端藏了按钮但 API 直连仍可达,必须后端拦死。这条承自鉴权域铁律,但**审核台是它最敏感的应用场景**——和第一轮 H01(admin 零 v-hasPermi、靠后端兜底)是同一条纪律在审核台的具体落点。值得确认:审核台前端到底挂不挂 v-hasPermi(H01 说 admin 现状零挂点),还是和现状一样纯靠后端。这是 H01 在新场景下的延伸,需明确口径。 | | - -### K. admin 观测前端(观测体系 / k8s 迁移新档带来的全新承载) - -> [观测体系](../运维/观测体系.md) §3.5 明确"admin 观测入口现状是零,要整套新建"。这又是第一轮没有的一块 admin 前端,且观测档自己点明 game-admin 下当前没有任何观测相关的路由/菜单/组件。同属跨域交界——观测设计落在运维域,但它要求的 admin 前端承载第一轮没扫。 - -| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 | -|---|---|---|---|---|---| -| 前端-K01 | admin 观测大图:嵌入 Grafana 核心大盘(可用性/错误率/生成成功率/关键链路) | 观测体系 §3.5「观测大图」 | 遗落 | 在 admin 新建"观测"菜单,把 Grafana 大盘以 iframe 或 embed 方式嵌进来,运营点一下看全局健康。现行前端档零承载。**这条带一个真实前端工程顾虑**:Grafana 默认 `X-Frame-Options: deny` + 自身 CSP,直接 `