我见证了 MiniMax 的“至暗时刻” - 世界杯直播

最令人窒息的时刻，内部的争执如期而至。平息之后，我与两位争执的关键人物进行了交流。“我当时认为他说的有道理，但那一刻我就是会和他争辩。”

“反正我们吵完之后并没有个人恩怨。我们争论的只是非常微小的内部参数。”后来我了解到，在另一个场合，当再次提及当初的定价风波时，他公开表示支持那位被他点名但当时并不在场的同事。

“他缺乏的是背景信息（context），这是我们所有人的责任。”

前言：

在刚刚过去的六月，我有机会深入大模型公司 MiniMax 的内部，获得了极高的访问权限，并几乎全程见证了 M3 模型的发布过程。

M3 作为一款在中国模型中罕见的、强化了编程和 Agent 能力的原生多模态模型，承载着公司的高度期望。

最初，我受邀了解这款模型上线的过程。这家组织结构极度扁平化的公司，一切都显得十分透明，这让我几乎像一个幽灵般在其中游荡。

然而，在模型发布之后，MiniMax 迅速卷入了一场关于模型产品定价策略的争议。各种复杂因素交织在一起，这家公司很快陷入了一场小规模的危机。

因此，我也全程近距离地体验了 MiniMax 的“至暗时刻”。

这次非同寻常的经历和获得的权限尤为宝贵，它使我有机会观察一家仍在成长但已快速完成上市的公司，如何在挑战面前进行内部的争论、和解、反思以及自我审视。

一切都以十倍的速度推进，显得有些杂乱，却又充满了蓬勃的生命力。一个公司的真正特质，往往正是在这些艰难时刻被充分“暴露”出来。

现在，除了最敏感的机密信息之外，我希望能将所见所闻全部呈现出来。

第一部分：争吵

争吵如期而至。

这场争执发生在 MiniMax 内部为新模型 M3 发布而组建的百人“作战”群中。M3 是一款拥有 1M 上下文的原生多模态模型，MiniMax 对其寄予厚望，希望借此在模型能力上实现重大突破。

6月1日清晨，M3 正式发布。这款模型的定位独树一帜，当天港股早盘，MiniMax 的股价一度上涨超过 7%。

然而，风暴却随之而来。

仅仅半天时间，这个刚刚经历通宵奋战、兴奋完成模型发布的群组，就被用户转发进来的各种外部批评声音淹没。

争议的焦点集中在该模型同步发布的定价方案上。

M3 的发布伴随着新收费体系的上线：从之前的订阅制 Coding Plan 转向按 token 计费的新版 Token Plan。由于模型本身的变动，部分用户很快发现，在同等使用强度下，额度消耗的速度远超预期。更关键的是，此次调整缺乏充分的解释：没有用户短信通知，没有站内信提醒，甚至官方页面上的说明也含糊不清。许多个人开发者在登录后才惊觉：规则已经改变。

不满情绪开始蔓延，有人涌向投诉平台要求退款，有人宣布不再续订，并在社交媒体上表达他们的不满。

当时，我已经“潜入” MiniMax 一小段时间。我几乎第一时间看到了这些截图，它们迅速涌入了内部的各个群组。

那些没怎么休息好的员工们再次迅速聚集起来，讨论如何向用户进行解释。在同步了内部的设计思路后，大家很快意识到此前确实存在沟通不足的问题。改进方案也随之提出。当天晚些时候，道歉公告发布——承认在调整前未能与用户进行充分沟通，以及对老用户周限额的处理不当，“是我们工作上的疏忽”。

尽管如此，MiniMax 当天的股价最终还是转为下跌，收盘时跌幅达到 15.71%。

每个人都在忙碌，每个人都能感受到情绪的变化。

模型发布后的第二天，焦虑和沮丧达到了临界点。一位技术负责人终于在群里直接质问负责开放平台的同事，质疑定价方案的设计思路，而后者正是服务于模型产品用户和客户的部门。

对方自然要进行辩解，双方就此争执起来。

剑拔弩张的背后，是巨大的落差。过去数月，MiniMax 全体员工都专注于一款至关重要的模型，而现在，所有人的注意力都被完全转移，每个人都迫切地想弄清楚发生了什么，并尽快解决问题。

我曾目睹模型发布前大家的期待，对我而言，这似乎预示着一场互相指责的开端。

争吵是任何一个正常运转的组织中都无法避免的，我总觉得这是窥探一家公司特质的绝佳切入点。而此刻，它毫无预警又恰到好处地发生在我面前。

他们围绕定价档位的划分、额度的对应关系，以及设计时是否充分考虑了用户视角等问题各执一词，火药味十足。然而，就在激烈的情绪对抗中，仅仅一个小时后，套餐设计就完成了更新。

这是一场高效的争吵。

后来我发现，这样的争吵在 MiniMax 并不少见，有时发生在大型群组中，有时在会议室里，有时甚至出现在最高层的讨论中，总之，很多时候就是这样，当着任何人的面发生。

风波稍有平息后，我约了两位争吵的关键人物在会议室进行交流。

我与其中一人聊了一会儿，另一人也推门而入。我本以为他们之间会有些尴尬，但似乎丝毫没有。

“我觉得他当时说的是对的，而且后来事实上也按照他说的进行了调整。”其中一人指着另一人说道。“但当时我就是会和他争辩。”

“反正我们吵完之后并没有什么个人恩怨。”另一人表示。“我们争论的只是非常细致的内部参数。”

而后来据我了解，在另一个场合，当再次讨论到当初的定价风波时，那位技术负责人公开支持了那位与他争执过的、当时并不在场的开放平台同事。他认为定价方案的整体方向没有问题，真正的问题在于后者加入公司才两三个月，并未经历过更早版本的套餐以及之前用户的情绪积累。

“他缺乏的是背景信息（context），这是我们所有人的责任。”

第二部分：Context

在 MiniMax，大部分员工通常在上午十点半左右陆续抵达公司。午餐和晚餐由公司统一订餐，无需打卡——反而是周末加班时才需要打卡，这种反向的考勤制度旨在保护员工。

中午时分，办公区域逐渐热闹起来。位于漕河泾的三层办公区，每个区域都像“大通铺”，四周分布着以各种星星命名的会议室，使用率几乎饱和，员工们经常找不到空闲的会议室。几个大型会议室则用于接待访客以及召开每周一次的全员会议。这个每周五午餐时间举行的全员会议，会邀请各行业的嘉宾进行分享。最近一次，一位从美国进修回来的上海交大教授分享了心理学与 AI 的关系，员工们通过线上提问，探讨“Anthropic 称模型表现出明显的焦虑和神经质，从心理学角度如何解释这种现象，以及如何将其归因于训练方式和数据？”

模型发布前的一个工作日也是周五，全员会议照常进行，嘉宾是《凡人修仙传》的编剧。

公司里许多人都是忠实粉丝，包括 IO（MiniMax 创始人闫俊杰的花名，本文中将持续使用此内部名称）。线上提问区最受关注的“问题”只有两个字：“催更”。

气氛轻松愉快，然而，在 48 小时后，变成 MiniMax 自己被“催更”了。

6月1日，M3 发布前夜，MiniMax 的大部分员工聚集在上海总部。这一晚，有人在办公区监控服务稳定性，有人在群里追踪模型训练进度（checkpoint），也有人在小型会议室围着一桌小龙虾，熬夜讨论最终细节。

尽管如此，这家公司最习惯的协作方式仍然是在线进行，而且其主要的沟通群组并非按部门或业务划分，而是谁掌握了某项事务的背景信息（context），谁就会被拉入同一个群组。重要事项也会迅速发起会议，快速开始，快速结束。许多关键信息会在群组中突然出现，并被所有相关人员同时知晓。

Context，是这家公司所有行动中潜移默化强调的核心。为此，公司极大地鼓励信息的自由流动。

这种组织方式给我的第一印象是混乱而热火朝天：群组众多，信息传递迅速，人与人之间几乎没有太多缓冲层。感觉就像一个广场。

6月1日凌晨，新模型 MiniMax M3 进入上线前的最后阶段，我看到所有算法和开发工程师都进入了同一个文档，更新最新的 checkpoint 跑出的榜单成绩，以及对模型技术细节的最终描述。

隔着屏幕看着几十个光标同时闪烁、移动、修改，仿佛整个公司都挤在一张纸上。

IO 也挤在其中。

在 M3 发布前的这个凌晨，我看到 IO 被拉进一个沟通群组，算法和关键技术方向的同事正在敲定一些核心细节，讨论热烈，每个人都在提出自己的看法。

IO 大部分时间是在倾听，这并非一种所有人听他指挥的讨论模式。但在最后，在获得了足够多的背景信息（context）之后，他会突然开口，做出最终决定。

在观察和体验了这家公司大量的协作过程后，我发现这是一个常态——

某个重要事项需要谁参与，想到后会第一时间将这个人拉进来，因为相信背景信息（context）足够清晰，任何人都能迅速提供和获取新信息，IO 也不例外。而在充分的背景信息下，他依然是那个进行研判、决策，以及在更复杂和关键事项中做取舍的角色。

在模型发布前的那个紧张的 48 小时里，我能真切地感受到群组中弥漫的兴奋。

M3 并非一次普通的更新。它寄托了这家公司对自身的许多期望。也正因如此，当他们的兴奋和期待遭遇因“缺乏 context” 而导致的 Token Plan 争议、攻击甚至谩骂冲击时，对团队中的许多人来说，这无疑是一次“至暗时刻”。

第三部分：症结

3月，OpenClaw 带来了大规模的 Agent 启蒙。MiniMax 当时的模型 M2.5 抓住了用户在“养虾”（指代 Agent 应用）上的热潮，凭借其极高的性价比和足够的能力，成为了这类产品的理想选择，MiniMax 也迎来了模型发展的一个高光时刻。

然而，模型领域的格局变化极快。3月18日，MiniMax 迅速推出了 M2.7，一个激活参数仅约 10B 的模型。

随后的两个月里，Kimi 开源了 K2.6，DeepSeek 的 V4 实现了 1M 上下文，智谱的 GLM-5.1 宣布其编程能力已逼近 Claude Opus 4.6；在大洋彼岸，Anthropic 推出了 Claude 5，OpenAI 的 GPT-5.5 也加入了竞争行列。

M2.7 的用户开始觉得这个定位的模型已不再够用。

一位产品线员工向我分享了后台用户对模型的反馈：当时的问题分类中，有六成指向了模型本身的问题。

外界容易忽视的一点是：MiniMax 是中国最早投入大模型训练的公司之一，并且一直以来对模型投入的资源也都是最大的。然而，由于 MiniMax 自身也有产品线，更多用户是通过这些产品（而非直接通过模型 API）建立了对 MiniMax 的初步认知。

在模型智能水平跨越了一个门槛后，MiniMax M2 成为首个被外界广泛认知其智能水平的模型。从内部的 KPI 和优先级来看，提升模型智能是内部最核心的目标，所有资源都被投入到交付更强大的模型上。

M3 正是这一长期目标中的一个关键节点。

“我们的全部注意力都集中在模型智能本身上了。”多位不同业务线的内部员工这样向我描述模型发布前几个月公司所有人的状态。

随着围绕 Token Plan 的争议不断被放大，在短短一天之内，我亲眼见证了这家公司交付了他们等待数月的模型，起初收获了技术圈的一些惊叹，随后因付费计划引发部分用户愤怒，不得不发布道歉声明，最终导致市值蒸发了两位数的百分比。

接下来的几天，反馈从零星的消息演变成各个群组中不断转发的信息流。后续的解决方案也接连推出。但许多批评的声音开始偏离付费计划本身，转为谩骂。内部开始发现一些账号表现出水军化的行为特征，成为情绪化传播的节点。

这一切都让公司内部感到愈发困惑，其中 MiniMax 最为在意的是，这些讨论冲淡了人们对模型本身各项技术创新以及新能力的关注。

同时，他们也以一种最令人心痛的方式意识到，缺乏提前沟通、缺乏对用户背景信息（context）的考量所造成的影响是多么惨烈。

这些问题看似难以理解，但在很大程度上源于经验的不足，也源于这家公司过于理想化的行动方式。

如前所述，M3 是 MiniMax 追求更强大模型的起点。但在在此之前的几个更轻量级模型的发布过程中，公司逐渐形成了一种习惯：模型最重要的就是让所有人都能用到，因此训练好就尽快发布，用户在使用过程中反馈的模型智能程度是最重要的。

在我与多位了解这些决策制定过程的员工交流时发现，此次收费方式的改变和设计，其实早已开始。它是追求模型能力提升的必然产物，而非表面上看起来的商业化举措。

大约在三四月份，看着训练中的模型不断变强，内部意识到：新模型对应的付费体系需要更新。旧体系过于复杂，每增加一个模型，都需要配套相应的次数，次数与套餐之间又是一层复杂的换算。开发平台的员工经常遇到用户指着一堆配置询问：“你这个是什么？我不知道是什么。”

而在对模型“终局”的判断上，内部的观点是，人们使用优质模型将越来越像使用水电煤一样，Token 将成为服务本身。

既然现有的订阅方案显然不符合未来趋势，那么就必须进行更改。那么，以何种节奏进行更改呢？

MiniMax 许多决策背后的思路再次显现：既然迟早要改，为何不早点开始。

“不改，用户可能都没法用好我们新的模型。”一位参与了当初决定制定的内部员工回忆道。

这并非 MiniMax 一家面临的困境。事实上，在 2026 年上半年，整个行业都在进行定价重估。“当一个行业在 6 个月内实现 20 倍的增长时，历史遗留问题是必然发生的，你不可能每件事都停下来做好、思考周全再往前走。”

而这一切在 MiniMax 身上变得更加复杂。

它成立仅仅四年，一切都处于快速成长的过程中。但正如我近距离观察到的那样：其内部依然保持着一家创业公司的状态。

然而，它又是最快完成上市的大模型公司，需要面对复杂的资本市场和商业化的审视。许多初创公司容易忽略的问题，因此会被放大数倍，并在一个猝不及防的时刻爆发式地呈现出来。

六月发生的一切，正是这种复杂度的集中体现，一场由模型进步带来的阵痛，以最激烈的方式，逼近在所有人面前。

第四部分：道歉

在 M3 发布后某周的例行全员会议上，公司推迟了原定的外部分享，转为内部闭门的全员复盘——全体员工以表格实名提问，将尖锐的问题抛入大群，IO 直面所有人。

在这次会议上，IO 向所有人道歉：效果未达预期，为此付出的同事们，对此深感抱歉。

我很少看到创始人如此直接地向全公司进行道歉。

接着，IO 分享了他全部的思考——关于竞争、关于技术、关于内部的组织运转方式，哪里判断失误，哪里准备不足，以及最重要的，接下来的改变措施。

“没有很复杂。接下来要做的，就是把模型做好。”有员工这样总结。

慌乱、沮丧、愤怒、公开争吵、在争吵中快速解决问题。有“问责”，也有包容，但并不撕扯，而是继续向前推进——这似乎并非所有公司都会采取的应对方式。

这勾起了我更多的好奇，我向更多人更直接地询问：在类似这样的时刻和过程中，是否出现过推卸责任的情况？

一位曾在 AI “大厂”工作过的员工思考了一下，向我对比了大厂的做法——大厂的思路是：“这件事谁没做好？他为什么没做好？责任是谁的？”而在 MiniMax，IO 会非常冷静客观地陈述：“这件事里哪些做得好，哪些做得不好，产品团队有哪些做得不够的地方。”

“当他说的是客观事实时，客观事实是不会给人带来额外压力的。”

这种“就事论事”的特质，我在许多员工那里听到了类似的描述，它显然不是一种可以“设计”出来的氛围。

一位曾在大厂模型团队工作，因受够了内部山头林立、争抢资源、安插眼线、频繁甩锅等制度性缺陷对模型研发造成持续侵蚀而愤然离开，转而加入 MiniMax 的员工告诉我，你其实可以很快发现这里完全不同。

“在一些公司，你会感到非常没有安全感，担心你的项目会突然消失，担心有人给你甩锅，担心你与隔壁组织的协同，担心他去投诉你，仅仅因为 KPI 不同。而在 MiniMax，人们可以在大群里吵架，没关系，因为创始人为你营造了一种环境：我们只要把事情想对、把事情做对，就没有问题。”

还有不少员工看到过两位联合创始人之间直接发生激烈的争吵——然后下一场会议，两人又正常地继续工作。

“我一开始嘀咕，他们俩怎么能吵成这样？吵完了马上又好好说话。后来我觉得这也是身体力行地在印证：这就是一个就事论事的公司。”

创始人不仅会直接参与争吵，也会被员工挑战。

一位开发团队的员工向我描述，他和 IO 也会“吵架”，争论过很多次，而有时 IO 也会认同他的观点。

还有一次，我看到群里在讨论一些思路，某个方案下，来自 IO 的一个“点赞”快速回复表示认可。紧