347 lines
12 KiB
Markdown
347 lines
12 KiB
Markdown
# 方向 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 端案例组织空间。
|