MGX 功能体验分析

简述

所执行的任务：让 MGX 创建一个工具类网站，用户可以通过上传一些图片来创建漫画电子书文件，并借助一些 AI 工具进行漫画的优化，例如设计封面等工作。

Prompt:

Help me create a tool type website, user can upload images and create a comic ebook file, like epub/mobi/azw3.

Here is main userflow:
1. user picker some images with serial filename, such as 1.jpg, 2.jpg, etc.
2. user upload images into website, and select a format of ebook, then website begin to create.
3. after or during the ebook generating, user can input extra informations for this file, like author, series name, etc. Those information should be written into the file.
4. User also can call GPT4o to create this comic file's thumbnail base on one image uploaded before. For example, coloring one image, and add comic's name, base on prompt user given or website preset. 
5. After file is generated, user can share this file by email or common social app, or download directly.

If anything you not understand, free to ask!

而在这次体验的过程中，我发现并记录了一些问题，分别关于：

主流程体验、首页结构、商业化路径、AI 对话范式

我将简要阐述这四个方面的问题

评估方法简述

在正式开始之前，还是先大概说一下每一个问题分析的方式，便于读者理解。

1. 我会先站在一个用户的视角，描述问题发生场景时用户的主要行为，以及他核心的期望。
2. 然后指出在产品呈现给用户的部分中，有哪些地方和用户的期望些许违背。
3. （可能会）引用一些适用的设计理论或者方法论。
4. 提出修改的方案，并明确预期的效果和可以核查的手段。

问题一：在 主流程体验 中

先抛出问题，与 AI 团队沟通时，有很强的割裂感，似乎在前半部分和后半部分在使用不同的产品。

通俗一点说，就是我作为一个甲方，在和 AI Team 沟通的过程中，主要沟通的方式是和 Team Leader 以及 Product Manager 进行沟通，这个是我这次体验中主要的反馈来源；而后续与 Architect、Engineer、Data Analyst 的沟通则偏少而且比较困难，因为是这三位是以代码为主。

所以现状就是：

首先，占据我大部分的精力的，与 Team Leader 和 Product Mananger 的沟通，我会花比较多的精力和时间，认真的去和两位 AI 进行沟通。但是在沟通的过程中两位似乎都非常着急的要将任务交付给 Architect（可能和算力紧张有关？），即使我自己觉得我还没有将信息完全说明清晰，希望能有进一步的沟通。

其次，当任务进入到开发流程后，此时 Architect 和 Engineer 开始工作，任务开始集中在右侧部分，此时我能做的事情已经比较少了，大部分时间只有等待而已。即使我试图理解右侧的产出内容，对于 non-coder 的我来说，也有着不小的难度。

上图是一个很经典的用户行为模型，描述了用户的行为从产生到执行到反馈的完整流程。重点关注“明确意图”这一部分，在过往的工作经历中，我发现意图的明确也是一件非常困难的事情，直白一点说就是“将事情想清楚说清楚”这个能力，在职场上也是非常稀缺的，这也是为什么大公司都会有一些明确的规章制度来确保基础的沟通。

而基于上图的这个模型，我对 main userflow 这个体验 case 给出的建议是：分离 Team Leader 和 Product Manager，并弱化 Architect、Engineer、Data Analyst 方面的产出展示。

我将完整的 Userflow 先拆分成三个阶段：

1. 需求明确阶段

这一部分用户需要通过与 TL、PM 的多轮沟通，逐渐明确自己的需求。

在用户界面上，我建议移除右侧部分。类似 IDE workspace 的界面虽然方便 Coder 组织文件，但是在需求明确阶段时，显得有些多余。该阶段还是应该以聊天界面为主，可以尝试 Claude 和 Manus 的方式，聊天界面+可扩展的画布

产出的部分直接添加在聊天记录中，更加符合企业 IM 的使用方式。也就是更加注重沟通本身，将注意力集中在沟通的内容上，以文档作为辅助。

总之，将 TL 和 PM 角色暂时从团队中分离，以侧重对话的方式，在需求明确阶段来辅助用户。

至于如何更好地辅助用户，一会会在问题 AI 对话范式 中给出。

2. 需求实现阶段

我希望在这个阶段，用户可以间隔性的追踪开发团队的任务进度。

首先我们必须考虑 non-coder 的用户，因为即使是对 Coding 略有涉猎的甲方用户，也很难有耐心的将 Workspace 中生成的代码一一看完。在我自己的 Case 中，当需求进入到“需求实现阶段”后，我更加关心的是这三位 AI 是如何一步步的去实现我的需求的，而非具体的代码实现。

在上一阶段中提到的用户行为模型，也可以适用于这一个阶段的设计，也就是其中的“感知结果”到“评估并理解”过程。

Architect 可以在自己一开始划分了实现结构的基础上，在每个小结构实现完成后，提供可验收的方式验证功能的实现效果，并分阶段的展示给用户。这样可以让用户更加关注阶段性的产出结果，并及时的干预，动态的调整编码结果。甚至当用户有了深度参与的感受后，也可以及时的调整自己的心里预期，让最后的产出更加精确。

界面结构上可以沿用现在的，不需要太大的调整。

这个 AI 交互的方式其他产品也已经用上了，Cursor 就是一个很好的例子。

虽然是一个很小的需求，但是 cursor 依然在构建的过程中临时生成了一些阶段性的代码，方便我了解目前是什么样的一个进度，并在方向跑偏时及时纠正。

Manus 其实也有类似的交互，不过我是在一次直播中看到的，实在找不到截图了。

3. 需求 iterate 阶段

iterate 直接翻译成迭代好像不太合适，总之是在产品完成后，进行再次调整以使结果更加贴近自己预期的阶段。

还没走到这一步我的 quota limit 就触发了，接下来会以 App world 中的例子为依据。

这部分说的简单一些，因为我也没有实际走到这个阶段。

这个阶段应该是所有人都能参与的，所以页面布局沿用上一个节点的即可。

对于成品的反馈理应是非常直观的，因为此时用户将成品对比的，是自己脑子中的预期产品，将两者的样子进行对比。

我建议可以尝试一下让用户直接在 Viewer 上画圈，并提出修改意见进行修改。让 AI 根据这种反馈来决定应该如何修改。例如，上图中我希望可以修改一下棋盘上方的按钮排布方式，可以直接圈定按钮区域然后使用 prompt 告知 Alex 调整前端。

几个可以参考的产品例子是，Figma 的画圈评论和 三星手机的圈定即搜，虽然并不是 AI 产品，但足以证明画圈指定范围是人类最自然的交互方式。

问题二：在 首页结构 中

参考竞品：Bolt.new、Lovable、Manus(网络截图)

两个核心的问题，认知负荷 和 功能清晰度。

我先明确一下 Persona，应该是一个试图使用低成本完成一些目标的普通用户，有一些编程技术但并不是特别擅长。

而 MGX 这个产品，核心主打的是一个 AI Software Develop Team，目前还是主要面向软件开发领域。无论是 Product Hunt 还是 Github 上的宣传，基本都是围绕这一类的需求。
那么目标用户进入网站后的预期就很明确，即通过自然语言对话的方式创建出自己想要的那个产品。

接下来结合一下当前的页面，我解释一下之前提到过的两个核心问题。

认识负荷

首页包含了许多相互竞争注意力的元素，应该适当整理，移除或重新设计与目标用户的预期相关性第的元素。

解决的方案是突出 Slogan 的设计，Slogan 是用户首先注意到的内容，也是在第一时间告知用户这个产品能做的事。在现在这个马天都有 AI 新产品推出的情况下，Slogan 的重要程度不言而喻。

当前的 Topic 是认知负荷，所以不会去详述如何修改 Slogan，我会说一些页面结构上的调整。

1. 比如 Product Hunt 标志。

Product Hunt 的确是重要的引流方式，但是也并非所有的流量都从 PH 中获得，对于其他用户，这部分的元素占据了顶部的位置，影响到了主 Slogan 的表达，后者相对来说更加关键。我建议保留一个 PH 标志（金牌的那个比赞同数的更优质），位置移动至右上角，可以使用”🏅#1 Product Hunt“ 这样的标志，既能表示荣誉，又不会影响到 Slogan。

2. 然后是输入框下方，以 Dashboard 为例的一种特色功能，我建议是直接移除。

回到目标用户的预期，“通过自然语言对话的方式创建出自己想要的那个产品”，下方的“特色功能”们会传递“要选择一个目标开始才能有更好的效果”这种意思，从而弱化产品的 AI 属性，而且，更是有着 Blog、PPT、Doc 这些和软件开发领域几乎毫无关系的模板功能。我记得我第一次进入的时候，都要花点时间想想这个和 AI Team 有什么关系。

可以考虑使用 prompt 模板的方式直接展示功能，这样可以强调自然语言对话这种特色，让产品更有 AI 感。

这里有一个正面的例子，Bolt.new。既使用不影响 Slogan 的方式展示一些信息，同时也使用了 prompt 模板的方式展示功能。

可以看到整个页面都让用户的注意力集中在 Slogan 上了

功能清晰度

“特色功能” 们移除后，其实就可以对功能清晰度有较大的提升了，不过还可以从一些其他地方提升。

• 比如输入框中的文案可以更加的自然，少用一些 #@ 之类的符号。
• 提供 Prompt 输入范式，例如让用户提供 Tast, Context, 甚至 References.
• App world 侧重社区属性，将 My App 和 My Likes 移动到别处，例如个人中心。

问题三：在 商业化路径 中

前两个问题占据了比较大的篇幅比较冗杂，接下来我会加速一些，简略的进行描述。

期望：选择一个既能实现我当前开发工作需求，又比较实惠的方案

现状：并不清楚 Plans 中的 Credits 的体量。虽然有通过每日的免费额度进行尝试，但是额度太低也无法估计完整项目所需用量。

解决方案：

1. 在当前页面提供一些方案示例，并附上方案所需的 total credits，便于用户进行参考。也可以借助一个免费的低成本 AI 对项目进行预估。
2. 提供方案之间的转换方式（如果已提供，在页面中明显进行标识），用户可以在实际的订阅过程中进行转换。

问题四：AI 聊天范式

这部分应该算是“主流程体验”的延伸，因为不是其中主要的问题，所以还是单独开一个问题来写。

期望和现状：

目前 AI 聊天中，还是有很强的 AI，或者说 GPT 即视感，也就是我问什么，对方回答什么，然后直接开始执行。而和真实同事沟通的时候，往往是有来有回的，也就是我提出话题，对方进行引申或者质询，然后在沟通过程中逐渐将问题和解决方案进行明确。

如果直接通过单次沟通就开始，不仅不会让人感到效率，反而会让人觉得很没有安全感。如果以实际公司中的场景举例的话，就是招了一个工作很积极但是沟通能力差的人吧，作为上司是不放心把工作交给他的。

解决方案：

可以考虑搭建起来一套 AI 对话的范式，对一些用户沟通过程中容易出现的沟通问题进行确认。

可以参考 Ant Design X 设计团队的 RICH 范式 ，在这个基础上进行调整。

思考题

1. 为什么多智能体产品比单智能体更具优势？

抛开技术上的优势，比如不同智能体可以通过微调或 Rag 在不同领域进行优化、或是分摊 Context 来支持更长的上下文。

我重点说一下在用户认知方面的优势：

• 更加接近于用户的心智模型，减少用户的学习成本。

根据不同的职能划分的多智能体更像是公司里面的组织结构。在所产生的产品出现问题时，用户能够清晰的知道应该去找到哪个角色（智能体）并以合适的方式提出意见。例如如果目标受众和实际受众有偏差，就需要找产品 Emma 让其重新拟定用户画像；若是前端页面效果不好，则直接找到工程师 Alex 要求调整页面。这样相比于直接和单个 AI（比如 Mike 进行沟通）会更加有效率。

更进一步的是，可以对多智能体进行拆解，直接无缝融合到现有的公司结构中，当然这是后话了，目前 Devin 在做这样的事，不过效果还不是很好。

• 降低复杂任务的决策难度

几乎没有甲方用户可以在一开始就将任务完全构思清晰，产品都是一步步打造出来的。而将 AI 产品以多智能体的方式呈现给甲方用户，相当于是强迫用户去进行分阶段地专注思考，比如先和产品经理聊清楚需求，然后再和 Architect 聊怎么实现。

用户和 AI 这样一步步走下来，也是一个对齐的过程，会让最终的产出更加符合用户的预期。

2. 对于 MGX 中的不同角色，你认为有哪些可优化的 Feature？

这个似乎在“主流程体验”和“AI 聊天范式“中均已有涉及。

这里跑个题，说一下“不同角色”这一部分吧，而且也是说说我个人的问题，可能不具备普适性。

我希望能给予用户手动调整团队结构的能力。

我作为一个独立开发者，会有很多零散的小需求，这些小需求通常都是一些能力的验证，例如 OpenAI 出了一些新能力，可能我需要做一个小网页快速接入 API 进行一下体验，这种情况下我只需要有 PM 帮我理一下需求，然后 Engineer 帮我写一个原型就可以了，写出来一个原型能验证能力即可。

我目前使用 Cursor 完成这一件事情，并在完成 Demo 后，自己手动开始实现 Architect，因为 Cursor 目前的 Agnet 还无法支持完整的项目。

所以我设想，如果 MGX 可以有一种自定义团队的方式，先进行 Demo 验证。并在完成后，开始调入 Architect 这样的角色进行进一步的实现，在使用上应该会更加的灵活。