用 MiniMax M3 来 Coding 实在太顶了！我让它接手了真实项目开发

熟悉我的朋友应该都知道，这一年我基本已经把 Vibe Coding 当成了主要开发方式。截至目前，我已经通过 AI 上线了 6 个产品，分别是 3 个小程序和 3 个网页应用，其中有些产品已经获得了 9000 多名用户。

最近 MiniMax 发布了 M3。如果用一句话概括，我觉得它最大的特点是：国产开源模型终于集齐了过去只有顶级国外模型才有的“三件套”：Coding、百万级上下文和原生多模态。过去能同时做到这三件事的基本都是 Opus、GPT、Gemini 这类顶级闭源模型，而 M3 是目前国内第一个把这三项能力同时带到开源世界的模型。

从上面的数据可以看到MiniMax M3 不只是会写代码。在官方测试中，它的 Coding 能力已经达到全球第一梯队水平，同时在图片、文档理解以及 Agent 自主执行任务等方面也表现非常亮眼。对于开发者来说，这意味着它不仅能写代码，还能看懂内容、理解需求，并持续把任务做完。

这次测试我直接选择了 MiniMax 自家的 MiniMax Code。原因很简单，MiniMax Code 本身就是专门为 M3 设计，并且与 M3 一起训练的 Agent 产品，可以说是目前最能发挥 M3 能力的官方搭档。

相比单纯测试模型本身，我更想看看 M3 在真实 Agent 场景下的表现。MiniMax Code 并不只是一个代码生成工具，它更像一个 AI 开发团队。面对复杂任务时，它会自动拆解任务、规划步骤，并由多个 Agent 协同推进。在执行过程中不断检查结果、反思问题、修正方案，而不是生成一次代码就结束。

同时它还具备超长上下文、多步骤推理以及原生多模态能力，不仅能够写代码，还能理解图片、分析视频、操作电脑，甚至跨应用完成任务。最近 MiniMax Code 还引入了 Agent Team 工作流，可以让多个 Agent 共同完成长程复杂任务。

我准备用三个真实开发场景，看看 M3 到底能不能像一个真正的工程师一样参与开发。

Case 1：我给它一段网站录屏，让它复刻整个交互

如果你经常用 AI 写代码，应该会有一个共同感受。现在让 AI 写个后台管理系统、做个表单页面、实现一个 CRUD 功能，其实已经没什么难度了。真正难的是那些让人眼前一亮的页面，比如苹果官网首页，最有价值的地方往往不是功能，而是交互体验。问题在你很难准确描述出来。很多时候你会发现自己陷入一种很尴尬的状态：

你知道自己想要什么。但你不知道该怎么告诉 AI。最终做出来的效果还是和原版差很多。我认为这是目前 Vibe Coding 最大的瓶颈之一。因为很多设计感和交互感本身就是动态的。它根本无法通过几句话完整描述出来。

所以这次我决定反过来测试，我没有写详细 Prompt，没有拆解页面结构，也没有告诉它动画应该怎么实现，而是直接录制了一段网站操作视频发给 MiniMax Code，让它使用多模态大模型去理解这个视频效果，然后复刻出来。

让它根据视频内容进行复刻，这个测试看似是在考验前端能力，实际上考验的是多模态理解能力，因为模型首先要看懂视频，理解页面结构，理解交互逻辑，理解动画之间的关联关系，然后再转化成代码实现。

这个网站本质上就是把滚动网页做成了动画片的感觉，你每滚一下鼠标，页面里的文字、颜色和场景都会跟着动起来，像在看一部可以自己控制进度的短片。难点在于让几十个动画跟着滚动丝滑同步、不卡顿、还看起来高级。

最终生成的结果让我比较惊喜，它不仅还原了页面布局，也还原了大部分交互逻辑和动画效果。过去很多模型宣传多模态能力的时候，本质上是在展示识图能力，比如识别图片里的文字，识别图片里的物体。

但对于开发者来说，这些能力其实并不是最重要的。真正有价值的是：能不能理解动态内容，能不能理解交互，能不能把视频直接转化成产品。如果这一点能够成立，那么未来设计稿、录屏、竞品网站都可以直接成为开发输入，这将大大降低了普通人做出优秀产品的门槛。

Case 2：从一句话开始，让它帮我设计并开发完整产品

过去一年我通过 Vibe Coding 做了 6 个产品。最大的感受其实不是 AI 写代码越来越快了。

而是我发现：产品开发最耗时间的环节根本不是写代码。而是想清楚要做什么，很多人以为创业者的一天都在写代码。实际上大部分时间都花在需求设计上，一个产品从想法到上线，中间要经历需求分析、功能规划、页面设计、交互设计、数据库设计、接口设计以及最终开发，而写代码只是最后一步。

所以这次我故意没有给 MiniMax Code 完整需求，只给了一句话：

帮我做一个AI智能体创建平台，支持创建智能体、分享智能体，使用智能体等。
做个最简单的MVP本地版，模型用MiniMax M3模型。

剩下的全部交给它自己完成，包括需求补全、页面设计、产品逻辑以及最终开发。因为我想测试一个问题：它到底只是一个程序员，还是一个能够参与产品设计的 Agent。

在执行过程中，我发现它并没有急着开始写代码，而是先主动分析我的业务目标，并针对一些关键细节向我发起追问。比如目标用户是谁、核心功能是什么、希望解决什么问题，以及一些具体的交互需求。

当我补充完这些信息后，接下来发生的一幕让我有点意外。它并不是像传统 AI 那样自己埋头干活，而是自动组建了一个“AI研发团队”。

我能看到多个 Agent 开始并行协作：有前端工程师负责页面设计和交互实现，有后端工程师负责接口和业务逻辑，还有专门的 Agent 负责产品规划、任务拆解和代码审查。每个 Agent 都承担着不同职责，同时推进项目开发。这种感觉很像一家创业公司的研发团队在开会分工。需求被拆解成多个子任务后，由不同角色分别负责，再将结果汇总回来，而不是所有事情都由一个 Agent 从头做到尾。

以前的 AI 更像一个程序员，而 MiniMax Code 给我的感觉更像一个研发团队。

从交付结果上来看，它考虑得非常周全。无论是 AI 智能体的创建页面，还是后续的使用体验，都能看出经过了大量打磨。

在创建环节，它为了降低用户门槛，提供了多个不同分类的提示词模板，即使是完全没有接触过提示词的新手，也能快速上手创建属于自己的智能体。在对话体验上，开场白和预设问题的设计也恰到好处，能够帮助用户快速进入场景，而不是面对一个空白对话框不知从何开始。

更让我意外的是一些细节处理。比如回复过程中的打字机效果、思考状态和输出状态的展示，以及历史对话记录的管理方式，都让整个体验更接近一个成熟的产品，而不是单纯把模型能力套了一层界面。包括智能体列表页的展示逻辑、信息层级和交互细节，也能看出这个AI团队对于开发者实际使用场景有比较深入的理解。很多地方看似不起眼，但真正做过产品的人都知道，这些细节往往比功能本身更难打磨。

我一直认为未来 AI 编程的发展方向并不是让程序员写代码更快。因为代码本身迟早会变得越来越廉价。真正昂贵的是需求理解能力。谁能更准确理解用户需求，谁就更接近产品本身，所以未来最有价值的模型，不一定是代码写得最好的模型。而是最懂产品的模型。

Case 3：在我的老项目里增加《给阿嬷的情书》同款侨批生成器

三个案例里面，我认为这个案例最有代表性。

因为它最接近真实开发。很多人展示 AI 编程的时候，喜欢从零开始做项目。因为这样最容易出效果，但现实世界里的开发并不是这样。绝大多数开发工作其实都发生在老项目里，修改需求，增加功能，修复 Bug，优化体验。这些才是开发者每天真正面对的事情。

所以这次我没有让它重新做一个新项目，而是把我之前上线运营的「马上表白」小程序直接交给它。

我这个小程序一共有三个模块：表白、约定、贺卡。

然后提出一个需求：把最近很火的电影《给阿嬷的情书》同款侨批生成器整合进去。

看起来只是增加一个功能，实际上难度非常高，因为它需要先理解整个项目，理解项目的目录结构，理解现有组件。理解页面设计风格，理解业务逻辑，理解用户体验，然后再决定应该把新功能放在哪里。

如何与现有功能融合，如果处理不好，很容易出现一种违和感，新功能像后来硬塞进去的一样，页面风格变了，代码结构乱了，交互习惯也变了，这也是很多 AI 在老项目场景下容易翻车的地方。

当我把需求交给它之后，它并没有像大多数 AI 那样直接开始写代码，而是先对整个项目进行了一轮“摸底”。

它先分析了项目的整体结构，了解当前有哪些业务模块、采用了什么技术栈、页面之间是如何组织的，甚至还会进一步阅读具体的方法和函数实现，试图理解现有代码的设计思路。

这个过程让我感觉它更像一个刚加入团队的新工程师。正常情况下，一个有经验的开发接手老项目，也不会上来就开始改代码，而是会先花时间了解项目背景、业务逻辑和代码结构，避免因为不了解上下文而造成破坏性修改。

在完成项目分析之后，它才开始制定改造方案，并逐步实现《给阿嬷的情书》同款侨批生成器功能。

最终的结果让我比较满意。它没有单独新增一个突兀的功能入口，而是把侨批生成器放到了原有的「表白」模块中。这个设计其实很符合产品逻辑，因为无论是表白信还是侨批，本质上都属于情感表达和信件创作场景，用户认知成本非常低。

更让我惊喜的是细节处理。新增功能并没有采用一套全新的设计语言，而是主动沿用了项目原有的视觉风格和交互模式。包括页面布局、按钮样式、转场动画以及生成过程中的反馈效果，都与原来的表白功能保持一致。

整个过程给我的感觉不是“新增了一个功能”，而更像是把原本就应该存在的功能补了回来。从代码层面来看，它也没有推倒重来，而是在理解现有项目的基础上进行扩展。组件复用比较合理，目录结构没有被破坏，新增代码与原有工程能够自然融合。

我一直认为，判断一个模型 Coding 能力的标准，不是看它能不能从零写出一个项目。因为现在大部分顶级模型都已经能做到这一点。

真正困难的是接手一个已经运行很久的项目，然后在不破坏现有体验的前提下持续迭代。因为这背后考验的不只是代码生成能力，而是对业务、架构、设计和上下文的理解能力。而这恰恰也是未来 Agent 最重要的价值之一。

相比从零创造，我认为理解和继承往往更难。而这次 MiniMax Code 在老项目改造上的表现，确实让我看到了它在工程化场景中的潜力。

Token Plan

除了模型本身，这次让我比较意外的还有 MiniMax 的 Token Plan，主打便宜，量大，管饱。

说实话，现在很多开发者用 Agent 最大的顾虑不是模型能力，而是成本。尤其是长上下文、多轮推理、复杂 Agent 任务，一跑起来 Token 消耗非常快。

这次 MiniMax 同步推出了三档 Token Plan：

• Plus：49 元/月，包含 6 亿 Token
• Max：119 元/月，包含 18 亿 Token
• Ultra：469 元/月，包含 55 亿 Token

如果和 Claude 同价位套餐对比，Token 用量大约能做到 15 倍左右。对于经常写代码、跑 Agent、做 Vibe Coding 的开发者来说，这一点还是挺有吸引力的。毕竟很多时候限制我们使用 AI 的不是能力，而是成本。

最后

过去一年，我通过 Vibe Coding 上线了 6 个产品。从最开始连前端都不会写，到现在能够独立完成产品设计、开发和上线，我最大的感受是：AI 正在快速抹平技术门槛。

但随着越来越多模型都会写代码，一个新的问题也出现了。未来比拼的可能已经不是谁生成代码更快。而是谁更懂需求、更懂项目、更懂协作。这次测试下来，MiniMax M3 给我最大的感受是它开始具备了一些“工程师思维”。

它能够看懂视频里的交互逻辑，能够从一句话中理解产品需求，也能够在老项目里理解上下文并完成迭代。这些能力单独看或许并不惊艳，但当它们组合在一起的时候，我开始觉得：AI 正在从一个代码生成工具，逐渐变成一个真正参与开发的伙伴。

当然，它距离完全替代工程师还有很长的路要走。但至少在 Vibe Coding 这条路上，我已经能够明显感觉到，产品开发正在从“人写代码，AI辅助”，逐渐变成“人负责想法，AI负责实现”。

而这或许才是这次 MiniMax M3 最值得关注的地方。