zizi-al/games-development-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(recall): 历史回收第二轮(查漏补缺+review)6 域清单 + 总索引更新

Browse Source 
拿这几天 9 份新设计档复核第一轮 199 条 + 补漏:
- 新挖 43:跨域双漏(admin 审核台四页+观测三入口)/ 3 条确定性后端缺口
  (trade_income 缺 game_id·game_stat 缺留存·封号级联零实现)/ 生成硬门 A-E
  pivot 未回填 canon / 冷启动供给(种子游戏+创作者 BD)/ 广告挂了要跳过保留存 /
  new-api 网关健康巡检
- 改判 28:含 1 个真判错(后端 008 推荐公式第一轮误判遗落,实早在架构 README §7)
- 已被新档覆盖 36:证回收→设计闭环有效(审核台整章接运营 9 条 / 观测+k8s 接运维
  9 条 / 数据飞轮接生成 4 条)
- 总索引 README 补第二轮章节;6 域清单带空判定列待创始人逐条判

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
zizi 2026-06-22 01:15:25 +00:00
parent 15b707fd2a
commit 7b40175853
7 changed files with 466 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
docs/architecture/_recall/README.md
View File

@ -80,4 +80,35 @@
第 2 / 3 / 5 条的骨架里原本写了"范围建议(待创始人确认边界)"——这三条要补的设计都不小,边界(MVP 做到哪一档)定了我才出正式设计稿,免得范围未定就写、写完返工。
**更新(2026-06-21):创始人已定三条边界——② 三条飞轮全做 / ③ 审核台全做(含锁风三档)/ ⑤ 观测全做且本阶段上 k8s。** 范围已回填进三个骨架(生成引擎 §10 / 合规闸门 §9 / 运维 §4);其中 ⑤ 的 k8s 迁移是部署架构大变更,我已在骨架里标注 blast radius、建议与观测埋点解耦单独立项。下一步出正式设计稿。
**更新(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 通道批量失效真实发生过),现行档只有一句飘在风险表的应对、零运维落点。
判定方式同第一轮:每条第二轮清单带空判定列,你勾捡回 / 不捡 / 再议。

55
docs/architecture/_recall/产品战略-第二轮.md Normal file
View File

@ -0,0 +1,55 @@
# 产品战略 · 历史设计点回收 第二轮(复核 + 查漏)
> **这份是什么**:对第一轮《产品战略-历史设计点.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 是一组,补上就让"这半年算不算没白干"有了一句能挂在墙上的判据。

98
docs/architecture/_recall/前端-第二轮.md Normal file
View File

@ -0,0 +1,98 @@
# 前端域 · 历史设计点回收 · 第二轮(复核 + 查漏)
> **这份是什么。** 第一轮已经把前端域的历史设计点穷尽式挖了一遍,落成 [前端-历史设计点.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"是否纳入近期前端范围。

64
docs/architecture/_recall/后端数据契约-第二轮.md Normal file
View File

@ -0,0 +1,64 @@
# 后端数据契约 · 第二轮:复核 + 查漏
> 这是对第一轮《后端数据契约-历史设计点.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)是新机制带来的、待创始人拍的后端契约设计选择。

76
docs/architecture/_recall/生成引擎-第二轮.md Normal file
View File

@ -0,0 +1,76 @@
---
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 那两条工程原则、和"整图串行"架构约束的补记,偏定性、留给创始人判要不要显式立。

86
docs/architecture/_recall/运维基建-第二轮.md Normal file
View File

@ -0,0 +1,86 @@
# 运维基建 · 第二轮(复核 + 查漏补缺)
> 这一份是对第一轮《运维基建-历史设计点.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 的调度面归谁管**,这两条都是"命脉级但无人接"的,值得优先拍。

55
docs/architecture/_recall/运营变现合规-第二轮.md Normal file
View File

@ -0,0 +1,55 @@
# 运营变现合规 · 第二轮(复核 + 查漏)
这一轮做的是给第一轮的回收清单做体检:抽验它的出处真不真、分类判得准不准,再看第一轮之后新落地的一批设计稿把哪些"遗落/不确定"接住了,最后顺着第一轮没扫到的角落补几条。不重抄第一轮已经对的条目,只产出三类——改判的、被新档覆盖的、新挖的。
> **第一轮之后新落地、这一轮拿来比对的新档**:运营域的《审核台运营》(双层审核判定流 + 锁风三档 + 违规处置联动 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(举报率反向触发人审)是审核台闭环里"事中召回"那一环的缺口,补上审核台就从"只防新内容"变成"也防上线后变坏的内容"。