docs(recall): 清理历史回收过程留痕(删 12 清单+README,保判定记录)
回收→判定→落档闭环已闭合,捡回项已写进现行设计档(带来源标记)。删 12 份回收 清单(第一轮 6 + 第二轮 6)+ README 总索引,git history 永久保留可随时翻;保留 创始人判定.md 作判定追溯权威。同步修 5 处指向被删清单的断链(前端 README 2 + 观测体系 3,改为文字引用 + 判定记录指针)。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
zizi
parent
c9db9f7d36
commit
14c3ce4896
@ -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 通道批量失效真实发生过),现行档只有一句飘在风险表的应对、零运维落点。
|
||||
|
||||
判定方式同第一轮:每条第二轮清单带空判定列,你勾捡回 / 不捡 / 再议。
|
||||
@ -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 周看指标）这些被冻结却没沉淀的好想法。
|
||||
@ -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 是一组,补上就让"这半年算不算没白干"有了一句能挂在墙上的判据。
|
||||
@ -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 编排(属架构域生成引擎)——均非前端域,不计。
|
||||
@ -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,直接 `<iframe src>` 会被浏览器拒,要么放开 Grafana 嵌入限制、要么改 admin 后端取数前端自渲(两条路见观测档 §6 待核)。这个嵌入安全开关是 admin 前端的具体硬点。 | |
|
||||
| 前端-K02 | admin → Grafana 单点免登(SSO):别让运营进监控还要再登一次 | 观测体系 §3.5 SSO 段 + k8s迁移 §4 阶段3 | 遗落 | admin 用户走 yudao 原生 system_users 身份,Grafana 是另一套登录态。要做 SSO 免登(倾向 auth-proxy 透传身份头)。这条是 admin 前端体验的关键约束(否则一键进盘变成两次登录),现行档无承载,观测档列为待核。 | |
|
||||
| 前端-K03 | admin 告警概览入口:夜莺最近告警列表 / 值班状态嵌进 admin | 观测体系 §3.5 图 + §3.1 | 不确定 | admin 观测菜单除了观测大图,还要有一个告警概览(从夜莺取最近告警/值班状态)。观测档的链路图画了 `admin -.-> 夜莺告警列表`,但这块前端承载比观测大图更模糊,值得确认是否第一期就做。 | |
|
||||
|
||||
### L. C 端 studio 前端漏挖(跨域交界 + 历史定过未承载)
|
||||
|
||||
> 这几条是第一轮 B/C/G 表边缘漏掉的 C 端前端承载,多数在变现/合规/数据飞轮的历史讨论里定过价值,前端始终没接。
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 前端-L01 | 创作者收益钱包页(studio 端):查收益、查明细、发起提现的真 UI | M4 变现真实化 review §「跨功能完整 e2e」明示"前端 studio 钱包页真 UI 走查提现"属前端接线波合并点;变现端到端 §「创作者收益钱包 game_trade_account」 | 遗落 | 后端收益钱包(`game_trade_account`:广告分账/打赏/订阅三线汇合)、提现状态机已落地真跑,但**studio 端的创作者收益页/钱包页/提现发起 UI 至今没有承载**。M4 review 自己把"studio 钱包页真 UI 走查提现"列为前端接线波的待合并点,变现端到端档只承载了 admin 侧(提现审核 Tab),C 端创作者怎么看自己赚了多少、怎么提现,前端档空白。第一轮 G05 只碰了"收益变动站内信跳到收益页"这个跳转映射,没把收益页本身当条目。这是创作者侧最直接感知"平台帮我赚钱"的界面,遗落。 | |
|
||||
| 前端-L02 | 创作者中心"我的作品被 N 人做了同款"溯源入口 + 试玩页溯源条"改编自 XX" | 数据飞轮 §3.1「试玩页展示溯源」+「原作者侧创作者中心能看到被 N 人做了同款」 | 不确定(部分已点) | 数据飞轮把这两个展示点钉成"溯源链对用户可见的出口,没有它们血缘就是孤儿数据",算是点了归属。但它们的前端设计(溯源条长什么样、点击跳回原作的交互、父被删时降级成不可跳/"原作已下架"灰态、创作者中心的同款聚合卡)留在前端域待补。属"数据飞轮点了归属、前端 UI 待补"——和 D05(tier2 承载)同构。 | |
|
||||
| 前端-L03 | AIGC"AI 生成"显式标识在各发行面的前端展示(卡片/详情/分享页) | 审核台运营 §3.6「AIGC 显式标识」;战略与合规 §「AIGC 显式标识」(8 项法定 P0 之一) | 遗落 | 《人工智能生成合成内容标识办法》要求显著标注"AI 生成",这是法定 P0 义务。审核台档明确它"在所有发行面都要带"(游戏卡片/详情页/分享页)。但这块**前端展示承载**——标识挂在哪、长什么样、分享页 OG 卡片里带不带——现行前端档零字。这是合规硬义务落到前端的具体动作,和 B 表的 feed 卡片设计强相关,遗落。 | |
|
||||
| 前端-L04 | 青少年模式 / 适龄分级在 feed 与详情页的展示与过滤(按 ContentRating 过滤候选集) | 审核台运营 §3.5「分级标签」(分级标签在 feed/详情页展示、青少年模式据此过滤);技术决策版 §「未成年人保护:识别未成年后禁广告+禁付费+限时长+最小采集」;鉴权 review(P-ACC-03 适龄分级展示标 v2.0) | 不确定 | 内容分级(all/8+/12+/16+)既是处置结果也是展示依据:一方面在 feed/详情页对用户展示分级,一方面青少年模式据此过滤掉不适龄内容。这套**前端的分级展示 + 青少年模式下的 feed 候选集过滤**,现行前端档无承载。历史上 P-ACC-03 标 v2.0(远期),但审核台新档把分级展示和防沉迷过滤重新摆上台面。值得确认:青少年模式的前端门控(限时长提示、禁付费入口隐藏、按分级过滤 feed)是 v2.0 推迟还是要在合规放量前补——这是放量合规绕不开的前端动作。 | |
|
||||
| 前端-L05 | feed 互动按钮当前是 mock(toast + 假数),真接后端是前端接线待办 | demo 审计 §「feed 互动按钮 mock(toast+假数)」 | 不确定 | demo 审计实证 feed 的点赞/收藏/分享/评论按钮当前是 mock(toast 加假数据),不是真接 community/social 后端。第一轮 B04 挖了"举报/评论/关注的入口从未在前端档出现",但没挑明**现存的点赞/收藏/分享这几个按钮本身还是假数据、真接后端是前端接线待办**。这是一条比 B04 更基础的现状缺口——不是"缺入口",是"有入口但是假的"。值得确认前端互动按钮真接后端排在哪。 | |
|
||||
|
||||
### M. 前端可观测性(观测体系新档带来,第一轮 I 表未及)
|
||||
|
||||
> 第一轮 I 表挖的是"体验 SLO 数字"(点卡≤2s、首帧<300ms 等),没有挖"前端运行健康怎么被观测到"这一面——因为观测体系档当时没落。这条补上。
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 前端-M01 | studio/admin 前端运行健康观测:OTel Web SDK 收首屏耗时(对齐 P75<3s)/JS 报错率/关键交互成功率 + traceparent 前后端串链 | 观测体系 §2「前端层」+ §3.3「前端怎么埋」 | 不确定(已被观测档承载、前端档未引) | 观测体系把"前端运行健康"列为独立观测层:页面首屏(P75<3s)、JS 运行时报错、关键接口(刷流/生成/发布)失败率,用 OTel Web SDK 经 OTLP/HTTP 推给 Collector;并要求前端发请求时注入 `traceparent` 把前后端 trace 串成一根(生成失败时前端拿 trace_id 能在 Grafana 查到卡在哪)。这条**在观测域已是现行设计**(排第三期),但前端域 README 完全没引用——它和第一轮 I 表的体验 SLO 是一体两面(SLO 是目标、Web SDK 是度量手段)。判定:观测档已承载,前端域是否需引一句"前端要接 OTel Web SDK"待定,属边界口径(同第一轮 43 条不确定的模式)。 | |
|
||||
|
||||
---
|
||||
|
||||
## 附:这一轮的两个判断,供创始人参考
|
||||
|
||||
**一、第一轮的质量结论:可信,不必返工。** 抽验的十来条出处全部对得上,九张表的分类只有 C05 一条状态需要拆细(资产驱动档不该算过期)、C01–C04/B06 因新档落地从"不确定"升级为"已覆盖"。没有发现编造出处、张冠李戴、或把现行已覆盖误判成遗落的情况。第一轮那句"前端 43 条不确定本质是一个边界问题、不是 43 个独立缺口"的判断,这一轮复核下来依然成立。
|
||||
|
||||
**二、这一轮新挖的 16 条,重心全在"跨域交界处的 admin 前端"。** J 段(审核台四页+权限)、K 段(观测三入口)合计 8 条,都是**新设计稿落在运营/运维域、但要求 game-admin 前端承载**的条目——它们第一轮被漏掉,不是因为没价值,而是因为"前端 agent 以为是别的域的活、别的域 agent 以为是前端的活"。这正是你这一轮特别交代要留意的双漏地带。L 段补的是 C 端 studio 几条历史定过、前端始终没接的承载(创作者收益页、同款溯源条、AIGC 标识、青少年模式过滤、互动按钮真接),其中**创作者收益页(L01)和 AIGC 显式标识(L03)分量最重**——前者是创作者侧"平台帮我赚钱"的核心界面、后者是法定 P0 合规义务,两条都白纸黑字定过、前端却空白。建议优先看这两条,以及 J/K 段那 8 条"审核台/观测台要落进 admin"是否纳入近期前端范围。
|
||||
@ -1,77 +0,0 @@
|
||||
# 后端数据契约 · 历史设计点回收清单
|
||||
|
||||
> 这份清单做的是一件事:把"后端数据契约"这个领域里——历史和留痕文档里认真讨论过、但**现行 docs/architecture 没有沉淀下来**的设计点、想法、顾虑、约束——逐条挖出来,交给创始人判一判该不该捡回。它不是现行架构文档,而是一次穷尽式的"翻旧账",目的是防止历史上想清楚过的好东西、或本该考虑的约束,在多轮 reframe 和文档重构里悄悄丢掉。
|
||||
>
|
||||
> **判定口径**:每条问"它在现行档里讲到没有?"——现行档 = `docs/architecture/后端/`(README / 数据模型 / 鉴权与权限)+ `架构/13模块.md` + `架构/契约总览.md` + `架构/生成引擎/`(固定游戏架构 / 引擎与运行时等)+ `运营/`(变现与单位经济 / 渠道发行 / 合规闸门)+ `.agents/`(knowledge / rules / skills)。注意:本领域不少东西**已经沉淀在运营域或 .agents 里**(比如分账公式、渠道 9c/9g 契约、ClickHouse/Sentinel/幂等四场景),这些**不算遗落**,我已剔除,不再列入下表当噪声。
|
||||
>
|
||||
> **扫过哪些历史文档**:`docs/architecture/_archive/` 三份长设计(技术决策版 HJ-ARCH-001 / 技术架构与模块 HJ-TECH-002 / 开发团队版);`docs/agent-specs/_archive/` 里的后端建设波(后端模块并行建设 review/execution、wave3 创作补全与发布闸门、admin-wave2)、真实鉴权与匿名玩家 review/e2e、agent 化生成 QA 闭环 review、M4 变现真实化 review、W4 单位经济埋点评审纪要、核心功能技术实现方案(已退役为桩)、已归档的 canonical(变现与单位经济 / 渠道发行 / 战略与合规);`docs/agent-specs/` 顶层活档(固定游戏架构与 SAA execution、生命周期项目管理 review);`docs/brainstorms/`、`docs/plans/`、`docs/memorys/`;以及 `contracts/agent-loop/source-project.schema.json` 等契约源文件。
|
||||
>
|
||||
> **怎么读这张表**:状态分三档——**遗落**(讨论过、有价值、现行档没沉淀也没被明确弃,这是重点)、**过期/弃用**(讨论过但已被取代/明确弃,列出来是让创始人知道"考虑过、为什么弃",避免重复讨论)、**不确定**(拿不准现行档到底覆盖没)。判定列留空,等创始人裁。
|
||||
|
||||
---
|
||||
|
||||
## 表 A:契约族与契约治理(8/9/10 类、防漂移门、版本演进)
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 后端数据契约-001 | **Pact 契约测试(Provider verify + Consumer stub)** —— 服务间契约靠 Pact 在 provider 端做验证、consumer 端做 stub 测试,正式阶段引入。 | 技术决策版 §7.7「服务间契约」;开发团队版 §6 联调 | 遗落 | 现行契约治理(契约总览 + engineering-conventions §5)只有"URL 版本 / 字段 additive / 后端先写 -api 前端据此定 TS"这套人工纪律,没有任何机器化的跨模块契约一致性验证手段。契约总览自己也坦白"防漂移门都不存在、是文档承诺非运行门"。Pact 正是当年为补这个缺口设计的,被整段丢了。值得捡回——它直指现行最大的契约风险:DB 镜像已实际漂移(18 vs 25)、改契约全靠自觉。 | |
|
||||
| 后端数据契约-002 | **事件 Schema Registry(Confluent 兼容)** —— telemetry/MQ 事件的 schema 正式阶段进 Schema Registry 统一管理,MVP 先用文档管。 | 技术决策版 §7.7「事件 Schema 演进」 | 遗落 | 现行 events.schema.json(第 5 类契约)+ `TelemetryEventEnum` 枚举守门人是当前真相,但"事件 schema 谁来统一登记、版本怎么强约束"在现行档里只剩"带 schema_version、新增给默认值"两条规则,没有 registry 这个长期归宿。考虑到 engineering-conventions §1.2 已经踩过"只改契约不改枚举=事件被静默 rejected"的雷,一个真正的 schema registry(契约即守门人)正是那个雷的根治方向。 | |
|
||||
| 后端数据契约-003 | **大表变更用 gh-ost / pt-online-schema-change 不锁表** —— Flyway 迁移规范里,对大表的 DDL 用在线改表工具避免锁表。 | 技术决策版 §7.6;engineering-conventions §8 已留一行 | 不确定 | engineering-conventions §8 的 Flyway 规范表里确实留了"大表变更用 gh-ost"这一行,所以它**没完全丢**;但后端/数据模型.md 的"加列纪律"只讲了 `NOT NULL DEFAULT 0`、不进唯一键,没接上"大表怎么不锁表上线"。MVP 单库小表阶段不咬人,但真上量后这是数据侧 review 必须知道的约束。列为不确定,请创始人判要不要在数据模型档里补一句指针。 | |
|
||||
| 后端数据契约-004 | **第 10 类 rt 约定是否升格 contracts/ 顶层** —— `runtime-api-2d.d.ts` 当前 additive 落在 game-runtime/src,是否升格为跨仓 contracts 是个待决位。 | 契约总览(状态列写"是否升格 contracts/ 待 6c6g 定");plan-001 U1 | 不确定 | 这条现行档**点到了**(契约总览明确标"待 6c6g 定"),所以严格说不算遗落;但它是一个被挂起、没人收口的真实待决项,放进来提醒别让它无限期悬空。 | |
|
||||
| 后端数据契约-005 | **"第 N 契约"编号轴五套互撞的收口** —— 仓里至少五套"第 N 契约"编号(跨仓第 9、生成工厂 9a-9g、渠道 9c、生成主线 8 契约 ①-⑧),数字撞、语义不撞。 | 契约总览「第几类口径收口」 | 不确定 | 这条现行档(契约总览)已经**专门收口讲清楚了**,本不该列;放进来只为提示创始人:这是一处历史欠债的现行解,若后续再新增契约编号,要回这张表登记、别再造第六套撞号。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 B:基础设施服务的设计点(MQ / 候选集缓存 / Nacos 配置键 / 多租户 / 网关)
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 后端数据契约-006 | **RocketMQ 同步刷盘 + 死信队列 + 延迟消息 + 事务消息** —— MQ 上线时的可靠性配置(同步刷盘保不丢、DLQ 兜异常、延迟消息做定时、事务消息做一致性)。 | 技术决策版 §6.5/§7.2;security-and-reliability §5.2 留一行 | 不确定 | RocketMQ 整体被定为 future-state(框架自带、MVP 未部署),现行档(SAA编排、契约总览)都标注了这个状态,所以"未部署"这件事不算丢。但**真上 MQ 时的具体可靠性形态**(同步刷盘 / DLQ / 延迟 / 事务消息这四件)只在归档长档和 security-and-reliability 表里零散留着,没进任何现行后端 canonical。等到第一个 MQ 消费者出现要落地时,这四条是必须先想清的约束。列不确定,看是否值得在数据模型或可靠性档里留一段"MQ 上线前置"。 | |
|
||||
| 后端数据契约-007 | **候选集 Redis Sorted Set + TTL 60s + cursor 分页** —— feed 候选集增长期形态 = Redis ZSET 缓存、TTL 60 秒、游标翻页。 | 技术决策版 §4.3;技术架构与模块 T-FED-02 | 过期/弃用(降级远期) | 现行 13模块.md 的 feed 卡片明确"候选集纯查 MySQL 无 Redis(增长期才上)、游标分页是桩(永远第一页)"。所以这条**有意降级**,不是遗忘——列在过期档里是让创始人知道:增长期 feed 的目标形态(ZSET+TTL60s+真游标)早设计好了,真要做时直接捡这套,别重想。 | |
|
||||
| 后端数据契约-008 | **推荐打分公式的完整信号集与权重方向** —— `Score = w1·quality + w2·freshness + w3·interaction − w4·skip − w5·error − w6·report + bonus_new + bonus_featured`,六正负信号 + 两 bonus。 | 技术决策版 §4.3;护城河复盘(实现真相栏);security-and-reliability §- | 不确定 | 现行 feed 现状是"quality 排序真 + boost 运营加权 + exposure_limit 限曝光",`sort_score = quality + boost − exposure_limit`(数据模型 §2.3)。但当年设计的**完整信号集**(freshness 衰减 / skip_rate / error_rate 硬降权 / report_rate 阈值触发人审 / 新人保底 / 精选 bonus)在现行档里只剩 boost 和 exposure_limit 两项落地、其余没沉淀成"目标排序公式"。这是 feed 推荐的核心 IP,值得在 feed 设计里留一份完整目标公式(标注哪些已落、哪些待建),否则增长期重做推荐时要从零捡信号。 | |
|
||||
| 后端数据契约-009 | **Nacos 配置键命名约定(llm.primary / creator_share / withdraw-min / point_rate / 阈值 block=0.7 review=0.4)** —— 一批关键业务参数走 Nacos/DB 配置而非硬编码,且当年给了具体键名与默认值。 | mvp 业务决策 D1/D3;security-and-reliability §1.2;变现与单位经济(部分) | 不确定 | 其中一部分**已沉淀**:`withdraw-min`(变现与单位经济)、`trade.payout-channel`、内容安全阈值 block/review(security-and-reliability §1.2)。但散落的几个键名约定——`llm.primary/secondary`、`creator_share=0.80`+`creator_share_tier`(分层结构)、`point_rate=10`——没有一个统一的"业务配置键登记表"。现行靠 `docs/内网凭据与端点.md` 管密钥、但业务可调参数(分账比例/积分单价/会员档)的键名与默认值没有单一登记处。列不确定:是否需要一张"Nacos 业务配置键登记"小表,防止同一个参数被两处用不同键名读。 | |
|
||||
| 后端数据契约-010 | **多租户 scoping 的公开读枚举风险** —— TenantBaseDO 表的 @PermitAll 公开读仍被 tenant-id 请求头 scoping,多租户开启后不可信头可枚举他租"已公开"数据,真·租户无关的公开读须 pin 租户或入 tenant.ignore-urls。 | security-and-reliability §:26;真实鉴权 review §5A | 不确定 | 这条**已经在 security-and-reliability §:26 写清楚了**,鉴权与权限.md §6 也引了那个指针。所以不算遗落。放进来只为强调:MVP 单租户(tenant.enable=false)下它休眠,一旦未来开多租户,这是个真实的越权读隐患,别因为现在不咬人就忘了它的存在。 | |
|
||||
| 后端数据契约-011 | **网关 trace_id 入口注入、全链路透传** —— trace_id 在网关入口注入并全链路透传(含生成/编译/加载/运行),调试模式贯穿全链。 | 技术决策版 §7.5;security-and-reliability §6 | 不确定 | 现行可观测性规范(security-and-reliability §6)写了"trace_id 网关入口注入、全链路透传"。但现行 MVP 是单体、网关不在请求路径上(鉴权与权限.md §7 已纠偏),所以"网关注入 trace_id"这件事在单体下由谁做、是否落地存疑。SAA 编排侧另有 trace_json 账本(契约④)。这两条 trace 链路(平台级 trace_id vs 生成域 trace_json)的关系没有在现行档里对齐过,列不确定。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 C:数据模型与表设计的设计点(审计列/状态机/字段语义/远期表)
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 后端数据契约-012 | **积分体系 point_rate=10(1 元=10 积分)用于打赏** —— pay/产品域配置默认 1 元=10 积分,打赏走积分、计入创作者收益、走同一分账口径。 | mvp 业务决策 D3「积分」 | 遗落 | 现行 trade 已建 TIP(打赏)入账的真实入口(变现与单位经济 §2),但**积分这层产品形态**——用户充积分、积分换打赏、point_rate 单价——在现行档里只剩"积分定价属产品域配置"一句(13模块.md pay 卡片),具体的 `point_rate=10` 默认值、积分→打赏→分账的链路没沉淀。pay 模块未接单体,所以它没真做;但作为已讨论的产品-数据契约设计,它是打赏闭环的一块拼图,值得在变现档里留一句"打赏的积分口径(待 pay 接入)"。 | |
|
||||
| 后端数据契约-013 | **creator_share_tier 分层分账结构(80%/75%/70%)在 DB 保留结构、值待填** —— 分账比例分小白/进阶/专业三档,MVP 统一 80%,但 DB 结构保留分层位、值后期填。 | mvp 业务决策 D3 + 复审拍板;技术架构与模块 T-TRD-01 | 不确定 | 变现与单位经济 §4.1 把分账公式收口为 R3 唯一口径(80% / 带 IP 则 55-65%+IP 15-25%),并说明"分层方向等真实数据后再定"。所以**结论层不算丢**。但 D3 明确要求"DB 分层结构保留、值后期填"这件**数据模型设计**——`game_trade_income`/账户侧是否预留了 tier 维度列——在现行数据模型.md 里看不到痕迹(trade 表只讲 share_rate 单值)。列不确定:确认一下分层结构到底有没有在表里留位,还是只活在 Nacos 配置。 | |
|
||||
| 后端数据契约-014 | **创作者实名链 game_player 预留 real_name/id_card_no AES 密文、提现前才收集** —— 实名字段加密预留,注册只收手机号,实名收集后置到提现前。 | 真实鉴权 review §5-5;数据模型 §2.5 已落 | 不确定 | 这条**已落**:数据模型 §2.5 明确 `game_player` 的 `real_name`/`id_card_no` 是 AES 密文预留、提现前才收集。所以不是遗落。放进来只为提示:"提现前收实名"这条时点约束(与支付进件/LLM 实名闸门对齐)是个跨闸门的排期约束,数据模型档写了字段、但"何时触发收集"的业务规则没明说,若后续做提现真实化要记得这条。 | |
|
||||
| 后端数据契约-015 | **per-creator token 绝不明文落 game_player + new-api AddToken 硬编码调用者 UserId 的可行性硬阻塞** —— 给每个创作者发的 new-api token 是支付工具,禁明文入库;且 new-api admin API 无法替他人铸 token(AddToken 硬编码成调用者自己 UserId),需重设计"凭证引导"流程。 | 变现与单位经济 §3/§6;newapi-billing 评审 | 不确定 | 这条**已在变现与单位经济 §6 写清楚**(含可行性硬阻塞 + 三方对账锚 trade_no UNIQUE)。不算遗落。放进来强调它是 per-creator 计量真实化的两个硬前置(安全红线 + AddToken 不可铸),被支付通道闸门阻塞中,真要做时这两条是设计起点。 | |
|
||||
| 后端数据契约-016 | **远期表/字段:渠道发布状态机表、TapTap 试玩包提审、素材授权链 game_ip_*、pay 收单 game_pay_*** —— 一批蓝图里列了、但当前没有独立迁移落地的表族。 | 技术架构与模块(T-RT-31/32、T-IP-02/03、T-PAY-*);数据模型 §0 | 不确定 | 数据模型.md 开头**已明说** pay/ip 当前没有独立 `game_pay_*`/`game_ip_*` 迁移(赋余额走 trade_grant、素材登记走 studio_material)。13模块.md 也标了渠道转换/TapTap/授权链全未建(远期)。所以这些"没建"都不算遗忘。列不确定只为留一份"远期数据表清单"的索引,免得真要做这些功能时,忘了它们当年挂在哪个 T-id 下、边界怎么定的。 | |
|
||||
| 后端数据契约-017 | **状态机口径在 DO 层不承载、非法流转由 Service 校验;金额一律 BIGINT 以分计禁浮点;幂等键四范式** —— 全平台共性数据范式。 | 数据模型 §5;engineering-conventions | 不确定(已覆盖,登记防丢) | 这套共性范式**现行档讲得很全**(数据模型 §5 + engineering-conventions §1.2/SQL 规范)。完全不算遗落。仅登记在此,作为"数据契约共性纪律已收口"的确认锚点,无需动作。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 D:鉴权权限与可靠性的设计点(SMS 滥用防护/匿名身份/反作弊/SDK 契约)
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 后端数据契约-018 | **真实短信渠道上线前的发码端点滥用防护(IP/设备限频 + 图形验证码开关)** —— 发验证码端点必然免登,切真实短信渠道前须补按 IP/设备限频与图形验证码开关(现状是上游 TODO + captcha 关闭)。 | 真实鉴权 review §R6/§9.1 执行版待办 | 遗落 | 鉴权与权限.md 把"mock 后门生产关死""创作白名单"都讲了,但**短信轰炸这个经典攻击面**——发码端点免登、现状只有按手机号频控、按 IP 的限制是上游 TODO、staging captcha 关闭——在现行鉴权档里完全没出现。这是切真实短信通道前的硬安全前置(漏了就是费用滥用/短信轰炸),且 game-module-* 的 pom 现在还没引 protection starter(限频组件)。值得捡回,在鉴权与权限.md §7 的"待办"里补一条。 | |
|
||||
| 后端数据契约-019 | **匿名身份机制:服务端签名匿名设备票据(方案 A)被弃,选纯客户端 anonId + 聚合侧异常剔除(方案 B)** —— anonId 当前纯前端 localStorage 随机串、可任意伪造;两个机制选项,种子期选了 B。 | 真实鉴权 review §5A/§9-7 拍板 | 过期/弃用 | 创始人 2026-06-10 拍板选 B(纯客户端 anonId + 聚合侧剔除),A(服务端签名票据,即 glossary 原"匿名 Token"意向)被弃。鉴权与权限.md §6 现在写的就是 B 这套(匿名 @PermitAll + anonId 透传)。列在过期档里是让创始人知道:A 方案(身份可信、可限频可撤销)被有意识地放弃了,代价是 anonId 不可信、靠事后剔除兜底——如果将来匿名刷量/操纵推荐成真问题,A 是早设计好的升级路径。 | |
|
||||
| 后端数据契约-020 | **匿名伪造事件可操纵 quality_score 推荐与广告分账的防刷归属(telemetry 聚合侧剔除 + ad/compliance 反作弊)** —— 伪造匿名事件直接喂 quality_score→feed 排序、并后接 trade 分账,防刷责任 owner 要先立。 | 真实鉴权 review §5A;技术架构与模块 §2 补登;13模块.md ad 卡片广告反作弊补登 | 不确定 | ad 侧的反作弊(幂等键 traceId + IP 限流 + AnomalyFilterService 剔除桩)**已在 13模块.md ad 卡片补登**,且明确"真接广告联盟前须升级为正式反作弊项"。telemetry 聚合侧的 anonId/IP 异常剔除桩也在鉴权 review 里立了 owner=telemetry。所以**归属已立、桩已有**,不算丢。放进来强调:这两处剔除目前都是桩,是放量/接广告前必须硬化的真实约束(伪造事件能操纵真金分成),且 telemetry 侧的剔除现行档(数据模型/13模块 telemetry 卡片)没单独点名,容易被当成已完成。 | |
|
||||
| 后端数据契约-021 | **生成成功→写版本+扣积分的分布式一致性补偿(标记版本待支付)** —— aigc 生成成功后扣积分,扣失败则补偿标记"版本待支付"。 | 技术决策版 §7.3;security-and-reliability §4 | 过期/弃用(前提变了) | security-and-reliability §4 仍留着这条补偿设计。但"生成扣积分"这件事的前提是 pay 收单/积分体系上线,而现行生成主线(便宜模型 + harness 门)和 pay 未接单体的现状下,"生成扣积分"的链路不存在。列在过期档:这套"本地事务写版本 + MQ 通知扣积分 + 失败补偿"的范式本身是对的(和 M4 的资金一致性红线同源),但具体场景(扣积分)要等积分/pay 真实化才激活,别误以为现在就该有。 | |
|
||||
| 后端数据契约-022 | **SDK 第 3 类契约的体积预算与降级铁律(Core<8KB / 各 Plugin<5KB / 不返 Promise / 5s 超时 fallback / semver 只增不改签名)** —— WanxiangGameSDK 作为第 3 类契约的硬约束。 | 技术决策版 §3.4;engineering-conventions §3;security-and-reliability §7 | 不确定(已覆盖,登记防丢) | 这套**现行档讲得很全**(engineering-conventions §3 + security-and-reliability §7 SDK 降级铁律)。完全不算遗落。仅登记为"SDK 契约纪律已收口"的确认锚点。注:它是第 3 类契约(sdk-interface.d.ts),与渠道线的 SDK adapter(9g 遥测字段)是两套面,别混。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 E:生成域数据契约的设计点(源项目 keystone / 九门 / 裁决工件)
|
||||
|
||||
> 说明:生成域设计链正处于架构演进过渡期(agent-specs 顶层活档 + 架构/生成引擎/ 域树并存),其契约(①-⑧、game-design/verdict 工件)**大体已沉淀**。下面只列几条历史讨论里有、但现行档容易读漏的约束。
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 后端数据契约-023 | **回调一次事务必须三表齐写(game_aigc_task / game_version / game_runtime_package),putManifest 未命中行须显式失败禁带病 succeeded** —— 落包写入链的硬约束,缺建 game_runtime_package 行则预览取包必走 demo 兜底。 | agent 化生成 QA 闭环 review §4 接线②(Z1/Z2 终审) | 不确定 | 这是当年终审揪出的一个真实致命断点(全仓无生产代码插 game_runtime_package、putManifest 未命中静默 log.warn 跳过)。现行落包链已实现(数据模型 §2.2 描述了 runtime_build→runtime_package 回写),但**"三表同事务齐写 + putManifest 命中失败"这条断言级约束**有没有作为红线留在现行档里存疑。它是"半假门"(demo 兜底掩盖真断链)的根因之一,值得确认现行落包链是否还守这条。 | |
|
||||
| 后端数据契约-024 | **GameConfig 文案字段入库前白名单字符集+长度校验、渲染侧转义、禁 innerHTML/eval(LLM 产物消毒)** —— 生成产物里的 title/label/theme 等文案字段的消毒规则。 | 技术决策版 §4.2;security-and-reliability §1.1 | 不确定(已覆盖,但注入面已扩大) | security-and-reliability §1.1 **已写**这条,且已注明"2026-06-12 主线改 agent 写码后,注入面从配置字符串扩大为生成代码本体"。所以消毒规则不算丢。放进来提示一个演进顾虑:文案消毒规则不变,但代码面的安全(生成代码只许调插件公开 API、过验证门才出厂)是另一套边界,两者别混为一谈——这点 §1.1 已点破,登记确认。 | |
|
||||
| 后端数据契约-025 | **裁决工件 Verdict 预留 completed:false 语义、playReport 必校 package checksum 防 demo 兜底假阳性** —— QA 闭环裁决契约的两个前瞻设计(判负契约零改动 / 兜底包判 infra_fail 不算通过)。 | agent 化生成 QA 闭环 review §3.2/§3.3 | 不确定 | game-design.schema.json / verdict.schema.json 作为 ACTIVE 契约在契约总览里登记了。但这两条**前瞻约束**——Verdict 的 `completed:false` 为 dodge 类判负预留(契约零改动)、PlayReport 必须校验所玩包 checksum 与落包一致(64 位 '0' checksum 的兜底包判 infra_fail)——是防"假阳性通过"的关键,容易在读现行契约总览时漏掉。列不确定:确认这两条是否还在现行裁决实现里守着。 | |
|
||||
|
||||
---
|
||||
|
||||
## 一句话小结(给主代理)
|
||||
|
||||
本领域历史设计点回收后,**真正的遗落只有少数几条**——现行策展层(尤其 2026-06-20 域化重构后的后端域 + 运营域 + .agents)其实把绝大多数历史设计都沉淀住了(分账公式、渠道 9c/9g、ClickHouse/Sentinel/幂等四场景、SDK 降级铁律、匿名身份机制都在)。最该捡回的集中在三处:**契约治理的机器化手段**(Pact 契约测试、事件 Schema Registry——现行只有人工纪律、DB 镜像已实际漂移)、**短信发码端点的滥用防护**(切真实短信前的硬安全前置,现行鉴权档完全没有)、以及**feed 推荐的完整目标信号公式**(当年六信号两 bonus,现在只落了 boost+exposure_limit 两项)。其余多为"有意降级远期"或"现行已覆盖、登记防丢"。
|
||||
@ -1,64 +0,0 @@
|
||||
# 后端数据契约 · 第二轮:复核 + 查漏
|
||||
|
||||
> 这是对第一轮《后端数据契约-历史设计点.md》的复核与补充。第一轮已经把这个领域翻了一遍旧账,这一轮做三件事:一是抽验它的出处真不真、分类准不准,把判错的标出来;二是第一轮交稿之后又落地了一批新设计稿(数据飞轮、审核台运营、观测体系、k8s 迁移,以及更早的五份 P0),看第一轮标"遗落/不确定"的条目里哪些现在已经被这些新档接住了;三是再扫一遍历史源,补第一轮漏挖的、尤其是卡在两个域交界处的设计点。
|
||||
>
|
||||
> **只产出三类**:改判的、被新档覆盖的、新挖的。第一轮已经判对的条目不重抄。判定列照旧留空给创始人。
|
||||
|
||||
---
|
||||
|
||||
## 一、复核勘误表:第一轮判错或判得不准的条目
|
||||
|
||||
第一轮整体是扎实的——出处抽验下来,关键几条(001 Pact、002 Schema Registry、008 推荐公式、018 短信防护)的原文都对得上,没有编造或张冠李戴。但有一处实打实的判错,根子在第一轮圈定"现行档"范围时漏了一份关键的 canonical。
|
||||
|
||||
第一轮在开头声明它比对的现行档是:`后端/`(README/数据模型/鉴权)+ `架构/13模块.md` + `架构/契约总览.md` + `生成引擎/` + `运营/` + `.agents/`。**这份清单漏掉了 `架构/README.md`**——而这恰恰是架构域的总纲 canonical,feed 推荐引擎、沙箱安全红线、数据流主线都写在里头。漏读它直接导致了下面 008、007、024 三条的误判。
|
||||
|
||||
| ID | 原判 | 新判 | 为什么 |
|
||||
|---|---|---|---|
|
||||
| 后端数据契约-008 | 遗落(称完整推荐公式只剩归档,现行只落了 boost + exposure_limit) | **现行已覆盖** | `架构/README.md` §7(339–347 行)**逐字写着那条完整公式**:`Score = w1·quality + w2·freshness + w3·interaction − w4·skip − w5·error − w6·report + bonus_new_creator + bonus_featured`,还补了"error_rate 是硬降权、report_rate 超阈值触发人审"的语义。第一轮说"六信号两 bonus 没沉淀成目标公式"是因为没读到这份档。这条不是遗落,是已在现行 canon。判错的是事实,不是判断口径。 |
|
||||
| 后端数据契约-007 | 过期/弃用(降级远期,称只在归档,现行 13模块说 feed 无 Redis) | **现行已覆盖(目标形态已成文)** | 紧挨着上面那条公式,`架构/README.md` §7(347 行)同一段就写了"候选集存在 Redis Sorted Set,TTL 60s,用 cursor 分页(MVP 也可直查 MySQL,Redis 缓存是增长期形态)"。所以"增长期目标 = ZSET+TTL60s+真游标"这件事不是只活在归档、要从零捡——它已经作为增长期目标形态写进现行总纲。第一轮的实质判断(有意降级远期)方向没错,但"只在归档长档零散留着"这个前提是错的。 |
|
||||
| 后端数据契约-024 | 不确定·已覆盖(指向 security-and-reliability §1.1) | **已覆盖,出处补一处** | GameConfig 文案消毒(白名单字符集+长度校验、渲染转义、禁 innerHTML/eval)除了 §1.1,**`架构/README.md` §6(328 行)也写了**一遍("LLM 产物消毒")。结论不变(已覆盖),仅补一个出处,说明这条在现行档里其实有两个落点、更稳。 |
|
||||
|
||||
除这三条外,第一轮的出处与分类都站得住:001/002 确实是技术决策版 §7.7 的原文、是真遗落(现行契约治理只有人工纪律);018 短信防护抽验下来现行鉴权档里 send-sms-code 确实只标了 `@PermitAll`、IP 限频/captcha 全无,真遗落;019 匿名身份选 B 弃 A、010 多租户公开读、017/022 共性纪律已收口——这些都判对了,不动。
|
||||
|
||||
---
|
||||
|
||||
## 二、第一轮标"遗落/不确定",现已被新档覆盖的条目
|
||||
|
||||
第一轮交稿后落地的新档,接住了下面几条。逐条说被哪份档、覆盖到什么程度。
|
||||
|
||||
| 第一轮 ID | 被哪份新档覆盖 | 覆盖程度 |
|
||||
|---|---|---|
|
||||
| 后端数据契约-008(推荐完整信号公式) | `架构/README.md` §7 + `生成引擎/数据飞轮.md` §3.3 | **完全覆盖**。目标公式本体在 §7;数据飞轮的"收益回流"那条飞轮又把"推荐排序校准——哪些游戏更容易留住玩家"列成语料下游消费 E2,等于给这条公式的增长期演进(信号怎么从数据回流里校准权重)补了去处。第一轮担心的"重做推荐要从零捡信号"已不成立。 |
|
||||
| 后端数据契约-011(网关 trace_id 入口注入 + 平台 trace_id vs 生成域 trace_json 两条链关系没对齐) | `运维/观测体系.md` §3.2 / §6 | **覆盖且把第一轮的疑点正面回答了**。观测体系明确点出"双 traceId 问题"(yudao `TraceFilter` 回写的小写 `trace-id` 来自 SkyWalking,OTel 走 W3C `traceparent`,两套不打通就对不上),给了统一方向(把 `TraceFilter` 取数源换成 OTel span 的 traceId),并把生成域的 `trace_json`(九门轨迹账本)接成 `gen_gate_fail` 指标的数据源——平台 trace 与生成域 trace_json 的关系不再悬空。第一轮说"这两条 trace 链路没在现行档对齐过",现在对齐了(虽然具体改法标"待核",但已是有主的待核项,不是无人认领的缺口)。 |
|
||||
| 后端数据契约-020(伪造匿名事件操纵 quality_score / 分账的防刷,处置联动 feed) | `运营/审核台运营.md` §3.5(部分) | **部分覆盖**。审核台把"违规处置真联动 feed 曝光/下架 + 封号连带下架 + 创作者信用扣分"这条处置链补全了(封号置 player DISABLE、按 creatorId 批量下架、feed 降权 -api 待建),这是 020 里"举报降权/封禁联动"那一半。但 020 的另一半——**telemetry 聚合侧的 anonId/IP 异常事件剔除桩**——审核台没碰(它管的是内容审核与处置,不是遥测聚合)。所以 020 里"telemetry 侧剔除桩待硬化、现行档没单独点名"这条仍站立,没被覆盖。归档在此说明:020 覆盖了一半,剩遥测剔除那半待 telemetry 域接。 |
|
||||
|
||||
> 一处需要点明的关系:被覆盖的 008/011 里,008 严格说不是被"新落地的 Tier-2 设计稿"覆盖,而是第一轮**本就漏读了** `架构/README.md` 这份既有 canon(见上节勘误)。这里把它一并列进"已覆盖",是为了让创始人看到完整结论——不管是漏读还是新档接住,这条现在的事实就是"现行已覆盖、无需捡回"。011 才是真正被新落地的观测体系档接住的。
|
||||
|
||||
其余第一轮标"不确定·已覆盖、登记防丢"的条目(004/005/010/014/015/016/017/022/023/024/025),本轮抽验后维持原判:它们要么现行档已写清(如 023 落包链 checksum 校验在 `架构/产物执行沙箱.md` §"取包验包"有完整实现描述、025 的 demo 兜底判 infra_fail 也在那份档讨论过),要么是被外部闸门挂起的真实待决项(015/016/021)。这些不重列。
|
||||
|
||||
---
|
||||
|
||||
## 三、查漏补充清单:第一轮漏挖的设计点
|
||||
|
||||
再扫历史源 + 比对新档后,补出下面几条。重点在两个域交界处——第一轮表 A–E 框的是"已有契约族/已有表/已有共性纪律"的视角,而新落地的数据飞轮档暴露出**几个为了新机制要新开的后端契约面/新表**,这些当年没单独讨论过、第一轮自然也没挖;另有一两条是跨域接缝上、第一轮和别的域 agent 都以为对方会管而都漏的。编号接第一轮续(026 起)。
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 后端数据契约-026 | **`game_trade_income` 缺 `game_id` 列,按游戏粒度的成本/收益归因断在这里** —— 入账流水只有 source/source_ref/gross/share_rate/net,要把分账金额追到具体哪款游戏,得先把 game_id 透传进整条入账链(契约 ad.yaml 加字段 → DTO 加 gameId → ALTER 加列 → recordIncome 透传,W4 四步链缺一即断)。 | `生成引擎/数据飞轮.md` §1/§3.3;`运营/变现与单位经济.md` "按游戏粒度成本/收益埋点";`后端/数据模型.md`(实证 trade_income 无 game_id) | 遗落(已有新档点到、但作为后端数据契约缺口第一轮没单列) | 这是个真实的后端数据模型缺口:`game_trade_income` 现在按 source_ref 串到广告单/打赏单,但串不到游戏。它同时卡着两件事——按游戏算单位经济(W4)、收益回流语料的 join 键。第一轮表 C(数据模型)逐张表看过 trade,却没把"缺 game_id 列"这条挑出来。数据飞轮档现在把它点明了,值得作为一条独立的后端契约待补项登记(它要改 ad.yaml 契约 + DB ALTER,是 contract-first 动作,不是顺手加列)。 | |
|
||||
| 后端数据契约-027 | **`game_lineage_edge` 跨游戏血缘边表 + 源 schema `lineage` 顶层字段,是同款创作的全新数据契约** —— 现行契约/库里跨游戏血缘字段零命中(`retry_of` 只记同款游戏内重生成、`base_version_id` 只记同款内版本血缘),要支撑"做同款"得新开一张血缘边表(child/parent/origin/depth/status/child_creator_id + 去重聚合索引)+ 源项目 schema 加可选 `lineage` 对象 + `/studio/create` 加 `remixFrom` 入参 + `remix_click/remix_submit` 两个漏斗事件。 | `生成引擎/数据飞轮.md` §3.1(完整 contract-first 清单) | 不确定(新档已设计、但是全新待落的跨端契约面,登记其落地状态) | 第一轮通篇没提血缘/同款(检索 lineage/血缘/remix 零命中),因为它交稿时这套设计还没落档。数据飞轮把它从口号补成了带 schema 的设计,新增物横跨五个契约面(源 schema / studio.yaml / Flyway 新表 / events.schema / VO-DTO)。登记在此,提醒它是一组**尚未落库的新契约**(P-FED-12 升 P0 的流程动作还挂在数据飞轮文末开放问题),别因为有了设计稿就当已建。 | |
|
||||
| 后端数据契约-028 | **trade 收入来源缺 `ASSET` 枚举 + 资产采购单表未建,资产市场分账的后端契约面是空的** —— `game_trade_income.source` 现在只有 1=AD/2=TIP,资产市场"买素材→素材作者分成"要复用 recordIncome 入账原语,得先把 source enum 扩出 ASSET(trade.yaml + DO 注释)、新建采购单/授权单表(买家/素材/作者/成交价/授权范围/状态,带自己的幂等键)作 source_ref,且退款撤权的冲正口径要先定。 | `生成引擎/数据飞轮.md` §3.2 | 不确定(新档已划边界、但整条卡支付,登记后端契约缺口) | 第一轮表 D 谈过 SDK 契约、谈过 per-creator token,但没碰资产市场这条线的 trade 侧契约缺口。数据飞轮把它划清了:入账原语能复用,但 source 枚举、采购单表、退款冲正口径三样都得新建/新定,且整条物理上排在真实支付收单之后。登记为后端契约的远期待补项(钱那半被日历闸门卡死,只读半可先行)。 | |
|
||||
| 后端数据契约-029 | **`game_telemetry_game_stat` 无次留/留存字段,留存信号口径未定** —— 聚合表只有 play/end/complete/duration/like/favorite,要拿"次留/留存"得先定义留存口径并新增聚合字段;这是收益回流语料"线上结果标签"的另一个待补 join 前置。 | `生成引擎/数据飞轮.md` §1/§3.3;`后端/数据模型.md`(实证 game_stat 字段) | 遗落(已有新档点到、作为遥测数据模型缺口第一轮没单列) | 和 026 同源但落点不同:026 缺的是 trade 侧的 game_id 连接键,029 缺的是 telemetry 侧的留存口径。第一轮表 C 看过 telemetry 聚合表,没把"无留存字段"挑出来。它卡着收益回流(没留存标签语料训不出"什么游戏留得住人")和未来的推荐 freshness/留存信号。登记为遥测数据模型的一条待补项(要先定义口径再加聚合字段,不是单纯加列)。 | |
|
||||
| 后端数据契约-030 | **`game_compliance_gate_result` 补记锁风档位/命中 IP:升列 vs 写 details JSON 的取舍** —— 锁风三档裁决要能回答"为什么这条走了严格档",但 GateResultDO 现只有 verdict/rating/details/traceId,没有 lock_strength/ip_id 列;MVP 走写 details JSON(不改表),确有按档位做报表需求才升列(Flyway 加两列 nullable)。 | `运营/审核台运营.md` §3.3 + 文末开放问题 3 | 不确定(新档已给取舍、登记为待创始人拍的后端数据模型选择) | 这是审核台档暴露的一个具体的后端数据模型取舍,第一轮没覆盖(它当时没有审核台这条线的设计)。两条路都正确(JSON 软扩 vs 升列),取决于要不要按档位聚合审核量做报表。登记在此,因为它是个"contract-first 升不升列"的真实待决项,且和 030/credit_score 那条迁移要错开版本号。 | |
|
||||
| 后端数据契约-031 | **`game_community_level` 加 `credit_score` vs 独立信用扣分台账:创作者信用的数据落点未定** —— 创作者信用要把单次处置转成长期约束(信用低→拉严档+降基线曝光),但等级引擎 LevelDO 只有 level/publishedCount,无 credit_score,CommunityNotifyApi 无扣分端点;落点二选一(等级表加列 / 独立台账),且跨模块扣分端点要带幂等键。 | `运营/审核台运营.md` §3.5 + 文末开放问题 2 | 不确定(新档已给两条路、登记为待拍的后端数据模型 + 跨模块契约选择) | 同 030,审核台暴露的后端数据落点取舍,第一轮未覆盖。它牵涉新表/加列 + 新跨模块 -api(带幂等键)+ 误伤治理,工作量与风险都不小,审核台已把它摆进开放问题。登记在此作为后端侧的待决数据契约项(信用台账若落库,版本号要和 030 那条错开)。 | |
|
||||
| 后端数据契约-032 | **封号连带下架 + `validateCreator` 查封禁态:封账号的级联是零实现** —— 现在封一个创作者账号只写 `game_user_ban` 台账,既不置 `game_player.status=DISABLE`、也不遍历下架其全部已发布内容,而 `validateCreator` 又不查 ban 表,结果封号拦不住本人继续创作、其旧内容仍在 feed。要补"封号→置 player DISABLE(或 validateCreator 多查 ban)+ 按 creatorId 批量 offlineRank"两条断链。 | `运营/审核台运营.md` §2/§3.5;`后端/鉴权与权限.md` §5(validateCreator 现状) | 遗落(跨鉴权×合规交界,两域都以为对方管而都漏) | 这是个典型的跨域接缝漏挖点:它一头在鉴权域(validateCreator 准入)、一头在合规域(封禁处置),第一轮的鉴权视角(表 D)谈了 mock 后门关死、创作白名单,却没谈"封号后准入链是否真拦得住";而它的另一头在 compliance,容易被当成合规域的事。审核台档现在把这条断链点明并给了补法(推荐封禁时同步置 player DISABLE,复用既有禁用态判定)。它是个真实的越权/绕管缺陷(封了号照样能创作、旧内容照样在流),值得作为鉴权×合规交界的硬约束登记。 | |
|
||||
| 后端数据契约-033 | **feed 降权跨模块 `-api` 是上一波"刻意没建"的孤儿 seam,处置自动降权要不要现在补** —— compliance 现在能调 feed 的只有 `offlineRank`(下架),没有降权接缝;`setExposureLimit` 只是 admin 管理端 HTTP 端点、不在跨模块 `FeedApi` 契约上,且封禁联动代码注释明写"P1 本波不生效——不建 FeedDownweightApi 孤儿 seam"。 | `运营/审核台运营.md` §3.5 + 文末开放问题 1;`运营/审核台运营.md` §2(FeedApi 现状) | 不确定(有意未建的契约面,登记为待拍的"要不要现在补 -api") | 第一轮表 B 谈过 feed 候选集形态(007),但没碰 feed 对外契约面这层——compliance 处置要联动 feed 降权时,跨模块接缝是缺的,而且是**上一波有意识地不建**(避免孤儿 seam)。这条状态特殊:它不是"忘了建",是"判断过、暂不建"。审核台现在把"要不要补降权 -api"重新摆出来(补 -api 让自动降权成立 / 或统一走下架+处置台账组合)。登记在此,因为它是个被有意挂起、现在又被审核台需求重新激活的契约面待决项。 | |
|
||||
|
||||
> 一条不补的说明:防沉迷/青少年模式的数据模型(实名认证触发、时长/宵禁台账、未成年充值限制)看似是个跨域缺口,但本轮核实后**确认它是已决定的"延后",不是遗落**——`运营/合规闸门.md` 把它列为法定闸门,并通过"双层定性(邀请制内测 + 渠道代管实名/防沉迷)"的战略裁决主动规避了自有端的这套义务,wave3 review 也明确把 T-CMP-36/37 实名/防沉迷标为"延后"。所以这条不进补充清单(现行已有明确弃/延的决定,补它是噪音)。
|
||||
|
||||
---
|
||||
|
||||
## 四、给创始人的一句话
|
||||
|
||||
第一轮整体可信,只有一处实打实的判错:**008 推荐完整公式(连带 007 候选集形态、024 消毒)其实早写在 `架构/README.md` §7/§6 里,第一轮圈现行档范围时漏了这份总纲 canonical,把已覆盖的误判成了遗落/降级**——建议第一轮的现行档比对范围补上 `架构/README.md`。被新档接住的主要是 011(观测体系把双 traceId 和 trace_json 接线讲透了)和 008(数据飞轮补了推荐校准的去处),020 只被接了一半(处置联动有了、遥测剔除桩还悬)。
|
||||
|
||||
真正值得创始人看的是**查漏挖出的 8 条**,集中在一个第一轮没料到的方向:数据飞轮和审核台这两份新设计稿,为了新机制要**新开一批后端契约面/新表**,而其中几条暴露的是现有表的硬缺口——`trade_income 缺 game_id`(026)和 `game_stat 缺留存字段`(029)这两个连接键不补,按游戏算钱和收益回流语料都是断的;封号级联零实现(032)是鉴权×合规交界上一个真实的绕管缺陷(封了号还能创作)。这三条(026/029/032)是确定性的缺口,不是取舍;其余(027/028/030/031/033)是新机制带来的、待创始人拍的后端契约设计选择。
|
||||
@ -1,97 +0,0 @@
|
||||
---
|
||||
date: 2026-06-21
|
||||
topic: 生成引擎 · 历史设计点穷尽式回收
|
||||
status: 回收清单(trace 层) · 判定列留空待创始人裁
|
||||
maintainer: 架构史官(一次性回收任务)
|
||||
---
|
||||
|
||||
# 生成引擎 · 历史设计点回收清单
|
||||
|
||||
## 这份清单是什么
|
||||
|
||||
绘境AI 的生成引擎子树(`docs/architecture/架构/生成引擎/`)经过多轮策展重构,现行档已经相当完整、相当自省——大部分真正的债和遗留,现行档自己就用"follow-up / backlog / 待办"显式挂着。但生成主线从 2026-06-08 一路演进到今天,中间在 brainstorm、plan、agent-specs(含 _archive)、早期 memorys、以及四份很长的旧架构文档里,讨论过、拍过、又被后来的 pivot 冲掉的设计点 / 想法 / 顾虑 / 约束,不全都沉淀进了现行档。这份清单就是把这些"历史上想过、但现行 docs/architecture 没讲到"的点逐条挖出来,目的只有一个:**不让历史上的好想法、深思过的顾虑、本该考虑的约束,因为一次次 reframe 而被悄悄丢掉。**
|
||||
|
||||
每条都标了状态:**遗落**(被讨论过、是个好想法或一条该考虑的约束,现行档没讲、也没被明确弃)、**过期/弃用**(历史里讨论过但已被明确取代或废除,列出来是让创始人知道它被考虑过、为什么弃,免得重复讨论)、**不确定**(拿不准现行档到底覆盖没)。判定列留空,给创始人圈点。
|
||||
|
||||
## 我扫了哪些历史文档
|
||||
|
||||
- **现行基准(先读清楚"已沉淀了什么",这些不列)**:`docs/architecture/架构/生成引擎/` 全子树 14 份(README / SAA编排 / 固定游戏架构 / 引擎与运行时 / prompt治理 / OpenGame对照 / WG1基准 / 验收门-W-G1 / 开闸接线 / 自治富游戏引擎 / agentic集成架构 / tier2实现详设 / 设计合理性裁决 / SAA能力API-dossier);以及 `.agents/knowledge/tech-decisions.md`、`.agents/skills/{cheap-model-game-generation,saa-graph-orchestration,ai-generation-pipeline}.md`。
|
||||
- **历史/留痕(从这里挖)**:`docs/brainstorms/`(游戏生成意图清单-草案、tier1-runtime-constraints、生成失败根因分析)、`docs/agent-specs/`(游戏生成系统总体架构-review HJ-GEN-001、生成主线-对话生成修改素材-review、生成主线-游戏生命周期项目管理-review、生成引擎主线-传承与演进-review、产品开发路线图-review、架构错误根因复盘-report)、`docs/agent-specs/_archive/`(OpenGame蓝图补缺-review、agentic基建框架选型-review、SAA-AgentScope-spike、python-to-SAA-migration-design、模型评估矩阵、generation-spike、自研偏误审计、agent-loop-v1 orchestrator/ideas)、`docs/memorys/`(技术护城河复盘、prefix-cache-preflight)、`docs/architecture/_archive/`(系统概要设计 投资人/技术决策/开发团队三版 + 技术架构与模块)。
|
||||
|
||||
> **一句话感受**:现行档已经把"工程债"挖得很透,这次回收的大头不是工程债,而是 **HJ-GEN-001 意图基线 29 条里那些产品级机制**(资产库 / 资产市场 / remix 飞轮 / 数据飞轮回流 / 商业化就绪多维评分),以及几条早期讨论过、后被简化掉的工程兜底(best-of-N、prompt-hash 结果缓存、生成产物降级到纯确定性模板)。它们大多不是"现行档说错了",而是"现行档把镜头收窄到 Tier0 当下产线后,没再带上它们"。
|
||||
|
||||
---
|
||||
|
||||
## 表一 · 创作侧产品机制(意图基线里讨论很透、现行生成引擎档基本没带)
|
||||
|
||||
来源主要是 `游戏生成系统意图清单-草案`(F1-F5 + 29 条定稿意图,创始人 2026-06-12 全采纳冻结)与 `游戏生成系统总体架构-review`(HJ-GEN-001 终审版)。这一批是这次回收最该看的——它们是创始人亲自拍过"all 全采纳"的意图,后来生成主线收窄到"把 Tier0 一句话产线焊稳",这些创作侧机制没被废、但也没进现行架构档。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 生成引擎-001 | **对话式生成 + 智能确认目标**:系统分析输入→清晰直通、模糊才弹确认卡(`/studio/analyze` 出 `{parsedGoal, needsConfirm, clarifyQuestions[]}`,结果用显式 `confirmedGoal` 携带无隐藏共享态),而非每次都打断或永远不确认 | 对话生成修改素材-review D2;生命周期-review C6;意图基线 F4 | 遗落 | 这是创始人口径"真创作能力"的一半("一句话快"与"确认目标准"兼顾)。现行生成引擎子树只讲"一句话→生成",`analyze`/智能确认这条交互纵切在生成引擎档里完全没有 SoT(只散在 agent-specs review,状态是 execution 前) | |
|
||||
| 生成引擎-002 | **六类素材驱动生成(assetContext)**:用户上传/选用 图元/角色/特效/场景/界面/音乐 六类素材透传进生成上下文(图/视觉走多模态、音乐/脚本作结构化上下文),驱动生成而非只凭一句话 | 对话生成修改素材-review D1/D5;生命周期-review C5;意图基线 F3 | 遗落 | "素材驱动创作"是创始人明确卖点。现行档反复讲"engineBundle / 六类资产规格 assetSpec"是生成产物侧,但"用户上传六类素材→透传进生成输入"这条创作入口在生成引擎档无 SoT | |
|
||||
| 生成引擎-003 | **创作者个人资产库 → 资产市场(GP6/P5)**:上传与生成的资产沉淀为创作者个人资产库,跨游戏复用、可版本化、权利链清晰(上传授权声明 / AI 生成归属),长期通向可授权可订阅的资产市场 | 意图基线 GP6/P5/XP4;HJ-GEN-001 §6 W-G3 资产生命周期 | 遗落 | 这是护城河"资产沉淀层"的工程落点,创始人采纳过。现行生成引擎档只字未提资产库/复用/血缘生命周期;它被路线图-review Phase 4 列为"v2.0 愿景"但没有任何设计沉淀 | |
|
||||
| 生成引擎-004 | **玩家→创作者 remix 飞轮(GP10/P9)**:玩家对 feed 内游戏一键"做一个类似的 / 换我的角色主题",带溯源链(9f 血缘),把玩家流量导回创作供给 | 意图基线 GP10/P9/XP6;HJ-GEN-001 §6 W-G3 remix 入口 + Q6 派生授权 | 遗落 | 创始人采纳的"网络效应核心飞轮"。现行生成引擎档零提 remix。它直接关系"玩与造互相转化"这条护城河叙事,且涉及派生授权法务口径(挂律所通道),值得显式记一笔免得忘 | |
|
||||
| 生成引擎-005 | **数据飞轮:生成全量数据 + 运营收益数据回流(GC10/C10)**:把生成的输入/中间产物/评估结果/上线游玩数据按统一 schema 归档为"训练与评估语料"(难度模型 / 质量分类器 / 推荐特征),回流模板评分 / 推荐排序 / 未来自训小模型——学的是"生成什么更容易赚钱" | 意图基线 GC10/C10/XC9;HJ-GEN-001 §6 数据采集即埋 | 遗落 | 这是"数据护城河"的工程落点。现行档有"进化语料半自动萃取品类模板"(设计合理性裁决 改动六),但那只覆盖"生成侧自我增强",**收益数据回流 + 训练自有小模型语料**这一更宽的飞轮没被带上。GC10 是创始人采纳意图,不该只剩半条 | |
|
||||
| 生成引擎-006 | **商业化就绪评分(多维 + 阻断动作)(D11/GP3/XP5)**:发布前出多维评分——可玩性 / 首局30秒 / 广告位有效性 / 版权风险 / 性能 / 审核预测,**每维带阈值与阻断动作**(可玩/首局/性能不过=不交付;版权高=阻断进 HITL、中=人审;广告位无效=可交付但禁开广告;审核预测低=转人审队列不自动拒) | HJ-GEN-001 D11/§9;意图基线 GP3+XP5 | 不确定 | 现行 D11 就绪评分(验收门-W-G1)只有 playability/firstPlay/stability/efficiency 四维 + 一个 0-100 分,**没有广告适配 / 版权风险 / 审核预测这三维,也没有"评分是门(带阻断动作)而非展示"的语义**。HJ-GEN-001 评审专门强调过"评分对象必须是门而非展示"——这条强约束在现行档丢了。判它是"已收窄"还是"待补",请创始人定 | |
|
||||
| 生成引擎-007 | **预算即产品 + 第一笔收益激活(GP7)**:每级生成预算对用户透明(积分/档位决定可用级别与额度),并明确引导"生成→发布→第一笔广告收益"激活路径 | 意图基线 GP7/P6+XP3 | 遗落 | 现行档讲了成本闸(¥0.15/款工程门)和 D12 控制平面的配额,但"预算对用户透明 / 收益激活路径引导"这条产品面没在生成引擎档落。它是订阅+广告两条收入线的创作侧入口 | |
|
||||
| 生成引擎-008 | **创作侧时延 SLO 作产品承诺(GP1)**:每级生成给用户明确时延承诺(L1≤30s/L2分钟级/L3小时级带阶段进度),对话调整一轮短时延可感知;迭代速度=创作留存第一驱动 | 意图基线 GP1/P1 | 不确定 | 现行档有 L1 P75≤30s 的工程门(README §8 三级表),但"作为对用户的产品承诺 + 对话调整一轮的可感知时延 + L2/L3 阶段进度可见"这条产品语义弱。L3 蓝图冻结后这条只剩工程数字,产品承诺面没了 | |
|
||||
|
||||
---
|
||||
|
||||
## 表二 · 生成工厂工程机制(HJ-GEN-001 拍过、现行档收窄掉或只剩骨架)
|
||||
|
||||
来源主要是 `游戏生成系统总体架构-review`(HJ-GEN-001)、`OpenGame蓝图补缺-review`、`生成失败根因分析`、`python-to-SAA-migration-design`。这一批是工程侧:有些是 HJ-GEN-001 设计过的机制被现行 Tier0 产线简化掉,有些是早期讨论过的兜底/优化没进现行档。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 生成引擎-009 | **best-of-N 多候选并行生成**:同一 brief 跑 K 个候选取最优(需先重构 dispatcher 解"整图串行"——`SaaGraphDispatcher` 单线程+Semaphore(1) 包住整条 graph.invoke、固定端口致 K 候选无法并行);评审警示 K 候选相关性致上界<94%、墙钟 K×3.5-16min、成本要对账 | 生成失败根因分析 §4④;SAA-dossier(U7) | 遗落 | 现行档零提 best-of-N。它是抬成功率的一条直接杠杆(尤其在 60% 实测基线下),但被列为"次要"后就没进任何现行档。连带"整图串行阻塞并行"这条架构约束也只在 trace 层,值得记 | |
|
||||
| 生成引擎-010 | **prompt-hash 结果缓存(免重复烧 LLM)**:相同 prompt hash 命中即跳过 LLM 调用直接复用产物 + 免计费;同 prompt 哈希缓存命中也用于 D12 防刷(命中免计费 + 频控) | HJ-GEN-001 §2.1 计费/防刷;技术决策版 §7.10;ai-generation-pipeline §9 | 遗落 | 现行档讲的是**三段式前缀缓存**(省 input token),那是另一回事。**整个生成产物按 prompt-hash 结果缓存**(命中直接复用整款游戏、零 LLM)是早期反复提的省钱+防刷机制,现行生成引擎档没有 | |
|
||||
| 生成引擎-011 | **L1 确定性 fallback 生成器(LLM 挂了仍出可玩)**:new-api/LLM 故障时,L1 可降级到纯确定性模板兜底,零 LLM 出基础可玩游戏,保证"LLM 挂了仍能出基础可玩游戏" | HJ-GEN-001 §2.1 降级 + 风险 1;技术决策版 §8 风险1;tech-decisions §5 | 不确定 | 现行档的失败处置是"显式 giveup + 留证据,绝不交付坏游戏"——这与"LLM 挂了降级到确定性模板兜底出可玩"是**相反取舍**。游戏模板/填参线已废(W-CLEAN)后这条 fallback 的载体也没了,但"LLM 全挂时整条产线怎么办"这个韧性问题现行档没正面回答。请创始人定:是接受"全 giveup",还是要一条非 LLM 兜底 | |
|
||||
| 生成引擎-012 | **反同质化相似度度量 v0(GP4/D9)**:同 prompt×10 批跑产相似度分布报告、palette/config/资产变体距离 v0、超限告警(首版只告警不阻断);"同一模板不同用户成品在主题/美术/关卡/参数上可见差异"是 feed 内容生态生死指标 | 意图基线 GP4/P3;HJ-GEN-001 D9/§9 | 不确定 | 现行 D9 反同质化(验收门-W-G1)只做了"NFKC+casefold 归一查重,撞重只告警"——那是**精确撞重去重**。HJ-GEN-001 的 D9 是**相似度度量(分布报告 + palette/config 距离)**,量的是"千篇一律"程度,完全不同的东西。现行档把"feed 同质化"这条生死指标的度量收窄成了"防完全重复" | |
|
||||
| 生成引擎-013 | **L2 代码不可信七层信任边界(逐层展开)**:补丁面白名单 / 依赖锁定离线镜像 / 静态安全门(禁 eval·new Function·网络逃逸·postMessage 越权)/ 构建隔离(一次性容器无密钥无外网)/ 运行取证门(CSP 双源零违规+真输入冒烟)/ 发布隔离(初期 100% 进人审抽样池,连续 50 款≥95% 后降采样)/ code-patch 契约 9e | HJ-GEN-001 §3.1;README §8(只点名"七层"未展开) | 不确定 | README §8 点名了"七层信任边界"但明说"细节都在源档,不在此展开"——而源档(HJ-GEN-001)是 _archive 流水档。L2 起代码不可信这套是真要命的安全约束(L2 上线前缺任一层不准放开),现行档**有指针没内容**。判:是否要把这七层在生成引擎子树落一份现行 SoT | |
|
||||
| 生成引擎-014 | **经验复利层引擎可移植性:经验绑契约不绑引擎**:每条 Debug/Template 经验强制拆 invariant 层(failureClass/archetype/物理画像/契约级 proactive check——换引擎100%继承)+ `engineBinding` 绑定层(具体 fix patch/骨架代码/引擎特定 check——换引擎需 re-derive);切引擎走 invariant 100% 继承 + bound re-seed + 契约无关黄金集 parity 门"达标才切默认" | OpenGame蓝图补缺-review §5/D7 | 遗落 | 现行档(README §6.2/OpenGame对照 §3.2)讲了要补 Debug Skill / Template Skill,但**完全没讲"经验如何对引擎切换有韧性"这层设计**。这是一条想得很深的约束(防一次 engine switch 把攒的经验库抹平),且与现行"引擎是模板携带的可换实现选项"原则同根,不该丢 | |
|
||||
| 生成引擎-015 | **经验库"去具体化 + case-based reasoning"沉淀范式**:完成任务→抽经验→去具体化(角色名→Player、硬编码值→config 引用)→沉淀本地 JSON 库→下次先查库命中复用→重复达阈值升格成可执行规则;纯本地零向量零 embedding=基于案例的推理而非 RAG;且家族规模上来后**没有遗忘/淘汰/冲突消解会退化**,需补真正的检索 | OpenGame对照 §2.7;OpenGame蓝图补缺-review §4/§9 | 不确定 | OpenGame对照档讲了 Debug/Template Skill 的机制(签名三元组、阈值升格),但"去具体化 + case-based 非 RAG + 规模化退化需补检索"这层范式定性偏弱。尤其"等品类规模上来需补一层真正检索(embedding/按字段索引)"这条前瞻约束容易在落地时忘 | |
|
||||
| 生成引擎-016 | **统一 trace 契约 `contracts/trace/` 立位(第N类 additive)**:两条生成线(SAA廉价 / tier2自治)轨迹落同一张表——公共核心子集(traceId/step/cost/verdict/timestamp)对称 + JSON 扩展列各写各的;含字段定义/schema版本/脱敏规则/两线 adapter 映射 + 一条要选边的策略(写不进去时阻塞生成还是 best-effort 告警) | agentic集成架构(提到待立);tier2实现详设(提到待立);python-to-SAA-migration §5 | 不确定 | 现行 agentic集成架构 + tier2实现详设都说了"这一位当前还没建,随 spike/控制面 phase-1 落地再新立"——所以它是显式挂着的待办,不算纯遗落。但它是第 9 契约组之外**一个新契约类的立位**,且"写不进去时阻塞 vs best-effort"这条要选边的策略容易被当细节漏掉,记一笔 | |
|
||||
|
||||
---
|
||||
|
||||
## 表三 · 运行时 / 引擎 / 渠道侧约束(早期讨论过、现行档收窄或没带全)
|
||||
|
||||
来源主要是 `tier1-runtime-constraints`(Tier1 三层约束框架的完整 requirements)、`自治富游戏引擎`(渠道侧)、`tech-decisions`。现行 `引擎与运行时.md` 已经把 SLO/B1/S2 三层框架讲清了,但 requirements 里几条工程增强/延后项没全带上。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 生成引擎-017 | **实例级引擎复用(常驻 runner 跨游戏复用引擎实例)**:省 init/WebGL 上下文重建,受候选引擎 destroy 卫生制约;LittleJS 选型时 Phaser 的 destroy 泄漏(issue #2138/#5456)曾是落选因素之一 | tier1-runtime-constraints KD4/Deferred;Tier1重设计-review | 遗落 | 现行 引擎与运行时.md 完全没提"实例级复用"这条延后项,也没记 destroy 卫生这条引擎选型约束。它被明确标"S2 实测逼出来再上(2.x)",是一条有意延后但该记住的优化路径(信息流场景跨游戏复用引擎实例对冷开收益巨大) | |
|
||||
| 生成引擎-018 | **工程增强层 E1-E6 六条便宜高杠杆**:E1 预热管线(点卡→可玩~0.5-1s 对齐短视频起播)/ E2 首帧保障(<300ms 绘主题底色标题)/ E3 自适应质量分档(首会话探测设备能力定档,P95 自动降粒子/关后处理/限 dpr)/ E4 模板级共享资产打进 Runner 享全局缓存 / E5 音效优先程序化合成(参数仅数十字节,沙箱 connect-src none 零开口)/ E6 brotli+WebP+manifest 随 feed 省 RTT | tier1-runtime-constraints R11-R16/KD5 | 不确定 | 现行 引擎与运行时.md 有 SLO/B1 但**没有 E1-E6 这层"把体感从达标拉到短视频级"的工程增强承诺**(只在 7.3 backlog 提了零星几项)。E3 自适应降档=KD1"P95 优雅降级"的机制化,E5 程序化音效=沙箱零开口约束,都是该记的设计点。判:是否把 E1-E6 在 引擎与运行时.md 落一笔 | |
|
||||
| 生成引擎-019 | **低端机真瓶颈是 JS parse 不是传输 + 引擎必须 URL 化交付(双缓存)**:千元机 ≈1MB/s parse、编译缓存只对 URL 脚本生效(内联两者皆无);引擎带版本号 URL + immutable 强缓存=每设备每版本只付一次 parse;主考最关键一题=编译缓存在 XWeb/低端 WebView 的真实表现(未验证、列为定向钉子) | tier1-runtime-constraints Problem Frame/KD3/KD4/A2 | 不确定 | 现行 引擎与运行时.md 讲了 LittleJS 冷开数据和 URL 化交付的好处,但**"低端机瓶颈=JS parse 而非传输"这条根本性认知、以及"编译缓存在低端 WebView 未验证(spike 钉子)"这条未决约束没带**。这是整个体积/冷开策略的底层依据,丢了会让后人重新纠结 KB | |
|
||||
| 生成引擎-020 | **渠道侧禁动态生成代码 → tier2 富游戏上渠道得"精选固化进壳"**:微信/抖音剥离远程代码、禁 eval 类解释器,只许"包内固定模板 + 远程纯数据配置";所以热发任意生成游戏只能上 web feed,渠道拿精选爆款(固化进壳走平台提审)。GameConfig 渠道合规红线=禁可执行串/枚举化 FSM/additionalProperties:false | 自治富游戏引擎(渠道段);HJ-GEN-001 D13 | 不确定 | 自治富游戏引擎档讲了 tier2 渠道这条(精选固化),且讲得不错。但**Tier0/1 这条线**(现 README/引擎与运行时)对"web feed 热发 vs 渠道精选"这条产品形态二分、以及 GameConfig 渠道合规红线(D13 来自 HJ-CH-001)没带。判:是否在 Tier0/1 档也补一句渠道约束 | |
|
||||
| 生成引擎-021 | **SDK Core 独立体积约束(<8KB)**:与引擎体积框架解耦的另一条约束;沙箱 connect-src 'none' 游戏内零网络、加载超时5s 自动跳过+降权 | tier1-runtime-constraints(Outside scope);技术决策版 §4 沙箱铁律 | 不确定 | 现行 引擎与运行时.md 讲了引擎 55KB 和装载契约,但 SDK Core <8KB 这条独立约束、以及"加载超时5s 自动跳过+降权"这条产物侧降级约束没带(可能归 runtime-and-multichannel skill,但生成产物侧该知道) | |
|
||||
|
||||
---
|
||||
|
||||
## 表四 · 已明确弃用 / 被取代(列出来免得重复讨论)
|
||||
|
||||
这一批历史里拍过、后被明确废除或取代。现行档大多已经标了"已废",这里汇总是为了让创始人一眼看清"哪些被考虑过、为什么弃",避免后来人或新 agent 重新捡起来。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 被什么取代 / 为什么弃 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 生成引擎-022 | **AgentScope 2.x 作 agentic 基建主力(HJ-AGI-001)**:全平台只养一套基建=AgentScope,W-G1 即 spike 验证门(分布式/持久化/L1开销验不过即切 LangGraph);五资产契约边界把框架压到"只租用不拥有" | agentic基建框架选型-review(HJ-AGI-001) | 过期/弃用 | 被 HJ-AGI-002(SAA-only,2026-06-15)取代:生产 SAA-only(SAA 自带 ReactAgent/asNode/subAgents/子图),AgentScope 降 long-term premium 独立轨。双评审查到 SAA 的 asNode 绑 agentscope-core 1.0.9 只能代理单 ReActAgent、本地是 2.0.0-SNAPSHOT,硬塞属未验证路径。现行档已是 SAA-only,此条仅作决策史 | |
|
||||
| 生成引擎-023 | **LangGraph 开源核心路线(生产实证优先)**:研究员推荐过,买最硬生产实证(Replit"agent写码"同构/Uber/Klarna ~400家)+ checkpoint/HITL 最成熟 | agentic基建框架选型-review B 案 | 过期/弃用 | 同被 HJ-AGI-002 取代。弃因:核心库 MIT 但生产 Server(langgraph-api)=Elastic License 须商业 key 或自建 Server 层(讽刺地把刚否决的"自研内核"以薄形态请回来)+ 退出成本最高(StateGraph+LangChain 生态嵌套深)+ 一行误引 langgraph-api 即许可违规(AI写码常驻法务雷)。仅作决策史 | |
|
||||
| 生成引擎-024 | **Dify(可视化DAG编排)+ OpenGame(文生代码微服务)+ Java壳 三段式生成栈**:早期 ADR 选入,组合4-6周跑通 vs 自研6-12月;Dify 多模型热切换/可观测开箱、OpenGame=CUHK MMLab SOTA 六阶段 pipeline + benchmark | 技术决策版 §6.2;ai-generation-pipeline(已挂 DEPRECATED 横幅) | 过期/弃用 | C2 裁定(2026-06-09 spike 结构层52/52=100%)+ HJ-GEN-001 终审取代:现行=new-api 网关直连便宜模型 + SAA 裸图 + agent 写码于插件库。Dify/OpenGame **从未部署**、降级远期增强。注:OpenGame 后来又作为"已验证 embodiment 蓝图"被深读对标(OpenGame对照档),那是"抄设计不抄运行时",与"部署 OpenGame 微服务"是两回事 | |
|
||||
| 生成引擎-025 | **模板驱动生成(LLM 只填 GameConfig 参数 + 固定模板 runtime)**:C1/C2 spike 证 LLM 出合法 GameConfig 100% 可靠 → 绕开高风险 LLM 代码生成;曾是 MVP 生成主线 | generation-spike(spike-summary);技术决策版 §4.1 模式A | 过期/弃用 | HJ-GEN-001 终审(2026-06-12)废除游戏模板/填参线(W-CLEAN,旧4模板+存量数据清除),理由=填参式整局代码是同质化根源。改"agent 写码于 LittleJS 插件库"。⚠️ 注意术语:废的是"游戏模板/填参线",**"玩法模板"=品类引导框架未废、有效待建**(HJ-DEMO-AUDIT-001 创始人纠偏)。现行档已对齐 | |
|
||||
| 生成引擎-026 | **GamePackage 可寻址 manifest(六槽+config+关卡可单独 target 做差量局部修改)**:对话生成修改素材-review v1 的 D5,创始人选"差量局部修改"→产物不能是不透明 blob、manifest 暴露可寻址部件、引擎从可解构包渲染 | 对话生成修改素材-review v1 D5 | 过期/弃用 | 被创始人生命周期重构(生命周期-review v2 C4)整条废除——改"不碰打包产物,在源项目(src/工程)上演进再构建"。"改打包产物/diff blob"被判根本走不通。现行档(README §3/固定游戏架构)已是"改源不改包"。此条仅记一次 pivot 历史:同一个"可局部改"诉求,载体从"可寻址manifest"换成了"src/源项目" | |
|
||||
| 生成引擎-027 | **15KB / 13KB 运行时体积红线**:srcdoc+toString 内联架构下 runtime 字节随每局游戏重复支付、无 HTTP 缓存,抠 KB 当时理性;13KB=js13k 极限分支,15KB=srcdoc 内联架构衍生约束 | tech-decisions(回填注);引擎与运行时 §2.3 | 过期/弃用 | 前提架构(srcdoc 内联)已废→约束失效,2026-06-11 改为三层框架(SLO@千元机+4G P75 / B1 入场券 gz≤350KB·raw≤1.5MB / S2 主考)。现行档已明确"请勿再引用 13KB/15KB"。汇总于此免新人再抠 KB | |
|
||||
| 生成引擎-028 | **"thinking:disabled"作 M3 截断的修补**:gamedef 路便宜模型"哑火静态游戏"+JSON被think块污染撑爆max_tokens截断,曾用关 thinking 躲 | 生成失败根因分析;saa-graph-orchestration §3.5 | 过期/弃用 | 被证为错补丁(关 thinking=丢质量)。正解=走 Anthropic /v1/messages 原生 thinking 分离 block + 必流式 + webClient NO_PROXY(实测 conc=12 gamedef 67%→91.7%)。现行 saa-graph-orchestration §3.5 已记正解,但这条"曾经的错补丁+为什么错"在 docs/architecture 生成引擎子树没明确,记一笔免得有人再关 thinking 图省事 | |
|
||||
|
||||
---
|
||||
|
||||
## 给主代理的汇总(headline)
|
||||
|
||||
这次回收的大头不是工程债(现行档自己挖得很透),而是 **HJ-GEN-001 意图基线里创始人亲自拍过"全采纳"、后被收窄到 Tier0 当下产线时丢掉的产品级机制**。最该捡回的遗落点:
|
||||
|
||||
- **生成引擎-001/002 对话式生成 + 智能确认 + 六类素材驱动**:创始人口径"真创作能力"的核心交互,现行生成引擎子树完全没 SoT,只散在 review。
|
||||
- **生成引擎-003/004/005 资产库→资产市场 / remix 飞轮 / 数据飞轮回流训练语料**:护城河"资产沉淀+网络效应+数据"三层的生成侧工程落点,创始人采纳过,现行档零提或只剩半条。
|
||||
- **生成引擎-006 商业化就绪评分多维+阻断动作**:现行 D11 只剩 4 维分数,丢了"广告适配/版权风险/审核预测"三维和"评分是门非展示"这条强约束。
|
||||
- **生成引擎-009/010 best-of-N + prompt-hash 结果缓存**:两条早期讨论过、抬成功率/省钱的直接工程杠杆,被列"次要"后没进任何现行档。
|
||||
- **生成引擎-013 L2 代码不可信七层信任边界**:README 有指针无内容(源档在 _archive),是 L2 上线前缺一层都不准放开的安全约束。
|
||||
@ -1,76 +0,0 @@
|
||||
---
|
||||
date: 2026-06-21
|
||||
topic: 生成引擎 · 历史设计点回收 第二轮(复核 + 查漏)
|
||||
status: 复核与补遗清单(trace 层) · 判定列留空待创始人裁
|
||||
maintainer: 架构史官(第二轮:review 复核 + 查漏补缺)
|
||||
---
|
||||
|
||||
# 生成引擎 · 第二轮:复核勘误 + 新档覆盖 + 查漏补充
|
||||
|
||||
## 这一轮做了什么
|
||||
|
||||
第一轮(`生成引擎-历史设计点.md`)把生成引擎子树的历史设计点挖了 28 条,主体是 HJ-GEN-001 意图基线里创始人拍过"全采纳"、后来收窄到 Tier0 产线时丢掉的产品级机制。这一轮不重抄它,只做三件事:一是抽验第一轮的出处真不真、分类准不准,把要改判的拎出来;二是核对第一轮之后又落地的一批新设计稿(数据飞轮、审核台、观测体系、k8s 迁移,以及更早的鉴权/沙箱/契约/数据模型/变现五份 P0),把第一轮标"遗落/不确定"、现在已经被这些新档接住的条目逐条列清;三是再扫一遍历史源,补第一轮漏掉的点——重点落在跨域交界、以及第一轮没扫到的两份新文档(`2026-06-20-关闭九门判定-全面参考OpenGame` 决策记录、`2026-06-19-002-gendone` plan)。
|
||||
|
||||
先说复核结论:**第一轮的出处经得起核对。** 我抽了 001/002/006/009/010/013/014/028 八条去源档逐一 git grep,引用的文件、章节、口径都对得上,没有发现编造或张冠李戴。需要改判的只有两条,都不是"出处错",而是"分类时漏看了代码现状"——把已经在库里、只是被有意推迟的机制,当成了纯粹"没人做过的遗落"。
|
||||
|
||||
这一轮新挖了 9 条(生成引擎-029 至 037),其中最该看的一条是:**2026-06-20 创始人拍板把生成硬门从"九门聚合"收窄成"客观健康门 A–E",F_wiring 移出、driver 依赖门 G/H/I 降为不否决生成的参考门**——这个让 gamedef 生成质量真正做到 91.7% 的关键 pivot,`.agents/skills` 层吸收了,但生成引擎子树的现行架构档(验收门-W-G1 / SAA编排 / OpenGame对照)至今还把九门当统一硬地板讲,没跟上。这是这次查漏最大的一块,且正好是第一轮没扫那两份新文档造成的盲区。
|
||||
|
||||
---
|
||||
|
||||
## 一 · review 勘误表(改判第一轮条目)
|
||||
|
||||
只列要改判的两条。其余 26 条复核后判定不变,不重列(那是噪音)。
|
||||
|
||||
| ID | 原判 | 新判 | 为什么改 |
|
||||
|---|---|---|---|
|
||||
| 生成引擎-010 prompt-hash 结果缓存 | 遗落 | **已规划待执行(字段已落、读取侧有意推迟)** | 第一轮说"整个生成产物按 prompt-hash 结果缓存,现行生成引擎档没有"——出处没错,但漏看了代码现状。`game_aigc_task.prompt_hash` 这一列**已经在库里**(数据模型 §"game_aigc_task")、生成入口已经在算它:`AigcTaskServiceImpl.java:157` 写得很白——`task.setPromptHash(sha256(reqVO.getPrompt())); // 产物缓存键，对齐 GamePackage.provenance.promptHash（v0 不读它做缓存，门③推迟）`。所以这不是"没人想过的遗落",而是**缓存键已就位、读取去重逻辑被 v0 有意推迟(门③)**的已规划项。按创始人"疑似缺陷三分法",它属"已规划待执行",不属"无背书的真遗落"。它仍值得记一笔(读取侧确实还没做、现行架构档没讲这条推迟),但判定要从"遗落"改成"待执行"。另:新档 `数据飞轮.md` §3.1 顺带点了"D12 当前没有 prompt-hash 维度的频控",侧面印证这条还没接通。 |
|
||||
| 生成引擎-011 L1 确定性 fallback 生成器 | 不确定 | **不确定(维持) · 但要剔除一个误读风险** | 判定本身不改(维持不确定),改的是要给创始人提个醒、免得被新出现的"兜底"字样误导。`saa-graph-orchestration.md` 现在写了一句"要快则 openai+disabled 兜底"——这容易让人以为 011 那条"LLM 挂了降级到确定性模板出可玩"已经有了着落。**两者不是一回事**:那句"兜底"指的是 M3 thinking 太慢时退回 openai 协议+关 thinking 的**模型协议降级,仍然在调 LLM**;而 011 问的是"new-api/LLM 整个挂了,产线还能不能零 LLM 出基础可玩游戏"。后者现行依然没有正面答案(失败处置仍是显式 giveup)。所以 011 维持不确定,但勘误一句:别把"openai+disabled 兜底"当成 011 的解。 |
|
||||
|
||||
> 补一条对第一轮自身判断的肯定(非改判):**生成引擎-009 best-of-N 维持遗落,判得对。** 我特意核了 06-20 那轮跑的 conc=12 是不是 best-of-N——不是。plan 写明"有界并发,K=正确性参数、非提速旋钮",那是**为了测真实成功率分布**的测量并发,跑完取的是通过率,不是"K 个候选里挑最优交付"。best-of-N(同 brief 跑 K 个选最好的那一个交付)在任何现行档里仍然零提及。第一轮判它遗落,准确。
|
||||
|
||||
---
|
||||
|
||||
## 二 · 已被第一轮之后的新档覆盖的条目
|
||||
|
||||
这一节是本轮重点之一:第一轮标"遗落/不确定"、但第一轮之后落地的新设计稿现在已经把它接住的条目。逐条核对、列出被哪份新档覆盖、覆盖到什么程度。
|
||||
|
||||
| ID | 第一轮原判 | 被哪份新档覆盖 | 覆盖程度 |
|
||||
|---|---|---|---|
|
||||
| 生成引擎-003 创作者个人资产库 → 资产市场 | 遗落 | **`架构/生成引擎/数据飞轮.md` §3.2 + §4 阶段二/三** | **完整覆盖。** 数据飞轮把"私有素材库(game_material V24)升级成跨创作者货架 → 授权采购走 trade 入账(新增 ASSET 来源枚举)→ 分成结算"整条画清了,还划清了生成侧/素材中心/trade 三模块边界(生成侧只透传素材+记 assetRefs 血缘),并把"流通半依赖真实支付收单(日历闸门)"这条硬前置标了出来。第一轮要的"资产沉淀层工程落点"已落,可视为收口。 |
|
||||
| 生成引擎-004 玩家→创作者 remix 飞轮 | 遗落 | **`数据飞轮.md` §3.1(整节)+ README §10** | **完整覆盖且做厚了。** 数据飞轮把 remix/同款做成了一整套设计:源 schema 新增 `lineage` 可选字段(parent/origin/depth/assetRefs)、新建 `game_lineage_edge` 血缘边表、`/studio/create` 加 `remixFrom` 入参、血缘边"先 pending 过九门后 active"的激活时机、三道防滥用(深度截顶/D12 配额空窗兜底/去重独立创作者数)、`remix_click/remix_submit` 漏斗埋点、父被删的断链降级。比第一轮设想的更完整,连派生授权法务挂律所这条也记了。收口。 |
|
||||
| 生成引擎-005 数据飞轮:生成全量 + 收益数据回流训练语料 | 遗落 | **`数据飞轮.md` §3.3 + §4 阶段四** | **完整覆盖,且诚实地标了前置缺口。** 数据飞轮把 GC10 那条"收益回流"补全了:统一 schema 以 gameId 为主键拼生成特征+留存+收益,喂 Template/Debug Skill 校准/推荐排序/未来自训小模型。更可贵的是它点破了两个"现在还 join 不上"的硬现状——`game_trade_income` 没有 game_id 列(待变现 W4 四步透传)、`game_telemetry_game_stat` 没有留存字段(待定义口径),以及它要复用 agentic 集成架构那个待建的 `contracts/trace/` 统一轨迹契约。第一轮说的"只剩半条"现在补成了整条。收口。 |
|
||||
| 生成引擎-016 统一 trace 契约 `contracts/trace/` 立位 | 不确定 | **`数据飞轮.md` §3.3(把收益回流挂在它下面)** | **部分覆盖,定位更清晰了。** 第一轮拿不准它算遗落还是已挂着的待办。数据飞轮把它的角色坐实了:收益回流语料 = 统一 trace 契约的归档记录 + 一层 telemetry/trade join 进来的线上结果标签,明确"实现成 trace 契约的下游归档,而不是平行第二套数据管线"。它仍是待建项(agentic 集成架构标"随控制面 phase-1 落地"),但"为什么要立这一位、它向收益侧怎么延伸"现在讲清了。可从"不确定"收敛为"已挂着的待办,定位已明"。 |
|
||||
|
||||
> 还有几条第一轮的条目,在新档里被**侧面触及但没被收口**,不算"已覆盖",仍留在第一轮清单待裁,这里只点一句免得误判:
|
||||
> - **006 商业化就绪评分多维**:`审核台运营.md` 的双层审核/锁风三档处理的是"内容安全审核"这条线,和 006 要的"发布前多维就绪评分(广告适配/版权风险/审核预测三维 + 评分是门非展示)"是相邻但不同的事——审核台是审核判定流,就绪评分是生成产物的多维体检门。审核台没有替 006 收口,006 维持第一轮判定。
|
||||
> - **007 预算即产品 + 第一笔收益激活**:`变现端到端.md` 我核了,没有覆盖 GP7 的"预算对用户透明 + 收益激活路径引导"这条创作侧产品面。007 维持遗落。
|
||||
|
||||
---
|
||||
|
||||
## 三 · 查漏补充清单(第一轮漏挖的)
|
||||
|
||||
判据同第一轮:遗落=历史讨论过、有价值、现行没沉淀也没明确弃;过期/弃用=已被取代或决定不做;不确定=拿不准现行覆盖没。现行已覆盖的不补。编号接第一轮续(从 029 起)。
|
||||
|
||||
这批里 029–032 是同一个来源——**第一轮没扫到的 `2026-06-20-关闭九门判定-全面参考OpenGame-决策与Phase0-4.md`**(那天创始人拍板、当天把 gamedef 做到 91.7% 的决策记录)。这份文档不在第一轮列的扫描源里,而它承载的恰恰是生成验收口径的一次重大 pivot。033–037 是再扫意图基线和早期 brainstorm 补出的几条跨域/产品面遗漏。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 生成引擎-029 | **生成硬门收窄成"客观健康门 A–E",driver 依赖门 G/H/I 降为不否决生成的参考门、F_wiring 移出客观硬门**:生成环(SAA 管线)硬门只认 build-health 客观门 A_boot/B_uncaught/C_frame/D_render/E_live;G_input/H_progress/I_control 不再否决生成、不进救场回喂;F_wiring(靠游戏事件触发 rt.fx、无 driver 真玩必挂)也移出客观硬门,"真用引擎/有特效"语义改由 VLM 看截图判;九门 harness 仍照常跑写 verdict.json(门判定本身不动),只改"生成环如何消费 verdict",`-Dsaa.gen.gateMode=all9` 双轨可回退 | `docs/plans/2026-06-20-关闭九门判定-全面参考OpenGame-决策与Phase0-4.md` §1/§4/§7;`.agents/skills/saa-graph-orchestration.md` §3.5 + L100 | 遗落 | **这是本轮查漏最该看的一条。** 创始人 2026-06-20 显式解除了"never edit nine-gate judgment"的安全约束、拍板这次收窄,且它是 gamedef 生成质量从 ~50%(all-9)做到 **91.7%** 的直接原因之一(配合 thinking+anthropic 协议)。但现行生成引擎子树**完全没跟上**:`验收门-W-G1.md` 仍把九门 harness 讲成统一"硬地板"、`SAA编排.md`/`OpenGame对照.md` 也没有 A–E 客观门 vs driver 门的切分。`.agents/skills` 层吸收了,架构 canon 没吸收——这是"决策落了代码、但没沉淀进现行架构档"的典型遗落。判:是否把这次九门口径 pivot 回填进验收门-W-G1 + OpenGame对照,让架构档与现行真相对齐 | |
|
||||
| 生成引擎-030 | **rc 门耦合 bug = 客观门解耦的隐形杀手(一条该记住的踩坑约束)**:`SaaGenNodes.playNode` 的 pass 一旦前置 `rc==0`,而 `play.cdp.cjs` 退出码=九门聚合(任一门含 driver 门挂即 exit 1),则 driver 门失败 rc=1 会**反向否决**"只认客观门 A–E"的解耦,使解耦形同虚设、空跑 8 轮救场烧 302K token;修法=客观门模式 `pass=(rc==0\|\|rc==1)&&objectiveGatesPass(verdict)` | `2026-06-20-关闭九门判定` §7-1;`saa-graph-orchestration.md` §3.5 | 遗落 | 这是 029 那条解耦真正生效的前提坑,且 06-20 当天就是这个 bug 让 Phase 1 空转。它已蒸馏进 skill,但和 029 一样没进架构档。和 029 同根:判 029 要不要回填时,这条作为"客观门解耦的实现约束"一并带上,免得后人重写 verdict 消费逻辑时再踩一遍 | |
|
||||
| 生成引擎-031 | **OpenGame 方法蓝图 Phase 2–4 落地路线(模板-First+hook +10.1 / 活调试协议 +6.9 / VLM 验证替 driver 判定)**:Phase 2=每 archetype 预建已验证 gamedef 骨架 + hook 覆写;Phase 3=活调试协议/离线 linter,坑入版本化匹配库、真玩前静态门回灌;Phase 4=build-health + VLM 验证替换 driver 判定、自修复封 T=3、达标 flip;消融最大杠杆=hook/模板 +10.1 BH、活调试 +6.9、模板族 +5.8 | `2026-06-20-关闭九门判定` §2/§3(Phase 表) | 不确定 | 现行 `OpenGame对照.md` 已经把 OpenGame 的方法(GDD 六节、Template-First、Debug Skill 升格、player 软门 M3 截图判)讲得很透,`设计合理性裁决.md` 改动六也有"进化语料半自动萃取品类模板"。**但"Phase 2/3/4 作为一条有编号、有消融杠杆量化(+10.1/+6.9/+5.8)、有 flip 达标条件的落地路线"没有在现行档成体系**——OpenGame对照是"对照分析",06-20 是"决策与执行 Phase",两者口径不同。判:OpenGame对照是否要补一节"我们的 Phase 0–4 落地路线"把这条决策路线沉淀进来,还是认为对照档+改动六已够 | |
|
||||
| 生成引擎-032 | **生成速度代价是上线前必须治的硬约束(非可延 backlog)**:M3 thinking-on 修了"哑火静态游戏"但代价是 ~10x 慢(adaptive 无界)+ 1.6x token,**单局 20–73 分钟**;异步产线可接受,但"要快则 openai+disabled 兜底"会退回 67% 哑火——质量与速度的张力是真实的,06-20 自己把"速度代价(单局 20–73min,上线要治)"列进未尽事项 | `2026-06-20-关闭九门判定` §7-6;`saa-graph-orchestration.md` §3.5(L61) | 遗落 | 现行生成引擎子树有 L1 P75≤30s 的工程门(README §8),但那是**面向用户的 L1 时延**;而 thinking-on 异步产线"单局 20–73 分钟"这条**便宜模型高质量路的真实墙钟代价**,以及"质量与速度按场景权衡、上线前要治 adaptive 无界"这条约束,现行档没带。它直接关系"91.7% 是用 73 分钟/局换来的、能不能这样上线"这个真问题,不该只躺在 skill 里 | |
|
||||
| 生成引擎-033 | **创作期数据回灌(试玩流失点/难度卡点结构化喂回对话调整)**:GP8 数据回灌双闭环的**创作期**那一半——把创作者自己试玩时的流失点、难度卡点结构化地喂回对话调整,让下一轮生成/修改据此校准;与"发布后运营建议"是两条不同的闭环 | 意图基线 GP8(P7+XP10);HJ-GEN-001 | 遗落 | 第一轮没拆开 GP8。现行档覆盖了 GP8 的**发布后**那一半(`固定游戏架构.md` §220 + README §105 的 maintain 步:据玩家遥测回项目演进),但**创作期**这一半——创作者试玩→流失点/卡点结构化→喂回对话调整——在生成引擎档零提。它是对话式生成闭环里"用数据让调整更准"的一环,和 001/002 那条对话式生成同属创作交互纵切,该补一笔 | |
|
||||
| 生成引擎-034 | **生成即合规(合规检查嵌在生成循环内,而非只在发布前过门)**:GP9 的核心口径是"内容安全/广告合规/版权检查嵌在生成循环内(生成即合规)、状态对用户可见",目的是生成过程中就挡掉违规、降审核队列压力,而不是等产物成型后在发布门一次性审 | 意图基线 GP9(P8+XP8);HJ-GEN-001 §9 合规先行 | 不确定 | 新档 `审核台运营.md` 覆盖了"产物成型后的双层审核 + 锁风三档 + 处置联动",`合规闸门.md` 覆盖法定上线门——**但 GP9 强调的是"合规嵌进生成循环内"这个生成侧的时机**(生成中即合规,不是生成后才审)。现行锁风门 `ComplianceGateApi.evaluate` 是在 project 发布前检查(T-PRJ-05),不是生成循环内。判:GP9 的"生成即合规(循环内嵌)"是已被"发布前锁风门"等价满足(只是时机略后),还是确有"生成循环内合规门"这条独立诉求待补?请创始人定 | |
|
||||
| 生成引擎-035 | **Agent 框架可替换 / 内核边界沉淀在协议而非框架(XC3/GC9 的反锁死约束)**:AgentScope/LangGraph/AutoGen 可借鉴组合但平台不绑单一框架,真正固化的是任务协议/状态模型/工具接口/验收门禁/遥测事件;五资产契约边界把框架压到"只租用不拥有" | 意图基线 GC9(C9+XC3+XC10)、GC2(模板与运行时解耦);agentic基建框架选型-review | 不确定 | 现行 `agentic集成架构.md`/`SAA能力API-dossier.md` 讲的是"SAA-only 怎么用、能力边界在哪",这是**当下选型的实现**;而 GC9 那条"内核边界=协议不绑框架、框架可替换"是一条**架构原则/反锁死约束**。第一轮表四 022/023 记了 AgentScope/LangGraph 被 SAA-only 取代(决策史),但"为什么仍要保持框架可替换、内核沉淀在哪五件"这条原则没被单独记。它和 long-term AgentScope premium 独立轨同根。判:这条反锁死原则是否已被 SAA-only 决策隐含覆盖,还是该显式记一笔(尤其 long-term 要切 AgentScope 时它是判据) | |
|
||||
| 生成引擎-036 | **harness=可版本化/可观测/可回放/可扩展的复利核心资产(工程护城河,非测试脚本)**:XC1/GC1——生产级 harness 应沉淀为可版本化、可观测、可回放、可扩展的生成运行环境,它决定成功率/成本/交付稳定性,工程投入全部沉淀于此、单次生成是消耗品 | 意图基线 GC1(C1+XC1);XC1 | 不确定 | 现行档对 harness 的"禁重写既有资产""复利中台轨迹仓+成本台账"(`固定游戏架构.md` §338、`tier2实现详设.md`)有零散覆盖,但**"harness 作为工程护城河、要可版本化/可回放/可观测/可扩展"这条定性**没有在生成引擎档作为一条明确的工程原则立着。它是 GC1 这条创始人采纳意图的工程纲领。判:是否已被"九门禁重写+复利中台"等价覆盖,还是该把 harness-as-moat 这条定性补一句 | |
|
||||
| 生成引擎-037 | **best-of-N 受"整图串行不可量"架构约束(架构约束本身值得单记)**:第一轮 009 记了 best-of-N 遗落,但它的**前置架构约束**——`SaaGraphDispatcher` 单线程+Semaphore(1) 包住整条 graph.invoke、固定端口致 K 候选无法并行——这条"整图串行阻塞并行"约束只在 trace 层,且它不只卡 best-of-N,也卡任何并行生成 | 生成失败根因分析 §4④;SAA-dossier(U7);`saa-graph-orchestration.md`(Semaphore(1) 守端口) | 不确定 | 第一轮把这条约束并进了 009 的"为什么"里一笔带过。它其实是一条独立的架构现状约束:**整条生成图当前是串行的(Semaphore(1) + 固定端口 4320/9222)**,这既是 best-of-N 落不了的原因,也是未来任何"并行抬成功率/抬吞吐"方案的共同前置。`saa-graph-orchestration.md` 记了"Semaphore(1) 串行守端口"这条坑,但作为"架构现状约束"它没进现行架构档。判:是否值得在 SAA编排/agentic集成架构里单记一句"当前整图串行、并行需先解端口绑定",免得后人提并行方案时重新发现 | |
|
||||
|
||||
---
|
||||
|
||||
## 给主代理的汇总
|
||||
|
||||
复核结论先行:**第一轮出处可靠,抽验八条全对得上,只有两条要改判,且都是"漏看代码现状"而非"出处错"**——010 prompt-hash 缓存的键其实已落库、读取侧是有意推迟(从遗落改判为已规划待执行),011 的"openai+disabled 兜底"别被误读成确定性 fallback 的解。
|
||||
|
||||
新档覆盖面很实:**第一轮标遗落的 003/004/005(资产库→资产市场 / remix 飞轮 / 收益回流训练语料)已被 `数据飞轮.md` 完整收口,016 统一 trace 契约也定位清晰了。** 这四条可以从待裁清单里划走。但 006(就绪评分多维)、007(预算即产品)没被新档接住,维持第一轮判定——别误以为审核台/变现档替它们收了口。
|
||||
|
||||
查漏最该看的一块:**2026-06-20 那次"生成硬门收窄成客观健康门 A–E、driver 门降为参考门"的 pivot(029),`.agents/skills` 吸收了、架构 canon 没吸收。** 这是第一轮没扫那份决策文档造成的盲区,而它恰恰是 gamedef 做到 91.7% 的关键。连带 030(rc 门耦合坑)、031(OpenGame Phase 2–4 路线)、032(单局 20–73 分钟的速度代价上线前要治)三条同根,都是"决策落了代码、没回填进现行架构档"。033(创作期数据回灌)、034(生成即合规嵌循环内)是拆开 GP8/GP9 后补出的两条创作交互遗漏。035/036/037 是 GC9/GC1 那两条工程原则、和"整图串行"架构约束的补记,偏定性、留给创始人判要不要显式立。
|
||||
@ -1,84 +0,0 @@
|
||||
# 运维基建 · 历史设计点回收清单
|
||||
|
||||
> 这份清单做的是一件事：把"运维基建"这个领域里——历史和留痕文档里认真讨论过、但**现行 docs/architecture 没有沉淀下来**的设计点、想法、顾虑、约束——逐条挖出来，交给创始人判一判该不该捡回。它不是现行架构文档，而是一次穷尽式的"翻旧账"，目的是防止历史上想清楚过的好东西、或本该考虑的约束，在多轮 reframe 和文档域化重构里悄悄丢掉。
|
||||
>
|
||||
> **判定口径**：每条问"它在现行档里讲到没有？"——这里的"现行档"是**整棵 `docs/architecture/` 域树**（产品 / 架构 / 后端 / 前端 / 运营 / 运维 六域 + 生成引擎子树）外加 `.agents/`（knowledge / rules / skills）。要特别说明的是：**运维这个主题被刻意拆在两处**——`运维/README.md` 只承载"环境边界 / 部署链 / 健康门 / 可用性目标"这层薄骨架，而**可观测性技术栈（Prometheus/Grafana/Sentry/Jaeger/Loki）、SLO、性能目标、告警升级链、LLM 网关失效巡检**这些反而沉淀在 **`架构/README.md` §6**、`.agents/rules/security-and-reliability.md` §5-6 里。所以判"遗落"时，我是拿整棵树 + .agents 一起比对的，不是只看运维那一页——只有**整棵树都没有**的才算遗落，否则只是"沉淀在隔壁域"，不算丢，我已剔除不再当噪声列入。
|
||||
>
|
||||
> **扫过哪些历史文档**：`docs/architecture/_archive/` 三份长设计——技术决策版（HJ-ARCH-001，§3.2 部署拓扑 / §5.2 存储 / §6 选型 / §7.2-7.9 可靠性·可观测·CI/CD·环境·灰度 / §10 成本）、开发团队版（§1 本地环境 / §8 部署流程 / §8.3 回滚 / §10 外部工具）、技术架构与模块（telemetry/compliance 的监控告警·备份 T-id）、投资人版（§7 成本结构·资本效率·Runway）；`docs/agent-specs/_archive/` 里 **2026-06-08-wave3-staging联调与P0补全-review**（最厚的一份隔离 staging 建栈设计，OOM 保护 / 内存硬限 / 网络隔离 / healthcheck / 备份重建）、下一阶段路线-plan、admin-cloud清理-codex执行单、agent-loop 编排器 README/.agent；`docs/memorys/`（技术护城河复盘 / prefix-cache-preflight 的缓存成本监控）；`docs/mvp/`（单位经济敏感性模型的 new-api 成本对账）；以及 `运营/变现端到端.md` 里 XXL-Job 三个结算 job 的运维形态。
|
||||
>
|
||||
> **怎么读这张表**：状态分三档——**遗落**（讨论过、有价值、整棵树都没沉淀也没被明确弃，这是重点）、**过期/弃用**（讨论过但已被取代/明确弃，列出来是让创始人知道"考虑过、为什么弃"，避免重复讨论）、**不确定**（拿不准现行档到底覆盖没，或已部分覆盖、登记防丢）。判定列留空，等创始人裁。
|
||||
|
||||
---
|
||||
|
||||
## 表 A：可观测性、监控与告警
|
||||
|
||||
绘境的可观测性有一个反直觉的现状：**外部技术栈那一层（Prometheus/Grafana/Sentry/Jaeger/Loki + 告警升级链）其实没丢**，它被沉淀在 `架构/README.md` §6 和 `.agents/rules/security-and-reliability.md` §6 里，是有家的。真正悬空的是另外两类：一是**这套栈现在到底部署了没、谁来搭**（蓝图画了容器，现实从未起过 Prometheus，运维主档对此一字未提）；二是**平台自己内建的那一套监控告警能力**（telemetry/compliance 模块里设计的健康监控、异常检测、数据质量监控），它们和外部 Grafana 栈是两回事，却在域化重构后只剩一句"产出监控告警信号"。
|
||||
|
||||
| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运维基建-001 | **可观测性容器栈从未部署，运维主档对"现状是什么"留白** —— 蓝图在部署拓扑里画了 Prometheus:9090 / Grafana:3001 / Jaeger:16686 三个可观测性容器，但 MVP 现实从未起过它们。 | 技术决策版 §3.2 部署拓扑图；架构 README §6（描述了目标栈） | 遗落 | 架构域把可观测性目标栈讲清楚了，但**那是目标态**。运维主档讲"怎么知道服务健康"时，现行答案只有一个秒级冒烟门（`smoke-test.sh`）+ 可用性目标数字，**没有任何一句交代"Prometheus/Grafana 这套栈现在没部署、现状靠什么观测线上、什么时候补"**。这正是运维域该回答而没回答的边界：一个 ≥99.5% 可用性的目标，配的却是"部署后跑一遍冒烟"——线上跑起来之后靠什么持续观测、靠什么发现 5xx 飙升，是个真空。值得在运维主档补一句现状与缺口声明。 | |
|
||||
| 运维基建-002 | **telemetry 模块内建的实时健康监控（服务/生成/Runtime 三维 + 异常检测告警）** —— T-TEL-13~16 把"实时监控服务健康 / 生成任务健康 / Runtime 健康 + 异常检测与告警"列为 telemetry 的技术功能。 | 技术架构与模块 telemetry §（T-TEL-13~16/19/20）；13模块.md telemetry 卡片（仅留"产出监控告警"一句） | 遗落 | 现行 `架构/13模块.md` 只说 telemetry"产出监控告警与数据质量信号"，一句话带过；当年设计的**三维健康监控 + 异常检测 + 数据质量监控 + 推荐效果监控**这套**平台自建的内观测能力**（区别于外部 Grafana 旁路监控），没有在任何现行档里展开成"它监控什么、阈值多少、告警去哪"。这是 telemetry 作为"数据底座"承诺过、却在域化重构里被压扁的一块。它和外部 Prometheus 栈不重叠——一个是平台业务级健康（生成成功率、Runtime 崩溃率），一个是基础设施级指标。值得在后端 telemetry 设计或运维档里留一份"平台内建监控清单（待建）"。 | |
|
||||
| 运维基建-003 | **生成成本的周期对账 + 缓存命中率告警（cache_hit_rate < 50%）** —— prefix-cache 预研明确列了三条运维待办：集成 cache_info 抽取、周期对账成本、配置 `cache_hit_rate < 50%` 监控告警。 | memory `2026-06-17-prefix-cache-preflight.md` §后续行动 | 遗落 | new-api `logs.quota` 权威成本对账已经接通（单位经济敏感性模型里坐实，那部分不算丢）。但**"前缀缓存命中率掉到 50% 以下就告警"**这条——它是生成成本失控的早期哨兵（缓存一旦因 few-shot 字节漂移而失效，成本立刻翻几倍，年化差 ¥40k+）——在现行档里没有落点。架构 README §6 有"日预算熔断告警"，但那是总量阀；缓存命中率是更前置的成本健康指标。值得在成本台账或运维监控里补一条"缓存命中率哨兵"。 | |
|
||||
| 运维基建-004 | **告警升级链的 P0-P3 分级 + 通知渠道（电话/短信/飞书/钉钉）+ 响应时限** —— P0=服务不可用 5 分钟电话+短信、P1=5xx>2% 或生成成功率<70% 15 分钟、P2=P95>800ms 1 小时、P3 工作时间。 | 技术决策版 §7.5；security-and-reliability §6（已收录该表） | 不确定（已覆盖，登记防丢） | 这套**已在 security-and-reliability §6 完整收录**，不算遗落。放进来只为提醒：它现在是一张**纯文档表，没有任何告警通道真的接上**（飞书/钉钉 webhook 谁配、P0 电话怎么打，全是空头承诺）。一旦线上化，这是运维必须先落地的一环，别因为表已写好就以为有了。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 B：部署、回滚、灰度与环境管理
|
||||
|
||||
这一块是历史与现实落差最大的地方。蓝图设计的是一套很完整的云原生发版链（CI 触发 → 构建镜像 → 安全扫描 → 部署 staging → 冒烟 → 审批 → 滚动部署 prod → 失败自动回滚），外加四套环境、按百分比灰度、镜像回退保留前 3 版。现实是内网四台物理机 + 人工经标准序在 mini-desktop 部署，运维主档已诚实地把蓝图那套标为"目标态、系统性脱节"。所以这里**大部分是过期/弃用**——但弃用不等于没价值：里面有几个**机制（不是工具）**是真正上线时还得重新捡回来想的，比如灰度的"路由权重 + 旧版本不销毁"思路、Feature Flag 上线后必须删除的纪律。
|
||||
|
||||
| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运维基建-005 | **按百分比灰度发布（路由权重 5%→20%→50%→100% + 旧版本容器不销毁，异常 5 分钟回退）** —— 服务/版本级灰度靠网关路由权重逐档放量，发现异常把权重调回 0%、旧版本不销毁即时回退。 | 技术决策版 §7.9；开发团队版 §8.3 方式二 | 过期/弃用（机制可捡回） | 现行架构树里"灰度"一词出现 13 次，但全是**别的灰度**——游戏内容的金丝雀发布（运营/合规："新生成的游戏须经灰度验证")、SAA 派发器的灰度切换、Feature-flag 默认关的灰度 opt-in。**服务/版本级的"网关按百分比放量"这套部署灰度机制，整棵树没有**。它依赖网关在请求路径上（现行单体下网关不在路径上）+ Nacos 路由权重（Nacos 未部署），所以现实做不了，弃得合理。但列出来是因为：**真上云、真要做无感发版时，"路由权重逐档 + 旧版本留着即时切回"是个早想好的正确机制**，别到时候从零设计。 | |
|
||||
| 运维基建-006 | **四套环境分层（local/dev/staging/prod）+ 数据策略 + 部署方式** —— local=Docker Compose+seed、dev=共享库可重置、staging=生产数据脱敏子集、prod=审批后滚动部署。 | 技术决策版 §7.6 环境管理；开发团队版 §8.2 | 过期/弃用（部分降级现状） | 现实只有两层：**本地 dev（lili-mac）+ 一套 staging（mini-desktop）**，没有独立 dev 联调环境、没有 prod。运维主档讲的就是这套两机现实。所以四套环境是有意降级，不算遗忘。但有一条**约束被一起丢了**：**staging 用"生产数据脱敏子集"**——现行 staging 是空库 + seed 假数据（wave3 定的"可幂等重建"），等真上线后 staging 要不要、怎么用脱敏后的真实数据来验证（暴露真实数据分布下的 bug），是个没人接的运维-合规交叉约束。列出来防止上线时漏掉"staging 数据该像生产"这条。 | |
|
||||
| 运维基建-007 | **Feature Flag 上线稳定 2 周后必须删除，不留死代码** —— Feature Flag 是临时开关，上线稳定后强制清理，admin 后台可开关无需重新部署。 | 技术决策版 §7.9 Feature Flag | 遗落 | 现行档里 feature-flag 用得很多（W-G1 开闸 `aigc.control-plane.enabled`、生成产线 `saaSourceMode`、九门 `GATE_ALL9` 等都是默认关的灰度开关），但**"flag 稳定后必须删除、不留死代码"这条纪律，整棵树没有**。这是个真实的技术债红线——现在已经攒了好几个默认关的 flag（控制平面、源项目模式、客观门），没有任何机制规定它们 flip 之后该不该清、什么时候清。值得在工程规范里补一条"feature-flag 生命周期纪律"，否则死开关只增不减。 | |
|
||||
| 运维基建-008 | **镜像回退保留前 3 个版本、5 分钟内可回退** —— 每次部署保留前 3 个版本镜像，发现问题 5 分钟内镜像回退（`docker compose pull` 指定 tag）。 | 技术决策版 §7.2/§7.6；security-and-reliability §5.2（留一行）；开发团队版 §8.3 方式一 | 过期/弃用（被隔离验证变体取代） | 现行运维主档的回滚机制是**另一套且更适合人工部署**：高风险变更走"隔离端口起新 jar 验全过才切 live、失败用 /tmp 备份 jar 恢复"（staging-ops §3 安全变体）。所以"前 3 版镜像回退"这个 CI/容器化前提的机制被有意识地替换了，不算丢。security-and-reliability §5.2 还留着那一行"保留前 3 个版本镜像"是**与现实脱节的残留**——列出来提示：这行该标注为目标态/已被隔离验证变体取代，免得误导。 | |
|
||||
| 运维基建-009 | **CI/CD 流水线（lint→test→构建镜像→安全扫描→部署 staging→冒烟→审批→滚动部署→健康检查→失败自动回滚）+ 工具选型** —— GitHub Actions + 阿里云 ACR/Harbor + Docker Compose→K8s ArgoCD + Trivy/Snyk 安全扫描 + Checkstyle/ESLint。 | 技术决策版 §7.6 CI/CD；开发团队版 §8.1 | 过期/弃用（明确无自建 CI） | 运维主档已明说"内网阶段没有 docker-compose、也没有自建 CI 流水线"，整条蓝图是目标态。所以弃得明确。但里面**有两件被一起丢掉、且现状真的缺**：① **依赖漏洞 / 镜像安全扫描**（Trivy/Snyk）——现行没有任何机制扫第三方依赖的 CVE，这是个上线前必补的安全门，不只是 CI 的事；② **Checkstyle/ESLint 静态检查门**——现行靠人工 review，没有自动化代码规范门。这两条即便不上完整 CI，也该作为"上线前必须有"的独立约束登记。 | |
|
||||
| 运维基建-010 | **K8s + ArgoCD 作为正式阶段编排/部署目标** —— Docker Compose（MVP）→ K8s ArgoCD（正式）的演进路径。 | 技术决策版 §7.6；§3.2 部署拓扑标题 | 过期/弃用（远期演进，登记） | 现行内网物理机方案明确不上 K8s。K8s/ArgoCD 是远期演进锚，不算遗忘。登记只为留一份"正式阶段编排目标"的索引，免得规模化决策时忘了当年设过这个方向、为什么当时不上（成本盒子 ¥4,300/月撑不起）。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 C：基建组件的运维约束与演进（MySQL/Redis/OSS/MQ/Nacos/Flyway/调度）
|
||||
|
||||
这一块里，数据库高可用、备份恢复、存储演进路径这些**真上量后躲不掉的运维约束**，大多只活在归档长档里，现行档要么只留一行、要么完全没有。MQ/Nacos 的 future-state 状态本身没丢（多处标注了），但"真上它们时的运维形态"在散落各处。
|
||||
|
||||
| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运维基建-011 | **数据库高可用：MySQL 主从（生产）+ 每日全量 + binlog；OSS 跨区域复制** —— 生产 MySQL 走主从、每日全量备份 + binlog 增量；对象存储跨区域复制做容灾。 | 技术决策版 §7.2 可靠性表；security-and-reliability §5.2（留一行"MySQL 主从/每日全量+binlog"） | 遗落（OSS 跨区复制完全丢） | security-and-reliability §5.2 留了"MySQL 主从 + 每日全量 + binlog"一行，所以**数据库高可用没完全丢**；但**OSS 跨区域复制（游戏包/素材的异地容灾）整棵树没有**，而游戏包一旦丢失是不可再生资产（创作者的作品）。更要紧的是：这些**全是"上线前/生产"才落地的约束，运维主档作为"可用性怎么达标"的家，却没有一处汇总"上线前数据保护清单"**（主从切换、备份频率、恢复演练、OSS 容灾）。≥99.5% 可用性 + 数据不丢，这两条硬约束的落地细节是真空。值得在运维档补一份"上线前数据可靠性前置清单"。 | |
|
||||
| 运维基建-012 | **数据备份与恢复作为 compliance 模块技术功能（T-CMP-38）** —— 数据备份与恢复、安全日志与告警（T-CMP-21）被列为 compliance 的技术功能。 | 技术架构与模块 compliance §（T-CMP-21/38） | 不确定 | 现行 `运营/合规闸门.md` 讲的是创作链路的合规门（锁风门/分级/审核），**没有提"数据备份与恢复"这个被挂在 compliance 名下的运维功能**。这条挂得本来就有点怪（备份恢复更像运维而非合规），但既然蓝图把它列为 P0 技术功能，就不该悄无声息消失。列不确定：确认一下数据备份恢复到底归哪——是运维域该接的，还是真的留在 compliance。 | |
|
||||
| 运维基建-013 | **存储演进双写期：事件表 MySQL→ClickHouse、搜索 MySQL FULLTEXT→Elasticsearch** —— 事件流增长期迁 ClickHouse、搜索增长期迁 ES，靠 DAO 抽象 + 双写期平滑迁移。 | 技术决策版 §5.2 存储选型 / §7.10 扩展性 | 不确定（部分覆盖） | ClickHouse 在现行档里有 3 处提及（事件表增长期目标），所以**事件存储演进方向没丢**；但**Elasticsearch（搜索增长期）整棵树没有**，而且**"双写期 + DAO 抽象"这个平滑迁移机制**——它是真做迁移时不停机的关键手法——没沉淀。MVP 单库阶段不咬人。列不确定：是否要在数据模型或运维档留一份"存储演进路线（含双写迁移手法）"，免得增长期重想。 | |
|
||||
| 运维基建-014 | **大表 DDL 用 gh-ost / pt-online-schema-change 不锁表** —— Flyway 迁移规范里，大表结构变更走在线改表工具避免锁表。 | 技术决策版 §7.6 数据库迁移；engineering-conventions §8（已留一行） | 不确定（已覆盖，登记防丢） | engineering-conventions §8 的 Flyway 规范表里**确实留了"大表变更用 gh-ost/pt-osc"这一行**，所以没丢。登记只为提示：这是真上量后数据侧 review 必须知道的约束，现行单库小表阶段休眠，别因为现在不咬人就忘了它的存在。（注：本条与后端数据契约清单 003 同源，两份清单交叉登记。） | |
|
||||
| 运维基建-015 | **RocketMQ 真上线时的运维形态（同步刷盘 + 死信队列 + 延迟消息 + broker IP 配置）** —— MQ 上线的可靠性配置（同步刷盘保不丢、DLQ 兜异常、延迟消息做定时）+ broker `brokerIP1` 内网地址配置。 | 技术决策版 §3.2/§7.2；wave3 review §3.1（broker 容器配置）；security-and-reliability §5.2（留一行） | 不确定 | RocketMQ 整体 future-state、MVP 未部署，这个状态多处标注了，不算丢。但**真上 MQ 时的具体运维形态**（同步刷盘/DLQ/延迟消息三件 + broker 内网 IP 配置 + 死信队列怎么消费）只在归档长档和 security-and-reliability 表里零散留着。等第一个 MQ 消费者落地时这些是必须先想清的运维约束。列不确定：看是否值得在运维或可靠性档留一段"MQ 上线运维前置"。（注：与后端数据契约清单 006 同源。） | |
|
||||
| 运维基建-016 | **Nacos 真上线时的运维形态（3 节点集群 + 配置加密 + 作为配置中心/注册中心）** —— Nacos 生产走 3 节点集群、配置加密存储、承担服务注册发现 + 配置中心 + Feature Flag 热改。 | 技术决策版 §3.2/§5.2/§7.2/§7.9 | 不确定 | Nacos future-state、MVP 未部署 registry/配置中心，状态明确，不算丢。但**真上 Nacos 时的运维形态**（3 节点高可用、配置加密、它一旦成为配置中心后"业务可调参数热改 + Feature-flag admin 后台开关"才成立）没沉淀。现行 feature-flag 全靠 `-D`/yaml + 重部署（无热改），这正是因为 Nacos 没上。列不确定：留一份"Nacos 上线后解锁哪些运维能力"的索引。 | |
|
||||
| 运维基建-017 | **XXL-Job 作为平台调度框架的运维面（admin 控制台部署 + executor 注册 + 在哪台机器跑）** —— 三个结算/补偿 job（tradeSettlementJob/WithdrawPayoutCompensateJob/RewardPayoutJob，全带 @TenantJob）真实运行在 XXL-Job 上。 | 运营/变现端到端.md（job 业务逻辑已详述）；security-and-reliability §4（补偿 job 红线） | 不确定 | XXL-Job 作为调度框架**存在**这件事没丢——运营域详细讲了三个 job 的业务逻辑、param 约定、补偿口径。但**它的运维面是空白的**：XXL-Job admin 控制台部署在哪、executor 怎么注册、这些 T+1 凌晨 job 实际跑在哪台机器上（mini-desktop？6c6g？）、调度可视化/失败重试在哪看——运维主档讲"定时任务落在 6c6g"但那指的是 agent 编排 cron，**不是 XXL-Job 这套业务调度框架**。这是个真实的运维盲区：结算 job 跑不跑得起来、卡了谁发现，没有运维落点。列不确定：运维档是否该补一句"XXL-Job 调度面归属与可见性"。 | |
|
||||
| 运维基建-018 | **生成产物缓存：相同 Prompt hash → 缓存命中 → 跳过 LLM 调用** —— 用 Prompt hash 做生成结果缓存，命中即跳过 LLM 调用，省成本/加速。 | 技术决策版 §7.10 扩展性；AGENTS §8 效率策略 7 | 不确定 | AGENTS §8"缓存昂贵步骤"把这条列为效率策略，且 prefix-cache（new-api 网关前缀缓存，token 级）已 spike 证绿——所以**token 级缓存这条线坐实了**。但**"整个生成产物按 Prompt hash 缓存、命中直接跳过整轮生成"这个更粗粒度的机制**（区别于 new-api 的前缀 token 缓存）在现行档里没有独立落点。两者不是一回事：一个省单次调用的输入 token，一个省整轮生成。列不确定：确认产物级缓存是不是有意只做 token 级、不做整轮级。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 D：隔离 staging 建栈的运维约束（wave3 设计，多数随两机现状漂移但机制有价值）
|
||||
|
||||
2026-06-08 的 wave3 staging review 是历史上**唯一一份系统设计过"在共享机器上安全地拉一套隔离环境"**的文档，里面的约束密度很高。但它有个重要的时空错位：当时设计的是"在 **mini-infra** 共享基建机上拉隔离 staging 栈"，而**现行 staging 实际跑在 mini-desktop 上、用的是 mini-desktop 自己的隔离 MySQL/Redis 容器**（不与 mini-infra 共享基建混）。所以 wave3 那套"在共享机上和现有服务抢内存"的约束，**前提已经变了**——但里面几条**机制**（OOM 优先级保护、全容器内存硬限、磁盘水位告警、代理劫持防护、最小权限 IAM）是任何时候在一台机器上多服务共存都成立的运维红线，现行 staging-ops 里**一条都没有**。值得逐条看哪些该捡进 staging-ops。
|
||||
|
||||
| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运维基建-019 | **OOM 优先级保护：给共存的关键服务设负 oom-score-adj，确保 OOM 优先杀新栈** —— 多服务共享一台机时，给现有关键服务设负 `oom-score-adj`（或给新栈正值），让内核 OOM-killer 优先杀"可重建的新栈"而非"护住的现有服务"。 | wave3 review §2 H1 / §3.1 OOM 保护 | 遗落 | 现行 staging-ops 只有一条"6c6g 禁跑重活（重型前端构建 OOM）"的回避式约束，**没有任何"当多服务真的共存、内存真的紧张时，怎么决定先杀谁"的主动保护机制**。`oom-score-adj` 是 Linux 上唯一能控制 OOM 优先级的杠杆，wave3 把它定为"护住现有服务=铁约束"。mini-desktop 上现在 huijing 单体 + studio + admin + MySQL + Redis 五个服务共存 15G，一旦吃紧内核会随机杀——可能正好杀掉 live 后端。这是个真实的稳定性红线，值得捡进 staging-ops。 | |
|
||||
| 运维基建-020 | **全容器内存硬限 mem_limit + 中间件堆/缓冲池显式限制** —— 每个容器都设 `mem_limit`，MySQL `--innodb-buffer-pool-size`、Redis `--maxmemory`、Nacos `JVM_XMX` 全部显式限制，不让任何单容器按宿主内存自取。 | wave3 review §2 H1 / §3.1 容器表 | 遗落 | 现行 staging-ops 完全没提容器内存限制。wave3 的核心洞察是：**MySQL 默认 innodb buffer pool 会"按宿主自取"**——不显式限，它会吃掉一大块，挤垮同机其它服务。这条和 019 是一对（限额 + 优先级），是"一台机器塞多个服务"的基本功。现行 mini-desktop staging 的 MySQL/Redis 容器有没有设这些限，运维档无从得知。值得捡进 staging-ops 作为"隔离容器起栈的内存纪律"。 | |
|
||||
| 运维基建-021 | **磁盘水位告警** —— 共享单磁盘卷场景下，加磁盘水位告警兜底（与内存限额、OOM 保护并列为三大共享面风险之一）。 | wave3 review §3.1 / §5.1 拓扑图 RES 注 / §6 blast radius | 遗落 | wave3 把"整机内存 + 单磁盘卷"列为隔离栈唯一真实的间接影响面，对磁盘开的兜底是"水位告警"。现行档**整棵树没有任何磁盘水位/disk 相关约束**。mini-desktop 跑 staging + 构建产物 + jar 备份 + 批跑证据 + 日志，磁盘是会涨满的（构建日志、/tmp 备份 jar、批跑 jsonl/png），满了 MySQL 直接挂、构建直接失败。这是个低成本高价值的哨兵，值得捡进 staging-ops。 | |
|
||||
| 运维基建-022 | **代理劫持防护：no_proxy / nonProxyHosts 放行内网网段** —— 机器上挂了 mihomo 之类代理（占 7890/9090）时，必须把 `100.64.0.0/10` 内网网段加进 no_proxy/nonProxyHosts，防 jdbc/redis/nacos 连接被代理劫持。 | wave3 review §3.3 后端接线 | 遗落 | 这是个**极隐蔽的真实坑**：内网机器若装了代理客户端，Java 进程连内网 MySQL/Redis 时可能被代理拦截，表现为莫名其妙的连接失败。wave3 专门记了这条。现行档里 no_proxy 只在生成域的 new-api 调用 skill 里出现过（那是出网调模型的场景），**staging 后端连内网中间件的代理劫持防护整棵树没有**。这条该进 staging-ops，作为"后端接 staging 前的环境检查项"。 | |
|
||||
| 运维基建-023 | **共享 MinIO 的最小权限 IAM policy（Resource 限定到本环境 bucket）** —— 复用共享 MinIO 时，新建 bucket 必须绑只授 `arn:aws:s3:::game-staging/*` 的最小权限 key，评审门核验 policy JSON，防配错越权读写现有对象。 | wave3 review §2 H2 / §3.1 MinIO / §八 D3 | 不确定（前提已变） | wave3 当时的前提是 staging 复用 mini-infra 的共享 MinIO，所以要给最小权限 policy 防越权。**现行 staging 在 mini-desktop 上用隔离容器，对象存储是否还复用 mini-infra 的 MinIO 不确定**——若复用，这条最小权限约束仍成立且现行 staging-ops 没有；若 staging 不碰 MinIO，则这条休眠。这是 §1 SoT《内网凭据与端点》该回答的。列不确定：确认 staging 的对象存储拓扑，再判这条是否捡回。 | |
|
||||
| 运维基建-024 | **healthcheck + depends_on:service_healthy + wait-for-it 启动编排** —— 容器加 healthcheck（mysqladmin ping / redis-cli ping 等），有依赖的容器 `depends_on: {condition: service_healthy}`，后端启动前 `wait-for-it` 探端口就绪。 | wave3 review §2 M / §3.1 healthcheck | 不确定（前提部分变） | wave3 设计这套是为"docker-compose 多容器栈按健康顺序起"。现行 staging 没有 docker-compose（运维主档明说），后端是人工 `start-app.sh` 起、起后验 health 200——**所以"compose 编排 healthcheck"这个形态弃得合理**。但底层意图（"等中间件真就绪了再起后端、别连空库"）现行靠人工验门兜着。列不确定：现状人工验门是否等价覆盖了"启动顺序依赖"，还是仍有"后端起太早连到没就绪的 MySQL"的窗口。 | |
|
||||
| 运维基建-025 | **staging 机密走环境变量占位，不明文入库** —— 连接串密码等用 `${STAGING_DB_PWD}`/`${STAGING_REDIS_PWD}` 环境变量占位，避免明文落库。 | wave3 review §2 M / §3.3 | 过期/弃用（被现行口径取代） | wave3 当时定"机密走环境变量占位、不明文入库"。但**创始人后来立了相反的内网铁律**（memory `internal-network-keys-decisions-in-docs`）：内网阶段所有密钥+决策直接进项目文档 `docs/内网凭据与端点.md`，不靠 env var。所以这条被**有意识地推翻了**——内网阶段为了不被 key 阻塞工作，故意把密钥写进仓内文档。列在过期档是让创始人知道：当年的"机密不入库"洁癖被"内网不设防、写进文档省事"取代了，这是个**清醒的、有代价的权衡**（内网可接受），真到公网上线时要记得把这条翻回来（机密回到 env/Secret，仓内凭据文档清掉）。 | |
|
||||
| 运维基建-026 | **staging 数据定位为"可幂等重建" + 自动化重建脚本（建库+导基表+Flyway）+ 钱财闭环验通后 mysqldump 存档** —— staging 库被定位成随时可丢、靠脚本一键重建（建空库 → 导 huijing 框架基表 → Flyway 迁移），关键验证通过后 mysqldump 备份留证。 | wave3 review §3.1 备份/回滚 / §3.2 建库 | 不确定 | 这套"幂等重建"思路在 staging-ops §3（重部署标准序：git reset → clean install → 验门）里**部分体现**了，但**两件具体的没沉淀**：① 一个真正的"建库+导基表+Flyway"一键重建脚本（现状重部署只重建 jar，不重建库；库是长期累积的，从没被"一键重建"过）；② "关键闭环验通后 mysqldump 存档"的留证习惯（鉴权波 e2e 报告里提过 jar 备份，但库快照备份没成约定）。列不确定：staging 库要不要有"可一键重建"能力（现在它是个长期手工累积的库，一旦坏了没有重建脚本）。 | |
|
||||
|
||||
---
|
||||
|
||||
## 表 E：成本、预算与资本效率
|
||||
|
||||
成本这块的**对账实现层（new-api logs.quota 权威成本）已经坐实**在单位经济敏感性模型里，那部分不算丢。这里列的是**预算约束、成本结构、Runway 这些"框约束"的东西**——它们大多沉淀在投资人版/运营域，但有几条"成本作为运维硬约束反推架构取舍"的逻辑链，和"成本失控的运维兜底"值得单独点出。
|
||||
|
||||
| ID | 设计点（标题 + 一句话） | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运维基建-027 | **MVP 月度基础设施成本明细（¥4,300/月分项）+ 监控/备份/冗余预留 ¥500** —— 云服务器/数据库/OSS+CDN/LLM API/域名 SSL/监控备份冗余的逐项月费拆解。 | 技术决策版 §10.1；投资人版 §7.1 | 不确定（已覆盖，登记防丢） | 运维主档 §1.4 引用了"< ¥5,000/月（约 ¥4,300）"这个总数作为可用性取舍的约束来源，所以**总额口径没丢**。但**分项拆解**（尤其"监控/备份/冗余 ¥500"这一项）只在归档长档里。这条登记是想提示一个**逻辑断点**：预算里**明确预留了 ¥500 给监控/备份/冗余**，但表 A/B 显示监控栈没部署、备份没落地——**这 ¥500 的预算对应的能力其实是空的**。要么这笔预算没花（那现状的可观测性真空就解释了），要么该花。值得创始人对一下账。 | |
|
||||
| 运维基建-028 | **成本约束反推架构取舍的逻辑链（不上云托管/单体而非微服务/人工部署而非重 CI，都是为撑在成本盒子内）** —— ¥4,300/月这个盒子是运维域所有取舍的约束来源。 | 运维 README §1.4（已沉淀此论）；投资人版 §7-8 | 不确定（已覆盖，登记防丢） | 运维主档 §1.4 **已经把这条逻辑链讲清楚了**（"这两个数字是运维域所有取舍的约束来源"），不算遗落。登记只为锚定：这是运维域少数已经写对、写透的地方，作为"成本→架构取舍"这条因果已收口的确认点。 | |
|
||||
| 运维基建-029 | **Runway 18-24 个月 + 融资使用效率分配（研发 40%/算法 20%/扩团队 15%/冷启动 15%/合规 10%）** —— 以 5 人核心团队算 Runway，种子轮 3000 万的用途分配。 | 投资人版 §7.2/§7.3 | 不确定（属投资人/资本域，非运维） | 这条是**资本效率/融资框架**，严格说不属于运维基建领域——它在投资人版里有家。放进来只为边界说明：运维域只管"基础设施成本作为可用性约束"那一面（已收口，见 028），Runway/融资分配不该往运维档塞。**判定倾向：不捡回运维档**，留在投资人/资本域即可。列出来是为穷尽，免得有人误以为它丢了。 | |
|
||||
| 运维基建-030 | **成本失控的运维兜底：生成限频限额 + 日预算熔断告警 + 显式 max_tokens，超额暂停生成入口仅模板兜底** —— LLM 成本被滥刷/推理输出吃光配额时的应对：限频限额 + 日预算熔断 + 超额暂停生成、退化到确定性模板。 | 架构 README §6（已沉淀）；W-G1 开闸门（QUOTA_EXCEEDED/BACKPRESSURE_REJECTED 错误码） | 不确定（已覆盖，登记防丢） | 这条**已在架构 README §6 沉淀**（"日预算熔断告警 + 显式 max_tokens，超额则暂停生成入口、仅确定性模板兜底"），且 W-G1 开闸门里已有 `QUOTA_EXCEEDED`/`GENERATE_PAUSED` 错误码落地。不算遗落。登记只为和表 A-003（缓存命中率哨兵）串起来看：**成本健康监控有两道哨兵——总量阀（日预算熔断，已设计）+ 命中率前哨（缓存 <50% 告警，遗落）**，前者有家、后者没家，是一对。 | |
|
||||
@ -1,86 +0,0 @@
|
||||
# 运维基建 · 第二轮(复核 + 查漏补缺)
|
||||
|
||||
> 这一份是对第一轮《运维基建-历史设计点.md》的二次过手。第一轮把 30 条历史设计点挖了出来、做了分类;这一份不重抄它对的部分,只做三件事:复核它判得准不准(出处真不真、分类对不对),把第一轮之后又落地的一批新设计稿对照过来、标出哪些条目现在已经被覆盖,以及再扫一遍历史源、补第一轮漏挖的设计点。
|
||||
>
|
||||
> 复核的口径和第一轮一致:拿整棵 `docs/architecture/` 域树外加 `.agents/` 一起比对,只有整棵树都没沉淀也没明确弃的才算遗落。这一轮额外多了一批参照系——第一轮之后,创始人 2026-06-21 拍了观测体系、k8s 迁移、数据飞轮、审核台运营四件新设计,加上更早落地的鉴权、沙箱、契约、数据模型、变现端到端五份 P0 设计稿,它们把第一轮当时悬空的不少条目接住了。
|
||||
>
|
||||
> 复核动作做了抽验:挑了第一轮里几条关键条目,用 git grep 回到源档逐字核对出处。结论先说在前面——**第一轮 30 条的出处全部属实,没有一条编造或张冠李戴**;抽验的 001(技术决策版 §3.2 部署拓扑 prometheus:9090/grafana:3001/jaeger:16686)、004(security §6 P0-P3 告警表)、008/015(security §5.2 原样留着的两行残留)、019/020/021/022(wave3 review 的 OOM/内存限/磁盘水位/代理劫持)、003(prefix-cache memory 的 cache_hit_rate<50% 告警)、007(技术决策版 §7.9 的 Feature Flag 两周后删除)、017(变现端到端的三个 job)逐一回源都对得上。所以这一轮的勘误不在"出处错",而在"分类判断要随新档更新"——好几条第一轮标遗落/不确定的,现在该改判成已覆盖了。
|
||||
|
||||
---
|
||||
|
||||
## 一、Review 勘误表:随新档更新的改判
|
||||
|
||||
第一轮的出处和事实判断都经得起核对,真正需要动的是分类——第一轮成稿时,观测体系、k8s迁移、数据飞轮、审核台这几份新档还没落地,所以当时判"遗落/不确定"是对的;现在这些档落了,对应条目的判定要往前挪一格。下面这张表只列**判定档位变了**的条目,没变的不重列。
|
||||
|
||||
| ID | 原判 | 新判 | 为什么改 |
|
||||
|---|---|---|---|
|
||||
| 运维基建-001 | 遗落 | **已被新档覆盖**(详见第二块) | 第一轮判遗落的核心理由是"运维主档对可观测性现状留白"。观测体系.md 和 k8s迁移.md 落地后,这条不再悬空——观测体系档 §1 开篇就明确写了"蓝图画过 Prometheus/Grafana/Jaeger,MVP 现实从未起过(运维基建-001)",并给了从无到有的完整设计;运维主档 §4 也补了立位。从"留白"变成"有正式设计稿在补",该归覆盖。 |
|
||||
| 运维基建-002 | 遗落 | **已被新档实质覆盖**(详见第二块) | 第一轮判遗落,理由是"telemetry 内建的服务/生成/Runtime 三维健康监控被域化重构压扁成一句话"。观测体系档把这套健康监控的**监控目标全部接住了**,只是实现路径从"telemetry 模块内建"换成了"OTel 外部观测":生成成功率→`gen_task_total{status}`、九门健康→`gen_gate_fail_total{gate}`、队列积压→`gen_queue_depth`、Runtime/服务健康→服务层指标。诉求(平台业务级健康有没有人盯)已被满足,判覆盖。下面第二块会说清它和 002 原始设想的差别。 |
|
||||
| 运维基建-003 | 遗落 | **已被新档覆盖** | 观测体系档 §3.2 把"缓存命中率<50% 告警"这个成本早期哨兵显式接进了 `llm_cache_hit_rate` 指标,§3.4 告警表把它落进 P2 级,且原样引用了运维基建-003。从"没有落点"变成"有指标有告警级",归覆盖。(注:成本数据源仍待 logs.quota 薄片落地,这是实现待办,不影响分类——设计上已有家。) |
|
||||
| 运维基建-004 | 不确定(已覆盖,登记防丢) | **已被新档覆盖**(升格) | 第一轮说它"是张纯文档表、没有通道真接上"。观测体系档 §3.4 正是冲着这个空补的——夜莺(Nightingale)把 P0-P3 表落成真的告警规则和真的通道,webhook 密钥进《内网凭据与端点.md》。从"登记防丢的纯文档表"升格为"有正式设计把它变成真东西",归覆盖。 |
|
||||
| 运维基建-019 | 遗落 | **已被新档覆盖** | OOM 优先级保护。k8s迁移.md §2 目标2、§5"新增 k8s 侧运维门"把它的意图用 k8s 原生机制实现了——kubelet 的 `--eviction-hard` 驱逐阈值 + QoS 分级,让 OOM 时优先驱逐辅助 workload 而非后端,并原样引用运维基建-019。机制从 `oom-score-adj` 换成 k8s 驱逐,意图一致,归覆盖。 |
|
||||
| 运维基建-020 | 遗落 | **已被新档覆盖** | 全容器内存硬限。k8s迁移.md 用每个 workload 的 requests/limits 实现(后端 requests 2Gi / limits 2.5Gi、QoS Burstable),§5 明写"把运维基建-020 的容器内存硬限用 k8s 原生实现",docker-compose 过渡期等价手段是 mem_limit。归覆盖。 |
|
||||
| 运维基建-021 | 遗落 | **已被新档覆盖** | 磁盘水位告警。两份新档都接住了:k8s迁移.md §5 把它列进"新增的 k8s 侧运维门"(local-path PV + 镜像层 + 构建产物吃 75G 磁盘),观测体系档 §3.4 把"磁盘水位>80%"落进 P3 告警,均引用运维基建-021。归覆盖。 |
|
||||
| 运维基建-026 | 不确定 | **部分被新档覆盖、剩余收敛** | 第一轮的"staging 可幂等重建"。k8s迁移.md 风险三明确把这条当现状前提引用("staging 库现在是长期手工累积、从没被一键重建过,运维基建-026"),并据此做出"数据库永远留在集群外、绝不和应用迁移同期搬"的设计裁决。所以这条不再是悬空疑问,而是被新档当成一个已知约束消费掉了——"该不该有一键重建能力"的答案现在是"先不动它、等应用层在集群里稳定数个迭代后单独评估"。判定从"不确定"收敛为"已被 k8s 迁移档纳入决策"。 |
|
||||
| 运维基建-027 | 不确定(已覆盖,登记防丢) | **逻辑断点已被新档接住** | 第一轮点出的逻辑断点是"预算留了 ¥500/月监控/备份,但能力是空的"。观测体系档 §1 缺口三、§6 待核都把这条对上了账:明写"预算里留了 ¥500/月给监控/备份,但这笔钱对应的能力一直是空的(运维基建-027)",并把"这套观测栈的存储够不够 ¥500/月"列为待创始人对账项。断点从"没人接"变成"新档点名待拍",归覆盖。 |
|
||||
|
||||
> 一处要单独说明的复核结论(不算改判,是确认):**运维基建-008 仍准确**。第一轮说 security-and-reliability §5.2 那行"保留前 3 个版本镜像、5 分钟回退"是与现实脱节的残留、该标注为目标态。回核确认它**至今原样留着、没标注**(§5.2 line 122)。而 k8s迁移.md 现在给了它一个更好的归宿——`kubectl rollout undo` 一键回退上一个 ReplicaSet,正是"保留前 N 版镜像回退"这个机制在 k8s 时代的原生实现(§5"重启/切流量"段)。所以 008 的状态可以更新为:机制已被 k8s rollout 取代,security §5.2 那行残留仍待标注。同理 **015**(RocketMQ 同步刷盘+死信队列)回核确认 security §5.2 line 121 仍原样留着,第一轮判断不变。
|
||||
|
||||
---
|
||||
|
||||
## 二、已被新档覆盖的第一轮条目(逐条列出被哪份档覆盖)
|
||||
|
||||
这一块把"第一轮标遗落/不确定、现在被新档接住"的条目集中起来,讲清被哪份新档的哪一段覆盖、覆盖到什么程度。重点是区分"诉求被满足"和"实现已落地"——下面这些都是**设计上有家了**,实现待办不影响"不再是悬空遗落"这个判断。
|
||||
|
||||
| ID | 第一轮判定 | 被哪份新档覆盖 | 覆盖说明 |
|
||||
|---|---|---|---|
|
||||
| 运维基建-001 | 遗落 | **观测体系.md(全篇)+ k8s迁移.md §1 + 运维README §4** | 可观测栈从未部署、现状留白这条,现在有了一份从 OTel 采集到 Grafana/夜莺看板告警到 admin 入口的完整设计稿,部署落点跟 k8s 迁移走。这是第一轮最大的一块遗落,现已被正面补上。 |
|
||||
| 运维基建-002 | 遗落 | **观测体系.md §2 + §3.2** | telemetry 三维健康监控的监控目标被观测体系档接住,实现路径从"模块内建"改为"OTel 外部观测"(生成成功率/九门失败/队列积压/Runtime 健康全部落成具体指标埋点)。下方有一条"覆盖方式变了"的提示。 |
|
||||
| 运维基建-003 | 遗落 | **观测体系.md §3.2(llm_cache_hit_rate)+ §3.4(P2 告警)** | 缓存命中率<50% 哨兵从无落点变成有指标、有告警级。 |
|
||||
| 运维基建-004 | 不确定 | **观测体系.md §3.4(夜莺把 P0-P3 表落成真规则真通道)** | 告警升级链从纯文档表升格为有设计把它变真。 |
|
||||
| 运维基建-019 | 遗落 | **k8s迁移.md §2 目标2 + §5(kubelet eviction + QoS)** | OOM 优先级保护用 k8s 驱逐机制实现。 |
|
||||
| 运维基建-020 | 遗落 | **k8s迁移.md §4 阶段2(requests/limits)+ §5** | 容器内存硬限用 k8s requests/limits 实现。 |
|
||||
| 运维基建-021 | 遗落 | **k8s迁移.md §5 + 观测体系.md §3.4(P3 磁盘水位>80%)** | 磁盘水位告警两份档都接,既是 k8s 运维门、又是观测告警规则。 |
|
||||
| 运维基建-026 | 不确定 | **k8s迁移.md 风险三** | staging 可幂等重建被当已知约束消费,据此裁定"数据库不进集群"。 |
|
||||
| 运维基建-027 | 不确定 | **观测体系.md §1 缺口三 + §6 待核** | ¥500/月预算对空能力的逻辑断点被点名、列为待创始人对账。 |
|
||||
|
||||
**一条要写明的覆盖方式差别(运维基建-002)。** 002 原始设想的是"telemetry 模块自己内建一套服务/生成/Runtime 三维健康监控 + 异常检测告警",是平台**业务进程内**的能力。观测体系档没有照这个路走,而是用 OTel + Grafana + 夜莺从**外部旁路**把同样的监控目标观测出来——生成成功率、Runtime 崩溃率、队列积压这些"业务级健康",现在是 Worker/控制平面/九门节点埋 Micrometer 指标、被 Prometheus 采走、在 Grafana 看、由夜莺告警。监控目标一致、覆盖更全(还多了基础设施层和前端层),但**实现归属换了**:从"telemetry 模块的内建功能"变成"观测体系的外部采集"。这对创始人的意义是:002 当年担心的"平台业务健康没人盯"这个诉求被满足了,而且换成了更标准、更解耦的实现路径——不需要 telemetry 模块再单独建一套内观测,直接埋点喂给统一观测栈即可。所以判覆盖,但要知道它不是"按 002 原样实现"、是"诉求被一个更好的方案吸收"。
|
||||
|
||||
**未被新档覆盖、第一轮判定仍成立的条目(简列,不重抄理由)。** 下面这些第一轮挖出的条目,回核后确认新档没有触及、判定不变,仍待创始人处置:
|
||||
|
||||
- **运维基建-005**(按百分比灰度发布机制)——过期/弃用,机制可捡回;新档未触及,仍是"真上云做无感发版时该捡回的早想好机制"。
|
||||
- **运维基建-006**(四套环境分层 + staging 用生产数据脱敏子集)——k8s迁移.md 反而强化了"现实只有 lili-mac 本地 dev + 一套 mini-desktop staging、不碰 prod"(§2 范围外引用 006),但"staging 数据该像生产(脱敏子集)"这条运维-合规交叉约束仍无人接。
|
||||
- **运维基建-007**(Feature Flag 上线稳定 2 周后删除)——遗落,新档未触及。值得一提:观测体系和审核台档又新增了一批默认关的 feature flag(阿里云内容安全 flag、观测埋点 profile 开关),flag 生命周期纪律的缺口比第一轮成稿时更大了。
|
||||
- **运维基建-009**(CI/CD 流水线 + 依赖漏洞扫描 Trivy/Snyk + Checkstyle/ESLint 门)——过期/弃用,但"依赖 CVE 扫描"和"静态检查门"两条上线前必补的独立约束,新档未触及。k8s迁移.md §5 只继承了现有冒烟门/构建门,没有新增安全扫描门。
|
||||
- **运维基建-010**(K8s+ArgoCD 远期编排)——状态有变但不算覆盖:创始人 2026-06-21 已定本阶段就上 k8s(单节点 k3s),所以"K8s 作为编排目标"从远期演进锚变成了正在做的事;但 ArgoCD(GitOps 声明式部署)那一层 k8s迁移.md 明确没上(用的是 ctr import + kubectl apply/rollout),ArgoCD 仍是远期。
|
||||
- **运维基建-011**(MySQL 主从 + OSS 跨区复制 + 上线前数据保护清单)——遗落,新档未触及。k8s迁移.md 有意把数据库留在集群外、不碰有状态数据迁移,所以"上线前数据可靠性前置清单"(主从/备份/恢复演练/OSS 容灾)这块仍是真空。
|
||||
- **运维基建-012**(数据备份恢复挂 compliance 名下,归属存疑)——不确定,新档未触及。审核台运营.md 讲的是内容审核,没碰"数据备份恢复"这个挂在 compliance 名下的运维功能,归属仍未厘清。
|
||||
- **运维基建-013**(事件表→ClickHouse、搜索→ES 双写迁移)——不确定,回核确认运维域和数据模型档都没触及"双写期+DAO 抽象"这个平滑迁移机制,ES 整棵树仍没有。
|
||||
- **运维基建-014**(大表 DDL 用 gh-ost/pt-osc)——已覆盖登记防丢,回核确认 engineering-conventions §8 Flyway 规范表 line 215 仍留着这一行,判定不变。
|
||||
- **运维基建-015**(RocketMQ 上线运维形态)——不确定,新档未触及,future-state 状态不变。
|
||||
- **运维基建-016**(Nacos 上线运维形态)——不确定,回核确认 k8s迁移.md 完全没触及 Nacos(明确 mini-infra 共享基建不进集群),Nacos 仍是 future-state,"上线后解锁哪些运维能力(配置热改/Feature-flag admin 开关)"仍无落点。
|
||||
- **运维基建-018**(产物级缓存,Prompt hash 整轮跳过)——不确定,新档未触及,与 token 级 prefix-cache 的区分仍未确认。
|
||||
- **运维基建-022/023/024/025**(代理劫持防护 / MinIO 最小权限 IAM / healthcheck 启动编排 / 机密走 env)——这四条是 wave3 staging 建栈约束。k8s迁移.md 把部署形态整个换成 k3s,对它们的影响要分别看:022(no_proxy 防代理劫持)新档未触及、仍是后端接 staging 前的环境检查盲区;023(MinIO 最小权限)前提仍取决于 staging 对象存储拓扑、未变;024(healthcheck/depends_on)在 k8s 下被 liveness/readiness 探针替代——k8s迁移.md §4 阶段2 的探针设计实质接住了"等中间件就绪再起后端"这个意图,可视为机制层覆盖(但 k8s 档没有显式引用 024);025(机密走 env)第一轮已判被内网铁律推翻,不变。
|
||||
|
||||
---
|
||||
|
||||
## 三、查漏补充清单(第一轮漏挖的新设计点)
|
||||
|
||||
再扫一遍历史源(技术决策版 §7 全章、开发团队版 §10 外部工具、wave3 review、风险表)和第一轮之后新落地的设计稿,补第一轮漏掉的设计点。编号接第一轮续(从 031 起)。重点放在跨域交叉地带——第一轮聚焦在"部署/回滚/可观测/基建组件"这条主轴上,漏掉的几条恰好都在运维与生成域、运维与数据域的交界处,是"两边都以为对方会管"的盲区。判定列留空给创始人裁。
|
||||
|
||||
| ID | 设计点(标题 + 一句话) | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运维基建-031 | **LLM 网关(new-api)多通道健康巡检 + key 激活状态监控 + 批跑冻结阀** —— 生成命脉 new-api 网关的运维面:多通道健康巡检、单 key 激活/失效状态监控、通道批量失效时的批跑冻结阀,失效时单通道降级运行。 | 架构 README §6 风险12(只一句应对策略);技术决策版 §8 风险12/R8;memory `generation-spike-c1-result`(二厂系批量失效真实发生) | 遗落 | 这是第一轮整个漏掉的一块,且是真盲区。架构 README §6 风险表里**只有一句话**列了应对手段("多通道健康巡检 + key 激活状态监控 + 同模型降级抽检 + 批跑冻结阀"),但它是"风险应对策略"的一句概括,**没有任何运维落点**——谁来巡检、巡检什么指标、多久一次、key 失效怎么触发告警、批跑冻结阀由谁拉、降级到单通道靠什么判定,整棵树没有展开。关键是这个风险**2026-06 已经真实发生过**(二厂系通道全废),不是假想。观测体系档讲的是"业务调 new-api 这次调用"的 trace 和耗时(被观测对象是业务侧),**不覆盖 new-api 网关自身的多通道健康与 key 失效巡检**——这俩是两回事:一个是"我调网关慢不慢",一个是"网关背后的通道还活着几条、key 还有效吗"。生成是平台命脉,网关一旦通道批量失效,生成直接全停。运维域该回答"这条命脉的健康谁在盯、失效了谁第一时间知道",现行只有一句飘在风险表里的应对策略。值得在观测体系或运维档补一段"LLM 网关健康巡检"——它和生成成功率告警是互补的两层:成功率<70% 是结果已经坏了(P1),通道健康巡检是结果坏之前的前哨。 | |
|
||||
| 运维基建-032 | **平台后台 job 调度面的整体运维归属(XXL-Job admin 控制台 + executor 注册 + 在哪台机跑 + 失败可见性)——范围已扩到新增的离线 job** —— 平台现在有一批后台批处理/聚合 job(结算/打赏发放/打款补偿三个 trade job + telemetry 日聚合 job + 数据飞轮离线归档 job),它们的调度面运维(admin 控制台部署在哪、executor 怎么注册、跑在哪台机、卡了谁发现、调度可视化在哪看)整体是空白的。 | 变现端到端.md(三个 trade job 业务面);后端数据模型.md §2.3(telemetry 日聚合);数据飞轮.md §3.3(离线归档 job);security-and-reliability §4(补偿 job 红线) | 遗落(第一轮 017 的范围扩展) | 这条**不是重复第一轮 017**——017 只点了"三个结算 job 的运维面空白"。第一轮之后落地的两份新档把这个空白**扩大了**:数据飞轮.md §3.3 明确设计了"一个离线 job 定期把三源 join 出来落档",后端数据模型档讲了 telemetry 的日聚合 job,但这两类**新 job 同样只给了业务逻辑、没给运维落点**。把它们和 017 的三个 trade job 合起来看,真正的问题浮出来了:平台有一整批后台 job(已落地的三个 trade job + telemetry 聚合 job,加上待建的飞轮归档 job),而"这些 job 跑在哪台机、XXL-Job admin 控制台部署在哪、executor 注册、T+1 凌晨 job 卡了谁发现、调度可视化/失败重试在哪看"——这个**调度面运维归属作为一个整体,整棵树没有落点**。运维主档讲"定时任务落在 6c6g"但那指 agent 编排 cron,不是 XXL-Job 这套业务调度框架。这是个会真咬人的盲区:结算 job 跑不起来=创作者拿不到钱、飞轮归档 job 卡住=语料断供,都没有运维落点去发现。建议升级为一条独立设计——"平台后台 job 调度面"该有一份运维归属说明(哪台机跑 executor、admin 控制台落点、失败告警怎么接进观测栈),覆盖现有 + 新增的全部 job。注:与第一轮 017 同源同主题,这一条是把它从"三个 trade job"扩成"全平台 job 调度面 + 新增离线 job",建议两条合并由创始人统一裁。 | |
|
||||
| 运维基建-033 | **safe-content-ai 自部署快检的部署运维形态(部署在哪台机 / 占什么端口 / 随哪个栈起 / 谁维护)** —— 内容安全第一层自部署快检模型 safe-content-ai 作为一个要自部署的服务,它的部署落点、端口占用、随哪套栈启动、资源占用、谁维护,现行没有运维落点。 | 开发团队版 §10 外部工具(safe-content-ai localhost:8200,future-state);审核台运营.md §3.2(讲了能力与接缝、未讲部署) | 不确定 | 审核台运营.md 把 safe-content-ai 的**能力面和接缝**讲透了(它是什么、第一层挡大面、第一期真跑、原子接进锁风门聚合),但它作为**一个要自部署的服务的运维形态**——部署在哪台机(mini-desktop?另起?)、占什么端口、随哪套栈启动、吃多少资源、谁来维护——没有落点。开发团队版 §10 给过一个 future-state 端点 localhost:8200,但那是蓝图态。这条偏 compliance 模块的部署细节,价值边际:审核台档"第一期快检真跑"已隐含它要被部署,真到部署时归 staging-ops 登记一行即可。列不确定而非遗落,是因为它更像"等真部署时顺手补一行"而非"想清楚过的好东西丢了"——但既然它是内容安全的第一道闸、且要自部署,登记一下防止它在"接缝已设计"的错觉下连部署落点都没人接。 | |
|
||||
| 运维基建-034 | **观测栈引入后的数据保留期作为运维-成本交叉约束(trace/metrics 存多久 × ¥500/月预算够不够)** —— OTel 观测栈落地后,trace 后端和 Prometheus 指标的保留期没定,而 trace 数据量大、直接吃 mini-desktop 的 75G 磁盘和那笔 ¥500/月监控预算,保留期与预算是一对要一起拍的运维约束。 | 观测体系.md §6 待核(trace/metrics 保留期没定);security-and-reliability §6(只定了日志 ERROR/WARN 90 天/INFO 30 天) | 不确定(新档已自列待核,登记串联) | 这条**观测体系档自己已经列进待核了**(§6"观测数据保留期与成本"),严格说不算第一轮漏挖。登记进来是为了把它和第一轮的 027(¥500/月预算对空能力)、021(磁盘水位)**串成一条线给创始人**:观测栈一旦真跑,trace/metrics 的存储就开始吃磁盘和预算——日志保留期 security §6 定了(ERROR/WARN 90 天),但 trace 和 metrics 的保留期是空的,而 trace 恰恰是数据量最大的一类。这意味着 027 那笔 ¥500/月的账,现在有了具体的消耗项(观测栈存储),但够不够还没算。三条(027 预算空账 + 034 保留期未定 + 021 磁盘水位)是同一个"观测栈落地后的资源-成本闭环"的三个面,建议创始人一起对账:观测栈的数据保留策略定下来,这笔预算才算得清。判定倾向:不算新遗落(新档已列待核),但作为 027 的具体化登记防丢。 | |
|
||||
|
||||
---
|
||||
|
||||
## 收尾:这一轮的净增量
|
||||
|
||||
复核确认第一轮 30 条出处全实、事实判断全部经得起核对,真正的变化集中在分类——**9 条**(001/002/003/004/019/020/021/026/027)随观测体系、k8s迁移两份新档落地从"遗落/不确定"改判为"已被覆盖",其中 002 是"诉求被一个更好方案吸收"(从 telemetry 内建改为 OTel 外部观测)、不是按原样实现,这点要让创始人知道。
|
||||
|
||||
查漏净挖出 **4 条**(031-034),最该看的是两条真盲区:**031 LLM 网关多通道健康巡检**——生成命脉的健康在现行档里只有一句飘在风险表的应对策略、没有运维落点,而通道批量失效 2026-06 已真实发生过;**032 平台后台 job 调度面**——它是第一轮 017 的范围扩展,数据飞轮和 telemetry 又引入了新的离线 job 却同样没给运维落点,把"一整批后台 job 跑在哪、卡了谁发现"这个盲区暴露得更彻底,建议和 017 合并由创始人统一裁。033(快检部署落点)、034(观测栈保留期-预算交叉)是两条边际登记,价值不高但登记防丢。
|
||||
|
||||
一句话给创始人:第一轮挖得准、出处都实;这一轮把新档接住的 9 条划掉,真正还悬着的运维盲区收敛到两处——**LLM 网关的健康谁在盯、平台那一批后台 job 的调度面归谁管**,这两条都是"命脉级但无人接"的,值得优先拍。
|
||||
@ -1,104 +0,0 @@
|
||||
# 运营变现合规 · 历史设计点回收清单
|
||||
|
||||
这份清单做的是一次"翻旧账"——把绘境AI 在运营、变现、合规、渠道发行这条落地链上，**历史文档里讨论过、但现行 `docs/architecture/运营/` 五份档没有沉淀下来**的设计点、想法、顾虑、约束，逐条挖出来摆在台面上。目的不是评判，而是防遗漏：避免现行架构漏掉历史上认真想过、本该继续考虑的约束，也让那些"想过但决定不做"的方向留个痕，省得日后有人再从头讨论一遍。
|
||||
|
||||
判定口径三档：**遗落**=历史上是个被讨论过的好想法、或一条该考虑的约束/顾虑，现行档没讲、也没被明确弃，这是回收的重点；**过期/弃用**=历史上讨论过但已被明确决定弃用或取代，列出来是让创始人知道它被想过、为什么没走；**不确定**=拿不准现行档到底覆盖没、或只覆盖了一半。现行档已经讲清楚的，一律不列。
|
||||
|
||||
**我扫过的历史文档**（按价值排序）：三向审计 `2026-06-10-架构文档三向审计-review.md`（四颗雷 R1-R4 的源头）、`docs/memorys/2026-06-08-技术护城河复盘.md`（六项能力对照 + IP 三轮压力测试）、demo 审计 `2026-06-17-demo与三文档套件缺口冲突审计-review.md`、Wave3 创作补全与发布闸门 review（compliance/审核台模块设计）、M4 变现真实化 review、`docs/mvp/全成本收益测算模型-v2.md`（16.6 万投入/15 月回本的第二套经济模型）、`docs/mvp/单位经济敏感性模型.md`、律所合规咨询 brief、A1 闸门看板、`docs/mvp/可行性方案16周-波次映射.md`（Token 计费/隐式水印/审核 SOP/留存门）、以及 `docs/architecture/_archive/` 下的投资人版、护城河话术双版本、技术决策版、开发团队版、技术架构与模块四份长档。
|
||||
|
||||
**与兄弟清单的边界**：同目录的 `产品战略-历史设计点.md` 已经收了竞品数据核查、IP 护城河战略、玩家获客通路、单位经济测量计划、B 端 32 模板承诺、P0 范围调整、对外诚信债这一类**战略/产品层**的遗落点。本清单只收**运营执行层**——变现工程与资金红线、渠道发行的合规执行、合规闸门的执行细节、审核台运营机制、Token 计费方案、成本测算缺口、运营 SLA。凡是战略层的，本清单只在必要处指一句"它的家在产品战略清单"，不重复展开。
|
||||
|
||||
---
|
||||
|
||||
## 一、变现工程与资金一致性（多为已沉淀，留几条工程红线与待裁口径）
|
||||
|
||||
现行《变现与单位经济》《变现端到端》两份档对收益闭环、七个资金动作的幂等键、四条资金一致性红线写得相当完整。下面是历史里讨论过、但没进现行档、或现行只覆盖一半的几条。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运营变现合规-001 | **mock 不变式：接真实联盟前必须先定 `revenue_amount` 存毛额 G 还是净额 N** —— 当前 MVP 下渠道扣率为 0（G==N），一旦接真广告联盟，若这列存的是毛额，trade 侧就得先 ×(1−渠道扣率) 再 ×创作者份额，否则违反 R3 公式、历史快照也无法回算 | 变现与单位经济 §5-4；M4 review | 不确定 | 这条在现行《变现与单位经济》§5 和《变现端到端》§6 都有写，**算已沉淀**；但它是"支付真实化的阻塞前置项"，标不确定是因为它埋在资金红线列表里，没有作为"接真广告联盟第一件要先拍的事"被显著标出。接真联盟前若漏了它，账面会在切渠道那一刻系统性错位 | |
|
||||
| 运营变现合规-002 | **回调丢失要有对账补偿 job 主动去查支付方真实状态** —— 打款"发起≠到终态"，万一 pay notify 回调丢失，钱会卡在 frozen，必须有定时任务扫 `status=1` 超时单、主动查支付方状态来补推进度（幂等 CAS 防重复） | 变现与单位经济 §5-1；变现端到端 §2.4 | 不确定 | 现行《变现端到端》§2.4 已落地为 `WithdrawPayoutCompensateJob`（卡单阈值 15 分钟）——**已沉淀**。标不确定是想确认：这个补偿 job 在真实微信企业付款接入后，查询接口、对账锚点 `transfer_ref` 是否都对得上，现行档只在 mock 口径下验过 | |
|
||||
| 运营变现合规-003 | **B 端收款/在线签章/分账整段在 16 周关键路径上，周 13-16 要真兑付，分账准确率要求 100% + 月度账单** —— 可行性方案把"首次真实分账兑付"作为阶段四（13-16 周）的硬交付，分账准确率 100%、出月度账单 | 可行性方案16周 §阶段四；§阶段二 | 遗落 | 现行《变现端到端》§4 把 B 端收款/分账整段都"留在 M4"，措辞是延期；但**可行性方案明确它在 16 周关键路径上、有"100% 准确率 + 月度账单"的验收口径**。现行档丢了这个"它不是可无限延的事、有明确兑付窗口和准确率门"的紧迫性与验收标准。分账在真钱面前，准确率不是"尽量"而是硬指标 | |
|
||||
| 运营变现合规-004 | **Token 计费体系有完整规则：1 Token = ¥0.1、有免费额度、超额可购买** —— 可行性方案给了创作者侧 Token 计费的完整定价规则（额度/免费/超额购），不是只有"配额只减不增"这一句 | 可行性方案16周 §阶段一；M4 范围扩 | 遗落 | 现行《变现与单位经济》只讲了"生成计费平面走 new-api 配额、只减不增"，**但 1T=¥0.1 的定价、免费额度怎么发、超额怎么买这套面向创作者的计费产品规则完全没沉淀**。这是订阅/充值收入线落地时绕不开的定价基座，被支付通道阻塞推迟了，但规则本身想清楚过，不该丢 | |
|
||||
| 运营变现合规-005 | **Token 对外试点要限种子创作者 + 单日充值上限** —— 阶段三 Token 对外试点时，限定只给种子创作者、且设单日充值上限 | 可行性方案16周 §阶段三 | 遗落 | 这是一条具体的**风控/灰度约束**（单日充值上限），现行变现档没记。真钱试点时没有充值上限，是资损/洗钱风险敞口。属于"接真钱前该先想到的护栏" | |
|
||||
| 运营变现合规-006 | **per-creator token 本质是支付工具，绝不能明文落进 `game_player` 表** —— 给每个创作者发的生成额度 token 是钱的凭证，明文入库等于把支付密钥摊开 | 变现与单位经济 §3-P0 红线 | 不确定 | 现行《变现与单位经济》§3 已经写了这条红线——**已沉淀**。标不确定是因为它和"new-api admin API 无法替他人铸 token、要重设计凭证引导流程"这个可行性硬阻塞是连体的，现行档把后者写在 §6 待办里，但两者作为"开通创作者账户前必须一起解决的一组前置"没有被绑在一起讲 | |
|
||||
| 运营变现合规-007 | **支付→配额不是本地事务，真实机制是三方对账（微信交易号 ↔ 平台订单 ↔ new-api 充值记录）** —— new-api 的 `top_ups.trade_no` 是 UNIQUE 幂等锚 | 变现与单位经济 §6；变现端到端 | 不确定 | 现行《变现与单位经济》§6 待办里有这句——**已沉淀**。标不确定是想确认：这个三方对账的失败补偿、对账差处理，在订阅/充值真做的时候有没有对应的设计，现行只点了"是三方对账"这个事实，没给对账失败时的兜底路径 | |
|
||||
|
||||
---
|
||||
|
||||
## 二、广告与计费机制（一条被降级的优化能力 + 几条反作弊红线）
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运营变现合规-008 | **广告位 AI 优化 / AI 自动植入 / eCPM 优化** —— 基于玩家行为数据优化广告植入的时机和格式来提升 eCPM；技术侧有 T-AD-01「广告位 AI 自动植入」、T-AD-07「eCPM 优化」、T-AD-09「归因」，产品侧 P-ADV-08「AI 广告位优化建议」 | 投资人版 §4.3-4；技术架构与模块 T-AD-01/07/09；产品需求清单 P-ADV-08（P2/v2.0） | 过期/弃用 | 这是投资人版列的四层技术护城河之一（"广告位 AI 优化"），技术架构里有完整的 T-id 承载，**但产品侧已主动降到 P2 / v2.0**（P-ADV-08）。列出来是让创始人记得：广告变现侧本来设计过一条"用行为数据优化广告时机/格式 → 抬 eCPM"的能力线，现在有意排到了 MVP 之外。它对单位经济（eCPM 是回本测算最敏感的变量）有直接杠杆，未来真要抬 IAA 收入时这是第一个该捡回的优化项 | |
|
||||
| 运营变现合规-009 | **激励视频 `rewarded=true` 只认平台返回的"完整观看"回调，兜底发奖必须标 `reward_fallback=true`，绝不能把兜底奖励伪装成真实广告收益** —— 渠道侧广告变现的反造假红线 | 渠道发行 §5.2 / 归档 canonical §3 | 不确定 | 现行《渠道发行》§5.2 写了这条——**已沉淀**。标不确定是因为它只出现在渠道发行档，而自有 H5 流的广告计费（《变现端到端》§2.1）也提了"激励视频按 reward 口径单独计、避免双算"，但"兜底发奖必须显式标记、不得伪装成真实收益"这条防造假红线没有在自有端这一侧同样钉死。两条发行线的广告防造假口径应该一致 | |
|
||||
| 运营变现合规-010 | **广告计费降级口径"宽松"、打款降级口径"严格"，两者方向相反，必须分开守** —— 没注册真实广告渠道时降级 mock 可接受（只少算收入）；但打款渠道缺失若降级 mock 就是把假钱当成功发出去，必须 fail-fast | 变现端到端 §2.1/§2.4；M4 review §2.3 | 不确定 | 现行《变现端到端》两处都写了——**已沉淀**。这里标不确定是想强调这条"同样是降级、口径却相反"的设计意图很容易在后续维护中被一个图省事的 try-catch 抹平（比如统一加个"失败就降级 mock"的兜底）。它值得作为一条独立的红线被显著标注，而不只是散在广告和打款两节里 | |
|
||||
|
||||
---
|
||||
|
||||
## 三、合规闸门的执行细节（法定闸门已讲清，留几条被法定 8 项盖住的执行件）
|
||||
|
||||
现行《合规闸门》把 12+1 道闸门、死锁三条链、双层定性讲得很透。但 A1 闸门看板里有几项不在"8 法定 + 3 审计 + 1 律所"那个框架里、容易被盖住的执行件，以及历史里讨论过的法律细节。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运营变现合规-011 | **隐私协议/用户协议、内容合规材料是两道独立闸门（A1 看板 #7/#8），不在"法定 8 项"里** —— #7 隐私/用户协议（占位文案可过渡，正式拉新前法务定稿）、#8 内容合规材料（审核制度文本 + 审核记录留存机制说明，渠道提审与 ICP 经营性升级都会要） | A1 闸门看板 #7/#8 | 遗落 | 现行《合规闸门》§3 把闸门讲成"8 法定 + 3 审计 + 1 律所 = 12+1"，**但 A1 看板实际有 #7 隐私协议、#8 内容合规材料两行，它们既不在 8 法定也不在 3 审计里**。读《合规闸门》的人会以为闸门只有那 12 项，漏掉这两道。隐私协议是注册前就要展示的、内容审核制度文本是渠道提审硬要的，都不能漏 | |
|
||||
| 运营变现合规-012 | **灰测合规出口=测试人数 ≤ 2 万人 + 不接广告 + 报备并删档，写进发布流程红线** —— 依据《网络游戏管理办法（草案）》第 21 条"公测=运营"（截至 2026-06 仍草案未生效）；种子创作者外测只要挂了广告就构成"运营"，必须先备案 | 渠道发行 §3.3 / 归档 canonical §2-3；可行性方案16周 §风险旗 | 不确定 | 现行《渠道发行》§3.3 有这条——**已沉淀在渠道档**。标不确定是因为它其实是一条约束**整个灰度测试节奏**的红线（"种子外测挂广告即属运营、备案须在外测前完成"），影响的是运营排期，却只躺在渠道发行档里。自有端邀请制内测要不要也守"≤2 万人 + 不接广告"这条，《合规闸门》没明确接住 | |
|
||||
| 运营变现合规-013 | **题材黑名单（棋牌、捕鱼）即便纯 IAA 也需律所季度更新合规报告，列入生成侧题材审查（生成前拦截）** —— 在游戏生成之前就拦掉黑名单题材 | 渠道发行 §3.3；可行性方案16周 §风险旗 | 不确定 | 现行《渠道发行》§3.3 有这条——**已沉淀**。标不确定是因为它是一条**生成前置闸门**（生成侧题材审查），跨了运营与生成两个域；现行渠道档讲了"要拦"，但"棋牌/捕鱼要季度更新的律所合规报告"这个持续性的合规运营负担，没有作为一项周期性运营任务被登记 | |
|
||||
| 运营变现合规-014 | **未成年人识别后的处置=禁止广告展示 + 禁止付费 + 限制时长 + 最小化数据采集，实名认证后触发** —— 防沉迷不只是"限时长/宵禁"，识别出未成年后是一组联动处置 | 技术决策版 :760 | 遗落 | 现行《合规闸门》§3.1 把"防沉迷时长/宵禁、未成年充值限制、青少年模式"列为三项法定要求，**但"识别未成年后要联动地禁广告 + 禁付费 + 限时长 + 最小采集"这个具体处置组合没沉淀**。其中"禁止给未成年展示广告"这条对一个 IAA 平台尤其要命——它直接砍掉未成年用户的广告收入，且与代码里已有的 `blockMinor` 合规位是对应的。值得作为防沉迷的执行细节落档 | |
|
||||
| 运营变现合规-015 | **SDK 数据采集的法律基础=《个保法》第 13 条第（二）款"为订立、履行合同所必需"** —— 用户接受平台服务即构成合同关系，SDK 采集的生命周期/互动/错误/性能数据是提供推荐、质量保障、变现服务的必要数据 | 技术决策版 :726 | 遗落 | 三向审计修过"GDPR 应为个保法"这个口径错，但**"我们采集玩家行为数据的合法性依据具体是个保法第 13 条哪一款"这个论证没沉淀进现行档**。算法备案、隐私协议定稿、数据合规自评估都会要这个法律依据；它想清楚过（合同必需条款），丢了等于到时候要重新论证一遍数据采集的正当性 | |
|
||||
| 运营变现合规-016 | **大模型登记/算法备案的材料可由 AI 代拟，但提交动作只有创始人能做；对外（奇绩）已承诺"8 月中旬材料就绪"** —— 这两项办理周期都以"数月"计、是全部闸门里最长的，材料准备必须尽早启动 | 合规闸门 §3.2；A1 看板 #9/#10 | 不确定 | 现行《合规闸门》§3.2 讲了这两项"数月、不能拖"——**已沉淀**。标不确定是因为"对外已承诺 8 月中旬材料就绪"这个**带日期的外部承诺**散在 A1 看板里，没进《合规闸门》正文；它是材料准备启动时点的硬锚，丢了就失去了倒排期的依据 | |
|
||||
|
||||
---
|
||||
|
||||
## 四、审核台运营机制（现行档几乎空白——这是最该补的一块）
|
||||
|
||||
现行《合规闸门》把"法定上线闸门"讲透了，但**平台自己每天怎么审内容、怎么处置违规、审核台后端怎么运转**这套运营机制，在运营域现行档里几乎是空白。这套机制在 Wave3 review、技术决策版、护城河复盘里设计得相当完整，是真正的遗落重灾区。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运营变现合规-017 | **内容审核双层架构：机审（safe-content-ai 自部署快检 + 阿里云内容安全兜底，文/图/音）+ 人审队列（BPM 审核状态机）** —— 自部署做首道快检（免费/低延迟），高风险样本二次送阿里云确认；人工层是审核队列 + Flowable/BPM 审核状态机 | 技术护城河复盘 §一；技术决策版 :1117/:1143；Wave3 review §2.2 | 遗落 | 现行《合规闸门》一个字没提平台**自己怎么审内容**。这套"自部署快检 + 阿里云兜底 + 人审队列 + BPM 状态机"是平台日常内容安全运营的骨架，且阿里云内容安全是要花钱的（三向审计点名"成本表漏审核 API"）。一个 UGC + AIGC 平台，内容审核机制是合规与运营的核心，现行运营档却完全没有这一章 | |
|
||||
| 运营变现合规-018 | **锁风门（风格一致性 Gate）有三档强度：标准 / 严格 / 人工复核** —— 聚合生成端风格指纹 + IP 库比对 → pass/review/block 三态，外加三档强度（P-LIC-05）；本质=嵌入相似度 + 阈值门 + 人审队列 | 技术护城河复盘 §一；Wave3 review §2.2 | 遗落 | 现行运营域完全没有"锁风门"这个概念。它是 IP 保真这件事在审核台上的落地机制（向 IP 方承诺人设不崩 → 签得到/签得便宜），是 demo 里"一句话生成→锁风保真→上架"演示链路的关键一环。三档强度（标准/严格/人工）是个具体的运营旋钮——不同 IP、不同风险级别用不同强度。这套机制只活在历史 review 里，现行运营档丢了 | |
|
||||
| 运营变现合规-019 | **违规处置机制：封禁 + 举报降权（产降权信号给 feed）+ 分级标签判定** —— compliance 模块产出降权信号喂给 feed 排序、对违规账号封禁、对内容做分级标签 | Wave3 review §2.2；技术架构与模块 T-CMP-11/13/18 | 遗落 | 现行运营档没有"内容/账号违规了怎么处置"这一块。封禁、举报降权（把违规内容在 feed 里压下去）、分级标签是平台日常运营的处置手段。审核台 UI 走查（链路②）历史上已经 e2e 闭环过，底层机制是有的，但现行运营档没把这套处置机制讲出来 | |
|
||||
| 运营变现合规-020 | **审核状态机的归属切分：compliance 拥有审核状态机/人工队列/锁风裁决，project 只持有游戏状态 + 接收审核结果回写，避免双写审核态** —— 这是一条防"两个模块都在写审核状态"的架构红线 | Wave3 review §四/§六-决策3 | 不确定 | 这条归属切分在 Wave3 review 里是明确拍过的设计决策，**现行运营档没记**。标不确定是因为它偏架构归属、可能该进架构域而非运营域；但它直接关系审核台运营的数据一致性（审核状态单一权威），运营这边至少该知道"审核状态以 compliance 为准、project 只读回写"这个事实 | |
|
||||
| 运营变现合规-021 | **审核 SOP + 隐式水印 + 舆情 2 小时下架** —— 阶段二要建审核 SOP、隐式水印（内容溯源用，新工程件）、舆情 2 小时内下架的能力 | 可行性方案16周 §阶段二；§新增工程件登记 | 遗落 | **隐式水印**（implicit watermark，给生成内容嵌入不可见溯源标记）是个全新工程件，可行性方案明确登记为"随 W-CH/G3 排期"，**现行任何运营档都没提**。它对内容溯源、版权追责、AIGC 标识合规都有用。"舆情 2 小时下架"是一条内容运营 SLA（出了舆情多快能下架），也没沉淀。这两条都是平台内容安全运营的实操能力，丢了可惜 | |
|
||||
| 运营变现合规-022 | **安全硬化整组（OWASP/SSRF/CORS/Secrets/加密/漏扫，T-CMP-20~38）在 MVP 被有意延后、复用 huijing** —— 38 个 T-CMP 里 MVP 只做锁风门链 + 审核状态机 6-7 项，安全硬化是"运维/安全专项"不是 MVP 业务 P0 | Wave3 review §2.2/§六-决策1 | 过期/弃用 | 这是一条**有意的延后决策**（安全硬化复用 huijing 框架自带 + 上线前再硬化），现行运营档没记。列出来是让创始人记得：OWASP 那套安全硬化不是没想到，是有意排到了 MVP 之后、靠框架兜底。上线前（尤其开公网/创作者账户前）这是必须回头补的一组，与下面的 WAF（运营变现合规-024）连体 | |
|
||||
|
||||
---
|
||||
|
||||
## 五、成本测算与单位经济（已有两套模型，留几条成本缺口与口径冲突）
|
||||
|
||||
现行《变现与单位经济》引用了两套经济模型（单位经济敏感性模型 + 全成本收益测算 v2）。模型本身在 mvp 目录里很完整，但有几条成本缺口和口径冲突值得在运营档层面被看见。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运营变现合规-023 | **存在两套不同口径的经济模型，回本结论差一个数量级，跨页引用前必须先对齐口径** —— 单位经济敏感性模型用"激励 eCPM 15/30/60 元/千次（每次曝光口径）"，全成本测算 v2 用"完整观看单价 ¥0.4/0.75/1.2（折算激励位 eCPM=200/562.5/1080）"，两者不是同一口径、高约一个数量级 | 全成本收益测算 v2 §0-5/§3.2；单位经济敏感性模型 §1 | 遗落 | 现行《变现与单位经济》§4 只引用了"激励 eCPM 15/30/60"这一套，**完全没提还有另一套口径、且两套差一个数量级**。这是个真实的口径地雷：任何人拿全成本 v2 的"15 个月回本"去和单位经济页的"1.33 万 DAU"对照，会得出矛盾结论而不自知。现行档该显著标注"两套口径并存、对照前先对齐"，否则对外引用极易出错 | |
|
||||
| 运营变现合规-024 | **¥4,300/月成本表漏算 GPU / 审核 API / WAF 高防 / 短信 / 通道费** —— 投资人版那张成本表只算了"跑 demo 的账"，真实经营要补这五项 | 三向审计 R3；技术决策版 :1236（WAF 阿里云/Cloudflare + DDoS 高防，上线前） | 遗落 | 现行《变现与单位经济》§7.2 仍在用那张 ¥4,300/月 的成本表，**没有标注它漏了 GPU/审核 API/WAF 高防/短信/通道费**。其中 WAF + DDoS 高防是技术决策版明确写了"上线前"要接的安全防护成本。三向审计早就点名这张表"只算了跑 demo 的账"，但现行档照搬了它、没带这个警示。真实上线成本被系统性低估，融资/单位经济测算会偏 | |
|
||||
| 运营变现合规-025 | **全成本测算 v2 明确未计入：税费、渠道 T+N 结算账期的资金占用成本、对账差与坏账** —— 这三项都是真实经营成本，规模化与融资测算时须单列补回 | 全成本收益测算 v2 §2.3/§7.2 | 遗落 | 现行《变现与单位经济》没提这三项被刻意排除。**渠道结算有 T+N 账期（占用现金流）、广告分成有对账差和坏账风险**——这些在真实运营里都会咬人。模型保守起见没纳入是对的，但"它们被有意排除、规模化时要补回"这个边界声明丢了，等于让人误以为成本已经算全了 | |
|
||||
| 运营变现合规-026 | **人审兜底人力是真正会随量咬人的成本：月新增 ≤2000 款内 3 人可吸收，超出 +1 审核人力（约 +6000 元/月台阶）** —— 生成算力成本可忽略，真正的随量成本是人审（台阶函数）和带宽 | 全成本收益测算 v2 §2.4 驱动 C；单位经济敏感性模型 §5 | 不确定 | 现行《变现与单位经济》§3 提了"人工审核兜底列为后续埋点项"——**部分沉淀**。但"人审是台阶函数、月新增超 2000 款就要 +6000 元/月、它才是真正会咬人的随量成本"这个具体量化结论没沉淀。它对"产能放大时成本怎么涨"的判断很关键，且和审核台运营（第四节）直接相关——产能越大，人审压力越大 | |
|
||||
| 运营变现合规-027 | **王蓝莓窄域口径 ≥90%（1 IP × 2 玩法）vs 工厂宽域门 ≥80%，对外口径统一前要双指标声明** —— 王蓝莓单点验证的成功率门是 ≥90%（窄域），而生成工厂的宽域门是 ≥80%，两个指标不能混为一谈 | 可行性方案16周 §阶段一 | 遗落 | 现行档只讲了"生成成功率 ≥80%"一个口径。**"王蓝莓窄域 ≥90% / 工厂宽域 ≥80%"这个双指标区分没沉淀**——它对应可行性验证（单 IP 单点打透）和平台能力（海量 UGC）两件不同的事。对外讲成功率时若不区分，要么虚高要么自相矛盾。是个该明确的口径约束 | |
|
||||
| 运营变现合规-028 | **三个成本假设值（每百万 token 单价 2.0 / new-api 额度换算 500000 / 汇率 7.2）在拿到真实账单前一律标【假设·待测】，不作预测口径、不对外锁价** —— 创始人 2026-06-11 采纳的红线 | 变现与单位经济 §4.3；单位经济敏感性模型 §1 | 不确定 | 现行《变现与单位经济》§4.3 有这张假设值表 + 红线——**已沉淀**。标不确定是因为这三个值的真实化依赖"创始人提供 new-api 网关账单口径"（关联 A1 的 LLM 实名充值闸门），现行档把它当成本侧待办，但"在拿到真实账单前不对外锁价"这条**对外承诺纪律**没有和对外材料（护城河话术/对外收益叙事）那边的口径红线挂钩 | |
|
||||
|
||||
---
|
||||
|
||||
## 六、渠道发行的执行细节（现行档很完整，仅留两条容易被忽略的约束）
|
||||
|
||||
现行《渠道发行》对一壳多游、备案锁、GameConfig 红线、引擎竞标写得非常详尽，归档 canonical 也已折叠进去。只剩两条容易被埋没的执行约束。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运营变现合规-029 | **C2 拍板：一壳多游以渠道合规为准绳，若律所判定必须每游独立备案则照办——合规优先于经济性** —— 备案锁有三条出路（每游独立备案/壳内游戏集稳定化月级提审/并入律所议题），最终以合规为先，哪怕成本更高 | 渠道发行 §8.1-C2 / 归档 canonical §6 | 不确定 | 现行《渠道发行》§8.1 写了 C2——**已沉淀**。标不确定是因为"合规优先于经济性"这个**取舍原则**很容易在成本压力下被悄悄翻转（比如为省备案费而选了风险更高的方案）。它是一条创始人级的取舍裁定，值得在运营决策层面被显著记住，而不只是埋在渠道档的"已完成"清单里 | |
|
||||
| 运营变现合规-030 | **L2 改码产物不能动态下发进小游戏渠道（微信明文禁动态代码 + 远程包剥离代码），L2 默认走自研流** —— 抖音"一软著一游戏"也使海量 UGC 各自上渠道不可行，渠道只能走一壳多游 | 可行性方案16周 §风险旗-A包定论；渠道发行 §1 | 不确定 | 现行《渠道发行》§1 讲了 L1/L2 分工、渠道禁动态代码——**已沉淀**。标不确定是想确认这条"L2 改码后的游戏在渠道侧是死路、只能留自研流"的硬边界，在产品/运营对"什么游戏能上哪个渠道"做承诺时，有没有被当成不可逾越的约束。它决定了渠道线永远只能是"精选 L1 整包"，不可能变成"UGC 都能上渠道" | |
|
||||
|
||||
---
|
||||
|
||||
## 七、与产品战略清单交接的几条（此处只登记指向，不重复展开）
|
||||
|
||||
下面这些设计点在运营/变现/合规的语境里也被讨论过，但它们的"家"在同目录的 `产品战略-历史设计点.md`，那边已展开。此处只登记一句，避免两份清单各列一遍造成重复债。
|
||||
|
||||
| ID | 设计点（一句话） | 它的家 | 说明 |
|
||||
|---|---|---|---|
|
||||
| 运营变现合规-031 | **"满 5 元提现/能赚钱"对用户是下一笔潜在诚信债**（种子期长尾款不可达） | 产品战略-011 | 现行《变现与单位经济》§4.2 已有"对创作者必须用头部款口径"的诚信红线；产品战略清单从用户预期管理角度补了它。运营这边知会即可，不重复列 |
|
||||
| 运营变现合规-032 | **每游戏粒度单位经济测量计划（LLM 成本/审核成本/广告产值真实埋点）** | 产品战略-012 | 现行《变现与单位经济》§6 已登记为 W4 ③④待办；产品战略清单议的是"要不要抬到战略优先级"。工程待办口径已在运营档，不重复列 |
|
||||
| 运营变现合规-033 | **法定 8 项产品功能须按三线排序分批进 P0（不是一次性全塞）** | 产品战略-017 | 现行《合规闸门》已把 8 项作为整组讲清；分批节奏的争议（渠道线起步即需/自有端公开前/真钱开闸前）在产品战略清单。合规执行逻辑已在运营档，不重复列 |
|
||||
| 运营变现合规-034 | **创作者梯度即订阅转化漏斗（免费 L1 → 订阅解锁 L2/L3），用生成级别做付费墙** | 产品战略-027 | 这是订阅收入线的核心产品机制；它的商业设计归产品战略清单。运营这边只需知道"订阅收入的产品逻辑是用生成分级做付费墙"，明细不重复列 |
|
||||
@ -1,55 +0,0 @@
|
||||
# 运营变现合规 · 第二轮(复核 + 查漏)
|
||||
|
||||
这一轮做的是给第一轮的回收清单做体检:抽验它的出处真不真、分类判得准不准,再看第一轮之后新落地的一批设计稿把哪些"遗落/不确定"接住了,最后顺着第一轮没扫到的角落补几条。不重抄第一轮已经对的条目,只产出三类——改判的、被新档覆盖的、新挖的。
|
||||
|
||||
> **第一轮之后新落地、这一轮拿来比对的新档**:运营域的《审核台运营》(双层审核判定流 + 锁风三档 + 违规处置联动 feed 与创作者信用 + admin 审核台),架构域生成引擎子树的《数据飞轮》(溯源链 + 同款创作 + 资产市场 + 收益回流),运维域的《观测体系》《k8s 迁移》,以及《合规闸门》§9 回填的审核台立位。更早的五份 P0(鉴权与权限、产物执行沙箱、契约总览、数据模型、变现端到端)也一并比对。
|
||||
|
||||
> **结论先说**:第一轮整体扎实。出处抽验了八条关键的(003/004/014/015/017–022/023/026),逐条 git grep 回源,**全部对得上,没有编造,没有张冠李戴**。需要改判的只有 2 条,都是分类口径上的微调,不是硬错。真正的大事是——第一轮第四节"审核台运营"那块自己判为"最该补的重灾区",现在被一份《审核台运营》正式稿几乎整章接住了:第四节六条里有五条(017/018/019/020/021)被全覆盖,加上第三节的 013/014、第五节的 026 和 024 的审核 API 那半,**合计 9 条第一轮的"遗落/不确定"被新档还上了账**。查漏补出 4 条新的,最值得看的是**广告加载失败必须跳过广告让游戏继续**这条运行时红线——第一轮在变现侧把"广告计费的降级口径"挖得很细,却漏了"广告在玩家端挂了不能卡住游戏"这条体验红线,两份变现档都没有。
|
||||
|
||||
---
|
||||
|
||||
## 一、复核勘误表(改判的条目)
|
||||
|
||||
第一轮逐条核过,出处全部属实,分类绝大多数判得准。只有下面 2 条的判定口径值得微调,都不是"判错了",而是"可以更准"。
|
||||
|
||||
| ID | 原判 | 新判 | 为什么 |
|
||||
|---|---|---|---|
|
||||
| 运营变现合规-008 广告位 AI 优化 / eCPM 优化 | 过期/弃用 | **过期/弃用(措辞宜改"有意降级·未弃")** | 出处属实——Doc A 现行确实把 P-ADV-08 标 P2 · v2.0(`需求清单.md:184`),RTM 也只挂了 T-AD-09/07 映射没标 P0(`需求模块映射.md:174`)。但"过期/弃用"这个标签在本清单的口径里专指"已被取代或决定不做",而 P-ADV-08 是**有意排到 v2.0、留着将来抬 IAA 收入时第一个捡回**(第一轮自己的"为什么"列写得很清楚)。所以条目实质没错,只是判定列的标签略重了——它不是"弃",是"押后"。建议读的人按"有意降级到 MVP 之外、未来要捡回"理解,别误当成砍掉的能力。 |
|
||||
| 运营变现合规-001 mock 不变式 G/N | 不确定 | **已沉淀(可摘掉不确定)** | 第一轮标不确定的理由是"它埋在资金红线列表里,没被显著标成接真联盟第一件要先拍的事"。但回源核《变现与单位经济》§5-4(`:151`),那条 mock 不变式不仅写了,末尾还**明确缀了一句"这是支付真实化的阻塞前置项"**——已经是被显著标注的阻塞前置,不是埋着的普通红线。所以第一轮担心的"没被显著标出"其实现行档已经做到了,这条可以从"不确定"收敛为"已沉淀、无需再补"。 |
|
||||
|
||||
> 其余条目(002/007/009/010/011/012/015/016/023/024/025/027/028/029/030)的出处与分类经抽验与交叉核对均成立,不改判,不在此重列。
|
||||
|
||||
---
|
||||
|
||||
## 二、已被新档覆盖的第一轮条目
|
||||
|
||||
这是本轮最重的一块。第一轮把第四节"审核台运营"整章判为"现行档几乎空白、最该补的重灾区",并在第三、五两节也挂了若干跨域执行件。第一轮交付之后,《审核台运营》正式稿落地,把这些账大面积还上了——而且这份新档**直接按第一轮的回收编号点名引用**(它在正文里写了"对应历史回收 014/020/021/026"),等于自带了一份覆盖对照。下表逐条登记。
|
||||
|
||||
| ID | 第一轮原判 | 被哪份新档覆盖 | 覆盖到什么程度 |
|
||||
|---|---|---|---|
|
||||
| 运营变现合规-017 内容审核双层架构(机审+人审队列+BPM) | 遗落 | 《审核台运营》§3.2 双层判定流 + §3.4 人审走 BPM | **全覆盖**。自部署快检挡大面、阿里云兜底、灰带转人审三段瀑布,人审工单状态机(认领/升级/超时 SLA)、轻量状态机起步 Flowable 留远期,都设计到位,且把阿里云接入时点定在"接真实公开流量前"。 |
|
||||
| 运营变现合规-018 锁风门三档(标准/严格/人工复核) | 遗落 | 《审核台运营》§3.3 锁风三档与 IP 库怎么绑 | **全覆盖**。三档语义、按 IP 敏感度自动选档、IP 库未建期间用过渡表 `lock_strength_policy`、题材黑名单兜底拉档,全讲清,并定了"随素材/IP 授权模型一起做"的范围依赖。 |
|
||||
| 运营变现合规-019 违规处置(封禁+举报降权+分级标签) | 遗落 | 《审核台运营》§3.5 违规处置怎么联动 feed 与信用 | **全覆盖**。三类处置逐一落到下游真字段:封禁补两条断链(置 `game_player.status=DISABLE` 拦创作 + 按 creatorId 批量下架)、降权走 feed `exposureLimit`(降权 `-api` 要不要单建挂了开放问题)、分级标签喂青少年模式过滤。比第一轮挖得还细。 |
|
||||
| 运营变现合规-020 审核状态机归属切分(compliance 拥有/project 只读回写) | 不确定 | 《审核台运营》§1 + §3.1 目标(明示"历史上 Wave3 评审就拍过这个归属切分,这里继承") | **全覆盖**。审核状态唯一权威在 compliance、project 只接收回写不双写,作为贯穿全页的纪律被钉死,第一轮担心的"运营这边该知道这个事实"已落进运营域档。 |
|
||||
| 运营变现合规-021 审核 SOP + 隐式水印 + 舆情 2 小时下架 | 遗落 | 《审核台运营》§3.4(SOP=BPM 工作流)+ §3.6 内容溯源(隐式水印,显式引用"历史回收 021")+ §5.2 风险(舆情 2h SLA) | **全覆盖**。隐式水印作为全新工程件登记进内容溯源(与 AIGC 显式标识互补、MVP 可后置随渠道线排),舆情 2 小时下架作为人审 SLA 写进风险与超时告警机制。 |
|
||||
| 运营变现合规-013 题材黑名单(棋牌/捕鱼)生成侧题材审查 | 不确定 | 《审核台运营》§3.3(题材黑名单作为兜底拉档规则,强制拉到人工复核档;新档此处误标为"回收020",实指本条) | **全覆盖**。棋牌/捕鱼即便纯 UGC 也强制人工复核档,落进锁风三档的选档兜底层,第一轮担心的"生成前置题材闸门没登记"已被接住。(注:新档引用编号有个 off-by-one,把本条写成了 020,实际对应的是 013。) |
|
||||
| 运营变现合规-014 未成年识别后联动处置(禁广告+禁付费+限时长+最小采集) | 遗落 | 《审核台运营》§3.5 分级标签(显式引用"历史回收 014") | **全覆盖**。识别未成年后按分级过滤 feed 候选集、禁广告禁付费限时长最小采集,作为分级标签的下游联动写明,且点出"禁给未成年展示广告对 IAA 平台尤其要命"这层第一轮强调的要害。 |
|
||||
| 运营变现合规-026 人审台阶函数(月新增超 2000 款 +6000 元/月) | 不确定 | 《审核台运营》§5.2 风险(显式引用"历史回收 026") | **全覆盖**。人审是台阶函数、超 2000 款 +6000 元/月、是真正随产能咬人的成本,作为风险写进审核台,且和快检阈值松紧的成本权衡绑在一起讲。 |
|
||||
| 运营变现合规-024 ¥4,300/月成本表漏算项(GPU/审核 API/WAF/短信/通道费) | 遗落 | 《审核台运营》§5.2 风险(仅"审核 API"这一项) | **部分覆盖**。审核台明确点了"¥4,300 那张表压根没算阿里云内容安全、放量前要把审核 API 成本单列进成本台账",把第一轮 024 的**审核 API 那一项**还上了;但 GPU/WAF 高防/短信/通道费另外四项仍只躺在《变现与单位经济》§7.2 的原表里没带警示,**024 整体仍未闭合**,留着。 |
|
||||
|
||||
> 一句话:**第一轮判为"重灾区"的审核台运营,被一份《审核台运营》正式稿基本补齐了**——第四节六条遗落/不确定里五条全覆盖(余下 022 安全硬化是 OWASP/WAF 那套、属运维安全专项,审核台不碰,仍留),连带把第三节的题材审查/未成年处置、第五节的人审台阶/审核 API 成本一并接住。这是第一轮运营域最大的一笔欠账被还上。剩下没还的主要是变现侧的口径地雷(023 两套 eCPM、024 剩四项成本、025 被排除成本、027 双成功率口径、028 对外锁价纪律)——这些都是《变现与单位经济》该补的,新落地的几份稿不碰变现口径,所以原样留着。
|
||||
|
||||
---
|
||||
|
||||
## 三、查漏补充清单(新挖的)
|
||||
|
||||
第一轮的扫法偏"审计开出的口径调整 + 可行性方案里登记的工程件",挖得很全。这一轮我顺着三条第一轮带过的线补:① M4 变现真实化 review 里偏"资金切换风控"的细节;② 全成本测算 v2 里偏"回本驱动变量"的结论;③ 旧技术决策版里偏"运行时与运营信号"的红线——尤其那些卡在运营与前端/运维交界、两边都以为对方会挖的跨域地带。判据同第一轮:遗落=历史认真讨论过、有价值、现行没沉淀也没明确弃;不确定=拿不准现行覆盖没。现行已覆盖的(如打赏/reward 现金发放——已在 M4 落地且《变现端到端》§2.5 沉淀;广告联盟 SPI 切换骨架——已在变现端到端沉淀)一律不补。
|
||||
|
||||
| ID | 设计点 | 出处 | 状态 | 为什么 | 判定 |
|
||||
|---|---|---|---|---|---|
|
||||
| 运营变现合规-035 | **广告在玩家端加载失败必须跳过广告、让游戏继续,绝不因广告问题阻断游戏体验** —— 这是一条运行时体验红线,和"广告计费的降级口径"是两码事:008/010 讲的是后端计费侧降级(少算收入可接受),这条讲的是玩家正在玩游戏时广告 SDK 拉不出来,不能把游戏卡死 | 技术决策版 :625 | 遗落 | 第一轮在变现侧把"广告计费降级口径"(010:广告侧降级 mock 可接受、打款侧必须 fail-fast)挖得很细,**但漏了运行时这一侧**。核《渠道发行》《变现端到端》两份现行档,都没有"广告加载失败→跳过→游戏继续"这条。它跨在运营变现与前端运行时的交界,正是两边各以为对方会挖而都漏的地带。对一个 IAA 平台,广告体验直接影响留存——广告偶发失败把游戏卡死,比少算一笔收入严重得多。值得作为广告变现的运行时红线落档(家可能在渠道发行或前端运行时档)。 | |
|
||||
| 运营变现合规-036 | **举报率(report_rate=举报数/曝光)是一个负向质量信号,超阈值自动触发人工审核** —— 这是一条"线上反向触发复审"的运营机制:不是用户主动提交内容送审,而是内容已经在线上跑、举报率冲高后被系统自动拎回人审 | 技术决策版 :902(report_rate 负向 · 阈值触发人工审核) | 遗落 | 《审核台运营》§3.2 的审核入口是"发布的游戏/上传的素材"主动送审这条正路,§3.5 把"举报降权"作为一个**处置动作**讲了,**但没有覆盖"举报率作为负向信号自动把已上线内容反向拎回人审"这条触发路径**。两者方向相反:一个是上架前拦,一个是上架后由舆情/举报反向召回。这条是内容安全运营的闭环里"线上发现"那一环,审核台只画了"事前审"和"事后处置",漏了中间"事中由信号触发"。它和审核台的人审队列、和 feed 的举报埋点都能接上,丢了等于审核台只防得住新内容、防不住"上线后才变坏/才被举报"的内容。 | |
|
||||
| 运营变现合规-037 | **资金渠道切换(provider / payout-channel)必须双人复核 + 配置审计,不允许单人改配置就切真** —— 广告 provider 从 mock 切真联盟、打款 channel 从 mock 切真微信/支付宝,是真钱开关,配置错配会致 mock 发真钱或真扣假到账 | M4 变现真实化 review §风险3缓解(切换需双人/配置审计)+ §2.3 | 遗落 | 第一轮把 M4 的资金一致性红线挖得很全(001/002/007/009/010 覆盖了 G/N 口径、对账补偿、三方对账、降级 fail-fast),**但漏了"切换动作本身的操作风控"这一条**。核《变现端到端》,有 provider/payout-channel 单一开关的设计,但没有"切换需双人复核 + 配置审计"这条操作约束。它和 028"拿到真实账单前不对外锁价"是一类纪律——属于真钱面前的操作护栏,不是代码逻辑而是流程规矩。资金渠道是整个变现链风险最高的开关,一个人手滑改错配置就可能酿成资损,这条值得作为变现的操作红线钉死。 | |
|
||||
| 运营变现合规-038 | **回本的头号杠杆是月增速(零投流下 15/25/35% 三档),比 eCPM 更主导回本月份;"零付费投流能否撑住高月增"是头号未验变量** —— 全成本 v2 的 9 宫格敏感性显示:同一 eCPM 档,月增速从 15% 升到 35%,回本月份近乎减半(基准列 24→12),而月增速这个变量当前完全未验证 | 全成本收益测算 v2 §5/§0 结论②/§7.2 风险1 | 遗落 | 第一轮在变现侧挖了 023(两套 eCPM 口径)、025(被排除成本)、027(双成功率口径)、028(成本假设值待测),**但这些都是"成本与口径"侧,漏了"收入侧最敏感的那个变量是什么"这条结论**。《变现与单位经济》§4 引了 eCPM 三档敏感性,却没引"月增速才是回本头号杠杆、且零投流能不能撑住高月增完全没验过"这条更要命的判断。这关系到对外讲回本周期时的诚实度:拿乐观月增算出来的"一年回本"和拿悲观月增算出来的"近三年回本"差着一个融资窗口,而决定走哪条的恰恰是这个最没把握的变量。它和 027/028 是一组对外口径纪律——讲回本必须连带声明"头号假设是零投流月增、低置信、待 W4 拉新埋点实测",否则极易给出过于乐观的预期。 | |
|
||||
|
||||
> **给创始人的一句话**:这一轮最该看的是 **035——广告加载失败让游戏继续那条运行时红线**。第一轮和现行档把广告的"钱怎么算、降级怎么守"挖得很细,却都漏了"广告在玩家手里挂了别卡死游戏"这条最朴素的体验底线,而它对一个靠广告吃饭的平台恰恰是留存生命线。其次是 037(资金切换双人审计)和 038(月增速是回本头号变量、零投流强假设待验)——前者补上变现链最高危开关的操作护栏,后者补上对外讲回本时最该声明的那个不确定性,两条都是"真钱/对外口径"上的诚实纪律,和第一轮已挖的 028 是一脉。036(举报率反向触发人审)是审核台闭环里"事中召回"那一环的缺口,补上审核台就从"只防新内容"变成"也防上线后变坏的内容"。
|
||||
@ -192,7 +192,7 @@ token 还承担一个长期使命:**做跨端的单一事实源**(single source
|
||||
|
||||
要把上一条和"对话式创作"分清,否则容易把产品形态错当成被砍掉的范围。绘境的**完整产品形态是对话式创作闭环**:多轮对话把游戏生成出来、对已经生成的游戏做差量修改(换美术、改第 2 关,只动一处、不毁全局)、以及修改游戏里用到的素材。"一句话 + 选玩法模板 → 整包生成"不是终点,而是**发起一次生成的启动点位之一**。
|
||||
|
||||
这套能力的后端已经是现行真相——`/studio/modify`、`/studio/extend` 端点和 SAA 的 modify 节点都建好了,studio 三路由 `/studio/{create,modify,extend}` 也在。当前缺的是前端承载:对话框、把六类素材传进去当生成上下文、系统解析意图后的目标确认卡、以及差量修改的入口和"改了哪、其余没动"的差异展示(对应[历史回收清单](../_recall/前端-历史设计点.md)的前端 C01–C04)。所以这块不是"descope 勿返工",而是**产品形态已经定调、前端 UI 待补设计**。
|
||||
这套能力的后端已经是现行真相——`/studio/modify`、`/studio/extend` 端点和 SAA 的 modify 节点都建好了,studio 三路由 `/studio/{create,modify,extend}` 也在。当前缺的是前端承载:对话框、把六类素材传进去当生成上下文、系统解析意图后的目标确认卡、以及差量修改的入口和"改了哪、其余没动"的差异展示(对应历史回收判定的前端 C01–C04)。所以这块不是"descope 勿返工",而是**产品形态已经定调、前端 UI 待补设计**。
|
||||
|
||||
> 一处口径校准:产品域需求清单里"智能体对话式创作"(P-CRT-05)、素材中心(P-MAT 整组)仍标 P1;同款创作(P-FED-12)已由创始人 2026-06-22 拍板升 P0(数据飞轮网络效应核心杠杆,Doc A 已改)。把 P-CRT-05 / P-MAT 定调为产品形态讲的是**方向**,不等于把它们的验收优先级一次性提到 P0——这两项的调整仍另走评审,别擅自改动验收契约。
|
||||
|
||||
@ -220,7 +220,7 @@ token 还承担一个长期使命:**做跨端的单一事实源**(single source
|
||||
|
||||
## 9. 前端域承载范围:近期待补的前端落点
|
||||
|
||||
前面几节讲的是设计体系本身、以及 studio 相对 demo 的能力盘点。但前端域要承载的不止设计体系——有一批能力,后端、契约、运维、架构域都已经把"里子"做出来或定下来了,缺的只是前端这层"面子":页面、入口、按钮、展示。这一节把这些**归属在前端域、近期要补的落点**钉清楚,按时间窗分组。它只立"该谁承载、什么时候补"这件事,不在这里写逐页 UI 的详细设计——具体到组件与交互的 file 级设计,留给实现时在活代码里落。这一整节都来自创始人 2026-06-22 历史回收判定的捡回,逐条对应[历史回收清单](../_recall/前端-历史设计点.md)里同名的设计点。
|
||||
前面几节讲的是设计体系本身、以及 studio 相对 demo 的能力盘点。但前端域要承载的不止设计体系——有一批能力,后端、契约、运维、架构域都已经把"里子"做出来或定下来了,缺的只是前端这层"面子":页面、入口、按钮、展示。这一节把这些**归属在前端域、近期要补的落点**钉清楚,按时间窗分组。它只立"该谁承载、什么时候补"这件事,不在这里写逐页 UI 的详细设计——具体到组件与交互的 file 级设计,留给实现时在活代码里落。这一整节都来自创始人 2026-06-22 历史回收判定的捡回,逐条对应历史回收判定([创始人判定](../_recall/创始人判定.md))里同名的设计点。
|
||||
|
||||
### 9.1 前端域引用承载:把活在别域的前端约束引一份过来
|
||||
|
||||
|
||||
@ -25,9 +25,9 @@ yudao 框架层有一个 `huijing-spring-boot-starter-monitor` starter,它里面
|
||||
|
||||
缺口归纳成三条:
|
||||
|
||||
1. **没有任何遥测后端在收数据**。Micrometer 指标没人 scrape,trace 没地方落,日志还是各进程自己的文件。蓝图里画过的 Prometheus / Grafana / Jaeger 三个容器,MVP 现实从未起过(历史回收清单 [运维基建-001](../_recall/运维基建-历史设计点.md))。
|
||||
1. **没有任何遥测后端在收数据**。Micrometer 指标没人 scrape,trace 没地方落,日志还是各进程自己的文件。蓝图里画过的 Prometheus / Grafana / Jaeger 三个容器,MVP 现实从未起过(历史回收判定 运维基建-001)。
|
||||
2. **采集标准不统一,且和创始人选定的不一致**。现状脚手架是 SkyWalking + Micrometer 两套各走各的;创始人 2026-06-21 定的是 **OpenTelemetry(OTel)一套统一 trace / metrics / log**。这不是补一个后端就完,而是要把采集标准收敛到 OTel。
|
||||
3. **告警是一张纯文档表,没有一根通道真接上**。`security-and-reliability.md` §6 把 P0–P3 升级链和触发条件写全了(P1=5xx>2% 或生成成功率<70%),但飞书/钉钉 webhook 谁配、P0 电话怎么打,全是空头承诺(历史回收清单 [运维基建-004](../_recall/运维基建-历史设计点.md))。预算里留了 ¥500/月给监控/备份,但这笔钱对应的能力一直是空的(运维基建-027)。
|
||||
3. **告警是一张纯文档表,没有一根通道真接上**。`security-and-reliability.md` §6 把 P0–P3 升级链和触发条件写全了(P1=5xx>2% 或生成成功率<70%),但飞书/钉钉 webhook 谁配、P0 电话怎么打,全是空头承诺(历史回收判定 运维基建-004)。预算里留了 ¥500/月给监控/备份,但这笔钱对应的能力一直是空的(运维基建-027)。
|
||||
|
||||
这份设计要做的,就是把这三条补成真东西:引入 OTel 统一采集、把已有的 SAA 图节点 observation 和后续新埋的指标接进去、给 Grafana + 夜莺喂上数据、把告警通道接通、并在 admin 开一个进大盘的入口。下面 §3 凡涉及新建的契约面(后端 pom 依赖、新增指标埋点、admin 路由与查询接口),会单列 contract-first 清单,讲清"现在没有、要新建什么"。
|
||||
|
||||
@ -120,7 +120,7 @@ flowchart TB
|
||||
- `gen_duration_seconds` —— 生成耗时分布(histogram),出 P50/P95,对齐"P50<60s、P95<180s"的硬指标。埋点位:Worker 一局生成的起止。
|
||||
- `gen_queue_depth` —— 队列积压(全局在飞 = queued+running)。**取数口径要对齐控制平面的真实实现**:背压阈值是 `AigcControlPlaneProperties.queueDepthLimit`,代码里当前是占位值 **50**(注释明确"占位值,需确认",不是蓝图里画过的 500);超阈值时走业务码 `AIGC_BACKPRESSURE_REJECTED`(`1_101_001_002`),**HTTP 仍 200、body.code 非 0,不产生 HTTP 429/503**(见 [开闸验收门-W-G1](../架构/生成引擎/验收门-W-G1.md) 决策E,以及 `ErrorCodeConstants` 注释)。所以这个指标的告警语义是"在飞数逼近 `queueDepthLimit`",不是"返回 429 的次数"。埋点位:控制平面 `enqueueWithControlPlane` 背压判定处。
|
||||
- `gen_gate_fail_total{gate}` —— 九门各门失败计数,从 `game_aigc_task.trace_json`(九门轨迹账本)那条信息里出,定位是哪道门在拖低成功率。埋点位:九门校验节点。
|
||||
- `llm_cost_cents` / `llm_cache_hit_rate` —— 生成成本与前缀缓存命中率。**成本数据源待薄片落地**:后端代码现在没有任何读取 new-api 计费日志(`logs.quota`)的逻辑——`logs.quota 权威对账`目前只是 `SaaGraphDispatcher` 里的一句注释和 `docs/memorys` 的一个待建薄片设想,不是已接通的链路。要把成本做成实时指标,得先落地一个读 new-api `logs.quota` 的薄片把成本拉出来,再注册成指标。**缓存命中率掉到 50% 以下要告警**(历史回收清单 [运维基建-003](../_recall/运维基建-历史设计点.md) 的成本早期哨兵,缓存因 few-shot 字节漂移失效会让成本翻几倍)。
|
||||
- `llm_cost_cents` / `llm_cache_hit_rate` —— 生成成本与前缀缓存命中率。**成本数据源待薄片落地**:后端代码现在没有任何读取 new-api 计费日志(`logs.quota`)的逻辑——`logs.quota 权威对账`目前只是 `SaaGraphDispatcher` 里的一句注释和 `docs/memorys` 的一个待建薄片设想,不是已接通的链路。要把成本做成实时指标,得先落地一个读 new-api `logs.quota` 的薄片把成本拉出来,再注册成指标。**缓存命中率掉到 50% 以下要告警**(历史回收判定 运维基建-003 的成本早期哨兵,缓存因 few-shot 字节漂移失效会让成本翻几倍)。
|
||||
|
||||
> **contract-first(新建项清单)**:生成链路要接观测,跨模块面的新增物有三类——① **后端依赖**:`huijing-server`(或 aigc-server)pom 引入 OTel 相关依赖(actuator + micrometer + OTel Java Agent 走启动参数,不进 pom 也可),让 `ObservationRegistry` 非 NOOP;② **指标埋点**:上面五个指标在对应 Worker/控制平面/九门节点类补 `MeterRegistry` 注册调用(纯应用内新增,不动契约 yaml/DB);③ **成本薄片**:新建读 `logs.quota` 的成本采集薄片(单独一件事,见上)。这三类都是"现在没有、要新建",落地前观测大盘上的生成指标全是空的。
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user