Evilom
17 KiB
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 组织方式
- 安全与权限机制
- 是否适合作为游戏行业二次开发基座
六、经营策略复盘会的思考
真正有价值的不是先设计一个宏大战略再去验证，而是让团队持续贴近市场、快速接触真实反馈，在低成本试错中把“道路”一步步踩出来。 核心不是更快生产，而是尽可能消除“灵感 → 原型 → 市场反馈”之间的摩擦，把反馈周期压到极短，用高频试错放大峰值、沉淀长尾，形成真正的产品飞轮。
七、下一步工作思考
后续推进方向