This commit is contained in:
@@ -0,0 +1,346 @@
|
||||
# 方向 13 软件智能化提升奖励材料整理（2026-04-14）
|
||||
|
||||
## 1. 方向判断
|
||||
|
||||
### 1.1 与当前项目的匹配点
|
||||
|
||||
当前项目与附件 13 的匹配点主要有：
|
||||
|
||||
1. 项目本质上是 `游戏软件` 的智能化提升。
|
||||
2. AI 能力不是外挂聊天，而是深入到剧情、世界生成、任务、NPC 关系、运行时内容编排等核心软件功能。
|
||||
3. 当前项目具有完整软件工程形态：
|
||||
- 前端应用
|
||||
- `Express` 后端
|
||||
- 数据存储
|
||||
- AI 服务编排
|
||||
- 编辑器与内容工具链
|
||||
|
||||
### 1.2 当前方向的主要风险
|
||||
|
||||
附件 13 的门槛并不低，当前必须优先核验以下事项：
|
||||
|
||||
1. 项目纳入奖励范围的总投资额是否 `>= 500 万元`
|
||||
2. 项目是否已经 `竣工并投入运行`
|
||||
3. 项目建设周期是否 `<= 2 年`
|
||||
4. 是否具备 `2 项软著` 或 `1 项发明专利`
|
||||
5. 是否已接入 `已备案国产主流大模型`
|
||||
6. 是否有 `日均 Token >= 500 万`
|
||||
7. 是否能满足 `5 个不同客户案例` 或 `5 万 DAU`
|
||||
8. 是否能取得 `CNAS/CMA` 机构出具的软件智能化成熟度测评报告
|
||||
|
||||
如果以上条件中有 3 项以上暂无依据，建议把方向 13 视为“高潜力但高补件强度”的主申报方向，而不是“马上能提报”的方向。
|
||||
|
||||
## 2. 官方要求拆解
|
||||
|
||||
### 2.1 申报条件
|
||||
|
||||
1. 在北京市登记注册，具有独立法人资格的信息软件企业
|
||||
2. 项目纳入奖励范围的总投资额超过 `500 万元（含）`
|
||||
3. 截至申报日项目已竣工并投入运行，竣工时间在 `2025 年 1 月 1 日` 及以后
|
||||
4. 项目形成的智能软件产品具备自主知识产权，取得不少于 `2 项软著` 或 `1 项发明专利`
|
||||
5. 项目建设周期不超过 `2 年`
|
||||
|
||||
### 2.2 绩效要求
|
||||
|
||||
项目需同时满足以下条件：
|
||||
|
||||
1. 形成智能化软件开发能力
|
||||
- 代码生成占比 `>= 35%`，或代码行采纳率 `>= 30%`
|
||||
|
||||
2. 形成智能化软件产品
|
||||
- 接入已备案国产主流大模型
|
||||
- 具备自然语言或多模态交互
|
||||
- 日均 Token 消耗量不少于 `500 万`
|
||||
- 软件智能化成熟度至少达到 `部分智能化`
|
||||
|
||||
3. 具备行业应用效果
|
||||
- 面向企业端：至少 `5 个不同客户`
|
||||
- 面向消费者端：`DAU > 5 万`
|
||||
|
||||
## 3. 申报材料总清单
|
||||
|
||||
### 3.1 必交材料
|
||||
|
||||
1. 《北京市软件智能化提升项目绩效要求》对应证明材料
|
||||
2. 《智能化提升项目纳入奖励范围的总投资要求》对应专项审计与明细
|
||||
3. 《智能化提升奖励申报表》
|
||||
4. 《智能化提升项目实施总结报告》及证明材料
|
||||
5. 《北京市高精尖产业发展项目资金承诺书》
|
||||
6. 企业最新版营业执照复印件
|
||||
7. 其他与项目有关的补充资料
|
||||
|
||||
### 3.2 材料与项目事实的对应关系
|
||||
|
||||
| 官方材料 | 需要表达什么 | 当前项目可复用内容 | 当前待补件 |
|
||||
| --- | --- | --- | --- |
|
||||
| 申报表 | 项目基本信息、投资、创新点、成效、推广性 | `README.md`、`docs/prd/`、`docs/technical/` | 企业信息、投资额、建设时间、客户/DAU、资金支持情况 |
|
||||
| 实施总结报告 | 项目背景、建设方案、关键技术、投资、绩效、效益 | `README.md`、剧情引擎/自定义世界/技术文档 | 立项/结项文件、专项审计、成熟度测评、日志证明 |
|
||||
| 技术设备与投资明细 | 硬件、软件、材料、研发人员投入 | 可从采购、云资源、模型调用、开发工具里整理 | 发票、合同、付款凭证、记账凭证、审计报告 |
|
||||
| 知识产权证明 | 项目形成软件的自主知识产权 | 仓库结构、架构、功能模块可支撑匹配说明 | 软著/专利证书本体 |
|
||||
| 绩效证明 | AI 编码、模型接入、Token、成熟度、应用效果 | 代码仓库、运行日志、接口能力说明 | 第三方编码平台证明、Token 数据、测评报告、客户合同或 DAU |
|
||||
|
||||
## 4. 建议的申报项目命名
|
||||
|
||||
建议在以下 3 个口径中选一个：
|
||||
|
||||
1. `AI 原生剧情引擎与游戏软件智能化提升项目`
|
||||
2. `面向互动叙事游戏的 AI 原生剧情引擎智能化提升项目`
|
||||
3. `跨题材 AI 原生叙事游戏软件智能化改造项目`
|
||||
|
||||
推荐优先使用：
|
||||
|
||||
`AI 原生剧情引擎与游戏软件智能化提升项目`
|
||||
|
||||
原因：
|
||||
|
||||
- 兼顾 `游戏软件` 与 `智能化提升`
|
||||
- 不把自己限制成单一玩法
|
||||
- 后续客户案例或平台化能力也更好挂靠
|
||||
|
||||
## 5. 申报表字段建议底稿
|
||||
|
||||
### 5.1 项目所属领域
|
||||
|
||||
建议填写：
|
||||
|
||||
- `游戏软件`
|
||||
|
||||
### 5.2 项目主要内容（1000 字内，可作为首稿）
|
||||
|
||||
建议首稿：
|
||||
|
||||
> 本项目围绕 AI 原生视觉 RPG 产品开展智能化提升，建设内容覆盖 AI 原生剧情引擎、自定义世界生成、角色关系与任务生成、运行时物品叙事编排、流式交互式对话以及后端持久化与内容工具链等核心模块。项目以“AI 负责叙事表达、本地规则负责状态裁决”为总体技术路线，通过接入大模型能力和本地规则编排机制，完成传统游戏内容生产和运行时交互链路的智能化改造，使游戏软件从固定脚本驱动升级为可结构化生成、可状态约束、可持续演进的 AI 原生软件产品。
|
||||
|
||||
### 5.3 项目关键技术和创新点（1000 字内，可作为首稿）
|
||||
|
||||
建议首稿要点：
|
||||
|
||||
1. `剧情引擎结构化`
|
||||
- 通过 `themePack / storyGraph / narrativeProfile / knowledgeFacts / threadContracts` 等结构，把大模型输出从松散文本升级为可控的剧情引擎语义层。
|
||||
|
||||
2. `AI 与本地规则分工`
|
||||
- AI 负责叙事表达、关系生成、世界扩展，本地规则负责数值、状态、任务推进、背包、招募、持久化等核心逻辑，提升软件稳定性与可验证性。
|
||||
|
||||
3. `跨题材自定义世界生成`
|
||||
- 支持从用户输入的世界锚点出发，生成世界框架、场景、角色、剧情线程和运行时资料，提升内容生产效率与可扩展性。
|
||||
|
||||
4. `运行时智能交互`
|
||||
- 在实际游玩过程中，支持流式剧情推进、NPC 对话、关系推进、任务生成和物品叙事编排，实现游戏软件运行态的智能化。
|
||||
|
||||
5. `前后端协同架构`
|
||||
- 以 `Express + PostgreSQL` 为服务端核心，实现运行时 AI 接口、持久化、资产接口、编辑器写盘与开发联调支撑，形成可持续迭代的软件产品工程体系。
|
||||
|
||||
### 5.4 项目智能化改造成效（1000 字内，建议结构）
|
||||
|
||||
建议分 4 段写：
|
||||
|
||||
1. `技术重构内容`
|
||||
- 从静态内容和单轮生成升级为结构化世界生成、角色叙事档案、线程驱动任务和运行时记忆回写。
|
||||
|
||||
2. `智能化改造重点`
|
||||
- 大模型接入、自然语言交互、智能生成剧情、智能生成任务、智能物品叙事、多阶段世界生成。
|
||||
|
||||
3. `效益量化评估`
|
||||
- 内容生产效率提升、生成链路自动化率提升、编辑器与运行时联动效率提升、研发智能辅助能力增强。
|
||||
|
||||
4. `生态适配能力和社会经济效益`
|
||||
- 面向互动叙事、游戏软件、数字内容、IP 衍生、文化科技融合场景具备复制潜力。
|
||||
|
||||
### 5.5 项目可推广性（1000 字内，建议结构）
|
||||
|
||||
建议强调：
|
||||
|
||||
1. 可从单款产品复用为 `AI 互动叙事引擎`
|
||||
2. 可扩展到多题材、多世界观、多角色规模
|
||||
3. 可服务于游戏、互动内容、数字文化产品
|
||||
4. 后续具备平台化、SaaS 化或中台化演化空间
|
||||
|
||||
## 6. 实施总结报告建议写法
|
||||
|
||||
### 6.1 报告结构
|
||||
|
||||
按附件 13-5 的模板，建议直接写成以下章节：
|
||||
|
||||
1. 企业基本情况介绍
|
||||
2. 项目建设方案
|
||||
3. 项目建设情况
|
||||
4. 相关证明材料
|
||||
5. 其他需说明事项
|
||||
|
||||
### 6.2 可直接落稿的章节框架
|
||||
|
||||
#### 一、企业基本情况介绍
|
||||
|
||||
建议覆盖：
|
||||
|
||||
- 企业基本信息
|
||||
- 发展阶段
|
||||
- 核心软件产品
|
||||
- 近 3 年经营情况或成立以来经营情况
|
||||
- 当前研发团队与技术方向
|
||||
|
||||
#### 二、项目建设方案
|
||||
|
||||
`2.1 项目主要内容`
|
||||
|
||||
- 从“传统脚本化内容生产和运行时交互效率低、扩展成本高”切入
|
||||
- 强调项目要解决的核心问题：
|
||||
- 内容生成成本高
|
||||
- 叙事扩展难
|
||||
- 互动体验不连续
|
||||
- 游戏软件的智能化程度不足
|
||||
|
||||
`2.2 项目建设方案`
|
||||
|
||||
建议写成 5 个子模块：
|
||||
|
||||
1. AI 原生剧情引擎模块
|
||||
2. 自定义世界生成模块
|
||||
3. 角色关系与任务智能生成模块
|
||||
4. 运行时交互与持久化模块
|
||||
5. 编辑器与资产工具链模块
|
||||
|
||||
`2.3 项目关键技术和创新`
|
||||
|
||||
建议围绕以下关键词展开：
|
||||
|
||||
- 大模型接入与多阶段编排
|
||||
- 结构化剧情引擎语义层
|
||||
- AI 叙事与本地规则协同
|
||||
- 游戏软件运行态智能化
|
||||
- 自定义世界生成和叙事图谱构建
|
||||
|
||||
`2.4 项目预期实现的经济社会效益`
|
||||
|
||||
建议从 3 个角度写：
|
||||
|
||||
1. 提升游戏软件研发和内容生产效率
|
||||
2. 形成 AI 原生互动叙事软件产品能力
|
||||
3. 为数字内容、文化科技融合和互动娱乐软件提供可复制技术路径
|
||||
|
||||
#### 三、项目建设情况
|
||||
|
||||
`3.1 项目概况`
|
||||
|
||||
- 项目建设地点
|
||||
- 起止时间
|
||||
- 版本迭代时间点
|
||||
- 上线 / 投运节点
|
||||
|
||||
`3.2 项目建设内容完成情况`
|
||||
|
||||
建议按“计划模块 -> 已完成内容 -> 当前状态”写。
|
||||
|
||||
`3.3 项目投资完成情况`
|
||||
|
||||
- 技术设备费
|
||||
- 材料费
|
||||
- 研发人员费用
|
||||
- 资金到位与使用情况
|
||||
- 专项审计情况
|
||||
|
||||
`3.4 项目绩效完成情况`
|
||||
|
||||
必须逐项回应：
|
||||
|
||||
1. 代码生成占比 / 采纳率
|
||||
2. 国产主流大模型接入
|
||||
3. 日均 Token 量
|
||||
4. 软件智能化成熟度等级
|
||||
5. 行业应用效果或 DAU
|
||||
|
||||
`3.5 项目其他实施效果`
|
||||
|
||||
- 工程效率提升
|
||||
- 研发流程优化
|
||||
- 内容产能提升
|
||||
- 交互质量提升
|
||||
- 可扩展性提升
|
||||
|
||||
## 7. 证据材料采集清单
|
||||
|
||||
### 7.1 基础证明
|
||||
|
||||
- 营业执照
|
||||
- 立项决议 / 项目启动文件
|
||||
- 项目竣工 / 版本上线证明
|
||||
- 项目建设周期证明
|
||||
|
||||
### 7.2 投资与审计证明
|
||||
|
||||
- 设备清单
|
||||
- 投资支出明细表
|
||||
- 发票
|
||||
- 付款凭证
|
||||
- 记账凭证
|
||||
- 银行流水
|
||||
- 采购合同
|
||||
- 专项审计报告
|
||||
- 研发人员清单、工资、社保材料
|
||||
|
||||
### 7.3 技术与知识产权证明
|
||||
|
||||
- 软著
|
||||
- 发明专利
|
||||
- 知识产权与申报产品对应关系说明
|
||||
- 架构图
|
||||
- 关键模块说明
|
||||
|
||||
### 7.4 智能化绩效证明
|
||||
|
||||
- 第三方辅助编码平台导出的代码生成占比 / 采纳率
|
||||
- 项目周期内 1 个月辅助编码平台日志
|
||||
- 大模型接入截图
|
||||
- 网信办备案截图
|
||||
- 日均 Token 量后台证明
|
||||
- 第三方智能化成熟度测评报告
|
||||
|
||||
### 7.5 应用效果证明
|
||||
|
||||
二选一准备：
|
||||
|
||||
1. `B 端路径`
|
||||
- 5 个不同客户销售合同
|
||||
- 上线或验收证明
|
||||
- 非关联关系证明
|
||||
|
||||
2. `C 端路径`
|
||||
- 后台 DAU 日志
|
||||
- 统计口径说明
|
||||
- 关键时间段截图
|
||||
|
||||
## 8. 当前项目的红黄绿核验表
|
||||
|
||||
| 核验项 | 当前判断 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 北京市信息软件企业主体 | `待核验` | 仓库无法证明，需企业基础材料确认 |
|
||||
| 项目总投资 >= 500 万 | `待核验` | 需按附件 13-3 口径做专项审计测算 |
|
||||
| 项目竣工并投运 | `待核验` | 需形成明确版本竣工和运行证明 |
|
||||
| 建设周期 <= 2 年 | `大概率可满足` | 需立项与竣工时间文件确认 |
|
||||
| 2 项软著或 1 项发明专利 | `待核验` | 当前仓库未见证书信息 |
|
||||
| 国产主流备案模型接入 | `待核验` | 需提供模型名称、备案号和接入截图 |
|
||||
| 日均 Token >= 500 万 | `高风险` | 需要真实运行数据支撑 |
|
||||
| 智能化成熟度测评 | `待补` | 需第三方机构报告 |
|
||||
| 5 客户或 5 万 DAU | `高风险` | 需选定 B 端或 C 端路径并集中准备 |
|
||||
|
||||
## 9. 推荐的实际推进动作
|
||||
|
||||
1. 立刻建立 `方向 13 数据底表`
|
||||
- 建设周期
|
||||
- 投资金额
|
||||
- 研发人员
|
||||
- 模型调用量
|
||||
- 客户 / DAU
|
||||
- 软著 / 专利
|
||||
|
||||
2. 先做一版 `项目实施总结报告` Word 初稿
|
||||
- 文字先成型
|
||||
- 数字和证明后补
|
||||
|
||||
3. 同步预约或筛选 `智能化成熟度测评机构`
|
||||
|
||||
4. 立刻判断应用效果走哪条路径
|
||||
- `C 端 DAU`
|
||||
- `B 端 5 个客户`
|
||||
|
||||
5. 如果当前达不到 `5 万 DAU`，且已经有引擎化输出可能，建议考虑把申报产品口径从“单款游戏”适度提升为“AI 原生剧情引擎及其游戏软件应用”，以增强 B 端案例组织空间。
|
||||
@@ -0,0 +1,349 @@
|
||||
# 方向 21 “创赢未来”成长计划材料整理（2026-04-14）
|
||||
|
||||
## 1. 方向判断
|
||||
|
||||
### 1.1 与当前项目的匹配点
|
||||
|
||||
当前项目与方向 21 的匹配度较高，原因如下：
|
||||
|
||||
1. 方向 21 明确支持 `未来信息` 领域。
|
||||
2. 当前项目更适合归入 `未来信息 -> 通用人工智能`。
|
||||
3. 项目同时具备 `沉浸式互动内容`、`世界生成`、`角色智能体化`、`多轮交互式叙事` 等特征，可作为 `元宇宙` 叙事补充语义，但不建议作为首选归类。
|
||||
4. 从仓库状态看，项目已具备完整产品原型、明确技术路线和多阶段演进文档，适合做早期高潜企业 / 团队的路演材料。
|
||||
|
||||
### 1.2 推荐申报口径
|
||||
|
||||
建议主口径：
|
||||
|
||||
- `未来信息 -> 通用人工智能`
|
||||
|
||||
备选口径：
|
||||
|
||||
- `未来信息 -> 元宇宙`
|
||||
|
||||
推荐理由：
|
||||
|
||||
- 当前项目的核心竞争力在于 AI 原生剧情引擎、结构化世界生成与运行时智能交互，而不是纯 3D 场景或虚拟空间平台。
|
||||
|
||||
### 1.3 时间节点
|
||||
|
||||
附件 21 明确写明：
|
||||
|
||||
- `2026 年 6 月` 路演对应申报截止时间：`2026 年 5 月 15 日`
|
||||
|
||||
## 2. 官方材料要求
|
||||
|
||||
### 2.1 必交材料
|
||||
|
||||
1. “创赢未来”成长计划报名表
|
||||
2. 承诺书
|
||||
3. 商业计划书
|
||||
4. 产品或技术演示材料
|
||||
5. 其他补充材料
|
||||
|
||||
### 2.2 与当前项目的适配判断
|
||||
|
||||
| 材料 | 主要看点 | 当前项目优势 | 待补信息 |
|
||||
| --- | --- | --- | --- |
|
||||
| 报名表 | 团队、技术、行业归类、融资规划 | 技术方向清晰，产品结构完整 | 企业基本信息、财务、股权、融资、估值 |
|
||||
| 承诺书 | 基础合规 | 只需走公章和法人签字流程 | 公司主体信息 |
|
||||
| 商业计划书 | 行业空间、技术壁垒、商业化路径、融资用途 | 文档体系完整，路线图和产品能力明确 | 市场数据、营收、客户、融资规划 |
|
||||
| 产品/技术演示 | 路演说服力 | 项目演示性很强，适合做 Demo | 需组织脚本、录屏和讲解 |
|
||||
| 补充材料 | 荣誉、知识产权、合作 | 可补架构、PRD、测试、软著等 | 荣誉、融资、客户证明 |
|
||||
|
||||
## 3. 报名表逐项整理建议
|
||||
|
||||
### 3.1 一、申报主体基本情况
|
||||
|
||||
#### 推荐准备字段
|
||||
|
||||
- 申报主体名称
|
||||
- 统一社会信用代码
|
||||
- 注册资本
|
||||
- 注册地址 / 通讯地址
|
||||
- 企业性质
|
||||
- 法定代表人
|
||||
- 申报负责人 / 联系人
|
||||
- 申报主体人数
|
||||
- 研发人员人数与占比
|
||||
|
||||
#### 企业或创新团队简介建议口径
|
||||
|
||||
建议首稿：
|
||||
|
||||
> 团队围绕 AI 原生互动叙事软件开展研发，核心方向是构建可支撑跨题材互动内容生成、角色关系演化、运行时剧情推进和自定义世界创建的 AI 原生剧情引擎。当前已完成以视觉 RPG 为主要产品形态的原型验证，形成了前后端一体的软件产品框架，并围绕剧情引擎结构化、世界生成、任务编排、角色关系和运行时状态持久化建立了较完整的技术路线和产品文档体系。
|
||||
|
||||
#### 核心团队信息建议准备
|
||||
|
||||
每位核心成员建议统一整理以下字段：
|
||||
|
||||
- 姓名
|
||||
- 角色定位
|
||||
- 负责模块
|
||||
- 学历 / 过往经历
|
||||
- 擅长方向
|
||||
- 与项目的适配性
|
||||
- 奖项 / 荣誉 / 代表成果
|
||||
|
||||
### 3.2 二、核心技术与产品 / 服务
|
||||
|
||||
#### 核心技术基础
|
||||
|
||||
建议围绕以下 5 点展开：
|
||||
|
||||
1. 大模型驱动的剧情生成与世界生成
|
||||
2. 结构化剧情引擎语义层
|
||||
3. AI 叙事与本地规则协同架构
|
||||
4. 自定义世界分阶段生成技术
|
||||
5. 运行时智能交互与持久化技术
|
||||
|
||||
#### 技术 / 产品定位（不超过 300 字）
|
||||
|
||||
建议首稿：
|
||||
|
||||
> 项目聚焦 AI 原生互动叙事软件，面向游戏、数字内容与沉浸式互动场景，提供从世界构建、角色关系、任务生成到运行时剧情推进的一体化智能引擎能力。产品核心解决传统互动内容生产成本高、扩展慢、剧情可玩性不足的问题，支持在统一规则约束下实现多轮对话、动态剧情、角色状态演化与自定义世界生成。
|
||||
|
||||
#### 差异化优势与壁垒（不超过 300 字）
|
||||
|
||||
建议首稿：
|
||||
|
||||
> 项目的差异化不在于简单接入大模型，而在于构建了“AI 负责叙事表达、本地规则负责状态裁决”的分层架构，并将大模型能力进一步沉淀为结构化剧情引擎语义层。相比纯聊天式互动产品，本项目在世界生成、角色关系、任务推进、内容持久化和运行时控制方面具备更强的可控性、可扩展性和软件产品化能力。
|
||||
|
||||
#### 知识产权情况
|
||||
|
||||
当前建议填写方式：
|
||||
|
||||
- 已授权专利：`[待补]`
|
||||
- 发明专利：`[待补]`
|
||||
- 软件著作权：`[待补]`
|
||||
- 其他知识产权：`[待补]`
|
||||
|
||||
#### 技术 / 产品成熟度
|
||||
|
||||
如果当前还未形成稳定商业化收入，建议优先选择：
|
||||
|
||||
- `中试 / 测试`
|
||||
|
||||
如果已经存在真实付费客户或稳定运营数据，再考虑：
|
||||
|
||||
- `已完成商业化`
|
||||
|
||||
#### 商业化进展
|
||||
|
||||
建议按真实情况二选一：
|
||||
|
||||
1. 如果已有收入
|
||||
- 填历史收入、当前客户和代表性案例
|
||||
|
||||
2. 如果尚在测试阶段
|
||||
- 建议如实填写：
|
||||
- 已完成核心原型验证
|
||||
- 已形成可演示产品
|
||||
- 正在推进测试验证 / 合作接洽 / 商业化探索
|
||||
|
||||
### 3.3 三、核心产业领域
|
||||
|
||||
建议勾选：
|
||||
|
||||
- `未来信息 -> 通用人工智能`
|
||||
|
||||
如需辅助说明，可在备注中补一句：
|
||||
|
||||
> 项目兼具沉浸式互动内容和数字世界生成特征，但核心技术驱动仍以通用人工智能能力为主。
|
||||
|
||||
### 3.4 四、融资历史与资本结构
|
||||
|
||||
需要准备：
|
||||
|
||||
- 历史融资时间、轮次、金额、投资方、估值
|
||||
- 当前股权结构
|
||||
- 当前估值
|
||||
- 现有资金储备与可持续运营时间
|
||||
|
||||
如果暂无外部融资，建议如实写：
|
||||
|
||||
- 历史融资：暂无
|
||||
- 当前股权结构：创始团队持股 `100%` 或按真实结构填写
|
||||
- 当前估值：按拟融资口径测算
|
||||
|
||||
### 3.5 五、历史财务信息
|
||||
|
||||
如果已注册公司，需要补齐：
|
||||
|
||||
- `2024`
|
||||
- `2025`
|
||||
- 最近一期
|
||||
|
||||
指标包括：
|
||||
|
||||
- 营业收入
|
||||
- 利润总额
|
||||
- 净利润
|
||||
- 研发投入
|
||||
- 总资产
|
||||
- 净资产
|
||||
- 经营活动现金流净额
|
||||
|
||||
### 3.6 六、融资规划与发展战略
|
||||
|
||||
#### 未来 12-18 个月资金用途建议分类
|
||||
|
||||
建议按以下 5 类填：
|
||||
|
||||
1. 产品研发与迭代
|
||||
2. 核心技术团队扩建
|
||||
3. 市场推广与业务拓展
|
||||
4. 基础设施与模型调用投入
|
||||
5. 补充运营流动资金
|
||||
|
||||
#### 关键发展里程碑建议
|
||||
|
||||
建议先按以下 5 条拟定：
|
||||
|
||||
1. 完成 AI 原生剧情引擎核心能力升级，并形成可对外展示的稳定版本
|
||||
2. 完成自定义世界生成与角色叙事系统的产品化闭环
|
||||
3. 完成首批种子用户测试与关键使用数据沉淀
|
||||
4. 完成核心知识产权申请 / 获取
|
||||
5. 完成下一轮融资所需的数据验证、客户验证或平台验证
|
||||
|
||||
#### 是否接受“拨改投”
|
||||
|
||||
建议先与公司决策层确认再填。
|
||||
|
||||
如果当前阶段确实需要政府快投和后续基金跟投支持，通常建议倾向：
|
||||
|
||||
- `是`
|
||||
|
||||
但这属于有实际融资后果的选择，必须由公司确认。
|
||||
|
||||
### 3.7 七、财务预测与要素需求
|
||||
|
||||
需要形成 `2026-2028` 三年预测：
|
||||
|
||||
- 营业收入
|
||||
- 净利润
|
||||
- 研发投入
|
||||
- 团队规模
|
||||
- 累计知识产权数量
|
||||
|
||||
建议同步准备：
|
||||
|
||||
- 增长驱动因素
|
||||
- 风险与应对
|
||||
- 希望获得的非资金支持
|
||||
|
||||
## 4. 商业计划书建议结构
|
||||
|
||||
附件 21-3 已给出 8 个章节，建议直接写成 15-18 页 BP：
|
||||
|
||||
1. 封面
|
||||
2. 一句话定义项目
|
||||
3. 行业痛点与机会
|
||||
4. 产品形态与演示截图
|
||||
5. 核心技术与架构
|
||||
6. 差异化与壁垒
|
||||
7. 当前进展与验证情况
|
||||
8. 商业化路径
|
||||
9. 市场空间
|
||||
10. 团队介绍
|
||||
11. 融资历史与当前结构
|
||||
12. 本轮融资需求与用途
|
||||
13. 未来 12-18 个月里程碑
|
||||
14. 三年财务预测
|
||||
15. 政府支持与生态协同需求
|
||||
|
||||
## 5. BP 各章节可直接复用的项目内容
|
||||
|
||||
### 5.1 公司 / 团队基本情况
|
||||
|
||||
可复用来源：
|
||||
|
||||
- `README.md`
|
||||
- `docs/technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md`
|
||||
- `docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md`
|
||||
|
||||
### 5.2 技术研发情况
|
||||
|
||||
重点引用：
|
||||
|
||||
- `docs/prd/AI_NATIVE_CROSS_GENRE_STORY_ENGINE_PRD_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_CLASSIC_RPG_EXPERIENCE_BENCHMARK_PRD_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_NARRATIVE_THREAD_ITEM_AND_WORLD_NPC_PRD_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_STORY_ENGINE_PHASE1_IMPLEMENTATION_PLAN_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_STORY_ENGINE_PHASE2_IMPLEMENTATION_PLAN_2026-04-06.md`
|
||||
|
||||
### 5.3 产品 / 服务
|
||||
|
||||
可突出以下模块：
|
||||
|
||||
1. AI 原生剧情引擎
|
||||
2. 自定义世界生成
|
||||
3. 角色关系与对话系统
|
||||
4. 任务生成与推进
|
||||
5. 运行时智能交互
|
||||
6. 编辑器与内容工作台
|
||||
|
||||
### 5.4 行业及市场
|
||||
|
||||
虽然仓库里没有市场数据，但可以先定义分析框架：
|
||||
|
||||
1. 游戏与互动内容的 AI 生产工具市场
|
||||
2. 互动叙事软件市场
|
||||
3. 数字文化和沉浸式内容市场
|
||||
4. 可扩展到教育、文旅、IP 互动内容的潜在空间
|
||||
|
||||
这一部分需要外部市场数据支持，不能只靠仓库文档。
|
||||
|
||||
### 5.5 发展战略与商业规划
|
||||
|
||||
建议路线：
|
||||
|
||||
1. 先做自有标杆产品验证引擎能力
|
||||
2. 再沉淀可复用的剧情引擎与世界生成能力
|
||||
3. 再探索平台化 / 工具化 / B 端合作 / 内容生态输出
|
||||
|
||||
## 6. 产品 / 技术演示材料建议
|
||||
|
||||
### 6.1 推荐演示结构
|
||||
|
||||
建议控制在 `5-8 分钟`：
|
||||
|
||||
1. 项目定位
|
||||
2. 进入世界或创建自定义世界
|
||||
3. 展示 AI 剧情推进
|
||||
4. 展示 NPC 对话 / 关系 / 任务生成
|
||||
5. 展示运行时状态与本地规则约束
|
||||
6. 展示编辑器或后台架构，证明不是单点 Demo
|
||||
|
||||
### 6.2 建议准备的演示附件
|
||||
|
||||
- 1 个主演示视频
|
||||
- 1 份产品截图包
|
||||
- 1 页系统架构图
|
||||
- 1 页技术路线图
|
||||
- 1 页未来里程碑图
|
||||
|
||||
## 7. 当前项目的材料缺口
|
||||
|
||||
| 类别 | 当前状态 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 企业基本信息 | `待补` | 需公司或团队真实资料 |
|
||||
| 财务数据 | `待补` | 报名表和 BP 都需要 |
|
||||
| 股权结构与融资历史 | `待补` | 仓库无此信息 |
|
||||
| 市场验证与客户信息 | `待补` | 需真实商业化数据 |
|
||||
| 知识产权 | `待核验` | 建议同步整理软著 / 专利 |
|
||||
| Demo 材料 | `可快速形成` | 项目演示性较强 |
|
||||
| 技术路线与产品逻辑 | `优势明显` | 仓库文档充足，可直接转写 |
|
||||
|
||||
## 8. 推荐的实际推进动作
|
||||
|
||||
1. 先把报名表做成一版可填写底稿。
|
||||
2. 同时做一版 `15 页` 左右的 BP 目录和每页一句话。
|
||||
3. 与创始团队确认：
|
||||
- 轮次
|
||||
- 估值
|
||||
- 拟融资金额
|
||||
- 资金用途
|
||||
- 是否接受拨改投
|
||||
4. 录制第一版产品演示视频。
|
||||
5. 把未来 12-18 个月里程碑先量化成数字。
|
||||
@@ -0,0 +1,184 @@
|
||||
# 方向 24 北京市中小企业服务券材料整理（2026-04-14）
|
||||
|
||||
## 1. 先说判断
|
||||
|
||||
方向 24 不能直接按“和 13、21 一样的项目申报”理解。
|
||||
|
||||
它至少有两条完全不同的路径：
|
||||
|
||||
1. `路径 A：服务机构申报配券产品`
|
||||
2. `路径 B：中小微企业领券用券`
|
||||
|
||||
对当前项目来说，必须先明确你想走哪条路径。
|
||||
|
||||
## 2. 当前项目与方向 24 的适配结论
|
||||
|
||||
### 2.1 如果你想走“服务机构申报配券产品”
|
||||
|
||||
当前项目不建议直接以现有形态冲这一路径，原因如下：
|
||||
|
||||
1. 当前项目核心是 `AI 原生视觉 RPG / 互动叙事产品`，不是天然面向北京市中小微企业销售的标准化企业服务产品。
|
||||
2. 附件 24 要求服务机构上年度与北京市中小企业签约合同不少于 `15 份`，营业收入不低于 `800 万元`。
|
||||
3. 还要求产品有明确服务内容、收费标准、知识产权、销售体系和售后服务。
|
||||
4. 当前批次配券产品征集时间截至 `2026 年 3 月 9 日`，本轮窗口已经结束。
|
||||
|
||||
结论：
|
||||
|
||||
- `不建议把当前轮 24 作为主申报方向。`
|
||||
|
||||
### 2.2 如果你想走“企业领券用券”
|
||||
|
||||
这条路径是可行的，但它不是重材料申报，而是：
|
||||
|
||||
1. 企业身份认证
|
||||
2. 查找上线服务产品
|
||||
3. 下单领券
|
||||
4. 线下签约
|
||||
5. 服务交付与留痕
|
||||
|
||||
这条路径更适合作为：
|
||||
|
||||
- 为 `方向 13` 配套采购第三方大模型、数据治理、智能研发工具、数智转型服务时的降本手段
|
||||
|
||||
## 3. 路径 A：服务机构申报配券产品
|
||||
|
||||
## 3.1 官方硬门槛
|
||||
|
||||
服务机构需满足：
|
||||
|
||||
1. 依法注册，有固定经营场所，成立 `1 年（含）以上`
|
||||
2. 拥有开展专业服务所需设备、许可、认证、资质、资格
|
||||
3. 近 `3 年` 经营、环保、纳税、诚信等方面无严重失信记录
|
||||
4. 上年度与北京市中小企业签订合同量不少于 `15 份`
|
||||
5. 营业收入不低于 `800 万元`
|
||||
6. 产品具有完整知识产权、销售体系及售后服务
|
||||
7. 产品需有明确服务内容和收费标准
|
||||
|
||||
## 3.2 申报材料清单
|
||||
|
||||
### 3.2.1 服务机构申请材料
|
||||
|
||||
1. 服务机构详细介绍（不少于 `2000` 字）
|
||||
2. 营业执照
|
||||
3. 运营所在地证明文件
|
||||
4. `2025` 年度财务审计报告 / 专审报告 / 财务报表
|
||||
5. 至少 `15` 份北京市中小企业合同扫描件或等效证明
|
||||
6. 申请方向相关专业资质证明
|
||||
7. 其他优势特色证明材料
|
||||
|
||||
### 3.2.2 配券服务产品申请材料
|
||||
|
||||
每个产品单独成一个文件夹，需提交：
|
||||
|
||||
1. 配券产品申请表
|
||||
2. 产品价格证明
|
||||
- 报价明细表
|
||||
- 近 `12` 个月 `5 套` 合同 + 发票 + 转账凭证
|
||||
3. 知识产权或销售 / 售后体系证明
|
||||
4. 近两年服务北京地区专精特新、小巨人、上市高成长企业名单（如无可不提供）
|
||||
|
||||
## 3.3 当前项目如果一定要做 24，需要怎么改口径
|
||||
|
||||
如果未来还想走路径 A，建议不要再以“游戏项目”名义申报，而是重构成面向中小企业的标准化服务产品，例如：
|
||||
|
||||
1. `AIGC 互动内容生成与叙事工作台`
|
||||
2. `AI 角色对话与剧情内容生产系统`
|
||||
3. `中小内容团队智能叙事创作平台`
|
||||
|
||||
更适合申报的类别：
|
||||
|
||||
- `方向 1 大模型应用`
|
||||
- 或 `方向 2 数智转型系统`
|
||||
|
||||
但即便如此，仍需补齐：
|
||||
|
||||
1. 北京地区 `15` 份中小企业合同
|
||||
2. `800 万元` 营收
|
||||
3. 标准化产品定价体系
|
||||
4. 售后和交付体系
|
||||
5. 如果按大模型产品报，还需网信办备案信息
|
||||
|
||||
## 3.4 当前路径 A 的建议结论
|
||||
|
||||
建议标记为：
|
||||
|
||||
- `本轮不主攻`
|
||||
- `仅保留备查清单`
|
||||
|
||||
## 4. 路径 B：企业领券用券
|
||||
|
||||
## 4.1 这条路径需要做什么
|
||||
|
||||
1. 在北京市统一身份认证平台完成企业认证
|
||||
2. 登录北京通企服版 APP
|
||||
3. 在服务券专区查找适合的产品
|
||||
4. 领券并下单
|
||||
5. 与服务机构线下签约
|
||||
6. 履约、付款并保留全套材料
|
||||
|
||||
## 4.2 对当前项目最有价值的用券方向
|
||||
|
||||
如果你们作为企业用券，最值得关注的通常是：
|
||||
|
||||
1. `大模型应用`
|
||||
- 模型部署
|
||||
- 模型调用
|
||||
- 大模型精调
|
||||
- 数据治理
|
||||
|
||||
2. `数智转型系统`
|
||||
- 智能研发工具
|
||||
- AI 辅助编程系统
|
||||
- 研发设计 / 经营管理 / 软件系统集成服务
|
||||
|
||||
## 4.3 用券侧建议留存的材料
|
||||
|
||||
虽然企业侧不一定需要像服务机构一样重申报，但仍建议留痕：
|
||||
|
||||
1. 企业认证截图
|
||||
2. 下单截图
|
||||
3. 订单编号与下单时间
|
||||
4. 服务合同
|
||||
5. 发票
|
||||
6. 付款凭证
|
||||
7. 服务交付说明
|
||||
8. 服务完成确认截图
|
||||
|
||||
这些材料后续也可能反过来支持 `方向 13` 的投资和智能化建设证明。
|
||||
|
||||
## 5. 当前项目的实际建议
|
||||
|
||||
### 5.1 不建议做的事
|
||||
|
||||
1. 不建议把当前 AI 游戏项目直接包装成 24 配券产品就立刻申报。
|
||||
2. 不建议在本轮窗口已过的情况下继续花大量时间准备服务机构征集材料。
|
||||
|
||||
### 5.2 建议做的事
|
||||
|
||||
1. 如果你们是 `用券企业`，优先研究可采购的 AI 服务产品。
|
||||
2. 如果你们未来想做 `配券服务机构`，把这份文档当成下一轮准备清单。
|
||||
3. 现阶段把主要精力放在 `方向 13` 和 `方向 21`。
|
||||
|
||||
## 6. 备查清单
|
||||
|
||||
### 6.1 路径 A：未来如要做服务机构征集
|
||||
|
||||
- 服务机构介绍
|
||||
- 营业执照
|
||||
- 场地证明
|
||||
- 审计报告 / 财务报表
|
||||
- `15` 份北京中小企业合同
|
||||
- 资质证明
|
||||
- 产品报价体系
|
||||
- `5` 套合同 + 发票 + 转账凭证
|
||||
- 知识产权 / 销售 / 售后体系
|
||||
- 高成长客户清单
|
||||
|
||||
### 6.2 路径 B：当前如要用券
|
||||
|
||||
- 企业认证
|
||||
- 下单记录
|
||||
- 合同
|
||||
- 发票
|
||||
- 付款记录
|
||||
- 服务交付留痕
|
||||
@@ -0,0 +1,233 @@
|
||||
# 北京市方向 13 / 21 / 24 申报总览（2026-04-14）
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
这份文档用于把当前项目与以下 3 个方向的申报要求对齐，并给出统一的材料准备框架：
|
||||
|
||||
- 方向 `13`：软件智能化提升奖励
|
||||
- 方向 `21`：“创赢未来”成长计划
|
||||
- 方向 `24`：北京市中小企业服务券
|
||||
|
||||
本文档基于以下官方附件整理：
|
||||
|
||||
- `C:\Users\windows\Downloads\W020260225601546780336.docx`
|
||||
- `C:\Users\windows\Downloads\W020260225601548312243.doc`
|
||||
- `C:\Users\windows\Downloads\W020260225601549271520.docx`
|
||||
|
||||
## 2. 先说结论
|
||||
|
||||
### 2.1 当前项目与三个方向的匹配判断
|
||||
|
||||
1. `方向 13` 是当前最值得主攻的申报方向。
|
||||
- 当前项目本质上是“AI 原生剧情引擎 + 本地规则裁决 + 游戏软件产品”的智能化软件项目，且附件 13 明确包含 `游戏软件`。
|
||||
- 但这一方向材料最重、硬门槛最多，必须优先核验 `总投资 >= 500 万元`、`项目已竣工投运`、`知识产权数量`、`国产模型接入`、`Token 量`、`5 个客户案例或 5 万 DAU`、`智能化成熟度测评` 等要求。
|
||||
|
||||
2. `方向 21` 与当前项目方向高度匹配，建议并行准备。
|
||||
- 当前项目适合归入 `未来信息 -> 通用人工智能`，`元宇宙` 可作为备选描述维度，不建议作为首选。
|
||||
- 这一方向更看重技术潜力、团队能力、融资规划和未来产业前景，比较适合当前这种“技术路线清晰、产品原型已成型、后续仍处于快速演化阶段”的项目。
|
||||
- 附件 21 明确写明 `2026 年 6 月` 路演对应申报截止时间为 `2026 年 5 月 15 日`。
|
||||
|
||||
3. `方向 24` 需要先区分申报身份，再决定是否投入材料准备。
|
||||
- 如果你想申报的是 `服务机构配券产品征集`，那当前项目并不天然匹配，因为现有仓库核心是 AI 游戏产品，不是面向北京市中小微企业销售的标准化企业服务产品。
|
||||
- 如果你想用的是 `中小企业服务券`，那不是一套重申报材料，而是企业认证、下单、签约、付款、留痕流程。
|
||||
- 附件 24 写明本轮 `配券产品征集` 截止至 `2026 年 3 月 9 日`，按当前日期 `2026 年 4 月 14 日`，这一轮服务机构征集窗口已经结束。
|
||||
|
||||
### 2.2 建议的投入顺序
|
||||
|
||||
1. 先完成 `方向 13` 的硬条件核验和主材料框架。
|
||||
2. 并行完成 `方向 21` 的报名表底稿、BP 结构和演示材料提纲。
|
||||
3. 对 `方向 24` 只做判断和备查，不建议当前把主要时间投入到“配券产品征集”上。
|
||||
|
||||
## 3. 当前项目可复用的共用事实
|
||||
|
||||
以下内容可以作为 `13` 和 `21` 的共用项目底稿基础：
|
||||
|
||||
### 3.1 项目定位
|
||||
|
||||
- 项目名称：`AI Native Visual RPG`
|
||||
- 核心定位：以 `AI 叙事 + 本地规则 + 像素演出` 为核心的 AI 原生视觉 RPG 原型
|
||||
- 产品形态：前端表现层 + `Express` 后端 + `PostgreSQL` 持久化 + AI 接口编排
|
||||
- 核心能力：
|
||||
- 世界与角色选择
|
||||
- AI 剧情推进与流式对话
|
||||
- 战斗演出、NPC 战斗、切磋
|
||||
- NPC 交易、送礼、求助、招募
|
||||
- 宝藏交互
|
||||
- 同伴跟随与战斗
|
||||
- 预设编辑器 / NPC 视觉编辑器 / 行为编辑器
|
||||
- 自动存档与继续游戏
|
||||
|
||||
### 3.2 技术架构
|
||||
|
||||
- 前端：`React 19` + `TypeScript` + `Vite`
|
||||
- 后端：`Express` + `TypeScript`
|
||||
- 数据层：`PostgreSQL`
|
||||
- AI 能力接入：
|
||||
- 流式剧情生成
|
||||
- 自定义世界多阶段生成
|
||||
- NPC 对话 / 招募 /关系总结
|
||||
- 任务生成
|
||||
- 角色视觉与动画资产生成接口
|
||||
- 工程门禁：
|
||||
- `npm run lint`
|
||||
- `npm run check:encoding`
|
||||
- `npm run check:content`
|
||||
- `npm run build`
|
||||
- `vitest`
|
||||
|
||||
### 3.3 当前可支撑的创新点
|
||||
|
||||
1. `AI 负责叙事表达，本地规则负责状态裁决`
|
||||
- 把剧情生成与关键规则分离，降低纯模型驱动的不稳定性。
|
||||
|
||||
2. `AI 原生剧情引擎`
|
||||
- 当前文档已经形成 `themePack -> storyGraph -> narrativeProfile -> knowledgeFacts / threadContracts` 的结构化设计。
|
||||
|
||||
3. `跨题材自定义世界生成`
|
||||
- 支持从世界锚点出发生成世界框架、角色、地点、叙事图谱与运行时编译结构。
|
||||
|
||||
4. `游戏软件的智能化改造方向明确`
|
||||
- 不是简单在游戏里接聊天，而是围绕剧情推进、任务、角色关系、物品叙事、世界生成做系统级 AI 注入。
|
||||
|
||||
5. `前后端职责边界清晰`
|
||||
- 遵循“前端只做表现，逻辑和数据放后端”的工程约束，便于形成可持续演进的软件产品能力。
|
||||
|
||||
## 4. 仓库内建议重点引用的项目依据
|
||||
|
||||
- `README.md`
|
||||
- `docs/prd/AI_NATIVE_CROSS_GENRE_STORY_ENGINE_PRD_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_CLASSIC_RPG_EXPERIENCE_BENCHMARK_PRD_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_NARRATIVE_THREAD_ITEM_AND_WORLD_NPC_PRD_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_CUSTOM_WORLD_CREATION_FLOW_OPTIMIZATION_PRD_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_STORY_ENGINE_PHASE1_IMPLEMENTATION_PLAN_2026-04-06.md`
|
||||
- `docs/prd/AI_NATIVE_STORY_ENGINE_PHASE2_IMPLEMENTATION_PLAN_2026-04-06.md`
|
||||
- `docs/technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md`
|
||||
- `docs/audits/engineering/README.md`
|
||||
- `docs/experience/PROJECT_DEVELOPMENT_EXPERIENCE.md`
|
||||
|
||||
## 5. 三个方向的共用材料包
|
||||
|
||||
以下材料建议先做成一个统一总包，再按方向拆分：
|
||||
|
||||
### 5.1 企业基础件
|
||||
|
||||
- 营业执照扫描件
|
||||
- 法定代表人信息
|
||||
- 联系人信息
|
||||
- 公司简介
|
||||
- 统一社会信用代码
|
||||
- 注册地址 / 办公地址 / 经营场所证明
|
||||
- 企业近 2 年到 3 年财务数据
|
||||
- 2025 年审计报告 / 专审报告 / 财务报表
|
||||
|
||||
### 5.2 项目基础件
|
||||
|
||||
- 项目命名口径
|
||||
- 项目建设周期
|
||||
- 项目立项文件 / 决策文件
|
||||
- 项目结项 / 版本竣工 / 上线证明
|
||||
- 项目建设地点
|
||||
- 项目实施团队名单
|
||||
- 项目总投资和构成明细
|
||||
|
||||
### 5.3 技术与知识产权件
|
||||
|
||||
- 软件著作权证书
|
||||
- 发明专利证书或申请进展材料
|
||||
- 产品版本说明
|
||||
- 系统架构图
|
||||
- 关键技术说明
|
||||
- 模型接入说明
|
||||
- 技术创新点说明
|
||||
|
||||
### 5.4 市场与应用件
|
||||
|
||||
- 客户合同 / 订单 / 上线验收证明
|
||||
- 用户数据后台截图
|
||||
- 日活 / 调用量 / Token 日志
|
||||
- 合作伙伴名单
|
||||
- 试点案例
|
||||
- 演示视频 / 产品截图
|
||||
|
||||
### 5.5 融资与团队件
|
||||
|
||||
- 核心团队简历
|
||||
- 股权结构
|
||||
- 历史融资情况
|
||||
- 当前估值与资金储备
|
||||
- 未来 12-18 个月资金需求与用途
|
||||
- 未来 3 年财务预测
|
||||
|
||||
## 6. 建议的材料目录结构
|
||||
|
||||
建议在仓库外或公司申报盘中采用以下目录：
|
||||
|
||||
```text
|
||||
申报材料/
|
||||
├─ 00_共用基础材料/
|
||||
│ ├─ 00_营业执照与资质/
|
||||
│ ├─ 01_财务与审计/
|
||||
│ ├─ 02_团队与融资/
|
||||
│ ├─ 03_知识产权/
|
||||
│ ├─ 04_项目立项与结项/
|
||||
│ ├─ 05_产品截图与演示/
|
||||
│ └─ 06_客户与应用证明/
|
||||
├─ 13_软件智能化提升奖励/
|
||||
│ ├─ 01_申报表/
|
||||
│ ├─ 02_实施总结报告/
|
||||
│ ├─ 03_绩效与测评/
|
||||
│ ├─ 04_投资明细与专项审计/
|
||||
│ └─ 05_补充证明/
|
||||
├─ 21_创赢未来成长计划/
|
||||
│ ├─ 01_报名表/
|
||||
│ ├─ 02_承诺书/
|
||||
│ ├─ 03_商业计划书/
|
||||
│ ├─ 04_产品技术演示/
|
||||
│ └─ 05_补充证明/
|
||||
└─ 24_中小企业服务券/
|
||||
├─ A_配券产品征集_如后续开放/
|
||||
└─ B_企业用券留痕/
|
||||
```
|
||||
|
||||
## 7. 当前最需要立即核验的硬条件
|
||||
|
||||
### 7.1 方向 13
|
||||
|
||||
- 是否已经形成一个可定义为“已竣工并投入运行”的软件版本
|
||||
- 是否能确认项目建设开始时间和竣工时间，且周期不超过 2 年
|
||||
- 是否有 `2 项软著` 或 `1 项发明专利`
|
||||
- 是否能拿到 `>= 500 万元` 的专项审计口径总投资
|
||||
- 是否能提供 `第三方辅助编码平台` 的代码生成占比 / 采纳率证明
|
||||
- 是否已接入 `已备案的国产主流大模型`
|
||||
- 是否有 `日均 Token >= 500 万`
|
||||
- 是否能拿到 `智能化成熟度测评报告`
|
||||
- 是否能满足 `5 个不同客户案例` 或 `5 万 DAU`
|
||||
|
||||
### 7.2 方向 21
|
||||
|
||||
- 当前申报主体是已注册公司还是创新团队
|
||||
- 是否已有历史融资、估值和股权结构
|
||||
- 是否已有最小商业化验证
|
||||
- 未来 12-18 个月的融资金额和用途是否可量化
|
||||
- 未来 3 年收入、利润、研发投入预测是否能由财务或管理层确认
|
||||
|
||||
### 7.3 方向 24
|
||||
|
||||
- 如果按 `服务机构配券产品征集` 走，是否满足：
|
||||
- 上年度与北京市中小企业签约合同不少于 `15 份`
|
||||
- 营业收入不低于 `800 万元`
|
||||
- 存在标准化、可售卖、可售后、可定价的企业服务产品
|
||||
- 如果不满足，是否转为 `企业用券` 路径，而不是继续准备配券申报材料
|
||||
|
||||
## 8. 推荐的本周推进顺序
|
||||
|
||||
1. 先把 `方向 13` 的硬条件做一次红黄绿核验。
|
||||
2. 同步准备 `方向 21` 的报名表底稿和 BP 第一版。
|
||||
3. 只保留 `方向 24` 的判断文档与备查清单，不建议本周作为主线。
|
||||
4. 所有数字类信息统一建一个 `数据底表`，避免三个方向口径不一致。
|
||||
|
||||
## 9. 关联文档
|
||||
|
||||
- [BEIJING_DIRECTION13_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION13_APPLICATION_MATERIALS_2026-04-14.md)
|
||||
- [BEIJING_DIRECTION21_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION21_APPLICATION_MATERIALS_2026-04-14.md)
|
||||
- [BEIJING_DIRECTION24_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION24_APPLICATION_MATERIALS_2026-04-14.md)
|
||||
@@ -0,0 +1,435 @@
|
||||
# 当前 Agent 创作流程优化执行规划（大白话版）
|
||||
|
||||
更新时间：`2026-04-21`
|
||||
|
||||
## 先把话说死
|
||||
|
||||
这轮不再加新流程。
|
||||
|
||||
不再新增一套创作动线。
|
||||
不再为了“更完整”继续把 PRD 里没落完的所有阶段、面板、动作全补出来。
|
||||
不再把前端创作工具改成另一套长得不一样的新系统。
|
||||
|
||||
这轮只做一件事：
|
||||
|
||||
**把现在这条你已经满意的前端创作流程，收紧、理顺、删重、补通，让它从“能跑”变成“稳、顺、好维护、不会自己打自己”。**
|
||||
|
||||
这份规划就是基于 [AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md](../audits/AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md) 里已经确认的问题，重新收束出来的一版执行方案。
|
||||
|
||||
## 0.1 当前正式执行基线
|
||||
|
||||
从 `2026-04-21` 起，当前仓库里和这条创作主链直接对应的文件级拆分、阶段验收、工作包进度，统一以以下文档为准：
|
||||
|
||||
1. [../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md)
|
||||
2. `docs/technical/CREATION_FLOW_CHAIN_REFACTOR_WORK_PACKAGE_*_PROGRESS_2026-04-21.md`
|
||||
3. [../technical/CURRENT_AGENT_CREATION_FLOW_STAGE4_CLEANUP_CHECK_2026-04-21.md](../technical/CURRENT_AGENT_CREATION_FLOW_STAGE4_CLEANUP_CHECK_2026-04-21.md)
|
||||
|
||||
本文件继续承担的职责只剩 3 件事：
|
||||
|
||||
1. 解释为什么当前版本只收口现有 Agent 创作动线，不再扩一套新流程
|
||||
2. 冻结这轮明确不做的能力边界
|
||||
3. 给出高层执行顺序与判断标准
|
||||
|
||||
凡是涉及目录落位、命名规范、前后端真相源边界、阶段完成度和工作包状态，统一以后面的技术执行文档为准。
|
||||
|
||||
---
|
||||
|
||||
## 1. 现在最大的问题，用大白话讲是什么
|
||||
|
||||
不是界面丑。
|
||||
不是步骤不够多。
|
||||
不是入口不够花。
|
||||
|
||||
而是现在这条链里，很多地方在“一个流程里混着好几套脑子”。
|
||||
|
||||
具体就是：
|
||||
|
||||
1. 用户明明在走 Agent 创作，但走到一半，很多关键数据又偷偷变成了 old profile 流程在接手。
|
||||
2. 明明已经有 Agent session 这条主线，但结果页、作品库、旧生成接口、旧编辑器能力还都在同时干活。
|
||||
3. 明明有“发布世界”这个概念，但现在实际上“不发布也能直接进入世界”。
|
||||
4. 明明有一些 session 内的数据，比如建议动作、草稿卡、澄清项、质量检查，结果走到结果页之后就像断电了一样，后面没人接着用。
|
||||
5. 明明有些功能已经决定这轮不做，但代码里和文档里还留着很多“半做不做”的说法，会持续误导后续开发。
|
||||
|
||||
所以这轮优化的目标不是“让系统更大”，而是：
|
||||
|
||||
**让整条现有流程只认一条主线，别再一会儿 Agent、一会儿 legacy、一会儿旧 session、一会儿作品库各管各的。**
|
||||
|
||||
---
|
||||
|
||||
## 2. 这轮优化后的目标状态
|
||||
|
||||
我们要收敛到下面这个状态：
|
||||
|
||||
```text
|
||||
用户进入 Agent 创作
|
||||
-> 在现有工作区里聊天和生成草稿
|
||||
-> 草稿整理完成后进入现有结果页
|
||||
-> 结果页只做预览、少量必要确认、进入世界
|
||||
-> 进入世界时走一条明确、统一、可解释的数据链
|
||||
-> 平台“我的创作”能稳定找回这份草稿或这份作品
|
||||
```
|
||||
|
||||
注意，这里有两个关键词：
|
||||
|
||||
1. **还是现有动线**
|
||||
2. **但背后的数据链要统一**
|
||||
|
||||
也就是说：
|
||||
|
||||
前端看上去可以几乎不换流程。
|
||||
但后面谁是真相源、谁负责编译、谁负责保存、谁负责恢复、哪些能力要删掉，必须彻底讲清楚。
|
||||
|
||||
---
|
||||
|
||||
## 3. 这轮不做什么
|
||||
|
||||
为了避免后面又做散，先把“不做什么”写清楚。
|
||||
|
||||
### 3.1 不新增新的大流程
|
||||
|
||||
不做这些：
|
||||
|
||||
1. 不再新增“另一个 Agent 创作工作台”
|
||||
2. 不再新增“另一套草稿结果页”
|
||||
3. 不再新增“另一条作品发布流程”
|
||||
4. 不再新增“另一套创作中心入口”
|
||||
|
||||
### 3.2 不为了补 PRD 而硬补所有未完成能力
|
||||
|
||||
不做这些：
|
||||
|
||||
1. 不把所有 `lock / unlock / regenerate_scope / expand_long_tail / scene asset pipeline` 一次性全打完
|
||||
2. 不为了“文档里写过”就把所有没接线面板都接进来
|
||||
3. 不把当前工作区重新改造成一个更复杂的大后台
|
||||
|
||||
补充更新（`2026-04-21`）：
|
||||
|
||||
上一轮审计里提到的一组旧 Agent 副面板，已经在工程清理中被明确判定为退出当前版本主链并物理删除，包括：
|
||||
|
||||
1. `CustomWorldAgentLockBar.tsx`
|
||||
2. `CustomWorldAgentQuickActions.tsx`
|
||||
3. `CustomWorldAgentSummaryPanel.tsx`
|
||||
4. `CustomWorldAgentIntentSummaryPanel.tsx`
|
||||
5. `CustomWorldAgentClarificationPanel.tsx`
|
||||
6. `CustomWorldAgentDraftDetailPanel.tsx`
|
||||
7. `CustomWorldDraftCardDetailModal.tsx`
|
||||
8. `CustomWorldDraftEditPanel.tsx`
|
||||
9. `CustomWorldGenerateEntityModal.tsx`
|
||||
|
||||
所以这里的“不为了文档里写过就全接进来”，现在不只是态度提醒，而是已经执行过的现实边界。
|
||||
|
||||
### 3.3 不把结果页继续当旧编辑器扩写
|
||||
|
||||
这轮明确不再鼓励：
|
||||
|
||||
1. 在结果页继续加更多直接生成角色 / 地点的按钮
|
||||
2. 在结果页继续加更多直接改 legacy profile 的编辑能力
|
||||
3. 让结果页承担越来越重的“补世界”职责
|
||||
|
||||
一句话：
|
||||
|
||||
**结果页要收口，不要继续发散。**
|
||||
|
||||
---
|
||||
|
||||
## 4. 接下来真正要做的 5 件事
|
||||
|
||||
## 4.1 第一件事：先定一条唯一主链，别再多套数据同时接力
|
||||
|
||||
这是第一优先级，也是最重要的一件事。
|
||||
|
||||
现在的问题不是“没东西可用”，而是“能用的东西太多了，而且互相抢活”。
|
||||
|
||||
接下来要明确：
|
||||
|
||||
1. 当前 Agent 创作流程里，`Agent session` 才是草稿阶段的真相源。
|
||||
2. 结果页只是这份草稿的展示和收口，不应该变成另一套独立编辑器。
|
||||
3. 进入世界时，只能走一条明确的编译出口，不能这里转一次、那里改一次、最后谁改得晚听谁的。
|
||||
|
||||
用大白话讲，就是：
|
||||
|
||||
**从聊天开始到点“进入世界”为止，中间只能有一条主水管。**
|
||||
|
||||
不能再出现：
|
||||
|
||||
1. Agent session 里一份数据
|
||||
2. 前端桥接后又一份 profile
|
||||
3. 结果页本地改完又一份 profile
|
||||
4. 自动保存到作品库后再来一份 profile
|
||||
|
||||
这样下去，后面谁出 bug 都说不清到底是哪一层改坏的。
|
||||
|
||||
所以这一阶段的目标不是改 UI，而是先把话语权统一：
|
||||
|
||||
1. 草稿阶段谁说了算
|
||||
2. 进入世界前谁负责最终编译
|
||||
3. 作品库里保存的到底是“正式世界”还是“当前草稿快照”
|
||||
|
||||
这件事不解决，后面所有优化都会继续打架。
|
||||
|
||||
---
|
||||
|
||||
## 4.2 第二件事：把结果页收口，只保留当前流程真正需要的事
|
||||
|
||||
现在结果页的问题很简单：
|
||||
|
||||
它干的活太多了。
|
||||
|
||||
它现在既像：
|
||||
|
||||
1. 草稿预览页
|
||||
2. 旧自定义世界编辑器
|
||||
3. AI 补角色/补地点的入口
|
||||
4. 自动保存中转页
|
||||
5. 进入世界前的最后一跳
|
||||
|
||||
这就是为什么它会越来越乱。
|
||||
|
||||
这轮要做的不是重做结果页，而是收口结果页。
|
||||
|
||||
收口方向很明确：
|
||||
|
||||
1. 结果页继续保留现在你满意的浏览和进入世界体验
|
||||
2. 但要逐步去掉“它自己偷偷改世界结构”的能力
|
||||
3. 让它更像“当前草稿的总览页”，而不是“另一套世界编辑器”
|
||||
|
||||
用大白话讲：
|
||||
|
||||
**结果页负责看，不负责偷偷再造一遍世界。**
|
||||
|
||||
所以这里建议后续逐步处理：
|
||||
|
||||
1. 把结果页里那些直接生成 playable/story/landmark 的旧能力下掉
|
||||
2. 把直接改 legacy profile 的重编辑能力从结果页移走或收紧
|
||||
3. 让“去 Agent 调整设定”真的是回主流程调，而不是结果页自己补完半套流程
|
||||
|
||||
这一步做完的好处很直接：
|
||||
|
||||
1. 结果页职责会清楚很多
|
||||
2. 进入世界前的状态会更稳定
|
||||
3. 不会再出现“用户以为还在 Agent 流里，实际上已经走到 legacy 编辑器里了”
|
||||
|
||||
---
|
||||
|
||||
## 4.3 第三件事：平台入口统一，不让草稿恢复和作品查看继续割裂
|
||||
|
||||
现在还有一个体验问题不是流程长短的问题，而是入口不统一。
|
||||
|
||||
简单说就是：
|
||||
|
||||
1. 后端已经能区分“草稿”和“已发布作品”
|
||||
2. 但平台页里“我的创作”主要还在看 `myEntries`
|
||||
3. Agent 草稿并不能自然地稳定出现在同一个主入口里
|
||||
|
||||
这会带来两个问题：
|
||||
|
||||
1. 用户做了一半的草稿，不容易稳定找回来
|
||||
2. 系统里其实已经有创作中心能力，但主入口没认它
|
||||
|
||||
所以接下来要做的不是新做一个创作中心，而是：
|
||||
|
||||
**把已经存在的聚合能力真正接回现在的平台入口。**
|
||||
|
||||
用户看到的应该是：
|
||||
|
||||
1. 还没进世界的草稿，可以继续创作
|
||||
2. 已经成型的作品，可以查看或进入世界
|
||||
|
||||
而不是：
|
||||
|
||||
1. 草稿在一套地方
|
||||
2. 已保存作品在另一套地方
|
||||
3. 恢复创作还得靠 sessionId 或隐藏状态兜底
|
||||
|
||||
这一步的核心价值不是“新功能”，而是“东西别丢、入口别分裂、用户心智别断”。
|
||||
|
||||
---
|
||||
|
||||
## 4.4 第四件事：删掉重复 pipeline，不再同时养两三套创作生成链
|
||||
|
||||
这一步很关键，而且一定要明确态度：
|
||||
|
||||
**既然你已经决定当前前端创作流程满意，那就不能继续默认保留那么多并行旧链。**
|
||||
|
||||
现在最典型的重复链有：
|
||||
|
||||
1. Agent 创作链
|
||||
2. 旧 `custom-world/sessions` 世界生成链
|
||||
3. 结果页 legacy profile 直改链
|
||||
|
||||
它们的共同问题是：
|
||||
|
||||
1. 都能生成世界
|
||||
2. 都能改世界
|
||||
3. 但不是同一套状态模型
|
||||
4. 后期维护会越来越痛苦
|
||||
|
||||
所以这一步不是说要立刻把所有旧东西物理删除，而是要明确分层：
|
||||
|
||||
1. 哪条是当前正式主链
|
||||
2. 哪条是兼容链
|
||||
3. 哪条只是暂时留着，但不能再往上继续加功能
|
||||
|
||||
用大白话讲，就是：
|
||||
|
||||
**该扶正的扶正，该降级的降级，该冻结的冻结。**
|
||||
|
||||
尤其是旧 `custom-world/sessions` 这条链，如果还要保留，也只能是兼容入口，不能再和 Agent 主链平起平坐。
|
||||
|
||||
补充更新（`2026-04-21`）：
|
||||
|
||||
这条旧 `custom-world/sessions` 世界生成链已经完成物理删除。
|
||||
|
||||
因此阶段三在当前仓库里的剩余任务，不再是“决定要不要保留这条旧链”，而是：
|
||||
|
||||
1. 继续收掉结果页 legacy profile 直改能力的误导性职责
|
||||
2. 继续清理文档里把旧链当成现行选项的表述
|
||||
|
||||
---
|
||||
|
||||
## 4.5 第五件事：把文稿里那些“这轮不做”的未完成项从主叙事里移掉
|
||||
|
||||
这是你这次特别强调的点，我完全同意，而且它很重要。
|
||||
|
||||
现在很多文稿的问题不是“写错了”，而是：
|
||||
|
||||
1. 写了很多理论上该有的能力
|
||||
2. 但当前版本并不准备继续往那个方向扩
|
||||
3. 结果文档会不断把团队拉回“是不是还要把这些补完”的思路里
|
||||
|
||||
这会直接制造两种问题：
|
||||
|
||||
1. 开发判断会飘
|
||||
2. 后续审计会永远得到“未完成项很多”的结论
|
||||
|
||||
所以这轮文档治理要做的，不是把文稿全删空，而是分清三类内容：
|
||||
|
||||
1. **当前版本要继续优化的**
|
||||
2. **当前版本明确不做、先冻结的**
|
||||
3. **未来可以再看，但这轮不纳入执行规划的**
|
||||
|
||||
用大白话讲：
|
||||
|
||||
**文档也要学会闭嘴。**
|
||||
|
||||
不是所有想过的东西，都要继续挂在当前版本的主任务里。
|
||||
|
||||
---
|
||||
|
||||
## 5. 推荐执行顺序
|
||||
|
||||
这轮建议按下面顺序推进，不建议乱穿插。
|
||||
|
||||
## 第一阶段：先收主链
|
||||
|
||||
先做：
|
||||
|
||||
1. 定义当前正式主链
|
||||
2. 明确 Agent session、结果页、作品库、进入世界之间谁负责什么
|
||||
3. 停止继续增强结果页里的 legacy 编辑能力
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**先让水管只有一根。**
|
||||
|
||||
## 第二阶段：再收结果页和平台入口
|
||||
|
||||
再做：
|
||||
|
||||
1. 结果页职责收口
|
||||
2. 平台“我的创作”入口统一
|
||||
3. 草稿恢复和作品查看走同一套入口认知
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**让用户走起来更顺，让系统找回内容更稳定。**
|
||||
|
||||
## 第三阶段：清理旧链残留表述与剩余兼容误导
|
||||
|
||||
再做：
|
||||
|
||||
1. 清理旧 `custom-world/sessions` 已删除链路在文档、索引、任务清单里的残留表述
|
||||
2. 结果页直改 profile 的旧能力继续收紧
|
||||
3. 把仍保留的兼容 façade / 兼容字段边界写清楚
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**减少旧链文档误导和兼容边界漂移。**
|
||||
|
||||
## 第四阶段：最后做文档清理
|
||||
|
||||
最后做：
|
||||
|
||||
1. 把当前版本不再追的未完成项，从主规划文稿里移出去
|
||||
2. 把“未来也许做”从“这轮要做”里拆开
|
||||
3. 让所有当前规划只服务当前版本
|
||||
|
||||
就当前状态补一句最重要的执行口径：
|
||||
|
||||
1. 已经物理删除的旧链和旧副面板，不再作为“本轮待落地项”
|
||||
2. 历史 PRD 可以保留实现设想，但必须和“当前版本执行规划”分开
|
||||
3. 当前版本规划只保留仍对正式主链有现实约束的事项
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**让接下来所有开发都围绕同一套现实目标执行。**
|
||||
|
||||
---
|
||||
|
||||
## 6. 每个阶段做完以后，应该看到什么效果
|
||||
|
||||
## 阶段一做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 代码里谁是主链一眼能看明白
|
||||
2. 不会再出现一会儿 Agent、一会儿 legacy profile 接管全局的情况
|
||||
3. 进入世界时的数据来源更清楚
|
||||
|
||||
## 阶段二做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 结果页更干净
|
||||
2. 平台页更容易找回自己的创作
|
||||
3. 用户对“草稿”“作品”“进入世界”这三个概念不会混
|
||||
|
||||
## 阶段三做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 已删除旧链不再继续出现在当前执行清单里
|
||||
2. 剩余兼容层的保留边界更清楚
|
||||
3. 后续开发不会再不知道该往哪条链上接
|
||||
|
||||
## 阶段四做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 文档和代码目标一致
|
||||
2. 团队不会再被一堆“理论上应该补”的项拉偏
|
||||
3. 后续迭代能真正围绕“优化已有流程”推进
|
||||
|
||||
---
|
||||
|
||||
## 7. 这轮最重要的判断标准
|
||||
|
||||
这轮不是看我们补了多少功能。
|
||||
|
||||
这轮的判断标准应该是下面 5 条：
|
||||
|
||||
1. 用户现在这条创作流程有没有被打断
|
||||
2. 同一个世界的数据是不是只走一条清楚的主链
|
||||
3. 结果页是不是还在偷偷承担旧编辑器职责
|
||||
4. 平台入口能不能稳定找回草稿和作品
|
||||
5. 文档是不是已经不再推动大家去补这轮明确不做的东西
|
||||
|
||||
如果这 5 条做好了，就说明这轮方向是对的。
|
||||
|
||||
---
|
||||
|
||||
## 8. 一句话总结
|
||||
|
||||
接下来的优化，不是再发明一套更复杂的创作流程，而是把当前你已经满意的这条前端动线背后的数据链、入口、职责和文档全部收紧到同一个方向上：
|
||||
|
||||
**少一点并行、少一点桥接、少一点重复、少一点“半做半留”，把现有流程真正打磨成一条稳定主链。**
|
||||
@@ -0,0 +1,608 @@
|
||||
# 世界 Profile 映射优化方案（2026-04-18）
|
||||
|
||||
更新时间：`2026-04-18`
|
||||
|
||||
## 0. 文档目标
|
||||
|
||||
这份文档基于以下结论继续推进：
|
||||
|
||||
- `docs/audits/CUSTOM_WORLD_PROFILE_MAPPING_AUDIT_2026-04-18.md` 已确认，当前世界 `profile` 已打通主干映射，但还没有成为“所有预设内容与实时生成规则共同优先读取的单一真相源”。
|
||||
- 当前最主要的缺口不是“没有世界设定”，而是“世界设定没有被所有运行时链路以同等强度消费”。
|
||||
- 优化重点应优先放在后端运行时消费链、跨题材兼容链、世界级内容对象化三条主线上，而不是继续堆新预设内容。
|
||||
|
||||
本文目标不是重复审计结论，而是把问题整理成：
|
||||
|
||||
1. 分优先级的落地改造项
|
||||
2. 每一项的目标状态
|
||||
3. 需要修改的关键模块
|
||||
4. 具体实施步骤
|
||||
5. 验收标准
|
||||
6. 风险与回滚策略
|
||||
|
||||
---
|
||||
|
||||
## 1. 目标状态
|
||||
|
||||
本轮优化完成后，系统应达到以下状态：
|
||||
|
||||
1. `CustomWorldProfile` 成为预设内容和实时生成规则的统一主数据源。
|
||||
2. 前端剧情链、后端任务链、后端物品链消费的是同一套世界语义，而不是“前端懂世界、后端只懂摘要”。
|
||||
3. `templateWorldType` 只承担兼容字段职责，不再主导跨题材世界的角色、场景、怪物和视觉映射。
|
||||
4. `items / factions / conflicts / threads` 不再只是文本种子，而是能驱动运行时行为的结构对象。
|
||||
5. landmark、场景、怪物、掉落、任务、奖励之间的对应关系优先由世界 profile 决定，模板补位只在缺口场景下触发。
|
||||
|
||||
---
|
||||
|
||||
## 2. 优先级总览
|
||||
|
||||
## P0：先补“真实消费不完整”的运行时主链
|
||||
|
||||
- 让后端 `runtimeItemModule` / `runtimeQuestModule` 接入完整可控的世界 profile 子集。
|
||||
- 去掉后端运行时里“伪线程 id 冒充真实线程”的弱映射。
|
||||
- 建立后端世界消费 contract，统一前后端字段裁剪方式。
|
||||
|
||||
## P1：再补“世界设定被模板压扁”的兼容链与物品链
|
||||
|
||||
- 把 `templateWorldType` 退回兼容层，不再主导真实映射。
|
||||
- 为世界级 `items` 建立 seed 与引用链，补齐“世界物件图谱”。
|
||||
- 让任务奖励、场景宝藏、运行时物品生成优先读取世界物品种子。
|
||||
|
||||
## P2：把文本种子升级为游戏对象
|
||||
|
||||
- 把 `majorFactions / coreConflicts` 升级成可索引、可关联、可推进的结构对象。
|
||||
- 调整 landmark 场景怪物注入逻辑，停止“模板怪物硬补丁”主导场景内容。
|
||||
- 让世界冲突、势力归属真正影响任务、场景压力、敌对关系。
|
||||
|
||||
## P3：补齐长尾映射与创作层沉淀
|
||||
|
||||
- 扩展 `referenceProfile.roleArchetypes` 的来源覆盖，补上 `storyNpcs` 长尾 archetype。
|
||||
- 重新定义 `creatorIntent / anchorPack / lockState / anchorContent` 中哪些字段需要进入运行时。
|
||||
- 为后续第四阶段的世界编辑器、运行时回写和世界演化能力预留稳定接口。
|
||||
|
||||
---
|
||||
|
||||
## 3. 设计原则
|
||||
|
||||
1. 前端只做表现与编排，世界规则解释、任务生成、物品生成、状态持久化都在 Express 后端完成。
|
||||
2. 优先改造现有链路与现有类型，不新造平行系统。
|
||||
3. 兼容字段只做 fallback，不反向主导真实世界内容。
|
||||
4. 所有新增结构都必须能同时服务“预设内容生成”和“运行时规则生成”，避免再次分叉。
|
||||
5. 每一个优化项都必须带测试入口、验收口径和回滚开关。
|
||||
|
||||
---
|
||||
|
||||
## 4. P0 优化方案：补齐后端真实世界消费链
|
||||
|
||||
## P0-1：建立统一的运行时世界消费 Contract
|
||||
|
||||
### 问题定义
|
||||
|
||||
当前前端剧情主链可以拿到较完整的 `customWorldProfile`，但后端任务与物品模块只消费 `{ name, summary }` 这类瘦身字段，导致同一个世界在不同链路里语义强度不一致。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- 后端所有运行时生成模块统一读取 `RuntimeWorldContext`。
|
||||
- `RuntimeWorldContext` 来源于 `CustomWorldProfile` 的受控裁剪，而不是各模块各自手写轻量字段。
|
||||
- 前后端消费世界信息时，共享同一套字段分层。
|
||||
|
||||
### 关键文件
|
||||
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\ai\customWorldOrchestrator.ts`
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\runtime-item\runtimeItemModule.ts`
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\quest\runtimeQuestModule.ts`
|
||||
- `E:\Repos\Genarrative\src\types\customWorld.ts`
|
||||
- `E:\Repos\Genarrative\src\hooks\story\storyContextBuilder.ts`
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 在后端新增统一的 `RuntimeWorldContext` 类型与构建函数。
|
||||
2. 首批纳入字段：
|
||||
- `name`
|
||||
- `summary`
|
||||
- `themePack`
|
||||
- `storyGraph`
|
||||
- `knowledgeFacts`
|
||||
- `threadContracts`
|
||||
- `majorFactions`
|
||||
- `coreConflicts`
|
||||
- `ownedSettingLayers.ruleProfile`
|
||||
- `referenceProfile`
|
||||
3. 在 orchestrator 层完成一次裁剪与归一化，禁止 `runtimeItemModule`、`runtimeQuestModule` 自己拼 world summary。
|
||||
4. 为后端 prompt 构造器增加“世界上下文来源检查”，缺字段时直接走 fallback 分支并记录日志。
|
||||
5. 将前端剧情链现有世界裁剪逻辑与后端世界裁剪逻辑对齐，避免出现同字段两套解释。
|
||||
|
||||
### 前后端职责
|
||||
|
||||
- 前端：只传递当前线程、当前场景、当前 encounter、当前角色状态等调用上下文。
|
||||
- 后端：解释世界 profile、构造任务 prompt、构造物品 prompt、产出最终结构化结果。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 后端任务和物品生成日志中可看到相同世界的 `themePack / activeThreads / ruleProfile` 已进入 prompt 上下文。
|
||||
- 同一世界下，前端剧情 prompt 与后端任务/物品 prompt 的核心势力、冲突、世界基调不再明显割裂。
|
||||
- 缺失字段时有稳定 fallback，不会因为世界 profile 某块为空直接报错。
|
||||
|
||||
### 风险与回滚
|
||||
|
||||
- 风险：一次性带入字段过多，可能导致 prompt 膨胀。
|
||||
- 回滚策略：保留 `RuntimeWorldContextLite` 开关，出现 token 或稳定性问题时，可按模块退回精简字段集。
|
||||
|
||||
---
|
||||
|
||||
## P0-2：让后端 active threads 读取真实故事线程
|
||||
|
||||
### 问题定义
|
||||
|
||||
当前后端运行时物品模块里的 `activeThreadIds` 只是 `thread:${encounter.id}` 或 `thread:${scene.id}` 这类伪 id，不是真正来自 `storyGraph` 的线程对象。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- 后端运行时统一读取真实 `storyGraph` 线程。
|
||||
- 若当前 scene / encounter 未命中真实线程，再进入显式 fallback。
|
||||
- 运行时物品、任务奖励、事件物件都能解释“为什么此刻出现”。
|
||||
|
||||
### 关键文件
|
||||
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\runtime-item\runtimeItemModule.ts`
|
||||
- `E:\Repos\Genarrative\src\services\storyEngine\worldStoryGraph.ts`
|
||||
- `E:\Repos\Genarrative\src\services\storyEngine\threadContract.ts`
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 在后端新增 `resolveActiveWorldThreads(...)`，输入 scene、encounter、knowledge facts、runtime memory。
|
||||
2. 线程命中优先顺序：
|
||||
- 当前 scene 关联线程
|
||||
- 当前 encounter / npc 关联线程
|
||||
- 当前已激活 `threadContracts`
|
||||
- 当前 `knowledgeFacts` 所属线程
|
||||
- fallback synthetic thread
|
||||
3. synthetic thread 必须显式标记 `source: fallback`，防止伪装成真实世界线程。
|
||||
4. 物品与任务模块统一消费 `ResolvedThreadRef[]`，不再直接消费裸字符串 id。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 后端日志中可区分真实线程与 fallback 线程。
|
||||
- 运行时物品说明、任务目标和世界冲突有明确对应，不再只围绕当前场景 id 即时拼接。
|
||||
|
||||
### 风险与回滚
|
||||
|
||||
- 风险：现有 scene / encounter 到 thread 的映射不完整，可能导致命中率不高。
|
||||
- 回滚策略：保留 synthetic fallback，但必须在日志和结构体中显式标识来源。
|
||||
|
||||
---
|
||||
|
||||
## P0-3：先补基础验证链，避免后端世界消费升级后失控
|
||||
|
||||
### 问题定义
|
||||
|
||||
世界上下文一旦进入后端主链，后续所有任务和物品生成都将更依赖字段质量；若没有结构化校验，很容易引入“字段有了但解释不一致”的新问题。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- 为 `RuntimeWorldContext` 建立结构校验与测试样例。
|
||||
- 世界映射升级后可以快速回归。
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 为 `RuntimeWorldContext` 增加 schema 校验或最小断言层。
|
||||
2. 建立 3 组回归世界：
|
||||
- 武侠
|
||||
- 现代都市
|
||||
- 科幻/魔法混合
|
||||
3. 增加任务模块、物品模块的世界消费快照测试。
|
||||
4. 对“缺 `storyGraph`、缺 `items`、缺 `factions`”的情况补边界测试。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 世界消费链新增测试可稳定通过。
|
||||
- 新增字段不会让现有预设世界直接失效。
|
||||
|
||||
---
|
||||
|
||||
## 5. P1 优化方案：弱化模板主导，补齐世界物件图谱
|
||||
|
||||
## P1-1：把 `templateWorldType` 退回兼容层
|
||||
|
||||
### 问题定义
|
||||
|
||||
当前 `templateWorldType / compatibilityTemplateWorldType` 仍然过度参与角色模板、场景视觉、怪物池、fallback 映射，导致跨题材世界被粗暴压回 `WUXIA/XIANXIA`。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- `templateWorldType` 仅用于兼容旧模板与最低保底 fallback。
|
||||
- 真实映射优先读取 `ownedSettingLayers`、`themePack`、`referenceProfile`、世界表达层信号。
|
||||
- 新世界生成不再被强制压成二元题材。
|
||||
|
||||
### 关键文件
|
||||
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\ai\customWorldOrchestrator.ts`
|
||||
- `E:\Repos\Genarrative\src\services\customWorldTheme.ts`
|
||||
- `E:\Repos\Genarrative\src\data\customWorldVisuals.ts`
|
||||
- `E:\Repos\Genarrative\src\data\customWorldNpcMonsters.ts`
|
||||
- `E:\Repos\Genarrative\src\data\characterPresets.ts`
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 梳理所有直接读取 `templateWorldType` 的模块，按用途拆成：
|
||||
- 必须兼容旧内容
|
||||
- 实际主导内容生成
|
||||
2. 新增 `worldFlavorProfile` 或等价归一层，从以下信号综合得出世界风味：
|
||||
- 世界主题摘要
|
||||
- `themePack`
|
||||
- `expressionProfile`
|
||||
- `ownedSettingLayers`
|
||||
- `referenceProfile.sceneBuckets`
|
||||
- `referenceProfile.creatureArchetypes`
|
||||
3. 将视觉、怪物、角色模板选择改为优先读取 `worldFlavorProfile`。
|
||||
4. `templateWorldType` 只在真实信号不足时参与兜底。
|
||||
5. 补 5 类题材测试样本：
|
||||
- 现代金融
|
||||
- 赛博 AI 战争
|
||||
- 校园悬疑
|
||||
- 海洋奇幻
|
||||
- 仙侠科技混合
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 非武侠/仙侠世界不再默认掉进 `WUXIA/XIANXIA` preset 池。
|
||||
- 视觉、怪物、角色原型对同一世界的选择结果更加一致。
|
||||
- 旧世界内容仍能被兼容字段兜住。
|
||||
|
||||
### 风险与回滚
|
||||
|
||||
- 风险：移除模板主导后，部分老世界可能暂时失去稳定视觉锚点。
|
||||
- 回滚策略：保留兼容开关，允许单模块临时回退到旧模板选择逻辑。
|
||||
|
||||
---
|
||||
|
||||
## P1-2：建立世界级 Item Seed 与 World Item Graph
|
||||
|
||||
### 问题定义
|
||||
|
||||
`CustomWorldProfile.items` 虽然在类型层存在，但主链会主动清空，导致世界级物品图谱缺席，任务奖励、宝藏、掉落、交易更依赖运行时临时生成。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- 世界生成阶段可产出一批结构化 `item seeds`。
|
||||
- `item seeds` 能挂接到 `knowledgeFacts`、`landmarks`、`factions`、`threads`、`treasure hints`。
|
||||
- 运行时物品生成优先从世界级物件图谱中取材，而不是完全现场即兴。
|
||||
|
||||
### 关键文件
|
||||
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\ai\customWorldOrchestrator.ts`
|
||||
- `E:\Repos\Genarrative\src\services\customWorldBuilder.ts`
|
||||
- `E:\Repos\Genarrative\src\data\customWorldRuntime.ts`
|
||||
- `E:\Repos\Genarrative\src\services\storyEngine\knowledgeGraph.ts`
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\runtime-item\runtimeItemModule.ts`
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 停止在主链里无条件把 `items` 压空。
|
||||
2. 新增 `WorldItemSeed` 结构，最少包含：
|
||||
- `id`
|
||||
- `name`
|
||||
- `category`
|
||||
- `rarity`
|
||||
- `originType`
|
||||
- `relatedFactionIds`
|
||||
- `relatedThreadIds`
|
||||
- `relatedLandmarkIds`
|
||||
- `knowledgeSummary`
|
||||
3. 世界生成阶段只产出“有限世界物件 seed”，不预生成全量成品装备。
|
||||
4. 运行时物品模块新增两段式生成：
|
||||
- 先从 `WorldItemSeed` 中挑选相关 seed
|
||||
- 再根据当前场景和奖励语境编译成最终 runtime item
|
||||
5. 任务奖励、宝藏提示、交易货单优先引用世界 item seed。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 同一世界内的物品来源能够被追溯到特定势力、地标或线程。
|
||||
- 宝藏、任务奖励和偶发掉落之间开始出现统一世界物件语义。
|
||||
- 即使不预生成大量装备，系统也已具备稳定的世界物件骨架。
|
||||
|
||||
### 风险与回滚
|
||||
|
||||
- 风险：若 seed 太多，会拖慢世界生成与存档体积。
|
||||
- 回滚策略：限制每个世界的 seed 上限，只保留高价值世界物件骨架。
|
||||
|
||||
---
|
||||
|
||||
## P1-3：统一“任务奖励 / 宝藏 / 掉落 / 交易”的物品取材顺序
|
||||
|
||||
### 问题定义
|
||||
|
||||
即使补上世界 `items`，如果各入口仍各自即时生成，世界物件图谱仍然无法变成真实运行时约束。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- 物品相关入口统一读取同一套 world-first 取材顺序。
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 制定统一物品取材优先级：
|
||||
- 世界线程相关 seed
|
||||
- 当前场景相关 seed
|
||||
- 当前势力相关 seed
|
||||
- 当前角色 build / 属性补位型 seed
|
||||
- 程序化 fallback
|
||||
2. 将该顺序接入：
|
||||
- runtime item
|
||||
- quest reward
|
||||
- treasure hint
|
||||
- shop inventory
|
||||
3. 为每种入口记录 `itemSourceType`，便于后续审计。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 不同入口产出的物品不再像来自多个无关池子。
|
||||
- 同一阶段的奖励和世界冲突、场景语境具有明显一致性。
|
||||
|
||||
---
|
||||
|
||||
## 6. P2 优化方案：把文本世界升级成可操作对象世界
|
||||
|
||||
## P2-1：把 `majorFactions / coreConflicts` 升级成结构对象
|
||||
|
||||
### 问题定义
|
||||
|
||||
当前势力与冲突已能进入 `ThemePack`、`StoryGraph`、`FactionTensionState`，但本质仍偏文本语义层，尚未形成可索引、可归属、可推进的游戏对象。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- faction 成为正式实体。
|
||||
- conflict 成为正式实体。
|
||||
- NPC、scene、shop、quest、thread 可以明确挂接到 faction/conflict。
|
||||
|
||||
### 关键文件
|
||||
|
||||
- `E:\Repos\Genarrative\src\services\storyEngine\themePack.ts`
|
||||
- `E:\Repos\Genarrative\src\services\storyEngine\worldStoryGraph.ts`
|
||||
- `E:\Repos\Genarrative\src\services\storyEngine\factionTensionState.ts`
|
||||
- `E:\Repos\Genarrative\server-node\src\modules\quest\runtimeQuestModule.ts`
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 新增 `WorldFaction`、`WorldConflict` 结构类型。
|
||||
2. `majorFactions` 进入标准化流程，最少补：
|
||||
- `id`
|
||||
- `name`
|
||||
- `publicImage`
|
||||
- `stanceTags`
|
||||
- `homeLandmarkIds`
|
||||
- `relatedNpcIds`
|
||||
3. `coreConflicts` 进入标准化流程，最少补：
|
||||
- `id`
|
||||
- `title`
|
||||
- `parties`
|
||||
- `stakes`
|
||||
- `relatedThreadIds`
|
||||
- `pressureLevel`
|
||||
4. 任务模块改为先选 conflict，再派生 quest intent。
|
||||
5. scene / npc / 商店 / 敌对阵营状态优先读取 faction 归属。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 任一任务都可追溯到某个 faction 或 conflict，而不只是笼统“世界 tension”。
|
||||
- NPC 与场景可以明确展示势力归属或冲突立场。
|
||||
|
||||
### 风险与回滚
|
||||
|
||||
- 风险：结构化后，旧世界数据可能缺字段。
|
||||
- 回滚策略：保留旧字符串字段作为输入源，通过标准化编译器补齐对象字段。
|
||||
|
||||
---
|
||||
|
||||
## P2-2：修正 landmark 场景中的模板怪物硬注入
|
||||
|
||||
### 问题定义
|
||||
|
||||
当前 landmark scene 在放入 `landmark.sceneNpcIds` 对应实体之外，还会从模板怪物池额外拼入敌对实体，导致地标设定与实际战斗实体池出现偏移。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- landmark 场景内容优先由 `landmark + storyNpcs + factions + conflicts` 决定。
|
||||
- 模板怪物仅在内容缺口时补位。
|
||||
- 补位结果也必须受世界题材和当前线程约束。
|
||||
|
||||
### 关键文件
|
||||
|
||||
- `E:\Repos\Genarrative\src\data\scenePresets.ts`
|
||||
- `E:\Repos\Genarrative\src\data\customWorldNpcMonsters.ts`
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 将场景实体池拆成三层：
|
||||
- 显式指定实体
|
||||
- 世界关系推导实体
|
||||
- 模板补位实体
|
||||
2. 补位触发条件必须显式化，例如：
|
||||
- 当前场景无敌对实体
|
||||
- 当前任务需要战斗对象
|
||||
- 当前地标存在压力标签但无实体承载
|
||||
3. 模板补位时必须额外经过：
|
||||
- 世界风味过滤
|
||||
- faction/conflict 过滤
|
||||
- landmark 标签过滤
|
||||
4. 记录实体来源，供后续审计。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- landmark 场景中的实体构成更忠于世界原始设定。
|
||||
- 非武侠/仙侠世界不再被模板怪物池轻易拖偏。
|
||||
|
||||
---
|
||||
|
||||
## P2-3：让冲突与势力真实进入任务和场景状态推进
|
||||
|
||||
### 问题定义
|
||||
|
||||
即使 faction/conflict 对象化，如果任务与场景状态推进仍然只吃文本 tension，总体改善也会有限。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- 冲突和势力状态能驱动任务来源、场景压力、敌我关系和奖励语境。
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 任务生成先选 conflict，再根据 `pressureLevel`、`party`、`stakes` 生成目标和阶段。
|
||||
2. 场景压力读取当前 `conflict` 和 `faction tension`，决定：
|
||||
- 敌对出现概率
|
||||
- 商店风格
|
||||
- 场景描述张力
|
||||
3. 奖励语义优先与 conflict/faction 绑定。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 同一冲突升温后，任务、场景、物品奖励能出现同步变化。
|
||||
|
||||
---
|
||||
|
||||
## 7. P3 优化方案：补齐长尾 archetype 与创作层沉淀
|
||||
|
||||
## P3-1：扩展 `referenceProfile.roleArchetypes` 来源
|
||||
|
||||
### 问题定义
|
||||
|
||||
当前 `roleArchetypes` 主要从 `playableNpcs.slice(0, 6)` 派生，导致可玩角色映射稳定，但长尾 `storyNpcs`、平民、敌对成员、怪物的 archetype 覆盖不足。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- `roleArchetypes` 来源覆盖 `playableNpcs + storyNpcs`。
|
||||
- 长尾角色也能沉淀为稳定 archetype。
|
||||
|
||||
### 关键文件
|
||||
|
||||
- `E:\Repos\Genarrative\src\services\customWorldOwnedSettingLayers.ts`
|
||||
- `E:\Repos\Genarrative\src\services\customWorldReferenceSignals.ts`
|
||||
- `E:\Repos\Genarrative\src\data\characterPresets.ts`
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 调整 archetype 编译输入，加入 `storyNpcs`。
|
||||
2. 按角色用途拆 archetype 桶：
|
||||
- playable
|
||||
- civilian
|
||||
- hostile
|
||||
- monster
|
||||
- faction member
|
||||
3. 为长尾 archetype 增加抽样上限与去重规则，避免噪声过大。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 非主角型角色在模板选择时命中率更高。
|
||||
- 长尾场景角色的表现更稳定，不再过度依赖 heuristics fallback。
|
||||
|
||||
---
|
||||
|
||||
## P3-2：重新定义哪些创作层元数据需要进入运行时
|
||||
|
||||
### 问题定义
|
||||
|
||||
`creatorIntent / anchorPack / lockState / anchorContent` 当前主要停留在创作与编辑器链路，对正式运行时作用较弱。
|
||||
|
||||
### 目标状态
|
||||
|
||||
- 明确区分“只服务创作编辑”的元数据和“应进入运行时约束”的元数据。
|
||||
- 防止未来编辑器功能越做越多，但运行时仍读不到关键锚点。
|
||||
|
||||
### 实施步骤
|
||||
|
||||
1. 对四类元数据逐项分层：
|
||||
- 创作态专用
|
||||
- 编译态可消费
|
||||
- 运行时必须消费
|
||||
2. 首批建议进入运行时的内容：
|
||||
- 不可违背的世界禁令
|
||||
- 必须保留的主势力/主线锚点
|
||||
- 必须保留的世界表达边界
|
||||
3. 将运行时需要消费的部分编译进 `ownedSettingLayers` 或 `RuntimeWorldContext`，不要让运行时直接读取编辑器原始字段。
|
||||
|
||||
### 验收标准
|
||||
|
||||
- 世界编辑器中被锁定的高优先级设定，能在任务、剧情、物品和场景中持续生效。
|
||||
- 创作层字段不会原样泄漏进运行时，仍保持清晰编译边界。
|
||||
|
||||
---
|
||||
|
||||
## 8. 推荐实施顺序
|
||||
|
||||
## 第一阶段：先打通后端世界消费主链
|
||||
|
||||
1. `P0-1` 统一 `RuntimeWorldContext`
|
||||
2. `P0-2` 接入真实线程解析
|
||||
3. `P0-3` 补回归验证链
|
||||
|
||||
## 第二阶段：弱化模板主导，补齐世界物件骨架
|
||||
|
||||
1. `P1-1` 模板退回兼容层
|
||||
2. `P1-2` 建立世界 item seed
|
||||
3. `P1-3` 统一物品入口取材顺序
|
||||
|
||||
## 第三阶段：把世界对象化
|
||||
|
||||
1. `P2-1` faction/conflict 对象化
|
||||
2. `P2-2` 修正 landmark 怪物注入
|
||||
3. `P2-3` 接入任务与场景状态推进
|
||||
|
||||
## 第四阶段：补齐长尾映射与创作层沉淀
|
||||
|
||||
1. `P3-1` 扩展 archetype 来源
|
||||
2. `P3-2` 明确创作层入运行时边界
|
||||
|
||||
---
|
||||
|
||||
## 9. 里程碑拆分建议
|
||||
|
||||
## M1：世界消费对齐
|
||||
|
||||
- 输出物：`RuntimeWorldContext`、后端任务/物品世界消费升级、真实线程解析
|
||||
- 结果判定：前后端都能围绕同一世界线程与规则说话
|
||||
|
||||
## M2：跨题材映射纠偏
|
||||
|
||||
- 输出物：`worldFlavorProfile`、模板兼容层瘦身、跨题材测试集
|
||||
- 结果判定：现代/科幻/混合题材不再被压回武侠/仙侠
|
||||
|
||||
## M3：世界物件与势力冲突对象化
|
||||
|
||||
- 输出物：`WorldItemSeed`、`WorldFaction`、`WorldConflict`
|
||||
- 结果判定：任务、场景、物品奖励开始围绕世界对象图谱运转
|
||||
|
||||
## M4：长尾稳定化
|
||||
|
||||
- 输出物：扩展 archetype、运行时锚点编译边界
|
||||
- 结果判定：长尾 NPC 与世界编辑器高优先级设定都能稳定进入运行时
|
||||
|
||||
---
|
||||
|
||||
## 10. 验收口径
|
||||
|
||||
本轮优化建议至少按以下 8 条验收：
|
||||
|
||||
1. 后端任务与物品模块都已消费统一 `RuntimeWorldContext`。
|
||||
2. 后端 `activeThreadIds` 已能区分真实线程与 fallback 线程。
|
||||
3. 非武侠/仙侠世界的视觉、怪物、角色模板选择明显更加合理。
|
||||
4. 世界 profile 中的 `items` 已形成有限但真实可用的 `item seed` 图谱。
|
||||
5. faction/conflict 已可被任务、场景、物品奖励直接引用。
|
||||
6. landmark 场景的实体池优先由地标与世界对象决定，不再被模板怪物硬主导。
|
||||
7. `storyNpcs` 已进入 archetype 编译链。
|
||||
8. 高优先级创作锚点已通过编译层进入运行时，而不是停留在编辑器态。
|
||||
|
||||
---
|
||||
|
||||
## 11. 本轮不建议优先做的事
|
||||
|
||||
- 不建议先扩充更多世界 preset、怪物 preset、场景 preset。
|
||||
- 不建议先美化编辑器文案或增加说明性 UI 文本。
|
||||
- 不建议在前端直接补更多规则判断，避免继续把世界逻辑留在表现层。
|
||||
- 不建议在没有统一后端世界 contract 之前分别微调 quest prompt 和 item prompt。
|
||||
|
||||
原因很明确：
|
||||
|
||||
**当前最缺的不是内容数量，而是“世界设定是否真的被一致消费”。在这一层没补齐前，继续加内容只会把映射偏差放大。**
|
||||
|
||||
---
|
||||
|
||||
## 12. 一句话结论
|
||||
|
||||
这轮优化最应该优先做的，不是继续往世界编辑器里加更多设定项，而是先把 `CustomWorldProfile -> 后端运行时任务/物品 -> 场景/NPC/奖励` 这条真实消费主链补齐；只有先把世界 profile 收束成单一真相源，后续跨题材世界、世界级物件、势力冲突和长尾 NPC 映射才会越做越稳。
|
||||
@@ -0,0 +1,579 @@
|
||||
# 工程无用分支、历史代码与隐形多链路大清洗执行计划（2026-04-21）
|
||||
|
||||
更新时间：`2026-04-21`
|
||||
|
||||
## 0. 文档目标
|
||||
|
||||
这份文档只解决一件事：
|
||||
|
||||
**对当前工程发起一轮“不是继续加功能，而是系统性减负、删重、收口、归档”的大清洗。**
|
||||
|
||||
这轮重点不是做表面上的“代码变少”，而是把下面 3 类长期拉低可读性和可维护性的东西真正处理掉：
|
||||
|
||||
1. 无用历史代码
|
||||
2. 隐形的多数据链路 / 多真相链路乱代码
|
||||
3. 实现到一半但长期挂在主工程里的半成品代码
|
||||
|
||||
本文目标不是重复现有审计，而是把已有结论整理成：
|
||||
|
||||
1. 可执行的清洗范围
|
||||
2. 明确的判定标准
|
||||
3. 分阶段的推进顺序
|
||||
4. 每阶段的交付物
|
||||
5. 可以落地的验收与回滚口径
|
||||
|
||||
---
|
||||
|
||||
## 1. 先把“清什么”说清楚
|
||||
|
||||
这次文档里说的“无用分支”，优先指的是：
|
||||
|
||||
1. 代码逻辑分支
|
||||
2. 数据链路分支
|
||||
3. 兼容实现分支
|
||||
4. 遗留入口分支
|
||||
|
||||
**不是先把 Git 分支清空。**
|
||||
|
||||
Git 分支治理可以后置做，但不能和首轮工程清洗混在一起，否则很容易把“代码归因”“入口归因”“历史责任归因”一起搅乱。
|
||||
|
||||
---
|
||||
|
||||
## 2. 三类清洗对象的定义
|
||||
|
||||
## 2.1 无用历史代码
|
||||
|
||||
满足以下任一特征，即进入“无用历史代码候选”：
|
||||
|
||||
1. 没有正式运行时入口，也没有当前规划要接回入口
|
||||
2. 只被测试或历史兼容层引用，但主流程已经不再依赖
|
||||
3. 与当前正式实现功能重复，但不是唯一真相源
|
||||
4. 只剩 stub、占位、迁移残骸、旧 prompt 壳子、旧 helper 壳子
|
||||
5. 生成产物仍留在主仓库，但已不再被正式流程消费
|
||||
|
||||
这类代码的处理目标是：
|
||||
|
||||
**删除、归档、降级标记三选一，不再长期以“也许以后要用”为理由挂在主路径里。**
|
||||
|
||||
## 2.2 隐形多数据链路乱代码
|
||||
|
||||
满足以下任一特征，即进入“隐形多链路问题候选”：
|
||||
|
||||
1. 同一份运行时状态同时由前端本地镜像和后端会话共同解释
|
||||
2. 同一类任务、物品、剧情、鉴权逻辑在前后端或多模块里各维护一份
|
||||
3. 同一份数据在“提交前本地写一份、提交后服务端再回填一份”
|
||||
4. 同一功能表面只有一个按钮，背后却有两到三条实现路径
|
||||
5. 正式链路和 fallback 链路长期并存，且没有退场时间
|
||||
|
||||
这类问题的处理目标是：
|
||||
|
||||
**把每条正式能力收敛成单一主链、单一真相源、单一编排出口。**
|
||||
|
||||
## 2.3 实现到一半的半成品代码
|
||||
|
||||
满足以下任一特征，即进入“半成品候选”：
|
||||
|
||||
1. UI、Hook、Service 已存在，但没有正式入口
|
||||
2. 文档写了概念，代码只落了一半，后续也没有继续接完
|
||||
3. 只有局部测试或局部 mock 在用，真实流程不用
|
||||
4. 仍保留 TODO / stub / draft / launcher / modal，但未纳入当前主线
|
||||
5. 用户看不到、主流程不调用、团队也没有当前阶段交付计划
|
||||
|
||||
这类代码的处理目标是：
|
||||
|
||||
**要么纳入当前主线尽快补完，要么明确归档，不允许继续以“半活状态”污染主工程。**
|
||||
|
||||
---
|
||||
|
||||
## 3. 这轮清洗后的目标状态
|
||||
|
||||
本轮完成后，工程应至少达到下面 7 个状态：
|
||||
|
||||
1. 同一领域只保留一条正式主链，不再出现前后端双真相或多桥接链路并存
|
||||
2. 无入口孤岛、旧兼容壳子、旧 prompt 壳子、旧 stub 文件有明确去留结果
|
||||
3. “实现到一半”的模块不再伪装成正式能力挂在主工程中
|
||||
4. 前端继续回到“表现层”，正式运行时逻辑、鉴权真相、任务物品编排继续向后端收口
|
||||
5. 热点大文件不再同时背负历史残留、兼容残留和新逻辑堆叠
|
||||
6. 文档与代码状态一致，不再让旧规划长期误导当前执行方向
|
||||
7. `lint + typecheck + test + build + check:content` 重新成为可信基线
|
||||
|
||||
---
|
||||
|
||||
## 4. 执行原则
|
||||
|
||||
## 4.1 不做大爆炸整仓改写
|
||||
|
||||
本轮只允许“小批次、可回归、可解释”的连续清洗，不做一次性整仓推翻。
|
||||
|
||||
## 4.2 先建台账，再动删除
|
||||
|
||||
任何删除、归档、重定向动作前，必须先确认：
|
||||
|
||||
1. 当前入口关系
|
||||
2. 当前依赖关系
|
||||
3. 当前替代路径
|
||||
4. 删除后的验收路径
|
||||
|
||||
没有台账，不做大规模删改。
|
||||
|
||||
## 4.3 先收真相源，再谈瘦身
|
||||
|
||||
如果同一领域仍有多条真相链路并存，优先收口真相源，而不是只删表面代码量。
|
||||
|
||||
## 4.4 文档和代码同步收口
|
||||
|
||||
只要本轮确认某条旧链降级、冻结、归档，相关文档必须同步更新，不能让旧文档继续把团队往废链路上拉。
|
||||
|
||||
## 4.5 每批清洗必须可回归
|
||||
|
||||
每一批完成后至少要求：
|
||||
|
||||
1. 入口可解释
|
||||
2. 回归路径明确
|
||||
3. 门禁可跑
|
||||
4. 回滚点存在
|
||||
|
||||
---
|
||||
|
||||
## 5. 当前已知问题基础
|
||||
|
||||
本计划基于现有文档已经确认的结论推进，重点参考：
|
||||
|
||||
1. `docs/audits/engineering/README.md`
|
||||
2. `docs/audits/engineering/ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md`
|
||||
3. `docs/audits/engineering/CURRENT_ENGINEERING_OPTIMIZATION_OPPORTUNITIES_2026-04-20.md`
|
||||
4. `docs/technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md`
|
||||
5. `docs/experience/PROJECT_WORK_EXPERIENCE_PLAYBOOK.md`
|
||||
|
||||
按当前审计结果，首轮就应重点关注下面 3 组对象。
|
||||
|
||||
## 5.1 当前高置信度“无入口 / 孤岛 / 残留”候选
|
||||
|
||||
以下对象已经在最近审计中被点名，默认进入首轮复核台账：
|
||||
|
||||
1. `src/components/GameShell.tsx`
|
||||
2. `src/components/custom-world-home/CustomWorldCreationHub.tsx`
|
||||
3. `src/components/custom-world-home/CustomWorldCreationLauncherModal.tsx`
|
||||
4. `src/components/custom-world-agent/CustomWorldAgentLauncherModal.tsx`
|
||||
5. `src/components/custom-world-agent/CustomWorldAgentDraftDrawer.tsx`
|
||||
6. `src/hooks/story/storyBootstrap.ts`
|
||||
7. `src/hooks/useEquipmentFlow.ts`
|
||||
8. `src/hooks/useForgeFlow.ts`
|
||||
9. `src/hooks/useInventoryFlow.ts`
|
||||
10. `src/services/customWorldPresentation.stub.ts`
|
||||
11. `src/services/typewriter.ts`
|
||||
12. `src/prompts/customWorldOrchestratorPrompts.ts`
|
||||
13. `src/prompts/storyOrchestratorPrompts.ts`
|
||||
14. `src/data/buildTagSimilarity.generated.ts`（已在后续清理批次中删除）
|
||||
|
||||
这些文件不能直接判死刑，但必须进入“保留 / 接回 / 归档 / 删除”四选一清单。
|
||||
|
||||
## 5.2 当前高置信度“隐形多链路 / 双真相”候选
|
||||
|
||||
以下对象应进入首轮主链收口清单：
|
||||
|
||||
1. `src/hooks/story/runtimeStoryCoordinator.ts`
|
||||
2. `src/services/runtimeStoryService.ts`
|
||||
3. `src/services/apiClient.ts`
|
||||
4. `src/hooks/story/npcEncounterActions.ts`
|
||||
5. `src/services/questDirector.ts`
|
||||
6. `src/services/runtimeItemAiDirector.ts`
|
||||
7. `src/services/ai.ts`
|
||||
|
||||
当前这批问题的共同特征是：
|
||||
|
||||
1. 前端仍保留本地镜像、自动登录凭证或双环境编排残留
|
||||
2. NPC 任务换单、任务生成、运行时物品生成仍有前端发起和混合执行痕迹
|
||||
3. 浏览器侧大型 AI orchestration 仍未完全退出主工程
|
||||
|
||||
## 5.3 当前“新热点继续吸纳历史复杂度”候选
|
||||
|
||||
以下对象不一定是垃圾代码，但很容易继续成为历史残留的新容器：
|
||||
|
||||
1. `src/components/CustomWorldEntityEditorModal.tsx`
|
||||
2. `server-node/src/modules/assets/characterAssetRoutes.ts`
|
||||
3. `src/prompts/storyPromptBuilders.ts`
|
||||
4. `server-node/src/modules/custom-world/runtimeProfile.ts`
|
||||
5. `src/components/game-shell/PreGameSelectionFlow.tsx`
|
||||
6. `src/components/game-shell/PlatformHomeView.tsx`
|
||||
|
||||
这批文件必须在本轮中被视为“禁止继续裸堆新逻辑”的重点区域。
|
||||
|
||||
---
|
||||
|
||||
## 6. 清洗判定表
|
||||
|
||||
每个候选对象进入清理台账后，只允许落到下面 4 类结果之一：
|
||||
|
||||
| 结果类型 | 适用场景 | 处理动作 |
|
||||
| --- | --- | --- |
|
||||
| 删除 | 无入口、无当前规划、无兼容价值 | 直接删文件、删引用、补回归 |
|
||||
| 归档 | 暂不继续，但保留历史价值 | 移出主路径、在文档中标明冻结状态 |
|
||||
| 扶正 | 当前主线确实需要，只是入口丢失或命名混乱 | 接回正式入口、补测试、补文档 |
|
||||
| 拆分收口 | 不是废代码，但混合了历史残留和正式逻辑 | 先拆职责，再删除残留分支 |
|
||||
|
||||
禁止出现第 5 种状态：
|
||||
|
||||
**“先留着，以后再说，但继续挂在主工程里。”**
|
||||
|
||||
---
|
||||
|
||||
## 7. 分阶段执行计划
|
||||
|
||||
## P0：冻结新增污染，先建立清洗台账
|
||||
|
||||
### 目标
|
||||
|
||||
先把“哪些东西要清、为什么清、怎么判定是否能清”讲清楚，停止继续往旧热点和疑似废链上加逻辑。
|
||||
|
||||
### 主要动作
|
||||
|
||||
1. 建立 3 份清单：
|
||||
- 无入口孤岛清单
|
||||
- 多真相链路清单
|
||||
- 半成品能力清单
|
||||
2. 为每个对象补 5 个字段：
|
||||
- 当前入口
|
||||
- 当前调用方
|
||||
- 当前替代路径
|
||||
- 建议结论
|
||||
- 回归验证点
|
||||
3. 约束新增开发：
|
||||
- 不再向疑似废链补功能
|
||||
- 不再向热点大文件直接叠逻辑
|
||||
- 新需求优先接到当前正式主链
|
||||
4. 明确本轮清洗后的唯一方向：
|
||||
- 前端只做表现
|
||||
- 后端持有正式运行时真相
|
||||
- 旧兼容链不能继续膨胀
|
||||
|
||||
### 交付物
|
||||
|
||||
1. 清洗对象总台账
|
||||
2. 首轮批次拆分表
|
||||
3. 每批回归清单
|
||||
|
||||
### 完成标准
|
||||
|
||||
不是“开始删文件”才算开始。
|
||||
|
||||
只要台账、批次、判定口径和冻结规则明确，这一阶段就算完成。
|
||||
|
||||
---
|
||||
|
||||
## P1：先清无入口孤岛和明显历史残留
|
||||
|
||||
### 目标
|
||||
|
||||
先把最容易污染阅读体验、又不需要大规模业务改造的对象清掉，快速降低仓库噪音。
|
||||
|
||||
### 优先清理对象
|
||||
|
||||
1. 无运行时入口组件
|
||||
2. 只被测试引用的旧壳层
|
||||
3. 已迁移后留下的 stub / prompt 壳 / helper 壳
|
||||
4. 已不进入正式链路的 generated 文件
|
||||
5. 旧 launcher / draft / modal 壳层
|
||||
|
||||
### 处理顺序建议
|
||||
|
||||
1. 先处理 `prompt / stub / helper / launcher` 级别的小残留
|
||||
2. 再处理 `旧 hook / 旧 flow / 旧 shell` 级别的流程残留
|
||||
3. 最后处理“可能有历史价值但暂不接回”的 UI 大块头
|
||||
|
||||
### 本阶段输出结果
|
||||
|
||||
每个对象必须给出明确结果：
|
||||
|
||||
1. 删除
|
||||
2. 归档
|
||||
3. 扶正接回
|
||||
|
||||
### 验收标准
|
||||
|
||||
1. 主工程中“没有正式入口的文件”显著减少
|
||||
2. 新人看目录时，不再大量遇到真假难辨的旧入口
|
||||
3. 相关引用、测试、文档同步更新
|
||||
|
||||
---
|
||||
|
||||
## P2：收单一真相源，清掉隐形多数据链路
|
||||
|
||||
### 目标
|
||||
|
||||
这阶段不以“删多少文件”为核心，而是以“同一件事最终只走一条正式链”作为核心。
|
||||
|
||||
### 第一优先级链路
|
||||
|
||||
1. 运行时快照链
|
||||
2. 鉴权与自动登录链
|
||||
3. NPC 任务生成 / 换单链
|
||||
4. 运行时物品生成链
|
||||
5. 浏览器端 AI orchestration 链
|
||||
|
||||
### 重点动作
|
||||
|
||||
1. 收掉前端“提交前先写本地真相，再等服务端回填”的链路
|
||||
2. 收掉本地存储中的自动登录用户名 / 密码真相
|
||||
3. 把 NPC 委托换单动作继续迁回后端运行时主链
|
||||
4. 将 `questDirector`、`runtimeItemAiDirector` 拆成：
|
||||
- 前端 SDK 层
|
||||
- 后端正式执行层
|
||||
5. 继续压缩浏览器端 `src/services/ai.ts` 的正式职责
|
||||
|
||||
### 这阶段最重要的判断标准
|
||||
|
||||
不是“文件还在不在”，而是下面 4 条是否成立：
|
||||
|
||||
1. 玩家一次动作只提交一个正式 action，而不是两边各写一遍状态
|
||||
2. 前端不再持有正式运行时镜像真相
|
||||
3. 前端不再长期持有自动登录账号密码
|
||||
4. 同一类生成能力不再同时存在“浏览器正式版”和“后端正式版”
|
||||
|
||||
### 验收标准
|
||||
|
||||
1. 正式运行时状态解释权明确以后端为准
|
||||
2. 鉴权边界不再依赖浏览器保存高风险凭证
|
||||
3. NPC 任务、物品、剧情编排链路的职责边界清楚
|
||||
|
||||
---
|
||||
|
||||
## P3：集中处理实现到一半的半成品能力
|
||||
|
||||
### 目标
|
||||
|
||||
把“看起来像功能、实际上不是当前正式能力”的对象清出主路径。
|
||||
|
||||
### 清理规则
|
||||
|
||||
半成品对象统一按下面规则处理：
|
||||
|
||||
1. 30 天内明确要接回主线的，进入补完批次
|
||||
2. 当前阶段不做的，降级为归档或实验稿
|
||||
3. 没有继续计划、也没有正式入口价值的，直接删除
|
||||
|
||||
### 本阶段重点对象
|
||||
|
||||
1. 只有 modal / launcher / draft 壳层，但没有正式调用链的 UI
|
||||
2. 只有部分 hook / service 实现，但没有主链消费的流程模块
|
||||
3. 只剩“概念占位”的 prompt、adapter、presentation、stub 文件
|
||||
4. 文档里反复提到、代码里却长期不接线的能力块
|
||||
|
||||
### 必须同步做的事
|
||||
|
||||
1. 更新对应规划文档
|
||||
2. 从当前主叙事中移除本轮明确不做的项
|
||||
3. 给保留实验稿加清晰标签，避免被误读成正式能力
|
||||
|
||||
### 验收标准
|
||||
|
||||
1. 主工程里不再混着大量“像功能但不是正式功能”的对象
|
||||
2. 文档不再持续推动团队回头补本轮已冻结能力
|
||||
3. 目录层级和入口关系显著更清楚
|
||||
|
||||
---
|
||||
|
||||
## P4：在减负后的基础上拆热点，恢复可读性
|
||||
|
||||
### 目标
|
||||
|
||||
前 3 阶段做完后，再进入“真正让工程重新好读”的结构优化。
|
||||
|
||||
### 重点对象
|
||||
|
||||
1. `src/components/CustomWorldEntityEditorModal.tsx`
|
||||
2. `server-node/src/modules/assets/characterAssetRoutes.ts`
|
||||
3. `src/prompts/storyPromptBuilders.ts`
|
||||
4. `server-node/src/modules/custom-world/runtimeProfile.ts`
|
||||
5. `src/components/game-shell/PreGameSelectionFlow.tsx`
|
||||
6. `src/components/game-shell/PlatformHomeView.tsx`
|
||||
|
||||
### 拆分原则
|
||||
|
||||
1. 先按职责拆，不按文件长度拆
|
||||
2. 先把历史残留和兼容分支移走，再做正式模块化
|
||||
3. 拆完之后必须更清晰地回答：
|
||||
- 谁负责 UI
|
||||
- 谁负责数据准备
|
||||
- 谁负责正式规则
|
||||
- 谁负责调用后端
|
||||
|
||||
### 验收标准
|
||||
|
||||
1. 热点文件不再同时吞 UI、规则、编排、兼容残留
|
||||
2. 新功能不需要再跨四五层历史壳子一起改
|
||||
3. 后续 review 能更快定位责任边界
|
||||
|
||||
---
|
||||
|
||||
## 8. 批次拆分建议
|
||||
|
||||
为了避免清理动作过大失控，建议按下面粒度推进：
|
||||
|
||||
## 批次 A：小型孤岛与残留壳子
|
||||
|
||||
处理对象：
|
||||
|
||||
1. stub
|
||||
2. prompt 壳
|
||||
3. 无入口 helper
|
||||
4. 无入口 launcher / modal
|
||||
|
||||
目标：
|
||||
|
||||
快速去噪，降低目录误导性。
|
||||
|
||||
## 批次 B：旧 flow / 旧 shell / 旧 hook
|
||||
|
||||
处理对象：
|
||||
|
||||
1. `GameShell`
|
||||
2. `storyBootstrap`
|
||||
3. `useEquipmentFlow`
|
||||
4. `useForgeFlow`
|
||||
5. `useInventoryFlow`
|
||||
|
||||
目标：
|
||||
|
||||
清旧主流程壳层和旧流程残留。
|
||||
|
||||
## 批次 C：运行时真相收口
|
||||
|
||||
处理对象：
|
||||
|
||||
1. `runtimeStoryCoordinator`
|
||||
2. `runtimeStoryService`
|
||||
3. `apiClient`
|
||||
|
||||
目标：
|
||||
|
||||
去掉本地镜像真相与本地鉴权真相。
|
||||
|
||||
## 批次 D：任务 / 物品 / AI 混合执行层收口
|
||||
|
||||
处理对象：
|
||||
|
||||
1. `npcEncounterActions`
|
||||
2. `questDirector`
|
||||
3. `runtimeItemAiDirector`
|
||||
4. `ai.ts`
|
||||
|
||||
目标：
|
||||
|
||||
消灭混合执行和双环境正式链。
|
||||
|
||||
## 批次 E：热点大文件拆分
|
||||
|
||||
处理对象：
|
||||
|
||||
1. custom world
|
||||
2. assets
|
||||
3. game shell platform
|
||||
4. prompt builder
|
||||
5. runtime profile
|
||||
|
||||
目标：
|
||||
|
||||
在主链已收口后恢复可读性。
|
||||
|
||||
---
|
||||
|
||||
## 9. 每批必须产出的内容
|
||||
|
||||
每一批都必须带着下面 5 类产出结束：
|
||||
|
||||
1. 代码改动
|
||||
2. 文档回填
|
||||
3. 去留说明
|
||||
4. 验收记录
|
||||
5. 回滚点说明
|
||||
|
||||
如果一个批次只能产出“删了几个文件”，但说不清：
|
||||
|
||||
1. 删除后谁接手
|
||||
2. 主链是否更清楚
|
||||
3. 文档是否同步
|
||||
|
||||
那么这个批次不算完成。
|
||||
|
||||
---
|
||||
|
||||
## 10. 统一验收口径
|
||||
|
||||
本轮建议至少用下面 10 条作为统一验收口径：
|
||||
|
||||
1. `npm run lint`
|
||||
2. `npm run test`
|
||||
3. `npm run build`
|
||||
4. `npm run check:content`
|
||||
5. 目录中高置信度孤岛数量下降
|
||||
6. 旧兼容链不再继续接收新逻辑
|
||||
7. 前端不再保存自动登录用户名 / 密码
|
||||
8. 运行时主状态不再由前端本地镜像优先解释
|
||||
9. 当前正式能力的入口关系能在文档中说清楚
|
||||
10. 新人阅读主目录和主流程文件时，不再频繁遇到真假并存入口
|
||||
|
||||
---
|
||||
|
||||
## 11. 风险与控制点
|
||||
|
||||
## 11.1 最大风险不是“删多了”，而是“边删边继续加废链”
|
||||
|
||||
如果没有冻结规则，这轮会一边清旧，一边又把新逻辑接回旧壳子里，最后只会重复劳动。
|
||||
|
||||
## 11.2 不能把“兼容”当永久借口
|
||||
|
||||
兼容链可以短期存在，但必须写清：
|
||||
|
||||
1. 为什么保留
|
||||
2. 保留到什么时候
|
||||
3. 谁负责后续移除
|
||||
|
||||
## 11.3 不能只删代码，不收文档
|
||||
|
||||
如果代码删了，旧文档不改，团队还是会持续把需求往旧链上接。
|
||||
|
||||
## 11.4 不能只盯文件大小，不盯真相链
|
||||
|
||||
有些文件很大但确实是正式主链。
|
||||
有些文件很小，却是双真相和多链路的根源。
|
||||
|
||||
本轮必须优先盯后者。
|
||||
|
||||
---
|
||||
|
||||
## 12. 当前不建议优先做的事
|
||||
|
||||
1. 不建议在清洗期间继续横向扩功能
|
||||
2. 不建议直接对热点文件做“纯格式化式拆分”
|
||||
3. 不建议在未确认入口关系前整片删除可疑模块
|
||||
4. 不建议让前端继续补正式运行时逻辑作为短期兜底
|
||||
5. 不建议保留“也许以后有用”的主工程残留
|
||||
|
||||
原因很简单：
|
||||
|
||||
**当前最需要恢复的不是功能宽度，而是工程的干净边界、单一主链和可读体验。**
|
||||
|
||||
---
|
||||
|
||||
## 13. 推荐推进顺序
|
||||
|
||||
建议严格按下面顺序推进：
|
||||
|
||||
1. 先做 P0：建台账、冻结污染
|
||||
2. 再做 P1：清无入口孤岛和小残留
|
||||
3. 再做 P2：收运行时、鉴权、任务物品的单一主链
|
||||
4. 再做 P3：处理半成品能力与文档冻结项
|
||||
5. 最后做 P4：拆热点、补结构可读性
|
||||
|
||||
不建议倒过来先拆热点。
|
||||
|
||||
因为如果历史残留和双真相还在，大文件拆完以后，复杂度只是换地方继续长。
|
||||
|
||||
---
|
||||
|
||||
## 14. 一句话结论
|
||||
|
||||
这轮工程大清洗的核心，不是“删旧代码看起来更清爽”，而是：
|
||||
|
||||
**用一轮有台账、有判定、有阶段、有验收的大清理，把无用历史代码、隐形多链路乱代码和半成品能力从主工程里真正清出去，让项目重新回到单一主链、单一真相源、目录可读、职责清楚的健康状态。**
|
||||
20
docs/planning/README.md
Normal file
20
docs/planning/README.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# 规划与优先级
|
||||
|
||||
## 当前入口
|
||||
|
||||
- [ENGINEERING_DEAD_CODE_AND_HIDDEN_BRANCH_CLEANUP_PLAN_2026-04-21.md](./ENGINEERING_DEAD_CODE_AND_HIDDEN_BRANCH_CLEANUP_PLAN_2026-04-21.md)：面向无用历史代码、隐形多数据链路和半成品实现的一轮工程大清洗执行计划，强调先建台账、再删重收口、最后恢复主工程可读性。
|
||||
- [../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/CREATION_FLOW_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md)：当前创作入口、Agent session、结果页自动保存、作品库与进入世界主链的正式文件级重构基线；涉及目录落位、命名规范、阶段验收与工作包拆分时优先看这一份。
|
||||
- [../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md](../technical/RPG_ENTRY_RUNTIME_CHAIN_REFACTOR_EXECUTION_PLAN_2026-04-21.md)：当前平台入口、继续游戏、角色选择、RPG runtime 与 runtime story 主链的正式文件级重构基线；涉及入口壳层、session、runtime、story、route/service/repository 拆分时优先看这一份。
|
||||
- [CURRENT_AGENT_CREATION_FLOW_OPTIMIZATION_PLAN_2026-04-20.md](./CURRENT_AGENT_CREATION_FLOW_OPTIMIZATION_PLAN_2026-04-20.md)：创作链高层目标、冻结边界与执行顺序说明；文件级拆分与阶段验收以创作链重构执行方案为准。
|
||||
- [../technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md](../technical/CURRENT_BACKEND_IMPLEMENTATION_BASELINE_2026-04-25.md)：当前后端唯一落地口径，后续排期涉及服务端、数据真相或 SpacetimeDB 时优先按这一份判断方向。
|
||||
- [BEIJING_POLICY_APPLICATION_OVERVIEW_13_21_24_2026-04-14.md](./BEIJING_POLICY_APPLICATION_OVERVIEW_13_21_24_2026-04-14.md)：北京市方向 13 / 21 / 24 的统一判断、共用材料框架和准备顺序。
|
||||
- [BEIJING_DIRECTION13_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION13_APPLICATION_MATERIALS_2026-04-14.md)：方向 13 软件智能化提升奖励的硬门槛、必交材料、底稿建议和证据清单。
|
||||
- [BEIJING_DIRECTION21_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION21_APPLICATION_MATERIALS_2026-04-14.md)：方向 21 “创赢未来”成长计划的报名表、BP、Demo 和融资规划整理。
|
||||
- [BEIJING_DIRECTION24_APPLICATION_MATERIALS_2026-04-14.md](./BEIJING_DIRECTION24_APPLICATION_MATERIALS_2026-04-14.md)：方向 24 服务机构配券产品与企业用券两条路径的判断和材料备查。
|
||||
|
||||
## 使用建议
|
||||
|
||||
- 需要排期、拆阶段、判断先修基线还是先加功能时，先看这份。
|
||||
- 当前如果要推进创作链或 RPG 运行时主链重构，先看上面的两份 `2026-04-21` 执行方案，再回来看高层优先级和冻结边界。
|
||||
- 涉及后端方案时，不再参考已删除的 Express / Node 规划文档，统一回到 Rust / SpacetimeDB 当前基线。
|
||||
- 这份文档大量引用了经验文档、工程审查和 PRD，适合作为跨文档导航页使用。
|
||||
Reference in New Issue
Block a user