MGX体验实录——理想与现实的差距

一、背景

近期，一款名为MGX（MetaGPT-X）的多智能体开发平台引发热议。其核心亮点在于：用户仅需用自然语言描述需求，即可通过平台生成完整的产品文档、技术文档和代码。社交媒体上已有不少案例展示------从小游戏到数据看板，许多功能简单的应用甚至能在几分钟内完成开发。这一特性吸引我亲自体验它的能力。

一、MGX简介

MGX具有以下特性：

全流程自动化开发：覆盖软件开发的全生命周期，包括需求分析、技术设计、编码实现、测试验证和部署上线。
多智能体协作：
- Emma（产品经理）：提炼用户需求，生成详细的产品需求文档（PRD）。
- Bob（架构师）：设计可用的技术方案，绘制软件架构图。
- Alex（工程师）：根据设计高效生成代码，支持主流开发框架。
- David（数据分析师）：实时分析数据，优化产品决策。
- Mike（团队领导）：统筹全局，协调各代理工作，确保项目按时交付。
自然语言编程：用户用自然语言描述需求，MGX 自动解析启动开发流程，无需用户具备编程技能。

以下为官网（ mgx.dev/ ）界面，UI非常简洁：

二、收费模式

版本	价格	权益描述
免费版	每月免费	每天 750,000 额度每月 250 万额度每次聊天最多 5 条用户消息
Pro 20	每月 20 美元	完全支持所有高级功能每月 1000 万额度
Pro 70	每月 70 美元	完全支持所有高级功能每月 3500 万额度
Pro 200	每月 200 美元	完全支持所有高级功能每月 1 亿额度
Pro 500	每月 500 美元	完全支持所有高级功能每月 2.5 亿额度

试用了Pro 20版本，实际体验下来成本有点高。需求稍微复杂些，调试次数多些，token消耗就特别快，导致需求还没开发完，额度就用完了。

三、生成结果展示和对比

场景1：简单Prompt输入

既然网上已经有不少一句话开发的案例，那么我也先尝试用比较简单的自然语言描述一个有一定复杂度的需求。

指令：

魔法学院学生需要依次通过所有选修学科的长老审核，并由授勋委员会授予勋章，方可毕业。每个学生至少选修了一个学科。学科为魔药学、占卜学、魔法史、炼金术。做一个魔法学院毕业系统，作为毕业申请全流程管理平台，涵盖申请发起、多角色审核、状态流转、权限控制等功能。

耗时：约45分钟
- Emma分析需求和编写产品文档：10分钟左右
- Bob进行系统架构设计：5分钟左右
- Alex进行代码开发：30分钟左右
输出
- 产品文档：包括产品定义（甚至有竞品分析和竞品象限图）、用户角色分析、功能需求、流程设计、界面设计、技术架构、实施计划、开放问题几个部分，看起来很完整，总体流程与外界常规申请流程相似，但显然存在不可信的部分，比如竞品分析和竞品象限图一定是随便编的
- 系统设计：包括系统架构设计、数据库设计、接口设计、时序图等
- 代码：只有前端代码，使用React框架实现，与后端接口有关的部分全部使用了mock数据

主要页面的最终实现情况：
- 登录页：常规的登录页样式，但登录按钮的背景颜色和文本颜色太浅，容易被忽略
- 学生角色发起申请：整体UI风格较简洁，细节处样式有瑕疵，且勾选框无法勾选，导致无法发起申请流程
- 数据看板：UI风格与其它页面统一，但暂无数据
- 此外，导航栏还存在一些PRD中没有提及的页面，进入页面时会显示尚未开发的文案

场景2：完整PRD输入

复杂的审批流和状态-角色-按钮间对应关系是业务的痛点之一，因此我设计了一个类似的魔法学院毕业申请流程，将编写好的prd作为输入，看看MGX有何表现。

指令：

魔法学院学生需要依次通过所有选修学科的长老审核，并由授勋委员会授予勋章，方可毕业。

文档内容是魔法学院毕业申请系统的主要流程，实现这个流程的全部功能，并补充登录流程，完成魔法学院毕业申请系统，不需要添加其他扩展功能。前端需要使用 Vue3+TypeScript+Vite 实现。

耗时：约30分钟
- David分析输入的说明文档：约1分钟
- Emma编写产品文档：2分钟~15分钟（虽然输入了需求明确的说明文档，但最初编写的产品文档依然改变和省略了一些需求，沟通调整了4次才符合预期）
- Bob进行系统架构设计：约10分钟
- Alex进行代码开发：5分钟（虽然很快就开发完了，但是登录进去就白屏了）
输出：
- 分析报告：将输入的说明文档转换成json的格式，内容与说明文档基本相符合
- 产品文档：包括项目信息、产品定义（竟然依然有竞品分析）、系统角色定义、功能模块说明、业务流程、技术规范、其他说明（性能要求、安全要求）、流程状态与操作权限（初版PRD无此部分，补充后又调整了几次才符合预期）
- 系统设计：包括系统架构设计、数据库设计、接口设计、时序图等
- 代码：依然只有前端代码，按要求使用Vue3框架实现
  - 另外，提这个需求，主要目的就是看看AI面对这种按钮权限比较复杂的情况会怎么处理，下载代码之后发现，真是简单粗暴的处理啊
主要页面的最终实现情况：
- 登录页：常规的登录页样式
- 列表页：没有展示列表想要继续debug时，发现20刀的额度竟然也已经用完了，这20刀哪里是充给MGX的，分明是插我心上的！
修复后的主要页面展示：下载代码并运行后，查看控制台发现原因竟然是没有引入computed

引入computed后，发现主要页面基本可以展示出来
- 列表页：缺少了产品文档有要求的一系列搜索框；撤销按钮无法点击，详情和新建申请可以点击
- 编辑页：表单交互基本正常；缺少了产品文档里有提及的选修专业模块的表单；产品文档里要求按钮为保存草稿和提交，实际实现却是取消和保存
- 详情页：所展示的字段与编辑页对应；无法返回列表页

四、优缺点深度分析

由此可见，MGX确实有以下优点：

对于比较简单常规的需求，可以快速完成开发（如众多网友分享的案例所示）
对于有一定复杂度的需求，可以快速生成demo
如果没有具体明确的需求，只是有一个想法，Emma也能按照常规的情况分析完善需求、生成产品文档，进行进一步开发

但是它的缺点也同样突出：

输入明确的需求时，有可能会擅自更改需求
虽然耗时短，但只是一个半成品的前端demo，后端接口都是mock数据
bug太多，预览效果时反复出现找不到引用的模块等错误，需要多次调试
token消耗太快了，特别是在反复调试bug时
对于比较复杂的需求，实现方式依然比较粗暴，这一点可能可以通过继续调试得到改善，但已经没有额度了
没有负责UI设计的智能体，目前看来页面的UI没有太大的亮点
没有负责测试的智能体，有时它提供的预览页面明明无法运行且弹出了报错信息，它却声称开发已经完成，请我开始验收
除了团队领导Mike与其它智能体有沟通，其它智能体之间并不会相互交流；Mike也仅仅接收其它成员的完成状态，不会把关它们实际的完成质量。这与现实的团队协作还是有较大差距

五、总结

AI的"创造性"是把双刃剑：可以帮助用户完善想法，但也可能"顺便"改掉用户的需求
成本陷阱：AI是不可控的，成本的消耗难以预料，甚至可能远超预期
人类具有不可替代性：目前为止，人类对各种明确或不明确的需求都能理解得更充分，而且稳定性更高

不可否认的是，MGX等AI仍是非常优秀的辅助工具，而且正在以难以预料的速度飞速成长。作为人类，我们要紧跟时代的脚步，积极拥抱AI，学会高效省钱使用AI；同时也不要妄自菲薄，更强的交流和理解能力以及稳定的逻辑思维依然是我们不可替代的竞争力。