chore:文档补全
This commit is contained in:
Evilom
@@ -0,0 +1,325 @@
|
||||
# QBIbdTcbdoiHYlxI3MocFnQnn3d
|
||||
|
||||
Source: https://my.feishu.cn/docx/QBIbdTcbdoiHYlxI3MocFnQnn3d
|
||||
|
||||
|
||||
#### **今日内容概述：**
|
||||
##### 1.调研游戏行业 AI 编程助手产品
|
||||
##### 2.梳理后续重点观察的开源通用 AI 编程助手方向
|
||||
##### 3.参与经营策略复盘会
|
||||
## 一、核心问题与调研目标
|
||||
**核心问题**
|
||||
#### 有哪些主流开源 AI 编程助手，各自具备哪些特点，哪些更适合作为二次开发基座
|
||||
#### 有哪些面向游戏行业的 AI 编程助手产品，它们采用了什么样的产品形态与技术路线
|
||||
**调研重点**
|
||||
从 **可扩展性、可控性、引擎/编辑器接入能力、人工干预空间** 四个维度，判断哪些方向更具落地价值。
|
||||
## 二、游戏行业 AI 编程助手产品调研
|
||||
### 1. 腾讯 MagicAI：面向 Godot 生态的垂直游戏 AI 编程助手
|
||||
**定位**
|
||||
腾讯基于 Godot 生态推出的游戏行业 AI 编程助手，当前重点价值在于打通编程助手、引擎与编辑器能力。
|
||||
#### （1）简单游戏生成体验
|
||||
围绕“飞机大战”小游戏进行测试，使用的提示词如下：
|
||||
**结果**
|
||||
- 移动正常
|
||||
- 攻击正常
|
||||
- UI 显示正常
|
||||
- 整体游玩未发现明显问题
|
||||
#### （2）复杂游戏生成体验
|
||||
围绕“MOBA 小游戏”进行测试，使用的提示词如下：
|
||||
- 帮我做一个 moba 的小游戏
|
||||
- 点击开始游戏没反应，并且在选择英雄界面，除了法师、射手和战士都显示错乱到左上角且缩小
|
||||
- 布局错乱，不能选英雄也无法开始
|
||||
- 启动游戏就显示错乱了
|
||||
- 此外还有这俩报错
|
||||
- 这里布局错乱
|
||||
- 编译报错
|
||||
- 这个界面错乱
|
||||
- 启动后布局显示这样错乱
|
||||
**结果**
|
||||
- 角色移动基本可用
|
||||
- 攻击等核心战斗能力无法正常完成
|
||||
- UI 布局与界面状态多轮错乱
|
||||
- 启动、编译、界面交互等多处存在问题
|
||||
**阶段性判断**
|
||||
- 简单游戏可以，复杂游戏不行
|
||||
- 问题主要来自两部分：
|
||||
- **模型能力限制**：复杂逻辑生成、布局一致性、长程状态维护不足
|
||||
- **Agent 与工具链不够垂直**：即便接入编辑器与引擎，仍缺少更细颗粒度的游戏任务拆解能力
|
||||
### 2. MagicAI 产品拆解
|
||||
**产品形态**
|
||||
MagicAI 本质上是一款运行在 **CodeBuddy（VS Code）插件生态**中的垂直工具，而不是一套独 IDE 或引擎体系。
|
||||
其能力大致分为两部分：
|
||||
#### （1）项目工具
|
||||
- 快速浏览或打开 Godot 工程
|
||||
- 运行 Godot 项目
|
||||
#### （2）AI 工具
|
||||
- 提供 Godot 相关 MCP 服务
|
||||
- 提供与 Godot 编程相关的部分 Skill 能力
|
||||
### 3. MagicAI 架构拆解
|
||||
**整体链路**
|
||||
CodeBuddy IDE 为主入口，串联项目、Godot 引擎、Godot 编辑器，以及 MagicAI 插件提供的 MCP 与 Skill 能力。
|
||||
其工作流程大致为：
|
||||
- CodeBuddy 接收用户输入
|
||||
- 大模型拆解任务
|
||||
- 通过 MCP 和 Skill 驱动 Godot 编辑器能力与代码编写能力
|
||||
**核心价值**
|
||||
- 打通 AI 与游戏引擎编辑器的连接
|
||||
- 让模型具备“写代码 + 操作编辑器 + 调度项目工具”的能力
|
||||
- 体现了 **行业化 AI 编程助手 = 通用 Agent 基座 + 引擎编辑器接入 + 领域 Skill / MCP 增强** 的思路
|
||||
### 4. Godot 生态的意义
|
||||
**参考地址**
|
||||
https://godotengine.org/download/windows/
|
||||
Godot 引擎本体是一个可执行二进制程序，内部同时包含 Godot 编辑器。更重要的是，Godot 是目前市面上少数 **编辑器与引擎核心都高度开放** 的客户端引擎之一。
|
||||
**这意味着**
|
||||
- 更容易做深度工具接入
|
||||
- 更容易为 AI 编程助手定制编辑器操作能力
|
||||
- 更容易围绕真实工作流做技能化、自动化、可干预化增强
|
||||
## 三、其他代表性游戏 AI 产品观察
|
||||
### 1. Astrocade：一句话生成游戏的多智能体路线
|
||||
**产品地址**
|
||||
https://www.astrocade.com/
|
||||
**试玩感受**
|
||||
当前生成出来的大多仍是非常简单的游戏。
|
||||
#### （1）整体技术路线
|
||||
- 自研引擎
|
||||
- 自研 AstroBrain 协调器
|
||||
**AstroBrain 的角色**
|
||||
扮演“AI 总导演”或“中央调度器”的角色，本质上是一个多智能体协同系统，负责理解用户意图、拆解任务、调度专项模型，并保证最终结果一致性。
|
||||
#### （2）多 Agent 分工方式
|
||||
- **planner agent**：负责整体规划
|
||||
- **game logic agent**：负责游戏逻辑实现
|
||||
- **asset agent**：确定需要的图片，并调用大模型生成图片
|
||||
- **animation agent**：确定需要的动画，并调用大模型生成动画
|
||||
- **sound agent**：确定需要的音效，并调用音频模型生成音效
|
||||
- **assembly agent**：收集各部分输出并组装成最终可执行包
|
||||
**判断**
|
||||
复杂游戏内容生成不应只依赖单一代码模型，而应拆成多个专门 Agent 协同完成。
|
||||
#### （3）专项生成模型的意义
|
||||
Astrocade 的关键点之一，是其图像生成并非直接调用通用生图模型，而是围绕引擎要求做专门适配，例如：
|
||||
- 保证图片存在透明通道
|
||||
- 保证风格可控
|
||||
- 保证可微调
|
||||
- 保证输出可直接被引擎消费
|
||||
### 2. Google Project Genie 3：直接生成可交互世界的世界模型路线
|
||||
**核心路线**
|
||||
- 通过扩散模型直接生成视频帧
|
||||
- 根据用户输入实时预测下一帧
|
||||
**特点**
|
||||
- 画面质量极高，逐帧渲染能力强
|
||||
- 理论上可以生成非常丰富的视觉效果
|
||||
- 运行成本极高，需要持续逐帧推理
|
||||
- 物理规则不够精确，扩散模型容易产生幻觉
|
||||
- 持续交互时长与稳定性存在限制
|
||||
**判断**
|
||||
这条路线更像是在探索“可交互世界生成”的上限，而不是短期内可直接落地为标准游戏开发工具的工程路线。
|
||||
### 3. Roblox AI 助手：平台生态内的生成辅助路线
|
||||
**主要定位**
|
||||
- 生成代码片段
|
||||
- 辅助生成 3D 资产
|
||||
**优势来源**
|
||||
- Roblox 已有的庞大资产库
|
||||
- 相对成熟的引擎与内容生产生态
|
||||
- 平台内天然统一的运行环境
|
||||
**局限**
|
||||
- 高度绑定 Roblox 平台
|
||||
- 更适合作为平台能力增强，而不是通用游戏行业 AI 编程助手基座
|
||||
## 四、阶段性结论
|
||||
### 1. 简单游戏可以靠生成完成，复杂游戏仍需要系统协同与人工干预
|
||||
一句话生成游戏在**简单场景**下已具备较强可行性，但一旦进入多界面状态联动、英雄/技能/战斗逻辑耦合、复杂资源组织、长链路错误修复等场景，模型与 Agent 系统就会明显暴露稳定性不足的问题。
|
||||
**结论**
|
||||
复杂游戏开发不能只依赖一次性生成，必须允许人对生成过程做分阶段、可视化、可定位的精准干预。
|
||||
### 2. 面向开发者的游戏 AI 编程助手，关键不只是生成能力，更是生产过程透明可控
|
||||
如果要让 AI 编程助手真正成为生产力工具，而不是演示型玩具，它至少要满足两个条件：
|
||||
- **生产流程透明**：编辑器、引擎、工具调用链路、任务拆解方式尽量开放可见，避免黑箱系统性阻断
|
||||
- **问题可被精准干预**：代码、设计、布局、资源等问题都应允许开发者进行细粒度修正
|
||||
**结论**
|
||||
只有这样，AI 才能进入真实生产流程，而不只是停留在“试玩可行”。
|
||||
### 3. 适合作为行业化基座的AI助手，必须兼具开放性、可控性与可接入性
|
||||
未来若要做面向游戏行业的 AI 编程助手，应优先选择：
|
||||
- 引擎源码与编辑器能力开放的技术体系
|
||||
- 允许接入 MCP、Skill、项目工具与编辑器控制能力的交互底座
|
||||
- 允许人工持续修复、替换与约束的 Agent 架构
|
||||
**判断**
|
||||
这也是为什么 Godot 及其周边生态值得重点关注。
|
||||
## 五、后续拟重点调研的开源通用 AI 编程助手
|
||||
**说明**
|
||||
当前对主流开源通用 AI 编程助手的横向比较尚未正式展开，因此这一部分暂不作为本轮已完成调研内容，而是作为后续重点观察对象保留。
|
||||
**后续拟重点观察对象**
|
||||
- Claude Code CLI
|
||||
- DeepSeek TUI
|
||||
- AtomCode
|
||||
- Crush（by Charmbracelet）
|
||||
- Space
|
||||
- Centaurus CLI
|
||||
- Mylo
|
||||
**后续比较维度**
|
||||
- 工程结构成熟度
|
||||
- 工具扩展能力
|
||||
- Agent 组织方式
|
||||
- 安全与权限机制
|
||||
- 是否适合作为游戏行业二次开发基座
|
||||
## 六、经营策略复盘会的思考
|
||||
真正有价值的不是先设计一个宏大战略再去验证，而是让团队持续贴近市场、快速接触真实反馈，在低成本试错中把“道路”一步步踩出来。
|
||||
核心不是更快生产，而是尽可能消除“灵感 → 原型 → 市场反馈”之间的摩擦，把反馈周期压到极短，用高频试错放大峰值、沉淀长尾，形成真正的产品飞轮。
|
||||
## 七、下一步工作思考
|
||||
**后续推进方向**
|
||||
#### **今日内容概述：**
|
||||
##### 1.调研游戏行业 AI 编程助手产品
|
||||
##### 2.梳理后续重点观察的开源通用 AI 编程助手方向
|
||||
##### 3.参与经营策略复盘会
|
||||
## 一、核心问题与调研目标
|
||||
**核心问题**
|
||||
#### 有哪些主流开源 AI 编程助手，各自具备哪些特点，哪些更适合作为二次开发基座
|
||||
#### 有哪些面向游戏行业的 AI 编程助手产品，它们采用了什么样的产品形态与技术路线
|
||||
**调研重点**
|
||||
从 **可扩展性、可控性、引擎/编辑器接入能力、人工干预空间** 四个维度，判断哪些方向更具落地价值。
|
||||
## 二、游戏行业 AI 编程助手产品调研
|
||||
### 1. 腾讯 MagicAI：面向 Godot 生态的垂直游戏 AI 编程助手
|
||||
**定位**
|
||||
腾讯基于 Godot 生态推出的游戏行业 AI 编程助手，当前重点价值在于打通编程助手、引擎与编辑器能力。
|
||||
#### （1）简单游戏生成体验
|
||||
围绕“飞机大战”小游戏进行测试，使用的提示词如下：
|
||||
**结果**
|
||||
- 移动正常
|
||||
- 攻击正常
|
||||
- UI 显示正常
|
||||
- 整体游玩未发现明显问题
|
||||
#### （2）复杂游戏生成体验
|
||||
围绕“MOBA 小游戏”进行测试，使用的提示词如下：
|
||||
- 帮我做一个 moba 的小游戏
|
||||
- 点击开始游戏没反应，并且在选择英雄界面，除了法师、射手和战士都显示错乱到左上角且缩小
|
||||
- 布局错乱，不能选英雄也无法开始
|
||||
- 启动游戏就显示错乱了
|
||||
- 此外还有这俩报错
|
||||
- 这里布局错乱
|
||||
- 编译报错
|
||||
- 这个界面错乱
|
||||
- 启动后布局显示这样错乱
|
||||
**结果**
|
||||
- 角色移动基本可用
|
||||
- 攻击等核心战斗能力无法正常完成
|
||||
- UI 布局与界面状态多轮错乱
|
||||
- 启动、编译、界面交互等多处存在问题
|
||||
**阶段性判断**
|
||||
- 简单游戏可以，复杂游戏不行
|
||||
- 问题主要来自两部分：
|
||||
- **模型能力限制**：复杂逻辑生成、布局一致性、长程状态维护不足
|
||||
- **Agent 与工具链不够垂直**：即便接入编辑器与引擎，仍缺少更细颗粒度的游戏任务拆解能力
|
||||
### 2. MagicAI 产品拆解
|
||||
**产品形态**
|
||||
MagicAI 本质上是一款运行在 **CodeBuddy（VS Code）插件生态**中的垂直工具，而不是一套独 IDE 或引擎体系。
|
||||
其能力大致分为两部分：
|
||||
#### （1）项目工具
|
||||
- 快速浏览或打开 Godot 工程
|
||||
- 运行 Godot 项目
|
||||
#### （2）AI 工具
|
||||
- 提供 Godot 相关 MCP 服务
|
||||
- 提供与 Godot 编程相关的部分 Skill 能力
|
||||
### 3. MagicAI 架构拆解
|
||||
**整体链路**
|
||||
CodeBuddy IDE 为主入口，串联项目、Godot 引擎、Godot 编辑器，以及 MagicAI 插件提供的 MCP 与 Skill 能力。
|
||||
其工作流程大致为：
|
||||
- CodeBuddy 接收用户输入
|
||||
- 大模型拆解任务
|
||||
- 通过 MCP 和 Skill 驱动 Godot 编辑器能力与代码编写能力
|
||||
**核心价值**
|
||||
- 打通 AI 与游戏引擎编辑器的连接
|
||||
- 让模型具备“写代码 + 操作编辑器 + 调度项目工具”的能力
|
||||
- 体现了 **行业化 AI 编程助手 = 通用 Agent 基座 + 引擎编辑器接入 + 领域 Skill / MCP 增强** 的思路
|
||||
### 4. Godot 生态的意义
|
||||
**参考地址**
|
||||
https://godotengine.org/download/windows/
|
||||
Godot 引擎本体是一个可执行二进制程序，内部同时包含 Godot 编辑器。更重要的是，Godot 是目前市面上少数 **编辑器与引擎核心都高度开放** 的客户端引擎之一。
|
||||
**这意味着**
|
||||
- 更容易做深度工具接入
|
||||
- 更容易为 AI 编程助手定制编辑器操作能力
|
||||
- 更容易围绕真实工作流做技能化、自动化、可干预化增强
|
||||
## 三、其他代表性游戏 AI 产品观察
|
||||
### 1. Astrocade：一句话生成游戏的多智能体路线
|
||||
**产品地址**
|
||||
https://www.astrocade.com/
|
||||
**试玩感受**
|
||||
当前生成出来的大多仍是非常简单的游戏。
|
||||
#### （1）整体技术路线
|
||||
- 自研引擎
|
||||
- 自研 AstroBrain 协调器
|
||||
**AstroBrain 的角色**
|
||||
扮演“AI 总导演”或“中央调度器”的角色，本质上是一个多智能体协同系统，负责理解用户意图、拆解任务、调度专项模型，并保证最终结果一致性。
|
||||
#### （2）多 Agent 分工方式
|
||||
- **planner agent**：负责整体规划
|
||||
- **game logic agent**：负责游戏逻辑实现
|
||||
- **asset agent**：确定需要的图片，并调用大模型生成图片
|
||||
- **animation agent**：确定需要的动画，并调用大模型生成动画
|
||||
- **sound agent**：确定需要的音效，并调用音频模型生成音效
|
||||
- **assembly agent**：收集各部分输出并组装成最终可执行包
|
||||
**判断**
|
||||
复杂游戏内容生成不应只依赖单一代码模型，而应拆成多个专门 Agent 协同完成。
|
||||
#### （3）专项生成模型的意义
|
||||
Astrocade 的关键点之一，是其图像生成并非直接调用通用生图模型，而是围绕引擎要求做专门适配，例如：
|
||||
- 保证图片存在透明通道
|
||||
- 保证风格可控
|
||||
- 保证可微调
|
||||
- 保证输出可直接被引擎消费
|
||||
### 2. Google Project Genie 3：直接生成可交互世界的世界模型路线
|
||||
**核心路线**
|
||||
- 通过扩散模型直接生成视频帧
|
||||
- 根据用户输入实时预测下一帧
|
||||
**特点**
|
||||
- 画面质量极高，逐帧渲染能力强
|
||||
- 理论上可以生成非常丰富的视觉效果
|
||||
- 运行成本极高，需要持续逐帧推理
|
||||
- 物理规则不够精确，扩散模型容易产生幻觉
|
||||
- 持续交互时长与稳定性存在限制
|
||||
**判断**
|
||||
这条路线更像是在探索“可交互世界生成”的上限，而不是短期内可直接落地为标准游戏开发工具的工程路线。
|
||||
### 3. Roblox AI 助手：平台生态内的生成辅助路线
|
||||
**主要定位**
|
||||
- 生成代码片段
|
||||
- 辅助生成 3D 资产
|
||||
**优势来源**
|
||||
- Roblox 已有的庞大资产库
|
||||
- 相对成熟的引擎与内容生产生态
|
||||
- 平台内天然统一的运行环境
|
||||
**局限**
|
||||
- 高度绑定 Roblox 平台
|
||||
- 更适合作为平台能力增强，而不是通用游戏行业 AI 编程助手基座
|
||||
## 四、阶段性结论
|
||||
### 1. 简单游戏可以靠生成完成，复杂游戏仍需要系统协同与人工干预
|
||||
一句话生成游戏在**简单场景**下已具备较强可行性，但一旦进入多界面状态联动、英雄/技能/战斗逻辑耦合、复杂资源组织、长链路错误修复等场景，模型与 Agent 系统就会明显暴露稳定性不足的问题。
|
||||
**结论**
|
||||
复杂游戏开发不能只依赖一次性生成，必须允许人对生成过程做分阶段、可视化、可定位的精准干预。
|
||||
### 2. 面向开发者的游戏 AI 编程助手，关键不只是生成能力，更是生产过程透明可控
|
||||
如果要让 AI 编程助手真正成为生产力工具，而不是演示型玩具，它至少要满足两个条件：
|
||||
- **生产流程透明**：编辑器、引擎、工具调用链路、任务拆解方式尽量开放可见，避免黑箱系统性阻断
|
||||
- **问题可被精准干预**：代码、设计、布局、资源等问题都应允许开发者进行细粒度修正
|
||||
**结论**
|
||||
只有这样，AI 才能进入真实生产流程，而不只是停留在“试玩可行”。
|
||||
### 3. 适合作为行业化基座的AI助手，必须兼具开放性、可控性与可接入性
|
||||
未来若要做面向游戏行业的 AI 编程助手，应优先选择：
|
||||
- 引擎源码与编辑器能力开放的技术体系
|
||||
- 允许接入 MCP、Skill、项目工具与编辑器控制能力的交互底座
|
||||
- 允许人工持续修复、替换与约束的 Agent 架构
|
||||
**判断**
|
||||
这也是为什么 Godot 及其周边生态值得重点关注。
|
||||
## 五、后续拟重点调研的开源通用 AI 编程助手
|
||||
**说明**
|
||||
当前对主流开源通用 AI 编程助手的横向比较尚未正式展开，因此这一部分暂不作为本轮已完成调研内容，而是作为后续重点观察对象保留。
|
||||
**后续拟重点观察对象**
|
||||
- Claude Code CLI
|
||||
- DeepSeek TUI
|
||||
- AtomCode
|
||||
- Crush（by Charmbracelet）
|
||||
- Space
|
||||
- Centaurus CLI
|
||||
- Mylo
|
||||
**后续比较维度**
|
||||
- 工程结构成熟度
|
||||
- 工具扩展能力
|
||||
- Agent 组织方式
|
||||
- 安全与权限机制
|
||||
- 是否适合作为游戏行业二次开发基座
|
||||
## 六、经营策略复盘会的思考
|
||||
真正有价值的不是先设计一个宏大战略再去验证，而是让团队持续贴近市场、快速接触真实反馈，在低成本试错中把“道路”一步步踩出来。
|
||||
核心不是更快生产，而是尽可能消除“灵感 → 原型 → 市场反馈”之间的摩擦，把反馈周期压到极短，用高频试错放大峰值、沉淀长尾，形成真正的产品飞轮。
|
||||
## 七、下一步工作思考
|
||||
**后续推进方向**
|
||||
Reference in New Issue
Block a user