最令人紧张的时刻，内部的争论如约而至。在平息之后，我与两位争论的核心人物进行了交流。“我当时觉得他说得很有道理，但当时我就是忍不住会和他争论。”

“反正我们吵完之后并没有个人恩怨。我们争论的都是非常细致的内部参数。”后来我了解到，在另一个场合，当再次谈及当初的定价风波时，他主动维护了那位当时并不在场的、曾被他点名的同事。

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

前言

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

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

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

然而，在模型发布后，MiniMax 迅速陷入了另一场围绕模型产品定价的争议之中。各种复杂因素交织，公司陷入了一场小型危机。

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

这次独特的经历和获得的权限实属难得，让我有机会观察一家仍在成长、但已快速完成上市的模型公司，在面对挑战时，如何经历内部的争吵、和解、反思及自我审视。

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

现在，除了那些最核心的机密信息，我希望将我所见的一切呈现出来。

1. 争吵

争论如期而至。

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

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

然而，风暴却随之而来。

仅仅半天后，这个刚刚全员熬夜兴奋完成模型发布的群组，便被用户转发进来的各种外部批评声音所充斥。

争议的核心是该模型同步发布的定价方案。

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

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

那时，我已经“潜入” MiniMax 一段时间。我几乎第一时间看到了这些截图，并迅速被传送到内部的各个群组。

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

尽管如此，MiniMax 当天的股价依然一路下滑，收盘下跌 15.71%。

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

模型发布后的第二天，焦虑和沮丧的情绪达到了临界点。一位技术负责人终于在群组中直接质问开放平台部门的同事：询问该定价方案是如何设计的。开放平台部门负责服务模型产品的用户和客户。

对方自然试图辩解，两人随即发生了争吵。

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

我曾目睹模型发布前的期待，对我而言，这似乎是互相指责的开端。

争吵在任何正常运转的公司组织中都难以避免，我总觉得这是窥探公司特质的一个绝佳窗口。而现在，它毫无预警且恰到好处地发生在了我面前。

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

这是一场高效率的争吵。

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

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

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

“我觉得他当时说得很有道理，而且后来事实也证明确实是按照他说的改了。”其中一人指着另一人说道。“但当时我就是忍不住和他争论。”

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

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

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

2. 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 也不例外。而在充分的 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 不同。而在 MiniMax，人们可以在大群里吵架，这没关系，因为创始人为你营造了一种环境：我们只要把事情想对、把事情做对，就没有问题。”

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

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

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

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

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

讨论结束后，大家普遍认为新的思路更有道理。

一切都围绕如何做好事情。当做错了，就坦然接受批评，然后快速改进