diff --git a/docs/architecture/_recall/README.md b/docs/architecture/_recall/README.md index e647d19d..d2b50fed 100644 --- a/docs/architecture/_recall/README.md +++ b/docs/architecture/_recall/README.md @@ -63,3 +63,19 @@ 每份清单是一张表,列是:**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 做到哪一档)定了我才出正式设计稿,免得范围未定就写、写完返工。 diff --git a/docs/architecture/产品/商业定位.md b/docs/architecture/产品/商业定位.md index 6776c632..cb4aab69 100644 --- a/docs/architecture/产品/商业定位.md +++ b/docs/architecture/产品/商业定位.md @@ -56,6 +56,8 @@ quadrantChart > 真正归我们独家的,不是 IP(IP 非独家,只是冷启动燃料),而是**创作者沉淀在平台上、搬不走的生态资产**。详细对外口径见[护城河话术](护城河话术.md)。 +**平台方下场的风险与应对(创始人 2026-06-21 定调)。** 有一个绕不开的真实风险:如果微信、抖音这类上游平台自己上线"IP 授权 + 一句话生成",绘境的位置还在不在?诚实的判断是——平台方会做通用、做规模,但不会为腰尾部 IP 做精细保真,也不会替创作者把"做得出 → 有人玩 → 赚到钱"这条闭环一段段踩实。我们的应对不是去比平台的流量,而是往产品深处扎,扎两个平台方为了通用化不愿意做的方向:一是**深化游戏引擎的使用**——tier2 自治富游戏引擎让生成的游戏从超休闲单局走到合成、经营、挂机这类有系统深度的品类(见[架构域生成引擎子树](../架构/生成引擎/自治富游戏引擎.md));二是**深化创作能力**——把对话式创作加差量修改的完整闭环做扎实,让创作者改得动、也养得熟一个能长期运营的游戏项目。引擎深度和创作深度都是平台方为通用化不愿做的脏活,也正是创作者真正搬不走的那层资产。 + --- ## 4. 三线变现战略(现行战略主轴) diff --git a/docs/architecture/前端/README.md b/docs/architecture/前端/README.md index 036132f7..0dcf5a42 100644 --- a/docs/architecture/前端/README.md +++ b/docs/architecture/前端/README.md @@ -186,7 +186,15 @@ token 还承担一个长期使命:**做跨端的单一事实源**(single source - **玩法模板中心**:注意——这里指的是 demo 那块"玩法品类层市场"屏,已被创始人 2026-06-12 的 W-CLEAN 清理(清理旧填参式模板的收口工作)废除。它与架构文档里"玩法模板 = 品类框架、未废、待建"是两回事,**不要混淆**。 - **创作者数据后台**:远期;落地须反向定义出回读 API + 把诊断接到生成侧,避免产生没有入口的孤儿数据。 - **多渠道发布**:抖音/微信/快手/TapTap 等渠道导出,归独立的渠道发行专项另行推进,游戏信息流的终裁不受影响。 -- **工作坊 IDE 化**:六类资产台、智能体对话、授权 IP 模式、编辑态调参等;MVP 走的是"一句话 + 选模板 → 整包生成"的简化路径。 +- **完整可视化编排 IDE**:全自定义拖拽式编排、授权 IP 模式、编辑态逐参可视化调试等专业向能力,属远期,MVP 不做。 + +### 7.3 产品形态定调:对话式创作不是 descope(创始人 2026-06-21) + +要把上一条和"对话式创作"分清,否则容易把产品形态错当成被砍掉的范围。绘境的**完整产品形态是对话式创作闭环**:多轮对话把游戏生成出来、对已经生成的游戏做差量修改(换美术、改第 2 关,只动一处、不毁全局)、以及修改游戏里用到的素材。"一句话 + 选玩法模板 → 整包生成"不是终点,而是**发起一次生成的启动点位之一**。 + +这套能力的后端已经是现行真相——`/studio/modify`、`/studio/extend` 端点和 SAA 的 modify 节点都建好了,studio 三路由 `/studio/{create,modify,extend}` 也在。当前缺的是前端承载:对话框、把六类素材传进去当生成上下文、系统解析意图后的目标确认卡、以及差量修改的入口和"改了哪、其余没动"的差异展示(对应[历史回收清单](../_recall/前端-历史设计点.md)的前端 C01–C04)。所以这块不是"descope 勿返工",而是**产品形态已经定调、前端 UI 待补设计**。 + +> 一处口径校准:产品域需求清单里"智能体对话式创作"(P-CRT-05)、素材中心(P-MAT 整组)、同款创作(P-FED-12)目前仍标 P1。把它们定调为产品形态讲的是**方向**,不等于把验收优先级一次性提到 P0——验收范围的调整另走评审,别因这条定调就擅自改动验收契约。 --- diff --git a/docs/architecture/架构/生成引擎/README.md b/docs/architecture/架构/生成引擎/README.md index a407edfc..593943e3 100644 --- a/docs/architecture/架构/生成引擎/README.md +++ b/docs/architecture/架构/生成引擎/README.md @@ -350,3 +350,21 @@ flowchart LR --- > **验证状态**:本文档为架构策展文档,由四份已评审源档(含 2026-06-20 设计合理性裁决)合成,未改任何代码。承重硬事实(V18 建表 + V20 加并发幂等唯一键、prompt registry 已存在、SAA 16 节点、九门、80% 门、¥0.15 / P75≤30s 预算时延门、76%–93% 缓存命中、OpenGame 结论锚在其真源码、Tier0 范式定性锚在裁决档)均沿用源档已抽查属实的结论;品牌已统一为"绘境AI"。 + +--- + +## 10. 待补设计:数据飞轮的生成侧落点(创始人 2026-06-21 判定补充) + +> 以下为创始人逐条判定[历史回收清单](../../_recall/README.md)后新增的待补设计立位,尚未展开为正式设计。 + +护城河逻辑里"资产沉淀 + 网络效应 + 数据"三层,在生成侧本来有一组具体工程动作。创始人在意图基线(HJ-GEN-001)里亲拍过"全采纳",收窄到 Tier0 当下产线时丢掉了,现行档没有落点。这一节先把要补的设计立位,等范围定了再展开成正式设计。 + +要补的是三条互相咬合的飞轮: + +- **创作者资产库 → 资产市场**:创作者生成游戏时沉淀下来的素材、配置、玩法骨架,能复用、能流通,长成搬不走的资产层。 +- **玩家 → 创作者的 remix(带溯源链)**:玩家在信息流里看到一款游戏,直接发起"做一个同款",生成时带上溯源,把消费侧流量导回创作侧——这是网络效应飞轮的核心动作(对应需求清单 P-FED-12 同款创作)。 +- **生成全量 + 收益数据回流训练语料**:生成全过程数据,加上线上真实的收益与留存数据,回流成训练语料,反过来抬升生成质量与商业化判断。现行的进化语料只覆盖了生成侧自增强,漏了收益回流这一半。 + +**范围建议(待创始人确认边界)**:MVP 建议先落"溯源链 + 同款创作"这条最轻、又直接喂网络效应的飞轮;资产市场牵涉交易与分成,和素材契约、支付绑定,建议排在素材中心(P-MAT)之后;收益回流训练牵涉数据管线,建议作为数据线(②自有端内测)成型后的增量。MVP 要落到哪一档,请创始人定。 + +**下一步**:边界定了之后由我出正式设计稿(接进本生成引擎子树),前端同款创作入口与 admin 落点随设计稿一并定;代码执行归 Mac。 diff --git a/docs/architecture/运维/README.md b/docs/architecture/运维/README.md index 39b0d018..c847359e 100644 --- a/docs/architecture/运维/README.md +++ b/docs/architecture/运维/README.md @@ -99,3 +99,21 @@ flowchart TB | 当前进度与实操总账 | staging 上各模块的真实状态、历次部署踩坑实录 | [`docs/mvp/MVP进度总账.md`](../../mvp/MVP进度总账.md) | > **纪律**:运维域只讲"环境边界 / 部署链 / 健康门 / 可用性目标"这层骨架。**一行命令该怎么敲,以 `deploy/` 脚本和 `.agents/skills/staging-ops.md` 为准**;两者冲突时,以会运行的脚本为准。本页与[架构域](../架构/README.md)(系统怎么搭)、[运营域](../运营/README.md)(合规上线与发行)互不重复、各管一段。 + +--- + +## 4. 待补设计:线上观测体系(创始人 2026-06-21 判定补充) + +> 以下为创始人逐条判定[历史回收清单](../_recall/README.md)后新增的待补设计立位,尚未展开为正式设计。 + +上面 §1.3 / §1.4 回答了"怎么知道它健康(冒烟门)"和"健康到什么程度算达标(≥99.5%)",但"线上靠什么持续观测"这一问,现行档是留白的——蓝图画过 Prometheus / Grafana / Jaeger,现实只有秒级冒烟门加一个可用性数字,配不上持续观测的目标。创始人判定:补,而且给了明确方向。 + +创始人指定的栈与落点: + +- **三件齐全**:链路日志 + 指标观测 + 监控告警。采集侧走 **OpenTelemetry**(统一 trace / metrics / log 的采集标准),看板与告警用 **Grafana** 加 **夜莺(Nightingale)**。 +- **admin 侧补观测入口**:在 admin 控制台补"观测跳转 / 观测大图",让运营和排查能从后台一键进到监控大盘,而不是各看各的散件。 +- **部署形态**:观测栈与服务编排往 **k8s** 收;可参考 **yudao-cloud / vue-pro** 已有的监控集成(它本身带了一套可观测性接入,能省掉从零搭的工夫)。 + +**范围建议(待创始人确认边界)**:MVP 建议先落"OpenTelemetry 采集 + 一个 Grafana 大盘 + 关键告警(可用性 / 错误率 / 生成失败率)+ admin 观测跳转"这条最小可观测闭环;夜莺与 k8s 编排建议随服务从单体 staging 走向正式集群时一起上。MVP 观测要做到哪一步、是否本阶段就上 k8s,请创始人定。 + +**下一步**:边界定了之后由我出正式设计稿(接进运维域 + admin 前端入口);采集埋点与栈搭建的代码执行归 Mac。 diff --git a/docs/architecture/运营/合规闸门.md b/docs/architecture/运营/合规闸门.md index 642595c1..2808ec7e 100644 --- a/docs/architecture/运营/合规闸门.md +++ b/docs/architecture/运营/合规闸门.md @@ -235,3 +235,21 @@ sequenceDiagram | 决策史与逐档证据 | git 历史 + [`战略与合规`](../../architecture/运营/合规闸门.md)(canonical 活档)+ `_archive/` 审计报告 | > **纪律**:本页只写"合规闸门的设计逻辑与不变量"。任何会随日历推进而变化的状态——某项是否已提交、卡在哪一步、谁负责——一律只记在 [A1 闸门看板](../../mvp/A1闸门看板.md);本页不得复制这些状态,否则就会出现两份冲突的真相。仍然阻塞全局的最大未决项是:**Doc A(产品需求清单)里的法定 8 项换血,待律所对两核心问给出书面意见后才能定稿。** + +--- + +## 9. 待补设计:审核台运营机制(创始人 2026-06-21 判定补充) + +> 以下为创始人逐条判定[历史回收清单](../_recall/README.md)后新增的待补设计立位,尚未展开为正式设计。 + +前面几节把"法定要过哪些闸门"讲清楚了,但平台日常怎么把内容安全运营起来——也就是审核台这一摊——现行档基本空白。创始人判定:没有设计,需要补。这一节先立位,范围定了再展开。 + +要补的是三块: + +- **内容审核的双层架构**:自部署的快检模型先过一道(快、便宜、挡掉大面),阿里云内容安全做兜底(权威、有合规背书),拦不准的进人审队列(走 BPM 工作流)。 +- **锁风门的三档强度**:标准 / 严格 / 人工复核,按 IP 敏感度和内容类型选档,决定一款生成内容要不要、以多严的力度过保真与版权检查。 +- **违规处置**:封禁、举报降权、分级标签这套处置动作,以及它们怎么联动到信息流的曝光权重和创作者信用。 + +**范围建议(待创始人确认边界)**:MVP 建议先落"自部署快检 + 人审队列 + 基础处置(下架 / 降权)"这条最小可运营闭环;阿里云内容安全兜底建议在接真实公开流量(渠道线③)前接入;锁风三档与 IP 库绑定,建议随素材 / IP 授权模型一起做。MVP 审核台要做到哪一步,请创始人定。 + +**下一步**:边界定了之后由我出正式设计稿(接进运营 / 合规域),admin 审核台前端入口随设计稿定;代码执行归 Mac。