在 MiniMax 公司内部，内部争吵在所难免。在一次紧张的争执平息后，我与两位争吵的当事人进行了交流。其中一位表示：“我当时认为他说得有道理，但当时我就是会和他争吵。”另一位则说：“无论如何，我们吵完架后并没有个人恩怨，争论的只是非常具体的内部参数。”据我后来了解，在另一场合，当再次谈及当初的定价争议时，他主动维护了那位并未在场的、曾被他点名的同事。

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

引言：

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

M3 作为中国模型领域少有的、强化了编程和 Agent 能力的原生多模态模型，承载着公司极高的期望。

最初，我受邀了解这款模型上线的过程。由于 MiniMax 组织结构高度扁平化，一切都显得十分透明，我几乎像一个隐形的观察者，在其中游荡。

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

因此，我近距离体验了 MiniMax 的这段“至暗时刻”。

这次独特的经历和获得的权限十分难得，让我得以窥见一家仍在成长、但已快速完成上市的模型公司，在面对挑战时所经历的内部争吵、和解、反思以及自我审视。

一切都以十倍速展开，显得杂乱却充满生命力。一家公司的真正特质，往往正是在这些困难时刻得以“暴露”。

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

1. 争吵

争吵如期而至。

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

6月1日清晨，M3 正式发布，其独特的定位吸引了市场关注。当天港股早盘，MiniMax 股价一度上涨超过 7%。

然而，风暴很快降临。

仅仅半天后，这个刚刚经历通宵发布、充满兴奋的群组，就开始被不断转发的外部批评信息淹没。

争议的焦点在于与 M3 同步发布的定价方案。

此次 M3 发布伴随着新的收费体系上线：从之前的订阅制 Coding Plan 转向按 token 计费的新版 Token Plan。由于模型本身的改变，一些用户发现，在同等使用强度下，额度消耗速度远超预期。更关键的是，此次调整缺乏充分的解释：用户未收到短信或站内信，官方页面上的说明也不够清晰。许多个人开发者登录后才意识到规则已变更。

不满情绪开始发酵，部分用户涌向投诉平台要求退款，有人宣布不再续订，并在社交媒体上表达不满。

我当时已在 MiniMax “潜伏”了一段时间，几乎第一时间看到了这些截图在内部各个群组中传播。

那些没怎么休息的员工迅速再次集结，讨论如何向用户解释。在内部同步设计思路后，大家立刻意识到此前沟通的不足。很快，改进方案被提出。当晚，道歉公告发布，承认在调整前未能与用户充分沟通，以及对老用户周限额处理不当，“是我们工作不到位”。

尽管如此，MiniMax 当天股价依然转跌，收盘下跌 15.71%。

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

模型发布次日，焦虑和沮丧情绪达到临界点。一位技术负责人直接在群里质问开放平台部门的同事，质疑该定价方案的设计。开放平台部门负责服务模型产品用户和客户。

对方自然开始辩护，双方争吵起来。

剑拔弩张的背后，是巨大的落差。过去数月，MiniMax 全员倾注于一款至关重要的模型，而现在关注点却完全跑偏，每个人都急于弄清状况并快速解决问题。

我曾目睹模型发布前大家的期待，而此刻，这仿佛是一场互相指责的开端。

争吵是任何公司化运作的组织中不可避免的现象，我总觉得这是窥探一家公司特质的绝佳窗口。此刻，它毫无预警且恰到好处地展现在我面前。

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

这是一场高效率的争吵。

后来我发现，类似的争吵在 MiniMax 并不少见，有时发生在大型群组，有时在会议室，有时在高层讨论中，总是在很多人面前发生。

风波稍稍平息后，我约了两位争吵的主角在会议室进行交谈。

我与其中一人聊了一会儿，另一人也推门进来。我本以为他们之间会有些尴尬，但似乎毫无影响。

“我觉得他当时说得是对的，而且后来事实上也按照他说的改了。”其中一人指着另一人说，“但当时我就是会和他吵架。”

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

据我后来了解，在另一个场合，当再次讨论到当初的定价风波时，那位技术负责人主动维护了那位与他发生争执、但当时并不在场的开放平台同事。他认为定价方案的整体方向没有问题，真正的问题在于那位同事入职公司仅两三个月，并未经历过更早版本的套餐和用户情绪。

“他缺的是 context，这是所有人的责任。”

2. Context

在 MiniMax，大部分员工会在上午 10 点半左右陆续到公司。午餐和晚餐由公司安排，无需打卡——反而是周末加班时才需要打卡，这种反向的考勤机制是为了保护员工。

中午时分，办公区逐渐热闹起来。位于漕河泾的三层办公区，每个区域都像是“大通铺”，四周分布着以各种星星命名的会议室，使用率几乎饱和，员工们经常找不到空闲的会议室。几个大型会议室用于接待访客和每周一次的全员大会。这个每周五午餐时间的全员会会邀请各行业人士进行分享。最近一次，一位从美国研学归来的上海交大教授分享了心理学与 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 也不例外。而在充分的 context 下，他依然是那个进行研判、决策，以及在更复杂和关键事项中做取舍的角色。

在发布模型前那紧张的 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 也有自己的产品，更多用户是通过这些产品（而非模型本身）建立了对 MiniMax 的第一印象。

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

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

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

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

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

这一切让人们越来越困惑。其中，MiniMax 内部最在意的是，这些讨论冲淡了人们对模型本身各项技术创新和新能力的关注。

同时，他们也以一种最刺痛的方式意识到，缺乏提前沟通、缺乏对用户的 context 所造成的影响有多么惨烈。

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

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

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

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

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

既然当前的订阅方案显然不符合未来趋势，那就需要改变，如何节奏地改变？

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

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

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

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

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

然而，它又是成长最快完成上市的大模型公司，面临着复杂的资本市场和商业化审视。那些初创公司通常会忽略的问题，因此被放大了数倍，在一个猝不及防的时刻，以爆发式的方式呈现出来。

六月的一切就是这种复杂度的集中体现，一场因模型进步带来的阵痛，以最激烈的方式，逼近了所有人。

4. 道歉

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

在这次会议上，IO 向所有人道歉：“效果没有达到预期，为此付出的同事，对不住。”

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

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

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

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

这引起了我更多的好奇，我询问了更多人，更直接地问：“在类似这样的时刻和过程中，有没有发生过甩锅？”

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

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

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

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

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

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

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

创始人不仅会亲自下场争吵，也会被员工挑战。

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

还有一次，我看到群里在讨论一些思路，某个方案下，IO 快速回复了一个“点赞”表情，表示认可。紧接着，有其他掌握更完整 context 的员工，直接批评并否决了该方案。

之后，大家认为新提出的思路更有道理。